-
Notifications
You must be signed in to change notification settings - Fork 957
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(identify): Skip invalid multiaddr in listen_addrs #3246
Conversation
With this commit `libp2p-identify` no longer discards the whole identify payload in case a listen addr of the remote node is invalid, but instead logs the failure, skips the invalid multiaddr and parses the remaining identify payload. > This is especially relevant when rolling out a new protocol to a live network. Say that most nodes > of a network run on an implementation version v1. Say that the `multiaddr` implementation is not > aware of the `webrtc/` protocol. Say that a new version (v2) is rolled out to the network with > support for the `webrtc/` protocol, listening via `webrtc/` by default. In such case all v1 nodes > would discard all identify payloads of v2 nodes, given that the v2 identify payloads would contain > the `webrtc/` protocol in their `listen_addr` addresses. See libp2p#3244 for details.
Ok(a) => a, | ||
Err(e) => { | ||
debug!("Unable to parse multiaddr: {e:?}"); | ||
Multiaddr::empty() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not ideal but in my eyes not worse than the status quo. Downstream code has to handle a Multiaddr::empty
due to the unwrap_or_default
anyways.
One might first think that a remote could never return an observed address, i.e. an address that it observes the local node as, that the local node doesn't know. One would expect that the local node supports the multiaddr to all all its supported transport protocols. One exception is a relayed address though. The relay between A and B might use a protocol to B that A does not support nor be able to parse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One might first think that a remote could never return an observed address, i.e. an address that it observes the local node as, that the local node doesn't know.
A remote can return all sorts of garbage :)
How big is the impact if we make this field an Option
? That would be cleaner IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed that Option
would be the way to go here. That said, I think we should keep the patch release minimal, i.e. only do this on latest master
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as a bug fix. Long-term we might want to make better use of the type-system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description
With this commit
libp2p-identify
no longer discards the whole identify payload in case a listen addr of the remote node is invalid, but instead logs the failure, skips the invalid multiaddr and parses the remaining identify payload.This is especially relevant when rolling out a new protocol to a live network. Say that most nodes of a network run on an implementation version v1. Say that the
multiaddr
implementation is not aware of thewebrtc/
protocol. Say that a new version (v2) is rolled out to the network with support for thewebrtc/
protocol, listening viawebrtc/
by default. In such case all v1 nodes would discard all identify payloads of v2 nodes, given that the v2 identify payloads would contain thewebrtc/
protocol in theirlisten_addr
addresses.See #3244 for details.
Notes
v0.50
branch such that we can release a patch version oflibp2p-identify
.v0.49
release family.master
to be included inv0.51
.Links to any relevant issues
#3244
Open Questions
Change checklist