-
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
[Tracking Issue] transports/quic: Add QUIC Transport #2883
Comments
Thanks for creating this @elenaf9! Whenever you make a significant change to the original issue description, would you mind posting a comment like #2052 (comment)? That way, everyone subscribed to this issue gets a notification. |
Changelog
|
Changelog
|
Should Stateless Reset handling / generation be added to the Long Term list? |
Changelog:
|
Changelog: Added link to kpp#27 (comment) so we don't forget to refactor the TLS-config handling. |
Changelog:
|
I hope this is the right place to ask. Is quic supported on relay-v2, and if not, what are the future plans regarding this? |
@geotro yes it is supported. You can combine them in the same manner as it is done here with tcp and quic: rust-libp2p/transports/quic/tests/smoke.rs Lines 118 to 136 in a714864
and either replace the Does this help? |
Changelog |
@elenaf9 it helps a bit, but I was hoping that once QUIC is implemented to be able to do UDP, as well as DCUTR. Why are you referring to TCP in the context of QUIC? I understand DCUTR with QUIC is not yet supported so I'll have to wait until that works before I retry it. |
I was referring to TCP to point out how you could support both TCP and QUIC together with the relay-v2 protocol. But TCP is not required, you may as well just combine QUIC and relay-v2. |
Ah OK, thank you for clarifying this! My use case requires DCUTR so I'm going to have to wait until this is available together with QUIC before I can begin testing/using it. Very much looking forward to this as I hope it's going to greatly improve the success rates of establishing a direct connection! |
Notes: - This is only compatible with v1 so likelihood of connecting to go-libp2p and go-ipfs/kubo peers via quic will unlikely to work until draft-29 is supported in rust-libp2p (see libp2p/rust-libp2p#3133) - DCuTR will not work with quic-v1 at this time so unless port mapping/UPNP is used (coming later), we wont be able to utilize quic-v1 with hole punching, but should work fine with relay (see libp2p/rust-libp2p#2883) Closes #10
Is there an issue or note somewhere what is missing for a working setup with QUIC + DCUTR + relay v2? Looking what pieces are missing there and would love any pointers. |
As far as I remember, the only thing missing is the implementation of rust-libp2p/transports/quic/src/transport.rs Lines 182 to 191 in 56b3b8f
Note that https://github.com/libp2p/punchr/blob/main/rust-client/ is already using QUIC for hole punching, though only on the @Frando contributions here are welcome. |
Posting some in-progress research on the various Rust QUIC implementations out there. VerdictThus far my preference is still
With #3454, Next step: Report our performance measurements to Comparison
//CC @marten-seemann |
Thanks for compiling this list @mxinden! This looks pretty comprehensive. Some thoughts:
|
The way it is implemented in #3964 is through channels sending quinn_proto::Transmit. However the go impl uses multiple sockets with SO_REUSEPORT. So in quinn wrapper we can go both ways not sure which one is better. |
Implement `Transport::dial_as_listener` for QUIC as specified by the [DCUtR spec](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md). To facilitate hole punching in QUIC, one side needs to send random UDP packets to establish a mapping in the routing table of the NAT device. If successful, our listener will emit a new inbound connection. This connection needs to then be sent to the dialing task. We achieve this by storing a `HashMap` of hole punch attempts indexed by the remote's `SocketAddr`. A matching incoming connection is then sent via a oneshot channel to the dialing task which continues with upgrading the connection. Related #2883. Pull-Request: #3964.
It appears that the above description of this issue is rather outdated, do you mind updating it? |
Status Update We just released |
I am closing here as the major milestone, adding QUIC to rust-libp2p, is achieved. Smaller follow-up improvements are tracked in individual issues. Thank you to the many many many people involved in this effort. ❤️ |
Summary
Implement the QUIC transport for rust-libp2p.
Done criteria
Swarm
for communication between nodes that can directly reach each otherStatus Quo
Alpha implementation based on
quinn
crate. See #3454.Previous attempts / History
picoquic
quinn
because back then mostquinn
types were!Send
quinn-proto
tomaka/quiccc-again
libp2p-quic
quinn-proto
#2289 [Most recent PR]tomaka/quiccc-again
branchquinn-proto
#2289quinn
instead ofquinn-proto
Tasks
quinn-proto
#2289:UdpSocket
fromquinn_udp
instead of the ruststd
implementationstd
ones for the first version.quic
codepoint , interpreted as QUIC version draft-29 #3133Long-term (not required for first implementation):
Transport::dial_as_listener
to support hole-punching feat(quic): implement hole punching #3964quinn_proto
quic implementations2n-quic
(AWS)quiche
(Cloudflare)PeerId
-validation on TLS level: Add muxer compliance test suite and refactor tests to not depend onlibp2p-swarm
kpp/rust-libp2p#27 (comment) Consider verifying expectedPeerId
as part of auth upgrades #2946The text was updated successfully, but these errors were encountered: