monitor 1.9.0 - aber richtig :)

[Buebchen]

Die Angabe einer Länge finde ich überflüssig. Die Daten werden eh von Trennzeichen eingegrenzt. Die Längenangabe ist dann höchstens von Bedeutung, wenn der übergebene Text auf richtig übertragene Länge geprüft werden soll. Aber ob der Inhalt stimmt, kann man mit der Längenangabe nicht prüfen. Sinnvoller wäre es nach wie vor, über die komplette Zeile eine Prüfsumme zu bilden. Dann kann schon das Fehlen eines Bits erkannt werden.

Um das ganze richtig Fehlertolerant zu machen, könnte man noch jede Zeile mit einer eindeutigen ID versehen. Wenn der Client eine Zeile als Falsch erkennt (Checksumme oder Datenfeldgültigkeit), kann er diese Anhand der ID beim Server nochmal anfordern.

CRC und alles vergleichbare ist ein eine TCP Verbindung nicht sinnvoll. Sofern man nicht gerade Man-In-The-Middle Attacken erkennen will sorgt das TCP schon für den korrekten Transport der Daten.

Checksummen würden man bei eher bei RS232 Verbindungen wiederfinden. Gerade wenn ohne Handshake gearbeitet wird geht da öfters mal ein Bit verloren.

Ansonsten bin ich auf die ersten Protokollversion gespannt. History werde ich ermutlich nur über ein SQL Backend machen. Log-File parsen ist nichts, was ich für so richtig toll halte. Zumal man die auch noch rotieren muss ...

[MiThoTyN]

Die Sache mit dem Log finde ich auch nicht gut. Dann haste plötzlich auch auf Seiten des monitors eine Art Datenhaltung. Das soll ja eben vom monitor getrennt sein und dann von einer Datenbank übernommen werden. Im Endeffekt würd ich also auch sagen, dass der monitor-daemon sturr das weitergibt, was er auswertet. Basta. Um eine History-Funktion muss sich dann ein Client kümmern. z.B. eben die angesprochene mySQL Datenbank, die ja durchaus als Proxy zwischen dem monitor und den weiteren Clients sitzen kann.

Gruß Joachim

[nepomuck]

History werde ich ermutlich nur über ein SQL Backend machen. Log-File parsen ist nichts, was ich für so richtig toll halte. Zumal man die auch noch rotieren muss ...

Das würde zwangsweise eine MySQL-Datenbank im Backend erfordern. Das würde mir nicht gefallen, da ich dadurch Probleme mit der Live-CD bekomme.

Bislang kann "Bosix" monatelang von CD gebootet arbeiten, wenn es die LOGs sequentiell auf einen simplen USB-Stick schreiben kann. Die permanenten Änderungen an SQL-Tabellen würden das Union-Dateisystem von Knoppix schnell zum überlaufen bringen, so dass die Live-CD wahrscheinlich innerhalb von wenigen Tagen abstürzt.

Ich dränge immer noch auf ein Backend OHNE MySQL.

Das mit dem Logfile-parsen kann doch nicht so komplex sein, oder?

Andreas

[MiThoTyN]

Nene .. Da haben wir uns schon richtig verstanden. Das eigentliche Backend hat keine MySQL Anbindung. Diese würde ebenfalls per TCP angedockt. Der monitor als Backend übernimmt einzig und alleine die Dekodierung der Funksignale.

Das mit der Logdatei hat meiner Meinung nach zu viele Nachteile. Zum einen ist es echt komplex zu Handhaben. Dateioperationen können immer mal schief gehen. Du musst ständig auf die Datei zugreifen und erzeugst so haufenweise Festplattenzugriffe. Diese kann dann auch nicht in den Standbymodus gehen. Ohne Logdatei läuft der monitor rein im Arbeitsspeicher. Auch musst du die Logdatei rotieren und immer hinten ein Eintrag rauswerfen und vorne einen neuen anfügen. Dazu muss ständig die ganze Datei geladen werden, über nicht wenige Befehle rotiert und wieder gespeichert werden. Rein aus Performance- und Dauerlaufsicht ist ein Dateizugriff in der Form nicht wünschenswert.

Auch sind die Vorteile der Logdatei nicht überzeugend. Sicher ist es für ein Frontend ne feine Sache, wenn es auch Meldungen bekommt, die in der Vergangenheit liegen. z.B. wenn sich das Frontend neu verbinden muss, dann gehen die Meldungen in der Zwischenzeit nicht verloren. Aber was passiert, wenn der monitor selbst mal ne Zeit ausfällt? Dann hast du in den Logdateien noch alte Daten drinne stehen, auf die dann brandneue Daten folgen. Diese werden dann an ein Frontend weitergegeben. Das hat dann plötzlich uralte Daten drinne. Man kann also auch nicht garantieren, dass die Daten aus der Logdatei nicht schon unsinnig sind. Es sei denn man bohrt das entsprechend auf und verwaltet das nach Uhrzeit und alles. Aber das ist ein riesen Aufwand, diesen Datenbestand sinnvoll aktuell zu halten. Und DAS wiederum ist nicht Aufgabe des monitor als solches. Wie gesagt bin ich durchaus für so eine komplexe History. Nur eben als Teil der Datenbank, wo sämtliche Daten eh gespeichert sind.

Gruß Joachim

[nepomuck]

OK, History entfällt im Backend -> Aufgabe des Frondends.
Das gilt dann auch für den Fahrzeug Status via FMS?

Andreas

[jhr-online]

OK, History entfällt im Backend -> Aufgabe des Frondends.
Das gilt dann auch für den Fahrzeug Status via FMS?

Andreas

Ich denke ja; der jeweils aktuelle Status sollte auch aus der DB erfragt werden.

jhr

[Buebchen]

Ne Ne Ne ... Warum nicht ein externer DB-Server ? Auch die logfiles muss er irgendwo hinschreiben. Da würde CD-Boot auch nicht gehen, bzw. es wäre fast das gleiche.

Mein Vorschlag: Es gibt eine Option für den Backend-DB Server. Entweder ist er aktiv oder nicht. Danach kann man immer noch klären welche Daten die Clients dann vom monitord anfordern können oder nicht. Ggf. können die Clients auch einfach selbst auf dem DB Server zugreifen. Das kann dann jeder Entwickler selbst entscheiden.

Eine Zwischenstufe (TCP Client speichert in DB) wäre denkbar. Aber es ist m.E. nicht sinnvoll, daß die Clients selbst die Daten speichern müssen. Was macht man, wenn man eben erst den Client startet ? Man hätte keine aktuellen Statusinformationen zu den Fahrzeugen. Aber alle in die "6" oder "2" zu stellen ist auch nicht richtig.
Gerade bei der Nutzung in einer nachbesetzten Führungsstelle ist das eine wichtige Information ("Welche Fahrzeuge sind ausgerückt - und wann ?").

[nepomuck]

Es gibt eine Option für den Backend-DB Server. Entweder ist er aktiv oder nicht.

Folgende Idee, um das Problem zu lösen.

Der eigentliche Backend hat selbst keine DB und schreibt seine Daten per Default in ein klassisches LOG. das kann man auch abschalten.

Es gibt ein SQL-Modul, welches sich regulär per TCP beim Frontend anmeldet und die Auswertungen per ODBC in irgend eine eine SQL-Db schreibt.
Das SQL modul kann auf dem Backend Server oder irgend einer Maschine im LAN arbeiten. Ebenso kann die Db sein wo sie will.

Eine History-Query muss ein Client an das SQL-Modul stellen.
Da sich das SQL-Modul beim Backend anmeldet, kann ein Client-Task bem backend danach fragen und bekommt als Antwort die IP-Adresse des SQL-Moduls.

123 SQL
234 NOPE

oder

123 SQL
234 192.168.23.65:1234

Vorteil: Die DB ist kein zwingender Bestandteil des backends. Falls die DB ausfällt oder der entfernte sql-server nicht antwortet, funtioniert das Backend regulär weiter.

nachteil: Ein Client der Live-Daten und alte daten auswerten will, muss sich mit zwei TCP-Sitzungen mit dem backend und dem SQL modul verbinden. ausserdem müssen wir ein zweites protokoll zur kommunikation zwischen frontend und sql modul entwickeln.

das hat im gegenzug den vorteil, dass ein task der db-auswertungen mit viel sql-traffic ausführt nicht den backend kanal belastet.

Andreas

[Buebchen]

Das geht schon eher so in die Richtung, die ich mir vorstellen könnte.

Das TCP->SQL Modul wäre zwar nicht mein Lieblingsding aber durchaus ok. Dadurch könnte man vor allen Dingen noch ein anderes Problem erschlagen, daß mir in der Praxis schon begegnet ist:

Was macht man, wenn man im Gerätehaus auf einigen Kanälen schlechten Empfang hat ? Richtig: Von einem besseren Standort die ausgewertete Daten holen. Man könnte also in einer Datenbank durch zwei oder mehr solcher Agenten Daten mehrerer monitord sammeln.

Müßte man noch klären, wie die Benutzerdaten verwaltet werden. Ich hatte bisher einfach gegen MySQL Anmeldung geprüft. Konnte man er sich mit den Daten am mysql anmelden (nur als Prüfung), war man auch am "monitord" angemeldet. Der Client konnte sich dann auch am MySQL anmelden (bekam er ähnlich wie nepomuck schon schrieb dann mitgeteilt, wo dieser MySQL zu finden ist).

Hier wäre dann auch direkt das Problem des externen Zugriffs: Hat der MySQL Server eine LAN IP aus Sicht des monitord nützt diese IP einem von aussen (ohne VPN) zugreifenden Client nichts. Man müßte in letzter Instanz auch über ein "masquerading" nachdenken (Fern-Fern-Fernziel).

Ach so:

Vorteil: Die DB ist kein zwingender Bestandteil des backends. Falls die DB ausfällt oder der entfernte sql-server nicht antwortet, funtioniert das Backend regulär weiter.

nachteil: Ein Client der Live-Daten und alte daten auswerten will, muss sich mit zwei TCP-Sitzungen mit dem backend und dem SQL modul verbinden. ausserdem müssen wir ein zweites protokoll zur kommunikation zwischen frontend und sql modul entwickeln.

Nachteil aus meiner Sicht wäre auch, wenn der monitord zwar läuft ich aber im Fall der Fälle keine Auswertungen der Daten machen kann, da der SQL-Agent sich weggehängt hätte.

Ich schaue weniger in die Auswerter aus Neugierde. Eher im Auswertungen zu fahren (Bsp: Ausrückzeiten, Eintreffzeiten) oder Doku zu schreiben.

Als Protokoll zum Backend würde ich vorläufig mysql-Tools nehmen und direkt auf den Server zugreifen. Alles andere ist ggf. schon wirklich komplex. Gerade wenn auch noch Performance dahinter sein soll. Benutzername und PW dafür sind noch zu klären (dynamisch oder static ...)