Lifecycle of peer addresses in the peerstore

Implementers and Contributors
1

I was trying to understand how we manage the “lifecycle” of peer addresses in the peerstore. Here are some notes I’ve gathered:

  1. 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 = 2 minutes. 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 .

  2. Upon a succesful connection to a peer, Identify invalidates all existing addresses by setting the TTL to transientTTL = 10 seconds & then adding the ListenAddresses it sees with a “permanent” TTL. We do not persist the RemoteMultiAddr of 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

  3. When we disconnect from a peer, Identify receives a Disconnect notification from Swarm and 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.

  4. 2 and 3 above are synchronised via a mutex in Identify to prevent race between connects/disconnects.

1 Like