Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- projekte:datenreise [2012/03/22 08:17] – philipp
+++ projekte:datenreise [2017/03/01 19:19] (aktuell) – Externe Bearbeitung 127.0.0.1
@@ Zeile 6: / Zeile 6: @@
 Die Daten werden von eine zentralen Instanz bereitgestellt. Die Stationen holen sich die Daten übers Inet von einem Server, übertragen sie auf die lustige und anschauliche Art und schieben sie wieder auf den Server zurück. Dadurch kann man alle Stationen monitoren und man kann das System dynamisch erweitern oder Stationen wieder entfernen. Sogar eine Erweiterung in eine andere Stadt ist denkbar.
-Also wird quasi nur die Schnittstelle zur zentralen Instanz definiert. Alles danach kann frei gestaltet werden. Vielleicht kann man für die große Gesamtaktion sich von irgendwem GSM Modem, UMTS Router o.ä. sponsorn lässt, damit eine Ethernetschnittstelle möglich ist, oder so. Aber zunächst sollten wir uns einige Stationen ausdenken.
+===Zentrale Instanz===
+Auf dem Warpzone Server gibt es eine VM (datenreise.warpzone.ms), die Stand heute noch nix kann. Ich will aber mal beschreiben was sie können soll:
+==Frontend==
+Das Frontend soll möglichst einfach sein, damit die Einstieghürde für potentielle Mitmacher möglichst gering ist. Die Schnittstelle soll möglichst vielseitig sein, aber auch ein Mindestmaß an Sicherheit bieten. Daher kommen für die Übertragung der Daten nur Protokolle in Frage, die eine Authentifizierung ermöglichen. Eine mögliche Schnittstelle wäre http mit nem PHP oder CGI im Hintergrund. Da http selbst zu proggen nicht ultraeingängig ist, könnte man noch ein MiniFTP entwickeln, der mit den Befehlen ''auth'',''get'' und ''put'' arbeitet. Der MiniFTPdemon könnte die Daten auch direkt aus der Datenbank holen.
+Mit dieser Vorgehensweise hat man folgende Probleme erschlagen:
+  * Dateinamen : Dateinamen sind immer eine Fehlerquelle bei Falschbenennung oder auch bei bereits vorhandenen Dateinamen. Dadurch kann es zu zahlreichen unvorhergesehenen Fehlern kommen und das Interface sollte ja einfach sein, gell?
+  * Timestamps: Für unsere statistische Auswertung müssen wir wissen, welche Station wie lange gebraucht hat. Einfach nur eine Datei hochladen, die dann von einem Prozess eingesammelt wird, der nur alle 15 Minuten läuft ist etwas ungenau. Dann könnte der Dateiname der Uploaddatei einen Timestamp enthalten. Der müsste aber korrekt im Layout und synchron zur zentralen Uhr sein. Zudem hat nicht jede Station überhaupt eine Uhrzeit da.
+  * Threadsicherheit: Die Threadsicherheit ist notwendig, da immer 2 Prozesse auf die Daten zugreifen. Erstens der Upload/Download der Station und zweitens Auswertungsprozesse auf der zentralen Einheit. Wenn beide Prozesse gleichzeitig auf eine Datei zugreifen, bekommt der eine nur die Hälfte der Daten und die andere Hälfte landet im Nirvana. Konstrukte mit .lock Dateien oder ähnlichem sind für dieses Szenario ungeeignet bzw. zu komplex umzusetzen. Beim Schreiben in eine Datenbank achtet die Datenbank drauf, dass sich 2 verschiedene Prozesse ins Gehege kommen.
+  * Authentifizierung: Für einen Dienst, der im Internet hängt und dessen öffentlich Schnittstellen dokumentiert sind, braucht man eine Authentifizierung. Sie muss nicht besonders komplex sein, aber man soll es ja auch nicht zu einfach machen.
+  * Datenintegrität: Damit uns nicht irgendwelche Skriptkiddies Pornobilder in die Daten schieben, sollten wir eine Überprüfung der Daten vornehmen. Z.b. mit der [[http://de.wikipedia.org/wiki/Levenshtein-Distanz|Levenshtein-Distanz]]. Wenn diese Distanz zu groß ist, ist vielleicht Schluderei oder eine defekte Station im Spiel. Hier sollte man überlegen, ob man der Station nochmal dieselben Daten schickt, oder die Daten einfach benutzt? Wenn eine Station offensichtlich defekt ist, weil sie nur noch Quatsch schickt, könnte man sie auch aus dem Prozess rausnehmen und dem Admin Bescheid geben. Damit die Stationen nicht nur als Datensenke fungieren, sollte es neue Daten immer erst geben, wenn die letzten bereits wieder hochgeladen wurden.
+Habe mal ein Datenbankschema gefummelt:
+{{ :projekte:datenreise.png?200 |}}
 ====Webseite====
@@ Zeile 42: / Zeile 55: @@
 === Analoge Übermittlung ===
 == Wasserwaage ==
-Je nach Bytewert wird eine bestimmte Menge Wasser in ein Wasserglas geschüttet und gewogen. Das Wiegeergebnis ist das übertragene Byte. Danach muss das Wasser wieder zurückgepumpt werden.
+Je nach Bytewert wird eine bestimmte Menge Wasser in ein Wasserglas geschüttet und gewogen. Das Wiegeergebnis ist das übertragene Byte (bzw. 100% Füllstand = vollster Farbwert, 0%=schwarz). Danach muss das Wasser wieder zurückgepumpt werden.
+== Entfernung ==
+Ein Hindernis wird auf einen Ultraschallsensor zu bewegt oder entfernt. Wenn es zum Stillstand kommt, ist die Entfernung zur Messeinheit das zu übertragende Byte. (Bzw. Volle Entfernung = 100% Farbwert, niedrigste 0%)
 === Alternative Übermittlung ===
 == Crypt/Decrypt ==
 Die Daten werden verschlüsselt (XOR(Data,"Warpzone"), oder so) und schickt es an die nächste Station. Dort werden die Daten nur verschlüsselt dargestellt und übertragen. Die Station danach entschlüsselt wieder und die Daten sind wieder lesbar.