280e4fe23d
In previous network updates we have made our libp2p connections more lean by limiting the maximum number of connections a lighthouse node will accept before libp2p rejects new connections. However, we still maintain the logic that at maximum connections, we try to dial extra peers if they are needed by a validator client to publish messages on a specific subnet. The dials typically result in failures due the libp2p connection limits. This PR adds an extra factor, `PRIORITY_PEER_EXCESS` which sets aside a new allocation of peers we are able to dial in case we need these peers for the VC client. This allocation sits along side the excess peer (which allows extra incoming peers on top of our target peer limit). The drawback here, is that libp2p now allows extra peers to connect to us (beyond the standard peer limit) which the peer manager should subsequently reject. |
||
---|---|---|
.. | ||
beacon_chain | ||
client | ||
eth1 | ||
eth2_libp2p | ||
genesis | ||
http_api | ||
http_metrics | ||
network | ||
operation_pool | ||
src | ||
store | ||
tests | ||
timer | ||
websocket_server | ||
Cargo.toml |