Very cool, but as someone developing real-time, browser-based games this troubles me:
"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 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.
BTW, 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.
I 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!
I'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.
In 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).
Thanks 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.
For anyone that is coming to SockJS directly from socket.io, I've built an event system on top of SockJS that has a similar API to socket.io. It's called ChuckT, and [like SockJS] it has both a client and server-side component.
The project is still very new, so I haven't finished the tests nor documentation, but the readmes on those repos have information about installation and usage.
1. Simple browser-side and server-side APIs, as close to WebSocket API as possible.
2. Well documented scaling and load balancing techniques.
3. Transports must fully support cross-domain communication.
4. Transports must fall back gracefully in case of restrictive proxies.
5. Connection establishment should be fast.
6. No Flash on the client side, Javascript only.
7. Client-side Javascript must be reasonably well tested.
8. Additionally the server side code should be simple, in order to lower the cost of writing servers for different languages.
"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.