
SockJS – WebSocket emulation (2011) - harrydoukas
http://www.rabbitmq.com/blog/2011/09/13/sockjs-websocket-emulation/
======
mmastrac
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.

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

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

[https://speakerdeck.com/3rdeden/realtimeconf-dot-oct-
dot-201...](https://speakerdeck.com/3rdeden/realtimeconf-dot-oct-dot-2012)

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.

~~~
majke
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!

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

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

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

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

------
majke
_Shameless plug_. SockJS powers:

* meteor.com

* q-music.be

* getbridge (from nowjs fame)

* realtime.co

* smarkets

* and loads of others.

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

