Basic peer manager based on libp2p peer_store and connection_limits
#126
Conversation
|
I propose we review and merge this, even though upstream has not merged the peer store yet. We need something to test. Very open for other suggestions though |
| .filter_map(|(enr, _)| manager.discovered_peer(enr)) | ||
| .collect::<Vec<_>>(); | ||
| for dial in to_dial { | ||
| let _ = self.swarm.dial(dial); |
There was a problem hiding this comment.
Lighthouse does something like that https://github.com/sigp/lighthouse/blob/unstable/beacon_node/lighthouse_network/src/peer_manager/network_behaviour.rs#L113
There was a problem hiding this comment.
The event only allows us to dial a single peer.
There was a problem hiding this comment.
Yes, I think it creates an event for each peer. But honestly, I don't know the reason. Maybe decoupling?
There was a problem hiding this comment.
@jxs: Is there a relevant difference between these approaches to dial?
There was a problem hiding this comment.
We could also encapsulate this code inside the Peer Manager. Similar to https://github.com/sigp/lighthouse/blob/stable/beacon_node/lighthouse_network/src/service/mod.rs#L1845
anchor/network/src/network.rs
Outdated
| /// A fraction of `PeerManager::target_peers` that we allow to connect to us in excess of | ||
| /// `PeerManager::target_peers`. For clarity, if `PeerManager::target_peers` is 50 and | ||
| /// PEER_EXCESS_FACTOR = 0.1 we allow 10% more nodes, i.e 55. | ||
| const PEER_EXCESS_FACTOR: f32 = 0.1; | ||
| /// A fraction of `PeerManager::target_peers` that we want to be outbound-only connections. | ||
| const TARGET_OUTBOUND_ONLY_FACTOR: f32 = 0.3; | ||
| /// A fraction of `PeerManager::target_peers` that if we get below, we start a discovery query to | ||
| /// reach our target. MIN_OUTBOUND_ONLY_FACTOR must be < TARGET_OUTBOUND_ONLY_FACTOR. | ||
| const MIN_OUTBOUND_ONLY_FACTOR: f32 = 0.2; | ||
| /// The fraction of extra peers beyond the PEER_EXCESS_FACTOR that we allow us to dial for when | ||
| /// requiring subnet peers. More specifically, if our target peer limit is 50, and our excess peer | ||
| /// limit is 55, and we are at 55 peers, the following parameter provisions a few more slots of | ||
| /// dialing priority peers we need for validator duties. | ||
| const PRIORITY_PEER_EXCESS: f32 = 0.2; |
There was a problem hiding this comment.
Would this be better encapsulated inside the Peer Manager?
# Conflicts: # Cargo.lock # anchor/network/src/network.rs
Draft of basic peer manager using
connection_limitsand a preliminary version ofpeer_store.This is just a draft, as the exact design of
peer_storeis still TBD and a few things are missing.