First let me address WebSockets readiness:
WebSockets implementation of the Hixie-76 protocol are shipped and enabled by default in Chrome, Safari and iOS (iPhone and iPad). The Hixie-76 protocol is also shipped but disabled by default in Firefox 4 and Opera 11. The web-socket-js project is a Flash shim/polyfill that adds WebSocket (Hixie-76) support to any browser with Flash.
In other words, WebSockets is available for almost every browser in the wild.
The reason why Opera and Mozilla chose to disable the protocol by default is because of a theoretical concern that there might be some broken HTTP proxies/intermediaries that could be attacked/poisoned using the Hixie versions of the protocol. The same concern applies to Flash but Mozilla and Opera felt a higher duty of responsibility for code that they ship. The HyBi versions of the protocol (the protocol was moved to the IETF HyBi working group) address the security concern.
Mozilla, Opera, Google, and Microsoft are all working on HyBi protocol implementations (although Microsoft is maintaining theirs as a separate download for now). There is a branch of web-socket-js with HyBi-07 support.
Update: As of Feb, 2013, the latest HyBi/IETF RFC 6455 spec is supported by Chrome 14, Firefox 7, IE10, Opera 12.1, Safari 6.0 and by the web-socket-js Flash shim/polyfill. On mobile devices IETF6455 is supported by Safari on iOS 6.0, Opera Mobile 12.1, Chrome 14 for Android, Firefox 7 for Android, and Blackberry 7. The original default Android browser does not have any WebSocket support.
WebSocket servers are easy to implement. There are numerous standalone and plugin implementations most of which support both Hixie-76 and HyBi protocol versions:
- libwebsockets
- Jetty
- pywebsockets
- websockify
- Socket.IO
- phpwebsocket
- Protocol::WebSocket (perl)
- em-websocket (ruby)
- node-websocket-server
BOSH vs WebSockets:
- latency: While the BOSH draft document claims very low-latency, it will be difficult for BOSH to compete with WebSockets. Unless you have ideal conditions where HTTP/1.1 is supported all the way through all intermediaries and by the target server, the BOSH client and connection manager will need to re-establish connections after every packet and every request timeout. This will significantly increase latency and latency jitter. Low jitter is often more important for real-time applications than average latency. WebSocket connections will be very similar in latency and jitter to raw TCP connections. And even under ideal conditions, the client-to-server latency of BOSH communication (and therefore round-trip) will always be higher than WebSockets: BOSH still has to abide by HTTP request-response semantics. HTTP streaming enables multiple responses per request (by splitting a "single" response into multiple parts) but not vice-versa (each client message is a new request).
- small-packet overhead: In WebSockets there are two bytes of framing overhead for small
messages. In BOSH, every message has HTTP request and response headers (easily 180+ bytes for each round-trip). In addition, each message is wrapped in XML (supposedly optional but the spec doesn't define how) with several session related attributes.
- complexity: while BOSH uses existing mechanisms in the browser, it requires a moderately complex JavaScript library to implement the BOSH semantics. Managing this in Javascript will also increase latency and jitter compared to a native/browser (or even Flash) implementation.
- traction: BOSH started life as a way to make XMPP more efficient. It grew up out of the XMPP community and from what I can tell has gotten very little traction outside of that community. The draft documents for BOSH and XMPP are split apart, but there seems to be very little real world use of BOSH without XMPP.
Update:
Just found a video where Ian Fette discusses the advantages of WebSockets over the Channel API which is similar to BOSH (at 44:00)
