Re: Making extensibility cheap

On Wed, Jun 4, 2014 at 5:25 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> 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.
>
>
Well written clients, utilizing async, multithreading
​, evented, whatever, can deal with TCP flow control quite well without
problem.
But they cannot avoid HTTP/2 flow control dead lock I am discussing.

The big difference between HTTP/2 flow control and TCP flow control is that
in HTTP/2 flow control receiver has to send WINDOW_UPDATE frame as
application data to notify the sender the consumed/processed size.

We cannot send WINDOW_UPDATE when transmission is blocked in the middle of
the other frame's payload due to flow control.  In DATA frame, we avoid
dead lock by slicing data size according to the remaining window size.  If
new extension frame is going to be subject to flow control, we need similar
way or something rather to avoid the dead lock.

Best regards,
Tatsuhiro Tsujikawa




> 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.
>