[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.
/hannes
More information about the Olsr-dev
mailing list