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.
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.
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