constellex

AJAX is all the rage over the Internet now, with various advantages and disadvantages. I won’t discuss those here, you’ve most likely read about them, and if not, there’s plenty of resources available. I want to talk about a problem that comes up often with people trying to develop applications using AJAX.

A lot of applications benefit from AJAX, but some are suffering as well. Some applications want to exist on the web, but break the rules. The HTTP 1.1 protocol spec states that “A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.” This is typically fine with AJAX, since you make a request and let the connection go. The same goes for a typical web request. As we’ll see later on with COMET, this is not the case.

HTTP requests and AJAX requests are both pull technologies. What I mean by that is the client makes the request and server simply responds. No connection is kept alive and the server is unable to contact the client at any point other than as a response to a request. But what if we want push technology through our browser? Well, HTTP wasn’t designed to do that. So most developers would stop there, which is probably a smart idea. It is impossible to create true push technology applications on the web without using third-party browser plugins. But you can fake it.

COMET is this elusive idea of being able to provide push technology through the browser. Most people would seem skeptical at first, but if you look further into the implementation, it’s almost a form of synchronous AJAX. That sounds strange… Synchronous Asynchronous JavaScript And XML (I understand AJAX, or Ajax, no longer has to stand for that acronym, but work with me here ). How can that be? Well let’s look at the strategy used to accomplish the COMET concept:

In essence, COMET acts a lot like typical threading, the client (browser) is the thread which blocks for a certain timeout period, until the server notifies it or the timeout occurs, and then repeat. This allows the end user to see instantaneous changes from the server, which is pretty awesome, because with AJAX, this can only be accomplished by using a polling technique, where the browser makes a call to the server checking for updates in very short intervals. That technique is a perfectly fine solution if you don’t mind scaling and performance issues as well as a large bandwidth bill. COMET will help reduce that.

Sound too good to be true? Well it is. Remember how I mentioned the HTTP 1.1 spec states we should only maintain a maximum of 2 connections at a time? Surprisingly almost all browsers follow this specification, which means while your COMET application is holding open those AJAX requests for that specified timeout period, the browser is now one less connection until you close the COMET application.

So there’s of course some advantages and disadvantages, just like any technology. COMET is useful for certain circumstances, most notably AJAX-y chat rooms. But tread lightly, you may be causing your end users headaches, which we all know is the last thing a company wants to do.