from Hacker News

SockJS – WebSocket emulation (2011)

by harrydoukas on 11/24/12, 2:55 PM with 13 comments

• by mmastrac on 11/24/12, 5:28 PM

  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.

• by courtewing on 11/24/12, 8:02 PM

  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.

• by hippich on 11/24/12, 6:53 PM

  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.

• by majke on 11/24/12, 5:44 PM

  Shameless plug. SockJS powers:

  * meteor.com

  * q-music.be

  * getbridge (from nowjs fame)

  * realtime.co

  * smarkets

  * and loads of others.

• by mememememememe on 11/24/12, 10:37 PM

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