The Evolution and Future of Real-time Browser Push

In the past months we have covered real-time client push services and seen the introduction of real-time client push technology and APIs to a number of services such as Superfeedr and DataSift. This focus on real-time push to client applications, and in particular web browser applications, is very exciting. The initial assumption would be that this movement has been triggered by an advancement in technology, and to some degree that is the case, but it might surprise you to know that the ability to push real-time updates into a web browser isn't new and has in fact been around for a number of years.

Real-time browser push technology has been around for at least 10 years mainly in the form of Comet Servers. The initial incarnation used Java Applets to allow communication between a server and a web page. The applet reliant version of the technology wasn’t widely adopted for a number of reasons; it required the Java Runtime Environment (JRE) to be installed on the client computer and Java to JavaScript communication via LiveConnect was found to be unreliable. Because of these shortfalls during the following years fat client technologies were more prominently used in real-time push applications such as Java, .NET, C and C++.

Eventually web browsers introduced technology that opened up ways for real-time browser push to be achieved without the need for browser plugins, although the methods were still considered to be “browser hacks.” The techniques such as forever-frame streaming, frame- Polling and script tag long-polling became more widely accepted but were still not massively adopted as mainstream technology solutions.

Later, other solutions to the real-time browser push problem were introduced including the htmlfile ActiveX object for Internet Explorer, XHR Multipart-replace for Firefox and XHR Streaming. These methods do not support bi-direction communication but this can be achieved by using a second HTTP connection to send commands to the server. These HTTP Streaming, or in some cases long-polling, solutions provide native web browser support for real-time browser push. The adoption of these solutions in mainstream websites was initially slow but with the introduction of the real-time web has now significantly increased.

Finally, we’ve seen the introduction of WebSockets which has massively increased the awareness that real-time client push within web browsers is possible. Websockets allow for bi-directional real-time communication between a server and a client. However, at present they do not always appear to offer the best solution due to the lack of web browser support, a specification that is still changing, some security concerns and problems that WebSockets will have with existing Internet infrastructure such as proxy servers. The current workaround suggestion for the problems that WebSockets have with proxy servers is to use a secure WebSocket connection.

The approach that many Comet Servers take when deciding which connection method to use is generally deferred to their JavaScript client Library. This decision to hide away the underlying transport mechasim powering the real-time communication is an example of where a service Endpoint isn't always directly exposed, as we covered recently when we asked "Should Cloud APIs Focus on Client Libraries More Than Endpoints?". Examples of these rich client libraries can be seen in two real-time client push services: The Kwwika JavaScript API (disclosure: author is a founder) detects the browser type and if supported will try to establish a HTTP Streaming connection for that browser type and will fallback to Flash for older browsers. Pusher's approach is to try to establish a WebSocket connection and fallback to using Flash. In both cases the intelligent client library is really required by the service due to inconsistent technology support in web browsers.

Real-time browser push technology has come a long way over the past 10 years but it still has a bit further evolve. We still need a reliable cross-browser method of establishing a connection between a server and a web browser. WebSockets promise to be the solution but until they are supported by the majority of web browsers and work more reliably with the existing Internet infrastructure we are going to continue to see other real-time communication methods used in their place, and the continued requirement for intelligent client APIs that can choose the best transport mechanism. The good news is that with increased visibility and demand for real-time browser push, and with WebSockets making their way into the heavily backed HTML5 technology stack we might not have too long to wait.

Photo via Blake Patterson

Be sure to read the next Real Time article: Twitter Indexer Topsy Adds Funding, Rejuvenates Real-time Search