Und gleich nochmal was...
Der Server sendet jetzt zur Begrüßung ein "100" ['100', 'monitord 2.0svn READY']
Früher hat er ein "110" gesendet!
Ist das gewollt?
Gruß
HP
Member
Und gleich nochmal was...
Der Server sendet jetzt zur Begrüßung ein "100" ['100', 'monitord 2.0svn READY']
Früher hat er ein "110" gesendet!
Ist das gewollt?
Gruß
HP
Newbie
Aaaalso:
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?
Gruß,
Bene
Advanced Member
Moin,
fuck, hatte ich hier zu schreiben vergessen und auch nicht im SVN eingecheckt sondern nur lokal bei mir geändert und aus den Sourcen den Installer gedreht.Zitat von HeckenPenner
Ja, das ist so gewollt, jedenfalls von mir und ich sollte das mal ins SVN einchecken. 110 ist laut Protokoll-Defnition "Inquiry" und nicht "OK". Daher muss hier eine 100 hin.
Martin
PS (edit): Noch was zum Inquiry, ist es überhaupt sinnvoll, dass der Server ein inquiry macht? Normalerweise muss der Client ja den Server connecten und fragen, was er kann und schauen, ob das zu seinem Befehlssatz matcht. Wenn nicht... pech ;).
Geändert von mdi (07.08.2008 um 15:20 Uhr)
Advanced Member
Moin,
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
Newbie
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 ;)
Geändert von ToffiFee (07.08.2008 um 16:06 Uhr)
Member
Ok, danke!
Find ich jetzt zwar schade, denn das bringt mir den gesamten Login Vorgang durcheinander, macht aber auch mehr Sinn.
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.
Gruß
HP
Advanced Member
Moinmoin,
wem sagst du das... ;D!
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).
Ja, das glaube ich Dir aufs Wort :7. Tut mir leid.
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
Advanced Member
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
Advanced Member
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.
Advanced Member
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.
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:
Alle Programmierer müssen sich an die Protokollstandards halten. Wenn jeder eigene Protokollvarienten implementiert, wird die Kommunikation zwischen Client und Server einfach nicht funktionieren.Code: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
viele Grüße,
Andreas
Advanced Member
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.
Advanced Member
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:
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.Code: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 ....
Ist das ein akzeptabler Vorschlag?
viele Grüße,
Andreas
Advanced Member
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 !
Advanced Member
Moin,
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
Advanced Member
Nix passiert.
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 crossposte die Protokolländerung dort. Dann sieht's hoffentlich jeder.
viele Grüße,
Andreas
Aktive Benutzer in diesem Thema: 2 (Registrierte Benutzer: 0, Gäste: 2)
Berechtigungen
Zitieren