Introduction
AJAX, with its asynchronous updates, enabled a richer user experience on the Web. It accomplished this primarily by obscuring the latency issues that brought a “clunk-ish” feel to traditional Web applications. More recently, Comet reintroduced HTTP-based “push” communications to enable Web applications with real-time events through a medium, namely JavaScript and a variety of transports (e.g. long-polling, forever frames, XHR Streaming, etc.), that is far more accessible than “push” technologies of the late 90's, and which further lessens latency concerns felt by end-users, creating a more dramatic, and interactive Web experience. Both AJAX and Comet can attribute their respective successes to addressing various shorting comings of HTTP communications, whether that be with the introduction of asynchronous requests/responses or server initiated events, but it is the resolution of these trouble areas that have enabled the user experience of the document-driven Web to rapidly evolve.
Today, with the advances brought about by AJAX and Comet, we enjoy the rich Web experience delivered by applications such as Meboo, Gmail with GChat, Google Docs, and Mint.com, but these applications, however impressive, simply represent a tipping point in user experience and, more importantly, still demonstrate a continued lag in the resolution of HTTP's limitations. Such applications approximate the experience afforded by the desktop, but do not deliver an experience that is as equally compelling. Granted, better “eye candy”, as provided by the canvas tag or plugin-based technologies such as Adobe Flex and MS Silverlight, helps to close the gap, but even with better visual effects, latency remains the beast of burden that drags down much of the user-experience delivered over the Internet, and as a result costs the industry money.
Yes, there is something to be said about the old adage “time is money.” Amazon.com, as reported by highscalability.com in a post "Latency everywhere and it cost sales - How to crush it", recently stated that 100 ms of latency costs Amazon 1% of every sale. In the same post, Todd Hoff reported that Google VP Marissa Mayer, at the 2006 Web 2.0 Expo, stated that a half a second delay content delivery is correlated with a 20% drop in traffic at Google. Hoff also references a 2008 report by the TABB Group estimated that a 5 millisecond lag behind competing trading platforms could be as costly as $4 million in losses per millisecond. In short, users respond well to speed, as do our wallets.
Therefore, to further address latency concerns, and bridge the gap between desktop and Web applications, we must look to a new communications paradigm. Fortunately, HTML 5 WebSockets, as defined in the communications section of the HTML 5 specification, represent the next evolution of Web communications. WebSockets provide not only a standard against which Comet- and AJAX-style, or any other RIA application, can be built, but also a socket, native to the browser, that facilitates network programing from the browser with efficient bi-directional (or full-duplex) communication over a single connection, eliminating many of the connection limitations that surround Comet and AJAX. The result is the promotion of the browser and its associated applications to the same citizenship on the network as that of rich desktop applications.
HTML 5 WebSockets: A Better Mouse Trap
The HTML 5 specification introduced the WebSocket interface, which defines a full-duplex communications channel that operates over a single socket and is exposed via a JavaScript interface in HTML 5 complaint browsers. The full-duplex capabilities of Comet and AJAX, unlike WebSockets, are not native to the browser, and rely on maintaining two connections –one for up stream and one for downstream-- in order to stream data to and from the browser. With the introduction of one succinct interface (see Listing 1), we can now divorce ourselves from the mind bending hacks all to often associated with Comet and focus on the task at hand. Furthermore, by moving to a single, streaming channel of communications, we can overcome the insufficiencies of techniques such as long-polling and “forever frames”, and as a result further reduce latency.
JAVASCRIPT:
-
[Constructor(in DOMString url)]
-
interface WebSocket {
-
readonly attribute DOMString URL;
-
// ready state
-
const unsigned short CONNECTING = 0;
-
const unsigned short OPEN = 1;
-
const unsigned short CLOSED = 2;
-
readonly attribute int readyState;
-
// networking
-
attribute EventListener onopen;
-
attribute EventListener onmessage;
-
attribute EventListener onclosed;
-
void postMessage(in DOMString data);
-
void disconnect();
-
};
Utilizing the WebSocket interface couldn't be simpler. To connect to an end-point, just create a new WebSocket instance, providing the new object with a url that represents the end-point to which you wish to connect (See listing 2). Note that a ws:// and ws:// prefix indicate a WebSocket and a secure WebSocket connection, respectively. A WebSocket connection is established by upgrading from the HTTP protocol to the WebSocket protocol during the initial handshake between the client and the server. Once established, WebSocket data frames can be sent back and forth between the client and the server in full-duplex mode. The connection itself is exposed via the onmessage and postMessage methods defined by the WebSocket interface.
JAVASCRIPT:
-
var myWebSocket = new WebSocket(ws://www.websocket.org);
Before connecting to the end-point and sending a message, you can associate a series of event listeners to handle each phase of the connection life-cycle.
JAVASCRIPT:
-
myWebSocket.onopen = function(evt) { alert(“Connection open ...”); };
-
myWebSocket.onmessage = function(evt) { alert( “Received Message: ” + evt.data); };
-
myWebSocket.onclose = function(evt) { alert(“Connection closed.”); };
To send a message to the server, simply call postMessage and provide the content you wish to deliver. After sending the message, call disconnect to terminate the connection. It really couldn't be much easier.
JAVASCRIPT:
-
myWebSocket.postMessage(“Hello WebSocket! Goodbye Comet!”);
-
myWebSocket.disconnect();
One of the more unique features WebSockets provides is its ability to traverse firewalls and routers, a problem area for many Comet-enabled applications. Comet applications typically employ long-polling as a rudimentary line of defense against firewalls and proxies. The technique is effective, but is not well suited for applications that have sub 500 millisecond latency or high throughput requirements. Plugin-based technologies such as Adobe Flash, also provide some level of socket support, but have long been burdened with the very proxy and firewall traversal problems that WebSockets now resolves.
A WebSocket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, support for SSL is inherent. Note that Web sockets are not natively supported by modern browsers, however there are a few vendors that provide implementations that enable today's browsers to take advantage of this emerging technology. Two vendors are Kaazing and its Kaazing Enterprise Gateway offering, due for release in early Fall 2008, and an early stage open source initiative, the Orbited projected, which provides its own Python-based server.
In addition, the WebSocket protocol supports a diverse set of clients (e.g. JavaScript, Adobe Flex, JavaFX, Microsoft Silverlight, etc.). However, in the case of JavaScript, WebSockets cannot deliver raw binary data, because at present JavaScript does not provide support for a raw binary type. Therefore, binary data is ignored if the client is written in Javascript, which in turn limits JavaScript clients to the usage of text-based protocols. Fortunately, other client types such as Adobe Flex and Microsoft Silverlight do provide support for binary types, enabling more than text-based services to reach the browser. As an additional note, some vendors, such as Kaazing, provide libraries to support binary types in JavaScript via base 64 encoding.
Summary
Latency is the mother of interactivity, and in no place is this more apparent than on the Web. Every slip of a millisecond equates to a slower end-user experience which in turn translates into elevated risk that a user's eyes will avert elsewhere. Both AJAX and Comet attempt to obscure latency problems, and certainly address the issue of user-perceived latency. However, WebSockets removes the need to obscure such problems and introduces a solution, one that does not play tricks on the perception of our end-users, but delivers content in real-time with real results.
AJAX, Comet, HTML 5, Kaazing, Kaazing Enterprise Gateway, RIA, Web 2.0, WebSocket, WebSockets
