Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
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. | 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 | + | 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: | ||
+ | node-client-ip und die dazugehörige Route wird erst später | ||
- | 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. | ### 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. | 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, | ||
- | ## Entscheidung | ||
Was meint ihr? | Was meint ihr? | ||
+ | |||
+ | # Lösung | ||
+ | Ich habe ACK implementiert. |