Re: Making extensibility cheap

On 4 June 2014 05:06, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

> If flow control is forced, payload of this new frame must be able to be
> fragmented in arbitrary size to avoid deadlock just like DATA frame, which
> Johnny and I wrote in the other thread.  If both ends started to send new
> frames and blocked in the middle of their payload due to exhaustion of
> window, deadlock will happen.


Sorry, but just as for headers, I don't get this one.  If h2 doesn't flow
control it, then TCP will and you can still fill your windows and
deadlock.  You can deadlock two UTF-8 decoders talking over a raw socket if
you try hard enough.

You get this in naive HTTP client/proxy implementations all the time, where
they try to write the entire request with blocking IO and then get the same
thread to read the response.   The answer is just don't write code like
that - got async or multi-threaded, don't try to hold the entire
request/response body at once.

The solution for HTTP has not been to seek an exemption from TCP flow
control, so I don't see why h2 headers/extensions should seek such an
exemption from their framing layer.
If an extension really must read 1GB of data before it is prepared to
continue, then it just needs to commit to reading that 1GB of data - either
decoding it as a stream of putting it in a buffer, and to not block it's
writing on it's reading and vice versa

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.