[Olsr-dev] OLSRd 0.6.0 with ETT available

[David Lamparter]

On Fri, Oct 08, 2010 at 03:40:33PM +0200, Henning Rogge wrote:
> On Fri October 8 2010 10:11:57 David Lamparter wrote:
> > On Thu, Sep 30, 2010 at 02:02:25PM +0200, Henning Rogge wrote:
> > > I have a question on your encoding of the ETT values in the Hello/TC
> > > messages.
> > > 
> > > In the HELLO messages you seem to be using a 5 byte encoding. OLSR
> > > messages have to be 4-byte aligned, so you want to add 3 bytes of
> > > padding there. It might crash your nodes on an ARM/MIPS cpu otherwise.
> > 
> > Um, what kind of crap is this? The padding in OLSR is not only
> > unneccessary but even harmful as it wastes airtime.
> If you look into the OLSR RFC you will notice two things:
> 
> 1.) all OLSR messages have a length of 4*x bytes
> 2.) all fields in OLSR messages are "well aligned"

Yes. That is "good practice" for binary protocols in most cases -- but
for OLSR, it's plain and simple waste of precious airtime.

> Even the original ETX extension enlarged the messages by 4 bytes (with 2 bytes 
> padding).
> 
> I was pretty sure that it's somewhere in the RFC, but I was unable to find it.

0 hits for "align"...

> The OLSRd core and most of it's plugins was written with this assumption and 
> nobody changed it up to version 0.6.0. If you have a message with a length 
> with is not a multiple of 4, bad things will happen.
> 
> We had a case like this last year in Berlin. It took us 3 weeks to find the 
> problem. After this OLSRd got a check if incoming messages have a "correct" 
> size... if not the rest of the packet is dropped.

Well, obviously you can't change the protocol afterwards. It has the
padding, so you need to put it on send and skip over it on receive. But
if someone extens the protocol for a new metric - which makes it
incompatible anyway - there is no reason to keep adding useless bytes to
the packets.

Relying on the alignment is quite useless either way since if you read a
2-byte or 4-byte value, you'll usually need to swap the bytes from
network to host order anyway.

> The problem will not be there in 0.7.0, because the new packet parser for 
> PacketBB (RFC 5444) will handle this stuff.

Yes, OLSRv2/PacketBB wastes much less space in its packets.

-David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20101008/4bb89352/attachment.sig>