Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| wiki:missing_info [10.05.2018 16:04] – christf | wiki:missing_info [31.10.2018 12:19] (aktuell) – [eine verteilte Datenbank einführen, die den client-state hält] christf | ||
|---|---|---|---|
| Zeile 28: | Zeile 28: | ||
| ### 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 48: | Zeile 52: | ||
| Was meint ihr? | Was meint ihr? | ||
| + | |||
| + | # Lösung | ||
| + | Ich habe ACK implementiert. | ||