SockJS – WebSocket emulation (2011)

http://www.rabbitmq.com/blog/2011/09/13/sockjs-websocket-emulation/

by harrydoukas • 14 years ago

41 13 14 years ago

mmastrac4• 14 years ago

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 large number of fallbacks is nice as well.

majke4• 14 years 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.

mmastrac4• 14 years ago

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.

mmastrac4• 14 years ago

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.

KaoruAoiShiho2• 14 years ago

Does Sockjs correctly fallback from websockets in all situations? Looking at this:

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.

majke4• 14 years ago

Shameless plug. SockJS powers:

* meteor.com

* q-music.be

* getbridge (from nowjs fame)

* realtime.co

* smarkets

* and loads of others.

hippich• 14 years ago

SockJS has ambitious goals:

  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.

majke4• 14 years ago

In retrospective I can say that some of them are much harder than originally anticipated :)

courtewing• 14 years ago

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.

Client: https://github.com/epixa/chuckt

Server (node): https://github.com/epixa/chuckt-node

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.

mememememememe• 14 years ago

There was a comment about java on browser. I think history tells us how people hate java on browser.

SockJS – WebSocket emulation (2011)

Related Stories