WCF中WSDualHttpBinding的优点是什么？
到目前为止，除了可以从双通道获得的即时通知之外，没有人能够真正提供在客户端轮询系统上使用双通道的任何好处。其他所有观点都说，如果您不需要立即通知，双重绑定会提供负面价值 - 有人不同意这一点吗？
假设在后者中服务缓存了相关数据，那么将 WSDualHttpBinding 与 IIS 托管服务结合使用与调用 WCF 服务的客户端轮询相比，有多少好处？
此场景适用于通知类型的服务，其中当事件发生时，服务需要通知客户端。
具体来说，WSDualHttpBinding 相对于轮询有哪些优势？ 即：更少的网络流量，更快的设计，更容易维护，更多的控制???
据我了解，WSDualHttpBinding 的可扩展性不如客户端轮询，那么为什么要使用它呢？编辑：正如马特所提供的，时间紧迫可能是双工绑定的原因之一。
这是我到目前为止所拥有的：
WSDualHttpBinding
adv：可以立即响应，无需等待轮询计时器
dis：可扩展性不如 WsHttpBinding
dis：防火墙不太友好
dis：比 WSHttpBinding 慢
我将根据评论添加此内容，请让我知道我是否表述错误。
感谢您的输入:-)
So far, no one can really offer any benefit of using dual channel over a client polling system except for the immediate notification you can get from the dual channel. Every other point says if you dont need immediate notice the dual binding provides negative value - anyone disagree with this?
How much benefit would there be to using WSDualHttpBinding with IIS hosted service vs. a client poll that calls the WCF service, assuming in the latter the service cached the data in question?
This scenerio would be for a notify type of service where the clients need to be notified by the service when an event occurs.
Specifically, what advantages would WSDualHttpBinding provide over polling?
ie: Less network traffic, faster to design, easier to maintain, more control ???
From what i understand, WSDualHttpBinding is less scalable than client polling, so why use it at all? Edit: As Matt supplied, time critical can be one reason for the duplex binding.
Here is what i have so far:
WSDualHttpBinding
adv: can get immediate response w/o waiting on polling timer
dis: less scalable than WsHttpBinding
dis: less firewall friendly
dis: slower than WSHttpBinding
I'll add to this based on comments, please let me know if i state anything incorrectly.
thanks for you input :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个SO线程。基本上，轮询的缺点是您的客户端仅与上次轮询一样最新，因此对于时间关键的信息，您需要增加轮询的频率。每次轮询都会占用网络资源并给客户端带来开销。长轮询和 WSDualHttpBinding 等解决方案是解决该问题的方法。 WSDualHttpBinding 的缺点是客户端必须向服务器公开端点（这在防火墙环境中会产生问题）。 BOSH/XMPP 或其他形式的长轮询是另一种选择。
There is a wealth of information in this SO thread. Basically, polling has the disadvantage that your client is only as up-to-date as its last poll, so for time-critical information you need to increase the frequency of polling. Each poll takes up network resources and creates overhead on the client. Solutions like long polling and WSDualHttpBinding are workarounds for that problem. WSDualHttpBinding has the disadvantage that the client must expose an endpoint to the server (which creates problems in firewalled environments). BOSH/XMPP or another form of long polling is another alternative.
创建 WSDualHttpBinding 是有原因的。 WCF 提供了对服务“回调”的支持 - 客户端上的方法，每当服务执行完成时就会收到通知。不幸的是，HTTP - 作为单向通道 - 不允许回调（相比之下，TCPBinding 允许回调，因为 TCP 是全双工通道）。
为了解决 HTTP 的单向性质，发明了 DualHttpBinding - 两个同时打开的 HTTP 连接 - 一个用于服务请求 - 另一个用于回调。
这不是可扩展性的问题，而是需求的问题。如果您想使用回调（回调非常有用，特别是当您的服务将是一项耗时（长时间运行）的服务时），WSDualHttpBinding 可能是您的最佳选择。由于已经指出的原因，轮询可能是最糟糕的 - 每个轮询都会占用网络资源等。
WSDualHttpBinding was created for a reason. WCF provided support for service 'callbacks' - methods on the client that were notified whenever service execution completed. Unfortunately, HTTP - being a one way channel - would not allow for callbacks (by contrast, the TCPBinding allows it since TCP is a full duplex channel).
To get around HTTP's one-way nature, the DualHttpBinding was invented - two simultaneously open HTTP connections - one for the service request - and one for the callback.
It is not a question of scalability - but of need. If you want to use callbacks (and callbacks are great especially if your service is going to be a time consuming (long running) service), WSDualHttpBinding may be your best option. Polling is possibly the worst for reasons already pointed out - each poll takes up network resources etc.