monitor 1.9.0 - aber richtig :)

[nepomuck]

Hier meine Vorlage zum Protokoll.

Danke für die Mühe und den Entwurf

Ich hätte da noch ein paar Punkte anzumerken:

Befehle 101,201 Error, Datenfelder 0
Ein Error ohne Beschreibung hilft in der Regel nicht weiter. Ich empfehle, dass wir dem Befehl ein Datenfeld mit einem Fehlercode anhängen und in der Protokolldefinition fehlercodes deklarieren, Beispiel:

101:001
Error:Server kann auf Sounddevice nicht zugreifen
101:034
Error:Benutzeranmeldung fehlgeschlagen
201:124
Error:Client unterstützt Protokollversion nicht

Dazu auch ein Vorschlag für ein weiteres Kommando:
111 Versionsnummer (Serverversion)
112 Protokollversion

Befehle 330,430 DTFM
Da sollten wir klären, ob wir diese Befehlsgruppe überhaupt brauchen. DTFM kommt sowieso nur in Verbindung mit einer ZVEI-Alarmierung vor, daher könnte man den DTFM-Code direkt mit der ZVEI-Alarmierung übertragen. Das hätte den Vorteil, dass der Client nach einem 5-Ton Alarm nicht eine gewisse Zeit warten muss, ob noch eine DTFM-Anweisung folgt oder nicht.

inklusive Trennzeichen und Zeilenende nicht länger als 512 Byte ist.

Da sollte bitte mal jemand, der sich mit FMS auskennt prüfen, wie lange Folgetelegramme sein dürfen. Da könnten 512 Byte evtl nicht reichen, vor allem, da wir die textmeldung hex codieren und daher pro character zwei Byte brauchen.

Andreas

[Fernmeldedienst]

Hallo!

Kann zwar leider nicht programmieren..

aber hätte da noch 2 Vorschläge...

das wäre zum einen die Einbindung des FMS-AuftragsText der Leitstelle

und zum anderen die Positionsmeldungen der einzelnen Fz an die Leitstelle via GPS (Stat 10)

73,

Daniel

[Dove]

ich möchte noch mal auf die datenbank anbindung ansprechen.
Wie wäre es wenn wir ein Modul schreiben das im monitord verankert ist das auf wunsch zu geschaltet werden kann.

Ich finde es einbischen umständlich wenn ich die daten in einer db speichern möchte, es über den deamon zu gehen das zu eines clienten zu schicken der das in eine Datenbank schreibt.

[Buebchen]

Fällt mir geradeso auf :Im TCP Protokoll fehlt noch ein Logout Kommando vom Client zum Server. Wäre im Bereich 2xx anzusiedeln. Ich würde 299 vorschlagen.

Wie soll ein Login eines Clients zum Server aussehen ? Erstmal im Klartext, richtig ? Also ungefähr so:

Server:
120:Please login !:

Client:
220:Harry:Hirsch:

Wobei "Harry" der User ist und "Hirsch" sein PW.

Danach käme dann

Server: 121:Login accepted:

oder

Server: 122:Login incorrect !:

Schließen wir die letzten Parameter mit ":" ab ? Ist in der PDF nicht ganz eindeutig. Aber sieht danach aus.

[Dove]

ich mit : am ende abschließen, damit man weiß, es ist wirklich zu ende.

Thema Login:
Ich würde das PW trotzdem irgendwie verschlüsselt rüberschicken. Sei es jetzt md5 oder base64 oder was auch immer.
Auch in der Probephase bzw Programmierphase

[MiThoTyN]

Hallo zusammen!

Habe momentan wenig Zeit, deswegen melde ich mich jetzt erst. Zu den ganzen Anmerkungen zum Protokoll:

@nepomuck

Die Sache mit dem Fehlercode ist gut. Das kann man als Datenfeld noch eintragen. Werd ich mal ins PDF aufnehmen.

111 als Version ist ja schon drinne. Eine Protokollversion ist auch sinnvoll. Den Befehl sehe ich auf beiden Seiten vor. Der Server teilt seine Protokollversionen mit und der Client bestimmt, welche genommen werden soll.

Ob DTMF drinne sein soll oder nicht hängt davon ab, ob der monitor ein reiner BOS-Auswerter sein soll, oder sich wie bisher durch die Module auch erweitern lassen soll. Dann kannste DTMF auch eigenständig laufen lassen. Der Sirenendoppelton wird beim ZVEI mit ausgegeben.

FMS-Text besteht aus maximal 99 Zeichen. Sagen wir 100 Byte. Als Hex 200 Byte. Bleiben 312 für den Rest. Langt dicke. POCSAG hat keine definitive Längenvorgabe, sollte aber auch dicke mit 512 Byte auskommen. Aber zur Not nehmen wir einfach 1024 Byte. Sollte halt Problemlos in den Zeilenpuffer des Frontend-Auswerters passen.

@Buebchen

Abschließender Doppelpunkt wird nicht benötigt. Die Zeile wird ja mit CR/LF abgeschlossen. Der Doppelpunkt trennt nur aufeinanderfolgende Datenfelder.

Solche Klartextübertragungen wie "Please login" sind eigentlich nicht nötig. Oder was meinst du? Ein Login sähe nach meiner Meinung z.B. so aus :

120
220:Harry:Hirsch
122

Passwort kann auch gerne verschlüsselt werden. Da die Passwörter auf beiden Seiten ja bekannt sind, kann man hier ne Einweg-Verschlüsselung nehmen und die beiden dann einfach miteinander vergleichen. Müssen wir nur jetzt im Vorfeld festlegen und uns auch auf eine Verschlüsselung einigen, die in vielen Programmiersprachen vorhanden ist. Oder wir lassen über einen zweiten Befehl auch das Anmelden im Klartext zu.

Logout Kommando wird auch noch eingefügt. Auch auf beiden Seiten. So kann auch der Server die Verbindung zum Client beenden.

Gruß Joachim

[nepomuck]

Die Sache mit dem Fehlercode ist gut. Das kann man als Datenfeld noch eintragen.

Mir fallen dazu spontan folgende Fehler ein:
Vom Server: Problem mit Soundkarte; Fehler in Konfig-Datei; Softwarefehler (kann Module nicht laden etc..); User ungültig; Passwort falsch; No anonymous Login(siehe unten); Netzwerkfehler; Server voll (evtl. Login-Limit)

Ping/Pong:
Ich würde einen Ping von beiden Seiten einrichten, so dass sowohl der Server als auch der Client die Verbindung überprüfen können. Dem Pong-Befehl sollte zudem als Datenfeld Datum und Uhrzeit der jeweiligen Maschine anhängen, dann können sich Client und Server synchronisieren.

Der Sirenendoppelton wird beim ZVEI mit ausgegeben.

Bei einer Sirenenalarmierung gäbe es also eine doppelte Ausgabe?
300:26250:1
330:1
Macht as Sinn?

Ein Login sähe nach meiner Meinung z.B. so aus :
120
220:Harry:Hirsch
122

Jagen wir da den Benutzernamen als ASCII durch? Oder bleiben wir dabei, dass wir Konsequent alle Textübertragungen Hex-Codieren?

Da die Passwörter auf beiden Seiten ja bekannt sind, kann man hier ne Einweg-Verschlüsselung nehmen

Das sollte genügen. Es müßte ja passende crypt-Funktionen geben, die als Output ein Hex-kodierten Code liefern.
Ich würde zudem vorschlagen, dass der Monitor-Daemon je nach Konfiguration auch anonyme Logins ohne PW zulassen kann.

Oder wir lassen über einen zweiten Befehl auch das Anmelden im Klartext zu.

Würde ich nicht. Entweder gleich anonym (für Server die ohnehin nur im Intranet laufen) oder mir sauber verschlüsseltem Hash. Da könnte man über die Konfigurationsdatei regeln, wer sich wie anmelden darf. Es könnte eine "Trusted-Hosts"-Liste geben mit IP-Adressen die anonym reinkommen während maschinen von außen sich anmelden müssen.

Andreas

[MiThoTyN]

Ping/Pong:
Ich würde einen Ping von beiden Seiten einrichten, so dass sowohl der Server als auch der Client die Verbindung überprüfen können. Dem Pong-Befehl sollte zudem als Datenfeld Datum und Uhrzeit der jeweiligen Maschine anhängen, dann können sich Client und Server synchronisieren.

Brauch man eigentlich nicht. Der Client prüft in regelmäßigen Zeitabständen die Verbindung. Das Ergebnis ist ja auch Aussagekräftig für den Server. Da muss der nicht auch noch den Client anpingen.

Die Uhrzeit zum synchronisieren würde ich damit nicht übertragen. Die Zeiten der Auswertungen werden bei der Datenübertragung selbst mitgesendet. Und Client und Server müssen ihre Zeit nicht über den monitor synchronisieren. Dazu gibt es bessere Wege und sollte auch standard sein mittlerweile.

Bei einer Sirenenalarmierung gäbe es also eine doppelte Ausgabe?
300:26250:1
330:1
Macht as Sinn?

Ja wie willst du das sonst machen? Der Sirenenton ist ein gültiger DTMF-Ton. Wenn also jemand das DTMF-Modul aktiviert hat, wird er so eine doppelte Anzeige bekommen. Was er damit im Endeffekt macht bleibt ja ihm überlassen. Richtig wäre es so auf jeden Fall.

Jagen wir da den Benutzernamen als ASCII durch? Oder bleiben wir dabei, dass wir Konsequent alle Textübertragungen Hex-Codieren?

Alles HEX-Codieren. Da sollte man in der Tat konsequent sein. Sonderzeichen kann es ja auch im Usernamen geben.

Würde ich nicht. Entweder gleich anonym (für Server die ohnehin nur im Intranet laufen) oder mir sauber verschlüsseltem Hash. Da könnte man über die Konfigurationsdatei regeln, wer sich wie anmelden darf. Es könnte eine "Trusted-Hosts"-Liste geben mit IP-Adressen die anonym reinkommen während maschinen von außen sich anmelden müssen.

Wäre ne Möglichkeit. Da der reine monitor-Server eh nur EIN Login hat und eine Benutzerverwaltung erst in der Datenbank geschieht. Es macht also Sinn zusätzlich zu dem einen Login auch eine Trusted-Host Liste anzulegen.

Gruß Joachim