Re: pipelined client/server behaviour

On Sun, Apr 01, 2007, Jamie Lokier wrote:
> 
> Roy T. Fielding wrote:
> > But there is no question that
> > pipelining is hard to do right across all implementations.  That
> > doesn't mean it can't be done across some implementations, and there
> > really isn't much point in discussing it -- the standard will not
> > be changed.
> 
> Without changing the standard -- here's a proposed enhancement:
> 
>     "Connection: pipeline" may be included in a response to indicate
>     that the agent generating the response (i.e. origin server or
>     proxy) correctly handles pipelined requests on this connection.

I seem to recall reading an old mailing list post from a while ago where
someone noted various implementations treated Connection: <anything not
keepalive> as an implicit Connection: closed.

>     Both origin servers and proxies may generate this, to indicate
>     their support.
> 
>     Conservative clients and proxies may refrain from sending
>     pipelined requests until this has been seen in a previous
>     response.  For example, a client may generate one request on a new
>     connection, and upon seeing this header, send more pipelined
>     requests immediately.
> 
>     Being a "Connection" token, it will be stripped by intermediate
>     proxies.  (Right...?)
> 
>     (Additional enhancements to pipelining, if any, may be indicated by
>     a "Pipeline" header.  For example if response multiplexing or
>     reordering were to be added, support would be indicated by
>     appropriate value of this header).
> 
> Just a little thought which might make pipelining more deployable.

I thought about this a couple of days ago. You'd want to cover:

* out of order replies;
* non-pipelinable replies (eg streaming media) being a small 4xx or 5xx reply
  which is interpreted as a "No, don't do this via pipelining; resubmit on its
  own connection please" so the User-Agent doesn't have to wait for the end of
  the reply chain to discover it hasnt' received a reply for a specific request
  (And this gets worse if the last reply allows the connection to be persistent
  and unfortunately the User-Agent expects a reply that isn't coming.)
* I can see more than one situation where a pipeline request chain of A, B and C
  does look to the User-Agent like a non-idempotent sequence but does have some
  session or database expectation of request order. If you treat the requests as
  potentially concurrent requests to handle then things could get subtly confused.
  If you treat pipelining as purely a method to dodge request queue RTT and 
  have the server just do it right (ie, don't try to handle them concurrently;
  handle them one at a time and pass off to the same server) then pipelining behaviour
  suddenly looks like non-pipelining behaviour.

SCTP might not be a bad idea; there was some post to the mozilla dev list
from a party interested in implementing SCTP support in Mozilla.



Adrian

Received on Monday, 2 April 2007 03:30:27 UTC