Re: Framing and control-frame continuations

Would it be enough to just make it a full 32 bits? Seems like anything
more than that would be complete overkill. If we run out of
stream-id's in a session at that point we just tear it down and create
a new one.

On Thu, Feb 7, 2013 at 2:31 PM, Martin Thomson <martin.thomson@gmail.com> 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.
>
> 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 22:40:44 UTC