Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
wiki:missing_info [22.03.2018 00:27] – angelegt 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. | 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, | ||
- | 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 | ### ACK einführen | ||
Man könnte dem Empfang von INFO-Nachrichten quittieren. | Man könnte dem Empfang von INFO-Nachrichten quittieren. | ||
- | Dadurch würde die roaming-Geschwindigkeit etwas verlangsamt, | + | Erhält der Info-sendende |
- | node-client-ip und die dazugehörige Route wird erst spät übernommen. | + | |
- | Allerdings wird die auch jetzt bereits erst nach dem dritten | + | |
- | da nun noch ein Ack-Zyklus dazu kommt ist wohl nicht mehr wichtig. | + | |
- | Was passiert eigentlich, wenn ein ACK verloren geht? | + | Für kurze Zeit wäre die special-IP dann auf zwei Nodes im Netzwerk zugeteilt. |
+ | Wie verhält sich babel in der Situation? | ||
- | ## Entscheidung | + | Auswirkung auf Roaming bei Paketverlust: |
+ | node-client-ip und die dazugehörige Route wird erst später übernommen. | ||
+ | |||
+ | |||
+ | |||
+ | ### 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. | ||
+ | |||
+ | ### 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, | ||
Was meint ihr? | Was meint ihr? | ||
+ | |||
+ | # Lösung | ||
+ | Ich habe ACK implementiert. |