I wrote Tornadio (and Tornadio2) - socket.io server implementations
for python. I also wrote sockjs-tornado - sockjs server implementation
for python. So I have knowledge of both projects.
Long story short..
I'll try to provide some information why SockJS is better choice:
1. It is actively maintained. By "actively" I mean that all tickets
are getting reviewed in matter of a day-two and you get meaningful
2. SockJS enforces certain behavior patterns for all server
implementations. Tests cover everything - from protocol to proper
error handing. So, it is easy to know if your server implementation
works according to the spec or not, which makes third-party server
implementations first-class citizens.
3. Because of the previous point, SockJS is more predictable and just
works better - tests even cover some edge cases which socket.io is not
aware of. There's test suite for client-side library as well:
4. SockJS is designed to be horizontally scalable. Have capacity
problems? Throw-in more nodes, add nodes to load balancer and you're
set. There's no need to use cookie-based sticky sessions - all
information is already in the URL.
5. SockJS really works for all browsers, even Opera, even in
cross-domain scenario. Socket.io client is more picky about where it
works. And SockJS supports streaming transports (one persistent
connection from the server instead of hammering it down with
short-living HTTP requests when using polling transports), socket.io does not.
If you'll open socket.io bugtracker, you'll see like 20+ pull requests
and 200+ open defects. That's not very good sign, even if 90% are not
Protocol and behavior patterns are poorly documented. No unit tests.
No protocol tests. No client-side library tests.
Client still does not know how to close multiplexed connections, can't
properly fallback to polling protocols if something screwed up native
websocket connection and so on.
Client has lots of places where race condition can happen, which
either kill your server (like issue #438 mentioned above, good it was
fixed) or you will lose data without knowing it. For example, for
polling transports, if client sees disconnect - it thinks that it was
intentional disconnect and will try to reconnect to get more data,
which might lead to data loss in some cases.
To sum it up: just go with SockJS, at least until Engine.io will be as
mature as SockJS.
On Sat, Apr 28, 2012 at 2:10 PM, StigFærch <stigf...@gmail.com> wrote:
>> If you (Marek) ...
> Sorry about that - it's Majek - not Marek.