RE: persistent conncetion HOL blocking

What may be a solution for now on, is that a client ONLY sends a second
request if it knows that the first won't take to much time, is not to large.
Maybe the proxy should also send "connection: close" if it already thinks
the request is going to take a long time. If the connection is going to be
closed, subsequent requests are not fulfilled by the proxy using the
currenct connection, they should be reissued on another connection or later

Thereby maybe that an more extended chunked transfer may be the solution in


-----Original Message-----
From: Matthew Delco [mailto:delco@CS.Berkeley.EDU]
Sent: vrijdag 12 mei 2000 20:45
To: Jeffrey Mogul
Subject: Re: persistent conncetion HOL blocking

> The same paragraph says:
>    A single-user client SHOULD NOT maintain more than 2 connections
>    with any server or proxy.
> The reasoning behind that requirement is related to a kind of
> head-of-line blocking.

Although, in the case of a proxy if a client is trying to get requests
from a number of different servers, through the same persistent connection
to a proxy, then it's not too difficult to get in a situation where a
proxy can't immediately return a response to the client because it's not
ready or able to reply to a previous request (on that same connection)
from the client.

For example, a client could pipeline requests to and through a
proxy. might be fast and reply right away to the proxy, but the
proxy can't forward the data to the client because hasn't replied
yet (and thus the response from must be queued).  Even though the
client can maintain two connections to the proxy, this doesn't eliminate
the problem (although it does make it less likely).  The problem can also
because worse in the case where is cached by the proxy (or a delta
[i.e., "IM:" header ] can be computed for, but is not cached.

Adjusting HTTP so that responses can be returned back in a different order
from requests would be one way to address the issue.  It would also be
useful in the case where two requests are made to the same server, and the
second request can be serviced much sooner than the first request (e.g.,
the first request might be some sort of CGI request).  In the case of a
significant amount of pipelining, the feature would also give a server the
ability to choose the best order in which to produce responses (e.g., long
MP3s last).  I'm personally not a fan of "enhancing" protocols, so I'm
interested in any suggestions that people might have for working within
the current confines of HTTP.


Received on Saturday, 13 May 2000 07:09:21 UTC