You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 RT connectivity changes go-libp2p-kad-dht#482 (comment) 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.
The text was updated successfully, but these errors were encountered:
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 RT connectivity changes go-libp2p-kad-dht#482 (comment) 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.The text was updated successfully, but these errors were encountered: