【问题标题】:WCF best practice for client/server with notifications带有通知的客户端/服务器的 WCF 最佳实践
【发布时间】:2012-04-04 19:18:44
【问题描述】:

首先:对于我将要描述的问题,我们已经找到了可行的解决方案,但感觉不对。

我们有一个应用程序,其中包含一台应用程序服务器和大约 30 到 100 个客户端。扩展服务器不是问题。最重要的是从服务器到客户端的通知,当然也有从客户端调用到服务器的服务方法。

我们现在要做的是创建一个带有回调通道的服务合约,在服务中注册客户端(即服务包含活动回调通道列表)并通过这些回调通道发送通知。

我们需要解决的问题是:

  1. 连接超时 - 服务现在包含一些 KeepAlive 方法,客户端大约每分钟 ping 一次
  2. 服务器或网络故障后重新连接客户端 - 这是我关心的重点。目前我们有一个长时间运行的客户端对象(服务引用,继承自DuplexClientBase)来调用服务和回调对象来处理收到的通知。在client.Faulted 上,我们尝试用新创建的客户端替换客户端和回调对象,直到可以再次访问服务器。这种方法涉及到一些奇怪的异常处理......

问题: 在每个客户端上启动一个 WCF 服务并在服务器上注册每个客户端的端点会更好吗?对于上述两个问题,有没有更好的解决方案?

编辑:重点是:我错过了什么吗? - 我相信所描述的架构应该很常见,我正在寻找“默认”,最好的方法。这种设置没有一些示例吗?

【问题讨论】:

    标签: wcf architecture client-server wcf-client


    【解决方案1】:

    如果您的问题与可用性有关(在这种情况下是服务-> 消费者和消费者-> 服务的可用性),那么也许您应该考虑使用一些更容错的传输,例如 MSMQ(可能使用 netMsmqBinding)。

    您可以将复杂的 WCF 回调基础结构替换为简单、持久的订阅存储。

    当您需要发送“回调”时,只需从订阅商店中检索消费者列表并向每个消费者发送消息即可。

    连接永远不会超时,因为您不会有状态连接。

    在网络故障后从消费者重新连接到服务的问题也得到了解决 - 事实上,小型网络中断甚至不会被注意到。

    很抱歉,这并不能直接回答您的原始问题,并且感谢您对这种规模的返工可能不在您的要求范围内。

    【讨论】:

      猜你喜欢
      • 2020-11-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-08-15
      • 2012-05-24
      • 2012-02-25
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多