Silverlight 中的 PollingDuplexHttpBinding
我知道轮询在获取实时更新方面不可避免地会出现延迟。目前，我正在使用来自 freeze mountain dot com 的 websync 来实现此目的，并且效果非常好。但我仍然想知道 PollingDuplexHttpBinding 是否值得。
- 有人在关键系统中使用过这个吗？
- 它的性能比彗星更好吗？当我说性能时，它可以处理多少个并发客户端连接？
- 是否可以配置轮询的时间间隔？我的意思是每 30 秒、60 秒等一次，
I understand that polling will inevitably have delays in getting real time updates. Currently I am using websync from frozen mountain dot com for achieving this and it works very well. But I would like to still know if PollingDuplexHttpBinding is a worthwhile one.
- Has some one used this in critical systems?
- Is its performance better over comet? When I say performance, how many simultaneous client connections it can handle?
- Is it possible to configure the time interval of polling? I mean once in 30 seconds, 60 seconds etc.,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们目前正在将其用于 Alanta 网络会议平台。我们的默认绑定是 Net.TCP，因为它更快且性能更高。但并不是每个人都让 Net.TCP 通过正确的端口，因此如果我们无法通过 Net.TCP 连接，我们就会回退到 PollingDuplexHttpBinding。而且它似乎运行得相当不错——至少到目前为止没有出现重大投诉。
在性能方面，PollingDuplex 绑定与您在其他基于长轮询的系统中发现的绑定大致相似。您可以在 Tomek 的博客上找到有关其性能的更多详细信息。
是的，几乎可以配置绑定的每个方面。控制轮询间隔的特定属性是 ClientPollTimeout 和 ServerPollTimeout。请参阅此处 了解更多详情。
We're currently using this for our Alanta web conferencing platform. Our default binding is Net.TCP, because it's faster and more performant. But not everyone lets Net.TCP through on the right ports, so if we can't connect over Net.TCP, we fallback to the PollingDuplexHttpBinding. And it seems to work reasonably well -- no major complaints so far at least.
With respect to performance, the PollingDuplex binding is roughly similar to what you'll find in other long-poll based systems. You can find more details on its performance on Tomek's blog.
And yes, it's possible to configure almost every aspect of the binding. The particular properties that control the polling interval are ClientPollTimeout and ServerPollTimeout. See here for more details.