monitor 1.9.0 - aber richtig :)

[mdi]

Moin,

Der Server läuft jetz... Mit derselben Konfiguration wie vorher, nur habe ich den Port jetzt einfach mal auf 111 gestellt. Telnet sagt mir:
110:monitord 2.0svn READY
Also bei mir nix 100. Weiß jemand woran das liegt das es auf den Standardports nicht läuft

die 100/110 habe ich ein Posting eher erklärt ;). Ich checks ein gleich...

Dass er nicht auf "seinem" Port läuft, ist komisch. Hast Du dahin auch mal per telnet connected?

Martin

[ToffiFee]

.

Dass er nicht auf "seinem" Port läuft, ist komisch. Hast Du dahin auch mal per telnet connected?

Klaro. Aber wie gesagt, alles dicht. Wenn ich per telnet auf 111 connecte kommt das protokoll richtig an, er decodiert richtig, die Befehle laufen usw. Habs grad mal mit Port 5000 probier (einfach mal irgendeinen zum Testen genommen, völlig random), da funktionierts auch. Keine Ahnung woran das liegen könnte, wie gesagt, firewall und son Schmarrn hab ich nicht ;)

Übrigens, kann mir jemand ein fähiges Webinterface empfehlen?

Gruß,

Bene

EDIT:
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 ;)

Aber son Webinterface interessiert mich dennoch ;)

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