我研究了如何在 ASP.NET / MVC 上实现像彗星一样的聊天。
我发现它可以通过长轮询来完成..
关于长轮询，因为它使线程保持打开状态，因此会产生许多并发连接，从而使其性能较差（或为零），因为IIS不适用于许多并发连接
现在商业工具：Pokein、SignalR、SocketIO、Now.Js（跳过付费工具，免费很漂亮:)）
据我所知，所有这些都使用长轮询，那么它们实际上是如何提高 IIS 的性能的（所有这些都可以与 asp.net 一起使用）。
我还发现 Facebook 使用 Erlang（不知道如何使用它）来制作它发生了&当然是价值 1 亿美元的硬件（平衡 7000 万用户）。 FB 使用长轮询而不是某些彗星服务器（就我的研究而言）。
我想在 asp.net MVC 3 上实现可扩展的长轮询
我发现的两个决赛是 此处和这里
我想知道哪个更好以及为什么..
以及给定工具中哪个工具最好
I did my research on how to implement comet like chat on asp.net / MVC.
what i found was it can be done by Long Polling..
about long polling , because it keeps the threads open so many concurrent connections will be made making its porformance poor (or flat zero), cuz IIS aint meant for many concurrent connections
Now the Tools For Business :Pokein, SignalR, SocketIO, Now.Js (Skipping paid tools, Free is pretty :) )
as far as i know all these use long polling ,then what do they actually du to improve performance in IIS (All these can be used with asp.net)..
I also found Facebook uses Erlang (Dunno how to use it) to make it happen & ofcourse $100 million worth of hardware(balancing 70 million user). and FB uses long polling not some comet server( as far as my research goes).
I want to implement scalable long polling on asp.net MVC 3
the two finalsit i found are Here and here
All i want to know which is better and why..
and also which tool is best among the given ones
发布评论
评论（2）
我的意见是 SignalR 将是更好的选择，不仅因为如果您使用 SignalR.WebSockets，如果用户的浏览器支持，它将自动升级到 Web 套接字的连接。这样，随着时间的推移，随着用户开始升级浏览器并远离长轮询方案，聊天应用程序的可扩展性实际上会变得更好。
此外，还有一个名为 JabbR 的很棒的代码示例，由创建 SignalR 的人创建。 （他们也恰好是 ASP .NET 团队的开发人员）
http://jabbr.net/< /a> - SignalR 的实际应用示例。
https://github.com/davidfowl/JabbR - JabbR 源。
My opinion would be that SignalR would be the better choice, if not only because if you use SignalR.WebSockets, it will automatically upgrade the connection to web sockets if the user's browser supports it. This way, over time, as users begin to upgrade the browsers and away from the long-polling scheme, the scalability of your chat application will actually get better.
Moreover, there is an awesome code example called JabbR, created by the very people that created SignalR. (who also happen to be developers on the ASP .NET team)
http://jabbr.net/ - an example of SignalR in action.
https://github.com/davidfowl/JabbR - JabbR source.
尽管您标记了答案，但我很想给出这个答案，因为我已经经历过这个问题很长时间了。
我使用了两个COMET大玩家的解决方案。一个是 websync，另一个是 PokeIn。网络同步很好但很贵。在成功使用 PokeIn 方面，我遇到了很多问题。实际上，我没有将其用于聊天服务器，而是用于推送实时更新，其中某些外部程序将更新发送/推送到订阅的客户端。
我建议您尝试使用基于 IHttpAsyncHandler 的逻辑。这又是一种长轮询技术，但客户端在发送请求后返回，服务器可以异步发送响应。
抱歉自我宣传。我在 codeplex 中名为 Flycomet 的项目中有一个示例实现。它只有一个处理程序，用于接收请求并根据请求的类型进行响应（如果有）。
目前，该实现不是作为聊天服务器给出，而是作为 Windows 控制台推送客户端应用程序给出，并且订阅者可以来自 asp .net 或 MVC 或 silverlight。优点是您可以调整代码以适应自己的规模。
如果您想将其修改为聊天应用程序，则通过 jQuery 推送数据非常容易。
Though your marked the answer, I am tempted to give this answer as I'd been through this and for long time as well.
I have used the solutions from two big COMET players. One is websync and the other is PokeIn. Web sync was good but expensive. I had lots of problems with PokeIn in terms of successfully using it. I actually did not use this for Chat server but for a push live update where some external program sends/pushes the updates to the subscribed clients.
I suggest you try using IHttpAsyncHandler based logic. This is again a long-polling sort of technique, but the client returns after sending the request and the server can send the response asynchronously.
Sorry for the self-publicity. I have a sample implementation of this in a project named flycomet in codeplex. This simply has a handler which receives requests and based on the type of request responds with the replies if any.
Currently the implementation is not given as a chat server but as a Windows Console Push Client Application and the subscribers can be from asp .net or MVC or silverlight. The advantage is you can tune the code to scale for yourself.
If you want to modify this as a chat application, it is quite easy to push the data through jQuery.