monitor 1.9.0 - aber richtig :)

[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) ?

[MacLeod]

uiiii ! hier tut sich wieder was.
gleich mal ausgechecked und configure gestartet.
habe nun das gleiche wie nepomuck:

checking for ALSA CFLAGS...
checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread
checking for libasound headers version >= 0.9.1... not present.
checking for snd_ctl_open in -lasound... no
configure: creating ./config.status
.infig.status: error: cannot find input file:

hm... natürlich auch unter linux
komme da nicht weiter.
unter win scheint's ja zu laufen.
schön wäre es wenn es kompartibel zu win und linux eingestellt wird.

öm zu den clienten...
ist es denn so geplant, dass ich mich mit nem crusader-client verbinden kann und er bekommt dann die letzten 500 auswertungen geschickt? verbinden geht ja schon, ich weiß, aber mich würden eben diese z.B 500 letzten protokolle reizen :-).
wenn das klappen würde wäre ich ultra begeistert.
leider kann ich aber nicht programmieren. kann also nur testen, auf nem headless-linux (ubuntu 6.10-server).

cu
MacLeod

[Buebchen]

Den Fehler

checking for ALSA CFLAGS...
checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread
checking for libasound headers version >= 0.9.1... not present.
checking for snd_ctl_open in -lasound... no
configure: creating ./config.status
.infig.status: error: cannot find input file:

konnte ich auf das unter windows erstellte configure script reduzieren. Ich habe jetzt unter Ubuntu 6.06 automake und autoconf nochmal gestartet und der Fehler im configure war behoben. Dafür habe ich noch andere Fehler (insbesondere streikt in der VMWare das /dev/dsp Interface im Moment). Könnte also bald wieder unter Linux laufen, sofern ich die Fehler heute noch finden kann :-)

Edit:
Sollte jetzt wieder unter Windows und Linux kompilieren. Fehler sind soweit gefixt. Wäre schön, wenn das mal jemand gegentesten könnte.

[MacLeod]

das configure lüppt nun durch
nun kommt das make:

make  all-am
make[1]: Entering directory `/home/tom/monitord/trunk'
source='monitord/Monitor.cpp' object='monitord/monitord_monitord-Monitor.o' libtool=no \
        DEPDIR=.deps depmode=none /bin/bash ./depcomp \
        g++ -DHAVE_CONFIG_H -I.  -Ijthread-1.2.1/src -D_DEBUG -Wall -pedantic         -c -o monitord/monitord_monitord-Monitor.o `test -f 'monitord/Monitor.cpp' || echo './'`monitord/Monitor.cpp
./depcomp: line 566: exec: g++: not found
make[1]: *** [monitord/monitord_monitord-Monitor.o] Error 127
make[1]: Leaving directory `/home/tom/monitord/trunk'
make: *** [all] Error 2

:-(
aso..
die ausführ-fags (755) mußte ich auch noch setzen, a sonst das configure nicht durchlief.
wäre nett wenn die gleich gesetzt sind ;-)

MacLeod

edit:
guten morgen....
g++ war nicht installiert *rolleyes*

[nepomuck]

Ist aber eher ein Langzeitprojekt - mit Betonung auf lang

Das ist klar. Aber irgendwann zwischendrin sollte es mal eine ferige lauffähige Version geben auf deren Basis die weitere Entwicklung fußt.

Ich möchte folgendes Vorschlagen:
Lasst uns jetzt einen "Feature Freeze" machen. Wir einigen uns jetzt auf den Funktionsumfang der Version 2.0 und auf den Befehlssatz des Protokolls 1.0. Dann bauen wir dazu den funktionierenden Server für Windows und Linux mindestens einen Client für Windows und Linux. In der Zwischenzeit lassen wir uns nicht mehr von "Ich-hätte-da-noch-ne-Idee"-Postings ablenken, bis 2.0 steht.
Danach können die einen Praxiserfahrung sammeln, Bugs fixen und eine Dokumentation schreiben, während sich die anderen wieder übder den Code hermachen und neue Features ausprobieren.

Mein konkreter Feature-Vorschlag für die 2.0:

Protokoll
wie Vorgeschlagen -- hier muss noch jemand die Pocsac-Paramter festlegen!

Server
- Bedient pro thread 2 Kanäle
- Decodiert ZVEI mit DTFM, Pocsac und FMS
- kann mehrfach parallel mit mehreren Soundkarten arbeiten
- Kommuniziert bidirektional mit einem oder mehreren Clients über sein eigenes Protokoll
- Kommuniziert optional (nur Alarm-Out) über FMSCrusader und FMS32-Protokoll
- Kann auf Kommando einzelne oder mehrere kanäle aufzeichnen (mit sox)

Client
- Kommuniziert bidirektional mit dem Server
- Zeigt die Auswertungen mehrere Kanäle in einem oder mehreren Fenstern an
- Startet Shell-Skripte und Batch-Dateien in Abhängigkeit von Alarrmmeldung und Konfigurationsdatei
- Setzt @REC-Kommandos in Abhängikeit von Meldung und Config ab
- Offeriert einen Debug-Modus, der die komplette Protokollkommunikations darstellen kann.

Was haltet ihr davon?

Andreas

[nepomuck]

Die gute Nachricht: Nach einem chmod +x configure läuft config und make durch und der monitord lässt sich unter Ubuntu 7.10 (32Bit) starten: (rev 216)

Die schlechte Nachricht: Das neue ZVEI-Modul läuft nicht richtig -- da ist irgendwas gröberes kaputt.

Ich habe dem Monitor die Aufzeichnung einer Probealarmierung vorgespielt und er hat ungeheuer viele Fehler gemacht. Zum Vergleich habe ich auf der selben Hardware die alte Version laufen lassen, die alles richtig macht.

Diesem Posting hängen zwei Screenshots von 1.8.1 und Build 216 an -- die beide die gleiche Alarmierung vorgespielt bekommtn.

Die Fehler sind gelb markiert.

Andreas

[MacLeod]

Das neue ZVEI-Modul läuft nicht richtig[/b] -- da ist irgendwas gröberes kaputt.

jupp
kann ich bestätigen, fms klappt wunderbar und zuverlässig zumindest auf der konsole.
zvei wird bei mir nicht erkannt...

mit dem crusader wird bei mir leider garnichts angezeigt.

kann ich noch was testen?

edit:
habe noch was:
wenn ich monitord auf der konsole gestartet habe wird fms ja nun prima ausgewertet.
nur wenn ich dann mich per telnet auf port 7778 anmelde kommt:

Signal setzen... .. done
Waiting for beendet
Dispatcher runnung ...Dispatcher waiting ...Waiting for signal
terminate called after throwing an instance of 'MonitorException'
  what():  monitord/SocketServer.cpp Zeile 512: memLockCreate failed
Aborted

komisch, das hat mal gefunzt...

[mdi]

Hallo,

Die schlechte Nachricht: Das neue ZVEI-Modul läuft nicht richtig -- da ist irgendwas gröberes kaputt.

Ich habe dem Monitor die Aufzeichnung einer Probealarmierung vorgespielt und er hat ungeheuer viele Fehler gemacht. Zum Vergleich habe ich auf der selben Hardware die alte Version laufen lassen, die alles richtig macht.

Diesem Posting hängen zwei Screenshots von 1.8.1 und Build 216 an -- die beide die gleiche Alarmierung vorgespielt bekommtn.

Die Fehler sind gelb markiert.

hast Du beide Kanäle der Soundkarte mit denselben Daten auf das ZVEI-Modul losgelassen oder kam es nur von einem Kanal? Das sieht irgendwie so aus, als würde er da was verschieben... Ich hatte diesen Fehler zwischendurch einmal relativ zu Anfang meiner Tests, allerdings habe ich irgenwann zwischendurch nur noch von einem der beiden Kanäle ausgewertet (sonst gabs alles doppelt, klar, und das nervte) um erstmal die saubere Erkennung zu haben und ging dann davon aus, dass das entsprechend auch bei zwei Kanälen sauber läuft. War wohl ein Trugschluss, wenngleich sich mir der Fehler jetzt nicht spontan erschließt :(. Lässt man nur von einem Kanal erkennen, tritt der Fehler also augenscheinlich nicht auf; bitte probier das mal aus (abschalten des Moduls von einem der beiden Sound-Kanäle in der Konfigurations-XML-Datei, so dass Du nur noch eine Datenquelle für den ZVEI-Auswerter hast).

Ich habe (nach dem Absetzen des Artikels) die aktuelle Revision (216) ausgecheckt, kompiliert und gestartet. Leider trat bei meinen Tests auch mit zwei Kanälen als Eingang der Fehler nicht auf. Kann ich Dein Testfile mal haben um den Fehler nachzuvollziehen (am liebsten als Download mit Link per pm)?
Mir ist außerdem noch eingefallen, dass ich zur Zeit ausschließlich unter Windows baue und teste, daher sollten wir auch in Sachen Sound-Verarbeitung auf den verschiedenen Plattformen schauen, ob alles glatt läuft (Schuss ins Blaue, klar - aber vielleicht auch ein Ansatz). Leider steht mir momentan kein Rechner mit einem Ubuntu (oder anderem Linux) zur Verfügung um selber zu testen, muss ich noch immer mal einrichten :(.

Ansonsten habe ich eben auch noch eine Merkwürdigkeit entdeckt: Ich habe mir einen kleinen Client geschrieben (wxWidgets), der den monitord connected und seine Ausgaben anzeigt (mit Datum und Zeit, optischer Signalisierung durch rot werdenden ALARM-Button und akustischer Signalisierung durch Abspielen eines Tons). Wenn ich diesen an den monitord hänge und schließe bzw. das ein paarmal mache, generiert der monitord 100% CPU-Last. Hat dazu spontan jemand eine Idee? Es ist dann kein Client mehr connected aber die Verbindungen wurden vom Client nicht sauber disconnected sondern stumpf abgebrochen.

Martin

[nepomuck]

hast Du beide Kanäle der Soundkarte mit denselben Daten auf das ZVEI-Modul losgelassen oder kam es nur von einem Kanal?

Meine Config läd ZVEI auf einem, FMS auf dem anderen Kanal.

Das sieht irgendwie so aus, als würde er da was verschieben

Ich habe da eine Vermutung:
Unsere Alarmierung löst jede Schleife doppelt aus. Wenn kein DTFM-Ton anhängt, kommen die Fünftonfolgen in sehr enger Abfolge -- es gibt keinen Melderton.

Für mich sieht das so aus: Dein Auswerter erkennt die erste Schleife korrekt. Dann wartet er auf einen DTFM- oder Weckerton. Da der nicht kommt, interpretiert er den ersten Ton der folgenden 5-Ton-Folge als DTFM-Ton und beginnt die eigentliche ZVEI-Dekodierung erst beim zweiten Ton.

Das würde erklären, warum so viele Fehlauswertungen mit "6" beginnen, da unsere Schleifen alle mit "26" anfangen. Der Fehler tritt vor allem in dem Bereich der Probelalarmierung auf, in der sehr viele Schleifen ohne Folgeton in sehr schneller Abfolge kommen.
Den zweiten Teil der Probealarmierung, der alle Sirenen auslöst, erkennt der Auswerter fehlerfrei.

Kann ich Dein Testfile mal haben um den Fehler nachzuvollziehen (am liebsten als Download mit Link per pm)?

Ich schicke dir einen Link.

Andreas

[Buebchen]

jupp
kann ich bestätigen, fms klappt wunderbar und zuverlässig zumindest auf der konsole.
zvei wird bei mir nicht erkannt...

mit dem crusader wird bei mir leider garnichts angezeigt.

kann ich noch was testen?

edit:
habe noch was:
wenn ich monitord auf der konsole gestartet habe wird fms ja nun prima ausgewertet.
nur wenn ich dann mich per telnet auf port 7778 anmelde kommt:

Signal setzen... .. done
Waiting for beendet
Dispatcher runnung ...Dispatcher waiting ...Waiting for signal
terminate called after throwing an instance of 'MonitorException'
  what():  monitord/SocketServer.cpp Zeile 512: memLockCreate failed
Aborted

komisch, das hat mal gefunzt...

Seltsamer Fehler. Könnte sein, daß ich den Fehler dafür gefunden habe (wenn ein Thread beendet wurde habe ich das memlock nicht freigegeben, aber dennoch versucht, es später wieder zu belegen).

Mein kleiner Test war in sofern erfolgreich, daß ich folgendes gemacht habe:
1. monitord unter Ubuntu 6.06
2. BOSTool als Tonquelle
3. Crusader unter Windows mit dem monitord in der VMWare verbunden

Alles soweit ok. Ist der Fehler reproduzierbar ? Ggf. mal ein make clean machen, um sicher zu sein, daß er einige Teil nicht korrekt neu baut.

Edit: SVN aktualisiert.

[nepomuck]

Sehr seltsam ...

Ich habe gerade den monitord (rev 217) unter Ubuntu 7.10 64-Bit übersetzt und ihm die besagte Probelalarmierung vorgespielt.
Auf der x64-Kiste läuft die ZVEI-Auswertung ohne Fehler.

???