monitor 1.9.0 - aber richtig :)

[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.

[Buebchen]

Ich habe nun begonnen, noch einen Dispatcher für die Nachrichten der Auswerter zu schreiben.

Vom Ablauf stelle ich mir es dann so vor:

1. Modul meldet Daten in einem einheitlichen Format (z.B. std::map) an Dispatcher (z.B. FMS Auswertung)
2. Dispatcher (eigener Thread, Auswerter läuft also ohne Unterbrechnung weiter) verteilt Daten an SocketServer und Plugins (Jeweils eigene Threads)
3. SocketServer und Plugins erstellen dann für sich die passenden Strings, die dann weiter verarbeitet werden (SocketServer an die einzelnen SocketThreads)

[mdi]

Hallo,

ich habe immernoch ein Problem mir vorzustellen, was und warum genau mit dem <std::map> gearbeitet werden soll :7.

Die Sache mit den Datenobjekten finde ich da einfacher, weil (wie geschrieben) dann eine Oberklasse BASEmsg ausreicht, um egal welche Daten überall im Kern durchzuschieben ohne sich um die innere Struktur kümmern zu müssen (braucht da ja auch niemand).

Vielleicht könnte man es dann auch sinnvoll implementieren, dass diese Daten-Objekte ihre eigene "getFMSProData", "getmonitordData", "getCrusaderData"-Routine mitbringen, so dass die Aufbereitung der Daten für die verschiedenen Ausgabeformate der Kernfunktionalität des monitord prinzipiell dem Autor der jeweiligen Auswerter- bzw. Datenobjekt-Klassen obliegt aber frei anpassbar ist für kommende Entwicklungen ohne dass die Ausgabe-Klassen extra angefasst werden müssen (die bekommen dann ein Datenobjekt BASEmsg bzw. dessen Ableitung in z.B. FMSmsg, und fordern es auf, seine Daten selber sinnvoll auszugeben bzw. sie sinnvoll formatiert als String an das Ausgabemodul zurückzugeben).

Hm... ja. So weit.
Martin

[Buebchen]

Hallo,

ich habe immernoch ein Problem mir vorzustellen, was und warum genau mit dem <std::map> gearbeitet werden soll :7.

Die Sache mit den Datenobjekten finde ich da einfacher, weil (wie geschrieben) dann eine Oberklasse BASEmsg ausreicht, um egal welche Daten überall im Kern durchzuschieben ohne sich um die innere Struktur kümmern zu müssen (braucht da ja auch niemand).
Martin

Ich glaube, die abgeleiteten Klassen mit klassischen Membervariablen finde ich in sofern unflexibel, daß jedes neue Feld dann im Source-Code hinzugefügt werden muss, bevor man es verwenden kann. Eine dynamische Struktur wie die map hat hat so ein Problem nicht. Dennoch kann man die map ja in eine Klasse packen, die den Zugriff auf die Daten nochmal kapselt und überwachen kann. Hin- und herschieben kann man so eine Klasse auch ganz prima :-)

Wenn man irgendwann beschließt aus einem optionalen Backend (z.B. Datenbank) ein Feld "Fahrzeugname" in den Datensatz einzufügen wäre das möglich (Durch ein "PreDispatcher" Plugin könnten die Daten ergänzt werden.) Und das ohne, die Klassendefinition anpassen zu müssen. Gleiches gilt dann für ein vorhandenes StorageModul. Es kann die ergänzten Daten lesen und nutzen, wenn es sie abfragt. Und das alles ohne SourceCode Änderung. Und andere Module sind davon unbeeindruckt.

Da fallen mir einige Möglichkeiten ein, um den monitord an ganz verschiedene Bedürfnisse anzupassen. Ich z.B. fände es toll, wenn ein Fahrzeugname schon vor dem Weiterleiten an die Clients ergänzt wird. Oder z.B. auch der POCSAG-Text der letzten Alarmierung. Oder der vorherige Status (wenn es ein FMS Protokoll ist)...

Sagen wir also mal, daß ich denke die map ist kein Erschwernis (sofern man damit leben kann, daß alle Daten als String behandelt werden) sondern eine Option für die Zukunft :-)

[nepomuck]

Kurze Bitte:

Könnte einer von euch mal prüfen, warum bei mir nicht einmal das configure-Skript durchläuft? Ohne das kein make und ohne Make kann ich aktuell gar nichts testen.

Andreas

[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

[mdi]

Hallo,

Sagen wir also mal, daß ich denke die map ist kein Erschwernis (sofern man damit leben kann, daß alle Daten als String behandelt werden) sondern eine Option für die Zukunft :-)

ja, da muss ich Dir (nachdem ich endlich verstanden habe, wozu die da sein soll - ich habe da total auf dem Schlauch gestanden) zustimmen, das ist sehr flexibel für mögliche Module, die die von Dir angebrachten Änderungen (Mapping Nummern->Namen, wie auch immer) durchführen. Das würde allerdings bedingen, dass wir drei verschiedene Arten von Modulen haben - Decoder, verarbeitende Module vor der Verteilung an die Ausgabemodule und eben diese Ausgabemodule, richtig?

Da möchte ich doch noch die Frage in den Raum werfen, ob eine derartige Datenzusammenführung nicht clientseitig oder durch eine Datenbank besser aufgehoben wäre.

@nepomuck:
Die Sirenentonerkennung sollte jetzt für alle möglichen Alarme funktionieren, allerdings werden alle zur Zeit noch als Typ 2 deklariert, wodurch der Subtyp nur im Klartext der Message erscheint (Sirenenauslösung: [Probe|Feuer|...]).

Martin