Google Groups

[sockjs] Re: sockjs vs socket.io ...


Serge S. Koval Apr 28, 2012 6:28 AM
Posted in group: sockjs
Well, I'm not Marek, but have some feedback :-)

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
response.

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:
http://sockjs.popcnt.org/

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.

6. I benchmarked sockjs-tornado and expect that tornadio2 will be ~20%
slower than sockjs-tornado due to more complex socket.io protocol. You
can find benchmark here:
http://mrjoes.github.com/2011/12/15/sockjs-bench.html

Only thing that SockJS is missing, in comparison to socket.io, is
events. But it is not very hard to implement them yourself.

And I know few guys who were very active in socket.io bugtracker
asking for help, but then they gave up and switched to SockJS.

As for the socket.io problems:
1. Development focus

Right now, socket.io devs are focused on the engine.io and current
socket.io version looks abandoned. However, there were 5 minor
releases in last month, which fixed some of the critical issues (like
this one - https://github.com/LearnBoost/socket.io/issues/438 which
was open for 8 months), so it might change in the future.

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
bugs.

2. Stability

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.

Serge.

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.