Re: Framing and control-frame continuations

One potential concern with this is that the opaque id is too small. We
haven't discussed this, but the current design relies on the fact that
stream identifiers are not reused. A 16 bit id would lead to connections
being rendered useless very quickly. Jeff mentioned that even at 31 bits,
this happens too often anyway.

That could mean that we need to consider other options anyway, but I
thought the information useful to surface, regardless.
On Feb 7, 2013 1:53 PM, "James M Snell" <jasnell@gmail.com> wrote:

> On Wed, Feb 6, 2013 at 3:47 AM, Amos Jeffries <squid3@treenet.co.nz>
> wrote:
> [snip]
> >
> > The Frame format:
> >
> >         0                   1
> >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> >        +-+-+-----------+---------------+
> >        |F|C|  type     |               |
> >        +-+-+-----------+               +
> >        |        Frame Length (24)      |
> >        +-------------------------------+
> >        |       opaque ID (16)          |
> >        +-------------------------------+
> >        |     Frame Data (16...N)       |
> >        +-------------------------------+
> >
>
> +1 ... I'm still unconvinced that control frames ought to be any
> longer than 16-bit but this seems like a reasonable compromise and
> workable format.
>
> - James
>
>