Re: Framing and control-frame continuations

On Thu, 7 Feb 2013, Martin Thomson wrote:

> 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.

I was concerned abut the 16bit Opaque ID as well, it seems small to me.

I also noted a comment when this frame header was suggested that frame
data must be a minimum of 16 bits. I'm perhaps not yet aware of the
bigger picture, but I don't understand that constraint. But it is
a desire to maintain 64bit alignment, then just expand the ID and remove
the 16 bit minimum constraing.

> 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
> >
> >
>

Received on Thursday, 7 February 2013 23:39:43 UTC