monitor 1.9.0 - aber richtig :)

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

[nepomuck]

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.

Das halte ich für eine gute Idee.

Vorschlag:
Wir legen zuerst die Datenfelder und die Reihenfolge fest, wie die Infos vom Backend aus gesendet werden. Beim Trennzeichen müssen wir uns auf was einigen, was nicht in der Meldung vorkommen kann, wie ":". Evtl. sollten wir Texttelegramme in Hochkomma stellen. Alles, was nicht in Hochomma steht ist nicht case-sensitiv. Alle Kommandos sollten möglichst eindeutig sein, dass sich auch fragmente einer Übermittlung zuweisen lassen. In FMS-Textmitteilungen dürfen Steuercodes drin sein. Wir könnten entweder das Telegramm gleich in Hex-Codes übermitteln (und uns die Hochkomma sparen) oder die Steuerzeichen in Spitzklammern angeben.

1. Servername
2. Kanal, Werte L oder R
3. Dienst, Werte ZVEI,FMS,POCSAC,TEST (sonstige?)

ZVEI:
4. Schleife
5. DTFM-Auswertung, Werte OHNE, FEUER, PROBE, WARNUNG, ENTWARN, ZIVIL
6. Abschlusmeldung "ZVENDE" (oder wie wärs mit "HABEFERTIG" :-)

Beispiel:
monitor1:L:ZVEI:12345:FEUER:ZVENDE

FMS:
4. Meldung
optional 5. Wenn ein Folgetelegramm kommt, steht hier TEXT
optional 6. Folgetelegramm in Hochkomma
5,6 oder 7. Abschlussmeldung "FMSEND"

Beispiel:
server07:R:FMS:631172141000:FMSEND
monitor1:R:FMS:631172140000:TEXT:"Kardio{CR}Hauptstrasse 5{CR}Huber{EOT}":FMSEND
(Spitzklammern kriege ich im Forum nicht hin, daher sind hier geschweifte abgebildet)
- oder -
monitor1:R:FMS:631172140000:TEXT:4B617264696F13486 17570747374726173736513487562657204:FMSEND

POCSAC:

damit kenne ich mich nicht aus.

was haltet ihr davon?

Andreas

[nepomuck]

1. Servername
2. Kanal, Werte L oder R

Ooops, fast vergessen:

1. Server,
2. DATUM/UHRZEIT YYMMDDHHMMSS
3. Kanal ....

also

monitor1:070417034312:ZVEI:26250:FEUER:ZVENDE

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

[jhr-online]

Mal wieder was pragmatisches ;)
Wenn ich das richtig überblicke, haben wir derzeit folgende Aktive (alphabetisch):

A.Nero
Buebchen
Dmitri_P
Dove
jhr-online
ManuelW
Max K.
MiThoTyN
nepomuck
Paneologe
SirFS

Ich fänd's total supi (*g), wenn mir alle kurz eine PN o.Ä. schicken könnten, in der sie mir ihren RL-Namen verraten und in zwei Stichworten kurz sagen könnten, was sie beitragen können/wollen. Danach bitte im BTS registrieren und ich trage euch als Developer ein, sodass ihr Aufgaben verändern und zuweisen könnt etc.
Ich will nicht zu viel Bürokratie hier einbringen, aber es wäre schon schön, einmal zu sammeln, was man für Potential hat. Dann mache ich einen groben Überblick fertig über das, was gemacht werden muss, und die, die es könnten.

Einverstanden?

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