4 ms·
Hi, SockJS author here. The hardcoded 5 second delay was true for early SockJS (0.1) but since 0.2 we have a more sophisticated timeout mechanism. Nowadays Soc
by majke 14y ago
Hi, SockJS author here.
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.
- mmastrac 14y agoThanks for the reply! The submitter probably should have put [2011] on the link to let us know that this might not be current information. 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.
- mmastrac 14y agoBTW, just an additional note after reading through some of the mailing lists. 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.
- KaoruAoiShiho 14y agoDoes Sockjs correctly fallback from websockets in all situations? Looking at this: https://speakerdeck.com/3rdeden/realtimeconf-dot-oct-dot-2012 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.
- mmastrac 14y agoIn theory v1.0 of socket.io will fall back correctly if blocked, as it will be based on engine.io. This is what I last recall, as I've had other problems with socket.io and clustering - I've just moved on to pure engine.io going forward (and loving it).
- majke 14y agoI have problem with this presentation - it doesn't seem to contain too many details. What mobile, what browsers, what 3g networks, etc. 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!
- KaoruAoiShiho 14y agoI'm using sockjs right now with polling, so don't get me wrong, I'm with you. I'm thinking about experimenting with turning on ws so that was the source of my question. I'd appreciate it if it could be addressed. Thanks.