Re: Large Frame Proposal

On 2014–07–09, at 10:17 AM, Jeff Pinner <jpinner@twitter.com> wrote:

> To be clear, my issue is that this change makes determining valid
> frame lengths dependent on the session state which to me seems a step
> backwards both in terms of protocol layering and in terms of the
> achievable decoding throughput based on the simple frame layout.

It adds state to the framing layer, but that’s not a layering violation. Using consecutive binary-format frames to express a single semantic frame, depending on the END_HEADERS flag, is a layering violation.

Dynamic changes are unlikely to happen in practice; perhaps that should be disallowed. (If only the first SETTINGS is only allowed to increase the limit, the problem goes away.) However, safe dynamic adjustment only requires that the frame encoder applies the state change synchronously with sending the SETTINGS receipt. This is already a pattern held in common with other adjustable settings.

The frame layout is as simple as it ever was, they just increased the size from 2 to 4 bytes. Decoding is faster when frames end less frequently.

Received on Wednesday, 9 July 2014 02:36:03 UTC