W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Framing and control-frame continuations

From: James M Snell <jasnell@gmail.com>
Date: Thu, 7 Feb 2013 14:39:57 -0800
Message-ID: <CABP7RbfMjpEH9FjrzjEBXhz+rpdRU7gLUHjBsdyM2z7jzfg7+g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 February 2013 22:40:47 GMT