monitor 1.9.0 - aber richtig :)

[mdi]

Hallo Andreas,

Erst einmal vielen Dank für dein Engagement bei diesem Projekt.

gern; ich habe zur Zeit eben selber eine gehörige Portion Interesse daran und bin schon sehr angetan, auf welch breiter Grundlage man hier mitarbeiten kann :)!

Ich werde den neuen ZVEI-Code gleich unter Linux gehörig stressen.

Das ist gut; ich habe zur Zeit leider keine sinnvolle Möglichkeit, den "mal eben" unter Linux zu testen ohne große Aktionen machen zu müssen. Muss dringend mal wieder ein Multiboot-System einrichten ;). Feedback ist gerne genommen; meine C/C++-Programmierkünste sind ein wenig eingerostet in den letzten Jahren.

Die Geschichte mit dem Unterscheiden der beiden Fälle "unklare Auslösung" wäre vom Code her kein Problem - da sowieso unterschiedliche Stellen für die Ausgabe zuständig sind, bräuchte man nur wie Du schriebst entsprechend eine weitere Definition. Ich weiß allerdings nicht, auf welchen Argumenten die bisherige fußt!

Wie aufwändig ist es, andere Dualton-Dekodierungen einzubauen? Neben "Feueralarm" kommen in der Praxis vor allem "Testalarmierung" und "Katastrophenalarm" zum Einsatz. Es wäre schön, wenn der monitor diese Töne erkennt und korrekt auswertet.

Das ist ein wenig Aufwand aber wie geschrieben noch zu machen und alles andere als vom Tisch, wenngleich bei mir zur Zeit etwas geringer priorisiert (da ich nur die echten Fünftonfolgen brauche -> Betriebsfunk). Notwendig ist dafür die Überarbeitung der process_block()-Methode, da diese zur Zeit nur Einzelfrequenzen erkennen bzw. zurückmelden (return int Frequenz-Index) kann. Lösungsansätze habe ich schon im Kopf, allerdings wird der Eingriff etwas umfassender, weil dafür vermutlich auch die diversen Matrizen erweitert werden müssen und ich in dem Zuge gleich alle im ZVEI-Standard definierten Buchstaben (A, C, J, ...) mit einbauen wollte - vielleicht braucht sie einmal jemand (ich brauche nur das A, das ist prinzipiell schon da, wird aber noch nicht weiter behandelt). Für die Fälle der Sirenentöne müssten dann auch entsprechende Typ-Nummern vergeben und im Protokoll integriert werden (oder gibt es die schon?).

Noch nicht. Der unrsprüngliche Plan sah vor, SQL-Datenspeicerung über einen Client abzuwickeln -- der natürlich auf der selben Maschine laufen könnte.

Hm, dem SVN-Inhalt nach zu urteilen gibt es bereits eine MySQL-Storage-Engine, die entsprechendes für MySQL tun könnte. Wie ist da der Stand der Dinge?

Web-Funktionen liessen sich über ein reguläres PHP-Backend umsetzen.

Öh... das habe ich jetzt nicht ganz verstanden, muss ich ehrlich sagen ;).
Mir schwebte vor, dass die StoreResult()-Methode in der Lage wäre, eine noch zu schreibende HTTPStorage-Engine zu nutzen, um per HTTP GET (oder auch POST, das kann man ja beliebig ausweiten) die Telegramme/Tonfolgen/... an einen Webserver zu übergeben. Das hätte in meinen Augen den Vorteil, dass diese nicht nur über eine dauerhaft bestehende TCP-Verbindung (entsprechend FMS/Crusader/monitor-Socket) erhältlich wären sondern (in der monitor.xml konfigurierbar) per HTTP an ein PHP-Skript "gepusht" werden könnten, was sie dann wie der Anwender möchte weiterverarbeitet. Oder gibt es etwas ähnliches schon und ich habe Tomaten auf den Augen, weil ich bisher nur die ZVEI-Codes angeschaut habe?

Ich finde allerdings, dass der monitord-Dienst an sich so klein wie eben möglich gehalten werden sollte, so dass er auf lausigen alten PCs läuft, die ein völlig abgespecktes Linux von CD oder USB booten.

Ja, das wäre gut, keine Frage. Ist halt die Frage, ob die Einbindung von libcurl da schon ein Problem wäre oder ob nicht. Meine Tests eben (Windows only) verliefen sehr vielversprechend und würden genau meinen Wunsch von oben realisieren: Übergabe der Daten an einen Webserver zur Weiterverarbeitung mittels PHP wie auch immer gewünscht.

Viele Grüße
Martin

[Buebchen]

Ich werde auch den Ansatz der StorageModule weiter verfolgen. Einfach aus eigenem interesse - Das MySQL Modul war mal so ein Ansatz zwischendurch :-)

Vorher möchte ich aber die Kommunikation der Auswertungsmodule zu den Display und Storagemoduln nochmal überarbeiten. Ich könnte mir gut ein std::map vorstellen, daß durch das Auswertungsmodul gefüllt wird und dann an eine std::list aller StorageModule geht. Der Auswerter kann dann auch neue Daten hinzufügen, die dem StorageModul nicht schaden, wenn es sie nicht versteht.

Ein Beispiel könnte sein, daß der Auswerter folgendes liefert:

data['typ']='zvei'
data['kennung']='12345'
data['Weckton']='Sirene'

Und das Storagemodul aber nur 'typ' und 'Kennung' nutzt (weil es den Eintrag 'Weckton' noch nicht gab, als das StorageModul gemacht wurde).

Nicht so umfangreich wie XML. Aber doch flexibel und vor allen Dingen erweiterbar. Kennt das StorageModul den typ der Daten nicht, kann es ihn ignorieren. Fehlende Felder (aus Sicht des StorageModuls) hätten automatisch einen leeren Wert.

Was halten denn die anderen von dem Ansatz ?

[nepomuck]

Ein Beispiel könnte sein, daß der Auswerter folgendes liefert:
data['typ']='zvei'
data['kennung']='12345'
data['Weckton']='Sirene'

Wobei data['Weckton'] folgende Ergebnisse liefern kann:
Ohne, Weckton, Feuer, Test, Katastrophe, Warnung, Entwarnung
Dieses Konstrukt läßt aber keinen Platz für "unklare Auslösung". Erkennt der Dekodierer einen möglichen Fehler, wenn das Signal schlecht, verzerrt oder überlagert ist?

Würde dann ein data['klare Auslösung'](Boolean)=1 (Fehlerfreie Dekodierung) oder =0 (mögliche Falsche Codefolge) Sinn machen?

Öh... das habe ich jetzt nicht ganz verstanden, muss ich ehrlich sagen ;).

Der Ansatz war hier, das monitor selbst nicht mit dem Web-Server spricht, sondern sich dieser per php aus der Datenbank bedient, die monitor füttert.
Bei deinem Vorhaben würde vom monitor aus direkt auf einen Webserver schreiben. Das ist eine gute Idee, aber ich würde diese Funktion lieber in einem Client-Modul sehen als direkt im monotord-Code.

Hm, dem SVN-Inhalt nach zu urteilen gibt es bereits eine MySQL-Storage-Engine, die entsprechendes für MySQL tun könnte.

Richtig. Das Problem der existierenden monitor-Version mit mysql-Engine ist nur, dass sie zu monolithisch aufgebaut ist und viele Dependencies hat. Die läuft nicht auf jedem Linux. Deshalb sind wir ja hier, um eine modulare Version zu schaffen. Der bestehende MySQL-Code liesse sich auf einem Client umsetzen.

@Buebchen: Wie sieht es eigentlich mit den Soundkartenfunktionen aus?
Wenn ich mich an die Überarbeitung des Protokolls mache, würde ich dabei gerne die Befehle für die Aufzeichnung integrieren. Liesse es das Backend zu, dass mehrere Tasks simultan von ein und dem selben Kanal aufzeichnen? Dann könnten mehrere Clients unabhängi voneinander Aufnehmen.
Wird es nun ein (optionales) MySQL-Modul im Backend geben oder nicht -- irgendwann müssen wir uns entscheiden.
Dann müssten nämlich die passenden Befehle ins Protokoll, wie "SendLastAlarms" oder so.

Mein Vorschlag: Wir lassen für die erste "Final" Version 2.0 von monitord und des Protokolls das SQL-Backend weg und konzentrieren uns auf die Dekodierung. Auch das Recording sollte drin sein.
Für 2.2 nehmen wir uns dann das MySQL-Backend und/oder die HTTP-Push-Engine vor.


Viele Grüße,
Andreas

[jhr-online]

So ganz zwischendurch melde ich mich zurück... Nach Umzug hat sich der Telekommunikationsdienstleister ordentlich Zeit gelassen. Ich bin aber jetzt wieder online und versuche die Mails und Forenbeiträge der letzten zwei Monate aufzuarbeiten. Ich freu mich schon den aktuellen Stand näher zu betrachten :)

jhr

[nepomuck]

Eine kurze Frage vom Nicht-C++-Entwickler::

Wenn ich das SVN auschecke: In welchem Verzeichnis muss ich dann meinen Make fahren, um die aktuelle monitord-Version für Linux mit dem neuen ZVEI-Dekoder zu erhalten.

Und was passiert, wenn ich das auf einer x86-64-Kiste mit 64-Bit-Ubunut mache?

Andreas

[mdi]

Hallo,

Wenn ich das SVN auschecke: In welchem Verzeichnis muss ich dann meinen Make fahren, um die aktuelle monitord-Version für Linux mit dem neuen ZVEI-Dekoder zu erhalten.

ich habe ausgecheckt: svn://jhr-online.de/monitor/monitor/branches/2.1.1-mergeWinLin (HEAD-Revision). Hier führst Du configure und make aus (also einen oberhalb von /monitord im Verzeichnisbaum). Jedenfalls tut das so unter Windows...

Martin

[nepomuck]

Hallo,
ich habe ausgecheckt: svn://jhr-online.de/monitor/monitor/branches/2.1.1-mergeWinLin (HEAD-Revision). Hier führst Du configure und make aus (also einen oberhalb von /monitord im Verzeichnisbaum). Jedenfalls tut das so unter Windows...
Martin

ast@fkl2:~/monitorsvn/monitor/branches/2.1.1-mergeWinLin$ ./configure
configure: error: cannot run /bin/bash ./config.sub

Das passiert, obwohl ich die Dateien mit chmod +x ausführbar gemacht habe.

Ich habe mit config.sub angesehen und festgestellt, dass die Textzeilen mit <0d><0a> enden (Windows-Like "CR+LF") statt wie unter Linux üblich mit <0a> "LF" alleine.

Für den Interpreter lautet die erste Zeile von config.sub daher "#1/bin/sh^M" und das geht nicht.
Auch die geänderten Sourcecode-Dateien haben den falschen Linefeed drin -- ich weiss nicht, wie der Compiler darauf reagiert.

Kannst du das in deinem Editor korrigieren und die von dir veränderten Dateien nochmal mit <0d> "LF" alleine einstellen?

Danke,
Andreas

[mdi]

Hallo,

Erkennt der Dekodierer einen möglichen Fehler, wenn das Signal schlecht, verzerrt oder überlagert ist?
Würde dann ein data['klare Auslösung'](Boolean)=1 (Fehlerfreie Dekodierung) oder =0 (mögliche Falsche Codefolge) Sinn machen?

hm... dass der Dekoder eine "Signalqualität" erkennt, ist zur Zeit so gar nicht vorhanden. Wenn eine Fünftonfolge erkannt werden kann (bei jedem Wechsel des Tons gibt es ein neues Zeichen, Pausen dürfen zwischen den fünf Tönen nicht auftreten), wird diese ausgegeben. Das ist ja auch verhältnismäßig einfach zu realisieren. Wenn man eine etwas fehlertolerantere Lösung schreiben wollte, könnte man die Toleranz von Pausen in der Tonfolge einbauen (so dass z.B. von den 70ms Tonlänge grob 30ms unerkannt bleiben dürfen - generell keine schlechte Idee, so etwas sollte ich machen). Andersherum könnte man das dann vielleicht für die "Signalqualität" nutzen: Wenn weniger als 60% der eigentlichen Tonlänge eines der Töne erkannt wurden, ist das Signal "unklar"). Da stellt sich aber die Frage: Wird so etwas echt benötigt? Ja, ok, es wäre dann nur noch ein BOOL ;D.

Der Ansatz war hier, das monitor selbst nicht mit dem Web-Server spricht, sondern sich dieser per php aus der Datenbank bedient, die monitor füttert.
Bei deinem Vorhaben würde vom monitor aus direkt auf einen Webserver schreiben. Das ist eine gute Idee, aber ich würde diese Funktion lieber in einem Client-Modul sehen als direkt im monotord-Code.

Hm, schade. ;).
Nein; Spaß bei Seite: Grundsätzlich kann ich die Einstellung gut nachvollziehen. Für mich (aus Anwendersicht) wirkt die MySQL-Geschichte "fetter" als die HTTP-Idee. Im Monitor integriert (als Storage-Engine) hätte es den Vorteil, dass man keinen direkten Zugriff auf eine MySQL-Datenbank braucht um Daten wegzuschreiben, sondern die Daten per HTTP POST an einen Webserver liefern kann (nicht jeder Hoster bietet MySQL-Zugriff von außen an). Auch bräuchte man keinen Client, der über Netz/Sockets dauerhaft connecten muss, sondern hätte entsprechend keinerlei Ports zu öffnen und würde mit dem Monitor keinen "Server" sondern einen "HTTP-Client" aufsetzen. Das wäre auch für Paketfilter/Firewalls einfacher zu händeln. Aber das als Client-Modul (das heißt, es läuft als eigenes Programm im eigenen Prozess und verbindet sich zum Monitor über die Sockets?) zu bauen, sollte ja grundsätzlich nicht problematisch sein und hätte wiederum den Vorteil, dass keine weitere Library für den eigentlichen monitord benötigt wird.

@Buebchen:
Wird es nun ein (optionales) MySQL-Modul im Backend geben oder nicht -- irgendwann müssen wir uns entscheiden.
Dann müssten nämlich die passenden Befehle ins Protokoll, wie "SendLastAlarms" oder so.

Hier würde ich die Weiterführung des obigen Gedankens vorschlagen: Das MySQL-Modul als Client-Modul bauen und für die History SQLite nutzen (wobei das Datenbank-Design und die SQL-Queries sicher ähnlich wenn nicht gleich sind). Damit könnte der Monitor "von Hause aus" immerhin eine SQL-fähige Datenbank auf Dateibasis mit den aufgefangenen Alarmierungen füttern, die sehr einfach handhab- und auch anderweitig nutzbar ist. Auch ist kein MySQL-Server dafür notwendig, den Monitor einschließlich der History-Funktion zu nutzen. Wer dann MySQL-Unterstützung braucht, kann das MySQL-Modul einbinden und die Daten in einer eigenen Datenbank sonstwo sammeln.
Ja, ich bin begeistert von SQLite, entschuldigung ;).

Mein Vorschlag: Wir lassen für die erste "Final" Version 2.0 von monitord und des Protokolls das SQL-Backend weg und konzentrieren uns auf die Dekodierung. Auch das Recording sollte drin sein.
Für 2.2 nehmen wir uns dann das MySQL-Backend und/oder die HTTP-Push-Engine vor.

Das finde ich sehr gut. Die HTTP-Push-Sache ist bereits in der Mache (basierend auf curl, ich brauche das Feature! ;)).

Da wir gerade bei der Zukunft sind: Ich habe mir gestern Abend das SVN einmal genauer angeschaut und gesehen, dass in /trunk gar nicht entwickelt wird. Stattdessen gibt es mehrere 2.x-Branches, in denen sich Dinge tun, wobei es den Eindruck macht, als würden die Branches immer wieder voneinander abstammen und "abbrechen", sobald ein neuer Branch gebaut wurde.
Da es ja auch bei der Nutzung von SVN gewisse Standards gibt, möchte ich hiermit vorschlagen, dass /trunk nach /branches/1.9.0 gemoved wird (als Archiv, damit es nicht wegkommt, quasi). Entsprechend ist /trunk dann leer und kann mit den Daten des aktuellen Branches (/branches/2.1.1-mergeWinLin) gefüllt werden, wobei dann hoffentlich keine wichtigen Änderungen aus den anderen 2er-Branches verloren gehen (gut, man könnte nochmal diff-en und nötigenfalls mergen). Damit wäre im /trunk die aktuelle Version 2.0 (ohne die 1en und das mergeWinLin am Ende - brechen wir es auf das eigentliche Ziel herunter), die dann als Feature-Set hat: Plattformunabhängigkeit, Funktionalität (Erkennung, Ausgabe über die drei Sockets in drei Formaten Crusader, FMS32, monitord).
Einen Branch/Branches für die 2.1 oder 2.2 (HTTP-Engine, MySQL-Engine, was auch immer) anzulegen, wäre dann sicher sinnvoll, sobald ein neues Feature implementiert werden soll. Ich möchte auch die Nutzung von Tags anregen, mit denen man ja ganz famos Revisionen im SVN Versionsnummern von Software aufklatschen kann, so dass nach einer Umstrukturierung wie vorgeschlagen direkt der Inhalt von /trunk in /tags/2.0-291107 als lauffähige Version markiert werden könnte und sollte, um lauffähigen Code schnell und einfach auscheckbar zu haben.

Auch möchte ich anregen, dass die tolle Entwicklung des 2er monitor ein bisschen mehr an die Öffentlichkeit kommt. Ich würde gern hier im Forum diesen Thread schließen (er wird doch arg unübersichtlich) und drei neue anfangen:
a) Der Monitor 1.9 (falls existent)
b) Der Monitor 2.0: Aktueller Stand der Entwicklung
c) Der Monitor 2.x: Ausblick

Dabei sollte b) enthalten: Verweise auf die Sourcen/das SVN, die genutzten Entwicklungsumgebungen unter Windows (MSYS/MinGW) und Linux, Protokolle, kompilierte Binaries zum Anschauen als naja, nicht nightly aber "aktueller Stand der Dinge"-Build, Informationen zu den Frontends (die ich mir ehrlich gesagt leider noch gar nicht weiter angeschaut habe).
c) sollte die Vorschläge/Planung für die nächste Version (MySQL-Storage, History-Funktion, HTTP-Push-Mechanismus) enthalten.
Eventuell sollte man auch einen Extra-Thread für die Monitor-Frontends anlegen, in denen diese kurz vorgestellt und ihre Benutzung erklärt werden. Sicherlich könnte man diese aber auch in b) mit integrieren.

Puuh... wieder viel geschrieben und "neue Ideen" eingebracht. Ich hoffe, ich verprelle damit niemanden, aber ich bin echt begeistert vom "neuen Monitor" und finde es ehrlich schade, dass der aktuelle Stand hier doch irgendwie ein Schattendasein fristet :7.

@Buebchen: Die Sache mit dem Überarbeiten der Storage-/Display-Module und dem "Übersehen" unbekannter Parameter finde ich sehr sinnvoll.
Allerdings fiel mir dazu ein: Warum sollte man nicht die Nachrichten, die von den Auswertern kommen, in eigene Objekte kapseln? Damit könnten die Nachrichtenpakete vom Typ "ZVEImsg", "POCmsg" und "FMSmsg" sein, auch wenn sie dann vielleicht nur Attribute enthalten (Datencontainer eben). Damit würde es die Ausgabe-Methoden geben "Output(ZVEImsg out)", "Output(POCmsg out)" und "Output(FMSmsg out)". Das würde auch ein ähnliches Verhalten abbilden wie Du schriebst: Zusätzliche Attribute der Datenobjekte würden zwar bestehen aber nicht ausgegeben (weil die Methode das Feld nicht kennt und eben nicht darauf zugreift - aus die Maus), ohne dass große Eingriffe in den Code (speziell die Definition der Ausgabemethoden) notwendig wären.

Viele Grüße
Martin

[Buebchen]

Hallo,
[...viel Text:-) ]

Ja, ich bin begeistert von SQLite, entschuldigung ;).

Ich kenne SQLite nicht. Aber ich suche noch eine effektive Methode um die Nachrichten vom Decoder zu den Socketthreads zu queuen oder spoolen. Könnte man nicht sogar eine SQListe-DB (oder mehrere) nehmen ?

Da es ja auch bei der Nutzung von SVN gewisse Standards gibt, möchte ich hiermit vorschlagen, dass /trunk nach /branches/1.9.0 gemoved wird (als Archiv, damit es nicht wegkommt, quasi). Entsprechend ist /trunk dann leer und kann mit den Daten des aktuellen Branches (/branches/2.1.1-mergeWinLin) gefüllt werden, wobei dann hoffentlich keine wichtigen Änderungen aus den anderen 2er-Branches verloren gehen (gut, man könnte nochmal diff-en und nötigenfalls mergen). Damit wäre im /trunk die aktuelle Version 2.0 (ohne die 1en und das mergeWinLin am Ende - brechen wir es auf das eigentliche Ziel herunter), die dann als Feature-Set hat: Plattformunabhängigkeit, Funktionalität (Erkennung, Ausgabe über die drei Sockets in drei Formaten Crusader, FMS32, monitord).

Kann ich nur unterstützen. Sofern nichts dagegen spricht werde ich mit jhr-online absprechen, daß wir mal umsetzen. Ich habe auch schon nem Test-PC ohne drauf zu achten den trunk ausgecheckt und war doch etwas verwundert...

Einen Branch/Branches für die 2.1 oder 2.2 (HTTP-Engine, MySQL-Engine, was auch immer) anzulegen, wäre dann sicher sinnvoll, sobald ein neues Feature implementiert werden soll. Ich möchte auch die Nutzung von Tags anregen, mit denen man ja ganz famos Revisionen im SVN Versionsnummern von Software aufklatschen kann, so dass nach einer Umstrukturierung wie vorgeschlagen direkt der Inhalt von /trunk in /tags/2.0-291107 als lauffähige Version markiert werden könnte und sollte, um lauffähigen Code schnell und einfach auscheckbar zu haben.

Kann ich auch so unterstützen.

@Buebchen: Die Sache mit dem Überarbeiten der Storage-/Display-Module und dem "Übersehen" unbekannter Parameter finde ich sehr sinnvoll.
Allerdings fiel mir dazu ein: Warum sollte man nicht die Nachrichten, die von den Auswertern kommen, in eigene Objekte kapseln? Damit könnten die Nachrichtenpakete vom Typ "ZVEImsg", "POCmsg" und "FMSmsg" sein, auch wenn sie dann vielleicht nur Attribute enthalten (Datencontainer eben). Damit würde es die Ausgabe-Methoden geben "Output(ZVEImsg out)", "Output(POCmsg out)" und "Output(FMSmsg out)". Das würde auch ein ähnliches Verhalten abbilden wie Du schriebst: Zusätzliche Attribute der Datenobjekte würden zwar bestehen aber nicht ausgegeben (weil die Methode das Feld nicht kennt und eben nicht darauf zugreift - aus die Maus), ohne dass große Eingriffe in den Code (speziell die Definition der Ausgabemethoden) notwendig wären.

Viele Grüße
Martin

Details zur Umsetzung sind noch ganz offen. Ich denke der Datentyp map<std::string,std::string> hat halt den Charme, daß man ihn wie ein PHPArray ansprechen kann. Das ganze kann ja dann auch Element einer der Klasse wie bei Dir beschrieben sein. Das ganze dann von einer BASEmsg abgeleitet könnte doch recht zukunftssicher sein.

Ob drei Ausgabemodule mehr oder weniger Sinn machen als eine einzelne Output-Funktion muss ich mal überlegen.

[jhr-online]

Um's nicht zu kompliziert zu machen:

Ich bin voll einverstanden und übergebe hiermit mal ausdrücklich buebchen die ehrenwerte Aufgabe, die Änderungen durchzuführen. Vielleicht sollten die Schreiberlinge kurz vom svn die Finger lassen bis buebchen hier die Durchführung bekannt gibt.
Okay?

jhr

[Buebchen]

trunk ist jetzt die 2.1.1-merginwin.

Die alten branches habe ich in den Ordner branches/discontinued verschoben.
Der alte trunk ist jetzt tags/1.9.0

Hab ich jetzt noch was vergessen ?

[mdi]

Hallo,

Ich kenne SQLite nicht. Aber ich suche noch eine effektive Methode um die Nachrichten vom Decoder zu den Socketthreads zu queuen oder spoolen. Könnte man nicht sogar eine SQListe-DB (oder mehrere) nehmen ?

ja, das könnte man.
SQLite ist eine SQL-Datenbank auf Dateibasis (ein File - eine Datenbank), die mit dem Dateinamen ":memory:" auch rein im Speicher (entprechend flüchtig) Daten halten kann. Das ist allerdings in dem Fall glaube ich nicht so praktisch, da der gesamte Datenbank-Overhead dazu käme, was hier ja nicht nötig wäre.
Wenn aber die Geschichte mit den *msg-Objekten realisiert wird - dann könnte doch einfach eine Datenstruktur (Array, verkettete Liste, ...) die *msg-Objekte pro Thread halten (hält der Thread selber oder soll das gebündelt vor der Übergabe an die Threads passieren?).

Änderung I:
Ich habe mal das anhängende Bild gemalt... ZVEImsg, POCmsg und FMSmsg sind abgeleitet von BASEmsg. Die Display- und Storage-Master sind quasi die Manager der Ausgabe-Module (sprich sie halten eine Liste der bestehenden Display/Storage-Module und geben die eingehenden Nachrichten *msg an die einzelnen Module weiter, können die auflaufenden Nachrichten aber auch queuen, falls bei den Modulen ein Problem auftritt - pro Modul wäre da eine Queue sinnvoll, damit bei fehlerhaftem Verhalten eines Moduls die anderen noch sauber weiterarbeiten können). Ich würde dann bevorzugen, pro Modul eine eigene Ausgabe-Routine pro *msg-Subtyp einzusetzen, damit erst im spezifischen Modul die Ausgabe-Formatierung geschehen muss. Die hier als einzelne Manager gezeichneten "Dinger" könnten auch zu einem Manager zusammengefasst werden, ebenfalls könnte der Manager eine Queue für eingehende *msg haben und die Ausgabemodule bei Bedarf eine eigene Queue halten (das wäre beim HTTP-Push nicht schlecht, weil Antwortzeiten zu berücksichtigen sind, beim monitor-Socket ist das wiederum nicht so wichtig, weil hier keine Zeitgeschichten/Feedbacks zu berücksichtigen sind).

Änderung II:
Mir fiel beim Einkaufen ein, dass genau im Manager (als dem "Sammler" für *msg-Objekte) auch die History-Geschichte (dann gerne in Form einer SQLite-Datenbank im Speicher oder in einer Datei) zu implementieren sinnvoll wäre, das nur als Ergänzung dazu.

Martin

[Buebchen]

Hallo,

Wenn aber die Geschichte mit den *msg-Objekten realisiert wird - dann könnte doch einfach eine Datenstruktur (Array, verkettete Liste, ...) die *msg-Objekte pro Thread halten (hält der Thread selber oder soll das gebündelt vor der Übergabe an die Threads passieren?).

Im Moment sind es getrennte Listen (std::list) pro Thread. Geht auch soweit. Ich würde sie dann ggf. nur denmächst mal in eine Klasse einbetten, da ich immer auch über eine Semaphore sicherstellen muss, da immer nur ein Prozeß die Liste ändert. Nach meiner Meinung müssen die Objekte pro Thread in eine eigene (private) Queue. Sonst könnte ich erst das Element aus der zentralen Queue entfernen, wenn alle Threads es abgearbeitet habe (was dann synchronisiert werden müßte).

Änderung I:
..., können die auflaufenden Nachrichten aber auch queuen, falls bei den Modulen ein Problem auftritt - pro Modul wäre da eine Queue sinnvoll, damit bei fehlerhaftem Verhalten eines Moduls die anderen noch sauber weiterarbeiten können ...

Martin

So in der Art würde ich mir das auch vorstellen können. Dann sollten wir einen Dispatcher als Dreh- und Angelpunkt für die Nachrichten vorsehen. Dieser bedient dann bei ihm registrierte Module (Füllt deren privaten Queues - ggf aber nur bis zu einem Limit von vielleicht 100 Einträge). Ich wüßte im Moment nur nicht, warum ich für Display und Storage verschiedene Dispatcher brauche. Die Daten sind identisch - nur die spätere Verarbeitung nicht. Wenn jedes Modul - wie es schon beim SocketThread ist - seine eigene Queue könnte man die StorageModule genauso behandeln.