Options for real-time web notifications and updates using Comet/XMPP vs WebSocket technologies on a Microsoft stack?

Question

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:

• Pokein
• WebSync

WebSockets camp:

• Kaazing
• LightStreamer
• SuperWebSocket
• XSockets
• SignalR

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:

1. Ability to implement fallback technology (if HTML5/WebSockets are not available)
2. High number of concurrent connections and number of messages per second
3. Scalable - ability to add additional servers/nodes for larger traffic requirements

Stutzman

I'd be really interested to hear anyone's experiences with SignalR. Thank you. – Chargeable

ElHaix , what did you end up going with, and what would you suggest to someone asking this question today? – Jallier

Answer 1

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)

Dugaid

Answer 2

For reasons incl. those already stated above, I'd go with WebSockets.

If you go with WebSockets, you might also consider Autobahn WebSockets, a high-performance WS server that supports Windows where it runs on top of IOCP (I/O completion ports).

The latter is important if you want to scale to large connection numbers (hundred thousands).

Disclaimer: I am author of Autobahn WebSockets. The base tech is OSS. We are currently preparing a commercial offering, a real-time messaging hub provided as a virtual appliance (runs on VMware/sphere) .. completely integrated, hardened appliance. The latter also allows you to push notification via the hub using a plain old HTTP/POST .. it has a REST API that allows you to dispatch to clients connected via WS. If you are interested in private beta testing, contact me ..

Ishii

Answer 3

It seems you pick the most stable Comet implementations available. All of them look stable, capable to host ten to hundred thousands of users per node and more.

So, what could be the next? For example, PokeIn is going to host all aspects of a web application over VisualJS.NET; Video-1, Video-2

This also shows the built-in capabilities of this library and the varieties you can do..

Besides, latest version supports Base64 serialization for the messages between a client and server hence no more naked JSON messages on network packages.

UPDATE: PokeIn 2.0 has built-in WebSockets support.

Graham

Why is it that there are so many "instructional" or "demo" videos, with no narration? Adding an audio instructional track to these would be helpful! – Stutzman

Answer 4

The performance gain you get with WebSockets over traditional comet solutions is in the multiple orders of magnitude range; I'd definitely go with the WebSockets camp. Here's a traditional comet vendor's comparison of the two technologies, measuring an over 150x factor in favor of WebSockets (700ms vs. 3 ms at 50,000 users).

A few notes on Kaazing's behalf:

Kaazing is fully supported on Microsoft as a server platform. Also, as you note, Kaazing supports a variety of client libraries and technologies, including the Microsoft stack: .NET and Silverlight, used happily by many of our customers.

In addition, Kaazing offers rich business protocols on top of WebSockets, allowing you to "speak" XMPP directly in your client code.

About browser support: Kaazing provides exceptionally good WebSocket emulation, supporting all the browsers out there, including old browsers, all the way back to IE6. You can read more about it in this blog post.

Regarding maturity: the Kaazing WebSocket Gateway has been shipping since 2009, and has a large number of high profile customers in many industries, including financial, logistics, gaming, and retail; very mature platform with top notch support.

Budge

Peter, I also read another of your comments ( #9168064 ), the ability to automatically select the appropriate transport layer is important (legacy browsers), which is what I gather you are alluding to in '... allowing you to "speak" XMPP...". Some very good points. Do you know of any .Net-based server implementations to compare against? :) – Stutzman

Sorry, I'm not familiar with .NET WebSocket servers. – Budge

On XMPP: We support XMPP messaging on top of WebSockets. So instead of you developing against the fairly low-level WebSocket APIs, you can use higher level messaging protocols/APIs sitting on top of native (or in case of older browsers, emulated) WebSockets. – Budge

Peter, It is clear to me how to use lightstreamer in a fully .net environment. It is NOT at all clear how, on the server side, to integrate kaazing. – Jallier

Jonesome - Kaazing supports various different client technologies, .NET is one of them. Can you shoot me an email so I can better understand what you're looking for? peter dot moskovits at kaazing dot com – Budge

Answer 5

SignalR wins.

Now that the product has matured it's been a breeze to implement. Essentially it offers what those $everal thou$and dollar packages cost, but don't have the marketing bucks to showcase some really cool implementations.

From a technical perspective you can accomplish the same things with SignalR. If your tech guys suggest otherwise, they probably don't know how to implement SignalR in a load-balanced environment (or even on its own).

Stutzman

And you (and SignalR) don't know about websockets sub-protocols. – Mnemosyne