relay: making a reservation should emit an external address

[thomaseizinger]

Description

When we make a reservation with a relay, we essentially now have an external address that other nodes can use to connect to us. We should emit a ToSwarm::ExternalAddrConfirmed event to let the Swarm know about this. Similarly, if our reservation expires, we should remove the external address again via ToSwarm::ExternalAddrExpired.

Motivation

Emitting these events allows protocols like libp2p-identify to pick up these addresses and advertise them to other nodes.

Current Implementation

Only the following ReservationReqAccepted event is emitted:

rust-libp2p/protocols/relay/src/priv_client.rs

Lines 57 to 62 in 19c5cf2

	ReservationReqAccepted {
	relay_peer_id: PeerId,
	/// Indicates whether the request replaces an existing reservation.
	renewal: bool,
	limit: Option<protocol::Limit>,
	},

Are you planning to do it yourself in a pull request ?

No

[thomaseizinger]

@mxinden Anything you can think of why we shouldn't do this?

[mxinden]

Proposal sounds good to me! I don't see any blockers.

[thomaseizinger]

In a similar vein, currently we make a reservation with every relay we connect to. Should we perhaps limit this e.g. 10? That sounds plenty 😁

[mxinden]

we make a reservation with every relay we connect to

Oh, that is news to me. Can you point me to the code?

As far as I can tell, we don't react to it at all, no?

rust-libp2p/protocols/relay/src/priv_client/handler.rs

Line 582 in 3a0f0c2

| ConnectionEvent::RemoteProtocolsChange(_) => {}

[thomaseizinger]

we make a reservation with every relay we connect to

Oh, that is news to me. Can you point me to the code?

I thought we did but maybe that is not true. I guess we only do it when the users explicitly requests listen_on, right? That is all fine then. I thought we had a similar AutoRelay functionality as go-libp2p.

cc @dariusc93 I remember you building an auto-relay like functionality, correct? What was your experience with it?

[mxinden]

I guess we only do it when the users explicitly requests listen_on, right?

Correct.

[dariusc93]

cc @dariusc93 I remember you building an auto-relay like functionality, correct? What was your experience with it?

I did have to backtrack on some of the functionality since it was going to get overly complex (eg emitting events to swarm to find relays over DHT, etc), but one thing I have done is emit an event to provide an external addr after the reservation is made. This, honestly should be in rust-libp2p and should be simple to do

[thomaseizinger]

cc @dariusc93 I remember you building an auto-relay like functionality, correct? What was your experience with it?

I did have to backtrack on some of the functionality since it was going to get overly complex (eg emitting events to swarm to find relays over DHT, etc)

I haven't thought much about it so perhaps there is a flaw but I was imagining something like:

• auto_relay::Behaviour
• Has a config for how many relayed connections we want to aim for (something like 10 as a default)
• On each new (outgoing?) connection, examine the supported protocols of the remote and report to Behaviour whether relay is supported
• If we are < than our desired reservation count, use ToSwarm::ListenOn to make a new reservation using one of the supported relays

[dariusc93]

I haven't thought much about it so perhaps there is a flaw but I was imagining something like:

* `auto_relay::Behaviour`

* Has a config for how many relayed connections we want to aim for (something like 10 as a default)

* On each new (outgoing?) connection, examine the supported protocols of the remote and report to `Behaviour` whether relay is supported

* If we are < than our desired reservation count, use `ToSwarm::ListenOn` to make a new reservation using one of the supported relays

Minus the reservation count, thats one way i have it setup currently (which might be best for rust-libp2p too), though disabled by default (since some nodes may advertise the hop protocol but may also be sitting behind a relay themselves - see #4260 on how to possibly resolve that) so right now, one can manually adding peers and their addrs, then they can either select a specific relay, or let it randomly select, in which we would connect, validate their protocol in the handler and pass that status to the behaviour, for that peer move on from there.

[thomaseizinger]

Oh yeah, forgot about #4260. We should get that fixed. I'll open a separate issue for an Auto-Relay like functionality.

[thomaseizinger]

I'll open a separate issue for an Auto-Relay like functionality.

Done here: #4651