Oxford Computer Consultants Ltd

Directors:
J. Boyle, K. Librowski & N. Warner

Oxford Computer Consultants Ltd,
23-38 Hythe Bridge St, Oxford
OX1 2EP

Tel. 01865 305200
Fax. 01865 793124

http://oxfordcc.co.uk/

Welcome to the OCC e-newsletter with its insight into how emerging Information Technology will impact on your business.

Our aim is to inform business managers and technical directors in clear language about topical aspects of IT. Every quarter we'll explain how businesses are using IT to gain a competitive advantage and improve their business processes.

"Real-Time" Websites

Damian Cugley

Right from its inception the web has been built on the idea that websites request information from web servers, and this has supported almost everything people have done on the web. However, we hit one of the exceptions when a project we were working on, called REACT, required a "real-time" website i.e. a website that automatically updates itself whenever new information arrives. This doesn't fit naturally into the way the web works but as REACT supports the sharing of incident data across emergency services it requires reliable, fast information.

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 web pages. It needs to do this despite firewalls and network-address translation (NAT). NAT means that all browsers at a particular site share one IP address; this means that standard methods of sending a message cannot be used because the server has no way to address a particular 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 network 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 as above, 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 (i.e.how many "Any new messages?" requests from clients it can remember). This is a far more extreme version of the so-called C10K problem.

Server Push

Some sites use a hidden IFRAME element which is effectively a hidden window. This window declares itself to the browser to be infinitely long and so the browser never stops trying to process it. The server can then issue updates to the hidden window when it wants and these contain code which refresh the main window. (This technique is 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, is commonly used for publishing blogs; as new data arrives it is added as a new item in an Atom collection to which all the clients subscribe.).

Web applications are usually implemented as code that plugs in to a web 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. The approach also made thorough 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 "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 from clients could be stored and replied to when an item was added to the 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.