monitor 1.9.0 - aber richtig :)

[Buebchen]

Chatten ginge im Grunde auch mal ausnahmsweise während der Arbeit. Sofern sich keiner wundert, daß ich mal für 20 Minuten abwesend wirke (weil dann ggf. ein Anruf reinkommt) - ich würde aber schon weiterhin mitlesen.

Ansonsten wäre mir ab 21:00 Uhr recht. Da ist die Change da, daß ich ein wenig Ruhe habe (Kinder im Bett :-) ).

[Buebchen]

Vorschlag:
Es gibt den bereits angesprochenen Launcher, der die monitord-Konfigurationsdatei auswertet und entsprechend viele monitord-Instanzen startet. Der Launcher besitzt einen TCP-Port über den er Steuerkommandos mit EINER Frondend-Anwendung (wie einem "Monitor Manager") abwickelt.

Ähh. Hast Du ne Zeitmaschine oder so ?

Ich würde mir da nicht zu viel auf einmal vornehmen, sonst kommt am Ende erst mal gar nichts raus. Ich sehe erst einmal keinen Grund, das Backend auf Windows zu portieren. Und beim Frondend ist ohnehin alles möglich, denn es gilt nur, die Daten eines TCP-Listeners auszuwerten.

Den Port zu Windows habe ich zu eigenen Zwecken schon vor ein paar Jahren gemacht. Sofern etwas von meine Modulen einfließt wäre es eher ein Backport :-)

Ich würde daher folgende Vorgehensweise vorschlagen:

• 1. Code entwirren und modularisieren (Buebchen)
  2. Backend "monitord" und Launcher bauen (Buebchen)
  2a. TCP-Kommunikatiosnprotokoll für Daemon und Launcher festlegen, Struktur der Config-Dateien festlegen (Nepomuck, Buebchen)
  3. Ausführliche Tests des Backends (Nepomuck) und Debugging (Buebchen)
  4. Bestehenden Frontend-Code zu "Frondend-Classic" konvertieren (Buebchen)
  5. Neues MySQL-Frontend erstellen -- dazu müssten Perl-Skripte völlig ausreichen (?)
  6. Testing der Frondends (Nepomuck u.v.a.) Dokumentation von Frond&Backend, der Konfigurationsdateien und den TCP-Protokollen (Nepomuck)
  7. Release 2.0
  7a. Release Bosix 0.2 :-)
  8. Spinnof diverser Frontends (Windows, Mac, Java, was-auch-immer)
  9. Projekt "Monitor Manager" als Control-Applikation für ein oder mehrere monitor Server
  10. Entwicklung des @rec-Streamings für die Backend-Version 2.1

...

Andreas

Grundsätzlich würde ich das nicht alleine schaffen können. Deswegen bin ich froh, daß es noch andere Entwickler gitb. Neben diesem Projekt habe ich noch ein Hardware-Projekt laufen (4fach Besprechungsstelle mit Headset-Möglichkeit und PC Fernsteuerung - µC gesteuert) und ausserdem noch meinen "Dauerbrenner" Einsatzunterstützungsprogramm - der läuft schon seit Jahren. Da kommt dann auch der Windows-Port her.

zu 4: Alles was das Frontend angeht ist ManuelW unser Mann (sofern er will). Ich könnte das zwar auch noch machen aber dann würde es wohl noch einige Zeit dauern, bis ich dazu komme...

zu 5: Ok, das habe ich nicht kapiert. Aber ich kann ja mal beschreiben, wie ich das für mich gelöst habe (bzw. meinen Lösungsansatz):
Ich habe einen Dienst, der die Telegramme auswertet und in eine MySQL-DB schreibt (monitord). Nun habe ich einen zweiten Dienst (Verarbeitungsserver) der alle "interessanten" Änderungen in der Datenbank erkennt und an die Clients, die sich per TCP verbunden haben meldet. Dies geschieht in der Form: "Änderungen FMS - Zeile 45000 ist neu, Einsatzmittel dazu hat den ID-Wert 5500". Nun kann jeder Client selbst entscheiden, ob ihn das interessiert und holt sich bei Bedarf den kompletten Datensatz aus der Datenbank.

Alles andere ist erstmal ok. Verteilung und Roadmap kommt dann sicherlich im IRC/TelCo/wo-auch-immer.

[Dove]

Den Port zu Windows habe ich zu eigenen Zwecken schon vor ein paar Jahren gemacht. Sofern etwas von meine Modulen einfließt wäre es eher ein Backport :-)

da möchte ich wxWidgets für C++ vorschlagen.
Damit entwickeln wir einen Sourcecode und kompilieren den unter win und unix ohne was dran geändert zu haben.

[nepomuck]

Ähh. Hast Du ne Zeitmaschine oder so ?

Nein, warum?

zu 5: Ok, das habe ich nicht kapiert. Aber ich kann ja mal beschreiben, wie ich das für mich gelöst habe (bzw. meinen Lösungsansatz):
Ich habe einen Dienst, der die Telegramme auswertet und in eine MySQL-DB schreibt

Ach so. Ich dachte, es würde genügen stumpf und uninterpretiert alles was vom Backend kommt erst einmal in eine DB zu schreiben und einem anderen Task das spätere auswerten zu überleassen.

Ich hatte nur die Idee, den MySQL-Teil als eigenes Modul vom bestehenden Frontend zu trennen, so das man den Monitor auch ohne MySQL betreiben kann.

Andreas

[Buebchen]

Nein, warum?

Weil Du geschrieben hast "es gibt ...". Da bin ich gerade mal ein wenig verwirrt. Gibt es einen Launcher für den monitord ?

Ach so. Ich dachte, es würde genügen stumpf und uninterpretiert alles was vom Backend kommt erst einmal in eine DB zu schreiben und einem anderen Task das spätere auswerten zu überleassen.

Ich hatte nur die Idee, den MySQL-Teil als eigenes Modul vom bestehenden Frontend zu trennen, so das man den Monitor auch ohne MySQL betreiben kann.

Die Trennung finde ich ok. Warum auch nicht. Man muss ja auch nicht in die SQL Datenbank schreiben. Für mich ist die Funktion wichtig. Ich will insbesondere FMS und Alarmierung dokumentiert wissen. Aber andere können bestimmt ohne leben.

@Dove: wxWidgets hatte ich mir mal angeschaut. Sah nicht schlecht aus. War mir zu dem Zeitpunkt aber zuviel Einarbeitung :-( Für das Backend zum Glück auch erstmal nicht erforderlich.

[Dove]

@Buebchen:
für das Backend ist das wirklich nicht erforderlich.
Für das Frondend sicherlich eine gute möglichkeit.

Muss man gucken wie man das realisiert oder was für andere Vorschläge noch kommen bzw welche, die hier schon vorgestellt wurden, anklang finden.

In wxWidgets bin ich grade drin :D

[nepomuck]

Man muss ja auch nicht in die SQL Datenbank schreiben. Für mich ist die Funktion wichtig. Ich will insbesondere FMS und Alarmierung dokumentiert wissen.

Mir ist das auch wichtig -- aber auf getrennten PCs. Auf dem eigentlichen Monitor-Rechner soll kein MySQL laufen, da dieser von CD startet (Bosix) und da würde eine aktive SQL-Datenbank nur stören.
Ich habe einen MySQL-Server im Netz und der soll die Daten erhalten.

Andreas

[Buebchen]

Mir ist das auch wichtig -- aber auf getrennten PCs. Auf dem eigentlichen Monitor-Rechner soll kein MySQL laufen, da dieser von CD startet (Bosix) und da würde eine aktive SQL-Datenbank nur stören.
Ich habe einen MySQL-Server im Netz und der soll die Daten erhalten.

Andreas

Habe ich auch so gemacht. MySQL läuft am besten auf oder "neben" dem Webserver, da diese intensiver Daten austauschen. Der monitord schickt im Vergleich dazu nur geringe Datenmengen.

Die Frage ist also eigentlich, ob der monitord direkt in die SQL-DB schreibt, oder aber ein angemeldeter Client (=Robot) das erledigt.

[funkwart]

Hallo Forum,

hier tut sich ja gewaltig etwas! Sehr gut, ich bin gespannt, was bei Euren Bemühungen herauskommt.
Leider kann ich nur wenig hier beisteuern, weil ich leider nur begrenzte Ahnung in den Bereichen Programmierung, Netzwerk, DB habe.
Trotzdem denke ich, dass es doch relativ egal ist, wo der MySQL Server läuft, auf dem die Daten gesammelt werden. Wenn man dem Backend angeben kann, unter welcher IP der MySQL-Server erreichbar ist, ist es doch schnurzpiepe, ob der auf 192.168.x.y oder 127.0.0.1 läuft. Der User muss halt nur, wenn er MySQL-Unterstützung auswählt, einen Server einrichten und die Adresse angeben.
Oder habe ich da was falsch verstanden?

Gruß,
Funkwart

PS: Als Tester stehe ich natürlich gerne zur Verfügung. ;-)

[Buebchen]

Also von meiner Seite aus wäre es gut, daß Kommunikationsprotokoll zügig zu definieren. Denn ohne geht es auf beiden Seiten der Entwicklung wohl nicht so recht weiter :-)

Habe im bts.jhr-online.de dazu mal einen Eintrag erstellt ( http://bts.jhr-online.de/?do=details&task_id=8 ) und wäre für Vorschläge dankbar.

[Edit]
Mein Favorit wäre übrigens XML. Da sind Erweiterungen leicht zu realisieren und ältere Clients finden trotzdem "Ihre" Daten im XML wieder.

[MiThoTyN]

Tach zusammen!

Zum Thema Datenprotokoll möcht ich mich auch mal einklinken. Ich werde sicher auch den ein oder anderen Client von mir auf den Monitor dann anpassen. Und da z.B. auch der Crusader ein eher schlechtes Protokoll verwendet, sollte das beim monitor tatsächlich sehr durchdacht sein.

Zur Auswahl stehen ja zur Zeit zeilenweise Datensätze mit Trennzeichen, oder XML. Ich sehe in der Zeilenweisen Kommunikation den Vorteil, dass vor allem der Client beim Auswerten der Daten sehr einfach gehalten werden kann. Zeile einlesen, an Trennzeichen trennen, und die einzelnen Parameter verarbeiten. Fertig. Bei XML müsste man einen größeren Umstand betreiben und einen XML-Parser benutzen. Das erhöht den Aufwand zum Empfang und zur Auswertung und vor allem auch den Datenverkehr auf der Schnittstelle. Gerade der Datenverkehr sollte sehr gering gehalten werden, um auch Handys oder PDA's nicht zu benachteiligen. Denn hier bezahlt man nach wie vor hauptsächlich pro Datenmenge.

Den Hauptvorteil von XML, das Protokoll flexibel zu erweitern und dabei Abwärtskompatibel zu halten sehe ich übrigens nicht. Bei ZVEI, FMS und POCSAG sind die zu übertragenden Daten konstant und ändern sich nicht mehr. Auch was Benutzeranmeldung und die wichtigsten Steuerbefehle angeht, kann man hier ein minimum definieren, was jede Version beinhaltet. Somit können alte Clients auch mit moderneren Servern kommunizieren. Die Clients können dann halt die "neuen" Features nicht benutzen und ignorieren diese einfach.

Sollte es tatsächlich mal nötig sein das Protokoll grundlegend zu ändern, kann man im Server ja einen Kompatibilitätsmodus einbauen. Der Client teilt dem Server mit, welche Version er hat und der Server entscheidet dann, welche Protokollversion für diese Verbindung benutzt wird. Ist vielleicht etwas mehr Aufwand im Server, aber sollte meiner Meinung nach nicht sehr schnell akut werden. Bei entsprechend modularisierter Bauweise des Servers, wird dazu dann eh nur ein anderes Protokoll-Modul benutzt. Mit solchen Modulen ließe sich auch nach entsprechendem ersten Handshake eine Datenübertragung per XML einstellen. Je nach Vorlieben des Clients. Vielleicht implementiert man auch die Protokolle von FMS32 und Crusader und kann diese dann pro Channel in der Konfiguration als default aktivieren. (Oder eben "auto" als default, und die Protokollversion wird per Handshake ausgehandelt)

Ich plädiere also dafür, dass das Haupt-Protokoll zeilenweise arbeitet und in beiden Richtungen alle Befehle mit Nummern versehen werden. So wie man das von SMTP oder FTP kennt. Zusätzlich sollten bei der Definition der Datenfelder auch gleich Gültigkeitsbereiche definiert werden, die dann der Client zur überprüfung der Daten verwenden kann. Ggf macht es auch Sinn eine Prüfsumme über die Zeile mitzusenden.

Gruß Joachim

[A.Nero]

Hi, ich wuerde auch mithelfen beim Programmieren, wobei ich nur relativ wenig php und perl kann. Viel Zeit bleibt mir durchs Studium auch nicht, aber kleine Sachen wuerde ich schon versuchen beizusteuern

[Buebchen]

Bei XML müsste man einen größeren Umstand betreiben und einen XML-Parser benutzen. Das erhöht den Aufwand zum Empfang und zur Auswertung und vor allem auch den Datenverkehr auf der Schnittstelle. Gerade der Datenverkehr sollte sehr gering gehalten werden, um auch Handys oder PDA's nicht zu benachteiligen. Denn hier bezahlt man nach wie vor hauptsächlich pro Datenmenge.

Das ist ein gutes Argument.

Den Hauptvorteil von XML, das Protokoll flexibel zu erweitern und dabei Abwärtskompatibel zu halten sehe ich übrigens nicht. Bei ZVEI, FMS und POCSAG sind die zu übertragenden Daten konstant und ändern sich nicht mehr.

Nun ja. Ich sehe das halt schon. Weniger an dem FMS Daten. Keine Frage. Aber man könnte dann später z.B. noch den Klartext-Namen Fahrzeugs mitsenden (wenn der monitord eine eigene DB hat). Und was es noch so gibt.

Ich plädiere also dafür, dass das Haupt-Protokoll zeilenweise arbeitet und in beiden Richtungen alle Befehle mit Nummern versehen werden. So wie man das von SMTP oder FTP kennt. Zusätzlich sollten bei der Definition der Datenfelder auch gleich Gültigkeitsbereiche definiert werden, die dann der Client zur überprüfung der Daten verwenden kann. Ggf macht es auch Sinn eine Prüfsumme über die Zeile mitzusenden.
Gruß Joachim

Na, dann mach mal einen Entwurf :-)

[Dove]

ich würde von XML in der Datenübertragung weg gehen und ein eigenes "Protokoll" schreiben.
D.h. Zeichenketten als Trennzeichen.
Es sollte ein Start und Stop und Trennzeichen geben.
Z.B.

###param1##param2##param3##param4===
sowas in der Art.

oder ähnliches.
So machen wir das bei einem anderen Projekt auch und funktioniert wunderbar.

[Buebchen]

Hi, ich wuerde auch mithelfen beim Programmieren, wobei ich nur relativ wenig php und perl kann. Viel Zeit bleibt mir durchs Studium auch nicht, aber kleine Sachen wuerde ich schon versuchen beizusteuern

Danke für die Unterstützung. Auch kleine Dinge können eine grosse Hilfe sein. Das wichtigste ist sicherlich, daß Du dich traust zu sagen: "Das versuche ich", wenn Du ein Thema findest, daß Du für machbar hälst. Gerade im Bereich der WebTools gibt bestimmt ne Menge kleiner Gimmicks, die viel helfen können.