[AutoNAT client] Refactor how we manage AutoNAT server addresses
- Dominant language
- Go
- Stars
- 6.9k
- Forks
- 1.3k
- Avg merge
- 13d 21h
- Merged PRs (30d)
- 1
Description
Please see https://github.com/libp2p/go-libp2p-autonat/issues/40 for the motivation.
When an AutoNAT client makes a connection with an AutoNAT server, it caches the server address to prevent losing it due to a disconnection. This is messy, causes memory leaks(https://github.com/libp2p/go-libp2p-autonat/issues/9) & prevents us from discovering AutoNAT servers we were connected to before we started the AutoNAT client(https://github.com/libp2p/go-libp2p-autonat/issues/28). There should be a better way to do this.
Once we have https://github.com/libp2p/go-libp2p/issues/801 in place, we have a way to proactively request the peerstore to keep peer addresses around even after the peer disconnects. We should leverage this. A rough design would be:
* Subscribe to the `EvtPeerIdentificationCompleted` message on the Eventbus & if a peer supports the AutoNAT protocol, note down it's peerId so we can keep pinning it till we get an error while trying to probe it. Once we get a dial error, we remove the peerId from our cache & Unpin it.
* When we want to dial to an AutoNAT server, we use our cached peerIDs to ask the peer store for addresses we can dial to. The metric to shortlist the peers needs to be discussed i.e. most recently seen peers, peers that are still connected etc.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the linked motivation issues and the AutoNAT client's current server-address cache. Review EvtPeerIdentificationCompleted, peerstore address retention, and the existing pinning behavior. Done means discovering eligible AutoNAT peers through peer IDs, retaining their addresses, and removing and unpinning peers after a probe dial error; the peer-shortlisting metric still needs a decision.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100