Re: Editorial note and question on connections

On Fri Feb 12, 1999, Jeffrey Mogul wrote:

> > Second, I was looking through this section trying to find
> > out if it's legal for proxies to multiplex requests from
> > different clients on the same connection to a server.  I
> > couldn't find a clear answer in the spec or in the
> > archives.  That is given two clients A and B talking to the
> > same server S via the same proxy P, what is minimum number
> > of connections required.  Clearly there must be a connection
> > from A to P and from B to P.  Can the proxy use just one
> > connection to S or must it open separate connections for
> > each client?
>     
> Its's legal, but not advisable.  Section 8.1.4 says
> 
>                A proxy SHOULD use up to 2*N connections to another
>    server or proxy, where N is the number of simultaneously active
>    users.

I saw this, but took it to mean a recommended maximum bound,
with out recommending any minimum bound.  I wasn't sure if
a recommended minimum would be N or 1.

> It might have been a good idea to explain the reasons behind
> this a bit more carefully.
> 
> The problem is "head-of-line blocking."  Consider, in your
> scenario, what would happen if A makes a request that generates
> a really lengthy response, and then B issues a request.  Because
> there is no packet-level multiplexing, B has to wait until
> A's response is fully transmitted.
> 
> More concretely, suppose that
> 	A = Administrative Assistant
> 	B = Big Boss

much more illustrative than Alice and Bob :-)

> and A requests a download of, say, the latest MP3 hit just
> before B requests, say, a short piece of critical business
> information.  (Not likely that these two resources would be
> on the same server, I guess, but this is just an example.)

So there is an ordering issue.  The proxy must wait for the
response before sending a request from B.  Is this also the
case in handling 100 Continue responses to a POST or PUT
request?  Must the proxy wait for the 100, and then wait
again to get the body from the client, send it to the server
and wait for the response before sending a request for B?

> If we ever get a decent QoS infrastructure, this would make
> it even more desirable to segregate request streams from
> different users onto different TCP connections.

Thanks.

Howard

Received on Friday, 12 February 1999 17:25:12 UTC