I was trying to understand how we manage the “lifecycle” of peer addresses in the peerstore. Here are some notes I’ve gathered:
Addresses we learn of without yet having a connection to them & soon plan to connect to (DHT Findprovider, FindPeer, cached AutoNAT server peers etc.) get added with a TTL of
TempAddrTTL = 2minutes. This is done throughout the codebase. Note that if the peerstore already has a higher TTL for that address, this becomes a no-op. Hence, it’s safe to do this without racing with all that happens below .
Upon a succesful connection to a peer,
Identifyinvalidates all existing addresses by setting the TTL to
transientTTL = 10 seconds& then adding the
ListenAddressesit sees with a “permanent” TTL. We do not persist the
RemoteMultiAddrof the other peer to the peerstore here to prevent persistence of NAT/undialable address. We only want to persist addresses the peer knows it’s listening on. We leave it to the peer to discover a “publically diallable address” for itself(See How we discover our own diallable IP address and port for a great explanation on how this is done) and advertise it to us. We do persist loopback addresses for now, but there’s a PR to fix it, though we still aren’t sure if this is right thing to do: https://github.com/libp2p/go-libp2p/pull/770
When we disconnect from a peer,
Swarmand resets the TTL to
RecentlyConnectedAddrTTL=10 minutes. This is because it’s good to have the address around in case we re-attempt a connection soon.
2 and 3 above are synchronised via a mutex in
Identifyto prevent race between connects/disconnects.