4 ms·
The "leave" portion of the protocol strikes me as unrealistic. Typically, when a node leaves a network it does so without warning and doesn't have tie to copy i
by etrain 15y ago
The "leave" portion of the protocol strikes me as unrealistic. Typically, when a node leaves a network it does so without warning and doesn't have tie to copy its data back. Maybe some level of redundancy will be discussed in the followup.
- lukesandberg 15y agoI noticed that too. But i can understand why the left it out. As soon as you add redundancy you need to start worrying about write consistency.
- peterwwillis 15y agoI would think one would dedicate N*2 nodes for a dataset N and just copy the data in any given node to its closest neighbor node. If the lookup for the primary node fails, try its closest neighbor, and if you really want to get snazzy then have that failover neighbor start to copy data to its closest neighbor until you get a replacement node up. A failover daemon on each node will detect when a neighbor goes down and block writes to a copy of data until it's sure the neighbor is down, and won't accept new copies until both it detects the neighbor is back up and has resolved time-based differences in datasets. Probably not foolproof but it's a start :)
- morazow 15y agoFor particular DHT, namely Chord, a node has f successor list where it stores the replicas of data on each f successors. After failure of a node, the data is stored in its successor list. However, this introduces more overhead to the system, after breakdown find successors and replicate date, and stabilize function should check every successor-list to find inconsistent links. Some other DHTs use interval based division, divide the nodes into fixed intervals and all the nodes in one interval store the data in all other nodes in that interval.