What specific use cases call for BOSH over WebSockets and long-polling? [closed]

Question

BOSH is...

a transport protocol that emulates the semantics of a long-lived, bidirectional TCP connection between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of frequent polling or chunked responses.

This sounds like WebSockets and HTTP long-polling except that it uses two open HTTP connections instead of one and doesn't extend the HTTP protocol.

What are the differences between the two protocols, and what use case would prefer WebSockets over BOSH?

Ampulla

Answer 1

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)

Wellfed

I just added an update with the current browser support status. – Wellfed

It's worth mentioning that Safari does not support WebSockets as specified in the RFC. – Eskilstuna

Julian, done. I noted current Opera and Android status (non-status) too. – Wellfed

The latency comparison is not comparing like-to-like. The equivalent for WebSockets (WS) of not having "ideal conditions where HTTP/1.1 is supported all the way through all intermediaries and by the target server" is "WS are not supported all the way through", in which case you simply have no WS connection. Eg, until very recently, nginx had no WS support. So the re-establish cases, with HTTP/1.0, would more fairly be described as "BOSH can keep working when WS would be absent, but performance will suck and diagnosis is less clean than 'not up'". WebSockets wins, for the other points. – Impudence

Phil, in ideal conditions for both, WebSockets will always have lower client-to-server (and therefore round-trip latency). In non-ideal situations the latencies would be approximately the same because the WebSocket app would need fall back to standard long-poll/HTTP streaming (i.e. the way Socket.IO does it). I will update to clarify. – Wellfed

@kanaka, What's the difference between BOSH and normal Ajax longpolling goo.gl/6dF02Q , goo.gl/NpThRd ? Aren't they actually doing the same thing? – Samson

@Samson Yes, you can think of BOSH as a standardization of the HTTP long-poll technique: xmpp.org/extensions/xep-0124.html#technique But it also specifies: an XML based message format, session handling, etc. – Wellfed

I think its one TCP connection but two data streams in BOSH,. – Evora