Based on some good ideas by @aschmahmann , here's a couple of things we can do to improve how we manage the replacement cache & "dead" peers:
Since the replacement cache is bounded, we could lose potential candidates if it's full. So, when we eject a candidate from the replacement cache either because it goes into the RT or it's not reachable, we should replace it with a connected peer that is neither in the RT nor in the replacement cache.
See https://github.com/libp2p/go-libp2p-kad-dht/pull/482#discussion_r389492178 for the motivating discussion.
When DHT calls HandleDeadPeer on the RT for a peer, we immediately eject it from the RT without replacing it. Currently, the DHT does this for a connected peer that stops being a DHT server. We should replace such peers.
Based on some good ideas by @aschmahmann , here's a couple of things we can do to improve how we manage the replacement cache & "dead" peers:
Since the replacement cache is bounded, we could lose potential candidates if it's full. So, when we eject a candidate from the replacement cache either because it goes into the RT or it's not reachable, we should replace it with a connected peer that is neither in the RT nor in the replacement cache. See https://github.com/libp2p/go-libp2p-kad-dht/pull/482#discussion_r389492178 for the motivating discussion.
When DHT calls
HandleDeadPeer
on the RT for a peer, we immediately eject it from the RT without replacing it. Currently, the DHT does this for a connected peer that stops being a DHT server. We should replace such peers.