Re: how pipeline works

----- 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?
e.g.
> > server takes longer time to deal with 1st request, but shorter time for
2nd
> > request. The server would hold 2nd response until 1st response is
generated
> > then send them both sequentially back to client, or the server just
sends
> > 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:
>
> 8.1.2.2 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.

Hi,
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
requests,
> > 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
kB
> 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?

-Jerry

>
> Cheers,
>
>   Richard
>
> --
>   __   _
>   |_) /|  Richard Atterer     |  GnuPG key:
>   | \/¯|  http://atterer.net  |  0x888354F7
>   ¯ '` ¯
>
>

Received on Monday, 8 September 2003 13:12:09 UTC