Re: [hybi] frame length encoding

[John Tamplin <[e-mail]>]

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

> On Sat, Aug 21, 2010 at 9:34 PM, John Tamplin <[e-mail]> wrote:
>
> > But those are going to be highly compressible, and will easily compress
> to
> > under 126 bytes, even with some application level framing around them.
>
> Compression is not an option for low-latency cases (where volumes are
> in the millions of messages /second).  We're already finding that
> zero-copy techniques halve the cost of processing.  So the sweet spot
> for these really high volume messages remains above 127 bytes IMO.
> However, websockets is not intended for the financial markets, and
> probably won't ever be used for such volumes.


Obviously, I don't know the details of your environment, but I suspect CPU
speed will continue to increase faster than network speeds.  Already, it is
nearly even between the time to send the extra bits and the time to compress
them, so over time I suspect that we will see compression used even more.


> > 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.
>
> Indeed.  Adding another 8 reserved bits in the header does not seem
> wasteful.
>
> Again, I plead for simplicity.  Mixing a length with other bits just
> makes it more complex to process WebSocket frames and the benefits
> seem marginal.
>

I am a bit confused at your position -- in one sentence you suggest we
should add another byte just in case we might use it, yet you are still
worried about a single AND instruction?  Surely the cost of sending that
byte is higher than one instruction?

Regardless of the differences between #0 and #1, it already seemed clear
that #1 was losing out to #2 or yet more complicated schemes, so I don't
think option #0, which removes the one advantage compared to #3 or Shelby's
proposal of preserving a reserved bit, will get any more backers than #1
did.

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