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 recently stated that 100 ms of latency costs Amazon 1% of every sale. 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.
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
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 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.
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. 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.
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.
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.
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.
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.
