monitor 1.9.0 - aber richtig :)

[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