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

The three approaches I've seen for COMET or similar functionality are

1. Standard poll - this is HTTP compliant and requires no special  
understanding between client and server.  Many poll requests are  
useless, returning "nothing new', but you can't know that in advance.

  2. the Long Poll - the client opens a GET and waits for a response  
after some event occurs, *not* immediately.  After the response does  
get sent, a new GET is made with another possible wait.  This  
approach requires the server to know that the client will indeed hold  
the connection and expects delay.  There need to be different URLs or  
something else different about the request to tell this is a request  
for *change* information, not the base document.

3. The infinite response body - the client opens a GET and the server  
starts a response body and never finishes it, merely adding more to  
the response body over time.  E.g. this is used in financial  
institutions to provide stock and commodity price streams.  This has  
some problems for certain kinds of intermediaries.  It requires some  
out-of-band mechanism for the client to know that it will get an  
unending stream so it has to parse and use it as it goes and not wait  
for a "finish".

All of these have problematic performance if they occur in many Web  
sites and are used by many clients.   The latter two aren't really  
standardized so we haven't examined how clients and servers know  
what's going to happen and how intermediaries are supposed to behave.

There've been various attempts at standardizing a set of Jabber or  
SIP address conventions or address discovery mechanisms that would  
allow one to see HTTP resource events over a channel that was  
actually designed to be server initiated --> client.  Ideally such a  
solution would allow aggregators so a client didn't need to hold open  
subscriptions to as many Jabber or SIP servers as it had subscriptions.

See http://www.sharemation.com/%7Emilele/public/notifications/ for  
some architecture diagrams for notification aggregators.

Lisa


On Feb 3, 2008, at 2:11 PM, Carsten Bormann wrote:

>
> 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 Saturday, 9 February 2008 01:38:12 UTC