monitor 1.9.0 - aber richtig :)

[mdi]

Moinmoin,

Es geht! Man weiss nicht warum, aber nachdem ich den Port nochmal auf 9333 gesetzt habe laeuft es. Verdammt, ich versteh das nicht, aber mir egal, er läuft =)
Danke Danke Danke für alle vergeblichen versuche mir unter die Arme zu Greifen, manchmal bedarf es eben einer höheren Macht ;)

wem sagst du das... ;D!

Aber son Webinterface interessiert mich dennoch ;)

Dazu gab es hier im monitor-Forum auch schon einige Diskussionen; wie weit die aktuellen Vorhaben derzeit sind, kann ich Dir nicht genau sagen - im SVN gibts aber auch ein Web-Frontend zu finden (PHP).

Find ich jetzt zwar schade, denn das bringt mir den gesamten Login Vorgang durcheinander, macht aber auch mehr Sinn.

Ja, das glaube ich Dir aufs Wort :7. Tut mir leid.

Inquiry ist Sinnvoll in so fern, dass der Server abwärtskompatibel ist und auch mit älteren evtl. nicht mehr gepflegten Programmen zusammenarbeiten kann. Dazu müssen sich die beiden halt auf eine Protokoll Version einigen und das geht dann nur per Inquiry.

Ja sicher, nur ist die Frage: Warum sollte der Server den Client fragen, was der kann? Dass der Client den Server fragt und dann sagt, er möchte mit Version xy sprechen, ok. Aber dass der Server den Client fragen kann und/oder sollte, hat mich grad verwirrt ;).

Viele Grüße
Martin

[nepomuck]

Moinmoin,
Ja sicher, nur ist die Frage: Warum sollte der Server den Client fragen, was der kann? Dass der Client den Server fragt und dann sagt, er möchte mit Version xy sprechen, ok. Aber dass der Server den Client fragen kann und/oder sollte, hat mich grad verwirrt ;)
Martin

Strenggenommen sollte das eigentlich aussehen:
Wenn die Verbindung steht, sendet der Server ein nacktes 100 als OK, ohne Versionsnummer oder Sonstwas, denn der Befehl 100 hat keine Parameter.

Der Client soll dann einen 210 (inquiry vom Client) an den Server schicken, welcher als Antwort mehrere 111er liefert und dem Client so mitteilt, was der Server alles kann.

Der Server könnte im Gegenzug vom Client ein Inquiry 110 einfordern, auf das der Client mit 211ern antwortet. Diese Funktion ist dafür gedacht, falls jemand auf dem Server eine Liste aktuell angemeldeter Clients verwalten will. Soweit ich weiss, ist das Feature aber im server noch nicht implementiert.

Danach soll von Seiten des Clients der Login "220" erfolgen, der als Paramter den Usernamen, das Passwort und die gewünschte Protokollversion enthält.

Aktuell arbeiten die Test-Setups ohne Logins und daher antwortet der Server momentan direkt mit 100 und Version -- das ist strenggenommen so nicht zulässig.

Die Protokolldefiniton 0.3 berücksichtigt den Sonderfall "Autologin" nicht -- hier sollten wir uns überlegen, wie wir das künftig korrekt handhaben.

viele Grüße,
Andreas

[Buebchen]

Warum ist ein 100 ...ready unzulässig ? Im Grunde genommen wird der TCP Connect damit bestätigt. Aber wir können da auch gerne einen anderen Code nehmen - Sozusagen für die welcome message ( Vgl. SMTP: "220 Server ready" - nach dem connect ).

Was genau beim bind geht muss ich nachsehen. Ich meine im Moment gehen ausschließlich IP Adressen. Ggf. noch hostnamen. Interfacenamen aber bestimmt nicht. Wäre auch nicht unter windows und Unix kompatibel in dem Fall.

[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 !