Skip to Content

One of the interesting features in the developing HTML5 spec is WebSockets . WebSockets are intended to be exactly what they sound like: TCP-like sockets for use in web applications. (For a more detailed description, read WebSocket is neither Web nor Socket ).

What does a socket-like communication protocol give you that the current HTTP protocol can’t?

The answer: Full-duplex communication.

That is actually only half true. After all, plenty of web applications appear to get asynchronous notifications from the server today. This is commonly referred to as Comet (in keeping with Ajax’s household cleaner theme), real-time web, or reverse-Ajax. Some of the current methods to do this are:

High Frequency Polling – The browser makes repeated, quick HTTP requests to check if new data is available. The server responds immediately with all available data. The whole cycle repeats itself after a short delay. This method provides the illusion of data being “pushed”, but at the expense of being ‘chatty’.

Long Poll – The browser makes a long-lived HTTP request, but the server defers responding until it has data. Once data is available, the server responds and the cycle starts again. This method is not as ‘chatty’ at the previous one, but in runs into another problem. The current HTML spec only allows browsers to maintain two connections back to the server. The result is you can only have one long-poll in each browser window (unless you do your own multiplexing strategy).

Streaming – The browser makes an HTTP requests, but the server does not close the connection after responding. Instead, it leaves it open indefinitely as a pipe that it can stream data into. However, the pipe is only unidirectional. If the browser wants send data to the server it will need to break the pipe.

In contrast, WebSockets would be appear as proper full-duplex communication pipes that break the current request-response cycle inherent to all HTTP communication (however, under the covers they may still use HTTP). This seems to me to be a natural progression of the web. In considering the early “static content” days of web, the HTTP’s request-reponse cycle made sense. Of course non-browser applications at that time made heavy use TCP sockets because they give an application so much flexibility.

Since it would seem that “browsers are the new desktop”, it makes sense to bring this (decades-old) full-duplex communication protocol to the browser. However the more interesting question is what exactly will developers do with it? After all, the internet is moving more and more towards stateless, RESTful communications which would seem to be at odds with stateful socket-like communication. For one interesting opinion on this, take a look at HTML5 WebSocket and WebJneering.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Anonymous
    Thanks very much for this pointer-rich article. Personally I’m not sure where “the internet is moving” but if it’s the web we’re talking about, didn’t it start out fully stateless on Day One? After all, state isn’t required for hypertext linking and that was all there was on Day One (or The Day After, depending on whether you can remember life before the singularity).   Since then, it seems like folks have been struggling to support state so we can actually get some work done.  Regardless, I have to thank you again, for the HTML5 WebSocket and WebJneering link… I thought I was alone, but not so: “I’m just like every other post-apocalyptic protagonist, having spent my whole life questing after futuristic technology of the past, only to discover upon finding it that we’ve fallen so far as to render its usage unobtainable.”
  2. Anonymous
    Yes Breck, you are correct that the internet was stateless from Day One. As you say, since then, “folks have been struggling to support state,” to get things done.  I was referring to the recent trend away from storing any central state (so called “Shared-Nothing Architectures”) in a database. I was suggesting that SN architectures seem to be at odds with using stateful sockets. I should have mentioned that explicitly so it wouldn’t have been confusing.

Leave a Reply