Engine.io or SockJS, which one to choose?

Question

I have run into trouble with Socket.io regarding memory leaks and scaling issues lately. My decision to use Socket.io was made over a year ago when it was undoubtedly the best library to use.

Now that Socket.io causes much trouble, I spent time looking for alternatives that became available in the meantime and think that both Engine.io and SockJS are generally well suited for me. However, in my opinion both have some disadvantages and I am not sure which one to choose.

Engine.io is basically the perfect lightweight version of Socket.io that does not contain all the features I do not require anyway. I have already written my own reconnection and heartbeat logic for Socket.io, because I was not satisfied with the default logics and I never intended to use rooms or other features that Socket.io offers.

But - in my opinion - the major disadvantage of Engine.io is the way connections are established. Clients start with slower jsonp-polling and are upgraded if they support better transports. The fact that the clients which support websockets natively (number increasing steadily) have a disadvantage in the form of a longer and unstable connection procedure over those clients which use outdated browsers, contradicts my sense of how it should be handled.

SockJS on the other hand handles the connections exactly as I would like to. From what I have read it seems to be pretty stable while Engine.io has some issues at this time.

My app is running behind an Nginx router on a single domain, therefore I do not need the cross-domain functionality SockJS offers. Because of providing this functionality, however, SockJS does not expose the cookie data of the client at all. So far I had a 2-factor authorization with Socket.io via cookie AND query string token and this would not be possible with SockJS (with Engine.io it would).

I have read pretty much all what is avilable about and pros and cons of both, but it seems there is not much being discussed or published so far, espacially about Engine.io (there are only 8 questions tagged with engine.io here).

• Which of the 2 libraries do you prefer and for which reason? Do you use them in production?

• Which one will likely be maintained more actively and could have a major advantage over the other in the future?

Answer 1

Have you looked at Primus? It offers the cookie requirements you mention, it supports all of the major 'real-time'/websocket libraries available and is a pretty active project. To me it also sounds like vendor lock-in could be a concern for you and Primus would address that.

The fact that it uses a plugin system should also a) make it easier for you to extend if needed and b) may actually have a community plugin that already does what you need.

Which of the 2 libraries do you prefer and for which reason? Do you use them in production?

I have only used SockJS via the Vert.x API and it was for an internal project that I would consider 'production', but not a production facing consumer app. That said, it performed very well.

Which one will likely be maintained more actively and could have a major advantage over the other in the future?

Just looking over the commit history of Engine.io and SockJS, and the fact that Auttomatic is supporting Engine.io makes me inclined to think that it will be more stable, for a longer period of time, but of course that's debatable. Looking at the issues for Engine.io and SockJS is another good place to evaluate, but since they're both split over multiple repos it should be taken with a grain of salt. I'm not sure where/how Automattic is using Engine/Socket.io, but if it's in WordPress.com or one of their plugins, it has substantial production-at-scale battle testing.

edit: change answer to reflect cookie support confirmed by Primus author in comments below

Answer 2

I'd like to redirect you to this (quite detailed) discussion thread about SockJS and Engine.io

https://groups.google.com/forum/#!topic/sockjs/WSIdcY14ciI

Basically,

SockJS detects working transports before marking the connection as open. Engine.io will immediately open the connection and upgrade it later.

flash, one of the Engine.io fallbacks (and not present in SockJS) loads slowly and in environments behind proxies takes 3 seconds to timeout.

SockJS doesn't use flash and therefore doesn't need to work around this issue.

SockJS does the upgrade on start. After that you have a consistent experience. You send what you send, you receive what you receive.

Also, as far as I can tell, engine.io-client (the client-side) library for engine.io, does not support requirejs builds, so that's another negative point. (SockJS does build perfectly).

Answer 3

You may also consider node-walve. Complete WebSocket basic. Extremely performant as fully stream based.

Example of how to use:

walve.createServer(function(wsocket) {
  wsocket.on('incoming', function(incoming) {
    incoming.pipe(process.stdout, { end: false });
  });
}).listen(server);

It may not be the best choice if you feel not secure in the nodejs environment (e.g. extending prototypes for API sugar), contributing to the project (though the code is more readable as socket.io).