Wie und warum man den Flood-Traffic lokal halten kann und sollte
So groß die Freude bei vielen Meshcore-Nutzer auch ist, dass man von Hamburg bis Kassel schreiben kann, so groß sind auch die Probleme, die sich dadurch zunehmend einstellen. Ein wachsendes Mesh mit vielen Repeatern wird widerstandsfähig und zuverlässiger. Mehr Teilnehmer im Netz sorgen aber auch für mehr Traffic und dort beginnen dann in einigen Regionen bereits heute die Probleme.
Viel Traffic wird durch die Nutzung der Channel erzeugt – das ist nach meinem Eindruck die Hauptnutzung, insbesondere für Einsteiger, weil hier die Fehlerquellen geringer und die Erfolgserlebnisse wahrscheinlicher sind.
Wie funktioniert Flood beim Repeater
Die Nachrichten aus den Channels werden per Flood (deutsch geflutet) transportiert – es wird also beim Absenden keinerlei Vorgabe gemacht wohin / wieweit diese Nachricht kommen soll – sie soll so weit wie möglich ins Land fluten.
Jeder Repeater, der eine Flood-Nachricht hört, schaut als erstes in einer Tabelle nach, ob er genau diese Nachricht schon mal gesendet hat (um Loops zu vermeiden) und falls nicht, wiederholt er einfach die empfangene Nachricht und fügt sein Kürzel (2 Bytes vom PublicKey) dem Pfad der Nachricht hinzu. Und so läuft die Nachricht von Repeater zu Repeater und wird auf dem Weg von vielen Companions gehört. Hat der Companion den passenden Channel, wird sie gespeichert und erscheint in der App … mit ihr die Info über den Weg (Pfad) und die Anzahl der Repeater auf dem Weg (Hops).
Im Meshcore-Packet-Protokoll liegt die maximale Anzahl an Hops bei 64 … dann ist das Feld für den Pfad voll und ein Repeater würde die Nachricht nicht mehr wiederholen. Tatsächlich braucht eine Nachricht von Hamburg bis Kassel aber nicht mal 10 Hops … also kein wirkliches Problem. Aber wo liegt nun das Problem?
viele Repeater, viele Nachrichten, viele Wiederholungen und die knappe Airtime
Je mehr Repeater die Maschen unseres Mesh-Netzes enger machen, desto häufiger wird jede einzelne Nachricht natürlich wiederholt. Das ist positiv, weil es eben die Wahrscheinlichkeit erhöht, dass die Nachricht zuverlässig viele andere Menschen erreicht … das Kernprinzip von dezentralen Mesh-Netzwerken.
Jetzt müssen wir aber auch wissen, dass die maximale Sendezeit pro Stunde durch die gesetzlichen Regeln auf 10% begrenzt ist … also alle Geräte im Netz dürfen maximal 6 Minuten pro Stunde senden (natürlich sinnvoll über die Stunde verteilt). Auch ein Fakt ist, dass diese Zeit nicht nur für Flood-Nachrichten aus den Channels, sondern eben auch für Direktnachrichten, Adverts und Telemetriedaten genutzt wird und schon können gerade in Regionen mit vielen Teilnehmern und Repeatern die 6 Minuten sehr gut gefüllt werden.
Und dann darf man auch nicht vergessen … während ein Repeater eine Nachricht wiederholt, kann er keine Nachrichten von anderen Repeatern oder Companions hören. Je öfter er also selber sendet, desto größer ist die Gefahr, dass er etwas nicht mitbekommt.
Ein weiteres Problem ist dann noch, dass wir uns ja diesen Frequenzbereich mit vielen anderen Geräten teilen müssen und diese natürlich auch unsere Meshcore-Signale stören können. Das können wir nicht beeinflussen, sollten wir aber nicht vergessen, wenn wir uns darüber aufregen, dass irgendwas nicht durchkommt oder warum wir denn nur diese 10% nutzen dürfen.
Warum ist der Channel-Traffic ein Problem?
– ich nutze doch nur vier Channel und davon einen rein lokal in Uslar
Als erstes müssen wir erstmal verstehen, dass es viel Traffic gibt, den wir selber vielleicht gar nicht sehen. Ich habe auf meinem Gerät als Beispiel die Channel Public, #uslar, #kaffeerunde und Familie – letzterer ist ein Private-Channel, den ich ja nur mit meinen Familienmitgliedern hier im Dorf nutzen will.
Jetzt gibt es aber noch unzählige andere Channels – offene wie private – deren Traffic ich auf meinem Gerät und in meiner App ja gar nicht wahrnehme – trotzdem werden dort quasi sekündlich Nachrichten geschrieben und im Zweifel bis zu 64 Hops weiter verteilt. Wer das mal genauer sehen will, wieviel wirklich in der Luft ist, der geht in der App auf das Menü > Tools > Rx Log und sieht, wie viele Nachrichten durchs Mesh gehen, die man selber gar nicht sieht.
Also selbst der scheinbar lokale Channel #uslar oder mein Channel Familie, der in Hamburg wohl eher keinen interessiert, wird dortin locker weitergeleitet – unnötig weitergeleitet, wenn die lokale Runde der Uslarer hier gerade mal ein Gebiet von vielleicht 10km² erreichen möchte.
Scopes und Regions im Repeater und der App
Mit der Repeater-Firmware 1.10 wurden bereits die Funktionen für regions implementiert. Es gab im November ein erstes Video in Youtube (https://www.youtube.com/watch?v=VlaebfwWUBA) wo die Funktionen, und auch warum die notwendig werden, kurz erklärt wurde. Jetzt endlich sind die passenden Gegenstücke auch in der App angekommen und nun sind wir alle – also Nutzer und Repeater-Admin – am Zug das ganze sinnvoll einzusetzen.
Was machen diese beiden Funktionen in der Praxis?
Im Repeater kann der Admin nun mehrere Regionen definieren, denen der Repeater angehört und für die er Flood-Traffic weiterleitet. Wichtig … das gilt erstmal nur für Nachrichten, die auch ein entsprechendes Merkmal (Scope) haben. Anderer Flood-Traffic ohne Scope wird standartmäßig weiterhin normal transportiert.
Den Scope einer Flood-Nachricht setzt der Absender und deshalb wird es jetzt wichtig, dass Nutzer aktuelle Apps verwenden und Repeater-Admins auf aktuelle Firmware updaten und sich gemeinsam Gedanken darüber machen, wie die Regionen definiert werden können und sollten. Auf der Seite https://meshcore-de.fyi/meshcore:allgemeines:regions gibt es hierzu einen aus meiner Sicht guten Ansatz, den ich auch verfolgen werde. Entsprechende Infos gibt es dann hier auf der Seite und dann auch jeweils bei den Repeater-Infos.
Und dann sind wir Nutzer am Zug die für uns passenden Scopes in der App anzulegen und in den Channeln jeweils den Scope auszuwählen. Von dort an, wird jede Nachricht im Channel mit dem Scope gekennzeichnet und die Repeater können entscheiden, ob sie die Nachricht wiederholen müssen (Region ist dort definiert) oder eben nicht.
Am Beispiel #uslar … ich definiere für diesen Channel den Scope #DE-37 und sende eine Nachricht. Die umliegenden Repeater haben #DE-37 in ihren Regions und transportieren die Nachricht. Irgendwann kommt die Nachricht z.B. auf dem Brocken an und dort ist #DE-37 nicht mehr definiert und die Nachricht wird nicht mehr wiederholt und kommt somit sehr wahrscheinlich nicht mehr in Hamburg an.
Fazit
Klingt alles gut, klingt auch einfach, aber wird eine Weile brauchen, bis es recht flächig und damit effektiv umgesetzt ist. Ohne Zweifel werden wir gerade bei exponierten Repeatern, die um Berge herum zusammengehörige Bereiche verbinden sehr kontrovers über Regionen diskutieren oder auch individuelle Lösungen suchen und finden müssen.
Wir werden Kompromisse eingehen und uns selbstkritisch hinterfragen müssen. Aber – und das sehen wir heute schon in diversen Traffic-Analysen und lokalen Beobachtungen – wir müssen aktiv werden, um das wachsende Mesh stabil und vor allem nutzbar zu halten … und das geht leider nur, in dem wir Traffic sinnvoll begrenzen ohne dabei Menschen auszugrenzen.
Lasst es uns gemeinsam angehen – Lets Mesh together 😉