WCF TCP 双工绑定配置的发布/订阅模式答案

【问题标题】：Publish/Subscribe Pattern for WCF TCP Duplex Binding ConfigurationWCF TCP 双工绑定配置的发布/订阅模式
【发布时间】：2016-01-14 11:10:49
【问题描述】：

在将 WCF TCP 绑定用于双工回调作为发布/订阅设计模式的一部分时，我遇到了 WCF 配置难题。

要求客户端使用单向回调从服务器接收通知。不知道何时会收到通知，因此目的是无限期地保持连接打开。如果客户端或服务器收到异常，则启动清理过程以正确关闭、中止和清理 CommunicationObject，然后发出新连接以继续接收通知。

我具有配置客户端和服务器 WCF 端点的显式访问权限。我的困境是我是否应该：

A.将 sendTimeout 和 receiveTimeout 配置属性设置为 infinite 以尽可能长时间地保持连接打开，同时仍处理异常以重新打开连接。

或者

B.将sendTimeout 和receiveTimeout 保持在较短的时间范围内，例如1 小时。客户端或服务器会接收到超时，进行清理，然后建立新的连接。

使用一个比另一个有优势还是 WCF 不是解决我的问题的可行解决方案？

我的目标是尽可能保持最高可用性。

编辑：

我担心超时的原因是服务器意外关闭或超时连接而客户端没有通过Faulted 和Closing 事件收到任何通知，但我可以确认客户端和服务器都对sendTimeout 和receiveTimeout 使用无限超时。这通常发生在 24 小时的时间范围内。

在 MSDN 文档中搜索 WCF Duplex model 我阅读了以下声明：

双工模型不会自动检测服务或客户端关闭其频道。因此，如果客户端意外终止，通过默认不会通知服务，或者如果客户端意外终止，服务将不会被通知。客户和服务可以如果他们愿意，实现他们自己的协议以相互通知。

这让我想问是否有人有解决方案来实现他们自己的协议以保持会话处于活动状态，因为这是我遇到的问题？

我是否需要简单的客户端线程定期向服务器发送“心跳”？显然我不想通过心跳向网络发送垃圾邮件，但同时尽可能保持会话处于活动状态。

我相信ReliableSession 不会为这个问题带来真正的好处。

【问题讨论】：

【解决方案1】：

我认为您应该将receiveTimeout 保留为infinite，仅此而已。每小时重新创建一个频道没有任何好处。

您不需要将 sendTimeout 设置为 infinite，因为这是一个超时，它定义了 WCF 基础结构在声明无法发送消息之前等待多长时间。

PS 在我们的应用程序中，我们使用了类似的技术，并且通道保持打开数周没有任何问题。

【讨论】：

感谢您的回复 - 根据我发现的与双工模型有关的一些研究，我扩展了我的问题。非常感谢您在此主题上的经验。
是的，我们确实在一些连接上实现了心跳。就像每分钟左右调用一次Ping() 方法一样。这不会为故障连接提供即时反馈，但在我们的业务中已经足够了。我还必须说，我们的客户端在与服务器的不同端点上维护了大约 8 个连接，并且它们都是“永久的”。但只有其中一个（特殊的、专用的）用于心跳。我们还没有看到任何一个连接关闭而其他连接还活着的情况。