Peer address discovery through bootstrap node

[depechec0de]

Hello, I am new to libp2p so sorry in advance if I assume something incorrectly.

I have a node B with a known address, and nodes A and C connected to B, so B works as a bootstrap for the system. My goal is to make A and C communicate directly. Because this is not a local network, I think I will need to use Kademlia in order for A to know the connection address of C and dial him. We can assume that A knows the public key of C.

• First, Is Kademlia the correct protocol for this?
• What are the events that I should listen from Kademlia in order to do this? In which steps?
• In my understanding node A should learn C's Multiaddrs and choose one to connect. Should A query manually for this info or I just need to listen to events from Kademlia?

I am also using the identify protocol in my behavior, but to be honest I don't know what purpose is serving. Any clarification about this will also help me.

Thanks in advance. I couldn't find a proper doc talking about this, but maybe I suck at googling.

EDIT: After more research, adding a call to swarm.kademlia.add_address(&peer_id, endpoint.get_remote_address().clone()); when a node handles a SwarmEvent::ConnectionEstablished { peer_id, endpoint, ..} event seems to trigger connections between A and C. This looks like what I am looking for, but my questions still remain, I want to understand properly why this is working and if it is the correct way.

• Is this the proper behavior when all nodes are in server mode in Kad? They automatically try to connect to each other? If A wants to send a request to C, Should I maintain some kind of state machine where A first waits to know some address of C, to be connected, and then finally send a request-response message?

[dariusc93]

First, Is Kademlia the correct protocol for this?

It is one of many protocols that can do this, but yes you can use kademlia to discover peers

What are the events that I should listen from Kademlia in order to do this? In which steps?

You can call Behaviour::get_closest_peers, which would get the closest peer.

In my understanding node A should learn C's Multiaddrs and choose one to connect. Should A query manually for this info or I just need to listen to events from Kademlia?

When the peer is discovered, its addressed is stored in the kbucket, which would make it dialable via Spawn::dial, though to get the address from the behaviour for the peers, you would need to use Behaviour::find_closest_local_peers (see #5626 and #5645)

• Is this the proper behavior when all nodes are in server mode in Kad? They automatically try to connect to each other?

They would connect if they are added to the kbucket, which would happen when during the bootstrap process or if they are added via Behaviour::add_address (which would also trigger the bootstrap process too if it is set to be done automatically). This is why A and C are able to connect because they both are using B for bootstrapping, which would provide information about A to C and C to A (and probably more if more peers are connecting to B) so they could respond to queries.

If A wants to send a request to C, Should I maintain some kind of state machine where A first waits to know some address of C, to be connected, and then finally send a request-response message?

You could wait for the connection to be established before sending a message, although the behaviour would do that for you already unless you want to handle the state yourself.

rust-libp2p/protocols/request-response/src/lib.rs

Lines 427 to 446 in b187c14

	pub fn send_request(&mut self, peer: &PeerId, request: TCodec::Request) -> OutboundRequestId {
	let request_id = self.next_outbound_request_id();
	let request = OutboundMessage {
	request_id,
	request,
	protocols: self.outbound_protocols.clone(),
	};
	if let Some(request) = self.try_send_request(peer, request) {
	self.pending_events.push_back(ToSwarm::Dial {
	opts: DialOpts::peer_id(*peer).build(),
	});
	self.pending_outbound_requests
	.entry(*peer)
	.or_default()
	.push(request);
	}
	request_id
	}

rust-libp2p/protocols/request-response/src/lib.rs

Lines 729 to 747 in b187c14

	fn handle_established_inbound_connection(
	&mut self,
	connection_id: ConnectionId,
	peer: PeerId,
	_: &Multiaddr,
	_: &Multiaddr,
	) -> Result<THandler<Self>, ConnectionDenied> {
	let mut handler = Handler::new(
	self.inbound_protocols.clone(),
	self.codec.clone(),
	self.config.request_timeout,
	self.next_inbound_request_id.clone(),
	self.config.max_concurrent_streams,
	);
	self.preload_new_handler(&mut handler, peer, connection_id, None);
	Ok(handler)
	}

rust-libp2p/protocols/request-response/src/lib.rs

Lines 772 to 796 in b187c14

	fn handle_established_outbound_connection(
	&mut self,
	connection_id: ConnectionId,
	peer: PeerId,
	remote_address: &Multiaddr,
	_: Endpoint,
	_: PortUse,
	) -> Result<THandler<Self>, ConnectionDenied> {
	let mut handler = Handler::new(
	self.inbound_protocols.clone(),
	self.codec.clone(),
	self.config.request_timeout,
	self.next_inbound_request_id.clone(),
	self.config.max_concurrent_streams,
	);
	self.preload_new_handler(
	&mut handler,
	peer,
	connection_id,
	Some(remote_address.clone()),
	);
	Ok(handler)
	}

[depechec0de]

@dariusc93 thank you for taking the time to reply.

When you say "one of the many protocols" you mean for example rendezvous or relay?

In a more philosophical question, why do they all do a similar job in the background? Why not extract that functionality in a common protocol that only do peer discovery and other protocols are on top of this hypothetical one?

[drHuangMHT]

In a more philosophical question, why do they all do a similar job in the background? Why not extract that functionality in a common protocol that only do peer discovery and other protocols are on top of this hypothetical one?

They are the building blocks that you can use for your own hypothetical peer-discovery protocol(may be not on a protocol level since the peers may not support all of the protocol). Kadelima is more of a passive protocol while rendezvous is more active. Their goals are (more or less)the same, but that doesn't mean what they do is the same. Sure, discovering a peer by calling one simple function is very easy to do on the surface, but there is huge complexity to manage under the hood.
Also, even you have all those ways of peer-discovery properly implemented, it is not guaranteed to successfully discover the peer you want. Though the more ways you have in hand the higher your chance of success.