Before starting sync of data, the sync state should accurately show the data that needs to be synced. There were bugs in the code that meant the "data to sync" was not accurate until the user had already started to sync the data. This PR fixes things so that after doing an "initial" sync, the sync state should accurately show how much data there is to be synced before the user starts syncing.
This PR fixes several things, because each fix revealed other bugs:
Updates RemoteBitfield with changes from upstream to fix findLast and a few other things (data was not being added to the Quickbit index when it was inserted from a UInt32Array (as opposed to being set bit-by-bit).
Fix CoreSyncState to correctly calculate wantwantedhave for cores that have not yet been replicated, based on preHave messages. We don't get the core length without replication, so we estimate it from the preHave messages. The length will be incorrect if the connected peer is missing blocks at the end of their core (because we use the last set bit in the bitfield for the length), but this is ok, it just means that missing might be inaccurate before a core is actually replicated.
Fix to ignore remote states for blocked peers - without this, because a blocked peer potentially has data which will not sync, then sync state never considers sync to be complete for a blocked peer.
Fix to test to ignore missing when comparing states of sync with a blocked peer, because different peers connected to a blocked peer can have different impressions of what is missing, based on whether they have tried to sync with them before blocking them.
(Note: I don't really like how this has been fixed by passing around peer sync controllers and making deriveState more complex because it relies on a more complicated state.... but all I can think of for now, so hopefully "good enough").
Before starting sync of data, the sync state should accurately show the data that needs to be synced. There were bugs in the code that meant the "data to sync" was not accurate until the user had already started to sync the data. This PR fixes things so that after doing an "initial" sync, the sync state should accurately show how much data there is to be synced before the user starts syncing.
This PR fixes several things, because each fix revealed other bugs:
RemoteBitfieldwith changes from upstream to fixfindLastand a few other things (data was not being added to the Quickbit index when it was inserted from a UInt32Array (as opposed to being set bit-by-bit).CoreSyncStateto correctly calculatewantwantedhavefor cores that have not yet been replicated, based on preHave messages. We don't get the core length without replication, so we estimate it from the preHave messages. The length will be incorrect if the connected peer is missing blocks at the end of their core (because we use the last set bit in the bitfield for the length), but this is ok, it just means thatmissingmight be inaccurate before a core is actually replicated.missingwhen comparing states of sync with a blocked peer, because different peers connected to a blocked peer can have different impressions of what is missing, based on whether they have tried to sync with them before blocking them.(Note: I don't really like how this has been fixed by passing around peer sync controllers and making
deriveStatemore complex because it relies on a more complicated state.... but all I can think of for now, so hopefully "good enough").