I was going to write more articles explaining DHTs in more detail, but I can at least write here a short answer. My general belief about dealing with nodes lea

I was going to write more articles explaining DHTs in more detail, but I can at least write here a short answer. My general belief about dealing with nodes leaving the network is as follows: You just notice at some point that a node doesn't respond, and then you look for a better one. That is because a node leaving the network could be caused by a failure or a user that kills the program. A node leaving the network is an interesting time, because the node doesn't have any incentive to behave well. If a node x wants to join the network, he will first contact a representitive y on the network. y will then search for x inside the DHT, and find the best location. y will then send x that location on the DHT, and x will just join there. You might be wondering how will the links be set up at this point. At the Chord DHT there is an operation called stabilize that is run from time to time. This operation is where every node updates his finger table. It is mentioned in a more detailed fashion in the original article. I didn't deal with those stuff in the article I wrote because I will deal with them in the future, talking about DHT security and stability. EDIT: One thing that people forget from time to time is that DHTs have some hidden assumption that allows them to work. A DHT assumes that things don't change too fast. At least not too fast that individual nodes can not follow. DHTs can deal with a few nodes joining and leaving, but if lots of nodes become offline in one moment, you might face a problem. Thanks for reading.