Was da deren Beweggründe sind, kann fmaurer sicherlich besser schildern; wie du auch hoffe ich dass ihnen klar ist, dass das kein Update sondern ein Wechsel des batman Ansatzes ist.
Generell kann man festhalten, dass B.A.T.M.A.N. IV mit der Einführung der TQ deutlich besser mit (im WLAN Umfeld üblichen) unsymmetrischen Verbindungen klarkommt, also wenn die eine Station die andere besser verstehen kann, als umgkehrt.
Das war ein Upgrade gegenüber dem Vorgängänger III.
Gleich ist bis dahin, dass die Protokolle Pakeloss nutzten um sich ein Bild vom Zustand des Netzes zu machen. Das ist ein konzeptionelles Problem bei immer größer werdenden Netzen, die im Prinzip überwiegend stabile Verbindungen haben, solange man sie nicht belastet.
Überlastet man eine Verbindung, ist folgender Packetloss unausweichlich.
Den Zusammenhang kennt die bestehende Metrik nicht und hat auch auch keinen Weg festzustellen, wann eine Verbindung am Limit wäre.
Genau da würde B.A.T.M.A.N. V gerne ansetzen und führt Datendurchsatz basierte Metriken ein.
Die Verbindung wird daran gemessen, was man auf ihr an Traffic fahren kann.
Dazu braucht es allerdings Unterstützung vom drunter liegnden Layer; irgendwer muss batman sagen, was da an Datenverkehr stattfindet. So kann man bei LAN-Verbindungen gut abschätzen, ob es sich um eine 100Mbit oder eine Gigabit Strecke handelt und auch WLAN Treiber exponieren immer häufiger brauchbare Kennzahlen über den aktuellen und aktuell möglichen Durchsatz.
Kann man abschätzen, dass beide Varianten nicht zuverlässig funktionieren werden oder man selber detailliertere Werte kennt, kann man auch einen Override nutzen um die Werte selber festzulegen.
Das bis dahin.
Kurzgesagt ist V wenigstens theoretisch in der Lage mit Abschätzungen über das Netz besonders in störungsarmen Netzwerken richtig zu liegen, als es IV konzeptionell möglich ist.
In der Praxis hast du aber richtig erkannt und ich glaube auch weiter oben festgehalten, dass die Integration von B.A.T.M.A.N. V in Gluon noch immer eine offene Baustelle ist (auf der sich schon relativ lange wenig tut).
Möglich ist, dass das Interesse in der Community größer wäre, wenn die Integration abgeschlossen wäre.
Auch möglich, dass die Performance in den Netzen dann besonders in stabilen und oder viel genutzten Segmenten deutlich besser belastbar ist, weil die Metrik nicht im Blindflug austestet, wie viel (mehr) Datenverkehr man dem zugrundeliegenden Band gerade zumuten kann.
Und so ziehe ich meinen Hut vor Communities, die sich auf die Fahne geschrieben haben, V zu nutzen und die Integration vorranzutreiben.
Letztendlich werden wir da alle dran gewinnen.
Letztes Ding was ich irgendwann gelernt habe:
Während IV und V auf der Mesh-Ebene inkompatibel zueinander sind, kann man sie trotzdem Zeitgleich auf einem Gerät (Server) betreiben.
So könnte man für einen Stadtteil während der Migration je ein IVer und ein Ver Interface betreiben, auf das sich Knoten verbinden können und die beiden dann auf dem Server zusammen routen oder bridgen lassen.
Ein Breaking Change ist also auch da nicht notwendig, wenn man sich ein bisschen Mühe macht.
