monitor 1.9.0 - aber richtig :)

[SirFS]

Ich habe hier zwar "Häuptlingsrechte" (Moderator) aber ich darf auch nur 100 KB hochladen.

Versuche doch mal die Datei zu packen. (ZIP,RAR, etc)
Oder du versuchst das mit einem "One-Klick-Hoster" (z.B. Rapidshare oder simpleupload) und postest dann den Link hier.

[nepomuck]

Hallo Zusammen,

Ich habe das bestehende Protokoll etwas erweitert und ein paar kleine Änderungen daran vorgenommen. Das Draft sieht Befehle vor, über die Client und Server ein paar wichtige Konfigurationsdaten austauschen können.
Zudem habe ich Kommandos für den Mitschnitt eingebaut.

Bitte seht euch das Draft an und schickt mir eventuelle Erweiterungen oder Änderungen.
Da das PDF für das Forum zu fett ist :-) habe ich es auf meinem FTP-Server hinterlegt.

ftp://andi.rw-labs.de/pub/monitor-protokoll-02.pdf

Andreas

[Buebchen]

Die Kommandoliste macht einen guten Eindruck.

Ich würde für die unterstützen Protokolltypen auch eine Liste als Antwort vorsehen. Dann kann der Server die unterstützen Protokolle anbieten und der Client nimmt das für ihn passende. Alternativ könnte/müßte man voraussetzen, daß das Protokoll immer abwärtskompatibel ist (Wenn ein Server Version 2.1 kann muss er auch 1.x bis 2.0 können).

Den Servernamen hatte ich vorgesehen, wenn man mal später eine Relay-Funktion vorsehen würde: Das Relay verbindet sich zu drei Servern. Der Client nur zum Relay. Dann wäre die Info futsch, welcher Server es war (ok, im Moment eher nicht nötig).

[Buebchen]

SVN Update (trunk, Rev. 205):

Ausgabezeilen für angeschlossene Clients werden nun im SocketThread erstellt.
Die Auswerter geben nun eine Resultset mit einer map zurück als Ergebnisliste.

Der Zugriff auf die globale Nachrichtenkette ist in in einem Dispatcher-Modul gekapselt.
Die Auswerter müssen nun nicht mehr die Queue mit einem Lock belegen, bevor sie darauf
zugreifen. Das erledigt der Dispatcher (MonitorModulesResults.h/cpp).

Unter Windows getestet. Unix noch nicht.

[nepomuck]

Ich würde für die unterstützen Protokolltypen auch eine Liste als Antwort vorsehen. Dann kann der Server die unterstützen Protokolle anbieten und der Client nimmt das für ihn passende.

Das liesse sich leicht implementieren, Ich halte es jedoch für unnötig. Client und Server fragen gegenseitig die unterstützte Protokollversion ab und dann muss die niedrigste zwangsläufig für die Kommunikation herangenommen werden.
Erfährt der V3.2-Server, dass sein Client nur V2.78a drauf hat, antwortet er entweder mit einem OK und spricht dann 2.78a -- wenn er die Version nicht mehr beherrscht, bricht er den Handshake mit Fehler, Protokoll nicht implementiert ab.

Den Servernamen hatte ich vorgesehen, wenn man mal später eine Relay-Funktion vorsehen würde

Das setzt voraus, dass der Servername in so gut wie jedes Kommando als Paramter eingefügt werden muss.

Gegenvorschlag:
Das Relay weiss, wie es mit den Servern verbunden wurde. Es kann daraufhin virtuelle Kanalnummern vergeben, so dass der Client letztendlich nach wie vor nur die Nummern einsetzt.

Beispiel:
Das Relay sieht drei Server mit Drei Kanälen -- der Client am Relay sieht einen Server mit 9 Kanälen.

Andreas

[Buebchen]

Beispiel:
Das Relay sieht drei Server mit Drei Kanälen -- der Client am Relay sieht einen Server mit 9 Kanälen.

Andreas

Und wie weiss der Client nun, welcher Kanal wohin gehört ? Ich halte nicht das Einfügen des Servernamens für den Stein der Weisen. Aber der Lösungsansatz jetzt ein Multiplexing einzuführen ist es aus meiner Sicht auch nicht.

Aber sei's drum. Sofern die Gemeinde zustimmt, wird der Servername also erstmal ersatzlos gestrichen.

Das "trial-and-error" Verfahren zu Protokollbestimmung ist nicht gerade eine elegante Lösung. Aber da wären eher die Client-Entwickler dazu zu befragen. Serverseitig wird es eben nur ein NACK geben, wenn's nicht passt:-)

[nepomuck]

Und wie weiss der Client nun, welcher Kanal wohin gehört ?

Jeder Kanal hat einen eindeutigen Namen. Letzten Endes geht es dem Client um den überwachten Dienst, nicht um irgendeinen Server.

Aber der Lösungsansatz jetzt ein Multiplexing einzuführen ist es aus meiner Sicht auch nicht.

Ich glaube ein Relay ist erst unser überübernächstes Problem. Jetzt sollten wir erst einmal die Basis umsetzen und im nächsten Schritt Sorgen über all die vielen möglichen Zusätze machen.

Das "trial-and-error" Verfahren zu Protokollbestimmung ist nicht gerade eine elegante Lösung.

Zwei Fragen, zwei Antworten: Bei einm "OK/OK" nimmt man die höchste Protokollversion, bei einem "OK/Not Supported" nimmt man die mit OK bestätigte, und bei einem "Not/Not" geht eh nix -- einfacher geht's kaum.
Alternativ könnte die gegenstelle auf den Inquiry mit mehreren Zeilen und mehreren Codes antworten: 111=Name,112=OS,113=ver,114=Proto

210
111:"monitord"
112:"linux"
113:0030
114:0021
114:0020
114:0015
100

Oder der 111 bekommt mehrere Paramter, wie der Errorcode, 1=Name, 2=OS, 3=Version, 4=Protokollversion 0="Habe fertig!"
also:

210
111:1:"monitord"
111:2:"linux"
111:3:0030
111:4:0021
111:4:0020
111:4:0015
111:0

Dann würde man die Versionsnummer als dritten paramter "Preferred Protocol" an den Login hängen.
Wie wäre das?

Aber da wären eher die Client-Entwickler dazu zu befragen. Serverseitig wird es eben nur ein NACK geben, wenn's nicht passt:-)

Naja -- das ist momentan glaube ich unser Hauptproblem: Keiner befasst sich mit der Cliententwicklung.

Andreas

[Buebchen]

Naja -- das ist momentan glaube ich unser Hauptproblem: Keiner befasst sich mit der Cliententwicklung.

Andreas

Ich denke auch man kann sich auf die Kanalbezeichnung einigen. Die Cliententwicklung ist halt so 'ne Sache. Ich habe den monitor vor einige Jahren ja nicht so ganz ohne Hintergedanken umgeschrieben :-) Ist aber eher ein Langzeitprojekt - mit Betonung auf lang .. *räusper* ...

Werde also mal anfangen, die Clientkommunikation im Sinne der PDF zu überarbeiten. Sollen wir mit einer Protokollversion 1.0 starten ? Oder 2.0 (parallel zum monitord) ?