W3C home > Mailing lists > Public > www-lib@w3.org > July to September 2003

Re: how pipeline works

From: Jerry G. Chiuan <jerry@oridus.com>
Date: Mon, 8 Sep 2003 10:15:33 -0700
Message-ID: <1f9601c3762c$d00c6e20$25a8a8a8@piglet>
To: <www-lib@w3.org>

----- Original Message -----
From: "Richard Atterer" <richard@list03.atterer.net>
To: <www-lib@w3.org>
Sent: Saturday, September 06, 2003 5:30 AM
Subject: Re: how pipeline works

> On Fri, Sep 05, 2003 at 10:49:26AM -0700, Jerry G. Chiuan wrote:
> > - By using pipeline, does client need only one TCP connection? ( all
> > requests go through the same connection )
> Yes!
> > - If yes, how does it guatantee the sequence of consecutive responses?
> > server takes longer time to deal with 1st request, but shorter time for
> > request. The server would hold 2nd response until 1st response is
> > then send them both sequentially back to client, or the server just
> > back directly no matter which response is ready
> The server will need to maintain a queue of pending requests. Any new
> requests get added to the end of the queue, and whenever a file has been
> sent out, the next request is taken from the front of the queue.
> RFC 2068 (HTTP/1.1) says the following:
> Pipelining
>    A client that supports persistent connections MAY "pipeline" its
>    requests (i.e., send multiple requests without waiting for each
>    response). A server MUST send its responses to those requests in the
>    same order that the requests were received.

I think you are right, the most straightforward and simpler implementation
is one thread for each "TCP connection" from client
The thread would block until the 1st request has been deal with, then 2nd
request can be handled afterwards....

> > - for doing that, we at least need 2 threads, one is for sending
> > another is for receiving reponses, don't we?
> That's one way to implement it - I guess it would also be enough if the
> server checked for new requests at regular intervals, e.g. after every x
> of sent data. I have no idea how Apache implements it.

I might need to correct my guess in previous email here
On client side, since the thread has to wait for the response after the
request is sent out "correspondingly", it is impossible to have
one dedicated thread taking care of sending requests and one for receiving
responses ( but we can do it in Socket implementation )
I might need to implement a thread pool, to pull out one thread for one
request....therefore there is a maximun number of requests which is possibly
sent out without waiting for their responses.

Is it a correct thought?


> Cheers,
>   Richard
> --
>   __   _
>   |_) /|  Richard Atterer     |  GnuPG key:
>   | \/|  http://atterer.net  |  0x888354F7
>    '` 
Received on Monday, 8 September 2003 13:12:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:56 UTC