Peer address obtention from Peer Id

[martinmsb]

I am using the Kademlia protocol and I am not sure how to obtain Peers' Addresses.
Once I obtain a Peer Id which is not in the local peer Routing Table, I would like to obtain its Addresses but I am not able to find the correct function for it. I have seen in the documentation that in previous versions it was provided a function, addresses_of_peer, where using a Peer Id, it was possible to obtain a Multiaddress vector as result, but in the actual version of I do not find it. Has it been replaced with something? Is it possible to obtain what I have described using any other function?
Thank you all in advance.

[jxs]

Hi, have you seen #3633?

[martinmsb]

Yes thank you, there is one example using k-buckets, but that would only work for peers in local routing table.
I have found #4103 but seems that is still in discussion.

[guillaumemichel]

If I understand correctly there are 2 different things:

1. Once you know the Peer Id, you want to make a Kademlia FIND_NODE RPC to discover the multiaddresses of this node (or even open a connection)
2. If you connected to a Peer in the past, you want to find its addresses locally (e.g from a Peerstore).

By looking at the doc and skimming quickly through the implementation, I didn't find any find_peer function exposed by Kademlia. This feature seems essential for Kad users, and if it is actually missing we should implement it.

The following call is possible, but AFAIU it isn't possible to recover the results of the queries (containing the addresses of the target PeerId).

let qid: kad::QueryId = swarm.behaviour_mut().get_closest_peers(PeerId::random());

Additionally, it would be great to have a Peerstore or abstraction get_addrs(peer_id) that either returns the addresses locally stored or makes a kad FIND_NODE RPC to find the addresses.

[martinmsb]

The find_peer function was previously implemented as addresses_of_peer, I am not sure why was it removed.
I am not sure about the call you mention, I only see this one with key as input:

pub fn get_closest_peers<K>(&mut self, key: K) -> QueryId

However, the query results can be recovered as:

/// The successful result of [`Behaviour::get_closest_peers`].
#[derive(Debug, Clone)]
pub struct GetClosestPeersOk {
    pub key: Vec<u8>,
    pub peers: Vec<PeerId>,
}

which neither provides any address.

[guillaumemichel]

What I meant, is that the closest RPC (from FIND_NODE) that can get initiated from the swarm is get_closest_peers, and it doesn't provide any multiaddresses in return. So IIUC there is no way to execute a find_peer from the swarm to discover the mutliaddresses associated with a peer id.

[drHuangMHT]

A DHT in my opinion is a very large and shared(D in distributed) binary tree(T in table) with PeerId(H in hash) in bits serving as the logical position of the peer. That's it, but of course you can associate some data with the records(peer entry). So in theory, if you build the tree along with address information, you can simply look up the tree using PeerId to find the peer and associated data(address) just like traversing through BTree. Buckets are a small collection of peers that is logically close to each other, and dividing the tree into smaller subtrees(buckets) reduces the cost to build the tree, because you can ignore empty part of the tree.

[drHuangMHT]

So there are two situations when trying to look up the address of a peer:

• The peer is locally present in the tree: simply return locally stored value.
• The peer is not present in local tree: issue FIND_NODE to the network and wait for response.

However I did not see the former being implemented, which is not so intuitive. Whenever I call find_closest_peer it always returns Err with peer not found, even if I'm looking up the peer I use to bootstrap the behaviour.
Also a note for bootstraping. In my opinion the bootstrap process first connect to nodes used for bootstraping and get their view of the tree, then traverse the tree on local node trying to reach every node present in the tree and update the local tree as more peers get visited.