我有一个双工WCF服务，它依赖于服务和客户端之间的一致命名管道连接。它是一种发布/订阅系统，客户端在服务上调用Subscribe并将其放入订阅列表中。然后，该服务调用自己的某些更新方法，这将通过回调将更新推送到客户端。
我已将netnamedpipebinding的recieveTimeout设置为“infinite”。我可以合理地依赖这种联系永远开放吗？更重要的是，是否存在通道在超时之外发生故障的情况？
由于命名管道只是一个共享内存位置，我无法想到除了硬件问题之外它会一直失败的原因。此外，在一定的时间间隔内，没有太多方法可以保证ping之外的连接。
另一方面，我的直觉是避免使客户端成为WCF服务。我知道这不是一个真正的循环依赖，但它只是感觉icky。但是，我向人们开放，告诉我，我只是偏执狂，而且这种模式是好的。
答案 0 :(得分：3)
您永远不能依赖连接。服务上的单个未处理异常/故障将关闭该通道。我认为您应该在客户端处理Closed和Faulted事件，或者使用代理重新创建和重新订阅来实现ping机制。
使用双工通信时，您只需要客户端公开合同 - 它与公开服务不同，因为客户端不公开端点。通过从客户端到服务创建的单个通道执行通信，因为命名管道是双工设计的。每次您希望通过某些传输进行双工通信时，您需要在客户端上使用一些处理代码。