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(relay): move stream-handling away from {In,Out}boundUpgrade #4275

Merged
merged 123 commits into from
Sep 20, 2023

Conversation

dgarus
Copy link
Contributor

@dgarus dgarus commented Jul 31, 2023

Description

Fixes: #4075.

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

@dgarus dgarus marked this pull request as draft July 31, 2023 12:10
@dgarus dgarus changed the title Refactoring of stop protocol feat: relay: refactor stream handling away from {In,Out}boundUpgrade Jul 31, 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.

The relay protocol is quite complex but you seem to be making great progress which is impressive :)

protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
@dgarus dgarus marked this pull request as ready for review August 2, 2023 13:21
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.

Amazing work so far!

I've done a review of the server's handler and the involved protocol. Let me know if you have any questions! Most of the style-suggestions likely apply to the other handler and protocol as well :)

protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
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 progress! I've made some more comments to steer you into the right direction.

Thanks a lot for your help with this PR, it is much appreciated!

protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/behaviour/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/priv_client/handler.rs Show resolved Hide resolved
protocols/relay/src/priv_client/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/priv_client/handler.rs Outdated Show resolved Hide resolved
protocols/relay/src/priv_client/handler.rs Outdated Show resolved Hide resolved
@thomaseizinger
Copy link
Contributor

Do you have a slack or telegram chat?

Yes! We have a public slack channel. You can join here: https://join.slack.com/share/enQtNTg5OTA0MzIwNjk0NC1iZGQ0YzIxYzdiMTUxNjZhNDJiZjJiMWQyNDM1N2U1MWY3YmY4NWI2ZjgyZWY0NzBmMTBiNTNkMzQ4OWFhNzJk

The protocol module outbound_hop looks like artificial to me. So if two functions are moved to the handler module, then we could use ConnectionHandlerEvent as the result and don't have circular dependencies.

I think it exists mostly for consistency across the 2 different protocols and inbound / outbound variants. I'd suggest to keep it :)

@dgarus
Copy link
Contributor Author

dgarus commented Sep 13, 2023

Should this testing be my creative or already exists an instruction?

The relay-server example has some basic instructions: https://github.com/libp2p/rust-libp2p/tree/master/examples/relay-server

You can then modify for example the ping example to include a relay client and use the relay's listen address to listen on it. We should be able to have successful pings across the relay.

Hi, @thomaseizinger !
I'm trying to test the relay, but it's not obvious to me how to do.
So I'm in the process.

@thomaseizinger
Copy link
Contributor

Should this testing be my creative or already exists an instruction?

The relay-server example has some basic instructions: master/examples/relay-server
You can then modify for example the ping example to include a relay client and use the relay's listen address to listen on it. We should be able to have successful pings across the relay.

Hi, @thomaseizinger ! I'm trying to test the relay, but it's not obvious to me how to do. So I'm in the process.

Yesterday, I managed to build a first version of an interop test for hole-punching which also uses the relay. See https://github.com/libp2p/rust-libp2p/tree/feat/hole-punching-tests/hole-punching-tests.

I've plugged this branch into the tests and they still work! I'd consider that enough confidence that we didn't break anything :)

@dgarus
Copy link
Contributor Author

dgarus commented Sep 13, 2023

Should this testing be my creative or already exists an instruction?

The relay-server example has some basic instructions: master/examples/relay-server
You can then modify for example the ping example to include a relay client and use the relay's listen address to listen on it. We should be able to have successful pings across the relay.

Hi, @thomaseizinger ! I'm trying to test the relay, but it's not obvious to me how to do. So I'm in the process.

Yesterday, I managed to build a first version of an interop test for hole-punching which also uses the relay. See https://github.com/libp2p/rust-libp2p/tree/feat/hole-punching-tests/hole-punching-tests.

I've plugged this branch into the tests and they still work! I'd consider that enough confidence that we didn't break anything :)

It's good news. But, anyway, I want to try relay manually

@thomaseizinger
Copy link
Contributor

Should this testing be my creative or already exists an instruction?

The relay-server example has some basic instructions: master/examples/relay-server
You can then modify for example the ping example to include a relay client and use the relay's listen address to listen on it. We should be able to have successful pings across the relay.

Hi, @thomaseizinger ! I'm trying to test the relay, but it's not obvious to me how to do. So I'm in the process.

Yesterday, I managed to build a first version of an interop test for hole-punching which also uses the relay. See feat/hole-punching-tests/hole-punching-tests.
I've plugged this branch into the tests and they still work! I'd consider that enough confidence that we didn't break anything :)

It's good news. But, anyway, I want to try relay manually

Perhaps have a read through the hole-punching tutorial: https://docs.rs/libp2p/0.52.3/libp2p/tutorials/hole_punching/index.html

@thomaseizinger
Copy link
Contributor

@mxinden Can you give this a final review? I've tested it with my in-progress hole-punching setup and it still works :)

Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

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

Just some small nit-picks. Otherwise this looks good to me. Thank you for the work!

misc/futures-bounded/src/list.rs Outdated Show resolved Hide resolved
misc/futures-bounded/src/list.rs Outdated Show resolved Hide resolved
misc/futures-bounded/src/list.rs Outdated Show resolved Hide resolved
misc/futures-bounded/src/map.rs Outdated Show resolved Hide resolved
dgarus and others added 4 commits September 19, 2023 20:05
Previously, a connection would be shut down immediately as soon as its `ConnectionHandler` reports `KeepAlive::No`. As we have gained experience with libp2p, it turned out that this isn't ideal.

For one, tests often need to keep connections alive longer than the configured protocols require. Plus, some usecases require connections to be kept alive in general.

Both of these needs are currently served by the `keep_alive::Behaviour`. That one does essentially nothing other than statically returning `KeepAlive::Yes` from its `ConnectionHandler`.

It makes much more sense to deprecate `keep_alive::Behaviour` and instead allow users to globally configure an `idle_conncetion_timeout` on the `Swarm`. This timeout comes into effect once a `ConnectionHandler` reports `KeepAlive::No`. To start with, this timeout is 0. Together with libp2p#3844, this will allow us to move towards a much more aggressive closing of idle connections, together with a more ergonomic way of opting out of this behaviour.

Fixes libp2p#4121.

Pull-Request: libp2p#4161.
@dgarus
Copy link
Contributor Author

dgarus commented Sep 20, 2023

@thomaseizinger @mxinden

Thank you so much for the review!

@thomaseizinger
Copy link
Contributor

Everything is addressed, no big blockers were mentioned by @mxinden so if anything else comes up, we can always do it in a follow-up!

Let's go!

@mergify mergify bot merged commit efea490 into libp2p:master Sep 20, 2023
69 checks passed
@dgarus dgarus deleted the 4075-relay branch September 20, 2023 08:24
thomaseizinger pushed a commit that referenced this pull request Sep 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

relay: refactor stream handling away from {In,Out}boundUpgrade
4 participants