Re: [hybi] frame length encoding

[Salvatore Loreto <[e-mail]>]

On 8/22/10 11:48 PM, John Tamplin wrote:
> On Sun, Aug 22, 2010 at 5:27 PM, Scott Ferguson <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>         I still think it is a mistake to increase the size of the
>         overwhelming majority of frames to make things easier for the
>         less-frequent (and larger, so that the extra overhead is
>         negligible) frames, but I am tired of arguing about it.  If
>         this is what people want then let's go with it.
>
>
>     I think the compact frame (LEN 00 = 0 byte length) would give you
>     that efficiency because the compact frame only uses 2 bytes total
>     for the header and length:
>
>
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>     +---+-+-+-------------+-+-------+
>     |00 |T|F| length(7)   |R|OPCODE |
>     |   |M|I|             |E|       |
>     |   |L|N|             |S|       |
>     +---+-+-+-------------+-+-------+
>
>     Where length(7) is the payload length and the payload immediately
>     follows the header.
>
>
> The problem with this is we only have a single reserved bit, which is 
> highly unlikely to be sufficient when we get to extensions.  That 
> means if those extensions are commonly used, we will be paying the 
> extra byte anyway and be doing it in a more awkward way.
>
>     If we were willing to trade some extra complexity for extension
>     bits, we could even reuse the TML and FIN bits for the compact
>     header, because those bits aren't needed for small frames. So the
>     compact (2 byte) header might be:
>
>
> If you are concerned about latency, you might well want to flush the 
> buffer with a small frame, with more fragments to follow when the 
> dynamic content is generated.
>
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>     +---+---------------+---+-------+
>     |00 | length(8)     |RES|OPCODE |
>     |   |               |   |       |
>     |   |               |   |       |
>     +---+---------------+---+-------+
>
>     I'm not sure if it's a good idea because it does make the compact
>     frame a special case, but it frees up some extra reserved bits.
>
>
> I think it is a false economy, because you only have 3 reserved bits 
> in this form, while 8 in the others.  If you assign a 4th reserved 
> bit, you now have to come up with a new way of representing it in the 
> short frame, so those extra reserved bits are less useful than the 
> others.  Also, given the complaints about complexity for simpler 
> things, I can't imagine having MORE/CMLP bits be dependent on the 
> length-length bits would go over well.
>
> I still think option #2 is the best compromise, and a number of people 
> agreed (and a number disagreed).
(as individual)
Hi John,

I know your preferences... but this is just an alternative/compromise if 
we can find a larger consensus
> If that option isn't deemed acceptable and having 4 length steps is 
> preferred,
(as individual)

it could be just a possible compromise among who wants 32 and who 64.
Then we do not need to use all 4 length steps, but also keep 1 step for 
future definition...
> I would rather just eat the extra byte for small frames and go with 
> the suggestion above, having headers of 3, 4, 6, and 10 bytes with 8 
> reserved bits between the defined flags and the opcode, as in:
>
>     * More - 1 bit
>     * CMLP - 1 bit
>     * LenLen - 2 bits
>     * Reserved - 8 bits
>     * Opcode - 4 bits
>     * Length - 2^LenLen bytes
>     * CML - 8 bytes - present only if CMLP=1
>     * Payload - Length bytes
>
(as individual)

+1
I like this proposed order.

cheers
/Sal

> Otherwise, as before.
>
> -- 
> John A. Tamplin
> Software Engineer (GWT), Google


-- 
Salvatore Loreto
www.sloreto.com