monitor 1.9.0 - aber richtig :)

[Buebchen]

Korrekt, das war mein Fehler


Das Protokoll sieht hier nichts vor. Ich habe den Sonderfall, dass sich Clients ohne Login verbinden dürfen nicht berücksichtigt.

Ich würde das folgendermassen umsetzen. Wenn die Verbindung steht sendet dein Client ein "202" (Keepalive) an den Server. Wenn ein 100 (OK) als Antwort zurückkommt, darf der Client ohne Login eine Verbindung aufnehmen (Infobox: Verbindung steht). Bekommt er hingegen ein 101:001 zurück (Fehler: Not logged in), dann muss dein Programm ein Fenster öffnen und Benutzernamen und Passwort abfragen.

@Buebchen: Wie weit sind hier die Protokolländerungen von 0.3 umgesetzt? Kennt der monitord schon den Login mit Protokollversionsparamter? Ist 202 komplett implementiert?

viele Grüße,
Andreas

Bisher habe ich am neuen Protokoll noch nichts umgesetzt :-( Ich hab's aber auch noch nicht komplett gegengelesen...

[nepomuck]

So, jetzt habe ich auch mal ein paar Zeilen Code geschrieben!
Der ist zwar nicht besonders toll, sollte uns aber beim Entwickeln etwas helfen.

ftp://andi.rw-labs.de/pub/bosix/poni.pl

"Poni", das Perl Monitor Frontend, stellt eine Verbindung zu einem Monitor-Server her und gibt die ankommenden Alarme in lesbarer Form auf der Kommandozeile aus -- mehr macht das Tool im Moment nicht.

Bei den Tests mit Poni (und dem BOS-Tool auf der Gegenseite) ist mir was aufgefallen:

Pocsac geht hier nur mit 512 Baud, 1200 Baud-Alarme werden nicht angezeigt.
Bei nummerischen Pocsac-Alarmen übermittelt Monitor die Ziffern im Klartext und nicht Hex-Kodiert. Der Client kann aber nicht wissen, ob was Alphanummerisches (Hex-codiert) oder was nummerisches (nicht HEX-codiert) ankommt.
Hier sollte Monitor auch die nummerische Ausgabe HEX-Kodieren, dann können die Clients das Text-Feld pauschal durch den HEX-Dekodierer jagen.
Oder wir müssen ein zusätzliches Feld "Alarmtype" beim Kommando 320 einführen, so dass der Client weiss was ihn erwartet.

viele Grüße,
Andreas

[nepomuck]

Schlechten Perl-Code schreiben macht Spass!

Ich habe gleich noch was nachgelegt: einen Mini-Client der Alarme im CSV-Format in separate Dateien schreibt und eine kompakte Darstellung auf dem Schirm ausgibt.

Das Perl-Programm ponilog.pl wertet die poni.cfg-Datei aus, um die Infos zum Server, Port etc. zu erhalten. Tool und Demo-Config liegen auf
ftp://andi.rw-labs.de/pub/bosix/

viele Grüße,
Andreas

[Buebchen]

Bisher habe ich am neuen Protokoll noch nichts umgesetzt :-( Ich hab's aber auch noch nicht komplett gegengelesen...

So. Versuche da jetzt mal beim Login weiter zu kommen. Was mir noch nicht gefällt ist die Geschichte mit der Programmversion. Die würde ich eigentlch am liebsten aus dem configure.ac ziehen. Da steht zur Zeit 2.0svn drin. Das wiederum passt natürlich nicht zum definierten Protokoll.

Ich könnte jetzt zwei Wege gehen:

a) Im configure.ac werden nur noch Zahlen mit einer Nachkommastelle als Programmversion genutzt
b) Wir lassen als Programmversion auch Text zu und können auch wie bisher svn / stable / dev / beta / sonstige Text als Version im configure.ac eintragen.

Spontan halte ich sowas für einen reinen Infotext. Oder wird der Client jemals mit dem "Versionswert" rechnen ? Interessant ist doch die Protokollversion für ihn. Ob das nun ein 2.1a oder 2.2svn monitord ist ist doch eher uninteressant und mehr etwas als Information für den Benutzer, oder ?

Kann die Antwort 111:5:"[Module]" auch vorläufig entfallen ? Denn das ist im Moment noch nicht weiter definiert und ich möchte mich noch nicht festlegen, wie und wo die Modulnamen festgelegt sind.

Wenn nicht, ist die Antwort vorläufig:

111:5:"[leer]"

[nepomuck]

Was mir noch nicht gefällt ist die Geschichte mit der Programmversion. Die würde ich eigentlch am liebsten aus dem configure.ac ziehen. Da steht zur Zeit 2.0svn drin. Das wiederum passt natürlich nicht zum definierten Protokoll.

Der Parameter ist -- wie du schon sagst -- reiner Infotext, da können wir eigentlich machen, was wir wollen. Ich ändere die Protokolldefinition für 0.4 ab, so dass der Paramter Programmversion ein Textfeld wird.

Bei der Protokollversion möchte ich allerdings das vierstellige nummeriesche Feld lassen, wenn's dir recht ist.

Kann die Antwort 111:5:"[Module]" auch vorläufig entfallen ?

So hatte ich das gedacht. 111:5 kann entfallen oder mehrfach vorkommen. Da wir 111:0 als Ende-Kommando festgelegt haben, weiss der Client wann die Inquiry-Antwort fertig ist und wird nicht vergeblich auf ein 111:5 warten.

Ein Login mit unbekannter Version sollte m.E. nicht mit 101:004 (Protokollfehler, nicht verstanden) beantwortet werden, sondern mit 101:008 (Versionsfehler)

Ich hatte 008 als Fehler der Programmversion und 004 als Fehler der Protokollversion gedacht. Ein Login mit falschem Protokoll ist demnach ein Protokollfehler und kein Problem der Softwareversion. Oder ist das unlogisch?

viele Grüße,
Andreas

[Buebchen]

Der Parameter ist -- wie du schon sagst -- reiner Infotext, da können wir eigentlich machen, was wir wollen. Ich ändere die Protokolldefinition für 0.4 ab, so dass der Paramter Programmversion ein Textfeld wird.

Bei der Protokollversion möchte ich allerdings das vierstellige nummeriesche Feld lassen, wenn's dir recht ist.

das vierstellige Protokollfeld finde ich so prima. Das sollte ruhig bleiben.

Da wir 111:0 als Ende-Kommando festgelegt haben, weiss der Client wann die Inquiry-Antwort fertig ist und wird nicht vergeblich auf ein 111:5 warten.

Prima. So hatte ich mir das auch vorgestellt. Dann lass ich das vorläufg erstmal weg.

Ich hatte 008 als Fehler der Programmversion und 004 als Fehler der Protokollversion gedacht. Ein Login mit falschem Protokoll ist demnach ein Protokollfehler und kein Problem der Softwareversion. Oder ist das unlogisch?

viele Grüße,
Andreas

Ich, glaube dann stehe ich auf dem Schlauch :-)

Ein Login mit falschem Format (kein Protokollwunsch oder fehlendem Passwortfeld, oder nur "220:" ) wird jetzt doch mit 101:004 (nicht verstanden) beantwortet - richtig ?

Ein Login mit passender Protokollversion aber falschem Benutzernamen oder Password mit 101:003 (incorrect login)

Aber wie beantworten wir einen Login mit richtigen Benutzerdaten und nicht passender Protokollversion ? Bei 101:004 könnte man vom 1. Fall nicht unterscheiden.

Deswegen hätte ich dann intuitiv 101:008 genommen. Dann kann dem User als Meldung gesagt werden, daß die Protokollversion geändert werden muss. Die Anmeldedaten sind zu dem Zeitpunkt ja noch ungeprüft.

Die eigentliche Programmversion sollte m.E. für die Kommunikation unerheblich sein. Da ist aus meiner Sicht nur die Protokollversion entscheidend.

[nepomuck]

Ein Login mit falschem Format (kein Protokollwunsch oder fehlendem Passwortfeld, oder nur "220:" ) wird jetzt doch mit 101:004 (nicht verstanden) beantwortet - richtig ?

Wir können für so etwas ja auch einen "Client-Software-Programmierer-unfähig"-Fehler einführen :-)

Scherz beiseite: du hast recht, es gibt keine Unterscheidung zwischen Protokoll fehlerhaft verwendet und Protokollversion falsch. Also nehmen wir wie vorgeschlagen den 008 als Protokollversionsfehler und den 004 als Protkollbenutzungsfehler, ok?

Falls wir im weiteren Verlauf noch einen eigenen Fehlercode für den Server an sich benötigen, erweitern wir einfah die Protokolldefinition.
Andreas

[mdi]

Moinmoin,

ich wollte nur mal ein kurzes Lebenszeichen von mir geben: Ich habe zur Zeit Prüfungen und dem entsprechend deutlich weniger Zeit, mich um die monitord-Sache zu kümmern. Ist nicht vergessen und ich bin noch da! :).

Martin