monitor 1.9.0 - aber richtig :)

[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