monitor 1.9.0 - aber richtig :)

[nepomuck]

Warum ist ein 100 ...ready unzulässig ?

Wir hatten und bei der Protokolldefinition auf etliche Standards geeinigt:
- Alle Kommandos und Quittungen sind rein nummerisch, Parameter sind durch ":" getrennt und, falls alphanummerisch, in Ascii codiert.
- Das Kommando "100" ist nicht mehr als eine positive Quittung auf ein vom Client abgesetztes Kommando. Laut unserem Standard gibt es bei "100" einfach keine Folgeparamter.

Folglich ist "100 Version xyz Ready" eine unzulässige Antwort.

Für die Beta-Versionen ist sowas ganz nett, da man viel mit einem Telnet-Client arbeitet und sehen will, was los ist. Aber wenn die ersten, richtig funktionellen Forntends da sind, müssen sich die Backend- und Frondend-Entwickler exakt an die Protokolldefinition halten -- sonst wird das ganze nicht funktionieren.

Aber wir können da auch gerne einen anderen Code nehmen - Sozusagen für die welcome message

Das Thema hatten wir schon einmal und haben uns damals gegen eine "lesbare" Welcome-Message entschieden, da ein trockenes "100" als positive Verbindungsbestätigung völlig ausreicht. Und für den Austausch der exakten Versionsinformationen haben wir deshalb das Inquiry-Kommando (210 vom Client an den Server oder 110 vom Server an den Client) mit einer mehrzeiligen Antwort festgelegt. Wobei die Klartextmeldungen Ascii codiert werden müssen.

Ich zitiere das Protokollmanual:

Beispiel (in allen Beispielen wird der Text zwecks der Lesbarkeit in „“ angegeben, statt in ASCII
kodiert):
     210 (=Inquiry-Anforderung vom Client)
     111:1:“monitord“ (sieht in wirklichkeit so aus: 111:1:6D6F6E69746F7264)
     111:2:“LINUX“ (111:1 = Name des Servers, 111:2=OS des Servers 111:3 = Version )
     111:3:0021
     111:4:0010
     111:4:0020 (111:4 = unterstützte Protokollversionen)
     111:4:0021
     111:5:"REC" (111:5 = unterstützte Module dieses Servers) 
     111:5:"MYSQL"
     111:0

Alle Programmierer müssen sich an die Protokollstandards halten. Wenn jeder eigene Protokollvarienten implementiert, wird die Kommunikation zwischen Client und Server einfach nicht funktionieren.

viele Grüße,
Andreas

[Buebchen]

Wenn ich das mal so sagen darf:

1. Ich sehe zum einen kein Frontend, daß in absehbarer Zeit zur Verfügung steht
2. Das aktuelle Frontend muss zwangsläufig mit diesem Protokollbruch schon umgehen können, um zu funktionieren. Demzufolge ist es mehr Aufwand die Programme an das Protokoll anzupassen als andersherum.

[nepomuck]

Das aktuelle Frontend muss zwangsläufig mit diesem Protokollbruch schon umgehen können, um zu funktionieren. Demzufolge ist es mehr Aufwand die Programme an das Protokoll anzupassen als andersherum.

Wozu haben wir uns dann überhaupt auf einenen Protokollstandard geeinigt, wenn sich keiner dran hält?

Client/Server-Applikationen können nunmal nur dann richtig funktionieren, wenn das Protokoll eindeutig vorgegeben ist und sich alle daran halten.

Natürlich können wir jederzeit eine neue Protokollversion 0.4 deklarieren, welche diese Änderungen berücksichtigt.

Ich sehe darin aber keinen Sinn. Warumm sollte der Server klar lesbare Meldungen von sich geben? Das Ziel dieser ganzen Entwicklung ist es doch, dass Client-Tasks mit dem monitord kommunizieren und nicht die Anwender per Telnet die Kommandoausgabe verfolgen, oder?

Dein Änderungswunsch hebelt gleich mehrere Syntaxregeln aus, auf die wir an dieser Stelle vor etlichen Monaten gemeinsam geeinigt hatten:
Dazu gehört, dass Paramter mit ":" getrennt sind und dass wir keinen Klartext übermitteln. Zudem haben alle Kommandos klar deklarierte Paramter. Woran soll der Client erkennen, wann ein OK mit oder ohne Paramter daher kommt und was soll er überhaupt damit anfangen?

Willst du du diese durchaus durchdachten Syntaxregeln auf den Kopf stellen, nur damit der Server freundlich "Hallo" sagen darf?

Ich persönlich halte das für einen absolut kontraproduktiven Vorschlag, weil es die Programmierung von Frondends verkompliziert und das Fehlerrisiko bei der Kommunikation zwischen Client und Server erhöht.

Ich möchte einen Gegenvorschlag machen:
So lange das hier alles im Beta-Stadium ist, fügen wir dem Protokoll zu Debug-Zwecken eine Art Kommentarfeld hinzu:
Am Ende eines Kommandos kann ein ";" als Trennzeichen kommen und dahinter steht, was immer du auch möchtest. Die Client-Entwickler können sich darauf einstellen und einfach alles, was nach dem ";" kommt ignorieren.

Beispiel:

S->C nach Verbindungsaufbau
100;Hallo von CVS 0.5.6a-xy auf Debian
C->S
220;sag mir, wer du bist
111:1:6D6F6E69746F7264;CVS 0.5.6a-xy auf Debian
....

Dann haben wir den freundlichen "Hallo" ohne das Protokoll zu vermurksen. Bei Erreichen einer Final-Release können wir das Kommentarfeld einfach sausen lassen, ohne dass die Clients umprogrammiert werden müssen.

Ist das ein akzeptabler Vorschlag?

viele Grüße,
Andreas

[Buebchen]

Hmm. Ich sollte so spät keine Postings schreiben ... Irgendwie klingt das etwas sehr "unfreundlich". Sorry dafür.

Zum Thema:
Generell halte ich ";" für sehr sinnvoll und würde es auch im Final drin lassen. Der Grund ist einfach. Wenn man mal debuggen will kann der arme Programmierer schneller erfassen, was da geschieht. Das ist ja auch der Grund warum eben bei einem täglich millionenfach genutzten Protokoll wie SMTP solche Ausgaben immer noch vorhanden sind.

Selbst SSH beginnt übrigens mit einer Klartextmeldung. Das soll nur verdeutlichen, daß ich nicht der einzige verirrte Geist bin der glaubt, daß menschenlesbare Meldung einen Nährwert haben können :-)

Also dann lass uns das so machen, daß Meldungen mit einem ";" noch einen lesbaren Kommentar bekommen können. Ich finde das eine sehr gute Lösung. Prima !

[mdi]

Moin,

Also dann lass uns das so machen, daß Meldungen mit einem ";" noch einen lesbaren Kommentar bekommen können. Ich finde das eine sehr gute Lösung. Prima !

hm... grundsätzlich fällt mir spontan kein echtes Gegenargument ein (außer dass das halt die sonstige Trennung am Doppelpunkt ein wenig verwurstet). Ein optionales Protokoll-Feld mit Doppelpunkt-Trennung ist aber nicht so günstig falls mal Felder hinzukommen, von daher trennt das ; einen Kommentar eindeutig.
Also: [x] - nicht dagegen.

Ich möchte kurz noch einen Verweis hier einbringen: Ich habe einen neuen Thread hier im Forum erstellt mit der Bitte um Kommentare -> http://www.funkmeldesystem.de/foren/...ad.php?t=39572 (Thema: Aktueller Stand der Dinge?). Würd mich über hilfreiche Antworten freuen :)!

Viele Grüße
Martin

[nepomuck]

Irgendwie klingt das etwas sehr "unfreundlich". Sorry dafür.

Nix passiert.

Also dann lass uns das so machen, daß Meldungen mit einem ";" noch einen lesbaren Kommentar bekommen können.

OK. Ich füge das so in die Protokolldeklaration (ab sofort 0.3a) ein.

Kommentar:
Ein ";" am Ende eines Kommandos signalisiert einen Kommentar. Dieser folgt im Klartext, darf aber keine Sonderzeichen (0x00 - 0x19) enthalten.
Bis zum ";" haben wir den "maschinenlesbaren" Teil, wie bereits in Protokollversion 0.3 festgelegt, danach folgt der "menschenlesbare" Kommentar. Das ";" steht auf jeden Fall am Ende eines Komandos nach allen Parametern.
Ein ";" kann jedem Befehl anhängen, muss das aber nicht.

Ich habe einen neuen Thread hier im Forum erstellt mit der Bitte um Kommentare -> http://www.funkmeldesystem.de/foren/...ad.php?t=39572 (Thema: Aktueller Stand der Dinge?). Würd mich über hilfreiche Antworten freuen :)!

Ich crossposte die Protokolländerung dort. Dann sieht's hoffentlich jeder.

viele Grüße,
Andreas

[nepomuck]

Ich füge das so in die Protokolldeklaration (ab sofort 0.3a) ein.

Murks! Eine Versionsnummer 0.3a läßt sich natürlich nicht wie vorgesehen mit dem Inquiry-Kommando übermitteln!.
Also: Aktuelle Protokollversion = 0.4, was beim Inquiry dann so aussieht: "111:4:004"

viele Grüße,
Andreas