Echo Hello HopGlass{\,,\ Server}

Hallo zusammen,

seit gluon v2015.1 ist gluon-announced standardmäßig in gluon enthalten. gluon-announced ersetzt alfred und ist eigentlich als Übergangslösung gedacht, die „weniger schlimm“ sein soll.
Während das ffmap-backend die Daten aus alfred bezieht, bezieht der gluon-collector, der von @dereulenspiegel entwickelt wurde, seine Daten per announced. Leider bin ich nicht zufrieden mit der Entwicklung des gluon-collectors. Neue Knoten tauchen erst nach Ewigkeiten auf der Karte auf, einige Formate werden nicht unterstützt, und vor allem: Ich finde mich nicht im Code zurecht und kann die Defizite so nicht selber beheben.

Daher habe ich mich hingesetzt und den HopGlass Server entwickelt. Der HopGlass Server ist eine in node.js geschriebene Anwendung, die - genau wie der gluon-collector - die Daten per announced aus dem Mesh sammelt. Im Vergleich zum gluon-collector ist der HopGlass Server dank der Sprache JavaScript, die nahtlos mit dem Datenformat JSON (JavaScript Object Notation) integriert ist, sehr viel kleiner und dadurch einfach erweiterbar und verständlich. Im Moment können die Daten für den Meshviewer generiert werden und das Programm reagiert relativ schnell auf neue Nodes im Netz. Geplant sind die Ausgabe von Prometheus-metrics, dem Format für die freifunk-karte.de „nodelist.json“ und das Streamen von Daten von Nodes bis zum HopGlass.

Im gleichen Zuge werde ich meinen meshviewer-fork absetzen, wie schon länger auf der Projektseite angekündigt. Statt die Features zum Upstream zu migrieren, werde ich aber einen Ableger mit drastischen Änderungen erstellen. Das Projekt trägt den Namen „HopGlass“. Im Moment sind für HopGlass noch keine der geplanten Änderungen implementiert. Diese werden beinhalten: das Streaming der Daten vom Node über das Backend zum Client, zahlreiche Features anderer Meshviewer-Forks, Differenzierung von Mo?-Links und bidirektionale Anzeige von Links.

Den Code für den HopGlass Server werde ich bald™ ins git pushen. Bis dahin darf man eine Demo auf https://karte.ffdus.de/hopglass/ beobachten. Das verwendete Frontend ist aktuell immernoch mein Meshviewer-fork.

11 Likes

Ich freue mich auf eine weitere Alternative zum backend.

Gerade bei uns im Netz stoße ich immer wieder auf große Probleme mit ffmap und Alfred die sich mir nicht erschließen.

Bin gespannt wie es wird.

@Tarnatos

Das sollte auch deine PN beantworten.

1 Like

Vorteil ist ja vor allem, dass Topologieänderungen (z.B. umbenannte Knoten, verschobene Knoten in 3- 10 Minuten „auf der Karte“ sind, gleiches gilt für neue Knoten.
(Die Alfred-Nutzenden werden meine Freude darüber vermutlich nicht nachvollziehen können, aber es dauert wirklcih nicht mehr 30-120 Minuten, bis Knoten an Randbereichen einer Wolke endlich „propagiert“ haben bis in den Meshviewer.)

Klasse Dankeschön.

Gibt es eine Möglichkeit, dass der Server aliases.json’s verarbeitet? Das wäre für uns essentiell.

Ja, das werde ich einrichten. Aber bevorzugt sollten Superknoten, RPis (ohne Gluon) und so mit einem seperaten Programm Daten senden und damit auch Statistiken generieren.
Bis ich das mit der Aliases.json einrichte, kannst du die Instanz stoppen und manuell in die data.json deine Knoten einfügen. Wenn du zu wenig Daten hast, könnte das Programm abstürzen. In dem Fall nur her mit den crash logs.

5 Beiträge wurden in ein neues Thema verschoben: Hamburger Knotenformular

Mumble gerne. Ich melde mich.

Nachtrag:

Wie übergibt man die Argumente korrekt an den Server, speziell die iface Angaben. node /path/to/hopglass.js iface=bat-xybla ?

node hopglass.js --iface bat0

Ist es möglich, den Server direkt an mehrere Interfaces zu binden? Sodass einfach von allen ifaces angefragt wird und auch von allen Interfaces die Antworten verarbeitet werden und in einer nodes.json landen.

Genau das tut er, da er er fastd in einem halben Dutzend Broadcast-Domains hängt und für jeden ein eigenes batman-Interface fährt.

@yayachiken Nein: Ich starte für jedes Iface eine neue Instanz, weil ich eine JSON für jede Community haben möchte.
Das lässt sich aber leicht machen…

@yayachiken schon passiert:

1 Like

Hint für alle die es ausprobieren wollen, und so wie ich keine Ahnung haben:

Das ganze läuft nicht mit node.js v0.10. Das ist Default bei Ubuntu Trusty (aktuelles LTS), da muss man also ein externes Repo hinzufügen um ein neueres Node zu kriegen.
Die Mindestanforderungen hatte ich noch nirgends dokumentiert gefunden, darum lass ich das einfach mal hier.

Ansonsten ist zumindest der hopglass-server so ziemlich Just Works™, Frontend hab ich noch nicht getestet.

1 Like

Eventuell ergibt es einen Unterschied, ob man

-var targetip = argv.targetip ? argv.targetip : 'ff02::2'
+var targetip = argv.targetip ? argv.targetip : 'ff02::1'

nutzt.
Auf ::2 antworten nicht alle Gluon-Versionen (zuverlässig).
Mag sein, dass sich da noch was ändert, und dass es ärgerlich ist, dass man so auch alle Clients einmal anstubst, aber zumindest funktioniert letzteres.

Also bei mir war es User-Fehler. Oder weiß nicht.

Als ich das mit --ifaces bat02,bat03… gemacht habe lief es eine Weile, dann kamen auf einmal keine Daten mehr raus. Hab die raw.json und die hosts gelöscht, dann wurden die neu erstellt mit 0 bzw. 2 Bytes Große.

Jetzt habe ich es auf die Bridges ins Freifunknetz lauschen lassen, jetzt gehts wieder. Macht ja auch Sinn.

Ich frag mich aber gerade wieso es überhaupt mal bei den batXX interfaces geklappt hat…
Irgendwo hab ich grade wohl nen grundsätzlichen Verständnisfehler.

Wir hatten bei uns in einigen Domains das von Dir beschriebene Szenario, dass der batctl o ein x-faches der Nodes auswarf als der HopGlass. In anderen Broadcast-Domains passte es jedoch 100%.

Es scheint so, dass Gluon-Master „aus Q3/4 2015“ nur auf auf die ::1 reagieren, d.h. sowohl die alten 2015.1.2 wie auch die aktuelleren Master (und natürlich das 2016.1-release) auch mit der ::2 antworten.

Wer sich also sicher ist, von diesen Versionen nicht betroffen zu sein, kann die Netzlast (geringfügigst) durch „nur ::2“ reduzieren. Ist ja immerhin ein Broadcast…

„Client-Pünktche“ und „Nodenamen“ auf der höchsten Map-Zoomstufe würden wirklich(!) helfen.
Wenn die Nodes eng stehen wie hier:

Eine Stufe höher gibt’s dann nix mehr:

Eine Möglichkeit die Routernamen auszublenden wäre auch fein, dann wird es ein wenig übersichtlicher und bei mouseover bekommt man den Namen dann weiterhin angezeigt.

1 Like

Das zu implementieren ist kindergeburtstag bzw relativ einfach

Das mit den aus geblendeten Clients und nodenamen kommt vom leaflet dort ist hardcoded das die nur bis zoomstufe 18 gezeichnet werden

Hatte im meshviewer v4 mod thread glaube ich eine Lösung dafür gepostet

Ich kann’s leider nicht.
Daher meine Bitte, das zu Implemtieren, wenn es keine Designziele gibt, die dem widersprechen.