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.
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.)
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.
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.
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.
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.
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…
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.
