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

From: "Mike Dierken" <[email-masked]>
Date: Sun, 3 Feb 2008 12:32:42 -0800

No new application level protocol (set of request/response messages) is
required for server-to-client communication, just consider the 'server' to
send requests and the 'client' to return responses (reverse their roles).

What is needed are approaches for delivering an unsolicited request message
to a protected or behind-a-firewall machine. (If the receiver of the
unsolicited message is not protected by a firewall, then it can be
considered the same as a traditional 'server'). Another way to think of this
is to separate which device initiates a network connection and which device
sends the application-level 'request'. 

For example, if the desktop initiated a network connection to a big remote
machine, and the remote machine responded with a signal (that clients and
intermediaries understood) to switch 'roles', then the client would become a
server (receiver) listening for requests and the server would become the
client (sender) sending requests. Perhaps the HTTP CONNECT method or Upgrade
header may be useful here.

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ??????? ?????
> Sent: Friday, January 18, 2008 1:55 AM
> To: [email-masked]
> Subject: HTTP 2.0: Request from server to clients at 
> persistent connection
> 
> 
> 
> 
> 
> Now there was very fashionable an expression " WEB 2.0", 
> though basically it as a matter of fact the same web. Though 
> reforming of a web it is very actual, and mainly it rests on 
> development of the new protocol http 2.0.
> 
> http 1.1 I consider as the main lack - request only from the 
> client. Now many processes pass from a server to clients, and 
> it demands back request - from a server to clients. 
> Therefore, " WEB 2.0" it is necessary to develop for real 
> introduction in the urgent image new protocol HTTP 2.0 and to 
> lay in it an emphasis on:
> - Revision persistent connections
> - Back request: from a server to clients.
> 
> Sorry for bad English.
> 
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.516 / Virus Database: 269.19.7/1232 - Release 
> Date: 1/18/2008 7:32 PM
>  
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 3 Feb 2008 23:11:39 +0100

> - 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

---

From: "Mike Dierken" <[email-masked]>
Date: Sun, 3 Feb 2008 18:42:22 -0800

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

> [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: Sunday, February 03, 2008 2:12 PM
> To: Зимаков Павел
> Cc: Carsten Bormann; [email-masked]
> Subject: Re: HTTP 2.0: Request from server to clients at 
> persistent connection
> 
> 
> 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.
> 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
> 
>

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 8 Feb 2008 17:37:55 -0800

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:

> There are even server extensions to cope with the resulting large  
> load of connections waiting for new data.
> 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,

---

From: "Mark Baker" <[email-masked]>
Date: Fri, 8 Feb 2008 22:35:42 -0500

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

The Wikipedia entry for COMET has the best description of its various
forms I've seen;

http://en.wikipedia.org/wiki/Comet_(programming)

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com