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

quicreuse: make it possible to use an application-constructed quic.Transport #3122

Merged
merged 10 commits into from
Jan 10, 2025

Conversation

marten-seemann
Copy link
Contributor

It would be nice if the application was able to construct its own quic.Transport, and have that transport used by libp2p.

This would allow an application:

  • on the listener side: inject its own tls.Config on the Listen call, and Accept (a subset of) QUIC connections returned by the listener
  • on the client side: dial QUIC connections without going through libp2p at all

This would make it possible to run a vanilla HTTP/3 server behind a NAT / firewall and use libp2p's NAT hole punching mechanism to create the NAT bindings.

We shouldn't create the listener entry. This happens once the libp2p
QUIC transport starts listening.
refCountedTr := &refcountedTransport{
QUICTransport: tr,
packetConn: conn,
isExternal: true,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does the actual owner of this transport want to know when libp2p will be done with it? My guess is yes.

Any preference for how this looks? We could accept a callback or we could return a done channel. Either way, we'd signal done when we otherwise would have closed this transport (in the case of a non "external" transport). This allows the actual owner to know when it is safe to free the transport.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure there's a lot of value in that. The only reason why libp2p would be done with this transport is when the host is closed, which is something that the owner of the transport initiated himself (by calling Host.Close). Or am I missing something?

Copy link
Collaborator

Choose a reason for hiding this comment

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

That's fair, but I think it would be a bit simpler if this package doesn't have to consider a Host for managing the lifecycle of this resource. Users could still simply ignore this signal and free after they've closed the host.

Without this, you may be closing the transport before the connmgr is actually done with it.

Copy link
Collaborator

@MarcoPolo MarcoPolo Jan 10, 2025

Choose a reason for hiding this comment

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

done in d8cc67d. Has the nice side-effect of removing the conditional branches around isExternal.

Copy link
Collaborator

@MarcoPolo MarcoPolo left a comment

Choose a reason for hiding this comment

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

Excited to see this used. Please report back

@MarcoPolo MarcoPolo merged commit 4651a0d into libp2p:master Jan 10, 2025
9 checks passed
@lidel lidel mentioned this pull request Jan 13, 2025
58 tasks
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