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.
| status: Status::Disable, | ||
| auto_status_change: true, |
There was a problem hiding this comment.
Can we please document this default behavior somewhere?
Co-authored-by: Elena Frank <elena.frank@proton.me>
| ([], Status::Enable) => { | ||
| tracing::debug!("disabling protocol advertisment because we no longer have any confirmed external addresses"); | ||
| Status::Disable |
There was a problem hiding this comment.
I think that this is important info for the user. What do you think of adding a variant Event::StatusChanged { new: Status }, that is returned to the user?
There was a problem hiding this comment.
I am not against it. I do have the snippet locally but held off since I was avoiding having this be a breaking change, however I will go on and add it since it will already be based on what was previously discussed :)
| } | ||
| } |
There was a problem hiding this comment.
I think we should wake the waker here, where we push to the event queue.
That way we also do it when the status changes due to a on_swarm_event. Technically it is not needed because in that case the behavior gets polled again anyway, but better be safe.
There was a problem hiding this comment.
If we put it here then we probably remove it from Behaviour::set_status.
Technically it is not needed because in that case the behavior gets polled again anyway, but better be safe
Yea, the behaviour would get polled again if there is activity causing the executor to poll it again, but if the status changes, there should be some way indicate that the behaviour needs to be polled again if nothing else is causing swarm to make progress
…feat/relay-enable-disable
2 participants
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