libp2p / libp2p/go-libp2p

[AutoNAT client] Refactor how we manage AutoNAT server addresses

Open
#809 1 comment 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.