Re: Large Frame Proposal

On 9 July 2014 13:33, David Krauss <> wrote:

> On 2014–07–09, at 11:13 AM, Greg Wilkins <> wrote:
> Currently a sender must dynamically adjust frame size by max(connection
> window, stream window).  This proposal changes that to
> max(connection window, stream window, settings limit).
> Don’t forget the TCP send window, which is just as likely to be the actual
> limiting factor.

That is transparent to the frame size.  Implementation are not required
(and in many cases probably not able) to take tcp window size into account
when determining the size of a data frame.

> In the receiver,  it probably does rule out the simple impl of just
> allocating a 16KB and expecting a full frame to fit into it.  But such
> naive impls do not actually work in practise as you invariably receive more
> than one frame in your initial 16KB buffer, so subsequent frames can still
> wrap over a buffer boundary.   The handling you have to do for that is no
> different to the handling you have to do for large frames.  So I still
> don't see any additional complexity?
> If a receiver advises that the max frame size is 16KB, then it may align
> each frame to the front of that buffer at the time it’s processed. This is
> not going to be complicated by anything, or simplified except maybe by
> switching to UDP instead :P .
> If a receiver wishes to implement itself in that way, then it is perfectly
able to advertise a 16KB limit in the settings and it will never see a
bigger frame.

FYI what Jetty does is to fragment data frames on arrival.  ie if we
receive only 8KB of a 16KB frame (because of TCP window or buffer wrap), we
simply pretend we've just received and 8KB data frame and forward that up
to the upper layers.   We think this is better than copying/shifting
because HTTP applications should be chunk size unaware.


Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Wednesday, 9 July 2014 03:43:00 UTC