It seems like everybody and their brother’s goldfish is writing a Comet server these days. The list of implementations has grown dizzyingly long, without any clear leaders emerging. Most of these are simple long-polling servers. Many have no client-side code and instead ask developers to provide their own JavaScript. One, pi.comet, does the opposite. It supplies the JavaScript and asks developers to provide their own long-polling server. It’s a wild world that we live in.

Just as it is quite easy to write a web server and devilishly hard to write a successful Apache killer, it is trivial to make a simple long-polling server compared to the task of developing a mature and full-featured messaging server. Well, I think everyone should write a web server. It’s a good exercise. The fact that everyone else is working on a Comet server probably shouldn’t deter you from making one, either.

The recipe for getting up and running with your very own Comet server from scratch is quite simple:

• Asynchronous IO
• HTTP
• JavaScript
• Message Dispatching

Without further delay, let us head to the kitchen and start cooking.

Comet Server Ingredients

Asynchronous Network Server

Using one thread per connection, the longtime standard for web servers, is completely impractical for Comet. The performance cost of idle threads is very high, and Comet relies on keeping many idle connections open. If you have aspirations for more than a double-digit number of users, it is best to bite the asynchronous bullet right away. Twisted has been a very popular choice for asynchronous frameworks. I count no fewer than 6 Comet servers based on Twisted, and I’m sure that number will double in the next year.

HTTP

Comet servers are specialized web servers. As such, many frameworks for writing web servers are not appropriate for use with Comet. Comet requires low-level access to HTTP requests or sockets. For streaming transports, you will need to incrementally write a response. For long-polling, delay the response until there is data to send downstream. Either way, you are either going to have to parse HTTP or use a framework that exposes that level of control. Several of the leading Comet servers have their own HTTP parsing code. Alternatively, you could borrow a well-respected parser from another project.

JavaScript

Your fancy new asynchronous server won’t be of much use without a browser-side client library. Love it or hate it, JavaScript is essential for Comet. This is a web-oriented technology, and the web means JavaScript. Many of the most important advances in this niche have been archaeological — discovering how to use uncommon or undocumented browser behavior in pursuit of better Comet transports.

You will want to conceal the dirty sausage-making details of Comet and provide a nice interface for developers to use. Also, leave yourself room to support the messaging features in HTML 5 without breaking your applications.

Message Dispatching

Now that you have a server that sends messages to web browsers, you need a way to get those messages from your app to the Comet server. Perhaps your applications will be written as plugins and run inside the server process itself. However, the suggested method that will grant the most flexibility to your future app developers is to make your server a standalone process and have a dispatch protocol. Maybe you will use STOMP, the Streaming Text Oriented Messaging Protocol.

Congratulations!

You now have a Comet server. You are well on your well to joining the throng of other Comet server hopefuls. All you need now is a web site and a funny name (probably a play on words relating to astronomy). If you want to pull away from that pack, however, you’re going to need to stay for the bonus round.

Extra Credit

Reliable Messaging

You’ll find that some transports, such as streaming iframe transports, will drop messages that were put on the wire while clients are reconnecting. This is unavoidable. There is nothing the server can do to detect when a connection has silently closed. Instead, employ an acknowledgment scheme by which the server can resend any messages that the client missed. As of this writing, there are no production ready Comet servers that will preserve message ordering and guaranteed delivery in the face of intermittent connectivity or flaky streaming transports. (There is an experimental branch of Orbited that does.) To write a Comet server that really distinguishes itself, you cannot simply lose messages into the void.

Addressing

Any self-respecting Comet server should be able to run multiple applications. It isn’t unreasonable that a site would want to deploy a chat widget, a notification widget, and several other real-time data views without having to make each application aware of the others. You will need some strategy for keeping different comet applications from stepping on their neighbors’ toes. Because of the browser connection limits, simply mapping URLs to applications might not suffice. Instead, you could send every message down on the same stream. Label them with identifiers, similar to ports. The JavaScript library, then, would route these messages to the appropriate widgets.

PubSub

PubSub, short for Publish/Subscribe, is a very natural model for building a large number of applications. It is especially well suited for applications that consist of channels, resources, or locations. Write a PubSub backend that plugs into your comet server and dispatches messages to subscribers. Better yet, integrate with existing distributed PubSub clouds.

Security

There is plenty of room in the world for a Comet server with good security features. It would be great to include the option to serve encrypted messages with SSL. Additionally, you could provide authenticated channels by which the application writer can control which users can publish and subscribe to various resources. Extra super-duper bonus points will be awarded if this ties into existing authentication methods such as LDAP.

Conclusion

That is the basic recipe for most Comet servers. It should now be no surprise how many new implementations are cropping up. For dessert we saw a partial roadmap for an advanced Comet server. If you go so far as to follow that plan, please package your server for Debian and send me a note.