monitor 1.9.0 - aber richtig :)

[Buebchen]

Ne Ne Ne ... Warum nicht ein externer DB-Server ? Auch die logfiles muss er irgendwo hinschreiben. Da würde CD-Boot auch nicht gehen, bzw. es wäre fast das gleiche.

Mein Vorschlag: Es gibt eine Option für den Backend-DB Server. Entweder ist er aktiv oder nicht. Danach kann man immer noch klären welche Daten die Clients dann vom monitord anfordern können oder nicht. Ggf. können die Clients auch einfach selbst auf dem DB Server zugreifen. Das kann dann jeder Entwickler selbst entscheiden.

Eine Zwischenstufe (TCP Client speichert in DB) wäre denkbar. Aber es ist m.E. nicht sinnvoll, daß die Clients selbst die Daten speichern müssen. Was macht man, wenn man eben erst den Client startet ? Man hätte keine aktuellen Statusinformationen zu den Fahrzeugen. Aber alle in die "6" oder "2" zu stellen ist auch nicht richtig.
Gerade bei der Nutzung in einer nachbesetzten Führungsstelle ist das eine wichtige Information ("Welche Fahrzeuge sind ausgerückt - und wann ?").

[nepomuck]

Es gibt eine Option für den Backend-DB Server. Entweder ist er aktiv oder nicht.

Folgende Idee, um das Problem zu lösen.

Der eigentliche Backend hat selbst keine DB und schreibt seine Daten per Default in ein klassisches LOG. das kann man auch abschalten.

Es gibt ein SQL-Modul, welches sich regulär per TCP beim Frontend anmeldet und die Auswertungen per ODBC in irgend eine eine SQL-Db schreibt.
Das SQL modul kann auf dem Backend Server oder irgend einer Maschine im LAN arbeiten. Ebenso kann die Db sein wo sie will.

Eine History-Query muss ein Client an das SQL-Modul stellen.
Da sich das SQL-Modul beim Backend anmeldet, kann ein Client-Task bem backend danach fragen und bekommt als Antwort die IP-Adresse des SQL-Moduls.

123 SQL
234 NOPE

oder

123 SQL
234 192.168.23.65:1234

Vorteil: Die DB ist kein zwingender Bestandteil des backends. Falls die DB ausfällt oder der entfernte sql-server nicht antwortet, funtioniert das Backend regulär weiter.

nachteil: Ein Client der Live-Daten und alte daten auswerten will, muss sich mit zwei TCP-Sitzungen mit dem backend und dem SQL modul verbinden. ausserdem müssen wir ein zweites protokoll zur kommunikation zwischen frontend und sql modul entwickeln.

das hat im gegenzug den vorteil, dass ein task der db-auswertungen mit viel sql-traffic ausführt nicht den backend kanal belastet.

Andreas

[Buebchen]

Das geht schon eher so in die Richtung, die ich mir vorstellen könnte.

Das TCP->SQL Modul wäre zwar nicht mein Lieblingsding aber durchaus ok. Dadurch könnte man vor allen Dingen noch ein anderes Problem erschlagen, daß mir in der Praxis schon begegnet ist:

Was macht man, wenn man im Gerätehaus auf einigen Kanälen schlechten Empfang hat ? Richtig: Von einem besseren Standort die ausgewertete Daten holen. Man könnte also in einer Datenbank durch zwei oder mehr solcher Agenten Daten mehrerer monitord sammeln.

Müßte man noch klären, wie die Benutzerdaten verwaltet werden. Ich hatte bisher einfach gegen MySQL Anmeldung geprüft. Konnte man er sich mit den Daten am mysql anmelden (nur als Prüfung), war man auch am "monitord" angemeldet. Der Client konnte sich dann auch am MySQL anmelden (bekam er ähnlich wie nepomuck schon schrieb dann mitgeteilt, wo dieser MySQL zu finden ist).

Hier wäre dann auch direkt das Problem des externen Zugriffs: Hat der MySQL Server eine LAN IP aus Sicht des monitord nützt diese IP einem von aussen (ohne VPN) zugreifenden Client nichts. Man müßte in letzter Instanz auch über ein "masquerading" nachdenken (Fern-Fern-Fernziel).

Ach so:

Vorteil: Die DB ist kein zwingender Bestandteil des backends. Falls die DB ausfällt oder der entfernte sql-server nicht antwortet, funtioniert das Backend regulär weiter.

nachteil: Ein Client der Live-Daten und alte daten auswerten will, muss sich mit zwei TCP-Sitzungen mit dem backend und dem SQL modul verbinden. ausserdem müssen wir ein zweites protokoll zur kommunikation zwischen frontend und sql modul entwickeln.

Nachteil aus meiner Sicht wäre auch, wenn der monitord zwar läuft ich aber im Fall der Fälle keine Auswertungen der Daten machen kann, da der SQL-Agent sich weggehängt hätte.

Ich schaue weniger in die Auswerter aus Neugierde. Eher im Auswertungen zu fahren (Bsp: Ausrückzeiten, Eintreffzeiten) oder Doku zu schreiben.

Als Protokoll zum Backend würde ich vorläufig mysql-Tools nehmen und direkt auf den Server zugreifen. Alles andere ist ggf. schon wirklich komplex. Gerade wenn auch noch Performance dahinter sein soll. Benutzername und PW dafür sind noch zu klären (dynamisch oder static ...)

[nepomuck]

Müßte man noch klären, wie die Benutzerdaten verwaltet werden.

Wie wäre es mit "gar nicht". Warum direkt gegen MySQL schreiben? Warum nicht ODBC, dann kann das SQL-Modul gegen jede SQL-Datenbank schreiben und die Login-Verwaltung ist Sache des ODBC-Treibers.

diese IP einem von aussen (ohne VPN) zugreifenden Client nichts.

Da sträuben sich mir die Nackenhaare! SQL via Internet ohne VPN. Warum sollte das jeman tun wollen? Jedes Linux und jedes Windows beherrscht zumindest PPTP.
Ich meine, wenn du ohnehin mit SQL-Server arbeitest, hängst du sowieso ein PHP/WEB-Frontend davor und kommst von außen daran -- warum also SQL direkt?

Als Protokoll zum Backend würde ich vorläufig mysql-Tools nehmen

was zwangsweise einen installierten MySQL-Client im Backend erfordert.

Gerade wenn auch noch Performance dahinter sein soll.

Wenn Funk-Nachrichten mit maximal 1200 Baud eingehen, ist die Performance glaube ich das geringste Problem.

Andreas

[Buebchen]

Wie wäre es mit "gar nicht". Warum direkt gegen MySQL schreiben? Warum nicht ODBC, dann kann das SQL-Modul gegen jede SQL-Datenbank schreiben und die Login-Verwaltung ist Sache des ODBC-Treibers.

Und woher weiss der SQL Agent, daß die Anmeldung, die da Daten holen will gültig sind ? Wenn ich nen monitor-client habe, der eine History zum Rettungsmittel zeigen soll, dann ist der

* am monitord angemeldet
* am sql angemeldet

... aber mit welchen Benutzernamen und viel wichtiger: wo werden diese zentral gepflegt ? Oder muss man dann immer die Benutzer zweimal anlegen ?

Da sträuben sich mir die Nackenhaare! SQL via Internet ohne VPN. Warum sollte das jeman tun wollen? Jedes Linux und jedes Windows beherrscht zumindest PPTP.
Ich meine, wenn du ohnehin mit SQL-Server arbeitest, hängst du sowieso ein PHP/WEB-Frontend davor und kommst von außen daran -- warum also SQL direkt?

Also mein altes Handy kann mal kein VPN :-)

was zwangsweise einen installierten MySQL-Client im Backend erfordert.

und ? Warum auch nicht ? Wer ihn nicht will kann ihn ja abschalten

Wenn Funk-Nachrichten mit maximal 1200 Baud eingehen, ist die Performance glaube ich das geringste Problem.

Andreas

Wenn ich aus 2 Mio Datensätze die FMS Protokolle eines Standorts für die letzten 24 Stunden filtere und mir anzeigen lassen sind 1200 Baud nicht viel :-)

Wir sollten auf jeden Fall drei Fälle unterscheiden.

1. Ein "Textbasierter Client" wie bisher
Er fragt weder einer Historie ab, noch sonst was. Braucht auch keine DB

2. Ein grafischer Client - Vielleicht eine Mischung aus Crusader und FMS32
Der könnte z.B. schon Daten aus der History-DB abfragen können

3. Ein erweiterter Client, der neben der reinen "Ansicht" der Funkdaten weitere Aufgaben übernimmt (Einsatztagebuch, Meldungsverwaltung, Patientenerfassung,...) und diese mit den Daten der History-DB verknüpft.

Nun ja. Erstmal nicht sooo wichtig. Ich werde definitiv eine Datenbankanbindung schreiben. Wer sie nutzt, kann das tun. Wer sie nicht will schaltet sie eben ab. Wichtiger ist das TCP Protokoll. Sonst gibts auch vorläufig keine Clients.

[nepomuck]

Und woher weiss der SQL Agent, daß die Anmeldung, die da Daten holen will gültig sind ?

SQL-Agent meldet sich am Backend an -- User meldet sich bei Backend an -- User fragt Backend nach SQL -- Backend übermittelt dem User die IP des SQL-Agenten UND sendet dem SQL-Agenten die IP des Users zu und bestätigt damit, dass er ran darf.

Also mein altes Handy kann mal kein VPN :-)

Einen MySQL-Client wird's dann ja auch nicht haben.

und ? Warum auch nicht ? Wer ihn nicht will kann ihn ja abschalten

Ohne MySQL-Client plus Headers und Libs läuft dann wieder kein Make durch. Oder es kommt ein neues Distributionsupdate mit einem neuen MySQL-Client raus der evtl. nicht zum Code passt und dann hängt wieder alles.
Je weniger Dependencies das Backend hat, umso besser.
Und ich würde Bosix 0.2 liebend gerne von einem USB-Stick anstelle einer CD booten und dafür würde ich die Linux-Distribution gerne so klein wie es irgend geht machen.

MySQL-Client = 5.6 MB. Libs and Headers = 7.3 MB Shared Libs = 1.6 MB
macht 14.5 MB
MyODBC = 2.5 MB

Wenn ich aus 2 Mio Datensätze die FMS Protokolle eines Standorts für die letzten 24 Stunden filtere und mir anzeigen lassen

OK. Aber für das Data-Mining kannst du ja eine Applikation schreiben, die direkt auf MySQL zugreift. Für das Backend würde ODBC genügen.

1. Ein "Textbasierter Client" wie bisher

der nur eine TCP-Verbindung zum Backend herstellt

2. Ein grafischer Client

der per TCP mit dem Backend und dem SQL-Agenten in Verbindung steht

3. Ein erweiterter Client

Der per TCP mit dem Backend und per MySQL-CLient mit der Datenbank in Verbindung steht.

Andreas

[Buebchen]

Einen MySQL-Client wird's dann ja auch nicht haben.

Aber ein SDK für Java. Und das kann Datenbankzugriffe. Aber eben kein VPN.

Ohne MySQL-Client plus Headers und Libs läuft dann wieder kein Make durch. Oder es kommt ein neues Distributionsupdate mit einem neuen MySQL-Client raus der evtl. nicht zum Code passt und dann hängt wieder alles.
Je weniger Dependencies das Backend hat, umso besser.
Und ich würde Bosix 0.2 liebend gerne von einem USB-Stick anstelle einer CD booten und dafür würde ich die Linux-Distribution gerne so klein wie es irgend geht machen.

MySQL-Client = 5.6 MB. Libs and Headers = 7.3 MB Shared Libs = 1.6 MB
macht 14.5 MB
MyODBC = 2.5 MB

Die Grössen sind aber doch nicht nur die benötigten libraries. Das betrifft doch nur die build Umgebung. Die dll und shared-lib für mysql haben um die 1MB. ODBC weiss ich nicht.

Soll an dieser Stelle auch erstmal egal sein. Ich werde das in eine virtuelle Funktion packen. Das DB Backend wäre dann mal generell austauschbar. Vielleicht auch eine Klasse, die die Daten repräsentiert.

der nur eine TCP-Verbindung zum Backend herstellt

der per TCP mit dem Backend und dem SQL-Agenten in Verbindung steht

Der per TCP mit dem Backend und per MySQL-CLient mit der Datenbank in Verbindung steht.

Andreas

Das hätte mein Full-ACK.

Die Geschichte mit SQL-Agent fragt monitord nach Useranmeldung etc ist vom Gedanken her gut. Bin mir nur noch nicht so sicher, ob das dann im technischen Detail auch ohne Probleme klappt.

Werde mir mal die aktuellen ODBC Varianten bei Gelegenheit mal anschauen. Vielleicht tritt da ja noch ein Sinneswandel bei mir ein.