- Peer-to-Peer (P2P) Networks
- Peer Connectivity
- Peer Addressability
- Peer Findability and Message Routability
- Chord P2P + DHT Network Algorithm
- Polymorph P2P Network Algorithm
- Peer GUID Ring
- Peer Routing Table
- Finding Peers in a P2P Network
- Booting and Joining a P2P Network
- Leaving a P2P Network
- Routing Table Management
- P2P Messages
Leaving a P2P Network
Jakob Jenkov |
When a peer no longer wants to be part of a P2P network, it will send a "leave" request to all peers in its routing table. Thus, each of these peers can remove the leaving peer from their routing table.
This process is illustrated below:
![]() |
A leaving peer sends leave messages to all peers in its routing table. |
Once a "leave" message has been send to all peers in the leaving peers routing table, the peer can safely close down all network connections, and shut down.
Choord vs. Kademlia
As I mentioned in the text Peer Routing Table, there is a difference in what peers a Choord and a Kademlia network would keep in its routing table.
In Kademlia, each peer reference in the routing tables goes both ways. If A has B in its routing table, then B also has A in its routing table. That means, that all the peers in A's routing table should be notified of A leaving, so they can remove A from their routing tables.
In a Choord, if A has B in its routing table, B does not necessarily have A in its routing table. Thus,
if A leaves a Choord network, it would have to find the peers in the network that has A in its routing table.
In other words, find those peers which have distance(X, A)
closest to 20, 21,
22 etc. Once those peers are found, the leaving peer (A) will send a leave message to each of them.
As you can possibly imagine, find log(N) peers and sending a leave message to them (Choord) is slower than just sending a leave message to each peer already stored in the routing table.
Tweet | |
Jakob Jenkov |