通过 WCF 双工通道长期运行的回调合同 - 替代设计模式？

Posted 2023-04-18

【中文标题】通过 WCF 双工通道长期运行的回调合同 - 替代设计模式？

【英文标题】：Long-running callback contract via WCF duplex channel - alternative design patterns?

【发布时间】：2010-10-10 15:48:33

【问题描述】：

我有一个 Windows 服务，可以将雷达枪的速度读数记录到数据库中。此外，我将该服务设为 WCF 服务器。我有一个订阅服务的 Forms 和一个 CF 客户端，只要有满足特定条件的读数就会被回调。

这在原则上有效，但一段时间后频道超时。似乎长时间运行的连接存在一些基本问题（请参阅 http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx) 和双工 HTTP 回调可能不是正确的解决方案。还有其他方法可以使用 WCF 实现发布/订阅模式吗？

编辑：即使有 2 小时的超时，频道最终也会受到影响。我收到此错误：

“SignalSpeedData”操作无法完成，因为会话通道在等待接收消息时超时。要增加超时，请在配置文件中的绑定上设置 receiveTimeout 属性，或直接在 Binding 上设置 ReceiveTimeout 属性。

这发生在最后一次成功通话后 15 分钟。我想知道是否可以为每次通话重新建立一个新的会话，而不是保持会话打开。

【参考方案1】：

可靠的消息传递将满足您的需求。如果出现问题，通道会自行重新建立。 WSDualHTTPBinding 为 http 绑定提供了这个，还有一个 tcp 绑定允许这个。如果您在同一台计算机上，命名管道绑定将默认提供此功能。

【讨论】：

如果您的意思是可靠会话 - 我已经在使用它，我将不活动超时设置为 2 小时。

因此，RS“应该”在您的不活动超时后发送基础设施消息。可悲的是，它不在最新版本的框架中。如果您每 20 分钟左右发送一个“心跳”消息，它应该可以解决问题。我明天还需要查看另一个设置。

亲爱的史蒂夫，cdonner， 实际的解决方案是什么？心跳消息对我来说看起来不太好，我更喜欢一些配置参数。

我同意亚历山大的观点。问题的最终解决方案是什么？谢谢！

除了增加receiveTimeout之外还有什么解决办法吗？当用户机器从睡眠中出来并使用昨天运行的应用程序实例时，我们会遇到这个问题。