[Berlin-wireless] Vorschlag neue globale MAP

Dennis Bartsch dennis_bartsch
Fr Sep 10 16:38:22 CEST 2010


Hallo Liste,

Rolf hat soweit alles auf den Punkt gebracht, was mich zu diesem Engagement getrieben hat.

Zum Primary Key: der wird von der Datenbank vergeben und vom Node gespeichert. Kennt der Node seine NodeID nicht, fragt er mit seiner MAC-Adresse beim Server nach. Ist diese in der Datanbank zu finden (also der Node noch nicht ausgetimed), bekommt er seine alte ID wieder und wir haben kein Nodezappeln auf der Karte. Selbst die Interfaces haben von der Datenbank vergebene IDs (welche der Node aber nicht speichert, weil es nicht nötig ist ... MAC-Adresse reicht zur Identifikation der einzelnen Interfaces in einen Knoten). 

Damit unterstützt der Kartendatenserver mobile Knoten genauso wie geänderte IP-Adressen, wenn man zB erstmal ne temporäre Konfiguration drauf packt und erst später die endgültige IP-Adresse (zB bei Austausch defekter Hardware). Selbst doppelte MAC-Adressen (der Server soll am besten bis zur Visualisierung _aller_ Community-Netzwerke der Welt skalieren können) sind beachtet worden (an welchen Stellen es dort nocoh knrischen wird, werden wir sehen). Die ganze Sache geht soweit, dass wir später eine "getConfig" Funktion implementieren, über welche man endweder die maprelevanten Daten oder gar alle Daten (Interface-configs, Hostname, usw.) eines bestimmten Nodes abrufen kann und damit mit wenigen klicks einen gestorbenen Knoten mit neuer Hardware rekonstruieren kann (immer vorrausgesetzt, der Node ist nicht aus der Datenbank ausgetimed).

Was Alex meinte mit "das ist Realität" ist, dass der Code betreits geschrieben ist/wird. Node-Updates in die Datenbank funktionieren bereits. Das globalUpdate ist beinahe fertig. Serverseitig sauber mit Object-Relation-Mapping mit Propel implementiert, Clientseitig zZ noch mit nem knapp 700 Zeilen Shell-Script. Das wird noch modularisiert, um Plattformunterstützung (FFF, oWRT/UCI (voyage linux ?!, RouterOS?!, AirOS?! ... alles offen, wenn sich jemand findet) und Routingprotokollunterstützung in getrennten Dateien gepflegt werden, um einen auseinanderdriften der Featureunterstützung auf verschiedenen Plattformen zu vermeiden.

so weit, so gut

Gruß
Dennis
 		 	   		  




Mehr Informationen über die Mailingliste Berlin