Re: [hybi] hum #3: Message

[Pieter Hintjens <[e-mail]>]

On Mon, Aug 9, 2010 at 2:50 AM, Greg Wilkins <[e-mail]> wrote:

> However, I do like having a very small minimal frame size for short
> messages, so I would modify Johns proposal to:
>
>  1 bit - fragment
>  2 bits - reserved
>  5 bits - opcode
>  8 bits - short length
>  [if length = 255: 6 bytes length]
>  length bytes of payload
>
> With opcodes defined for text, binary, mime and ping/pong frames

What we've also found in ZeroMQ is that we need two fragment bits, not
one.  That is, a 'first' and 'last' bit.  That lets a receiver catch
frames in mid-stream and decide whether to collect them, or discard
them.  I'm not sure WebSockets has current use cases for that.
However if we *ever* want WebSockets' framing to work on UDP or
multicast I'd recommend two fragment bits.  It may also reduce
somewhat the state needed in clients.

> I've proposed a 48 bit length to make the total header 64bits, but I'm
> ok with it being 64 bit length as well.

I think history teaches us that "big enough" never is.  Data gets a
bit larger every 18 months.  (I.e. data sizes double every 18 months.)
There is great benefit in allowing 1 frame = 1 message.  So I'd use 64
bits now and expect that we upgrade to 128 bits in 30 years or so.

-Pieter