在双工绑定 WCF 应用程序中处理丢弃的客户端

Posted 2023-04-18

【中文标题】在双工绑定 WCF 应用程序中处理丢弃的客户端

【英文标题】：Handling dropped clients in a duplex binding WCF application

【发布时间】：2011-06-02 03:40:14

【问题描述】：

我们在 WCF 应用程序中使用了一个 pub-sub 模型，该模型几乎遵循 Microsoft 示例：Design Patterns: List-Based Publish-Subscribe。

虽然服务提供了subscribe() 和unsubscribe() 的概念，但在客户端死亡或通道故障的情况下处理清理的最佳做法是什么？目前，当客户端订阅时，我将处理程序附加到当前 InstanceContext 的 Closed 和 Faulted 事件（服务用户使用 PerSession 实例上下文模式和 netTcpBinding）：

_communicationObject = OperationContext.Current.InstanceContext;
_communicationObject.Closed += OnClientLost;
_communicationObject.Faulted += OnClientLost;

OnClientLost 处理程序只是取消订阅客户端，但是：

上述方法是否是一种良好的做法，并且足以在客户端中断双工通信时捕获所有情况？还是服务应该只处理在尝试与客户端通信时遇到的异常并随后处理清理？ 除了取消订阅客户端回调处理程序之外，是否应该执行任何进一步的清理，尤其是在出现故障的情况下？

This question 提出了类似的问题，但最终并未对客户调用订阅和/或取消订阅之外的案例提供答案

谢谢

【参考方案1】：

我做了一些测试，将处理程序附加到回调通道的 Closed 和 Faulted 事件，然后在服务器调用回调之前终止客户端。在每次试验中，Closed/Faulted 事件会在服务器尝试调用回调之前立即触发。尽管如此，我仍然将回调调用包装在 try-catch 块中，因为客户端通道的破坏可能会在另一个线程进入回调时发生。

唯一需要清理的是删除对回调通道的引用。 WCF 和垃圾收集器完成剩下的工作。

【参考方案2】：

处理这些事件将使您的订阅者列表保持同步。它确实足够强大。请记住，如果客户端在消息传输期间掉线，您可能会在这些事件触发之前收到异常，因此请准备好忽略它们以便清理事件。

除了从订阅者列表中删除客户端外，其他清理完全取决于您的应用程序（即释放您在客户端连接时获得的资源）。我不知道需要进行任何其他清理。