Core
Core copied to clipboard
DecentralizedAmateurPagingNetwork
Netzwerkprotokoll überarbeiten
Da wir jetzt schon mal dabei sind, die Hälfte umzubauen, würde ich auch eine Überarbeitung des Netzwerkprotokolls zwischen Core und Sendern anstreben. Für die C9000 Kisten kann ich im raspager-proxy einen Umsetzer implementieren, das ist also kein wirkliches Problem. Ich würde damit aber warten wollen, bis der Core als Master-Server sauber läuft. Nicht zu viel auf einmal machen ;)
Der Einfachheit halber würde ich JSON-Nachrichten vorschlagen. Ein Binärprotokoll ist von der Bandbreite zwar besser, aber in der Umsetzung komplexer. Oder man nutzt beispielsweise Googles protobuf.
Hier mal mein erster Vorschlag: dapnet_msg.txt
Ansonsten können wir gerne mal sammeln, welche Features man haben möchte. Denkbar wäre beispielsweise auch, dass der Sender Statistiken liefern kann: Anzahl der tatsächlich gesendeten Nachrichten, SWR, usw.
Meine 2Cent hier https://github.com/DecentralizedAmateurPagingNetwork/Core/blob/master/TXProtocol.txt . Wir können die Datei auch als Arbeitsgrundlage verwenden, bis wir einen Übereinkunft haben.
Gut, machen wir das so. Das mit dem NTP ist übrigens eine gut Idee, das vereinfacht die Logik an der Stelle schon deutlich. Ich habe die Datei mal in den experimental Branch übernommen.
oh, falscher Branch... Den Zeitsync brauchen wie gesagt weiterhin die XOS-Pager mit nicht-änderbarer Firmware
Für den Aufbau des Protokolls könnte man sich an JSON-RPC orientieren, damit ist unter anderem auch eine eindeutige Zuordnung der Antworten zu allen Anfragen möglich.
@dh3wr Ja, aber das kann dann halt der Proxy machen und wir werden das aus dem Core los. Die anderen Clients könnten dann auch drauf verzichten.
Edit: Wie sieht das denn mit Zeitzonen aus? Muss man da was beachten?
@7h0ma5 Sieht auf den ersten Blick jedenfalls nicht verkehrt aus, ich werde mir das mal genauer ansehen.
Ich habe mir mal JSON-RPC genauer angeschaut und im Wiki einen Vorschlag gemacht. https://github.com/DecentralizedAmateurPagingNetwork/Core/wiki/Example-for-JSON-RCP-communication-protocol
Über die Telemetrie muss man sich nochmal Gedanken machen, die sollte eher von anderen Programmen auf dem Sender-Host kommen statt vom Unipager.
Websocket und MQTT kannst du dir wie Layer 2 vorstellen, JSON-RPC wie Layer 3. Man kann zum Beispiel JSON-RPC über Websocket machen. Wir brauchen JSON-RPC auch nicht komplett zu implementieren, das "jsonrpc": "2.0" könnten wir zum Beispiel weglassen.
Der Hautpnutzen ist, dass jede Anfrage eine ID hat, zu der dann auch eine passende Antwort kommt. Wenn keine Antwort oder eine Fehlermeldung zu der ID kommt, weiß der Sender, das mit diesem Request etwas schief gelaufen ist.
Noch eine Idee: Wenn wir jetzt schon bidirektionale Kommunikation zwischen DAPNET Core und Sender haben, könnte man die Zeitschlitzzuteilung doch komplett dynamisch machen. Im DAPNET Core ist dann hinterlegt, welche Sender sich untereinander stören würden. Der Sender alloziert sich dann immer beim Core eine bestimmte Sendedauer. Ein Problem wäre nur, wenn sich Bereiche von Sendern überschneiden, die mit verschiedenen Cores verbunden sind.
Gute Idee: Also komplett dynamisch, je nach Last auf den jeweiligen Rechnern? Als verteiltes System wird das wohl etwas herausfordernd, aber wenn sich die Cores absprechen würden, könnte das gehen. Muss man mal überlegen, welcher Optimierungs-Algorithmus da der mit der kürzesten Zeit bis zum Aussenden bei einer globalen Optimierung der beste ist. Geil wäre das schon.
Ich würde vom Core aus den Sendern Zeiträume zuweisen, nichrt die Sender sich den Zeitraum anfragen lassen. Sollte besser zu optimieren sein, oder?
Oder man plant im DAPNET-Cluster zumindest die nächsten 30 Sekunden bis 3 Minuten vor, welcher Sender wann und was (Msg.-Prio) sendet. Das wäre auf jeden Fall eine Sache, die richtig Durchsatz bringen könnte. Und die Überlappungsmatrix könnte man aus den Abdeckungsbildern erzeugen. Wenn es mind. einen farbigen Pixel an einer Koordinate gibt, dann ist Überlappung gegeben. Im Grunde ist das eine bool NxN Matrix mit den Sendern, die man ab und zu neu erstellen müsste. False bedeutet dann: Keine Überlappung.