|
|
Auf dieser Seite sammeln wir Ideen für Erweiterungen für drasyl. Einige dieser Ideen werden oder wurden dabei implementiert.
|
|
|
|
|
|
# Empfangsbestätigungen
|
|
|
Eine Design-Entscheidung von drasyl war es, dass wir das Netz nicht mit Empfangsbestätigungen belasten wollen.
|
|
|
# ~~Empfangsbestätigungen~~
|
|
|
~~Eine Design-Entscheidung von drasyl war es, dass wir das Netz nicht mit Empfangsbestätigungen belasten wollen.~~
|
|
|
|
|
|
Man müsste gucken, wie TCP den Empfang von Paketen sichergestellt und das dann in eine Erweiterung gießen.
|
|
|
~~Man müsste gucken, wie TCP den Empfang von Paketen sichergestellt und das dann in eine Erweiterung gießen.~~
|
|
|
|
|
|
# Nachrichtenreihenfolge
|
|
|
Eine Design-Entscheidung von drasyl war es, dass wir keine Garantien geben, dass Nachrichten beim Empfänger in der selben Reihenfolge ankommen, wie sie vom Sender verschickt wurden. Sowas kann passieren, wenn während des Versands von Nachrichten zwischen Direkt- und Relay-Verbindung gewechselt wird.
|
|
|
# ~~Nachrichtenreihenfolge~~
|
|
|
~~Eine Design-Entscheidung von drasyl war es, dass wir keine Garantien geben, dass Nachrichten beim Empfänger in der selben Reihenfolge ankommen, wie sie vom Sender verschickt wurden. Sowas kann passieren, wenn während des Versands von Nachrichten zwischen Direkt- und Relay-Verbindung gewechselt wird.~~
|
|
|
|
|
|
Man müsste gucken wie TCP die Reihenfolge der Pakete sicherstellt und das dann in eine Erweiterung gießen.
|
|
|
~~Man müsste gucken wie TCP die Reihenfolge der Pakete sicherstellt und das dann in eine Erweiterung gießen.~~
|
|
|
|
|
|
# ~~Objekt-/Nachrichten-Serialisierung~~ (done https://git.informatik.uni-hamburg.de/sane-public/drasyl/-/merge_requests/181)
|
|
|
drasyl verschickt/empfängt nur Byte-Arrays. Jede Applikation muss sich selbst um die (De)serialisierung der Nachrichten kümmern. Hier könnte man den Entwickler an die Hand nehmen und Hilfestellungen leisten. Man könnte Code-Beispiele mit drasyl & [Jackson](https://github.com/FasterXML/jackson) zeigen.
|
... | ... | @@ -44,5 +44,5 @@ Eine rudimentäre grafische Benutzeroberfläche zum Starten & Stoppen des Nodes, |
|
|
# ~~Special Fork für Unix-Umgebungen~~
|
|
|
~~Netty kann deutlich performanter betrieben werden, wenn man die nativen Transporte von Linux bzw. MacOS verwendet. Dies würde sich vor allem für das Docker-Image lohnen. Die (Root-)Server sollten davon profitieren und stabiler laufen. Nach der netty Doku (https://github.com/netty/netty/wiki/Native-transports) sollte das relative einfach per Suchen-und-Ersetzen funktionieren. Möglicherweise kann man dies auch durch ein Build-Script erreichen, dass die Ersetzungen nur für den Docker-Build vornimmt oder zusätzlich Linux- und MacOS-Natives baut.~~
|
|
|
|
|
|
# Websocket/HTTP-Client für DrasylNode
|
|
|
Aktuell erfolgt die Kommnunikation mit dem drasyl-Netz zwingend über eine eigene Implementation der DrasylNode-Klasse. Dies muss die Application erledigen und muss dazu in der JVM laufen. Man könnte nun eine Sprachunabhängige Implementation in Java bereitstellen und so die Schnittstellen der DrasylNode-Klasse z.B. via HTTP oder Websocket (JSON-RPC) zugänglich machen. Dies würde es auch nicht-JVM-Applicationen erlauben, mit dem drasyl-Netz zu kommunizieren. |
|
|
\ No newline at end of file |
|
|
# ~~Websocket/HTTP-Client für DrasylNode~~
|
|
|
~~Aktuell erfolgt die Kommnunikation mit dem drasyl-Netz zwingend über eine eigene Implementation der DrasylNode-Klasse. Dies muss die Application erledigen und muss dazu in der JVM laufen. Man könnte nun eine Sprachunabhängige Implementation in Java bereitstellen und so die Schnittstellen der DrasylNode-Klasse z.B. via HTTP oder Websocket (JSON-RPC) zugänglich machen. Dies würde es auch nicht-JVM-Applicationen erlauben, mit dem drasyl-Netz zu kommunizieren.~~ |
|
|
\ No newline at end of file |