Re: [hybi] frame length encoding

[John Tamplin <[e-mail]>]

On Sun, Aug 22, 2010 at 5:27 PM, Scott Ferguson <[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).  If that option isn't deemed acceptable and
having 4 length steps is preferred, 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

Otherwise, as before.

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