Zitat Zitat von MiThoTyN
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.
Zitat Zitat von MiThoTyN
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?

Zitat Zitat von MiThoTyN
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?

Zitat Zitat von MiThoTyN
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.

Zitat Zitat von MiThoTyN
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