monitor 1.9.0 - aber richtig :)

[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