monitor 1.9.0 - aber richtig :)

[jhr-online]

Mal wieder was pragmatisches ;)
Wenn ich das richtig überblicke, haben wir derzeit folgende Aktive (alphabetisch):

A.Nero
Buebchen
Dmitri_P
Dove
jhr-online
ManuelW
Max K.
MiThoTyN
nepomuck
Paneologe
SirFS

Ich fänd's total supi (*g), wenn mir alle kurz eine PN o.Ä. schicken könnten, in der sie mir ihren RL-Namen verraten und in zwei Stichworten kurz sagen könnten, was sie beitragen können/wollen. Danach bitte im BTS registrieren und ich trage euch als Developer ein, sodass ihr Aufgaben verändern und zuweisen könnt etc.
Ich will nicht zu viel Bürokratie hier einbringen, aber es wäre schon schön, einmal zu sammeln, was man für Potential hat. Dann mache ich einen groben Überblick fertig über das, was gemacht werden muss, und die, die es könnten.

Einverstanden?

[nepomuck]

ich würde von XML in der Datenübertragung weg gehen und ein eigenes "Protokoll" schreiben. D.h. Zeichenketten als Trennzeichen. Es sollte ein Start und Stop und Trennzeichen geben.

Das halte ich für eine gute Idee.

Vorschlag:
Wir legen zuerst die Datenfelder und die Reihenfolge fest, wie die Infos vom Backend aus gesendet werden. Beim Trennzeichen müssen wir uns auf was einigen, was nicht in der Meldung vorkommen kann, wie ":". Evtl. sollten wir Texttelegramme in Hochkomma stellen. Alles, was nicht in Hochomma steht ist nicht case-sensitiv. Alle Kommandos sollten möglichst eindeutig sein, dass sich auch fragmente einer Übermittlung zuweisen lassen. In FMS-Textmitteilungen dürfen Steuercodes drin sein. Wir könnten entweder das Telegramm gleich in Hex-Codes übermitteln (und uns die Hochkomma sparen) oder die Steuerzeichen in Spitzklammern angeben.

1. Servername
2. Kanal, Werte L oder R
3. Dienst, Werte ZVEI,FMS,POCSAC,TEST (sonstige?)

ZVEI:
4. Schleife
5. DTFM-Auswertung, Werte OHNE, FEUER, PROBE, WARNUNG, ENTWARN, ZIVIL
6. Abschlusmeldung "ZVENDE" (oder wie wärs mit "HABEFERTIG" :-)

Beispiel:
monitor1:L:ZVEI:12345:FEUER:ZVENDE

FMS:
4. Meldung
optional 5. Wenn ein Folgetelegramm kommt, steht hier TEXT
optional 6. Folgetelegramm in Hochkomma
5,6 oder 7. Abschlussmeldung "FMSEND"

Beispiel:
server07:R:FMS:631172141000:FMSEND
monitor1:R:FMS:631172140000:TEXT:"Kardio{CR}Hauptstrasse 5{CR}Huber{EOT}":FMSEND
(Spitzklammern kriege ich im Forum nicht hin, daher sind hier geschweifte abgebildet)
- oder -
monitor1:R:FMS:631172140000:TEXT:4B617264696F13486 17570747374726173736513487562657204:FMSEND

POCSAC:

damit kenne ich mich nicht aus.

was haltet ihr davon?

Andreas

[nepomuck]

1. Servername
2. Kanal, Werte L oder R

Ooops, fast vergessen:

1. Server,
2. DATUM/UHRZEIT YYMMDDHHMMSS
3. Kanal ....

also

monitor1:070417034312:ZVEI:26250:FEUER:ZVENDE

[funkwart]

Die Idee ist gut, aber bei der Auswahl des Zeichens solltet Ihr nochmal gründlich überlegen: Ein Doppelpunkt kann durchaus in Meldungen vorkommen, sogar einigermaßen häufig. Am besten etwas wie § oder ° oder | oder µ oder oder oder nehmen, irgendwas, das mit großer Sicherheit nicht auftaucht. Vielleicht sogar eine Kombination wie §*§ oder §°§.
Ihr findet da schon etwas.

Gruß,
Funkwart

[Buebchen]

Wir wäre sonst das Konzept, daß auch früher auf dem Amiga mal "IN" war (Bstrings): Da ist das erste Byte ein Längenbyte. Man könnte vor jedem Text dann einfach die Länge vorher angeben. Wäre sogar resistent gegen Nullbytes.

....:050:{50-zeichen}:....

[Dove]

Die Idee ist gut, aber bei der Auswahl des Zeichens solltet Ihr nochmal gründlich überlegen: Ein Doppelpunkt kann durchaus in Meldungen vorkommen, sogar einigermaßen häufig. Am besten etwas wie § oder ° oder | oder µ oder oder oder nehmen, irgendwas, das mit großer Sicherheit nicht auftaucht. Vielleicht sogar eine Kombination wie §*§ oder §°§.
Ihr findet da schon etwas.

Gruß,
Funkwart

es würden ja auch mehrere trennzeichen genommen werden: §§§ oder so.

das Datum würde ich als datetime übertragen also als unix timestamp.
damit kann man ab besten arbeiten und überall verwenden.

[nepomuck]

@funkwart
Auch recht. Aber der Doppelpunkt kommt wenn, dann nur in Textmeldungen vor und die sind dann entweder in Hochkomma gestellt oder Hex Dekodiert
@Buebchen
Das Längebyte könnte man in die TEXT-Anweisung einbauen, also: ...FMS:1234567890ab:TEXT(5):6520136565:...

Die Fragen sind

- brauchen wir weitere Felder?
- darf der Cllient was zu Server senden und wenn ja was?
- gibt es dafür einen eigenen TCP-Port oder läuft alles über einen?
- gibt es eine "private" kommunikation zwischen server und client oder nur einen multicast vom server aus

Andreas

[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 ...