在将双工回调作为发布/订阅设计模式的一部分使用WCF TCP绑定时，我遇到了WCF配置困境。
要求客户端使用单向回调从服务器接收通知。未知何时收到通知，因此目的是使连接无限期地保持打开状态。如果客户端或服务器收到异常，则启动清理过程以正确关闭，中止和清除CommunicationObject，然后发出新连接以继续接收通知。
我有明确的访问权限来配置客户端和服务器WCF端点。 我的困境是我是否应该：
一个。将sendTimeout和receiveTimeout配置属性设置为infinite，以尽可能长时间保持连接打开，同时仍处理异常以重新打开连接。
或者
B中。保持sendTimeout和receiveTimeout更短的时间跨度，例如1小时。客户端或服务器将收到超时，清理，然后建立新连接。
使用一个优于另一个是否有优势，或者WCF不是解决我问题的可行解决方案？
我的目标是尽可能保持最高的可用性。
编辑：
我担心超时的原因是服务器意外关闭或超时连接，而客户端未通过Faulted和Closing事件收到任何通知，但我可以确认客户端和服务器都使用sendTimeout和receiveTimeout的无限超时。这通常发生在24小时的时间范围内。
研究WCF Duplex model的MSDN文档我读了以下语句：
双工模型不会自动检测服务或服务的时间 客户端关闭其频道。因此，如果客户端意外终止，请通过 默认情况下，不会通知服务，或者客户端意外通知 终止后，服务将不会被通知。客户和服务都可以 如果他们愿意，可以实施自己的协议来通知对方。
这让我想知道是否有人有一个解决方案来实现他们自己的协议来保持会话活着，因为这是我的问题？
我是否需要简单地拥有一个发送＆＃34;心跳＆＃34;的客户端线程？定期到服务器的时间间隔？显然，我不想通过心跳向网络发送垃圾邮件，但同时要尽可能保持会话活跃。
我相信ReliableSession对这个问题没有任何实际好处。
答案 0 :(得分：0)
我认为您应该将receiveTimeout保留为infinite，就是这样。每小时都没有重建频道的好处。
您不需要将sendTimeout设置为infinite，因为这是一个超时，用于定义WCF基础结构在声明无法发送消息之前等待的时间。
PS 在我们的应用程序中，我们使用类似的技术，并且通道保持打开几周没有任何问题。