Skip to content
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

ObsAddrManager: Infer external addresses for transports that share the same listening address. #2892

Merged
merged 3 commits into from
Aug 1, 2024

Conversation

MarcoPolo
Copy link
Collaborator

@MarcoPolo MarcoPolo commented Jul 30, 2024

The Observed Address manager can now infer external addresses for transports that share the same listening address if another transport has an observation.

For example, say I'm listening on UDP 0.0.0.0:4001 for QUIC, WebTransport, and WebRTC. And I learn that my external IP address for QUIC is 5.4.3.2:4001 (as reported by my peers). This means I can infer that my external WebTransport and WebRTC addresses are also 5.4.3.2:4001 since these other transports are using the same underlying socket.

This PR also removes the old hack that inferred WebTransport address. It was hacky because we didn't have access to the connection of external <-> local address like the observed address manager does.

@sukunrt
Copy link
Member

sukunrt commented Jul 31, 2024

Not quite :(
The current implementation depends on having 1 connection on that transport to infer the addresses. This should be easy enough to fix though.

@MarcoPolo MarcoPolo changed the title fix: Remove inferWebtransportAddrsFromQuic ObsAddrManager: Infer external addresses for transports that share the same listening address. Jul 31, 2024
twToObserverSets[localTWStr] = append(twToObserverSets[localTWStr], o.getTopExternalAddrs(localTWStr)...)
}
}
for _, a := range o.listenAddrs() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you'll need to infer for interfaceListenAddrs also.

It's okay for the time being since that's only relevant for tcp and we don't share tcp addresses with any other transport.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not completely sure about this but I think this is what happens.

When listening on 0.0.0.0 on tcp, the listen address is 0.0.0.0 but conn.LocalMultiAddr() on the connection is something like 192.168.1.34. which is the specific network interface that was used for the connection.

On UDP, conn.LocalMultiAddr() is always 0.0.0.0

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I'm now doing it on both listenAddrs and interfaceListenAddrs. I think in the ideal world we would just use interfaceListenAddrs because those are what map to the 4-tuple for connection flows. For UDP right now, this doesn't work yet as you say. So we have to do it for both because the 0.0.0.0 is what shows up in the observed address mapping due to it being the conn.LocalMultiAddr result.

addrs = append(addrs, s.cacheMultiaddr(t.Rest))
}
}
return addrs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to do a ma.Unique here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a case where we have multiple identical normalized listen addresses?

@MarcoPolo MarcoPolo merged commit 0cc0b2f into master Aug 1, 2024
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants