[Olsr-dev] RIB2 refactoring

[Bernd Petrovitsch]

On Mon, 2007-12-03 at 09:31 +0100, Sven-Ola Tücke wrote:
[...]
> Mir ist nicht ganz klar, welche Drawbacks '!flat_fib_metrics' hat (also warum 
> wir es dem User ueberlassen wollen ober er's nimmt oder nicht). Ich vermute, 
> es wird viele AddRoute/DelRoute ausloesen um die Metric aktuell zu halten?

Ohne den Patch im Detail angeschaut zu haben, nur nach den letzten
Diskussionen: So ist es.

> Ich habe auszerdem gerade eine Optimierung wieder ausgebaut und es als 
> FFF-1.6.22 'rausgestellt (Patch anbei). Hintergrund: Je nach seqno=random() 
> kann es stundenlang dauern, bis TC's eines neu gestarteten olsrd-Daemons von 
> einem Nachbarn geforwarded/verarbeitet werden. Man muss in der Zeit neu 
> gestartet haben, solange die Nachbarn noch vom letzten Lauf etwas im Speicher 
> haben. Um das so zu machen, koennen wir evnt:
> 
> a) Die seqno irgendwo speichern, wo sie einen Neustart/Reboot ueberlebt

Hat, den Nachteil, das sie u.U. auch "3 Wochen ausgeschaltet" überlebt.

> b) Die Abfrage umbauen, damit die Chance auf diesen Effekt klein ist

MbMn besser.

> c) Bei den Nachbarn anfragen, welche Seqno wir zuletzt hatten

Uuugh, das widerspricht mbMn der Intention (und damit der
Sinnhaftigkeit) einer SeqNo: Die ist ja nur drin, damit der Nachbar
erkennen kann, ob er alle Pakete bekommen hat.
Da find ich ein explizites "ich hab neu gestertet" besser - z.B. als
zusätzliches Bit. Oder wir schicken auch die Uptime zum Startzeitpunkt
des Prozesses mit (hurra, ich gerade "Epochen" erfunden;-). Wenn die
verschieden ist, hat der neu gestartet.

> d) Immer bei Null anfagen und beim Wraparound dann auf 100 setzen

Uuuh, grauslich.

> e) Beim Beenden/Start jede Menge "Invalidate-me()" 'raussenden

Naja, bei 50% Packet Loss wird das mbMn aber auch ein wenig zum
Hazardspiel.

> Ich vermute auch, dass die zweite SEQNO_GREATER_THAN-Abfrage (Kommentar von 
> dir: "It could be that a TC message spans across multiple packets") so nicht 
> gewuenschten Effekt hat (defragementieren tut es jedenfalls nicht oder?).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services