HTML 5: WebSockets

With the recent releases of Mozilla’s Firefox 4, and Microsoft’s Internet Explorer 9, and Google’s frequent updating of Chrome, current releases of the major browsers now include significant support for HTML 5, the latest iteration of the standard markup language for constructing Web pages.  One of the aims in developing HTML 5 has been to standardize HTML usage, which has developed into a sort of organic hodge-podge of various standards, features introduced by specific software packages (e.g., Web browsers), and miscellaneous hacks.  This has allowed the Web to be developed well beyond its initial conception, but is a bit messy.

One of the areas that HTML 5 attempts to address is application programming interfaces [APIs] for some basic functions.  One interface that is supported in HTML 5 is a new Web protocol called WebSockets.  The Technology Review has an overview article describing this new technology, which provides Web-based applications with a means of maintaining persistent communications between the client and the server, and to pass data back and forth as the application runs.

The original HTTP [Hyper-Text Transfer Protocol], formalized in version 1.0 in 1996, was designed around the original idea of the Web as a network of inter-linked documents.  It is a request-response protocol, and was designed to be stateless, meaning that the server did not maintain any “memory” of a client, once any outstanding request had been satisfied.   (This means that the concept of “logging in” to a Web site is, with pure HTTP, meaningless.)   This was done for a reason; a stateless server is much easier to restart, or to replace with a standby server;  stateless operation also makes the use of caching proxies much easier.  The familiar phenomenon of browser “cookies” was introduced in order to save state on the client, and pass it back to the server with the next request.

Although the cookie mechanism was an effective hack around the lack of state on the server, HTTP still required a “request – wait for response – response” pattern for all communications between the browser and the server.  This is a potential handicap for interactive application generally, and especially for applications that have timing requirements or dependencies.  What the new protocol does is to provide the ability to set up an alternate communications channel, which, once opened, stays open until closed, much like an ordinary file.  This permits data to be passed back and forth with much less processing and network overhead.

This protocol [WebSockets] allows a Web client to create a connection, keep it open as long as it wants, and both send and receive data continuously.

Some of the application providers showing early interest are financial trading sites, and gambling sites (but then, I repeat myself).

If you are interested in the technical nitty-gritty, the IETF site has a draft of the protocol specification; the W3C has a specification draft for the WebSockets API.