0dc95a1d37
## Issue Addressed https://github.com/sigp/lighthouse/issues/4543 ## Proposed Changes - Removes `NotBanned` from `BanResult`, implements `Display` and `std::error::Error` for `BanResult` and changes `ban_result` return type to `Option<BanResult>` which helps returning `BanResult` on `handle_established_inbound_connection` - moves the check from for banned peers from `on_connection_established` to `handle_established_inbound_connection` to start addressing #4543. - Removes `allow_block_list` as it's now redundant? Not sure about this one but if `PeerManager` keeps track of the banned peers, no need to send a `Swarm` event for `alow_block_list` to also keep that list right? ## Questions - #4543 refers: > More specifically, implement the connection limit behaviour inside the peer manager. @AgeManning do you mean copying `libp2p::connection_limits::Behaviour`'s code into `PeerManager`/ having it as an inner `NetworkBehaviour` of `PeerManager`/other? If it's the first two, I think it probably makes more sense to have it as it is as it's less code to maintain. > Also implement the banning of peers inside the behaviour, rather than passing messages back up to the swarm. I tried to achieve this, but we still need to pass the `PeerManagerEvent::Banned` swarm event as `DiscV5` handles it's node and ip management internally and I did not find a method to query if a peer is banned. Is there anything else we can do from here? |
||
---|---|---|
.. | ||
beacon_chain | ||
beacon_processor | ||
builder_client | ||
client | ||
eth1 | ||
execution_layer | ||
genesis | ||
http_api | ||
http_metrics | ||
lighthouse_network | ||
network | ||
operation_pool | ||
src | ||
store | ||
tests | ||
timer | ||
Cargo.toml |