monitor 1.9.0 - aber richtig :)

[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