WCF - 长时间保持通道开放是不好的做法吗？
我刚刚了解 WCF 的相关知识。我打算做的是使用 NetTcpBinding 在客户端和服务器之间打开一个双工通道，并无限期地保持该通道打开，以便服务器可以向客户端发起请求。
然后我偶然发现了这个 Jesse Ezell 的博客，这似乎表明无限期地保持通道开放是一件坏事，因为你无法发现错误，这会导致各种不稳定。
这是正确的吗？如果我使用 NetTcpBinding 并保留对关系两侧开放通道的引用，那么如果出现通信故障，会发生什么情况？如何捕获失败事件？还有哪些其他问题？您使用的 .NET 框架有什么区别吗？ （我用的是4.0。）
I'm just learning the ropes around WCF. What I was planning to do was have a duplex channel open between a client and server using NetTcpBinding, and keep that open indefinitely so that the server can initiate requests to the client.
Then I stumbled upon this blog by Jesse Ezell, which seems to indicate that it's a Bad Thing to keep a channel open indefinitely, because you can't catch faults, and that causes all manner of instabilities.
Is that correct? If I use NetTcpBinding and keep a reference to an open channel on either side of the relationship, what happens if there's a communication failure? How do I catch the failure event? What other gotchas are there? Is there any difference which .NET framework you're using? (I'm on 4.0.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不同意 Jesse 的观点（作为旁注：他还建议您默认使用 WCF 服务类作为单例，在我看来这是最糟糕的想法）......
只要当您小心地捕获服务器上的异常时（例如，通过在服务类中实现 IErrorHandler 接口），这里没有必要继续关闭您的通道...尤其是在公司 LAN 中使用 netTcpBinding 的环境。
与经常产生许可成本的数据库连接相反，保持与服务计算机的网络连接打开不会导致任何问题。它通常也不是有限的资源，因此不断地打开和关闭它似乎毫无意义。
如果您确实使服务通道保持开放状态较长时间，则需要在客户端具有处理故障的能力 - 例如，当发生异常时，您需要能够从通道出现故障的情况中恢复毕竟发生了（例如网络中断或类似的情况）。
但如果你这样做，那么我看不出在每次通话后不断关闭你的频道并在下一次通话时重新打开有任何好处......
I don't agree with Jesse (as a side note: he also recommends you use WCF service classes as singletons by default, which is the worst idea ever in my opinion).....
As long as you take good care of catching exceptions on the server (e.g. by implementing the
IErrorHandlerinterface in your service class), there's no point here to keep shutting down your channel... especially not in a corporate LAN environment using netTcpBinding.Contrary to e.g. a database connection which often incurs licensing costs, keeping a network connection to your service machine open shouldn't cause any issues. It's also usually not a limited resource, so constantly opening and closing it seems pointless.
If you do keep your service channel open for a longer period of time, you need to be capable on the client side to handle faults - e.g. you need to be able to recover from a situation where the channel has become faulted, when an exception has occured after all (e.g. the network is down or something like that).
But if you do that, then I don't see any benefit in constantly closing your channel after every call, and reopening for the next...
是的，一旦不再需要该通道，就将其关闭是一个很好的做法。但在双工通信的情况下并不常见。当您使用双工通信时，您需要打开通道以允许服务器将消息发送回客户端。 WCF 通信始终由客户端发起。只有保持客户端发起的通道打开才允许回调。
双工通信涉及一些处理连接失败的附加任务。您的服务应该包含一些 ping 机制，以允许客户端定期检查连接。如果连接失败，客户端会收到异常，您将能够重新建立连接。此外，服务应在向故障通道发送回调消息时处理异常。
Yes it is good practice to close the channel as soon as it is not needed any more. But it is not usual in case of Duplex communication. When you are using duplex communication you need opened channel to allow server send messages back to the client. WCF communication is always initiated by the client. Callback is allowed only by keeping channel initiated by the client openned.
Duplex communication involves some additional tasks to handle connection failures. Your service should contain some ping mechanism to allow client to check the connection in regular interval. If the connection fails client receives exception and you will be able to reestabilish connection. Also service should handle exception when sending callback message to faulted channel.