在 Microsoft 堆栈上使用 Comet/XMPP 与 WebSocket 技术的实时 Web 通知和更新选项? [英] Options for real-time web notifications and updates using Comet/XMPP vs WebSocket technologies on a Microsoft stack?
问题描述
我正在确定一个项目的架构选项，该项目将呈现用户活动的实时更新(如 Facebook) - 登录、照片等.其中的两个主要 UI 组件是一个自动更新滚动区域，新通知将在其中显示列出(照片等)，以及一个工具栏，该工具栏将更新消息计数等内容.
I am scoping out the architectural options for a project that will render live updates (like Facebook) of user activities - logins, photos, etc. Two main UI components of this are an auto-updating scrolling area where new notifications will be listed (photos, etc.), and a toolbar that will update with things like updated message counts, etc.
这方面的竞争者是基于 Jabber/Comet/XMPP 和 WebSocket 的技术.
The contenders for this are Jabber/Comet/XMPP-based and WebSocket technologies.
彗星营:
WebSockets 阵营:
WebSockets camp:
由于现有的基础架构是 Microsoft 堆栈，因此我宁愿不将基于 Java 的服务器引入到组合中.说到这里，就留下了(非常吸引人的)WebSync(Comet)和SuperWebSocket(WebSockets).然而，Pokein 的 DLL 集成也可以无缝集成到 .Net 项目中.
Since this the existing infrastructure is a Microsoft stack, I would rather not introduce Java-based servers into the mix. Saying this, it leaves (a very attractive) WebSync (Comet), and SuperWebSocket (WebSockets). However the Pokein's DLL integration is fairly seamless into a .Net project as well.
.Net 是否有更多真正的生产级 WebSocket 计划?在 Microsoft 堆栈上采用 WebSockets 是否为时过早，我应该支持 Kazing 之类的东西吗?
Are there any more real production level WebSocket initiatives for .Net? Is it too early to adopt WebSockets on a Microsoft stack, and should I go in favor of something like Kazing?
我仍在等待有关我们当前用户群的浏览器类型和版本的报告(检查 HTML5 兼容性).我怀疑这个数字会很低(老用户群).如果是这种情况，彗星选项将是赢家.
I am still waiting for a report on our current user base's browser types and versions (checking for HTML5 compatibility). I am suspecting that this number will be low (older user base). If that is the case, the Comet option would be the winner.
还有哪些需要考虑的事项?
What are some other things to consider?
查看一些 .Net 计划，如 Sockets.IO 和其他计划，我认为这可能还处于起步阶段，无法应用于大规模生产系统.
Looking at some of the .Net initiatives like Sockets.IO and others, I'm thinking this may be too much in its infancy yet, to apply to a large scale production system.
我可以从使用过上面列出的任何技术和产品的任何人那里得到一些评论吗?
Can I get some comments from anyone that has used any of the technologies and products listed above?
谢谢.
更新
我仍在寻找一些在生产级别上可靠的优秀 WebSocket 服务器.在最近找到 XSockets 和 SignalR 之后，我将它们添加到 Websockets 阵营中.然而，此时仍有两个主要竞争者.这可能只是因为他们拥有非常出色的营销团队、可供开发人员使用的优质材料——API 和视频.许多其他实现似乎仍处于新生阶段，其中仅给出了与少数客户端连接的示例.虽然这展示了该技术，但这些演示并未使用重要的有效载荷/负载容量数据进行备份.Kaazing 和 LightStreamer 确实满足以下要求.
I am still hunting for some good WebSocket servers that are reliable on a production level. I added XSockets and SignalR to the Websockets camp after recently finding them. Hoewver, there are still two main contenders at this time. That could be just because of the fact that they have amazingly great marketing teams, good material available for developers - API's, and videos. A lot of other implementations seem to still be in new-born phases, where examples are given of connectivity with only a few clients. While this demonstrates the technology, these demos are not backed up with significant payload/load capacity data. Kaazing and LightStreamer do meet the requirements below.
XSockets 有一些不错的例子，但同样缺少一些实际的生产指标.
XSockets has some nice examples, but again, missing some real production metrics.
SignalR 似乎尚未在真正的生产环境中进行过测试.横向扩展解决方案正在开发中，但似乎还不稳定.期待看到这个项目在未来的表现.
It doesn't seem that SignalR has yet been tested in a true production environment. A scale-out solution is in development but doesn't appear stable yet. Looking forward to seeing how this project does in the future.
主要要求是:
- 能够实施回退技术(如果 HTML5/WebSockets不可用)
- 高并发连接数和每条消息数第二个
- 可扩展 - 能够为更大的规模添加额外的服务器/节点交通要求
推荐答案
WebSync v4 除了根据需要回退到长轮询/回调轮询之外，还使用 WebSocket.WebSync 中的 WebSockets 也都是标准的 HTTP 端口，所以路由器/文件墙/等不会有任何问题.
WebSync v4 uses WebSockets in addition to falling back to long-polling/callback-polling as needed. The WebSockets in WebSync are all over standard HTTP ports as well, so there won't be any issues with routers/filrewalls/etc.
在正常"系统上，您应该看到大约 20k 并发(每个节点)和大约 100k 消息/秒.不过，这些是非常的粗略数字，因为它在很大程度上取决于您的系统和您发送的消息类型等.我们已经看到高达 50k 用户(每个节点)和(在一个不同的测试)30 万条消息/秒.
On a "normal" system, you should see ~20k concurrent (per node) and ~100k messages/sec. Those are very rough numbers though, as it depends drastically on your system and the types of messages you're sending, etc. We've seen as high as 50k users (per node) and (in a different test) 300k messages/second.
(免责声明:我为冰山工作)
(Disclaimer: I work for Frozen Mountain)
这篇关于在 Microsoft 堆栈上使用 Comet/XMPP 与 WebSocket 技术的实时 Web 通知和更新选项?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
