Re: concurrent requests?

Note: I still don't think half-closed connections are supported by the
HTTP specification, and generally dislike the idea. I always run with
them turned off.

Support for half closed client connections lives perfectly well in
client_side I think. It may well learn about the fact from comm_read.
Why does this concern you?

The fact that a client connection is half-closed only tells that no
further requests will arrive on this connection, thus it can't be kept
persistent.

Regarding the data flows. Yes some kind of feedback is required to
trigger the receiving of more data.

How I envision it to be handled:
When a data flow is to be established a "flow object" is created. This
object involves
a) A small (slightly less than N*MRU) buffer for in-transit data
b) A "provider", capable to populate the buffer with data
c) A reader reading data out of the buffer (returned as pointers to the
data, not copies).

The readers feeds back when they have consumed the read data.

Both reader and the provider might be suspended by the flow object if
there is no data/space available for them.

The buffer is filled from start to end, with a high water mark at one
MRU from the end. If the current write offset is above the high water
mark then the provider is suspended until the buffer is fully emptied by
the reader.

Suspension is done by simply not calling a callback until it is time to
process anything.

comm_read/write then has the responsibility to register for the select
loop if required:

IF previous call was partial AND no select loop since then
    register for the select loop
    END
ELSE
    perform operation
    IF not possible due to no data/buffer availability
       register for the select loop
       END
return data
END

Note that it is the flow object which controls the ping-pong effect
between the sending and receiving end, and the comm_read/write
operations which controls when the select loop is required.

Hmm.. thinking about it further the process can be simplified a lot.
There is no need for a buffer with high/low water mark. Simple
"referenced" buffers created when the data arrives is sufficient. Simple
state machine with two states: reading from the provider, or writing to
the receiver.

Both states operates very similarly, like the above small psuedo
fragment above. The return statement is best implemented using a
callback.

/Henrik

Adrian Chadd wrote:

> Hmm .. ok. I'll look at request pipelining later on. The two things
> that is really required here to totally kill deferred reads is
>
> * half-closed connection handling
> * some form of optimistic io feedback where the server connection
> populating a MemObject can be kicked into reading more data
>
> Right now half-closed connections are handled inside client_side.c
> and the connection populating a MemObject for the store clients to read
> off just runs as fast as possible and is throttled by by the
> deferredread function. With a comm_read() implementation I think it
> will be possible for a sane event-handled half-closed connection
> system to be written. Stopping a MemObject read when it is too far
> ahead isn't going to be hard, but there isn't (AFAIK) a way to
> kickstart it again.
>
> Adrian
>
> --
> Adrian Chadd Build a man a fire, and he's warm for the
> <adrian@creative.net.au> rest of the evening. Set a man on fire and
> he's warm for the rest of his life.
Received on Wed May 31 2000 - 11:05:13 MDT