Re: HEADERS and flow control

On 28 May 2014 17:16, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

>
> On Wed, May 28, 2014 at 11:55 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>>
>> Tatsuhiro,
>>
>> but flow control exists to limit the resources that a server must
>> dedicate to a connection.  If the window is 0, then the server is saying
>> that it does not have any more resources available.   So the client simple
>> should not send a new stream as there are no server resources.
>>
>>
> Are you saying that while server retains request headers in memory, it
> must not respond WINDOW_UPDATE since it is the commitment of the resource?
>  If so, the connection window gets drastically small and concurrency is
> vastly reduced.
>

No I'm not saying that.  I'm saying that with flow control the server makes
a fixed memory commitment when it accepts a connection.   If it is prepared
to accept more data it will send a WINDOW_UPDATE.

If the server is not prepared to accept any more data from a connection,
then it will not send a WINDOW_UPDATE.  If the client then sends enough
data to consume the window, then the window is consumed and the client
should be flow controlled.

So just saying, that the data the client wants to send is meta-data in a
header field does not some how make the server have any more resources
available in order to handle those HEADER/CONTINUATION frames.  Sending
additional headers when the flow control windows are full violates the
resource contract between client and server as the client is asking the
server to handle and store an unlimited amount of extra data.

I well written server will reset the stream, a not so well written server
may try to continue but may eventually throw an out of memory exception and
crash.   Eitherway, the non-flow controlled header data does not get
through and the dead lock is not resolved (well I guess crashing the server
will resolve the dead lock).


By removing the protection of excess resource consumption from the protocol
>> will not magically give the server any more resources.
>>
>> In the case that you give, if there are 200 bytes available, but the
>> headers of a new stream is 250, then there can be two possibilities - the
>> client sends the 250 without flow control and the server resets the stream
>> because it has not resources  OR the client does not send the 250, but
>> instead uses the 200 to allow another request to progress (and maybe
>> complete).
>>
>>
>
In your example, you said that if we flow controlled headers then a client
with a 250B header but only 200B window would not be able to send the
header.     You said this as an argument to say the client should be able
to send the 250B without flow control, otherwise an important request might
not get through and you may get deadlock.

I'm saying that a well written server that enforces resource limitations on
connections would probably  reset the stream if you did send those 250B as
it goes above the resource allocation it is prepared to make per
connection.  Perhaps an accepting server might accept some additional
requests even when they are low on resources, but servers are not infinite
and at some point they will have to reject some incremental important 250B
header set from the client (or crash) - so dead lock will result anyway.

Removing flow control from headers has not avoided deadlock, it has just
made the client unaware of the amount of data that it can send before
deadlock will occur.

regards




-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.