netnamedpipebinding无限receiveTimeout有多可靠？

Question

我有一个双工WCF服务，它依赖于服务和客户端之间的一致命名管道连接。这是一种发布/订阅系统，客户在该服务上调用Subscribe，并将其放入订阅列表中。然后，服务会调用其自己的某些更新方法，这会通过回调将更新推送给客户端。

我已经设置了recieveTimeout为netnamedpipebinding为“无限”。我能否合理地依靠这种联系永远开放？更重要的是，有些情况下频道会在超时之外发生故障吗？

由于命名管道仅仅是一个共享的存储位置，我想不出有很多原因，这将始终如一地失败，除了硬件问题。此外，在一定的时间间隔内，没有太多的保证ping之外的连接的方式。

在一个侧面说明，我的直觉是避免也使客户端的WCF服务。我知道这不是一个真正的循环依赖，但它只是感到恶心。不过，我对有人告诉我，我只是偏执狂，而且这种模式是好的。

Answer 1

你永远不能依靠连接上。服务中单个未处理的异常/故障将关闭该通道。我认为你应该在客户端处理Closed和Faulted事件，或者通过代理娱乐和重新订购来实现ping机制。

当使用双工通信，你只需要在客户端暴露的合同 - 这是不一样的公开服务，因为客户不公开的端点。通信由从客户端到服务创建的单个通道执行，因为命名管道是按设计双工的。每次你想通过一些传输进行双工通信时，你需要在客户端上有一些处理代码。