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

feat: quic,webtransport: enable both quic-draft29 and quic-v1 addrs on quic. only quic-v1 on webtransport #1881

Merged
merged 19 commits into from
Nov 17, 2022

Conversation

MarcoPolo
Copy link
Collaborator

Fixes #1841 see that issue for more context.

This lets transports advertise multiple multiaddrs. Allows the quic transport to advertise both QUIC versions draft29 and 1. Changes webtransport to only support QUIC version 1.

Before merge:

Copy link
Contributor

@marten-seemann marten-seemann left a comment

Choose a reason for hiding this comment

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

This turned out to be a much larger change than I expected. Good work here.

Contrary to what the PR title suggests, we're not advertising draft-29 for WebTransport, right? This is the reasonable thing to do. We don't need draft-29 to support WebTransport (it's unclear if it's even RFC-compliant to run WebTransport over draft versions).

p2p/transport/quic/listener.go Outdated Show resolved Hide resolved
rcmgr network.ResourceManager
privKey ic.PrivKey
localPeer peer.ID
localMultiaddrs map[quic.VersionNumber]ma.Multiaddr
Copy link
Contributor

Choose a reason for hiding this comment

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

Does a map make sense here? Alternatively, we could just have 2 member variables (localMultiaddrDraft29 and localMultiaddrQUICv1).
I don't expect us to add any more QUIC versions here any time soon (the opposite actually, we'll be dropping draft-29 long before we'll have a new incompatible QUIC version).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It's a bit cleaner when we access them: https://github.com/libp2p/go-libp2p/blob/marco/quic-v1/p2p/transport/quic/listener.go#L143

Otherwise we'd have to branch and update a variable. Not really a problem, just a bit less tidy imo. I don't have a strong opinion here so if you feel strongly we can use two vars.

Copy link
Contributor

Choose a reason for hiding this comment

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

No strong opinion either, but using two vars would make the return order of LocalMultiAddr deterministic, which would be nice (see #1881 (comment)).

p2p/transport/quic/listener.go Outdated Show resolved Hide resolved
p2p/transport/quic/listener.go Show resolved Hide resolved
p2p/transport/quic/listener_test.go Show resolved Hide resolved
p2p/transport/quic/quic_multiaddr.go Outdated Show resolved Hide resolved
}

func fromQuicMultiaddr(addr ma.Multiaddr) (net.Addr, error) {
return manet.ToNetAddr(addr.Decapsulate(quicMA))
func fromQuicMultiaddr(addr ma.Multiaddr) (net.Addr, quic.VersionNumber, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Alternatively (might loop through the multiaddr twice, but easier to read):

func fromQuicMultiaddr(addr ma.Multiaddr) (net.Addr, quic.VersionNumber, error) {
     if _, err := addr.ValueForProtocol(ma.P_QUIC); err == nil {
           return manet.ToNetAddr(addr.Decapsulate(quicV1MA))
     }
     if _, err := addr.ValueForProtocol(ma.P_QUIC_V1); err == nil {
           return manet.ToNetAddr(addr.Decapsulate(quicDraft29MA))
     }
     return errors.New("not a QUIC multiaddr")
}

Copy link
Collaborator Author

@MarcoPolo MarcoPolo Nov 16, 2022

Choose a reason for hiding this comment

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

Preference for keeping this such that we iterate the multiaddr fewer times. (I've even made a change to join the multiaddrs once at the end instead of each step).

Do you feel strongly here?

Copy link
Contributor

Choose a reason for hiding this comment

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

In general, it feels "wrong" to do that much multiaddr magic in libp2p packages. Maybe the API we expose in multiaddr is insufficient? Or are we over-optimizing things here?

Anyway, no strong feelings, I'm ok with keeping this as is, just something to think about.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe the API we expose in multiaddr is insufficient

I think so. I think there are some things we can add that would replace 80% of our uses of ForEach.

p2p/net/swarm/swarm_addr.go Outdated Show resolved Hide resolved
p2p/net/swarm/swarm_listen.go Show resolved Hide resolved
p2p/transport/quic/transport.go Show resolved Hide resolved
@MarcoPolo MarcoPolo marked this pull request as draft November 15, 2022 23:11
@MarcoPolo MarcoPolo changed the title feat: quic,webtransport: enable both quic-draft29 and quic-v1 addrs feat: quic,webtransport: enable both quic-draft29 and quic-v1 addrs on quic. only quic-v1 on webtransport Nov 15, 2022
@MarcoPolo MarcoPolo marked this pull request as ready for review November 16, 2022 03:33
ConnsInbound: 4,
ConnsOutbound: 8,
ConnsInbound: 6,
ConnsOutbound: 6,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are you modifying the limits 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.

A bit more info in the commit: a969c6d

We see flakiness in CI because a client will dial with concurrency 8 but the limit on the server is 4 so we get rcmgr failures. We notice this when we have a lot of addrs to dial

// can optionally implement if they want to filter the multiaddrs.
//
// This mutates the input
func maybeRemoveQUICDraft29(addrs []ma.Multiaddr) []ma.Multiaddr {
Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch!

p2p/transport/quic/transport.go Outdated Show resolved Hide resolved
@marten-seemann
Copy link
Contributor

@MarcoPolo I just released quic-go v0.31.0. Let's get #1882 merged and then rebase this PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

quic: advertise both quic-draft29 and quic-v1 addresses
2 participants