Subject: Re: On pipelining

From: "Fred Bohle" <[email-masked]>
Date: Fri, 21 Jan 2000 09:48:42 -0600

Fred Bohle@NEON
01/21/2000 09:48 AM

Daniel,

     I would suggest that the multi-threading be done at the connection
level,
not at the request level.  That way you can be sure the requests are
handled in their
proper order.  Multi-threading at the request level would require some
other mechanism
to be sure that they are executed in the same order, defeating the purpose
of multi-
threading.  At a minimum, you must return the responses in the same order
that you
received them.  Again multi-threading the requests would require a
mechanism to
ensure this order, minimizing the benefits of such multi-threading.

     Consider three requests that:
1. display a database item.
2. update that database item.
3. display the same database item.

The intent here is to show the before and after views of the database item.
In a
multi-threaded request server, if the requests execute in 1,3,2 order, or
2,1,3 order,
the before/after sense of the display is lost.  Note that this is true even
if you force
the order of responses to be reshuffled as 1,2,3.

     So, I don't see how you can make it work if you multi-thread the
requests.

Fred Bohle

"Daniel Hellerstein" <[email-masked]> on 01/21/2000 09:35:53
AM

To:   [email-masked]
cc:    (bcc: Fred Bohle/Dev/Neon)

Subject:  On pipelining

I'm redoing the persistent-connection/pipelining support in my web
server, and
the question came up of how to resolve pipelined requests. By resolve,
I mean
the act of the server using the request line (and headers, etc) to
determine which file to read, which script to run, etc ... the end
result being the creation of  a response to  send to the client.

Basically,  in the following scenario (from mike sabin)..

>  Request1
>  Request2
 > Request3
>         Response1
>           Response2
 >         Response3
>(although, clearly, if there are many requests we might expect
>the request stream to partially overlap the response stream).

would "resolution of request2" await the completion of transmission
of response1? Or can these  3 requests be resolved simultaneously
(say, using
seperate threads); with first response1 sent, then 2, then 3.
That is, could a multi-threaded server create response2,  wait for
succesful transmission of  response1 (over the persistent connection),
and then transmit response2 (over this
same persistent connection)?

This is a problem if the resolution of request2 can depend on the
resolution of
request 1 (for example, when request1 causes some client-specific
state variable, that is  used in request2, to change)

The definition of idempotency (rfc2616  9.1.2)  suggests NO -- since
identical sequences should return the same result, which would
preclude
situations where the oddities of server load may dictate the  speed
with which
simultaneously resolved requests are processed.

Any strong opinions?

Daniel Hellerstein
[email-masked]
http://www.srehttp.org

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 21 Jan 2000 08:09:38 -0800

Multi-threading can be done for requests that come in over the
same connection; this seems valuable, especially if each of the
requests require computation or communication with other service
elements in the network.

For example, you could have a server with a request thread and
a response thread, where requests would spawn additional threads
to handle them if necessary (e.g., if the request was for a
CGI or non-local resource) and then queue the results for the
response thread.

#    I would suggest that the multi-threading be done at the connection
level,
# not at the request level.  That way you can be sure the requests are
handled in their
# proper order.  Multi-threading at the request level would require some
other mechanism
# to be sure that they are executed in the same order, defeating the purpose
of multi-
# threading.  At a minimum, you must return the responses in the same order
that you
# received them.  Again multi-threading the requests would require a
mechanism to
# ensure this order, minimizing the benefits of such multi-threading.

 #     Consider three requests that:
# 1. display a database item.
# 2. update that database item.
# 3. display the same database item.

# The intent here is to show the before and after views of the database
item. In a
# multi-threaded request server, if the requests execute in 1,3,2 order, or
2,1,3 order,
# the before/after sense of the display is lost.  Note that this is true
even if you force
# the order of responses to be reshuffled as 1,2,3.

#      So, I don't see how you can make it work if you multi-thread the
requests.

but

   Clients SHOULD NOT pipeline requests using non-idempotent methods or
   non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
   premature termination of the transport connection could lead to
   indeterminate results. A client wishing to send a non-idempotent
   request SHOULD wait to send that request until it has received the
   response status for the previous request.

It is not the server's responsibility to insure consistency, and a server
implementation that multithreads the responses would seem to be valid.