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

refactor(*): Transport redesign #4568

Merged
merged 240 commits into from
Aug 3, 2024
Merged

Conversation

umgefahren
Copy link
Contributor

@umgefahren umgefahren commented Sep 27, 2023

Description

Resolves: #4226.
Resolves: #3953.
Resolves: #3889.

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

@umgefahren umgefahren changed the title Transport redesign refactor(core): Transport redesign Sep 27, 2023
Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

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

Great start! I left some high-level comments :)

core/src/transport.rs Outdated Show resolved Hide resolved
swarm/src/dial_opts.rs Outdated Show resolved Hide resolved
swarm/src/dial_opts.rs Outdated Show resolved Hide resolved
transports/tcp/src/lib.rs Show resolved Hide resolved
core/src/transport.rs Outdated Show resolved Hide resolved
swarm/src/lib.rs Outdated Show resolved Hide resolved
@umgefahren
Copy link
Contributor Author

umgefahren commented Sep 28, 2023

I have implemented some of the suggestions. However I didn't touch the question on whether DialOpts should be struct or the field should just be passed as arguments.

I also moved some methods into a macro.

@umgefahren
Copy link
Contributor Author

Since we are touching PortUse anyway and we don't want to introduce breaking changes in the future: Is there a use for choosing not only if we should use an existing or new one, but also a specific one?

swarm/src/lib.rs Outdated Show resolved Hide resolved
@umgefahren
Copy link
Contributor Author

At the moment I'm pretty pleased with the implementation. But I don't really like having the list of things that we wan't to strip. It feels like something that might cause a bug later on, but I honestly don't have a better idea.

@umgefahren umgefahren changed the title refactor(core): Transport redesign refactor(core, swarm): Transport redesign Oct 4, 2023
@thomaseizinger
Copy link
Contributor

But I don't really like having the list of things that we wan't to strip. It feels like something that might cause a bug later on, but I honestly don't have a better idea.

As long as we cover it with unit tests, that is fine. We can always ship improvements as patch releases later if we find that we are missing something :)

swarm/src/lib.rs Outdated Show resolved Hide resolved
swarm/src/lib.rs Outdated Show resolved Hide resolved
@umgefahren umgefahren requested a review from jxs August 2, 2024 12:06
Copy link
Contributor

mergify bot commented Aug 2, 2024

This pull request has merge conflicts. Could you please resolve them @umgefahren? 🙏

@umgefahren umgefahren changed the title refactor(*): Transport redesign refactor(*): Transport redesign, allowing for specifying port (re-)use policy when dealing Aug 2, 2024
@umgefahren umgefahren changed the title refactor(*): Transport redesign, allowing for specifying port (re-)use policy when dealing refactor(*): Transport redesign, allowing for specifying port (re-)use policy when dialing Aug 2, 2024
@umgefahren umgefahren changed the title refactor(*): Transport redesign, allowing for specifying port (re-)use policy when dialing refactor(*): Transport redesign Aug 2, 2024
Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

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

I think this is a fine solution. It is known that one of the disadvantages of enabling port reuse is that you can only have a single connection to another peer. Thus, our best way of fulfilling the request to establish another connection is to ignore port reuse and simply allocate a new port. I think that is better than the connection failing.

I have two suggestions for slightly revising the log and bumping its severity.

transports/tcp/src/lib.rs Outdated Show resolved Hide resolved
transports/tcp/src/lib.rs Outdated Show resolved Hide resolved
umgefahren and others added 2 commits August 3, 2024 11:52
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
@umgefahren
Copy link
Contributor Author

I think this is a fine solution. It is known that one of the disadvantages of enabling port reuse is that you can only have a single connection to another peer. Thus, our best way of fulfilling the request to establish another connection is to ignore port reuse and simply allocate a new port. I think that is better than the connection failing.

I have two suggestions for slightly revising the log and bumping its severity.

I'm glad you are fine with the solution and I implemented your suggestions. I'm ready to merge.

Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

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

LGTM

@thomaseizinger
Copy link
Contributor

Great to see this being so close to merging. Thanks for pushing this over the finish line @umgefahren.

@umgefahren
Copy link
Contributor Author

Is there something left for me to do for merging?

@thomaseizinger
Copy link
Contributor

Is there something left for me to do for merging?

Not at this stage. I'll leave it to @jxs to coordinate when it is good to go in!

Copy link
Member

@jxs jxs left a comment

Choose a reason for hiding this comment

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

LGTM Thanks Hannes for your hard work, and Thomas for the review! ❤️
I will try to release 0.54 on Monday

@jxs jxs added the send-it label Aug 3, 2024
@mergify mergify bot merged commit 079b2d6 into libp2p:master Aug 3, 2024
72 checks passed
@umgefahren
Copy link
Contributor Author

Thanks to everyone involved, I'm sorry it took so much longer than anticipated.

@umgefahren umgefahren deleted the transport-redesign branch August 3, 2024 15:02
@thomaseizinger
Copy link
Contributor

thomaseizinger commented Aug 3, 2024

I will try to release 0.54 on Monday

Do you not want to release AutoNatV2 with this together? There is another PR coming for that I'd assume.

@umgefahren
Copy link
Contributor Author

I will try to release 0.54 on Monday

Do you not want to release AutoNatV2 with this together? There is another PR coming for that I'd assume.

In case you do: I have opened #5526.

mergify bot pushed a commit that referenced this pull request Aug 8, 2024
Closes: #4524

This is the implementation of the evolved AutoNAT protocol, named AutonatV2 as defined in the [spec](https://github.com/libp2p/specs/blob/03718ef0f2dea4a756a85ba716ee33f97e4a6d6c/autonat/autonat-v2.md).
The stabilization PR for the spec can be found under libp2p/specs#538.

The work on the Rust implementation can be found in the PR to my fork: umgefahren#1.

The implementation has been smoke-tested with the Go implementation (PR: libp2p/go-libp2p#2469).

The new protocol addresses shortcomings of the original AutoNAT protocol:

- Since the server now always dials back over a newly allocated port, this made #4568 necessary; the client can be sure of the reachability state for other peers, even if the connection to the server was made through a hole punch.
- The server can now test addresses different from the observed address (i.e., the connection to the server was made through a `p2p-circuit`). To mitigate against DDoS attacks, the client has to send more data to the server than the dial-back costs.

Pull-Request: #5526.
TimTinkers pushed a commit to unattended-backpack/rust-libp2p that referenced this pull request Sep 14, 2024
Resolves: libp2p#4226.
Resolves: libp2p#3953.
Resolves: libp2p#3889.

Pull-Request: libp2p#4568.
TimTinkers pushed a commit to unattended-backpack/rust-libp2p that referenced this pull request Sep 14, 2024
Closes: libp2p#4524

This is the implementation of the evolved AutoNAT protocol, named AutonatV2 as defined in the [spec](https://github.com/libp2p/specs/blob/03718ef0f2dea4a756a85ba716ee33f97e4a6d6c/autonat/autonat-v2.md).
The stabilization PR for the spec can be found under libp2p/specs#538.

The work on the Rust implementation can be found in the PR to my fork: umgefahren#1.

The implementation has been smoke-tested with the Go implementation (PR: libp2p/go-libp2p#2469).

The new protocol addresses shortcomings of the original AutoNAT protocol:

- Since the server now always dials back over a newly allocated port, this made libp2p#4568 necessary; the client can be sure of the reachability state for other peers, even if the connection to the server was made through a hole punch.
- The server can now test addresses different from the observed address (i.e., the connection to the server was made through a `p2p-circuit`). To mitigate against DDoS attacks, the client has to send more data to the server than the dial-back costs.

Pull-Request: libp2p#5526.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
7 participants