[WLANware] Was ist besser an B.A.T.M.A.N.? B.A.T.M.A.N Advanced!

Jens-Uwe Pohl jens-uwe.pohl at hostingfamily.net
Wed Oct 11 20:17:50 CEST 2006


Hallo elektra und Marek!

Natürlich seit Ihr Euch der Probleme bewußt. Das hätte ich nicht so
unnötig deutlich anzweifeln sollen. Tut mir leid! Mein Beitrag war wohl
zu kritisch und wenig konstruktiv. Gerade jetzt, wo viele Tester gesucht
werden.

Mich hat nur etwas gestört, daß so euphorisch von vielen plötzlich
gelösten Problemen geschrieben wurde. Das läßt immer erstmal ein
Fragezeichen bei mir aufleuchten.

Klar werden überflüssige Broadcasts nicht weitergeleitet. Das hatte ich
auch so verstanden und in meiner Kalkulation berücksichtigt.

Daß es keine Routingloops gibt, darf auch ruhig bezweifelt werden. Vor
allem, wenn Broadcasts wegen Packetverlusten verloren gehen und mit
unterschiedlich aktuellen bzw. veralteten Routingtabellen gearbeitet
werden muß.

Auch bin ich mir sicher, daß es insgesamt ein gut funktionierendes
Routing ist. Es scheint durchdacht und logisch und basiert auf aktuellen
Erkenntnissen und Ideen. Wie es sich in großen Netzen verhält, darauf
bin ich gespannt.

Viel Erfolg!

Jup

elektra schrieb:
> Hallo Jens -
> 
> Ich freue Mich darüber, dass Du Dich intensiv mit unserem neuen Kind 
> beschäftigst. Worüber Ich Mich weniger freue: Da ist sie wieder, die 
> leidige Skalierbarkeitsdiskussion ;) Leidig deshalb weil die Kreativität 
> der wissenschaftlichen Forschung seit Jahrzehnten unter Diskussionen 
> über diesen Aspekt leidet. Viel zu viele Köpfe sind damit beschäftigt 
> 'skalierbare' Routingprotokolle für Ad-Hoc Netzwerke zu ersinnen, 
> anstatt es bescheidener dafür aber funktionierend angehen zu lassen. 
> Dabei liegt der Pferdefuss weniger in den Protokollen (solange man nicht 
> das ganze bekannte Universum in einem einzigen Subnetz routen will kann 
> man die Probleme IMHO lösen) - sondern in der Tatsache, dass Daten 
> drahtlos übertragen werden. Eine Verkettung verlustbehafteter 
> Übertragungsstrecken skaliert nun einmal nicht, weil nach N Hops nix 
> brauchbares mehr an Bandbreite herausfällt.
> 
> Viel lieber sähe Ich es, wenn an den wissenschaftlichen Instituten keine 
> Luftschlösser simuliert werden, wie etwa: Unser drahtloses Protokoll 
> skaliert bis 100.000 Knoten... --- sondern Protokolle die z.B. in einem 
> Subnetz von 254 Knoten routen was das Zeug hält und stets für jedes 
> Paket die beste Route verwenden. Das ist IMHO das strategische Ziel. Ein 
> allwissendes Protokoll, das sofort immer alles weiss ist 
> selbstverständlich ebenfalls theoretischer Natur - aber dahin sollte es 
> meiner Meinung nach in der Tendenz gehen. Skalierbarkeit bis zur Grenze 
> des Sinnvollen kommt später in den Überlegungen. Das ist jedenfalls 
> meine bevorzugte Herangehensweise.
> 
> Soll das heissen, dass B.A.T.M.A.N nicht skaliert? Bewahre. Ich vermute 
> es skaliert bis zur Grenze dessen was Drahtlos überhaupt zu vernetzen geht.
> 
> Der Batman-Algorithmus baut darauf, dass es Paketverluste gibt. In der 
> drahtgebundenen Welt ist Batman sinnlos - jedenfalls würden Deine 
> Bedenken bezüglich Skalierbarkeit hier zutreffen. Mit Einschränkungen. 
> In der drahtgebundenen Welt muss man nicht im Sekundentakt die Qualität 
> der Übertragungsbedingungen überprüfen.  Schickt man Originatorpakete 
> alle 20 Sekunden skaliert das sehr wohl sehr hoch. Dazu kommt, dass 
> Batman-Pakete sehr, sehr klein sind...
> 
> OLSR skaliert bis zu der Größe wie sie in Berlin am Laufen ist auch nur, 
> weil wir nur noch alle 2,3 x 13 Sekunden einen einzigen stadtweiten 
> Broadcast pro Knoten erzeugen lassen. Entsprechend träge reagiert das 
> Netz auf Veränderungen.
> 
> Würden wir alle 30 Sekunden eine Originatornachricht pro Knoten 
> losschicken wäre Batman ebenfalls sehr träge - wie OLSR heute. Aber 
> einige tausend Knoten sind dann garantiert kein Skalierbarkeitsproblem 
> mehr...
> 
> Probiere einfach mal Batman aus. Ich denke Du wirst positiv überrascht 
> sein...
> 
> cu elektra
> 
>>Hallo!
>>
>>Mit meinen folgenden Gedanken möchte ich keine Hoffnungen zerstören,
>>denn die Idee von BATMAN finde ich im Grunde nicht übel, denn sie ist
>>irgendwie genial. Aber ich denke, wir könnten damit vom Regen in die
>>Traufe kommen.
>>
>>So, wie ich https://snr.freifunk.net/svn/b.a.t.m.a.n/trunk/LIESMICH
>>verstanden habe, broadcastet jeder Node zyklisch durchs gesamte Netz,
>>denn jeder Broadcast wird weitergereicht. Muß er auch.
>>
>>Wenn wir nun davon ausgehen, daß jeder Node in max. 30 Hops irgendwie
>>erreichbar ist (sonst funktioniert das IP-Protokoll sowieso nicht mehr),
>>dann bekommt im definierten Zeitraum jeder Node von jedem anderen Node
>>im Netz ein Broadcastpaket. Plus Doubletten, weil jeder Node mehrfach
>>erreichbar ist und von verschiedenen Nachbarn das gleiche Paket vom
>>gleichen Ursprungsnode bekommen kann. Sogar bis zu
>>(AnzahlNodes-1)*AnzahlNachbarn.
>>
>>Das erinnert mich stark an Windowsnetze auf NETBIOS-Basis. Da versandte
>>jeder Node im Minutenabstand so ein ähnliches Broadcastpacket und bei
>>200 bis 300 Nodes war eine 10MBit-Leitung voll. Dort hat allerdings
>>jeder Node auf jedes Paket geantwortet, was bei BATMAN nicht der Fall
>>ist. Dafür sind hier die Zeitabstände kürzer.
>>
>>Wie auch immer... Irgendwie muß trotzdem jeder Node erfahren, wo sich
>>jeder andere Node befindet, sonst weiß er nicht, an welchen Nachbarn er
>>das Paket weiterreichen soll. Die Routingtabellen bleiben groß.
>>
>>Die Routen-"berechnung" wird mit BATMAN nur auf eine andere Ressource
>>verlagert. CPU -> Bandbreite. Ob es sich als Ersatz für OLSR in großen
>>Netzen (z.B. Berlin) eignet, kann man erst sehen, wenn man weiß, ob die
>>Ressource "Bandbreite" die größeren Reserven hat. Insofern bin ich auf
>>die Ergebnisse größerer Feldversuche gespannt.
>>
>>Es ist auch kein Patentrezept, um MESH-Netzwerke beliebig zu vergrößern.
>>
>>Wie gesagt, wenn ich es richtig verstanden habe. Ausprobiert habe ich es
>>nicht.
>>
>>Schön finde ich, daß die Konfiguration erheblich vereinfacht ist.
>>
>>Beste Grüße,
>>
>>Jup
>>
>>
>>_______________________________________________
>>WLANware mailing list
>>WLANware at freifunk.net
>>Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware
>>
>>Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten
>>
>>
>>  
> 
> 
> _______________________________________________
> WLANware mailing list
> WLANware at freifunk.net
> Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware
> 
> Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten
> 
> 




More information about the WLANware mailing list