RE: HTTP 2.0: Request from server to clients at persistent connection

Thanks for the link to mod_mailbox - I hadn't thought anyone had built
efficient connection management extensions for this sort of thing. I'll
definitely take a look.

For low latency delivery, I've used an approach where the client sends a GET
(looking for new messages) and the server doesn't send any response but
keeps the connection open until new messages arrive. The client then
receives the messages fairly soon after the server sends the response. This
type of approach requires a server that can handle lots of open connections
(essentially, not one thread per socket...)
See http://www.searchalert.net/xmlrouter/ and
http://www.searchalert.net/xmlrouter/events/chat.html?topic=hello-world

> -----Original Message-----
> From: ietf-http-wg-request@w3.org 
> [mailto:ietf-http-wg-request@w3.org] On Behalf Of Carsten Bormann
> Sent: Sunday, February 03, 2008 2:12 PM
> To: ϊΙΝΑΛΟΧ πΑΧΕΜ
> Cc: Carsten Bormann; ietf-http-wg@w3.org
> Subject: Re: HTTP 2.0: Request from server to clients at 
> persistent connection
> 
> 
> On Jan 18 2008, at 10:55, ϊΙΝΑΛΟΧ πΑΧΕΜ wrote:
> 
> > - Back request: from a server to clients.
> 
> There are a lot of systems out there doing this with HTTP today.
> http://alex.dojotoolkit.org/?p=545
> is a nice introduction on the subject (Alex Russell calls 
> this "COMET", I prefer to call it real-time AJAX).
> 
> There are even server extensions to cope with the resulting 
> large load of connections waiting for new data.
> http://blog.lighttpd.net/articles/2006/11/27/comet-meets-mod_mailbox
> is an example for this.
> 
> Given ugly realities such as NAT timeouts, simple polling is 
> the right solution for most HTTP applications that need to 
> push updates from a server.  For the ones that need a 
> combination of low latency and limited bitrate/server load, 
> the solutions mentioned work well.  As an example, 
> http://tzi.org:2000/s6.html is an old demo I wrote for a 
> synchronized slide presenter.
> 
> Gruesse, Carsten
> 
>

Received on Monday, 4 February 2008 02:42:29 UTC