The hardcoded 5 second delay was true for early SockJS (0.1) but since 0.2 we have a more sophisticated timeout mechanism. Nowadays SockJS falls back to next protocol when:
- protocol is not available in the browser
- protocol was tried but failed (like: proxy actively rejecting requests)
- protocol timeouted before receiving first frame (ie: no error, just lack of action)
The last case is the most interesting (but also the least common) - we timeout when N x RTT ms passed (for N depending on a particular transport). This is pretty reliable, and very fast in practice.
In real world people have different uses for SockJS, but some just open a new SockJS connection on every page refresh (like: a newspaper website). This is rather extreme, but SockJS does seem to be working fine and establishing connections fast even in this circumstances.
There was a lot of discussion about SockJS vs Engine.io approach to falling back / upgrading protocols. Engine.io approach is caused by the fact that they support flash websockets, which have some weird properties (launching flash can take a while, plus flash timeouts after 3 seconds if port 843 is blocked, so you might want to have JSONP already running during that time). SockJS doesn't use flash - a simpler fallback mechanism is enough.
Flash sockets don't necessarily require port 843 to work - there are ways around that and it works quite well in the latest engine.io source. We use port 10000 in our setup and the client doesn't even attempt to connect to 843. We also use HAProxy to serve the flash policy file directly, which is extremely fast.
I don't necessarily think that the Flash transport is bad myself, but I can definitely understand why you wouldn't want to implement it.
https://speakerdeck.com/3rdeden/realtimeconf-dot-oct-dot-201...
Makes me afraid to turn on websockets. Will websockets correctly fall back if blocked, even if I don't use SSL?
One of the biggest problems with socket.io is that it doesn't fallback correctly.
Sure, there are issues - Safari (I think) used to crash when you opened inspector on a page with ws.
Some (meteor.com) just ignore all those issues by disabling native ws altogether. Performance of polling SockJS transports is enough for them now, so why bother?
If you find a real problem with SockJS in the wild - please do let us know!
I'll have to give SockJS a shot when I've got some free time to investigate. We're not tied to engine.io at all for our real-time gaming stuff, so I'm very interested in giving it a shot and seeing how it performs for us.
"If the browser supports it SockJS first tries to open a native WebSocket connection. Depending on a network and server setup it may work or fail. The failure should happen quite fast, unless the client is behind a badly misbehaving proxy - in such case it can take up to 5 seconds to timeout."
engine.io's approach of starting with the lowest common denominator, JSONP, to get communication up and running immediately seems much better to me.
Starting with the LCD connection and upgrading to something more performant also works around the below issue:
"This is one of the reasons why SockJS avoids using Flash transports - Flash connection can take at least to 3 seconds if port 843 is blocked"
There's a bunch of nice stuff in this library too. The built-in support for load-balancers is sweet. That's often something of a frustrating afterthought for library writers.
The large number of fallbacks is nice as well.