Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- wiki:missing_info [22.03.2018 22:26] – christf
+++ wiki:missing_info [31.10.2018 12:19] (aktuell) – [eine verteilte Datenbank einführen, die den client-state hält] christf
@@ Zeile 25: / Zeile 25: @@
 Der Schaden ist lokal begrenzt.
-### Bei gescheitertem Unicast-Claim einen Multicast-Claim schicken
-Das tut der l3roamd aktuell: Sofern ein Claim an eine unicast-Adresse
-scheitert, weil keine Route vorhanden ist, wird ein netzweites Claim an die
-multicast-Adresse geschickt.
-Das funktioniert, hat jedoch den Nachteil dass man für eine Kommunikation
-zwischen zwei Nodes netzweit Pakete verschickt.
-Hoffentlich ist die Ausgangssituation selten genug, dass das nicht schlimm ist.
-Optimierung bei CLAIM/SEEK können hier helfen, die Nachrichten zumindest nur an
-ein Teil des Netzes zu versenden.
 ### ACK einführen
 Man könnte dem Empfang von INFO-Nachrichten quittieren.
-Dadurch würde die roaming-Geschwindigkeit etwas verlangsamt, die neue
+Erhält der Info-sendende node kein ACK, verschickt er im retry-Intervall weitere INFO-Nachrichten bis entweder der max-retry-count abgelaufen ist oder ein ACK kommt.
-node-client-ip und die dazugehörige Route wird erst spät übernommen.
-Allerdings wird die auch jetzt bereits erst nach dem dritten retry gesetzt. Ob
+Für kurze Zeit wäre die special-IP dann auf zwei Nodes im Netzwerk zugeteilt.
-da nun noch ein Ack-Zyklus dazu kommt ist wohl nicht mehr wichtig.
+Wie verhält sich babel in der Situation?
+Auswirkung auf Roaming bei Paketverlust: die roaming-Geschwindigkeit wäre etwas verlangsamt, die neue
+node-client-ip und die dazugehörige Route wird erst später übernommen.
-Was passiert eigentlich, wenn ein ACK verloren geht?
 ### Für jeden Client eine eigene Multicast-Gruppe einführen zu dem sich nodes die Interesse an den Daten haben subscriben.
 Dann kann eine subscription über den Zeitpunkt hinweg aufrechterhalten werden, an dem ein Client sich von einem Node trennt und retries werden möglich.
-Dafür bräuchten wir multicast-routing, was wir nicht haben.
+Dafür bräuchten wir multicast-routing.
+### viele Unicast-Adressen dem node zuweisen
+... - aus einem Pool von 10 Stück und zufällig eine auswählen. Claims an alle 10 möglichen IP-Adressen des clients schicken und die Adressen erst nach eine KArenzzeit droppen.
+### eine verteilte Datenbank einführen, die den client-state hält
+Hat man eine verteilte Datenbank, kann diese die Informationen bereitstellen. Es gibt mit kadnode eine DHT-Lösung, die ist in voller Ausbaustufe 70KB groß und auf 4MB-Geräten nicht aus dem Stand einsetzbar. Kleinere Varianten sind sicher denkbar.
-## Entscheidung
 Was meint ihr?
+# Lösung
+Ich habe ACK implementiert.