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.
新一篇: 2014总结及2015计划 旧一篇: 回归，准备步入正轨
当前暂无评论