There has always been a need to support UI’s that constantly update themselves as new data becomes available on the server. The implementation for this falls into two general categories: either client side polling or server side push.
Comet is the term that is often used to describe current Client side polling and server side push techniques. Lets delve briefly into what the techniques are and then move to HTML 5 Server Sent Events and WebSockets. Check out Cometd for an implementation that you can try out. Cometd implements the Bayeux spec. Implementations are available in multiple languages.
Comet Techniques
Client Side Polling
Client periodically polls the server for new data and updates the UI as the data becomes available. The benefit of this is in its sheer simplicity. Downside is that for medium to high volume sites we introduce too many useless round trips to the server. From an architectural point of view if your volumes are relatively low this may be the right solution for you.
Client Side Polling – Long Polling
Slight variation from the previous ones. The client makes a call to the server for data. The server can hold onto the connection for some period of time. When data becomes available it is sent back and the connection is closed. If no data is available for a predefined time then the connection can be closed too. Once the connection is closed a new one is created and the process continues on. The obvious advantage of this is that we do not keep opening and closing too many connections from the client side.
Server Side Push
The idea here is for the server to push data updates to the client rather than the client polling the server for updates. In this data exchange pattern the client opens a connection to the server for which the server responds but the client does not close the connection. The client is in a continuous read mode on the connection. Whenever the server has data it sends it back within JavaScript <script> tags. Due to the way the browser renders incoming data, any JavaScript is executed which is how we can call our callback function in the client to render the updates.
If you want full duplex communication between client and server then two connections are required. One for the client-to-server communications and the other for the server-to-client communications. With browsers often supporting up to two connections for a server this can be a big limitation. So you need to use this approach carefully. Otherwise you can run into some interesting problems.
HTML 5
HTML 5 Server Sent Events (SSE)
SSE standardizes the Comet styles of communication between client and server. It adds a new DOM element and the following new tag to support it.
<eventsource src=”http://myserver/dosomething” onmessage=”alert(event.data)”>
There is also a programmatic way to create this.
var es = document.createElement(”eventsource”);
es.addEventListener(”message”, callbackmethod, false);
es.addEventSource(”http://myserver/dosomething” );
document.body.appendChild(es);
Once the server has data it will stream it to the call back method registered above. As per the spec the events have a reconnection time. The browsers should check with the server for data updates once the reconnection time has elapsed.
HTML 5 Web Sockets
Web Sockets allow for full-duplex communication over a single connection and the API is exposed via JavaScript. The API is quite simple as can be seen from the example below:
var myconn = new WebSocket(“ws://myserver/something”);
myconn.onopen = function(event) { }
myconn.postMessage(“my message”);
myconn.onread = function(event) { // u can read event.data) }
myconn.onclose = function(event) { }
The above is quite self explanatory. ws:// stands for web socket connection and wss:// represents the secure connection.
Web Socket implementations are not yet out there. That is especially the case with HTML 5 still not being official yet. Hopefully in the coming months we will have more widespread support for this. Remember for this to work there needs to be support on the browser as well as the web server.