monitor 1.9.0 - aber richtig :)

Zitat:

---

Zitat von Norad

Für den Direktzugriff auf die DB müssen GUI- und DB-Frontend sich bloß auf eine Datenbankstruktur einigen

---

Das ist ein wunder Punkt. Ich habe mir gerade die Datenbankstruktur des aktuellen MySQL-Frontends angesehen. Die Tabellen werden wir so nicht beibehalten können. Bislang übernimmt ja der Monitor eine Reformatierung und Filterung der Events. Das ist künftig nicht mehr der Fall da das Backend die Rohdaten in die SQL-Datenbank schickt. Dazü genügt im Prinzip seine sehr einfache Datenbankstruktur.

Soll ich mir da mal was ausdenken, oder möchte das lieber einer der Frondend-Entwickler tun, der später später seine Anwendung an die DB andocken muss?

Andreas

Morsche zusammen!

Also bei der Diskussion eben zum Thema Datenbank ist mir auch bischen schwindelig geworden. Die Komplexität ist in der Tat explodiert. Da müssen wir nochmal ansetzen an der Ecke.

Also einig darüber, dass der monitor keine DB-Anbindung hat und auch keine Log's schreibt sind wir uns?

Es bleibt jetzt nur zu klären, wie eine Datenbank an den monitor angebunden wird und wie entsprechende GUI's dann auf die Datenbank zugreifen können.

Mein Vorschlag wäre folgender :

Variante 1 : Es ist keine DB installiert

Sämtliche Clients (GUI's bzw. Frontends) verbinden sich direkt an den monitor. Da der monitor keine Benutzerverwaltung hat, gibt es nur einen Standarduser zum Verbinden. monitor und Frontend unterhalten sich über das "normale" Monitor-Datenprotokoll. Nachteil ist, dass der Client nur die Live eingehenden Daten anzeigen kann, da es ja eben keine Datenbank gibt. Für eine SMS-Alarmierung oder ähnliches ist dieser Zustand aber durchaus in Ordnung, da hier eh keine History-Daten interessieren.

Variante 2 : Es gibt eine DB-Middleware

Eine entsprechende DB-Middleware hat sich per TCP an den monitor angedockt und bekommt von dort die Rohdaten, um diese in die Datenbank zu schreiben. Sämtliche Frontends verbinden sich nun mit dieser DB-Middleware direkt, die nach außen hin jetzt als Backend fungiert. Sich über einen zweiten Kanal nochmal mit dem monitor verbinden halte ich für sinnlos, da alle Daten vom monitor eh an die Datenbank geschickt werden. In der Datenbank sind jetzt verschiedene Benutzerkonten und Benutzerrechte konfigurierbar und die Frontends können per Sessionhandling überwacht und gesteuert werden. DB-Middleware und Frontends unterhalten sich jetzt auch über das Monitor-Protokoll, welches um Befehle für den Datenbankzugriff (History) erweitert wurde. So kann ein Frontend jetzt aus der Datenbank z.B. die letzten 100 Statis eines Fahrzeugs abfragen o.ä.

Prinzipiell bleibt egal bei welcher Methode zu klären, WAS genau die Datenbank speichert und was man Abfragen kann. Reicht es die Daten in einer Tabelle als Rohdaten abzulegen oder muss/soll/kann die DB-Schicht schon erste Auswertungen vornehmen und die Daten in unterschiedliche Tabellen speichern? (Letzter Status eines Fahrzeugs z.B.) Und welche Funktionen kann ein Frontend dann von der DB benutzen? Gibt es vorgefertigte Funktionen wie "HoleLetzteXXEinträge" oder gestalten wir das so flexibel, dass man SQL-Anfragen an die Datenbank schicken kann?

Gruß Joachim

PS.: Heut Abend kommt irgendwann ne erste Protokollversion.

Hier meine Vorlage zum Protokoll. Ich denke es ist soweit alles grundsätzliche drinne erstmal. Über die Befehlsliste müsst ihr mal drüber gucken. Fürn Anfang sind mir nicht mehr eingefallen. Wenn wir uns dann über einen Mindestsatz an Befehlen geeinigt haben, mach ich Punkt 6 ausführlich. Dann bekommt jeder Befehl ne eigene Beschreibung.

Soweit erstmal!

Gruß Joachim

Hi MiThoTyN,

ich habe mir das Protokoll seit mal angeschaut. Ist doch ein wenig anders als z.B. SMTP, da die erste Ziffer nicht "Info, Warnung, Fehler" signalisiert, sondern direkt spezifisch auf die genutzten Funktionen eingeht.

Wenn man (bzw. ich) das kapiert hat, dann versteh' ich das ganze soweit auch. Einiges ist auch für die Zukunft noch frei. Werde das - sobald ich an dem Punkt bin - also mal anfangen umzusetzen. Dabei ergeben sich zwangsläufig weitere Fragen. Aber die Struktur ist ja nun klar.

Du willst anfangen umzusetzen, also Code zu produzieren? Hälst du es nicht für besser, erst dafür zu sorgen, dass das Konzept allen willigen Entwicklern klar ist und dann ein wenig abzusprochen, wie entwickelt werden soll und wer was macht und so?

jhr

Zitat:

---

Zitat von jhr-online

Du willst anfangen umzusetzen, also Code zu produzieren?

---

Hmmmmmmmm --- Ja !

Den Kern habe ich relativ schnell umgesetzt, da ich einiges an Vorarbeit geleistet habe. Alles andere ist ja erstmal nicht meine Baustelle.

Und bei den Frontends ist genug zu tun. Aber wie soll jemand ein Frontend entwickeln, wenn es kein Backend gibt ?

Das Backend wird sich ebenso weiterentwickeln. Es ist aber sicherlich einfacher, wenn ein mögliches Backend erstmal da ist, um es anzupassen und weiterzuentwickeln.

Zitat:

---

Zitat von jhr-online

Hälst du es nicht für besser, erst dafür zu sorgen, dass das Konzept allen willigen Entwicklern klar ist und dann ein wenig abzusprochen, wie entwickelt werden soll und wer was macht und so?

---

Mir geht es auch nicht darum direkt mit allem fertig zu sein. Aber ich habe die Module für ZVEI/POC und FMS als C++ Klassen umgesetzt. Wenn das als Basis bereitsteht ist die Arbeit an Dingen wie der Datenhaltung und Client-Kommunikation erheblich einfacher.

Mein Beitrag ist im Grunde auch nur eine Fleissarbeit. Ich habe den monitor entwirrt und die Decoder als C++ Klassen gekapselt. Alles andere steht noch nicht fest und wird ja auch fast täglich neu diskutiert.

wenn die Essenz des Ganzen, das Protokoll, steht und von allen Entwicklern abgesegnet ist, kann doch nicht mehr viel schiefgehen. Egal, ob das Back- oder die diversen Frontends noch geändert werden, solange sie sich an das Protokoll halten, sollten alle miteinander auskommen. Nur diese gemeinsame Sache sollteunbedingt festgemacht werden von allen Beteiligten.
Danke Dir Buebchen, dass Du schon so viel Vorarbeit geleistet hast - auch wenn es nach Deiner Aussage nur Fleißarbeit ist, gemacht werden muss sie ja.

Gruß,
Funkwart

Zitat:

---

Zitat von Buebchen

Mir geht es auch nicht darum direkt mit allem fertig zu sein. Aber ich habe die Module für ZVEI/POC und FMS als C++ Klassen umgesetzt. Wenn das als Basis bereitsteht ist die Arbeit an Dingen wie der Datenhaltung und Client-Kommunikation erheblich einfacher.

Mein Beitrag ist im Grunde auch nur eine Fleissarbeit. Ich habe den monitor entwirrt und die Decoder als C++ Klassen gekapselt. Alles andere steht noch nicht fest und wird ja auch fast täglich neu diskutiert.

---

Ich verstehe! Genau das festzuhalten (was du bereits gemacht hast und wie der Stand ist, an dem andere anknüpfen können), war mir sehr wichtig.

Ich halte dich also nicht davon ab, jeglichen Rummel ins svn hochzuladen :). Dann schauen wir mal, wer wo weiter macht. Wenn es etwas klarer wird und die anderen deinen Code kennen, lässt sich sicherlich ein Paln im Wiki aufstellen und vernünftige Bugs schreiben, die zugewiesen werden können.

Danke,
jhr

wenn das backend steht und ich es habe schieß los ^^

ne nu ma richtig.

es ist sher loblich das du buebchen dir die Arbeit gemacht hast, den monitor in einen dienst zu ändern und in c++ konvertiert hast.

Ich denke das umschifften und um modelieren ist schon mal eine gute idee um die zeit des "diskutierens" zu überbrücken in der dann das Kommunikationsprotokoll besprochen und entwickelt wird.

Und ich denke das wir irgendwann an einem Punkt stehen, wo wir mit "deinem" backend "unser" frontend entwickeln können. Und ich hoffe das ziemlich zeit nah :D

denn ich freue mich ehrlich gesagt schon den monitor auf einer grafischen Umgebung zu sehen !!!!!

Das Protokoll von MiThoTyN ist ein sehr guter ansatz. Sicherlich kommen dort noch neue Punkte hinzu. Aber der Anfang ist da und das ist gut. Thx MiThoTyN :D

so nu will ich mitm quacksalbern aufhören denn ich muss weiter arbeiten, dis die tage

Zitat:

---

Zitat von MiThoTyN

Hier meine Vorlage zum Protokoll.

---

Danke für die Mühe und den Entwurf

Ich hätte da noch ein paar Punkte anzumerken:

Befehle 101,201 Error, Datenfelder 0
Ein Error ohne Beschreibung hilft in der Regel nicht weiter. Ich empfehle, dass wir dem Befehl ein Datenfeld mit einem Fehlercode anhängen und in der Protokolldefinition fehlercodes deklarieren, Beispiel:

101:001
Error:Server kann auf Sounddevice nicht zugreifen
101:034
Error:Benutzeranmeldung fehlgeschlagen
201:124
Error:Client unterstützt Protokollversion nicht

Dazu auch ein Vorschlag für ein weiteres Kommando:
111 Versionsnummer (Serverversion)
112 Protokollversion

Befehle 330,430 DTFM
Da sollten wir klären, ob wir diese Befehlsgruppe überhaupt brauchen. DTFM kommt sowieso nur in Verbindung mit einer ZVEI-Alarmierung vor, daher könnte man den DTFM-Code direkt mit der ZVEI-Alarmierung übertragen. Das hätte den Vorteil, dass der Client nach einem 5-Ton Alarm nicht eine gewisse Zeit warten muss, ob noch eine DTFM-Anweisung folgt oder nicht.

Zitat:

---

inklusive Trennzeichen und Zeilenende nicht länger als 512 Byte ist.

---

Da sollte bitte mal jemand, der sich mit FMS auskennt prüfen, wie lange Folgetelegramme sein dürfen. Da könnten 512 Byte evtl nicht reichen, vor allem, da wir die textmeldung hex codieren und daher pro character zwei Byte brauchen.

Andreas

Hallo!

Kann zwar leider nicht programmieren..

aber hätte da noch 2 Vorschläge...

das wäre zum einen die Einbindung des FMS-AuftragsText der Leitstelle

und zum anderen die Positionsmeldungen der einzelnen Fz an die Leitstelle via GPS (Stat 10)

73,

Daniel

ich möchte noch mal auf die datenbank anbindung ansprechen.
Wie wäre es wenn wir ein Modul schreiben das im monitord verankert ist das auf wunsch zu geschaltet werden kann.

Ich finde es einbischen umständlich wenn ich die daten in einer db speichern möchte, es über den deamon zu gehen das zu eines clienten zu schicken der das in eine Datenbank schreibt.

Fällt mir geradeso auf :Im TCP Protokoll fehlt noch ein Logout Kommando vom Client zum Server. Wäre im Bereich 2xx anzusiedeln. Ich würde 299 vorschlagen.

Wie soll ein Login eines Clients zum Server aussehen ? Erstmal im Klartext, richtig ? Also ungefähr so:

Server:
120:Please login !:

Client:
220:Harry:Hirsch:

Wobei "Harry" der User ist und "Hirsch" sein PW.

Danach käme dann

Server: 121:Login accepted:

oder

Server: 122:Login incorrect !:

Schließen wir die letzten Parameter mit ":" ab ? Ist in der PDF nicht ganz eindeutig. Aber sieht danach aus.

ich mit : am ende abschließen, damit man weiß, es ist wirklich zu ende.

Thema Login:
Ich würde das PW trotzdem irgendwie verschlüsselt rüberschicken. Sei es jetzt md5 oder base64 oder was auch immer.
Auch in der Probephase bzw Programmierphase

Hallo zusammen!

Habe momentan wenig Zeit, deswegen melde ich mich jetzt erst. Zu den ganzen Anmerkungen zum Protokoll:

@nepomuck

Die Sache mit dem Fehlercode ist gut. Das kann man als Datenfeld noch eintragen. Werd ich mal ins PDF aufnehmen.

111 als Version ist ja schon drinne. Eine Protokollversion ist auch sinnvoll. Den Befehl sehe ich auf beiden Seiten vor. Der Server teilt seine Protokollversionen mit und der Client bestimmt, welche genommen werden soll.

Ob DTMF drinne sein soll oder nicht hängt davon ab, ob der monitor ein reiner BOS-Auswerter sein soll, oder sich wie bisher durch die Module auch erweitern lassen soll. Dann kannste DTMF auch eigenständig laufen lassen. Der Sirenendoppelton wird beim ZVEI mit ausgegeben.

FMS-Text besteht aus maximal 99 Zeichen. Sagen wir 100 Byte. Als Hex 200 Byte. Bleiben 312 für den Rest. Langt dicke. POCSAG hat keine definitive Längenvorgabe, sollte aber auch dicke mit 512 Byte auskommen. Aber zur Not nehmen wir einfach 1024 Byte. Sollte halt Problemlos in den Zeilenpuffer des Frontend-Auswerters passen.

@Buebchen

Abschließender Doppelpunkt wird nicht benötigt. Die Zeile wird ja mit CR/LF abgeschlossen. Der Doppelpunkt trennt nur aufeinanderfolgende Datenfelder.

Solche Klartextübertragungen wie "Please login" sind eigentlich nicht nötig. Oder was meinst du? Ein Login sähe nach meiner Meinung z.B. so aus :

120
220:Harry:Hirsch
122

Passwort kann auch gerne verschlüsselt werden. Da die Passwörter auf beiden Seiten ja bekannt sind, kann man hier ne Einweg-Verschlüsselung nehmen und die beiden dann einfach miteinander vergleichen. Müssen wir nur jetzt im Vorfeld festlegen und uns auch auf eine Verschlüsselung einigen, die in vielen Programmiersprachen vorhanden ist. Oder wir lassen über einen zweiten Befehl auch das Anmelden im Klartext zu.

Logout Kommando wird auch noch eingefügt. Auch auf beiden Seiten. So kann auch der Server die Verbindung zum Client beenden.

Gruß Joachim