Orbited
SitePen Support

Comet vs. BOSH?

by Alessandro AlinoneFebruary 21st, 2008

BOSH (Bidirectional-streams Over Synchronous HTTP) is an XMPP/Jabber extension proposal.

It has already been mentioned several times on Comet Daily. For example:

While re-reading the BOSH specification, I was a bit surprised to see that the authors define BOSH in explicit opposition to Comet, even though BOSH seems to be based on the Comet paradigm…

For example, in the Introduction:

BOSH achieves this efficiency and low-latency by avoiding polling without resorting to chunked HTTP responses (i.e. without using the technique which is now commonly known as “Comet”).

Then, in the Requirements (note the sentence I’ve put in bold):

The following design requirements reflect the need to offer performance as close as possible to a standard TCP connection.
1. Compatible with constrained runtime environments** (e.g., mobile and browser-based clients).
2. Enable browser-based clients to make bidirectional cross-domain connections.*
3. Compatible with proxies that buffer partial HTTP responses.*
4. Efficient through proxies that limit the duration of HTTP responses.*
5. Fully-compatible with HTTP/1.0.*
6. Compatible with restricted network connections (e.g., firewalls, proxies, and gateways).
7. Fault tolerant (e.g., session recovers after an underlying TCP connection breaks at any stage during an HTTP request).
8. Extensible.
9. Consume significantly less bandwidth than polling-based protocols.
10. Significantly more responsive (lower latency) than polling-based protocols.
11. Support for polling (for clients that are limited to a single HTTP connection at a time).
12. In-order delivery of data.
13. Guard against unauthorized users interjecting HTTP requests into a session.
14. Protect against denial of service attacks.
15. Multiplexing of data streams

*Not possible to fulfill these requirements with the Comet technique.

Finally, in “The BOSH technique” section:

Each block of data pushed by the connection manager is a complete HTTP response. So, unlike the Comet technique, the BOSH technique works through intermediate proxies that buffer partial HTTP responses. It is also fully compliant with HTTP/1.0 - which does not provide for chunked transfer encoding. Also unlike Comet, Web clients can use BOSH to make cross-domain connections.

This misunderstanding seems to derive from the fact that by “Comet” the authors only mean the “forever-frame technique”. In reality, BOSH is based on long polling, which has been part of Comet since the very beginning. In fact, from “The BOSH technique” section:

The technique employed by this protocol achieves both low latency and low bandwidth consumption by encouraging the connection manager not to respond to a request until it actually has data to send to the client. As soon as the client receives a response from the connection manager it sends another request, thereby ensuring that the connection manager is (almost) always holding a request that it can use to “push” data to the client.

So, BOSH is a very interesting specification, but it is not that new from a paradigmatic point of view, and certainly not opposed to Comet.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]
Comet Support by SitePen

Leave a Reply



Copyright 2014 Comet Daily, LLC. All Rights Reserved