netnamedpipebinding 无限 receiveTimeout 的可靠性如何？
我有一个双工 WCF 服务，它依赖于服务和客户端之间一致的命名管道连接。这是一种发布/订阅系统，客户端在服务上调用 Subscribe 并将其放入订阅列表中。然后，服务调用自己的某些更新方法，这将通过回调将更新推送到客户端。
我已将 netnamedpipebinding 的 receiveTimeout 设置为“无限”。我可以合理地依赖此连接永远打开吗？更重要的是，是否存在通道在超时之外发生故障的情况？
由于命名管道只是一个共享内存位置，因此除了硬件问题之外，我想不出它会持续失败的许多原因。此外，除了按一定时间间隔执行 ping 操作外，没有太多方法可以保证连接。
顺便说一句，我的直觉是避免让客户端也成为 WCF 服务。我知道这不是真正的循环依赖，但感觉很恶心。然而，我愿意接受人们告诉我，我只是偏执，这种模式是可以的。
I have a duplex WCF service that relies on a consistent named pipe connection between the service and the client. It's sort of a publish/subscribe system where the client calls Subscribe on the service and gets put in a subscription list. Then, the service calls certain update methods of its own, which will push the update to the client(s) via callbacks.
I've set the recieveTimeout for the netnamedpipebinding to "infinite." Can I reasonably rely on this connection to be open forever? More importantly, are there situations where the channel will fault outside of timeouts?
Since a named pipe is just a shared memory location, I can't think of many reasons why it would fail consistently besides hardware problems. Furthermore, there isn't much of a way of guaranteeing the connection outside of pinging at a certain interval.
On a side note, my gut feel is to avoid also making the client a WCF service. I know it's not a real circular dependency, but it just feels icky. However, I'm open to people telling me I'm just being paranoid and that that kind of pattern is a-okay.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你永远不能依赖这种联系。服务上的单个未处理的异常/故障将关闭通道。我认为您应该在客户端上处理 Closed 和 Faulted 事件，或者通过代理重新创建和重新订阅来实现 ping 机制。
使用双工通信时，您只需要客户端公开合约 - 这与公开服务不同，因为客户端不公开端点。通信是通过从客户端到服务创建的单个通道执行的，因为命名管道在设计上是双工的。每次您想要通过某些传输进行双工通信时，您都需要在客户端上编写一些处理代码。
You can never rely on the connection. Single unhandled exception / fault on the service will close the channel. I think you should handle Closed and Faulted events on client or implement pinging mechanism with proxy recreation and resubscribtion.
When using duplex communication you simply need the client to expose contract - it is not the same as exposing the service because client do not expose an endpoint. The communication is performed by single channel created from client to service because Named pipes are duplex by design. Every time you will want to have duplex communication over some transport you will need some handling code on the client.