轮询或不轮询（在 Web 服务上下文中）
我们可以使用轮询来查找来自某些来源的更新，例如连接到网络服务器的客户端。 WCF 以 Duplex 契约的方式提供了一个很棒的功能，在这种功能中，我可以维护与客户端的连接，并随意对该连接进行调用。 办公室里的一些人正在讨论这两种解决方案的优点，我想获得有关何时最好使用每种策略的反馈。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会使用基于事件的机制而不是轮询。 在 WCF 中，您可以通过遵循 Juval Lowy 在其网站上提供的发布-订阅框架来轻松完成此操作，IDesign.net。
I would use an event-based mechanism instead of polling. In WCF, you can do this easily by following the Publish-Subscribe framework that Juval Lowy provides at his website, IDesign.net.
部分取决于您有多少用户。
假设您有 1,000,000 个用户，您在维护这么多会话时会遇到问题。
但是，如果您的系统每秒可以响应 1000 个轮询请求，那么每个客户端可以每 1000 秒轮询一次。
Depends partly on how many users you have.
Say you have 1,000,000 users you will have problems maintaining that many sessions.
But if your system can respond to 1000 poll requests a second then each client can poll every 1000 seconds.
我认为设拉子（Shiraz）做到了这一点，但我还想说两件事。
合同。 你必须拥有所有
你的鸭子排成一排
回调通道...你必须
检查它以确保它已打开，
等等 IDesign.net 的东西是
最少数量的管道代码
你必须包括在内。
如果它对您的解决方案有意义
（这仅适用于某些
情况），MSMQ 绑定允许
客户端将数据发送到服务
以异步方式（如 Duplex），
但该服务不是“轮询”
消息...它会收到通知
一个人通过一些进入队列
地下管道。
这会迫使你转动
周围的沟通（客户变成
服务器，服务器变成客户端），但是
如果大部分的通讯
是单向的，这会提供很多
的好处。 另一个优点
这显然是排队的
通信 - 服务器可以是
下来不要错过任何消息...
当它回来时它会捡起它们
在线。
值得思考的事情。
I think Shiraz nailed this one, but I wanted to say two more things.
contracts. You have to have all of
your ducks in a row with regards to
the callback channel... you have to
check it to make sure it's open,
etc. The IDesign.net stuff would be
a minimum amount of plumbing code
you'll have to include.
If it makes sense for your solution
(this is only appropriate in certain
situations), the MSMQ binding allows
a client to send data to a service
in an async manner (like Duplex),
but the service isn't "polling" for
messages... it gets notified when
one enters the queue through some
under-the-covers plumbing.
This sort of forces you to turn the
communication around (client becomes
server, server becomes client), but
if the majority of the communication
is one-way, this would provide a lot
of benefits. The other advantage
here is obviously the queued
communication - the server can be
down and not miss any messages...
it'll pick 'em up when it comes back
online.
Something to think about.