-
Notifications
You must be signed in to change notification settings - Fork 773
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
upgrade to Libp2p 0.52 #4087
Conversation
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 |
There was a problem hiding this 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/peer_manager/network_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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
This is now released: https://crates.io/crates/libp2p-identity/0.1.1
|
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 |
fn on_connection_handler_event( | ||
&mut self, | ||
_peer_id: PeerId, | ||
_connection_id: ConnectionId, | ||
_event: libp2p::swarm::THandlerOutEvent<Self>, | ||
) { | ||
todo!() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend:
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
This reverts commit 58bd2f7.
There was a problem hiding this 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. |
There was a problem hiding this comment.
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!() |
There was a problem hiding this comment.
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... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, we see NetworkBehaviour
s as plugins and mDNS
for example is also a NetworkBehaviour
so implementing discovery as one is totally fine.
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!() | ||
} |
There was a problem hiding this comment.
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? |
There was a problem hiding this comment.
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.
// // What happens if another behaviour prevents our dial attempt? do we get any | ||
// // notification to get the peer out of dialing state? dial failed? |
There was a problem hiding this comment.
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
.
#[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!() | ||
} |
There was a problem hiding this comment.
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.
closed in favor of #4431 |
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.