Re: [hybi] frame length encoding

[John Tamplin <[e-mail]>]

On Sat, Aug 21, 2010 at 3:24 PM, Pieter Hintjens <[e-mail]> wrote:

> The advantage of #0 is simplicity.  Frames can be read and written
> with the utter minimum of logic: no special cases, no ceilings, no bit
> mangling.
>

It has the same special case that option #1 does.


> Simplicity of the framing is also an essential part of reducing CPU
> cycles needed to process frames, which matters in low-latency
> scenarios.
>

I think the difference between option #0 and option #1 will be exactly a
single AND instruction, which hardly seems significant.

Our main use case for high performance messaging is market data and
> the generally-accepted average size of a FIX message is 157 bytes.  We
> also have Twitter messages at 140 bytes and SMS text messages at 160
> bytes.  This argues (gently) that a "short" message is under 255 bytes
> rather than 127.
>

But those are going to be highly compressible, and will easily compress to
under 126 bytes, even with some application level framing around them.

The main difference between #0 and #1 is that #0 uses one of three reserved
bits.  They are easy to spend, but then when we find out we need them it
becomes much more expensive to get them back.  We already know, today,
several potential uses for the reserved bits.  They are reserved simply
because we haven't agreed on how to use them and we are trying to separate
the base framing from how we will implement extensions so we can make
progress, but I think it is very likely that the extension mechanism we
define, starting shortly after the base framing is finished, will
immediately use at least 2 of the bits one way or another.  That doesn't
even include future extensibility requirements we haven't even thought of
yet.

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