[Berlin-wireless] Save the Fish..

Mo Okt 15 08:51:51 CEST 2007

Hallo Lorenz, hallo Alina,

also ich finde das artet aus. Nix gegen das eine oder andere praktische 
XML-Zeugs, aber ich bin ein KISS-Fanatiker. Guck mal hier:

ll usr/lib/libxml2.so.2.6.20
-rwxr-xr-x 1 root root 1082267 2007-09-13 10:06 usr/lib/libxml2.so.2.6.20

Wie waere es mit diesem nameservice-Umbau (siehe Patch). Schreibt infach in 
eine fifo. Das kann man auf der plugin-Seite einfach mit 
fprintf(fifo, "<xml>\n"); beliefern und auf der Abfrageseite einfach 
mit "cat /var/run/fifo" auslesen.

@Lorenz: Sag mal - vor ein paar Tagen sauste ein Update des olsr-viz aus'm 
CVS. Ich dachte das waere die Reaktion auf die Aenderungen von Hannes wg. 
Routing-Refactoring (es gibt z.B. keinen String "HOST" mehr in der Ausgabe). 
Gestern geguckt, aber der VIZ will nicht. Kannste nochmal gucken?

@Alina: Du hattest keinen Bock, Javascript zu parsen. Dann mach ich das mal 
besser selber. Das beigefuegte Shellscript (cgi-bin-latlon.xml) einfach auf'm 
WRT hieven und aufrufen. Ist noch nicht perfekt aber da koennte man 
Zeugs 'reinflicken bevor man das in C-Code umsetzt was ja laenger dauert). 
Falls du keinen WRT in Betrieb hast, anbei auch Demodaten (gunzip -c ...).

Ganz generell: Ich wuerde tendenziell den Router-Daemon keine Routing-Fremden 
Aufgaben ueberhelfen wollen. Bestimmte Dinge gehoeren einfach nicht da 'rein.

// Sven-Ola

Am Sonntag, 14. Oktober 2007 15:39 schrieb lorenz schori:
> On 14.10.2007, at 13:58, Alina Friedrichsen wrote:
> > Halo Lorenz!
> >
> >> Könntest du dir mal noch den olsr-viz code anschauen und eventuell
> >> ein ähnliches Konzept fahren? Werte, die sich regelmässig verändern
> >> wären dann auf der Map einfach abzubilden...
> >
> > Kenn den Code nicht, wie leuft es da?
>
> Die Daten werden regelmässig per "iframe-ajax" ausgelesen (cgi-bin-
> vizdata.html) und in einer js-Datenstruktur der Mutterseite (cgi-bin-
> viz.html) aktualisiert.
>
> Links:
> parent.touch_edge(parent.touch_node('10.247.23.33').set_metric
> (1).update(),parent.touch_node('10.247.25.129').set_metric(1).update
> (),'3.45');
>
> Topologie:
> parent.touch_edge(parent.touch_node('10.247.23.33').update
> (),parent.touch_node('10.247.25.129').update(),'2.99');
>
> HNA:
> parent.touch_hna(parent.touch_node
> ('10.247.23.33'),'10.247.23.32','255.255.255.240');
> parent.touch_hna(parent.touch_node
> ('10.247.20.129'),'0.0.0.0','0.0.0.0');
>
> Routen:
> parent.touch_node('10.247.38.209').set_metric('3').update();
>
> Hostnmaen:
> parent.touch_node('10.247.23.33').set_desc('znerol-wl550ge.olsr');
>
> Enige Anmerkungen
> * Das ganze ist mit "iframe-ajax" gelöst, d.h. ohne XHR. Daher auch
> die "parent", die im txtinfo-output nicht sinnvoll wären.
> * touch_hna will ich noch loswerden und in die Form "touch_node
> ('10.247.23.33').touch_hna('0.0.0.0','0.0.0.0');" bringen.
> * update() aktualisiert den timestamp des Objektes welches per
> touch_xy im Browser erstellt wurde. Läuft dieser aus, wird der
> entsprechende Node nicht mehr angezeigt. Schön wäre natürlich ein
> "set_timeout(x)" anstatt dem "update()"
> * Die touch_x- und set_x-Funktionen geben jeweils das betroffene
> Objekt zurück.
>
> Um die Koordinaten noch mit einzubeziehen würde das bei diesem
> Konzept folgendermassen aussehen:
> parent.touch_node('10.247.23.33').set_latlon(x,y);
>
> >>>   passende printf's oder sowat mit XML dazu. Gibt dann sowat:
> >>>
> >>>   wget -O - http://localhost:2006/neighbours (gibt's jetzt schon)
> >>>   wget -O - http://localhost:2006/mapjs (JavaScript)
> >>>   wget -O - http://localhost:2006/maprdf (XML)
> >>
> >> Das gefällt mir nicht. Besser so:
> >>
> >> wget -O - http://localhost:2006/neighbours?format=rdf
> >> wget -O - http://localhost:2006/hna?format=txt
> >> wget -O - http://localhost:2006/?format=js
> >
> > Ich wuerde eher folgendes vorschlagen:
> >
> > wget -O - http://localhost:2006/neighbours (gibt's jetzt schon)
> > wget -O - http://localhost:2006/mesh.js (JavaScript)
> > wget -O - http://localhost:2006/mesh.rdf (XML)
> >
> > Der "." da dann die Dateierweiterung beim Runterlanden dann schon
> > stimmt. (Leider war soweit ich weiss das einziege Betriebsystem,
> > das Mime-Types im Filesystem unterstuetzt BeOS.) Und "mesh" statt
> > "map" da sich diese Daten z.B. auch wunderbar dazu nutzen liessen
> > um daraus Topologie-Grafiken zu zeichnen.
> >
> > Ich denke die Sache so flexiebel zu Programmieren, wie Du es
> > vorschlaegst, waere unnoetig schwierig, da Mesh-RDF dazu ausgelaegt
> > ist das gesammte Mesh abzubilden und nicht nur z.B. die HNA's.
>
> Ich frage mich ein bisschen wie z.b. das RDF einigermassen komplett
> aus dem OLSR rauskommen soll. Wo kommen z.B. die Werte für rdf:ID
> her? Oder dc:description? Damit die einzelnen RDF-Streams der Nodes
> auf einem Server aggregiert werden können müssen die ja irgendwie
> zusammengeführt und duplizierte Daten erkannt werden können. Oder
> verstehe ich da etwas falsch?
>
> >> Wir haben bei uns ein kleines ipk, das wählbare Netzdaten regelmässig
> >> auf unseren Server synchronisiert. Wir empfehlen unseren Nutzern nur
> >> die Gateway-Nodes damit auszurüsten.
> >> https://lab.openwireless.ch/trac/browser/firmware/ch/trunk/manetstate
> >
> > Hmm, das sammelt auch die ueber OLSR gefluteten Daten der anderen
> > Nodes ein, wie bei uns frueher?
>
> Keine Ahnung wie es bei euch ausserhalb der C-Base aussieht ;)
>
> > Die Ueberlegung bei der zentralen Map hier ist, das sie auch mit
> > anderen Mesh-Protokollen, wie z.B. B.A.T.M.A.N. laufen soll.
>
> Natürlich. Zu diesem Zweck wäre ein RDF durchaus sinnvoll. Was
> eventuell noch eine Überlegung wert wäre ist dass z.b. für
> verschiedene Daten verschiedene Feeds generiert werden. Metadaten,
> die nicht ständig wechseln wie Node-Namen, Antennen, Ausrichtung in
> ein node.rdf, solche die ständig wechseln in ein olsr.rdf, ein
> batman.rdf und ev. sogar ein phy.rdf mit Daten direkt aus horst, die
> Koordinaten in ein latlon.rdf. Das Generieren dieser Feeds wäre dann
> ziemlich viel einfacher auf den einzelnen Nodes. Wie komplex das
> Aggregieren dieser Daten wäre kann ich kaum abschätzen. Müsste aber
> eigentlich gehen ...(?)
>
> >> Darf ich noch anregen, dass den Daten noch ein Timestamp und ein TTL
> >> hinzugefügt wird? Das hab ich bei meiner Lösung bis jetzt immer auf
> >> dem Server hinzugebastelt...
> >
> > Hmm, meist Du jetzt um die Aktualitaet von z.B. der Mesh-RDF Datei
> > zu beschreiben? Gibt es bei den Weg uebers Internet so lange
> > Verzoegerungen, dass das ein Problem ist?
>
> Schlussendlich ist dies nur ein Mittel um die Datenqualität bewerten
> zu können. Wenn ein Node über Minuten nicht mehr im txtinfo-Output
> erscheint wird er nicht mehr angezeigt... Auf unserer Karte erscheint
> er dann rot (offline) und später gelb (unbekannt)...
> Da ein MANET durchaus Eigenschaften eines Realtime-Systems hat ist es
> meiner Ansicht nach nicht ganz verkehrt auch die zeitliche
> Komponenten der Daten zu berücksichtigen oder zumindest zur Verfügung
> zu stellen. Es müsste eigentlich möglich sein diese Timeouts direkt
> aus OLSR heraus zu bekommen.
> Vielleicht sollen die Daten ja auch mal gecached werden können...
>
> LG
> Lorenz
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : cgi-bin-latlon.xml
Dateityp    : text/xml
Dateigröße  : 1183 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071015/4de0acd6/attachment.xml>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : 135-georss-map-for-nameservice.patch
Dateityp    : text/x-diff
Dateigröße  : 13970 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071015/4de0acd6/attachment.patch>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : latlon.js.gz
Dateityp    : application/x-gzip
Dateigröße  : 10375 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071015/4de0acd6/attachment.bin>