[hybi] frame length encoding

[John Tamplin <[e-mail]>]

>From the discussions related to my previous proposal, it seems like how we
encode the length is the remaining contentious issue (at least there were no
other comments on the rest of the 4 issues I outlined).  It is hard to get a
sense of who prefers what to what extent.  Also, in a comment not intended
as a serious proposal I mentioned a 1/2/8 option, I had a couple of people
reply to me privately that they liked the idea.  So, I thought I would ask
for a "show of hands" about three possibilities.  If you feel strongly for
or against a particular option, please reply and say so.  If you are fine
with any of the three, then there is no need to reply.

A sample code snippet (not suggesting this is optimal for any of the cases)
is included to make sure what is intended is clear.

Option 1
========
Use 7 bits in the frame header, and if the value is 0-126, that is the
length.  If the value is 127, the next 8 bytes are a 63-bit length (the high
bit must be zero).

long long len = readByte();
if (len == 127) {
  len = readLongLong();
}


Option 2
========
Use 7 bits in the frame header, and if the value is 0-125, that is the
length.  If the value is 126, then the next 2 bytes are a 16-bit length.  If
the value is 127, the next 8 bytes are a 63-bit length (the high bit must be
zero).

long long len = readByte();
switch (len) {
  case 126:
    len = readUnsignedShort();
    break;
  case 127:
    len = readLongLong();
    break;
}


Option 3
========
Use 8 bits in the frame header (assigning RSV2 in the most recent proposal
to be part of the length field).  If the high bit is set in that byte, shift
the current length seven bits and read the next byte.  Leading 0x80 bytes
are disallowed, and at most 9 length bytes may be included

int byte = readByte();
if (byte == 0x80) // fail
long long len = byte;
for (int i = 1; (byte & 0x80) && i < 9; ++i) {
  byte = readByte();
  len = (len << 7) | (byte & 0x7f);
}
if (byte & 0x80) // fail



I would be willing to live with any of the three personally.  My preference
is roughly even for #1 or #2 over #3 because #3 uses one of our reserved
bits (reducing expansion options) and has error states which must be
checked.  Also, most of the lengths don't buy you much in terms of reducing
overhead, as the overall frame is much longer than the header at that point
anyway.

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