我正在规划一个项目的架构选项，该项目将呈现用户活动的实时更新（如Facebook） – login，照片等。这两个主要的UI组件是自动更新的滚动区域，其中将列出新的通知等等），还有一个工具栏，可以更新更新的消息数量等。
这个竞争者是基于Jabber / Comet / XMPP和WebSocket技术。
彗星营：
WebSockets阵营：
（不能张贴两个链接）
既然这样，现有的基础架构就是微软的堆栈，我宁愿不把基于Java的服务器引入混合。 说这个，它离开（一个非常有吸引力的）WebSync（Comet）和SuperWebSocket（WebSockets）。 然而，Pokein的DLL集成与.Net项目相当无缝。
有没有更多的真正的生产级WebSocket的.Net的举措？ 在微软的系统上采用WebSocket还为时过早，我是否应该赞成像Kazing这样的东西？
我仍在等待有关我们当前用户群的浏览器types和版本（检查HTML5兼容性）的报告。 我怀疑这个数字会很低（较老的用户群）。 如果是这样的话，彗星选项将是胜利者。
还有什么其他的事情要考虑？
我可以从任何使用上述技术和产品的人那里得到一些评论吗？
谢谢。
我有偏见（我为冷冻山工作），但你应该检查出WebSync。
WebSync v4除了根据需要回退到长轮询/callback轮询之外，还使用WebSocket。 WebSync中的WebSockets也都是标准的HTTP端口，所以路由器/ filrewalls /等不会有任何问题。
在一个“正常”的系统上，你应该看到〜20k并发（每个节点）和〜100k消息/秒。 这些都是非常粗糙的数字，因为它取决于你的系统和你发送的消息types等。我们已经看到高达5万用户（每个节点）和（在不同的testing中）每秒30万条消息。
来自其他使用过它的人的一些评论：
https://stackoverflow.com/a/8525454/25330
https://stackoverflow.com/questions/2604193/websync-pros-and-cons
从我的研究中，使用IISNode查看带有SocketIO的Node.JS可能是一个不错的select。 不过，有很多关于SignalR的Node.JS已经提到，并进一步深入研究，SignalR与.Net的集成是完全无缝的。