monitor 1.9.0 - aber richtig :)

[Buebchen]

2 Fragen dazu:

1. Du hast das aktuelle SVN (jetzt aus dem trunk Pfad) ?
2. Existiert da eine config.h.in ? Diese scheint zu fehlen. Ist aber im Repository vorhanden

Andere möglichkeit wäre mal mit dos2unix config.sub zu bearbeiten. Sieht nach nem Fehler mir [cr] und [cr][lf] aus (das .infig.status macht irgendwie keinen Sinn).

[nepomuck]

1. Du hast das aktuelle SVN (jetzt aus dem trunk Pfad) ?

Ja. Über Rapidsvn ausgecheckt und unter monitor/trunk den configure gestartet.

2. Existiert da eine config.h.in ? Diese scheint zu fehlen. Ist aber im Repository vorhanden

Die Datei ist da. Ich habe so gut wie alle Dateien im trunk-Pfad auf cr-lf untersucht und mit dos2unix bearbeitet. Zudem habe ich alle executables mit +x geflagged.

Es funktioniert nach wie vor nicht.

Andreas

[nepomuck]

Wer hat denn in diesem Forum "Häuptlingsrechte"?

Ich würde gerne mein Draft zur Protokollversion 0.2 posten, aber das PDF hat 130KB und ich darf nur 100 KB anhängen.

Kann mir jemand bitte erlauben, 140 KB zu posten?

Danke,
Andreas

[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