我使用net tcp duplex callback
进行自托管的wcf服务在客户端，我在Channel和ChennelFactory上听故障事件。当频道出现故障时，客户端将重新创建频道并重新订阅。
在服务器端，我通过调用OperationContext.Current.Channel存储回调通道和存储通道的引用，以便我可以监听此通道上的故障和已关闭事件。出现故障时，服务器将删除该订户。
这大部分时间都在工作，直到最近我发现了一个意外的行为：回调通道在服务器上出现故障但通道在客户端似乎没问题，这导致客户端在服务器已经删除时没有重新订阅订阅者和客户端将不会收到任何回调。
我想在双工通信上，如果一端检测到故障，双工通道应该出现故障。
启用可靠会话并且超时很长（2小时）（这可能会导致客户端无法快速感知故障？）
有人可以解释为什么会这样吗？
另一个问题是它为何会出现故障？我连接了40个客户端，但服务器会在随机时间检测到随机客户端出现故障。
答案 0 :(得分：2)
我不确定原因。但我认为某个频道可能会因故障事件永远不会到达客户端或服务器而失败。还有一种情况需要考虑客户端何时崩溃。
无论如何在我的项目中我得出的结论是，依赖故障频道事件是不够可靠的。所以我经常通过回调通道从服务器ping所有用户。如果客户端未在超时限制内回复，则会从订户列表中删除它。
从客户端，您还可以捕获超时异常，并在必要时重新创建通道。
答案 1 :(得分：1)
长时间超时不应该受到责备，我确信这是因为我处于相同的情况，我也遇到了短暂超时的问题。
处理服务方面的故障渠道很容易。您可以在回调调用周围进行try / catch，并仅在实际需要时处理它。
在客户端，我现在没有看到任何合理的方法。希望有人会在这里提出一些建议......