Wcf 回调网络 tcp 双工仅 1 路故障答案

【问题标题】：Wcf callback net tcp duplex only 1 way faultedWcf 回调网络 tcp 双工仅 1 路故障
【发布时间】：2012-02-17 04:43:45
【问题描述】：

我有一个使用 net tcp 双工回调的自托管 wcf 服务

在客户端，我在 Channel 和 ChennelFactory 上监听故障事件。当频道发生故障时，客户端将重新创建频道并重新订阅。

在服务器端，我通过调用OperationContext.Current.Channel 存储回调通道和通道的引用，以便我可以在此通道上监听故障和关闭事件。发生故障时，服务器将删除该订阅者。

这大部分时间都在工作，直到最近我观察到一个意外行为：服务器上的回调通道出现故障，但客户端上的通道似乎没问题，这导致客户端没有重新订阅，而服务器已经删除了它订阅者和客户端不会收到任何回调。

我认为在双工通信中，如果一端感应到故障，则应该是双工通道故障。

启用了可靠会话并且超时时间很长（2 小时）（也许这会导致客户端无法足够快地感知故障？）

谁能解释为什么会这样？

另一个问题是为什么它还是有故障的？我连接了 40 个客户端，但服务器会在随机时间检测到一个随机客户端出现故障。

【问题讨论】：

【解决方案1】：

我不确定原因。但我认为通道可能会以故障事件永远不会到达客户端或服务器的方式失败。当客户端突然崩溃时，也需要考虑这种情况。

无论如何，在我的项目中，我得出的结论是，依靠故障通道事件是不够可靠的。所以我经常通过回调通道从服务器ping所有订阅者。如果客户端在超时限制内没有回复，则将其从订阅者列表中删除。

您还可以从客户端捕获超时异常并在必要时重新创建通道。

【讨论】：

【解决方案2】：

长时间超时不应该受到责备，我确信这是因为我处于相同的情况并且我也遇到过短超时的问题。

在服务端处理故障通道很容易。您可以在回调调用周围进行尝试/捕获，并仅在实际需要时处理它。

在客户端，现在我没有看到任何合理的方法。希望有人会在这里提出一些建议......

【讨论】：