monitor 1.9.0 - aber richtig :)

[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

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

[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 :-)