Re: [hybi] frame length encoding

[Scott Ferguson <[e-mail]>]

John Tamplin wrote:
> On Sun, Aug 22, 2010 at 3:44 PM, Salvatore Loreto 
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
>
>     (again as individual)
>
>     Hi Scott
>
>     almost, what I had in mind was
>
>
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>     +-+-+---+-+-------+--------------+
>     |F|T|LEN|R|OPCODE | reserved(7)  |
>     |I|M|   |E|       |              |
>     |N|L|   |S|       |              |
>     +-+-+---+-+-------+--------------+
>
>     in this way we have the possibility to add 1 extra bit to OPCODE
>     in the case we will run out of it
>
>
> Why not just move the opcode all the way to the right, and then we can 
> allocate reserved bits from the left as separate flags or from the 
> right to extend the opcode field?

Those are good points. Moving it to the right would also keep the opcode 
aligned, which is nice for debugging.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+-+-+---------------+-------+
|LEN|T|F| reserved(8)   |OPCODE |
|   |M|I|               |       |
|   |L|N|               |       |
+---+-+-+---------------+-------+

>  
>
>
>         It might also be possible to define 00 to use the reserved
>         byte for an
>         ultra-compact header, or 00 could be ultra-compact, and 01
>         could be the
>         normal 1 byte after the reserved and 10 be 2 byte.
>
>         LEN: 00 = 0 byte length (uses reserved byte)
>              01 = 1 byte length
>              10 = 2 byte length
>              11 = 8 byte length
>          
>
>     +1
>
>
> 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.

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:


 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 that would give you the compact frame with the minimal overhead 
that you want, while still reserving 8 bits for the standard frames.

-- Scott

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