Re: Large Frame Proposal

On 9 July 2014 13:01, Jeff Pinner <> wrote:

> I fear the they will happen frequently in practice, requiring dynamic
> changes to the frame encoder/decoder. In practice they will likely be
> driven by what is seen at the HTTP layer (large uploads/downloads,
> file-transfer, etc).

I'm not sure I understand the extra dynamics that you think this proposal

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).       That is hardly
a significant change.

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?

So can you expand a bit more on your concern because I'm just not seeing it
(which is entirely different to not agreeing with it... which I may or may
not do once I've understood it).


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

Received on Wednesday, 9 July 2014 03:13:38 UTC