comet and server push

[scotspine]

that's about the size of it. [initial] tests do show a sig. drop in server load under most conditions and it looks as though it will be a good-ish fit for what i'm doing.
oddly enough, vsj dropped through my letterbox on saturday and had a good article on it, including coverage of various implementations, including long-polling. i couldn't put it down

[VectraMan]

It looks like a bit of a half-way house. The server is fudged to artificially keep the connection open, which means it then can send messages to the client without the client having to poll.

But the connection is dropped periodically (the article says 5 seconds) so that the first n clients don't permanently tie up the server's threadpool and available sockets.

So it is a mostly push connection. As long as the event happens whilst the client has an active connection, it's low latency. If the event happens whilst the client is reconnecting or is having to wait for a connection, then it's no better than polling.

[DSW]

It sounds interesting, but I don't understand how it can work, it must involve the client polling as that is the only way that http is going to work. At which point it basically just AJAX?

[scotspine]

it's an event based model which essentially punts data up to the client only when there is new data to punt up.

[DimPrawn]

The term COMET is new to me.

Found this on CodeProject http://www.codeproject.com/KB/aspnet/CometAsync.aspx

Not sure how it is really a push? Sounds more like asynchronous polling from the browser to the server on an open connection.

How this differs/ is better than ajax webservices and timers on the browser I'm not clear about.

[scotspine]

hi. i was wondering if anyone has come across, or better, used the comet server push model, esp the implementation that uses IHttpAsyncHandler. if so, any comments?
thanks...