Tech and Media Labs
This site uses cookies to improve the user experience.

Routing Table Management

Jakob Jenkov
Last update: 2014-05-23

In a perfect world, the join and leave requests would be enough to keep all peers routing tables up-to-date. In the real world, however, peers and networks crash from time to time, so peers fall out of the network, without sending "leave" requests.

To keep the routing tables up-to-date in spite of peer crashes, each peer in the network must periodically search for the correct peers to store in its routing table. If a peer tries to contact a peer, and that peer does not respond, that peer should be removed from its routing table.

Similarly, if a closer peer than the peer currently kept in a given cell in the routing table, has somehow joined the network without notifying the the updating peer, such a closer peer would be found during the routing table management process. Such new, closer peers can then be added to the routing table.

This diagram shows a peer contacting the peers in its routing table. Peer 4 is crashed, so it should be removed from peer 0's routing table.

A peer updating its routing table, where peer 4 is crashed.
A peer updating its routing table, where peer 4 is crashed.

Here is an illustration of a different situation. Peer 8 was not part of the network, when peer 0 built its routing table originally. Instead, peer 0 had peer 9 in its routing table. Later, peer 8 joins the network, but somehow forgets or fails to notify peer 0. When updating its routing table, peer 0 searches for peer 8, and finds it, and adds it to its routing table.

Jakob Jenkov

Copyright  Jenkov Aps
Close TOC