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

upgrade to Libp2p 0.52 #4087

Closed
wants to merge 71 commits into from

Conversation

divagant-martian
Copy link
Collaborator

Issue Addressed

Which issue # does this PR address?

Proposed Changes

Please list or describe the changes introduced by this PR.

Additional Info

Please provide any additional information. For example, future considerations
or information useful for reviewers.

@divagant-martian
Copy link
Collaborator Author

divagant-martian commented Mar 16, 2023

put on halt until libp2p/rust-libp2p#3623 is somewhat addressed. Right now the suggested solution is to change the way we encode and store on disk keys, which makes no sense to me.

Possible solution addressing this: libp2p/rust-libp2p#3626 waiting for a release that contains this

Copy link

@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.

Some thoughts, take as you will :)

beacon_node/lighthouse_network/src/config.rs Outdated Show resolved Hide resolved
beacon_node/lighthouse_network/src/service/behaviour.rs Outdated Show resolved Hide resolved
@@ -352,7 +352,7 @@ impl<AppReqId: ReqId, TSpec: EthSpec> Network<AppReqId, TSpec> {
Executor(executor),
)
.notify_handler_buffer_size(std::num::NonZeroUsize::new(7).expect("Not zero"))
.connection_event_buffer_size(64)
.per_connection_event_buffer_size(4)

Choose a reason for hiding this comment

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

This is less than the default, FYI.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we allow one connection per peer and have a target peer count of 80. So I think this is still more than what the previous value allowed. I'm changing it to 4 (I'm aware the default is 7) for now until we can have an internal discussion about this

@thomaseizinger
Copy link

thomaseizinger commented Mar 20, 2023

Possible solution addressing this: libp2p/rust-libp2p#3626 waiting for a release that contains this

This is now released: https://crates.io/crates/libp2p-identity/0.1.1

cargo update -p libp2p-identity should do the trick.

@divagant-martian
Copy link
Collaborator Author

divagant-martian commented Mar 20, 2023

Possible solution addressing this: libp2p/rust-libp2p#3626 waiting for a release that contains this

This is now released: https://crates.io/crates/libp2p-identity/0.1.1

cargo update -p libp2p-identity should do the trick.

Thanks @thomaseizinger this helped in some places. On another note, I added a new issue since I'm encountering a lot of unnecessary clones while trying to deal with references in libp2p/rust-libp2p#3649

Comment on lines 60 to 67
fn on_connection_handler_event(
&mut self,
_peer_id: PeerId,
_connection_id: ConnectionId,
_event: libp2p::swarm::THandlerOutEvent<Self>,
) {
todo!()
}

Choose a reason for hiding this comment

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

I would recommend:

Suggested change
fn on_connection_handler_event(
&mut self,
_peer_id: PeerId,
_connection_id: ConnectionId,
_event: libp2p::swarm::THandlerOutEvent<Self>,
) {
todo!()
}
fn on_connection_handler_event(
&mut self,
_peer_id: PeerId,
_connection_id: ConnectionId,
event: libp2p::swarm::THandlerOutEvent<Self>,
) {
void::unreachable(event)
}

@@ -62,20 +60,17 @@ pub fn build_transport(
// yamux config
let mut yamux_config = libp2p::yamux::YamuxConfig::default();
yamux_config.set_window_update_mode(libp2p::yamux::WindowUpdateMode::on_read());
let multiplexer = core::upgrade::SelectUpgrade::new(yamux_config, mplex_config);
let (transport, bandwidth) = transport
.upgrade(core::upgrade::Version::V1)

Choose a reason for hiding this comment

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

In general (not just due to this upgrade): Consider using Version::V1Lazy for 0-RTT protocol negotiation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

thanks, this one is new to me, I'll be reading about this

@divagant-martian divagant-martian changed the title upgrade to Libp2p 0.51.3 upgrade to Libp2p 0.52 Jun 24, 2023
Copy link

@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.

Made some comments on things I noticed, hope they are helpful :)

}
Keypair::Ecdsa(_) => Err("Ecdsa keypairs not supported"),
fn from_libp2p(key: Keypair) -> Result<CombinedKey, &'static str> {
// TODO: more clones that should not be happening.

Choose a reason for hiding this comment

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

As you probably noticed, libp2p/rust-libp2p#3649 is now resolved. Let me know if you'd like a patch release for that.

_local_addr: &Multiaddr,
_remote_addr: &Multiaddr,
) -> Result<(), libp2p::swarm::ConnectionDenied> {
todo!()

Choose a reason for hiding this comment

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

There is no need to override this function if you are not doing any connection management of pending connections.

@@ -925,31 +926,94 @@ impl<TSpec: EthSpec> Discovery<TSpec> {
impl<TSpec: EthSpec> NetworkBehaviour for Discovery<TSpec> {
// Discovery is not a real NetworkBehaviour...

Choose a reason for hiding this comment

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

FWIW, we see NetworkBehaviours as plugins and mDNS for example is also a NetworkBehaviour so implementing discovery as one is totally fine.

Comment on lines +960 to +979
fn handle_established_inbound_connection(
&mut self,
_connection_id: ConnectionId,
peer: PeerId,
local_addr: &Multiaddr,
remote_addr: &Multiaddr,
) -> Result<libp2p::swarm::THandler<Self>, libp2p::swarm::ConnectionDenied> {
todo!()
}

#[allow(unused)]
fn handle_established_outbound_connection(
&mut self,
_connection_id: ConnectionId,
peer: PeerId,
addr: &Multiaddr,
role_override: libp2p::core::Endpoint,
) -> Result<libp2p::swarm::THandler<Self>, libp2p::swarm::ConnectionDenied> {
todo!()
}

Choose a reason for hiding this comment

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

These will need to return a handler otherwise you'll panic on the first established connection.

_local_addr: &libp2p::Multiaddr,
_remote_addr: &libp2p::Multiaddr,
) -> Result<(), libp2p::swarm::ConnectionDenied> {
// TODO... is it guaranteed that the ip the peer is connecting from is in the _remote_addr?

Choose a reason for hiding this comment

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

It is taken from the socket but we can't do anything if the remote spoofs their IP.

Comment on lines +92 to +93
// // What happens if another behaviour prevents our dial attempt? do we get any
// // notification to get the peer out of dialing state? dial failed?

Choose a reason for hiding this comment

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

Yes, you will get a FromSwarm::DialFailure with a DialError::Denied.

Comment on lines +346 to +355
#[allow(unused)]
fn handle_pending_outbound_connection(
&mut self,
_connection_id: ConnectionId,
maybe_peer: Option<PeerId>,
_addresses: &[libp2p::Multiaddr],
_effective_role: libp2p::core::Endpoint,
) -> Result<Vec<libp2p::Multiaddr>, libp2p::swarm::ConnectionDenied> {
todo!()
}

Choose a reason for hiding this comment

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

These have a sensible default impl which I'd use instead of overwriting it.

@divagant-martian
Copy link
Collaborator Author

closed in favor of #4431

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants