Publish/Subscribe WCF TCP 双工绑定配置模式
Publish/Subscribe Pattern for WCF TCP Duplex Binding Configuration
在 Publish/Subscribe 设计模式中使用 WCF TCP 绑定进行双工回调时，我遇到了 WCF 配置难题。
要求客户端使用单向回调从服务器接收通知。不知道何时会收到通知，因此目的是无限期地保持连接打开。如果客户端或服务器收到异常，则会启动清理过程以正确关闭、中止和清理 CommunicationObject，然后发出新连接以继续接收通知。
我有显式访问权限来配置客户端和服务器 WCF 端点。
我的困境是我是否应该：
一个。将 sendTimeout 和 receiveTimeout 配置属性设置为 infinite 以尽可能长时间保持连接打开，同时仍然处理异常以重新打开连接。
或者
乙。将 sendTimeout 和 receiveTimeout 保持在较短的时间跨度，例如 1 小时。超时将由客户端或服务器接收、清理，然后建立新连接。
使用其中一个是否比另一个有优势，或者 WCF 不是解决我的问题的可行解决方案？
我的目标是保持尽可能高的可用性。
编辑：
我担心超时的原因是服务器意外关闭或超时连接，而客户端没有通过 Faulted 和 Closing 事件收到任何通知，但我可以确认客户端和服务器都对 sendTimeout 和 receiveTimeout 使用无限超时。这通常发生在 24 小时时间范围内。
在 MSDN 文档中搜索 WCF Duplex model 我读到了以下声明：
The duplex model does not automatically detect when a service or
client closes its channel. So if a client unexpectedly terminates, by
default the service will not be notified, or if a client unexpectedly
terminates, the service will not be notified. Clients and services can
implement their own protocol to notify each other if they so choose.
这让我想问是否有人有解决方案来实现他们自己的协议以保持会话活动，因为这是我遇到的问题？
我是否只需要一个客户端线程定期向服务器发送 "heartbeat"？显然我不想用心跳向网络发送垃圾邮件，但同时尽可能保持会话存活。
我认为 ReliableSession 不会为这个问题提供任何实际好处。
我认为您应该将 receiveTimeout 保留为 infinite，仅此而已。每小时重新创建一个频道没有奖励。
您不需要将 sendTimeout 设置为 infinite，因为这是一个超时，它定义了 WCF 基础结构在声明无法发送消息之前等待的时间。
PS
在我们的应用程序中，我们使用了类似的技术，并且通道保持打开状态数周没有任何问题。
在 Publish/Subscribe 设计模式中使用 WCF TCP 绑定进行双工回调时，我遇到了 WCF 配置难题。
要求客户端使用单向回调从服务器接收通知。不知道何时会收到通知，因此目的是无限期地保持连接打开。如果客户端或服务器收到异常，则会启动清理过程以正确关闭、中止和清理 CommunicationObject，然后发出新连接以继续接收通知。
我有显式访问权限来配置客户端和服务器 WCF 端点。 我的困境是我是否应该：
一个。将 sendTimeout 和 receiveTimeout 配置属性设置为 infinite 以尽可能长时间保持连接打开，同时仍然处理异常以重新打开连接。
或者
乙。将 sendTimeout 和 receiveTimeout 保持在较短的时间跨度，例如 1 小时。超时将由客户端或服务器接收、清理，然后建立新连接。
使用其中一个是否比另一个有优势，或者 WCF 不是解决我的问题的可行解决方案？
我的目标是保持尽可能高的可用性。
编辑：
我担心超时的原因是服务器意外关闭或超时连接，而客户端没有通过 Faulted 和 Closing 事件收到任何通知，但我可以确认客户端和服务器都对 sendTimeout 和 receiveTimeout 使用无限超时。这通常发生在 24 小时时间范围内。
在 MSDN 文档中搜索 WCF Duplex model 我读到了以下声明：
The duplex model does not automatically detect when a service or client closes its channel. So if a client unexpectedly terminates, by default the service will not be notified, or if a client unexpectedly terminates, the service will not be notified. Clients and services can implement their own protocol to notify each other if they so choose.
这让我想问是否有人有解决方案来实现他们自己的协议以保持会话活动，因为这是我遇到的问题？
我是否只需要一个客户端线程定期向服务器发送 "heartbeat"？显然我不想用心跳向网络发送垃圾邮件，但同时尽可能保持会话存活。
我认为 ReliableSession 不会为这个问题提供任何实际好处。
我认为您应该将 receiveTimeout 保留为 infinite，仅此而已。每小时重新创建一个频道没有奖励。
您不需要将 sendTimeout 设置为 infinite，因为这是一个超时，它定义了 WCF 基础结构在声明无法发送消息之前等待的时间。
PS 在我们的应用程序中，我们使用了类似的技术，并且通道保持打开状态数周没有任何问题。