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.