如果出现故障，如何自动重建双工通道？

Question

我正在使用WCF在.Net 3.5中开发客户端/服务器应用程序。基本上，长时间运行的客户端服务（在多台计算机上）通过netTcpBinding建立到服务器的双工连接。然后，服务器使用客户端的回调契约来执行某些按需操作，客户端以异步方式响应（我认为这是相当标准的东西）。我将DuplexClientBase类子类化以处理大部分通信。

不幸的是，当两端出现问题时（例如网络故障，意外异常等），通道出现故障/中止，所有后续操作都会失败。我通过创建一个RecoveringClientBase类来解决非双工通道中的这种限制，该类在客户端出现故障并重试操作时自动获取。

所以我的问题是，是否有确定双工通道何时出现故障的既定方法？我应该在服务器或客户端上检查这个位置？如果做不到这一点，我有什么选择来确保重新建立连接？

更新：我正在寻找一些特定于双工通道的建议，服务器可能会尝试使用出现故障的回调通道。因此，当频道发生某些事情时，我需要立即重新连接/重新订阅的内容。目前，我正在收听频道的Closing事件，如果状态不是已关闭，则重新创建它。它有点工作，但感觉很烦人......

Answer 1

我在长时间跑步（分钟 - 小时）中经历过邋。我不能确定它是WCF，我很确定它的网络级别。

我想完全废除双工。尝试管理连接状态真是令人讨厌。

我正在考虑在客户端上托管服务端点，以获取当前属于回调合同的操作。客户端将使用端点详细信息联系服务器，服务器可以将这些存储在某处（持久或任何地方）。当服务器需要联系客户端时，它会通过隐藏的端点详细信息打开与客户端的连接。基本上，将双工连接转换为2个客户端 - 服务器连接。

不回答你的问题，但我感到痛苦。

Answer 2

来自WCF团队的Nicolas Allen对此提出了建议：

http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx

他的建议是在频道级处理这个问题。通道级别更好一些，因为您可以通过行为将其插入任何绑定的堆栈，而不需要自定义客户端基类。

Answer 3

我遇到了一些类似的问题，对我而言，似乎这些长时间运行的呼叫或多或少都不受支持。

WCF似乎被设计用于短期运行的呼叫。被叫的服务会做一些小事，然后完成。

我将我的应用程序重构为较小的工作项目。因此，我现在获得了很多较小的物品，而不是一个长期运行的物品。 当然，有时这是不可能实现的。然后我得为稳定的网络连接祈祷（可以捕获异常，因此我认为错误不是真正的问题）。

Answer 4

我认为你真的应该听错事件。 你可以在两端听到它，客户端我觉得你已经在处理了，服务器端是OperationContext.Current.Channel.events。

我还没有找到一种方法来自动重新发送消息，因为你的回调通道已经出现故障并且你还不知道新的回调通道，但需要在服务器的某处保留这些调用，直到客户端重新连接。

客户端最终会出现故障并且应该重新与服务器握手，这是点服务器应该发送未发送的呼叫。

基本上从故障/封闭通道中恢复的唯一方法是用新的替换它，但是，最关键的部分是你应该真正检测断开ON TIME，我发现启用可靠会话将按时引发故障事件大多数情况。或者，您可以在两端发送心跳消息以“测试”通道出现故障。