Push technology

Since the beginning of the Web, what you see in your browser window depended on what you clicked on on or entered. It’s all been end-user driven – although the choices of what they can click on are predefined by the Web site designer. This is what they call ‘pull’ technology because the information on the screen is pulled from a Web server. But there are times when it would be useful to have push technology – particularly to mobile phones.

Push technology could keep you informed about the latest football scores and results. It could give you the latest news from international sport events. It could give you stock prices, and highlight rising or plummeting shares. It could tell you when a Web site you follow is updated. There are lots of potential reasons for organizations to want to use push technology.

You may have thought that AJAX (Asynchronous JavaScript and XML) made the Web seem a bit more responsive – but it was still client initiated. Another technique that’s sometimes used is called ‘long-polling’. A client requests information from the server, but if the server does not have anything to send when the poll is received, it holds the request open and waits for response information to become available (instead of sending an empty response). The server then sends an HTTP/S response. Of course, each HTTP request means that headers and cookie data are transferred to the server. If large amount of data are sent, this can lead to increased latency.

Another technique is called streaming, which uses a persistent HTTP connection between the server and client. The browser remains in ‘loading’ mode after the initial page load. Then, from time-to-time, the server sends small bits of JavaScript to update the page. There can be problems with browsers timing out with this technique.

What if it were possible to have a full-duplex communication channel that operates through a single socket over the Web? That’s where HTML5 WebSockets comes in – it makes it possible to have real-time, full-duplex, bidirectional, event-driven Web applications.

How it works is that during their initial handshake, the client and server upgrade from the standard HTTP protocol to the WebSockets protocol. Once established, WebSocket data frames (text and binary frames) can be sent in both directions between the client and the server in full-duplex mode. The data has a two-byte frame. Text frames start with a 0x00 byte, end with a 0xFF byte, and contain UTF-8 data in between. They also use a terminator. Binary frames use a length prefix. There is no polling involved.

Enthusiasts say that WebSockets can make your applications run faster, be more efficient, and more scalable. WebSockets started life as a feature of the HTML5 spec known as TCPConnection. Currently, WebSockets are specified in two places: the Web Sockets API is maintained by HTML5 editor Ian Hickson, while the Web Socket protocol is edited by Ian Fette.

So, if it’s so great, why isn’t it everywhere, why don’t we come across it being used all over the place? Well, it works with Firefox; it works with Chrome; it works with Safari and Opera; and it works with Internet Explorer 10 and above. And that’s pretty much the hold up. Many organizations are still running older version of Explorer – Version 8 in many cases. And figures suggest that just under a quarter of users use Internet Explorer (http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Wikimedia_.28April_2009_to_April_2013.29), so why would any company cut itself off from a quarter of its potential clients?

The very fact that there have been workarounds, shows that there is a business need for push technology. WebSockets provides a solution to the problem of how to implement push technology. The fly-in-ointment at the moment is that a popular browser (from a well-known manufacturer of games consoles) doesn’t support it. As more-and-more companies upgrade to IE10 and above, the likelihood is that we will see much more push technology in use, and WebSockets will be the way to implement it.