Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- wiki:missing_info [31.03.2018 22:26] – [ACK einführen] 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, 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.
@@ Zeile 50: / Zeile 43: @@
 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.