Hi,
die folgende Idee ist auf dem Kongress in diversen Diskussionen entstanden und bei weitem noch nicht ausgereift. Mich würde eure Meinung dazu interessieren.
Bisher rebroadcastet jeder batman Knoten alle batman Pakete (wir ignorieren die Ausnahmen jetzt mal). Können wir einen geschickten Algorithmus entwickeln / anwenden, der es uns gestattet an Stelle des Rebroadcasts der Nachbar-Nachrichten HNA informationen in unserem Paket mitzusenden ?
So könnte das funktioneren: Mein batman Knoten merkt, dass er 3 one Hop Nachbarn hat, welche keine anderen Nachbarn hinter sich haben. Daher nehme ich diese Nachbarn als HNA auf. Meine anderen Nachbarn erhalten nun das Paket und können feststellen, dass meine IP und die IPs meine Nachbarn ziemlich dicht beieinander sind und stopfen uns alle in eine HNA Nachricht.
Die Vorteil liegt auf der Hand: Weniger batman Pakete und weniger Routeneinträge.
Wir müssten das aber so geschickt machen, dass wir nicht unsere eigene Statistik fälschen. Wenn ich zu meinem aggregierten Nachbarn 50% packet loss habe, ihn aber in jeder meine OGMs erwähne, könnte der Eindruck entstehen, dass der Link recht gut ist ?!
Was meint ihr ?
Gruß, Marek
Hi Marek -
Die Vorteil liegt auf der Hand: Weniger batman Pakete und weniger Routeneinträge.
der Nachteil ist erhöhte Komplexizität der Sache. Der Vorschlag geht in die Richtung Methoden aus Linkstate Protokollen zu übernehmen. Prinzipiell spricht nichts dagegen.
Ich würde vorschlagen alle notwendigen Schritte zu machen, so dass der Code tendenziell die bestmöglichen Entscheidungen beim Routing trifft. Wenn Uns Linkstate-Komponenten dabei helfen (ETX-Werte zu Single-Hop-Nachbarn) können wir gerne darauf zurückgreifen. Bislang sehe Ich die Notwendigkeit jedoch nicht. Wenn der Code dann beim Routing sein Bestes gibt können wir schauen wie wir ihn in Richtung Skalierbarkeit optimieren.
Was die Abstürze angeht kann Ich die Aussage von Lui nur bestätigen - wir haben ein Memory-Leak. Der Speicherverbrauch stieg auf der Zwingli mit etwa 0.2% des Gesamtspeichers pro Stunde. Ich habe den Daemon daraufhin wieder abgeschaltet, da Ich ungern die Zwingli lahmlegen möchte - ein Neustart geht leider nicht remote. Auf dem WRT in der Wagenburg läuft der Daemon seit Tagen durch - der Speicherverbauch beträgt konstant 2,7 %.
Ziemlich ominös das Ganze...
Was haltet Ihr davon auf der Liste in English zu schreiben? Bislang ist Deutsch ok - aber wir bauen damit potentiell eine Barriere auf.
cu elektra
Hi,
Ich würde vorschlagen alle notwendigen Schritte zu machen, so dass der Code tendenziell die bestmöglichen Entscheidungen beim Routing trifft. Wenn Uns Linkstate-Komponenten dabei helfen (ETX-Werte zu Single-Hop-Nachbarn) können wir gerne darauf zurückgreifen. Bislang sehe Ich die Notwendigkeit jedoch nicht. Wenn der Code dann beim Routing sein Bestes gibt können wir schauen wie wir ihn in Richtung Skalierbarkeit optimieren.
schön. Wollte das nicht sofort einbauen, aber solche Ideen brauchen ein bisschen Zeit. ;-)
Was die Abstürze angeht kann Ich die Aussage von Lui nur bestätigen - wir haben ein Memory-Leak. Der Speicherverbrauch stieg auf der Zwingli mit etwa 0.2% des Gesamtspeichers pro Stunde. Ich habe den Daemon daraufhin wieder abgeschaltet, da Ich ungern die Zwingli lahmlegen möchte - ein Neustart geht leider nicht remote. Auf dem WRT in der Wagenburg läuft der Daemon seit Tagen durch - der Speicherverbauch beträgt konstant 2,7 %. Ziemlich ominös das Ganze...
In der Tat eigenartig. Gibt es irgendwelche bekannten Unterschiede wie: Startparameter, Nachbarkonstellation, etc ?
Um den Memory Leaks auf die Schliche zu kommen habe ich unseren internen MemoryChecker so umgebaut, dass er nun etwas brauchbares Auspuckt. An den Problemorten einfach mit Debuglevel > 0 starten, eine Weile laufen lassen und den Speicherverbrauch beobachten. Wenn dieser ansteigt, muss batman beendet werden und dann sollte ein solcher Output erscheinen:
Memory leak detected, malloc tag = 7 Memory leak detected, malloc tag = 7 Memory leak detected, malloc tag = 7 Memory leak detected, malloc tag = 7 Memory leak detected, malloc tag = 6 Memory leak detected, malloc tag = 2 Memory leak detected, malloc tag = 1
Schickt mir den dann einfach. Es ist durchaus denkbar, dass ihr diesen Output *nicht* seht. Der MemoryChecker kann nur "richtige" MemoryLeaks finden (benutzer Speicher, der nicht freigegeben wurde). Möglicherweise handelt es sich aber um "logische" MemoryLeaks (es wird immer mehr und mehr Speicher angefordet, beim Beenden aber alles wieder freigegeben). Letzteres wäre im Output natürlich nicht sichtbar.
Gruß, Marek
b.a.t.m.a.n@lists.open-mesh.org
-
elektra -
Marek Lindner