spv: Drop unsynced peers earlier #2299
Conversation
|
Not sure about this. We already do set the required peer height with lp.RequirePeerHeight called early on in the spv syncer's Run method and each time the main chain is extended. This results in an announced height check in lp.ConnectOutbound and will cause that to error before the syncer ever adds the remote peer to the remotes map. (And the height check at the top of startupSync looks completely superfluous.) |
|
Fair point. I'll drop the check after I'll also add a commit that drops peers that have been left behind after processing a batch of headers (to ensure if we overtake a peer, than that peer is disconnected in order to make room for a new, possibly more updated peer). |
matheusd
force-pushed
the
drop-unsynced-peers-earlier
branch
from
a6e434f to
7d54640
Compare
This adds tracking of the last height of any header returned by a remote peer. This will be used in the future to determine whether the peer correctly sent all headers it should have.
The p2p package already ensures peers are dropped if they are behind the wallet's main chain tip height, therefore this check is redundant in the spv syncer.
matheusd
force-pushed
the
drop-unsynced-peers-earlier
branch
2 times, most recently
from
709cc35 to
31b9f47
Compare
This adds a function to force disconnection from peers that have been overtaken by the wallet. During initial sync, we might connect to a peer that is useful during the earlier block ranges but which is overtaken due to the wallet connecting to peers with more up to date blocks. After initial sync completes and the sendheaders message is sent, the remote peers should be announcing new blocks via headers message. If a particular peer don't send any headers after the wallet has received several new headers, it probably means that peer has poor connectivity to the network and should be disconnected in favor of attempting to find a better peer.
matheusd
force-pushed
the
drop-unsynced-peers-earlier
branch
from
31b9f47 to
6f510a5
Compare
This disconnects SPV peers ealier in the peer startup sequence, before they are added to the
remotesmap. This improves the SPV loop by ensuring peers that are too much behind the wallet's tip are not given a chance of being selected for any operations and a new peer connection is attempted.It also adds tracking of the last returned header per peer, which will be useful in future refactorings.