W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Re: pipelined client/server behaviour

From: Adrian Chadd <adrian@creative.net.au>
Date: Sun, 1 Apr 2007 19:18:44 +0800
To: Adrien de Croy <adrien@qbik.com>
Cc: ietf-http-wg@w3.org
Message-ID: <20070401111844.GA10579@skywalker.creative.net.au>

On Sun, Apr 01, 2007, Adrien de Croy wrote:
> Is there still some confusion about what we mean by pipelining?

There's none from me. I understand that pipelining wasn't viewed as a
property of connections, its what you've said:

> In my understanding it's when multiple requests are sent down a single 
> connection and subsequent requests are sent before the previous response 
> is received back.

And the behaviour of this is what I'm going to do a little more research
into. I'm currently specifying the pipeline in this application as a property
of the connection and requests will be pipelined only to the server or
upstream over the same connection - I'm trying to avoid having to build
my own pipeline logic and would like instead to trust the user-agent's
pipeline logic.

(This means passing the invalid HTTP replies back up to the client though;
and that could be rather exciting to try and attempt..)

> The approach we took with WinGate was to serialize the requests.  Whilst 
> this effectively breaks potential pipelining performance benefits, it's 
> about the only way we found to make the system stable.  We tried various 
> ways where we honoured the client and server pipelining (i.e. pass 
> through), but actually found the performance to be worse.  So now, we 
> don't even process the FD_READ notification on the socket if it's a 
> client send and we've received the entire message from the client and 
> the server response hasn't been sent back, so TCP windowing etc should 
> choke back the sends of subsequent requests.

You found it performed worse? Did you ever investigate why it turned out to be

Received on Sunday, 1 April 2007 11:08:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC