经过几次阅读，包括…
- http://anthymecaillard.wordpress.com/2012/06/06/wcf-real-time-web-development-with-long-polling/
- WCF服务器如何通知WCF客户端有关更改?(比简单轮询更好的解决方案，例如Comet或长轮询)
…我想我已经准备好给长轮询一个机会了。
从第二个链接，我的理解是异步模式允许我们:
- 在WCF服务器上接收请求
- 调用BeginMyMethod返回一个IAsyncResult 当线程接收到IAsyncResult时，挂在某个地方请求"安全搁置"——还是被释放?-不消耗任何额外的资源
- 当发生相关业务逻辑事件时"whip the IAsyncResult back out"发生
- 使用IAsyncResult调用EndMyMethod，在此期间我们完成响应(即，将数据写回客户端)
我的假设听起来正确吗?我还认为，由于上述机制保持零线程等待事件，因此这具有很大的可伸缩性。
这是今天和。net 4.5实现WCF长轮询的最佳方式吗?
我相信我最初的印象是错误的。当WCF请求处理程序线程接收到请求并将其传递给工作线程时，我以为所有资源都被神奇地释放了。当工作线程变成现在正在等待的线程时，情况就不是这样了!当请求量变大时，这听起来并不比传统轮询更具可扩展性。
虽然像SignalR这样的框架提供了长轮询，但我认为没有任何方法可以在WCF中以不占用线程的方式本地构建它。
我遇到的一些额外的有用的链接。令人震惊的是，他们似乎从可扩展性的角度推荐传统的轮询。
- http://www.codeproject.com/Articles/186723/Push-Messages-in-RESTful-WCF-Web-Application-with
- 扩展聊天应用-短轮询vs.长轮询(AJAX, PHP)
您考虑过双工信道上的发布者-订阅者模式吗?