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