Real-time Websites

Real-Time Web: Long Polling

The real-time web requires two things: communication between servers, and a way for web servers to push notifications to JavaScript code running in web pages, despite firewalls and network-address translation (NAT). NAT means that all browsers at a particular site share one IP address; this means that the usual methods of sending a message cannot be used because the server has no way to address the browser. Firewalls may further limit which protocols browsers can use. How can we get around this?

How to be Pushy

There are three main ways to allow servers to update clients in browsers: polling, long polling, and server push.

Polling

Polling means the client keeps asking the server for new events:

C: Any new messages?
S: None
C: Any new messages?
S: None
C: Any new messages?
S: Here's one message: ...
C: Any new messages?
S: None

The frequency of polling controls how responsive the display is: if you poll every five seconds, events will take up to five seconds to update the user's screen. The problem is that the higher the frequency, the more bandwidth is used and the higher the load on the server.

Long Polling

Long polling is a slightly odd technique where the client makes a poll request, but the server stores the request and does not respond to it until an event is ready to be returned. It goes a little like this:

C: Any new messages?
... time passes ...
S: Here's one message: ...
C: Any new messages?
... time passes ...

The network bandwidth used is much less, because there is little traffic until it is time to update the client. You need a special web server that allows your application to store requests like this. The limit now is the number of simultaneous connections the server can support: a far more extreme version of the so-called C10K problem. Most servers reserve a thread per active request, and on some systems threads are a relatively expensive resource. Newer servers like nginx, Twisted, and Tornado use non-blocking I/O so they can handle many connections per thread. Yaws uses Erlang's lightweight processes to do the same.

Server Push

Some sites use a hidden IFRAME element combined with esoteric HTTP features like chunked transfer-encoding to allow a series of JavaScript fragments to be issued to a hidden window controlled by the main window (sometimes called Comet, as a pun on Ajax). Like long polling, it ties up a network connection for each client, and presents other difficulties.

Long Polling and REACT

For the research project REACT, OCC created an architecture for software agents to exchange messages about incidents reported to the emergency services. For inter-server messages we used the Atom Publishing Protocol (Atompub, defined in RFC 5023).

Web applications are usually implemented as code that plugs in to a server (like Apache HTTPD or Microsoft IIS), but for REACT we created a lightweight HTTP server that could be embedded in a normal application.

This innovative approach allowed console programs and desktop applications to participate in the Atompub conversation. It also made testing easier, since we did not need to have half a dozen separate web sites set up to test one component.

When we wanted to create a web page that displayed near-real-time data from the REACT system, having our own HTTP server implementation proved invaluable: it was fairly straightforward to tweak it so that active requests could be stored and retrieved when an item was added to an Atom collection, thus implementing the long poll method. Compared with setting up a specialized Comet server -- which would be overkill for this small an application -- this was a simple and efficient solution.