Re: Some clarifications

> From: Kacheong Poon <Kacheong.Poon@eng.sun.com>
> Resent-From: ietf-http-ng@w3.org
> Date: Tue, 8 Dec 1998 11:57:45 -0800
> To: <ietf-http-ng@w3.org>
> Subject: Some clarifications
> -----
> In yesterday's RUTS BOF, it was mentioned (by Jim Gettys?) that it would
> be nice if TCP had a call back channel for HTTP.  Can someone explained how
> that call back channel will be used by HTTP?  What are the requirements of
> the channel?  It was also mentioned that the socket API should provide
> mechanisms to get back some more TCP info.  What info is needed?  I remembered
> RTT being mentioned...  And how they will be used by HTTP?
> 
> In the HTTP-NG BOF, a question was asked about the proposed transport layer
> requirements.  The answer was that it should not be discussed in the BOF.
> I guess it is OK to state them here...  Can the chairs do that?  Thanks.
> 
>                                                         K. Poon.
>                                                         kcpoon@eng.sun.com

TCP does have a back channel; TCP streams are bi-directional.

The issue comes up of how to use the return from the server;
traditionally, most protocols just use the TCP stream to return
responses and/or errors, and you can't interspearse other traffic over
the return channel.

Once you have a multiplexing layer that enables its use, if the server 
needs to call back the client, this is easy and much faster to do over 
an existing TCP connection than establishing a new TCP connection, which 
saves packets, the round trip times to establish a connection, and it may
not even be possible to establish a separate TCP connection (think about
how firewalls work. 

The potential uses are myriad.

If you are doing a distributed object system on top, your natural programming
model is to send object references around that get called; method invocations
in this sense often invert client and server to get thie jobs done.  We exploit
this in the prototype HTTP-NG implementation; if there is a callback to
an object on the "client", it goes over a new session we establish
in the MUX over the same TCP connection, rather than establishing a new
connection, saving a connection establishment (with the multiple packets
and RTT's as a result).  As RTT's are large in the Internet, this is a major
win for many uses.

And about the most commonly asked for feature of the Web is some way to 
provide notifications.  I've had people describe to me amazingly gross
ways of doing really ugly things inside of HTTP to do this.  Yuk....

If you have a cache heirarchy of proxy servers, it is perfectly reasonable
to leave the browser's connection to a Web server open for a long time,
and therefore the server might inform the client of some change.  Ultimately,
when (if) scalable multicast can be deployed, it may be better to do
notification this way, but almost anyone doing collaborative work is
desparate for any solution, even if notification of the entire planet
is not needed (and typical workgroups are small enough that the ultimate
scalability is not required for most collaborative work applications).
			- Jim

Received on Tuesday, 8 December 1998 16:43:21 UTC