Re: #541: CONTINUATION

On 3 July 2014 16:36, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 3 Jul 2014, at 4:29 pm, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
> > On 2014-07-03 00:29, Poul-Henning Kamp wrote:
> >> PPS:
> >>    I'm looking for co-authors for a jumboframe extension draft.
> >
> > Do you really need them? if you publish a sensible draft I expect
> several of us not liking CONTINUATION would implement.
>
> Would you (or any of the other Jumbo advocates) mind explaining why on its
> own it’s better than CONTINUATION, beyond syntactic sugar?
>
> AIUI you have to buffer and decode the entire header set in either case;
> is there some other aspect where it’s significantly better?



I've been very keen to say that Continuations ARE Jumbo frames, but I do
see some key differences that go beyond syntactic sugar:

   - The max acceptable size will be declared in a SETTING, allowing for it
   to be know in advance
   - max frame size can be adjusted down for low resource impls.
   - A true jumbo frame has its total size in the first frame, so an impl
   can immediately know if it is acceptable or not. With continuations, you
   might have to process 5 frames to reach a 64KB limit, only then to find out
   that their is a 6th frame and you have to throw away all that work done.
   - The code path for handling large or small frames will be pretty much
   the same for jumbo frames, with the exception of the code that determines
   the frame length.   With continuations, there is a significantly different
   code path that will be executed only for headers that are larger than
   20-something KB.   This is a code base that will be rarely used and thus
   probably not well tested.  Here be dragons!
   - Jumbo frames can also be applied to data frames (IF both the endpoints
   so desire).   This can be done to either simply tune the frame size to the
   most efficient size for the network (eg the fast hop between a load
   balancer and application server maybe able to have a much larger frame size
   and still have good multiplexing), or it may even be used to allow a single
   frame to send very large content.
   - Closing stuff down is just really hard.  No its harder than that!  I
   mean really really difficult!   SSL handshakes, half closed TCP
   connections, race conditions, blah blah blah - it is just really really
   really difficult to write robust code that always closes neatly, without
   double/triple work and does not leak any resources.    Any simplification
   in this part of the code will be really really really valuable.
   - Jumbo frames means that the END_STREAM flag is set on the last frame
   of a stream.   It is a real WTF moment for anybody looking at the spec when
   they see CONTINUATIONS can be sent after END_STREAM.  The confusion this
   causes should not be underestimated and reading this list is a good
   indication of the communication problems that will result.
   - A finally - CONTINUATIONS are jumbo frames.     If it quacks like a
   duck....


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