COMET: Socket Hungry AJAX

Dietrich Kappe, Friday, May 5, 2006 @ 9:00 am

From back in late March, Alex Russel over at IrishDev writes about a new AJAX technique, calling it COMET. What is COMET? Basically the browser makes a request of the servers, but the server keeps the socket open over a long period of time.

[COMET applications] all use long-lived HTTP
connections to reduce the latency with which messages are passed to the
server. In essence, they do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client.

Does it scale? We've talked about this stuff before when we spoke about Jetty Continuations. I wrote then that

I don't like this method because it is wasteful in terms of sockets and
threads; also, it is likely to stress stateful firewalls, load
balancers, etc., and may break in lots of client environments.

I stand by that statement. Beyond the issue of migrating these connections between nodes in a load-balanced cluster (yes, you could close the connection and have the client automatically reopen the connection), there are serious scaling issues.

One of the things that made HTTP based applications scalable was that they made use of small, stateless requests. This meant you could handle requests from an order of magnitude or more users than a comparable stateful application.

It's true that the typical AJAX polling for async updates also puts a burden on the server, firewall, load balancers, etc., but that depends partly on the frequency of the polling and the number of clients doing the polling. Even if I have 10,000 users polling the server every half second, I may still only have a few hundred sockets open at any one time if the request/response size is small and the user's network latency is low.

Modifications to server software like Apache and Jetty to conserve resources like threads and make use of IO multiplexing is a first and probably necessary step. Maybe I'm making too much of this stateful thing. We may have so much application state information floating around on the server side anyway that is will dwarf any OS and network resources that COMET and related technologies seek to spend.

Update 1: DWR's next release should have an implementation of COMET that they are calling "Reverse AJAX." More interesting, however, is the fact that they are releasing an API that allows one to write Javascript by writing Java.

Related posts:

1. Not There Yet: COMET with Apache and Jetty
2. Grizzly – Infrastructure for COMET and AJAX
3. Comet 2008: The State of Play in Reverse Ajax
4. Jetty 6’s Continuation Mechanism for Ajax
5. GWT and Comet – Using GWT with Jetty Continuations

Comments (2)

Software Development

Comments: 2 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I’ve implemented the server-push http pattern a couple of times, I’ve also blogged quite extensively about it, though I call it LazyHttp…

   Comment by Thomas Hansen, Saturday, December 16, 2006 @ 10:47 am

2. 

   While it’s true there are some hurdles to overcome with stateful firewalls, proxies, etc. most of these can be managed by judicious use of caching headers. The “wasted sockets and threads” are addressed in modern web servers that limit the size of the TCP/IP stacks, and that do away with the “1 thread per request” model and instead allow a thread to suspend a response.

   As for your argument about wasted resources, your example of 10K clients polling every 1/2 second is a a red herring. There is simply no way that a traditional polling architecture can handle the required 20,000 requests/second this requires. Most web servers max out at 1,000-2,000 requests/second for _static_ files, let alone dynamically generated content (as this requires) which is typically only served at 100-200 request/second. The only way you would “only have a few hundred sockets open at any one time” is if your CPU can process those requests fast enough. But it can’t – it wouldn’t just overheat, it would explode in giant fireball as soon as as it started receiving requests!

   (and that’s not even mentioning the 20MB/sec data transfer rates required by 1KB in header data x 20K request/second.)

   Contrast that to the in-the-field, yes-it-really-works, example of the COMET-based AIM Express (aimexpress.aol.com), whose servers handle 10,000+ simultaneous COMET connections on hardware that was available bought in 2003, and I think the scalability (and advantages) of the COMET architecture are pretty compelling.

   Comment by Robert Kieffer, Thursday, January 25, 2007 @ 11:18 am

Leave a comment