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

by

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:

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)

More Related Contents:

  1. WebSockets protocol vs HTTP
  2. How WebSocket server handles multiple incoming connection requests?
  3. What is the maximum length of a URL in different browsers?
  4. What requests do browsers’ “F5” and “Ctrl + F5” refreshes generate?
  5. CORS with POSTMAN
  6. Detecting the character encoding of an HTTP POST request
  7. Is a 302 redirect to relative URL valid, or invalid?
  8. ETag vs Header Expires
  9. How can I get the clients IP address from HTTP headers?
  10. What is the difference between URI, URL and URN? [duplicate]
  11. How many socket connections can a web server handle?
  12. Comparing HTTP and FTP for transferring files
  13. What are proper status codes for CORS preflight requests?
  14. REST response code for invalid data
  15. How big can a user agent string get?
  16. What rules apply to MIME boundary?
  17. How can I find out whether a server supports the Range header?
  18. REST, HTTP DELETE and parameters
  19. What is the boundary parameter in an HTTP multi-part (POST) Request?
  20. How to send NULL in HTTP query string?
  21. Semicolon as URL query separator
  22. How can I deal with HTTP GET query string length limitations and still want to be RESTful?
  23. HTTP Keep Alive and TCP keep alive
  24. How to serve http partial content with Go?
  25. What is the usefulness of PUT and DELETE HTTP request methods?
  26. HTTP 400 (bad request) for logical error, not malformed request syntax
  27. Avoid caching of the http responses
  28. Is it possible to set more than one cookie with a single Set-Cookie?
  29. HTTP Headers: Controlling Cache and History Mechanism
  30. luaSocket HTTP requests always respond with a redirect (301 or 302)

Leave a Comment