NAT Traversal ETA?

Toivo · February 12, 2024, 11:31am

Hah, since November, I’ve been very frustrated to see almost nothing happening with Autonat in the corresponding PR here :

github.com/libp2p/rust-libp2p

refactor(core, swarm): Transport redesign

libp2p:master ← umgefahren:transport-redesign

opened 09:20PM - 27 Sep 23 UTC

umgefahren

+456 -499

## Description First implementation of the redesign of the Transport trait. T…his should not be merged, but instead a place where the proposed changes are discussed. This PR belongs to #4226. I have implemented the trait, according to what has been discussed in the https://github.com/libp2p/rust-libp2p/issues/4226#issuecomment-1737221327. ## Notes & open questions What do you think of the implementation? ## Change checklist - [ ] I have performed a self-review of my own code - [ ] I have made corresponding changes to the documentation - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] A changelog entry has been made in the appropriate crates

And now I just found out, that the work has been going on all the time here :

github.com/umgefahren/rust-libp2p

feat(autonatv2): Implement autonat v2

umgefahren:transport-redesign ← umgefahren:implement-autonat-v2

opened 04:08PM - 07 Nov 23 UTC

umgefahren

+3829 -378

## Description This is a WIP implementation of AutoNATv2. I would appreci…ate feedback by @mxinden and @thomaseizinger. You don't have to go into any specifics, I just wanted to check up if the direction is correct. A complete and formal PR will follow once everything is done. - 🚧 Client - ConnectionHandler (~80% done) - 🚧 Client - Behavior (~10% done) - 🌰 Server - ConnectionHandler - 🌰 Server - Behavior I'm sorry it took me so long to give a sign of life. I sunk a lot of hours into doing it with request-response just to discover I need to do it without it. Additionally I couldn't work on it for the last week since I had to study for a midterm.  ## Notes & open questions  ## Change checklist - [ ] I have performed a self-review of my own code - [ ] I have made corresponding changes to the documentation - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] A changelog entry has been made in the appropriate crates

And while there’s no definite ETA yet, this comment makes me feel, that it’s not that far away anymore :

github.com/umgefahren/rust-libp2p

Comment by thomaseizinger - feat(autonatv2): Implement autonat v2

umgefahren:transport-redesign ← umgefahren:implement-autonat-v2

To ensure we are on the right track, here is my view of what we still need from …this work: - Integration of the dial-back ACK from client to server. We need to make sure that we are only sending this once the `Behaviour` has processed the nonce to ensure data consistency. This is a bit tricky / annoying because the Rust ecosystem doesn't have good async generators yet so writing a sequential stream that yields is annoying. Why do we need this? Well, the functionality we _should_ implement is: - Read nonce from the stream - Yield the nonce to the behaviour - Wait - Have the behaviour signal that it processed the nonce (remember that they run on different tasks, so actually in parallel) - Send the `Ok` response on the stream From the perspective of the handler, this is a sequential operation that maps to a stream which yields on a single item (the nonce) and later terminates (after sending the `Ok` response). The waiting we can model with a `oneshot` where we pass the `Sender` up to the `Behaviour` and signal that things are ready to continue by waiting on the `Receiver` inside the handler. Importantly, I think we also want all of this to be within a timeout, meaning that using `futures_bounded::StreamSet` would be good. I think we will need something like (pseudo-code): ```rust struct State { io: swarm::Stream, oneshot: Option<Receiver<()>> } let stream = futures::stream::unfold(state, |mut state| async move { if let Some(receiver) = state.oneshot { if receiver.await.is_err() { // Fail here: behaviour did not process nonce successfully (i.e. `incomingNonce` got dropped earlier). // Maybe we can just `?` together with the below IO errors? }; state.io.send(DialBackOk).await; // TODO: Error handling. state.io.close().await; return None; // Signal stream finished. } let nonce = io.next().await; let (sender, receiver) = oneshot::channel(); let yielded = IncomingNonce { nonce, sender, }; state.oneshot = Some(receiver); Some((yielded, state)) }); ``` The above is a rough sketch. Let me know if you get the idea :) - Once our unit-tests are stable, we will need a smoke-test with `go-libp2p` to ensure that it works correctly. - Fix the bugs that turn up during the smoke test. - After all that is confirmed, we have successfully validated our design and can continue work on https://github.com/libp2p/rust-libp2p/pull/4568 to make it compile and merge it. - Move this PR to `rust-libp2p` and merge that. - Cut a new breaking release with this feature.

Topic		Replies	Views
NAT Traversal - possible ideas and solutions Development	16	995	February 20, 2023
NatNet [May 26 Testnet 2023] [Offline] Releases	131	3160	June 1, 2023
Nat detection still has some unnecessary issues Support	11	354	August 25, 2024
PunchNet [24/04/24 Testnet] [Offline] Releases	656	4343	May 9, 2024
Update 27 April, 2023 Updates	25	2178	May 7, 2023

NAT Traversal ETA?

Related topics