feat(relay): allow enabling and disabling of relay HOP advertisement #6154
Conversation
dariusc93
changed the title
There was a problem hiding this comment.
Thanks for the PR and sorry for the delay!
Although nothing is mentioned in libp2p spec (besides maintaining the reservation), should we disconnect peers who have an active reservation with the relay when the node is no longer reachable (ie if the node decides to disable advertisement of its protocol, or if there are no external addresses available if its determined automatically) or should we maintain the current reservations until they expire?
I wouldn't disconnect them if there is an active circuit for the peer, because in that case we are already connected to both, dialer and listener.
If not, I am unsure. We currently also don't tell clients if individual external addresses expire, so they might be advertising outdated info anyway. And it might also be that we are just temporarily unreachable in which case we probably don't want to immediately close all active reservations. So I am leaning towards not disconnecting. Or only disconnect if the status was manually set to disable.
protocols/relay/src/behaviour.rs
Outdated
| for (peer_id, connections) in self.reservations.iter() { | ||
| self.queued_actions | ||
| .extend(connections.iter().map(|id| ToSwarm::NotifyHandler { | ||
| peer_id: *peer_id, | ||
| handler: NotifyHandler::One(*id), | ||
| event: Either::Left(handler::In::SetStatus { | ||
| status: self.status, | ||
| }), | ||
| })); | ||
| } |
There was a problem hiding this comment.
Don't we need to inform all handlers? I think otherwise existing connection handlers without an active reservation would still have the outdated status.
There was a problem hiding this comment.
Yea we should. Good catch. Forgot this behaviour only tracks active reservations instead of every connection. Will update this shortly.
| status: Status::Disable, | ||
| auto_status_change: true, |
There was a problem hiding this comment.
Can we please document this default behavior somewhere?
| - Automatically configure HOP protocol advertisement based on external addresses, with the ability to override this | ||
| functionality using `Behaviour::set_status` to explicitly set `Status::{Enable,Disable}` to enable or disable | ||
| protocol advertisement. | ||
| See [PR 6154](https://github.com/libp2p/rust-libp2p/pull/6154). |
There was a problem hiding this comment.
I think this is a breaking change. Previously, the HOP advertisement was always enabled, whereas now it depends on external addresses being present. The behavior in the end is probably the same (reservations only work if external addresses are present), but the error on the client side will be a different one.
There was a problem hiding this comment.
I was a bit torn on if this would be considered breaking or not since if the relay message doesnt contain the addresses (which in our case, external addresses), it would error on the client side when attempting to establish a reservation, though in this case it would give a different error message compared to previously where if the relay didnt have an external address since it would not be advertising its protocol without it being enabled in some manner. I guess in a sense, it would be though since it would be a different error than what is expecting (probably should check and see the errors myself too)
| connections: HashMap<PeerId, HashSet<ConnectionId>>, | ||
| reservations: HashMap<PeerId, HashSet<ConnectionId>>, |
There was a problem hiding this comment.
Im almost inclined to say we should merge this in some way so we can track connections and the connections that have reservations. Could probably be done in a separate PR though. Thoughts?
Description
This PR allows the relay to enable and disable its advertisement of the HOP protocol, with the option to automatically determine if the relay should advertise its protocol and function based on its reachability via external addresses (following suite with how libp2p-kad operates)
resolves #4260.
Notes & open questions
Status. Should we change it to any other name likeMode, etc?By default, the status is set to enabled to prevent it from "breaking" relays that do update to a version with this PR merged, but given that the relay need external addresses to operate (the clients with STOP would receive an error if the relay does not have an external address), should have it set to automatic instead, allowing it to be override later on?Additionally, as a note that this is WIP as this is not tested (yet) and mostly to throw the idea out there based on the issue above (#4260)
Change checklist