10

到目前为止，除了可以从双通道获得的即时通知之外，没有人能真正提供使用双通道而不是客户端轮询系统的任何好处。每隔一点说，如果您不需要立即通知，双重绑定提供负值 - 有人不同意这一点吗？

与调用 WCF 服务的客户端轮询相比，将 WSDualHttpBinding 与 IIS 托管服务一起使用会有多大好处，假设在后者中服务缓存了有问题的数据？

这个场景将用于通知类型的服务，当事件发生时，客户端需要由服务通知。

具体来说，与轮询相比，WSDualHttpBinding 有哪些优势？即：更少的网络流量，更快的设计，更容易维护，更多的控制？？？

据我了解，WSDualHttpBinding 的可扩展性不如客户端轮询，那么为什么要使用它呢？编辑：正如马特提供的那样，时间紧迫可能是双面绑定的原因之一。

这是我到目前为止所拥有的：

WSDualHttpBinding

adv：无需等待轮询计时器即可立即获得响应

dis: 比 WsHttpBinding 可扩展性差

dis：不太友好的防火墙

dis: 比 WSHttpBinding 慢

我将根据评论添加此内容，如果我陈述不正确，请告诉我。

感谢您的输入:-)

4

2 回答 2

9

此 SO 线程中有大量信息。基本上，轮询的缺点是您的客户端仅与上次轮询一样是最新的，因此对于时间关键信息，您需要增加轮询频率。每次轮询都会占用网络资源并在客户端上产生开销。长轮询和 WSDualHttpBinding 等解决方案是解决该问题的方法。WSDualHttpBinding 的缺点是客户端必须向服务器公开端点（这会在防火墙环境中产生问题）。BOSH/XMPP 或其他形式的长轮询是另一种选择。

于 2010-04-26T17:15:56.260 回答
5

WSDualHttpBinding 的创建是有原因的。WCF 提供对服务“回调”的支持——服务执行完成时通知客户端的方法。不幸的是，HTTP - 作为单向通道 - 不允许回调（相比之下，TCPBinding 允许它，因为 TCP 是全双工通道）。为了绕过 HTTP 的单向特性，发明了 DualHttpBinding——两个同时打开的 HTTP 连接——一个用于服务请求——一个用于回调。这不是可扩展性的问题，而是需要的问题。如果您想使用回调（并且回调非常好，特别是如果您的服务将成为一项耗时（长时间运行）的服务），WSDualHttpBinding 可能是您的最佳选择。由于已经指出的原因，轮询可能是最糟糕的——每次轮询都会占用网络资源等。

于 2011-05-21T03:53:15.637 回答