Some time ago we got a request on how to implement COMET with lighttpd. I responded with a idea about a mod_multiplex which would allow the let the client open a COMET-channel and give the backend the possibility to feed multiple channels at once with the client to poll for new data.

Basicly it would separate the HTTP Request-Response cycle from the underlying connection. HTTP would be used to open the connection and reopen it in case it went away, but otherwise it would be just a data-channel for your JavaScript/AJAX content we want to send to the client when WE (the content-provider) want.

Let’s quote my understanding of COMET again:

My idea on this is to decouple the request from the COMET stream.
AFAI understand COMET it is a ‘one-receiver-multiple-senders’ concept.
The channel (a HTTP-response) is kept-open while the server/app can send multiple responses even without browser interaction to the client.

This is what you see in a web-chat application or what is used to send out stock-quotes in real-time to a large group of users.

In the classic HTTP world you either have to poll every one few seconds for new data or you keep the connection open and let it stream you the data. Polling is not instant and generates load even if no data is available. Streaming binds FastCGI (or similar) backend to the connection which limits the number of parallel users.

Decoupling the Connection from the content

We want

• a persistent connection between to server and client to minimize the setup costs (keep-alive) and have immediate responses
• a way to send data from a backend to multiple connections
• to run a backend only to generate content

As this doesn’t fit into the classic model, we have to break it a bit. Classic means:

1. server reads HTTP Request
2. server forwards the request to the backend and waits for its response
3. server sends HTTP Response to the client

As soon as the backends closes its connection to the server, the server will assume that there is no more data to transfer and waits for the next client-request.

That’s what we want to change. We want to decouple the backend from the client-connection. To take it one step further we want to implement something we already know every well: a mailbox.

Queuing messages in a mailbox

If you are at home when the postman rings twice … hmm, let’s start again.

If you are at home when the postman delivers the a letter you can read it right away. He rings the bell, you say hello, take the letter, read it.

If you are working hard in the office, the postman will the deliver the letter too, just to your mailbox. Actually several companies deliver letters, packages, … all to your mailbox. You’ll pick the up when you come home.

mod_mailbox

First we need a name for the mailbox. The client opens a mailbox on the server, the server ties the client connection to this mailbox and sends all the data it gets for this mailbox right away to the client.

If the client drop the connection it either re-establishes or the server will remove the mailbox after some time.

A backend is started as usual and can send its response to multiple mailboxes and doesn’t have to care about connections being up or down. It only delivers to mailboxes (queues) managed by the mod_mailbox.

In case the backend delivered new content into a mailbox while the connection was temporary closed it will be sent as soon as the client re-opens the mailbox.

Can I use it ?

Not yet. This is a idea how to implement COMET in a nice, performing fashion. On the way to 1.5.0 it will be implemented. Meanwhile I’m looking for comments on the idea and if it matches your needs for COMET and AJAX.