[Olsr-dev] RIB2 refactoring

Hannes Gredler (spam-protected)
Mon Dec 3 12:52:35 CET 2007

Sven-Ola Tuecke wrote:
> Hannes,
> lets continue in english. To ask SEQNO_GREATER_THAN() for doubles/duplicates 
> is fine. As long as the possiblity to run into the "does not 
> forward/process" condition is unlikely and/or _if_ that happens it does not 
> take too long.
> The current implementation of SEQNO_GREATER_THAN() defines a quarter of the 
> possible values 0-0xffff as implausible IMO. In real live, we have ~ 0.1-10 
> messages per second and a hold time for status info ~ 10 - 600 seconds. The 
> firmware uses a relatively moderate default timing, leads to ~ 0.5 messages 
> / sec. and 300 seconds hold time for info. The chance to run in this 
> condition is 0.25 but we need to wait 0xffff/4*2 seconds == 9 hours until 
> processing continues. That's too long and too likely.
> We can narrow the "Impossible-Value-Window" - from 1/4 to (Holdtimeforinfo / 
> average message rate). In case of the firmware's timing, this is ~ 300 * 0.5 
> == 600. Everything below the last-seqno-seen is old. Everything above 
> last-seqno-seen+600 is a restart. If things went bad (Chance is ~ 1/100) we 
> need to wait up to 300 seconds until processing continues - which is not too 
> bad becaue olsrd is not designed to restart every now and then...

what about this:

1. upon startup generate the first TC with seqno random()
2. generate your second TC with seqno += MAXVALUE/2 (forcing a sequence wrap).
3. fallback to noremal +1 seqno generation.


More information about the Olsr-dev mailing list