The forever-frame Comet technique is a true push implementation that is not based on polling, the XMLHttpRequest, or setting a dynamic script source. Instead, features of HTTP 1.1 originally intended for transfer and incremental rendering of very large documents are put to use to incrementally deliver data through an HTML iframe element.

This technique is very low-latency because it avoids HTTP and TCP/IP set-up and tear-down by reusing a single long-lived connection.

Chunked Encoding

Chunked Encoding is the feature in the HTTP 1.1 specification allowing a server to start sending a response before knowing its total length. This allows the server to break a complete response into smaller “chunks”, sending them in series. Responses are easy to identify because their header contains “Transfer-Encoding: chunked”. A specification for a message is as follows:

       Chunked-Body   = *chunk
                        last-chunk
                        trailer
                        CRLF

       chunk          = chunk-size [ chunk-extension ] CRLF
                        chunk-data CRLF
       chunk-size     = 1*HEX
       last-chunk     = 1*(”0″) [ chunk-extension ] CRLF

       chunk-extension= *( “;” chunk-ext-name [ "=" chunk-ext-val ] )
       chunk-ext-name = token
       chunk-ext-val  = token | quoted-string
       chunk-data     = chunk-size(OCTET)
       trailer        = *(entity-header CRLF)

Iframe

In typical Comet server implementations such as mod_pubsub, KnowNow, and Lightstreamer, a hidden iframe element is opened in the browser after page load, establishing a long-lived connection inside the hidden iframe. It is not supported in the current version of the Cometd client found in Dojo 1.0, but it will return in the near future. That said, it’s simply a matter of using the DOM to create a hidden iframe, and setting the source with the necessary parameters to communicate with your Comet server.

Incremental rendering and flushing

Browsers incrementally render chunked encoded documents after each chunk is rendered. Each chunk is wrapped in a script block, and executed with a function call in the Comet client library living in the parent document. Not every browser behaves well. For example, Internet Explorer requires a rendering element such as a <br /> tag, and Safari requires 1KB of data (usually sent in the form of whitespace), to force incremental rendering. The major Comet toolkits provides these workarounds automatically. In order to avoid excessive peak memory usage, the DOM nodes added to the iframe are typically removed after they are rendered.

Summary

The forever-frame technique uses HTTP 1.1 chunked encoding to establish a single, long-lived HTTP connection in a hidden iframe. Data is pushed incrementally from the server to the client over this connection, and rendered incrementally by your web browser.