在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组件是自动更新滚动区域，新的通知
这里的竞争者是Jabber / Comet / XMPP-based
- Pokein
- WebSync
WebSockets阵营：
由于现有的基础架构是Microsoft堆栈，我宁愿不将基于Java的服务器引入混合。说这个，它离开（一个非常有吸引力的）WebSync（Comet）和SuperWebSocket（WebSockets）。然而，Pokein的DLL集成也是一个非常无缝的.NET项目。
有没有更多真正的生产级WebSocket计划的.Net？在Microsoft栈上采用WebSockets是太早了，我应该赞成类似Kazing的东西吗？
我还在等待我们当前用户群的报告浏览器类型和版本（检查HTML5兼容性）。我怀疑这个数字会低（老用户群）。如果是这样，彗星选项将是赢家。
需要考虑的其他事项？
查看一些.Net计划，如Sockets.IO和其他人，我认为这可能是太多的婴儿期，以应用于大规模生产系统。
我可以从任何人使用上面列出的任何技术和产品？
感谢。
UPDATE
我仍然在寻找一些在生产级别上可靠的好的WebSocket服务器。我最近找到它们后，向Websockets营地添加了XSockets和SignalR。 Hoewver，目前还有两个主要竞争者。这可能只是因为他们有令人惊讶的伟大的营销团队，良好的材料可用于开发人员 - API和视频。许多其他实现似乎仍然处于新生阶段，其中给出了仅与少数客户端的连接的示例。虽然这演示了该技术，但这些演示没有备份显着的有效负载/负载容量数据。 Kaazing和LightStreamer确实满足以下要求。
XSockets有一些很好的例子，但是又缺少一些真实的生产指标。
SignalR还没有在真正的生产环境中测试。横向扩展解决方案正在开发中，但并不稳定。期望看到这个项目在未来如何。
主要要求是：
- 实施备用技术的能力（如果HTML5 / WebSockets是
不可用） - 每
秒的并发连接数和消息数量较多 - 可扩展 - 为更大的
流量需求添加其他服务器/节点的能力
WebSync v4除了根据需要回退到长轮询/回调轮询之外，还使用WebSockets。 WebSync中的WebSockets也是标准的HTTP端口，所以路由器/ filrewalls / etc不会有任何问题。
在正常系统上，你应该看到〜20k并发（每个节点）和〜100k消息/秒。这些是非常粗略的数字，因为它显着取决于您的系统和您发送的消息类型等。我们已经看到高达50k的用户（每个节点）和（在一个
（免责声明：我在冷冻山工作）
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.
The contenders for this are Jabber/Comet/XMPP-based and WebSocket technologies.
Comet camp:
WebSockets camp:
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.
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?
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?
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?
Thanks.
UPDATE
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 has some nice examples, but again, missing some real production metrics.
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.
Primary requirements are:
- Ability to implement fallback technology (if HTML5/WebSockets are not available)
- High number of concurrent connections and number of messages per second
- Scalable - ability to add additional servers/nodes for larger traffic requirements
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.
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屋！
