[Berlin-wireless] Save the Fish..
lorenz schori
lorenz.schori
So Okt 14 15:39:49 CEST 2007
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 : PGP.sig
Dateityp : application/pgp-signature
Dateigröße : 186 bytes
Beschreibung: This is a digitally signed message part
URL : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071014/d500d63d/attachment.pgp>
Mehr Informationen über die Mailingliste Berlin