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(swarm)!: remove handler from NetworkBehaviourAction::Dial #3328

Merged
merged 63 commits into from
Feb 14, 2023

Conversation

thomaseizinger
Copy link
Contributor

@thomaseizinger thomaseizinger commented Jan 16, 2023

Description

We create the ConnectionId for the new connection as part of DialOpts. This allows NetworkBehaviours to accurately track state regarding their own dial attempts.

This patch is the main enabler of #3254. Removing the handler field will allow us to deprecate the NetworkBehaviour::new_handler function in favor of four new ones that give more control over the connection lifecycle.

Notes

Please review this design critically. I believe it has value on its own but at the end of the day, we only do this for #3254.

Links to any relevant issues

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

swarm/src/behaviour.rs Outdated Show resolved Hide resolved
@thomaseizinger
Copy link
Contributor Author

Converting to draft until #3327 is merged to prevent accidental merges.

Instead of carrying around an enum and parsing its contents later,
directly set the correct values as we construct the final `DialOpts`.
We no longer add connections for banned peers to the pool so we don't
have to filter them later.
Now that we no longer add connections to banned peers, we need to:

- Reduce the number of expected connections by 1 (i.e. delete line 1954)
- Act in `Stage::BannedDial` earlier (i.e. remove the `if`)
@mergify
Copy link
Contributor

mergify bot commented Jan 27, 2023

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

@thomaseizinger
Copy link
Contributor Author

Friendly ping @elenaf9 @jxs @mxinden. This is ready for review.

@mergify
Copy link
Contributor

mergify bot commented Feb 1, 2023

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

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.

Overall looks good to me Thomas! I am not very familiar with dctur and relayyet so Max and Elena should also chime in.

swarm/src/lib.rs Show resolved Hide resolved
Ok(())
}

pub fn spawn_connection(
Copy link
Member

Choose a reason for hiding this comment

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

yeah I think this fits here better, and being handled by the Swarm on Swarm::handle_pool_event after receiving ConnectionEstablished rather than on the Pool before returning it 🚀

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah it turned out surprisingly clean and fixes up some weird state tracking where we had to "filter" connection IDs that are banned. Now we just don't spawn the connection in the first place :)

protocols/dcutr/src/behaviour_impl.rs Show resolved Hide resolved
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.

Ready to go from my end.

core/src/muxing/boxed.rs Show resolved Hide resolved
swarm/src/lib.rs Show resolved Hide resolved
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.

This still needs further investigation:

swarm/src/lib.rs Outdated
concurrent_dial_errors,
established_in,
} => {
if self.banned_peers.contains(&peer_id) {
// Mark the connection for the banned peer as banned, thus withholding any
// future events from the connection to the behaviour.
self.banned_peer_connections.insert(id);
self.pool.disconnect(peer_id);
Copy link
Member

Choose a reason for hiding this comment

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

Given that we drop connection here, is the call to pool.disconnect still needed? There should be no connection to the peer in the pool. The previous Swarm::ban_peer_id should have already called pool.disconnect.

Also, if I am not mistaken, we would previously gracefully close connections to banned peers via the pool.disconnect call. Given that connection is now just dropped, this is no longer the case, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Given that we drop connection here, is the call to pool.disconnect still needed? There should be no connection to the peer in the pool. The previous Swarm::ban_peer_id should have already called pool.disconnect.

Originally I thought that we might have other connections to this peer but I guess that isn't actually possible because we would have disconnected those at the time of banning the peer.

Also, if I am not mistaken, we would previously gracefully close connections to banned peers via the pool.disconnect call. Given that connection is now just dropped, this is no longer the case, right?

True. I didn't bother much because this code will go away anyway once we implement it via the new NetworkBehaviour callbacks but yeah, it is a change in behaviour so we should probably keep this behaviour.

This made me think though, we should probably gracefully close connections in #3254 that have been rejected by a NetworkBehaviour.

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've pushed some more commits, let me know what you think!

Copy link
Member

Choose a reason for hiding this comment

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

Changes look good to me, thanks!

@mxinden
Copy link
Member

mxinden commented Feb 13, 2023

@thomaseizinger ready to merge from my end. Please trigger mergify once you are ready. Looking forward for this to land.

@mergify mergify bot merged commit caed1fe into master Feb 14, 2023
@mergify mergify bot deleted the 2824-no-handler-in-dial branch February 14, 2023 01:09
umgefahren pushed a commit to umgefahren/rust-libp2p that referenced this pull request Mar 8, 2024
libp2p#3328)

We create the `ConnectionId` for the new connection as part of `DialOpts`. This allows `NetworkBehaviour`s to accurately track state regarding their own dial attempts.

This patch is the main enabler of libp2p#3254. Removing the `handler` field will allow us to deprecate the `NetworkBehaviour::new_handler` function in favor of four new ones that give more control over the connection lifecycle.
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.

3 participants