Re: Large Frame Proposal

OK, so keep the stream ID at 31 bits.

I cannot see that similar arguments do not apply to length. There are
already use-case for 64KB headers, so a 16b frame size is only just big
enough for them today, so we have zero room for growth and there are some
headers already larger than 64KB, so we are cutting off some users.

I can't live with 16 bit length.

24 bit minimum for me.


On 11 July 2014 11:54, Martin Thomson <> wrote:

> On 10 July 2014 18:12, Greg Wilkins <> wrote:
> > 24 bits of each is still 16MB frames and 16M streams in a connection....
> I
> > think both are reasonable guesses for infinity and this is a good
> compromise
> > between all the concerns.
> We've had input to the effect that a rollover would occur too
> frequently for some users at a 24-bit identifier.  I think that the
> number in question was a rollover every 10 minutes happens anyway.
> I'd have to confirm whether that is at 31 or 24.  Given how disruptive
> a rollover is, a the extra bits are useful.
> Note also that stream identifiers are used elsewhere, so we'd need to
> rework things in a few other places if they changed in size.

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

Received on Friday, 11 July 2014 02:17:00 UTC