Re: Some clarifications

At 15:44 08/12/1998 -0800, Kacheong Poon wrote:
>>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.
>
>This was my question.  From your description in the BOF, it seemed to me
>that HTTP needed an out of band (OOB) channel, what you called call back
>channel.  Currently, TCP does not have such a thing.  By OOB channel, I
>mean a stream which is not constrained by the original TCP stream.  This
>means data sent/received in the OOB channel is independently handled.  My
>question is if there is such a OOB channel, how it will be used?  

The WebMux model is more symmetric than what I think you are referring to
with your OOB channel. For example, I expect that in many cases, the role
of the server and client will simply swap so that the server can initiate a
new channel to the client and send a request. There should be no
constraints on the amount of data going in either direction.

Jim mentions some scenarios where this is useful. Another example is an
inter-cache communication where two caches can cooperate as two peers in a
Web of caches and not only as a downstream vs. upstream cache.

Maybe your question is really whether we need to be able to prioritize
streams either from the client to the server or the other way. In fact, we
have been discussing this as there are several scenarios where this comes
up in typical Web applications. My feeling is that it should be done at a
higher layer and not try and deal with it in neither TCP nor WebMux.

Note that there is no reason why bidirectionality can't be done in TCP
already and if peers can reuse state then this may be just as efficient as
what we are attempting to do in WebMux. I don't believe that the firewall
argument is useful here as I can't see why firewall administrators should
be more willing to have outgoing Mux channels than outgoing TCP
connections. However, I don't think your question is whether WebMux can be
done completely in TCP (in fact it can't) so I will not dive into this
discussion here.

>Can you also explain your requirements about getting more info from TCP?  I
>guess this was what you meant by a better socket API.  Please correct me if
>this is not what you meant.

Yes, this is what we have in mind. When we implemented HTTP/1.1 with
persistent connections, pipelining, and output buffering, it would have
been extremely useful for us to have had access to segment sizes, timers,
etc. The best we can do for now is to guess these parameters.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Sunday, 13 December 1998 21:40:48 UTC