[NC-1273] Consider peer count insufficient until minimum peers for fast sync are connected #629
Conversation
… full sync once that completes. Currently the FastSyncDownloader immediately fails with FAST_SYNC_UNSUPPORTED.
…n of fast sync actions.
…ad of having to check the return value is success constantly.
… it can return a single header, handle retrying and provide a place to do additional validation.
…ock) agree on the block.
… we have enough to start fast sync.
| private List<Capability> supportedCapabilities; | ||
| private final Blockchain blockchain; | ||
|
|
||
| EthProtocolManager( | ||
| final Blockchain blockchain, | ||
| final WorldStateArchive worldStateArchive, | ||
| final int networkId, | ||
| final boolean fastSyncEnabled, | ||
| final SynchronizerConfiguration syncConfig, |
There was a problem hiding this comment.
Originally, I intended EthProtocolManager to be something like a generic service provider - a base layer for handling communication over the network related to the eth subprotocol without holding any process-specific code. So, I tried to keep the sync package dependent on the management layer without the management layer depending on sync-specific code. Not a huge deal, but I try to keep an eye on circular dependencies between packages.
One alternative idea would be to expose something like a PeerRefreshRequests object on EthContext. And the manager could then check and clear that when hasSufficientPeers() is invoked.
There was a problem hiding this comment.
You're right, looking at it whether we have enough peers or not is actually a property of Synchronizer not EthProtocolManager so I've moved it there which simplifies a bunch of stuff.
…n optional error return. Remove unused FastSyncState.
… it can be reused.
…not rather than ProtocolManager.
PR description
When fast sync is enabled, consider the peer count insufficient until we have enough to start fast sync.
PeerDiscoveryControllerwill then refresh the peer table more often to find extra peers more quickly.