[Berlin-wireless] Save the Fish..

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>