Re: [hybi] Framing take IV [why fragment]

[Roberto Peon <[e-mail]>]

The biggest reason that variable length encoding is annoying is that it
either adds complexity of buffer management or it adds overhead dealing with
the system.

A big advantage of length-prefixed data is that one need only read the
length, and then one can do a single alloc and read() to consume the rest of
the message exactly.

If any part of this is sentinel based (and that is what BER is,
effectively), you end up either doing read() one byte at a time, or you end
up doing a read for something you're guessing is larger than the max length.
If you guess wrong, you either have to have kept the encoded state from the
previous read, read more (involves another alloc), and only then do you get
to alloc and read the payload.

If you've guessed wrong and you read too much, then you have to save that
data, alloc another buffer, move it, and only then can you safely delete the
previous buffer.

This is a fair bit of complexity.
What is the gain?
-=R

On Wed, Aug 4, 2010 at 12:58 PM, Ian Hickson <[e-mail]> wrote:

> On Wed, 4 Aug 2010, Patrick McManus wrote:
> > On Wed, 2010-08-04 at 17:55 +0000, Ian Hickson wrote:
> > > On Wed, 4 Aug 2010, Patrick McManus wrote:
> > > >
> > > > But I also believe fragments with fixed lengths are simpler than a
> > > > BER because properly aligned lengths are always correct data - there
> > > > are no error cases as all the bits are defined to be some quantity
> > > > regardless of their arrangement. BER has error cases and determining
> > > > the expressed quantity requires multiple indirections and a
> > > > significant algorithm to use it.
> > >
> > > As far as I can tell there are no error cases as defined in
> > > WebSockets.
> >
> > I believe the specific ber length suggestion was:
> >
> >  - a BER-encoded packed integer, most-significant-digits first, high bit
> > used to indicate a continuation byte, giving the payload length.
> >
> > In that case, as I understand it, it would be an error if the ber type
> > encoding byte didn't specify a universal primitive type of 2. (or maybe
> > I'm wrong and it needs to be some other identifier - but that doesn't
> > really matter).
> >
> > it is not a big deal, but it is an error case.
>
> The spec just uses the packed integer part, not the whole ASN.1 form.
> There are no error conditions with that as far as I can tell. There's one
> redundancy (leading 0x80 bytes), but that's not an error case, and since
> the behaviour is well-defined, doesn't even seen to be a likely attack
> vector (which redundancies can often become), though naturally we'd want
> to make sure we tested that thoroughly in our test suite.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>