Comet Ripple Effects
The Comet model for communications is a drastic departure from that found in the classical Web model in which events are client-initiated. The most obvious benefit of Comet’s model is the server’s ability to send information to the browser without prompting from a client. Comet-style communication also differs from that found in the traditional AJAX model, in which browser clients poll at regular predefined intervals for data – also known as Time to Refresh (TTR).

In most cases, polling schemes blindly check for updates irrespective of state changes in the application. The result is poor resource utilization on both the client and server, since CPU-cycles and memory are needlessly allocated to prematurely or belatedly detect updates on the server. Furthermore, high polling frequencies result in increased network traffic and server demands, while low polling frequencies result in missed updates and the delivery of stale information. So achieving a refresh rate that approximates real-time updates is difficult without flooding the network.

How Comet Works
Comet applications create long-lived HTTP connections between the client and server. These connections eliminate the need for clients to poll the server and allow servers to stream messages to clients as new data becomes available.

HTTP does not provide a scheme for a server to open a connection to a browser; therefore, the creation of a long-lived connection is client-initiated.

From the client’s perspective, the data is arriving in chunks over the lifetime of the HTTP response. The client can process each chunk as it arrives, rather than wait for the entire HTTP response to complete.

The net effect of streaming data over an open connection is a reduction in the latency between the time an event occurs and a message is delivered, enabling application state to update in real-time. In addition, the overhead of HTTP headers and opening and closing connections (as seen in polling) is greatly reduced.

Some Comet implementations provide a publish-and-subscribe programming paradigm, which allows clients to subscribe or express interest in a certain type of information – commonly known as a topic or channel.

Supported Technologies
Comet is not bound to any particular set of client technologies, but refers instead to a group of techniques that facilitate bi-directional, low-latency communication between clients and servers. However Comet, like traditional AJAX, generally implies the use of JavaScript to create and maintain connections in a browser without using proprietary browser plug-ins. But Comet is not limited to JavaScript. Java, Flex, Silverlight, .NET, Python, and Ruby are examples of just a few of the technologies that can be used to include Comet in applications outside of the native browser environment.

A variety of techniques exist for managing connections to a Comet server from a browser endpoint. Each technique has its own characteristics in terms of browser support as well as latency and throughput.

For example, some Comet clients may attempt to use plug-ins such as Flash or Java to open socket connections instead of using methods native to the browser. Other clients rely on more traditional approaches, using native JavaScript to opening connections via iFrames, ActiveX, or XmlHttpRequest (XHR) objects. Either connection scheme provides equivalent methods of streaming and/or efficiently polling for information.

Browser developers are also aware of the growing demand for real-time Comet streaming support and, as such, the upcoming proposals for HTML include the concept of Server-sent Events (SSE). SSE will allow clients and servers to standardize the protocols and APIs for making long-lived Comet connections from browser to server, which should usher in a new area of interoperability and support for real-time browser messaging.

Like Comet clients, Comet servers do not mandate the use of a specific technology. However, some technologies are better suited for handling Comet connections than others.

Performance and Scalability Considerations
Despite their promise, long-lived connections do pose a problem for server performance. For this reason, until now most Comet deployments today have been limited to small- or mid-sized audiences. In general, Comet servers maintain some state and, therefore, must store information about connected clients and the resource allocated to each connection. These additional demands for resources limit the number of concurrent connections that a server can maintain.

Long-Polling and Streaming
Some Comet vendors attempt to offset these costs by implementing efficient polling strategies such as long-polling. This method of polling, also known as Asynchronous-Polling, allows a long-lived connection to be maintained between the client and server for a set timeout interval, after which the server terminates the HTTP response and forces the client to reconnect. If the server sends a message before timeout, the server still terminates the HTTP response, once again forcing the client to reconnect to the server.

Messages are buffered at the server until the client reconnects, when they are immediately delivered in a complete HTTP response to the client. Therefore, in high message throughput environments, the long-polling technique degrades to traditional polling, with no wait on the server.

The long-polling strategy helps prevent starvation of resources on the server, but fails to deliver the minimum latency guaranteed by streaming data over a long-lived connection. In long-polling over HTTP/1.0, a single response is sent over each open connection before the connection is torn down and reopened. In HTTP/1.1 with keep-alive, the underlying HTTP persistent connection can be reused by the browser, but HTTP response headers accompany each message delivery to the browser.

Streaming data optimizes network traffic by eliminating the need to send redundant HTTP response headers. Streaming data over an open connection that is initialized only once incurs only the cost of sending response headers on the setup of the connection. Subsequent messages are sent over the connection without the response header, reducing the network bandwidth required to deliver the same messages, when compared with long-polling.

Few Comet implementations provide the scalability to enable streaming and instead rely on long-polling as a means to serve additional clients. Kaazing’s Enterprise Comet represents one of the few Comet offerings that can scale to meet the intensive requirements of streaming data.

Measuring Concurrency
When developers start implementing Comet functionality into their Web applications, there is a need to be cautious and alert about changes in user behavior and how it might impact the server architecture. Today, when developers and IT managers track concurrency the numbers are usually in the low hundreds, which is still a considerable number when addressing a short-lived request and response cycle. With a Comet solution concurrency takes on a new meaning because everyone is connected to the server for lengthy periods of time.

Developers and IT managers will have to confirm the size of their user community and research their user-base’s behavior. How large is it – 200,000 – 2,000,000 – 20,000,000 users? And what happens if these clients stay connected for 30 seconds, 90 seconds, 30 minutes, or 90 minutes?

When concurrency suddenly skyrockets with the usage of Comet, what options do we have to address this scalability issue?