HTML5 gets pushy

In the past there have been a number of clever approaches to get around the limitations of web technologies inability to allow servers to broadcast messages/data to clients. One of the more popular libraries for such capability has been...

Dharmesh Mistry
January 17, 2012

Share

Twitter

Facebook

LinkedIn

In the past there have been a number of clever approaches to get around the limitations of web technologies inability to allow servers to broadcast messages/data to clients. One of the more popular libraries for such capability has been Comet.

Whilst providing a solution where the standard lacked functionality, Comet is quite inefficient - both in terms of network bandwidth and performance.

Comet effectively posts a message to the server and the server replies if there is data waiting to go, if there is not the call is left waiting and if subsequently it times out the client is notified which in turn then makes another call. So it’s inefficiency is that it is constantly making calls to the server regardless of whether there is data to be sent back or not. Also it is using HTTP, so the requests are relatively large in size.

In a previous blog, I mentioned how the WebSockets API allows you to have bi-directional messaging between a browser and server. The use of WebSockets requires a Socket server to facilitate messaging using the socket protocol (which is far more efficient in terms of request size than HTTP). The most popular example of a good use of WebSockets is online chat.

The main advantage of SSE is that no additional software is required, a standard web server can be used as it only relies on the HTTP protocol. However, the main downsides therefore are that SSE is uni-directional, server to client broadcast only and, because they use the HTTP protocol, the message requests are much larger than socket calls.

SSE also allows arbitrary events which even allows messages to be sent to different domains. Care needs to be taken as this can be open to abuse, so developers should check the domain from which the event has been generated is one that they are expecting.

This is a powerful capability, and for anyone looking at "lean portal" implementations, could be a way of creating functionality like "inter-portlet communication" without requiring a portal server to facilitate the sharing of data.

They are also relatively simple to implement which again gives them an advantage over WebSockets.

SSE will be most useful to applications like stock ticker’s, live news, weather updates, sports scores and any other applications where the server needs to push data to a client. So does this mean the end of Comet? No because to provide backwards compatibility with non-HTML5 browsers, Comet could be used as a polyfill.