| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | Nächste ÜberarbeitungBeide Seiten der Revision |
| projekte:datenreise [2012/04/10 16:36] – [Infrastruktur] macgoever | projekte:datenreise [2012/04/16 17:56] – [Infrastruktur] macgoever |
|---|
| |
| ==Frontend== | ==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. Toll wären: HTTP, FTP, SCP. Ggf noch SMTP zum Einschicken? Die einzelnen Stationen sollen einfach die Daten als Datei runterladen und als Datei wieder hochladen können. Jeder hat dann sein eigenes abgeschlossenes Homeverzeichnis, aus dem er auch nicht rauskommt. | 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: |
| Noch zu lösen: | * 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? |
| Dann noch das Problem mit den Dateinamen. Statisch wäre einfacher, birgt aber die Gefahr des Überschreibens. | * 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. |
| Und ein Upload ist leider keine atomare Aktion. Der Backenddienst könnte also in einen Upload reinpfuschen. Erst Upload und dann umbenennen ist ggf zu komplex? | * 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, das nix passiert. |
| | * 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. |
| ==Backend== | * Datenintegrität: Damit uns nicht irgendwelche Skriptkiddies Pornobilder in die Daten schieben, sollten wir eine minimale Überprüfung der Daten vornehmen. Die Größe der Daten sollte zumindest ungefähr passen (vielleicht +/-10%). Wenn ein gewisser Prozentsatz (70%) falsch ist, ist vielleicht auch eine 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. |
| Im Backend brauchen wir ein Script, das die Daten aus den Verzeichnissen klaubt. Dass darf natürlich nicht während eines Upload passieren. Die Daten sollen in eine Datenbank geschrieben werden. Daraus können dann die Daten/Statistiken für die Webseite zusammengebaut werden. Dann müssen die Daten auch in das Home der nächsten Station gelegt werden. Wann das passieren muss, ist auch noch zu definiern. | |
| | |
| ==Sicherheit== | |
| Da wir auch Externe einbinden möchten, müssen wir auch mit Scherzkeksen rechnen, die zB. große Files hochschieben oder Pornobilder in unser Landschaftsbild einbauen. Eine gewisse Plausibilitätsprüfung muss also ran. Vielleicht kann man sagen, ab 70% Bitfehlern auf einer Station (durch Injektion oder kaputte Station) kriegt sie dieselben Daten nochmal und beim 10ten Mal wird sie unter Generierung eines Alarms temporär aus dem Prozess ausgenommen und bekommt Dummydaten. | |
| ====Webseite==== | ====Webseite==== |
| Um das Projekt auch überregional bekannt zu machen brauchen wir natürlich eine Webseite. Dort wäre eine Karte nett, auf der alle Stationen verzeichnet sind. Bei Klick auf die Stationen kriegt man Infos über die Station: | Um das Projekt auch überregional bekannt zu machen brauchen wir natürlich eine Webseite. Dort wäre eine Karte nett, auf der alle Stationen verzeichnet sind. Bei Klick auf die Stationen kriegt man Infos über die Station: |