Jeffrey Greenberg on Technology Strategy

The Problem: Web apps often require immediate communications between users mediated by the website, rather than directly connecting users to each other. That website communication via HTTP requires the browser to poll the servers, servers cannot push data to browsers. An example is a chat application: one user wants to send a message to another, so their browser app sends it to the server, but the recipient doesn’t know that there’s a message there on the server to be picked up. The server can’t push it to the recipient’s browser. So the problem is how can the recipient recieve messages quickly and reliably?

The solution is a set of hacks that are collectively known as ‘Comet”. Comet actually a combination of techniques intended to work portably across browses as efficiently as possible, and to work efficiently on the server-side as well. It’s basically, a bunch of ways to do efficient polling. And the reality of it is that at this time there are a bunch of technical challenges to implementing them.

On the Server Side:
The assumption of most http (web) servers is that a browser connection is quick. Most web implementations use interpreted languages which take up alot of memory (ram). So with quick connections of bloated memory, you don’t use up much memory. But if a connection is to be long-lived, then web server will have many more bloated interpreted apps to run at once and will run out of memory sooner. So you get a scaling problem.

You either need smaller apps that take less memory (so you’d have to forget about the entire “P” in the LAMP stack, or you need a server that can run a more efficient server to handle push efficiently.

There is a class of servers out there know as CometD for such long-lived connections. The state of Cometd servers is experimental at best. They are basically bodies of server code which you have to hack. There are no standards, most don’t have plug-ins or any clean way to isolate your code except through coding discipline… There’s no mod_cometd for instance for apache etc. So you’ve got to hack your own. It’s not rocket science, but it’s certainly neither enterprise quality or highest-level maturity, open source quality. It’s the first round of sketches… You have fill in here and there, but you can get the general ideal working.

CometD really only specs a transmission protocol known as Bayeux. There’s no server or client standard, only the protocol. The Bayeux protocol describes the transmission of data in a publish/subscribe model. There is no further control or information for the server to something other than broadcast messages from a publisher to a multiplicity of subscribers. Great!, but say you don’t want just anyone to subscribe to your channel… well the protocol isn’t going to help you directly. So a basic CometD server that supports Bayeux does nothing other than route messages, anything else you’re going to have to provide through modifications to the server. And as I noted there’s no standard here, not nice plugin to modify the server… You have to start hacking. So be it.

So:
- no security: there’s currently no means to prevent anyone from subscribing or publishing… You have to hack that in yourself.
- no connection to your App or DB: you have roll your own. There’s no pre-built mechanism like a callback that you can hook into on certain server events. You have to read the server code and roll your own system These shortcoming are being addressed more or less in open-source and in commercial server implementations. Less for now.

Check these out as they’re the best way to get push done:

• http://meteorserver.org/
• http://cometdproject.dojotoolkit.org/documentation/cometd
• http://www.lighttpd.net/
• Erlang *

* From Facebook Engineering blog: For Facebook Chat, we rolled our own … epoll-driven web server (in Erlang) that holds online users’ conversations in-memory and serves the long-polled HTTP requests. … Why Erlang? In short, because the problem domain fits Erlang like a glove. Erlang is a functional concurrency-oriented language with extremely low-weight user-space “processes”, share-nothing message-passing semantics, built-in distribution, and a “crash and recover” philosophy proven by two decades of deployment on large soft-realtime production systems.

On the Client side, there are Comet libraries that implement the Bayeux protocol to CometD servers, but given the state of the protocol, you’re only getting a starting point for significant elaboration. Dojo supplies one of them, authored by Alex Russell, who coined the term “Comet” and who is one very smart and able technologist.