Druckbare Version
@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
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.Zitat:
Zitat von Buebchen
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.Zitat:
Zitat von nepomuck
Die Frage ist also eigentlich, ob der monitord direkt in die SQL-DB schreibt, oder aber ein angemeldeter Client (=Robot) das erledigt.
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. ;-)
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.
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
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
Das ist ein gutes Argument.Zitat:
Zitat von MiThoTyN
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.Zitat:
Zitat von MiThoTyN
Na, dann mach mal einen Entwurf :-)Zitat:
Zitat von MiThoTyN
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.
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.Zitat:
Zitat von A.Nero
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?
Das halte ich für eine gute Idee.Zitat:
Zitat von Dove
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}Haupts trasse 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
Ooops, fast vergessen:Zitat:
Zitat von nepomuck
1. Server,
2. DATUM/UHRZEIT YYMMDDHHMMSS
3. Kanal ....
also
monitor1:070417034312:ZVEI:26250:FEUER:ZVENDE
Die Idee ist gut, aber bei der Auswahl des Zeichens solltet Ihr nochmal gründlich überlegen: Ein Doppelpunkt kann durchaus in Meldungen vorkommen, sogar einigermaßen häufig. Am besten etwas wie § oder ° oder | oder µ oder oder oder nehmen, irgendwas, das mit großer Sicherheit nicht auftaucht. Vielleicht sogar eine Kombination wie §*§ oder §°§.
Ihr findet da schon etwas.
Gruß,
Funkwart
Wir wäre sonst das Konzept, daß auch früher auf dem Amiga mal "IN" war (Bstrings): Da ist das erste Byte ein Längenbyte. Man könnte vor jedem Text dann einfach die Länge vorher angeben. Wäre sogar resistent gegen Nullbytes.
....:050:{50-zeichen}:....
es würden ja auch mehrere trennzeichen genommen werden: §§§ oder so.Zitat:
Zitat von funkwart
das Datum würde ich als datetime übertragen also als unix timestamp.
damit kann man ab besten arbeiten und überall verwenden.
@funkwart
Auch recht. Aber der Doppelpunkt kommt wenn, dann nur in Textmeldungen vor und die sind dann entweder in Hochkomma gestellt oder Hex Dekodiert
@Buebchen
Das Längebyte könnte man in die TEXT-Anweisung einbauen, also: ...FMS:1234567890ab:TEXT(5):6520136565:...
Die Fragen sind
- brauchen wir weitere Felder?
- darf der Cllient was zu Server senden und wenn ja was?
- gibt es dafür einen eigenen TCP-Port oder läuft alles über einen?
- gibt es eine "private" kommunikation zwischen server und client oder nur einen multicast vom server aus
Andreas
Zum ersten Punkt: Stimmt, wenn es denn so einfach ist, das auseinander zu halten, meinetwegen. Trotzdem wäre es doch in Ordnung, ein Zeichen mit noch geringerer Auftet-Wahrscheinlichkeit zu wählen.Zitat:
Zitat von nepomuck
Zum zweiten Punkt: Ich denke, es sollte schon eine Identifizierung bzw. Authentifizierung von Clients geben, somit müssen diese ja zwangsläufig mit dem Server kommunizieren. Ich weiß, dass das keine Sicherheit darstellt, weil Klartext-Übermittlungen ohne Probleme mit einem Sniffer mitgelesen werden können, aber es ist zumindest nicht so einfach, nur einen Client zu starten, die monitor-Server-IP zu geben und lustig alles mitzulesen.
Gruß,
Funkwart
Wir können die Daten auch gpg-verschlüsseln... *SCNR*
jhr
kurze frage.
sind daten wie auf welchem kanal das signal anlag für das frondend interesant ?
Ich finde nicht. Ich finde das sowas auch weg gelassen werden könnte, oder nicht ?
Doch das ist sehr wichtig. Weil du 2 verschiedene Funkkanäle pro Line-Eingang auswerten kannst. Also muss das Frontend auch wissen, von welchem Kanal die Auswertung stammt.
Zum Datenformat selbst noch was grundsätzliches. Die Länge pro Zeile und pro Datenfeld sollte minimiert gehalten werden. Diese Datenzeile muss vom Menschen nicht gelesen werden können. Auf Klartexte wie bei den DTMF-Tönen FEUER, PROBE und sowas kann man also verzichten. Eher sollte man solche starren Werte einfach mit Nummern belegen. Also 1=Feuer, 2=Probe und so weiter. Verringert erstens die Datenmenge und lässt sich im Frontend leichter auf Richtigkeit überprüfen, denn das Feld mit dem Sirenenton hat dann einfach einen Gültigkeitsbereich von 1 bis 6 (z.B.).
Auch sollten die Befehle kategorisiert und nummeriert werden. Bsp:
100er : Steuerbefehle von Server
200er : Steuerbefehle vom Client
300er : FMS
400er : ZVEI
500er : POCSAG
usw.
Texte würde ich in der Tat gleich Hexadezimal übertragen. Vergrößert zwar die Datenmenge, erledigt aber alle Probleme mit Steuerzeichen im Text. Diese müssen dann nicht erst einzeln durch entsprechende "harmlose" Synonyme ersetzt werden.
Die Angabe einer Länge finde ich überflüssig. Die Daten werden eh von Trennzeichen eingegrenzt. Die Längenangabe ist dann höchstens von Bedeutung, wenn der übergebene Text auf richtig übertragene Länge geprüft werden soll. Aber ob der Inhalt stimmt, kann man mit der Längenangabe nicht prüfen. Sinnvoller wäre es nach wie vor, über die komplette Zeile eine Prüfsumme zu bilden. Dann kann schon das Fehlen eines Bits erkannt werden.
Um das ganze richtig Fehlertolerant zu machen, könnte man noch jede Zeile mit einer eindeutigen ID versehen. Wenn der Client eine Zeile als Falsch erkennt (Checksumme oder Datenfeldgültigkeit), kann er diese Anhand der ID beim Server nochmal anfordern.
Ein paar Zeilen Daten zur Anschauung :
(§=Trennzeichen //=Kommentar für euch)
XXX- (Mit Bindestrich: Daten nach Befehlsnummer nur zur Info)
XXX (Ohne Bindestrich: Daten nach Befehlsnummer zum Bearbeiten)
// 100 Server Identifikationssting
100 monitord
// 101 Server Versionsstring
101 V1.20
// 200 Client Identifikationsstring
200 Jogis Super Frontend // 200
// 201 Client Versionsstring
201 V3.40
// Client will Protokollversion MON3
202 MON3
// Server stimmt zu
202 MON3
103-Login
203 username§passwort
104-Login correct
// 111 Server Kanal links§rechts
111 kanal501§rettungsdienst
299-OK
// ZVEI Auswertung Kanal§Folge§Doppelton$timestamp
400 1§67223§1§071102192233
299-OK
400 1§67223§1§98733,,,,,,, (Fehler)
298-ERR
Usw usw .... Wenn ich mal ne Stunde ZEit hab heute Abend, kann ich mal bischen Gehirnschmalz da reinstecken. Also ich entwickel mal ne erste Protokollversion und leg die hier zur Ansicht vor.
Gruß Joachim
@funkwart;@jhr-online
Ich glaub, dass abhörsicherein ein Feature mit niedriger Priorität ist. Eine künftige Version könnte das Monitor-Protokoll via SSL übertragen.
@MiThoTyN
Auch eine gute Idee, wobei ich glaube dass es bei der Datenübermittling nicht auf jeden einzelnen Charakter ankommt und ein im Klartext lesbares Protokoll bei Debugging hilft.
Dein Protokoll setzt ein Login voraus und legt damit fest, dass jeder Client über einen eigenen Kanal mit dem Server spricht. Das ist auf jeden Fall die sauberere Variante als ein one-way Multicast. Ich hoffe, dass es kein zu großer Aufwand beim Programmieren des Backends wird.
Vorschläge
Ich würde in das Protokoll auch noch eine Art "Ping" integrieren, damit der Client/Server von Zeit zu Zeit die Verbindung prüfen kann.
Beispiel:
297 Alive
199 OK
oder
197 Alive
299 OK
Vieleicht wäre es auch ganz nett, eine History-Funktion einzubauen, so dass ein Client beim Start die letzten Ereignisse nachfragen kann
123 lastevents 10
401 1§26100§0§datetime (0 ist ohne DTFM also Melderauslösung)
401 1§26250§1§datetime
401 1§26380§1§datetime
401 1§26433§0§datetime
401 1§26104§0§datetime
499 END
299 OK
und für FMS wäre natürlich wichtig, dass der Client nach dem Start den aktuellen Fahrzeigstatus der Flotte abfragen kann:
147 fmsstat
501 63117214§6§datetime
501 63117215§7§datetime
501 63117256§1§datetime
501 63117603§1§datetime
...
599 END
299 OK
Vieleicht würde es den Entwicklern zudem helfen, einige Testkommandos einzubauen:
222 test§1§zvei§12345§1
400 1§12345§1§datetime
Andreas
Diese "History-Funktion" wollte ich auch noch ansprechen. Das ist was, was man im Vorfeld auch abklären muss. Die Frage ist, ob diese History vom Auswerter kommt. Eigentlich könnte es auch aus einer Datenbank kommen. Da aber der monitor selbst keine Datenbank ansprechen soll, muss die History aus einem Speicher-Puffer kommen. Dieser kann dann natürlich nicht beliebig groß sein und die Anzahl der enthaltenen Datensätze muss begrenzt sein.
Theoretisch müsste man pro Signal-Art (ZVEI, FMS, POCSAG) einen eigenen Puffer bereithalten. Bei FMS macht es sogar Sinn, zwei getrennte Puffer vorzuhalten. Einen mit den letzten X Telegrammen (chronologisch geordnet) und einen mit dem aktuellen Status pro bekannter Kennung (nach Kennung geordnet).
Das ist aber meiner Meinung nach was, was in eine Datenbank gehört, bzw aus einer Datenbank kommen muss.
Wie sind die Meinungen dazu? Monitor doch gleich mit Datenbankanbingung bauen? Andere Möglichkeiten?
Gruß Joachim
Das stelle ich mit einfacher vor. Das Backend kann wie bisher eine LOG-Datei schreiben. Die enthält die "rohen" Codes, so wie sie auch über das Netz übertragen werden.Zitat:
Zitat von MiThoTyN
Ein History-Query kann des Backend dann ganz einfach aus den letzten Zeilen der LOG-Datei beantworten.
Mann kann diese Funktion ja darauf beschränken, dass der Client nicht explizit irgendwelche Services abfragen kann, so dass das Backend ihm einfach die geforderte Zahl an Zeilen aus dem LOG übermittelt.
Auswerten muss dann das Frontend -- aber dafür ist es ja sowieso konzipiert.
Für FMS könnte mann theoretisch ein Status-LOG generieren. Da schreibt das Monitor-Backend einfach sequentiell alle Status-Meldungen (Fahrzeug, Status,Uhrzeit) rein.
Vor jedem Eintrag prüft das Backend, ob das entsprechende Fahrzeug schon in der Liste steht und löscht einfach die Zeile mit dem alten Eintrag, bevor er den neuen anhängt.
Andreas
CRC und alles vergleichbare ist ein eine TCP Verbindung nicht sinnvoll. Sofern man nicht gerade Man-In-The-Middle Attacken erkennen will sorgt das TCP schon für den korrekten Transport der Daten.Zitat:
Zitat von MiThoTyN
Checksummen würden man bei eher bei RS232 Verbindungen wiederfinden. Gerade wenn ohne Handshake gearbeitet wird geht da öfters mal ein Bit verloren.
Ansonsten bin ich auf die ersten Protokollversion gespannt. History werde ich ermutlich nur über ein SQL Backend machen. Log-File parsen ist nichts, was ich für so richtig toll halte. Zumal man die auch noch rotieren muss ...
Die Sache mit dem Log finde ich auch nicht gut. Dann haste plötzlich auch auf Seiten des monitors eine Art Datenhaltung. Das soll ja eben vom monitor getrennt sein und dann von einer Datenbank übernommen werden. Im Endeffekt würd ich also auch sagen, dass der monitor-daemon sturr das weitergibt, was er auswertet. Basta. Um eine History-Funktion muss sich dann ein Client kümmern. z.B. eben die angesprochene mySQL Datenbank, die ja durchaus als Proxy zwischen dem monitor und den weiteren Clients sitzen kann.
Gruß Joachim
Das würde zwangsweise eine MySQL-Datenbank im Backend erfordern. Das würde mir nicht gefallen, da ich dadurch Probleme mit der Live-CD bekomme.Zitat:
Zitat von Buebchen
Bislang kann "Bosix" monatelang von CD gebootet arbeiten, wenn es die LOGs sequentiell auf einen simplen USB-Stick schreiben kann. Die permanenten Änderungen an SQL-Tabellen würden das Union-Dateisystem von Knoppix schnell zum überlaufen bringen, so dass die Live-CD wahrscheinlich innerhalb von wenigen Tagen abstürzt.
Ich dränge immer noch auf ein Backend OHNE MySQL.
Das mit dem Logfile-parsen kann doch nicht so komplex sein, oder?
Andreas
Nene .. Da haben wir uns schon richtig verstanden. Das eigentliche Backend hat keine MySQL Anbindung. Diese würde ebenfalls per TCP angedockt. Der monitor als Backend übernimmt einzig und alleine die Dekodierung der Funksignale.
Das mit der Logdatei hat meiner Meinung nach zu viele Nachteile. Zum einen ist es echt komplex zu Handhaben. Dateioperationen können immer mal schief gehen. Du musst ständig auf die Datei zugreifen und erzeugst so haufenweise Festplattenzugriffe. Diese kann dann auch nicht in den Standbymodus gehen. Ohne Logdatei läuft der monitor rein im Arbeitsspeicher. Auch musst du die Logdatei rotieren und immer hinten ein Eintrag rauswerfen und vorne einen neuen anfügen. Dazu muss ständig die ganze Datei geladen werden, über nicht wenige Befehle rotiert und wieder gespeichert werden. Rein aus Performance- und Dauerlaufsicht ist ein Dateizugriff in der Form nicht wünschenswert.
Auch sind die Vorteile der Logdatei nicht überzeugend. Sicher ist es für ein Frontend ne feine Sache, wenn es auch Meldungen bekommt, die in der Vergangenheit liegen. z.B. wenn sich das Frontend neu verbinden muss, dann gehen die Meldungen in der Zwischenzeit nicht verloren. Aber was passiert, wenn der monitor selbst mal ne Zeit ausfällt? Dann hast du in den Logdateien noch alte Daten drinne stehen, auf die dann brandneue Daten folgen. Diese werden dann an ein Frontend weitergegeben. Das hat dann plötzlich uralte Daten drinne. Man kann also auch nicht garantieren, dass die Daten aus der Logdatei nicht schon unsinnig sind. Es sei denn man bohrt das entsprechend auf und verwaltet das nach Uhrzeit und alles. Aber das ist ein riesen Aufwand, diesen Datenbestand sinnvoll aktuell zu halten. Und DAS wiederum ist nicht Aufgabe des monitor als solches. Wie gesagt bin ich durchaus für so eine komplexe History. Nur eben als Teil der Datenbank, wo sämtliche Daten eh gespeichert sind.
Gruß Joachim
OK, History entfällt im Backend -> Aufgabe des Frondends.
Das gilt dann auch für den Fahrzeug Status via FMS?
Andreas
Ich denke ja; der jeweils aktuelle Status sollte auch aus der DB erfragt werden.Zitat:
Zitat von nepomuck
jhr
Ne Ne Ne ... Warum nicht ein externer DB-Server ? Auch die logfiles muss er irgendwo hinschreiben. Da würde CD-Boot auch nicht gehen, bzw. es wäre fast das gleiche.
Mein Vorschlag: Es gibt eine Option für den Backend-DB Server. Entweder ist er aktiv oder nicht. Danach kann man immer noch klären welche Daten die Clients dann vom monitord anfordern können oder nicht. Ggf. können die Clients auch einfach selbst auf dem DB Server zugreifen. Das kann dann jeder Entwickler selbst entscheiden.
Eine Zwischenstufe (TCP Client speichert in DB) wäre denkbar. Aber es ist m.E. nicht sinnvoll, daß die Clients selbst die Daten speichern müssen. Was macht man, wenn man eben erst den Client startet ? Man hätte keine aktuellen Statusinformationen zu den Fahrzeugen. Aber alle in die "6" oder "2" zu stellen ist auch nicht richtig.
Gerade bei der Nutzung in einer nachbesetzten Führungsstelle ist das eine wichtige Information ("Welche Fahrzeuge sind ausgerückt - und wann ?").
Folgende Idee, um das Problem zu lösen.Zitat:
Zitat von Buebchen
Der eigentliche Backend hat selbst keine DB und schreibt seine Daten per Default in ein klassisches LOG. das kann man auch abschalten.
Es gibt ein SQL-Modul, welches sich regulär per TCP beim Frontend anmeldet und die Auswertungen per ODBC in irgend eine eine SQL-Db schreibt.
Das SQL modul kann auf dem Backend Server oder irgend einer Maschine im LAN arbeiten. Ebenso kann die Db sein wo sie will.
Eine History-Query muss ein Client an das SQL-Modul stellen.
Da sich das SQL-Modul beim Backend anmeldet, kann ein Client-Task bem backend danach fragen und bekommt als Antwort die IP-Adresse des SQL-Moduls.
123 SQL
234 NOPE
oder
123 SQL
234 192.168.23.65:1234
Vorteil: Die DB ist kein zwingender Bestandteil des backends. Falls die DB ausfällt oder der entfernte sql-server nicht antwortet, funtioniert das Backend regulär weiter.
nachteil: Ein Client der Live-Daten und alte daten auswerten will, muss sich mit zwei TCP-Sitzungen mit dem backend und dem SQL modul verbinden. ausserdem müssen wir ein zweites protokoll zur kommunikation zwischen frontend und sql modul entwickeln.
das hat im gegenzug den vorteil, dass ein task der db-auswertungen mit viel sql-traffic ausführt nicht den backend kanal belastet.
Andreas
Das geht schon eher so in die Richtung, die ich mir vorstellen könnte.
Das TCP->SQL Modul wäre zwar nicht mein Lieblingsding aber durchaus ok. Dadurch könnte man vor allen Dingen noch ein anderes Problem erschlagen, daß mir in der Praxis schon begegnet ist:
Was macht man, wenn man im Gerätehaus auf einigen Kanälen schlechten Empfang hat ? Richtig: Von einem besseren Standort die ausgewertete Daten holen. Man könnte also in einer Datenbank durch zwei oder mehr solcher Agenten Daten mehrerer monitord sammeln.
Müßte man noch klären, wie die Benutzerdaten verwaltet werden. Ich hatte bisher einfach gegen MySQL Anmeldung geprüft. Konnte man er sich mit den Daten am mysql anmelden (nur als Prüfung), war man auch am "monitord" angemeldet. Der Client konnte sich dann auch am MySQL anmelden (bekam er ähnlich wie nepomuck schon schrieb dann mitgeteilt, wo dieser MySQL zu finden ist).
Hier wäre dann auch direkt das Problem des externen Zugriffs: Hat der MySQL Server eine LAN IP aus Sicht des monitord nützt diese IP einem von aussen (ohne VPN) zugreifenden Client nichts. Man müßte in letzter Instanz auch über ein "masquerading" nachdenken (Fern-Fern-Fernziel).
Ach so:
Nachteil aus meiner Sicht wäre auch, wenn der monitord zwar läuft ich aber im Fall der Fälle keine Auswertungen der Daten machen kann, da der SQL-Agent sich weggehängt hätte.Zitat:
Zitat von nepomuck
Ich schaue weniger in die Auswerter aus Neugierde. Eher im Auswertungen zu fahren (Bsp: Ausrückzeiten, Eintreffzeiten) oder Doku zu schreiben.
Als Protokoll zum Backend würde ich vorläufig mysql-Tools nehmen und direkt auf den Server zugreifen. Alles andere ist ggf. schon wirklich komplex. Gerade wenn auch noch Performance dahinter sein soll. Benutzername und PW dafür sind noch zu klären (dynamisch oder static ...)
Wie wäre es mit "gar nicht". Warum direkt gegen MySQL schreiben? Warum nicht ODBC, dann kann das SQL-Modul gegen jede SQL-Datenbank schreiben und die Login-Verwaltung ist Sache des ODBC-Treibers.Zitat:
Zitat von Buebchen
Da sträuben sich mir die Nackenhaare! SQL via Internet ohne VPN. Warum sollte das jeman tun wollen? Jedes Linux und jedes Windows beherrscht zumindest PPTP.Zitat:
Zitat von Buebchen
Ich meine, wenn du ohnehin mit SQL-Server arbeitest, hängst du sowieso ein PHP/WEB-Frontend davor und kommst von außen daran -- warum also SQL direkt?
was zwangsweise einen installierten MySQL-Client im Backend erfordert.Zitat:
Zitat von Buebchen
Wenn Funk-Nachrichten mit maximal 1200 Baud eingehen, ist die Performance glaube ich das geringste Problem.Zitat:
Zitat von Buebchen
Andreas
Und woher weiss der SQL Agent, daß die Anmeldung, die da Daten holen will gültig sind ? Wenn ich nen monitor-client habe, der eine History zum Rettungsmittel zeigen soll, dann ist derZitat:
Zitat von nepomuck
* am monitord angemeldet
* am sql angemeldet
... aber mit welchen Benutzernamen und viel wichtiger: wo werden diese zentral gepflegt ? Oder muss man dann immer die Benutzer zweimal anlegen ?
Also mein altes Handy kann mal kein VPN :-)Zitat:
Zitat von nepomuck
und ? Warum auch nicht ? Wer ihn nicht will kann ihn ja abschaltenZitat:
Zitat von nepomuck
Wenn ich aus 2 Mio Datensätze die FMS Protokolle eines Standorts für die letzten 24 Stunden filtere und mir anzeigen lassen sind 1200 Baud nicht viel :-)Zitat:
Zitat von nepomuck
Wir sollten auf jeden Fall drei Fälle unterscheiden.
1. Ein "Textbasierter Client" wie bisher
Er fragt weder einer Historie ab, noch sonst was. Braucht auch keine DB
2. Ein grafischer Client - Vielleicht eine Mischung aus Crusader und FMS32
Der könnte z.B. schon Daten aus der History-DB abfragen können
3. Ein erweiterter Client, der neben der reinen "Ansicht" der Funkdaten weitere Aufgaben übernimmt (Einsatztagebuch, Meldungsverwaltung, Patientenerfassung,...) und diese mit den Daten der History-DB verknüpft.
Nun ja. Erstmal nicht sooo wichtig. Ich werde definitiv eine Datenbankanbindung schreiben. Wer sie nutzt, kann das tun. Wer sie nicht will schaltet sie eben ab. Wichtiger ist das TCP Protokoll. Sonst gibts auch vorläufig keine Clients.
SQL-Agent meldet sich am Backend an -- User meldet sich bei Backend an -- User fragt Backend nach SQL -- Backend übermittelt dem User die IP des SQL-Agenten UND sendet dem SQL-Agenten die IP des Users zu und bestätigt damit, dass er ran darf.Zitat:
Zitat von Buebchen
Einen MySQL-Client wird's dann ja auch nicht haben.Zitat:
Zitat von Buebchen
Ohne MySQL-Client plus Headers und Libs läuft dann wieder kein Make durch. Oder es kommt ein neues Distributionsupdate mit einem neuen MySQL-Client raus der evtl. nicht zum Code passt und dann hängt wieder alles.Zitat:
Zitat von Buebchen
Je weniger Dependencies das Backend hat, umso besser.
Und ich würde Bosix 0.2 liebend gerne von einem USB-Stick anstelle einer CD booten und dafür würde ich die Linux-Distribution gerne so klein wie es irgend geht machen.
MySQL-Client = 5.6 MB. Libs and Headers = 7.3 MB Shared Libs = 1.6 MB
macht 14.5 MB
MyODBC = 2.5 MB
OK. Aber für das Data-Mining kannst du ja eine Applikation schreiben, die direkt auf MySQL zugreift. Für das Backend würde ODBC genügen.Zitat:
Zitat von Buebchen
der nur eine TCP-Verbindung zum Backend herstelltZitat:
Zitat von Buebchen
der per TCP mit dem Backend und dem SQL-Agenten in Verbindung stehtZitat:
Zitat von Buebchen
Der per TCP mit dem Backend und per MySQL-CLient mit der Datenbank in Verbindung steht.Zitat:
Zitat von Buebchen
Andreas
Aber ein SDK für Java. Und das kann Datenbankzugriffe. Aber eben kein VPN.Zitat:
Zitat von nepomuck
Die Grössen sind aber doch nicht nur die benötigten libraries. Das betrifft doch nur die build Umgebung. Die dll und shared-lib für mysql haben um die 1MB. ODBC weiss ich nicht.Zitat:
Zitat von nepomuck
Soll an dieser Stelle auch erstmal egal sein. Ich werde das in eine virtuelle Funktion packen. Das DB Backend wäre dann mal generell austauschbar. Vielleicht auch eine Klasse, die die Daten repräsentiert.
Das hätte mein Full-ACK.Zitat:
Zitat von nepomuck
Die Geschichte mit SQL-Agent fragt monitord nach Useranmeldung etc ist vom Gedanken her gut. Bin mir nur noch nicht so sicher, ob das dann im technischen Detail auch ohne Probleme klappt.
Werde mir mal die aktuellen ODBC Varianten bei Gelegenheit mal anschauen. Vielleicht tritt da ja noch ein Sinneswandel bei mir ein.
Ok. Dannn sollte es gehen. Ich muss für den Remaster-Prozess alles installieren, den Make fahren und kann danach die Bulid-Umgebung und Headers wieder entfernen. Ich brauche dann nur eine Liste der shared libs, die bleiben müssen.Zitat:
Zitat von Buebchen
Andreas
Wenn ich noch mal was technisches reinwerfen darf:
Wie wäre es damit, wenn ich sich einer derjenigen, die auch wirklich verstehen, was hier geplant ist, mal dranmachen würde, das ganze etwas systematisch im Wiki aufzuarbeiten. Der Thread wird langsam unübersichtlich - die ersten beklagen sich :)
Da ich am Code nicht viel mitarbeiten kann, bin ich gerne bereit, mich weiter in dieses organisatorisch reinzuhängen, aber den ersten Schritt muss wirklich jemand machen, der das alles versteht... Die Vorschläge auseinanderhalten und das, was zusammen gehört, auch zusammen zu formulieren; Backend- von Frontend-Vorschlägen trennen etc.
Hat jemand Lust? Hier geht's los:
http://monitor.08k.de/index.php/Devel bzw. eigentlich erst
hier: http://monitor.08k.de/index.php/Devel/2.0
jhr
Nachtrag: Ich muss ja nicht alles selber machen und auf meinem PC horten... :) Tragt euch ein: http://monitor.08k.de/index.php/Devel/Team
Moin, ich mische mich hier auch mal ein :)
Mir scheint, dass die Komplexität hier gerade explodiert ;)
Ich würde mir das so vorstellen:
monitor-backend: nimmt Daten von der Soundkarte und stellt diese Dekodiert über TCP zur Verfügung. Kein Logging, keine Datenbank.
Frontends: z.B. Daten in eine Datenbank schreiben, Daten in ein Log schrieben usw.
Ein GUI- (oder Textkonsolen-) Frontend würde aktuelle Ereignisse direkt vom Monitor-Backend bekommen und könnte die Historie entweder direkt aus der Datenbank des DB-Frontends abrufen oder evtl. mit dem DB-Frontend kommunizieren. Für den Direktzugriff auf die DB müssen GUI- und DB-Frontend sich bloß auf eine Datenbankstruktur einigen, für die andere Variante müsste man ein Protokoll entwerfen ...
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.Zitat:
Zitat von Norad
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
Hmmmmmmmm --- Ja !Zitat:
Zitat von jhr-online
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.
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.Zitat:
Zitat von jhr-online
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
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.Zitat:
Zitat von Buebchen
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
Danke für die Mühe und den EntwurfZitat:
Zitat von MiThoTyN
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.
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.Zitat:
inklusive Trennzeichen und Zeilenende nicht länger als 512 Byte ist.
Andreas