The Evolution and Future of Real-time Browser Push

Phil Leggetter, February 25th, 2011

Real-timeIn 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

Both comments and pings are currently closed.

6 Responses to “The Evolution and Future of Real-time Browser Push”

February 25th, 2011
at 12:41 am
Comment by: Tweets that mention The Evolution and Future of Real-time Browser Push -- Topsy.com

[...] This post was mentioned on Twitter by programmableweb, Einar Thorsen, Josh's Tech Items, Directory Marketing , Venkat and others. Venkat said: The Evolution and Future of Real-time Browser Push http://goo.gl/fb/PwujD [...]

March 6th, 2011
at 11:26 pm
Comment by: don park

Great post. I’d like to know more about why FF4 and chrome turned off websockets

March 11th, 2011
at 1:58 am
Comment by: Phil Leggetter

@don I don’t believe that they turned off support for WebSockets in Chrome. Just Firefox 4 and Opera. You can read more about the Firefox 4 decision here:
http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/

March 17th, 2011
at 2:37 am
Comment by: Real-Time Web or Right-Time Web?

[...] That’s why these technologies have been pioneered in the financial sector and have been in that sector for over 10 years and have only recently moved into wider adoption. There is also an argument that push technology [...]

March 21st, 2011
at 1:51 pm
Comment by: Real-Time Web or Right-Time Web? | Phil Leggetter - Real-Time Web Software and Technology Evangelist

[...] matter. That’s why these technologies have been pioneered in the financial sector and have been in that sector for over 10 years and have only recently moved into wider adoption. There is also an argument that push technology [...]

July 21st, 2011
at 12:01 am
Comment by: Spend Less Time Building Real-time Apps With Pusher

[...] February we provided an introduction to real-time push technology. The ProgrammableWeb directory also lists 42 real-time APIs, mostly for accessing [...]

Follow the PW team on Twitter

ProgrammableWeb
APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.