monitor 1.9.0 - aber richtig :)

[funkwart]

@funkwart
Auch recht. Aber der Doppelpunkt kommt wenn, dann nur in Textmeldungen vor und die sind dann entweder in Hochkomma gestellt oder Hex Dekodiert
[...]
- gibt es eine "private" kommunikation zwischen server und client oder nur einen multicast vom server aus

Andreas

Zum ersten Punkt: Stimmt, wenn es denn so einfach ist, das auseinander zu halten, meinetwegen. Trotzdem wäre es doch in Ordnung, ein Zeichen mit noch geringerer Auftet-Wahrscheinlichkeit zu wählen.
Zum zweiten Punkt: Ich denke, es sollte schon eine Identifizierung bzw. Authentifizierung von Clients geben, somit müssen diese ja zwangsläufig mit dem Server kommunizieren. Ich weiß, dass das keine Sicherheit darstellt, weil Klartext-Übermittlungen ohne Probleme mit einem Sniffer mitgelesen werden können, aber es ist zumindest nicht so einfach, nur einen Client zu starten, die monitor-Server-IP zu geben und lustig alles mitzulesen.

Gruß,
Funkwart

[jhr-online]

Wir können die Daten auch gpg-verschlüsseln... *SCNR*

jhr

[Dove]

kurze frage.

sind daten wie auf welchem kanal das signal anlag für das frondend interesant ?
Ich finde nicht. Ich finde das sowas auch weg gelassen werden könnte, oder nicht ?

[MiThoTyN]

Doch das ist sehr wichtig. Weil du 2 verschiedene Funkkanäle pro Line-Eingang auswerten kannst. Also muss das Frontend auch wissen, von welchem Kanal die Auswertung stammt.

Zum Datenformat selbst noch was grundsätzliches. Die Länge pro Zeile und pro Datenfeld sollte minimiert gehalten werden. Diese Datenzeile muss vom Menschen nicht gelesen werden können. Auf Klartexte wie bei den DTMF-Tönen FEUER, PROBE und sowas kann man also verzichten. Eher sollte man solche starren Werte einfach mit Nummern belegen. Also 1=Feuer, 2=Probe und so weiter. Verringert erstens die Datenmenge und lässt sich im Frontend leichter auf Richtigkeit überprüfen, denn das Feld mit dem Sirenenton hat dann einfach einen Gültigkeitsbereich von 1 bis 6 (z.B.).

Auch sollten die Befehle kategorisiert und nummeriert werden. Bsp:

100er : Steuerbefehle von Server
200er : Steuerbefehle vom Client
300er : FMS
400er : ZVEI
500er : POCSAG

usw.

Texte würde ich in der Tat gleich Hexadezimal übertragen. Vergrößert zwar die Datenmenge, erledigt aber alle Probleme mit Steuerzeichen im Text. Diese müssen dann nicht erst einzeln durch entsprechende "harmlose" Synonyme ersetzt werden.

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.

Ein paar Zeilen Daten zur Anschauung :

(§=Trennzeichen //=Kommentar für euch)
XXX- (Mit Bindestrich: Daten nach Befehlsnummer nur zur Info)
XXX (Ohne Bindestrich: Daten nach Befehlsnummer zum Bearbeiten)

// 100 Server Identifikationssting
100 monitord
// 101 Server Versionsstring
101 V1.20
// 200 Client Identifikationsstring
200 Jogis Super Frontend // 200
// 201 Client Versionsstring
201 V3.40
// Client will Protokollversion MON3
202 MON3
// Server stimmt zu
202 MON3

103-Login
203 username§passwort
104-Login correct

// 111 Server Kanal links§rechts
111 kanal501§rettungsdienst
299-OK

// ZVEI Auswertung Kanal§Folge§Doppelton$timestamp
400 1§67223§1§071102192233
299-OK

400 1§67223§1§98733,,,,,,, (Fehler)
298-ERR

Usw usw .... Wenn ich mal ne Stunde ZEit hab heute Abend, kann ich mal bischen Gehirnschmalz da reinstecken. Also ich entwickel mal ne erste Protokollversion und leg die hier zur Ansicht vor.

Gruß Joachim

[nepomuck]

@funkwart;@jhr-online
Ich glaub, dass abhörsicherein ein Feature mit niedriger Priorität ist. Eine künftige Version könnte das Monitor-Protokoll via SSL übertragen.

@MiThoTyN
Auch eine gute Idee, wobei ich glaube dass es bei der Datenübermittling nicht auf jeden einzelnen Charakter ankommt und ein im Klartext lesbares Protokoll bei Debugging hilft.

Dein Protokoll setzt ein Login voraus und legt damit fest, dass jeder Client über einen eigenen Kanal mit dem Server spricht. Das ist auf jeden Fall die sauberere Variante als ein one-way Multicast. Ich hoffe, dass es kein zu großer Aufwand beim Programmieren des Backends wird.

Vorschläge
Ich würde in das Protokoll auch noch eine Art "Ping" integrieren, damit der Client/Server von Zeit zu Zeit die Verbindung prüfen kann.

Beispiel:
297 Alive
199 OK
oder
197 Alive
299 OK

Vieleicht wäre es auch ganz nett, eine History-Funktion einzubauen, so dass ein Client beim Start die letzten Ereignisse nachfragen kann

123 lastevents 10
401 1§26100§0§datetime (0 ist ohne DTFM also Melderauslösung)
401 1§26250§1§datetime
401 1§26380§1§datetime
401 1§26433§0§datetime
401 1§26104§0§datetime
499 END
299 OK

und für FMS wäre natürlich wichtig, dass der Client nach dem Start den aktuellen Fahrzeigstatus der Flotte abfragen kann:

147 fmsstat
501 63117214§6§datetime
501 63117215§7§datetime
501 63117256§1§datetime
501 63117603§1§datetime
...
599 END
299 OK

Vieleicht würde es den Entwicklern zudem helfen, einige Testkommandos einzubauen:

222 test§1§zvei§12345§1
400 1§12345§1§datetime

Andreas

[MiThoTyN]

Diese "History-Funktion" wollte ich auch noch ansprechen. Das ist was, was man im Vorfeld auch abklären muss. Die Frage ist, ob diese History vom Auswerter kommt. Eigentlich könnte es auch aus einer Datenbank kommen. Da aber der monitor selbst keine Datenbank ansprechen soll, muss die History aus einem Speicher-Puffer kommen. Dieser kann dann natürlich nicht beliebig groß sein und die Anzahl der enthaltenen Datensätze muss begrenzt sein.

Theoretisch müsste man pro Signal-Art (ZVEI, FMS, POCSAG) einen eigenen Puffer bereithalten. Bei FMS macht es sogar Sinn, zwei getrennte Puffer vorzuhalten. Einen mit den letzten X Telegrammen (chronologisch geordnet) und einen mit dem aktuellen Status pro bekannter Kennung (nach Kennung geordnet).

Das ist aber meiner Meinung nach was, was in eine Datenbank gehört, bzw aus einer Datenbank kommen muss.

Wie sind die Meinungen dazu? Monitor doch gleich mit Datenbankanbingung bauen? Andere Möglichkeiten?

Gruß Joachim

[nepomuck]

Da aber der monitor selbst keine Datenbank ansprechen soll, muss die History aus einem Speicher-Puffer kommen.

Das stelle ich mit einfacher vor. Das Backend kann wie bisher eine LOG-Datei schreiben. Die enthält die "rohen" Codes, so wie sie auch über das Netz übertragen werden.
Ein History-Query kann des Backend dann ganz einfach aus den letzten Zeilen der LOG-Datei beantworten.

Mann kann diese Funktion ja darauf beschränken, dass der Client nicht explizit irgendwelche Services abfragen kann, so dass das Backend ihm einfach die geforderte Zahl an Zeilen aus dem LOG übermittelt.

Auswerten muss dann das Frontend -- aber dafür ist es ja sowieso konzipiert.

Für FMS könnte mann theoretisch ein Status-LOG generieren. Da schreibt das Monitor-Backend einfach sequentiell alle Status-Meldungen (Fahrzeug, Status,Uhrzeit) rein.
Vor jedem Eintrag prüft das Backend, ob das entsprechende Fahrzeug schon in der Liste steht und löscht einfach die Zeile mit dem alten Eintrag, bevor er den neuen anhängt.

Andreas

[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