How Comet Works

Comet works by taking advantage of less commonly used features of the HTTP specification. Through the more intelligent management of longer-lived connections, and by reducing the server-side resources per connection, Comet can easily provide more simultaneous connections than a traditional web server, and faster data transit between the client and the server.

Large-scale applications must use asynchronous connection handling because traditional server architectures require the use of one thread per connection. For high-concurrency applications, Comet servers generally leverage event libraries such as libevent,^[24] epoll,^[25] and kqueue,^[26] depending on the operating system. Operating systems handle asynchronous I/O in various ways, the traditional method being select or poll. Your application can use these constructs to ask the operating system which sockets are ready to be written to or read from, to avoid ever incurring a blocking read or write.

What if the scale of your application is not large, but you want the benefits of Comet? Even a site of 50,000 visits per day with a typical connection time of three minutes averages only 92 open connections. Although you may need to raise the max thread count on your server, 92 threads is not a terrible approach for smaller but high-performance web sites.

The use of one thread per connection for high-performance Comet-based sites is problematic, so most Comet servers either significantly reduce the resource overhead per thread, or make use of microthreads or processes. For example, ErlyComet^[27] is written in Erlang, which is a virtual machine and microthreads-based functional language. Because a connection is represented by a process, and Erlang’s event-driven approach makes it easy for processes to communicate with each other via message passing, Erlang makes it very easy to scale the number of connections, even on different servers.

By contrast, PHP makes for a very poor choice as a Comet server language because of its threading model, so most PHP web applications that wish to use Comet make use of an off-board approach.^[28] To make this work, a Comet client is written in PHP that communicates with the Comet server written in another language. While programming languages for Comet servers in general do not matter (there is no shortage of attempts at PHP Comet servers), languages such as C, Erlang, and Python are better suited for creating a Comet server, and there are a number of great Comet servers written in Java as well. The term on-board is used when your web server is the same as your Comet server.

While on-board Comet provides the benefits of simplicity and often lives on the same domain, off-board Comet is much more common for larger-scale web sites, or for sites where the primary development language is not well suited to Comet performance. For example, a site such as Facebook would probably use an off-board solution for its chat application, whereas a site such as Meebo uses an on-board solution since virtually all of its site traffic uses Comet techniques.

On the client side, the common techniques include polling, long polling, forever frame (iframe), XHR streaming, and soon, WebSocket. In conjunction with these techniques for establishing a Comet connection, a number of protocols exist for sending messages between the client and the server. A toolkit such as the Dojo Toolkit, or a library such as js.io, can handle many of these complexities for you automatically, but understanding how these techniques work without a toolkit is essential to understanding how to evaluate and optimize Comet performance.