Track sync state for a core identified by discoveryId. Can start tracking
state before the core instance exists locally, via the "preHave" messages
received over the project creator core.
Because deriving the state is expensive (it iterates through the bitfields of
all peers), this is designed to be pull-based: the onUpdate event signals
that the state is updated, but does not pass the state. The consumer can
"pull" the state when it wants it via coreSyncState.getState().
Each peer (including the local peer) has a state of:
have - number of blocks the peer has locally
want - number of blocks this peer wants. For local state, this is the
number of unique blocks we want from anyone else. For remote peers, it is
the number of blocks this peer wants from us.
wanted - number of blocks this peer has that's wanted by others. For
local state, this is the number of unique blocks any of our peers want.
For remote peers, it is the number of blocks we want from them.
Attach a core. The sync state can be initialized without a core instance,
because we could receive peer want and have states via extension messages
before we have the core key that allows us to create a core instance.
Add a pre-emptive "have" bitfield for a peer. This is used when we receive
a peer "have" via extension message - it allows us to have a state for the
peer before the peer actually starts syncing this core
Parameters
peerId: string
start: number
bitfield: Uint32Array
Returns void
setPeerWants
setPeerWants(peerId, ranges): void
Add a ranges of wanted blocks for a peer. By default a peer wants all
blocks in a core - calling this will change the peer to only want the
blocks/ranges that are added here
Track sync state for a core identified by
discoveryId. Can start tracking state before the core instance exists locally, via the "preHave" messages received over the project creator core.Because deriving the state is expensive (it iterates through the bitfields of all peers), this is designed to be pull-based: the onUpdate event signals that the state is updated, but does not pass the state. The consumer can "pull" the state when it wants it via
coreSyncState.getState().Each peer (including the local peer) has a state of:
have- number of blocks the peer has locallywant- number of blocks this peer wants. For local state, this is the number of unique blocks we want from anyone else. For remote peers, it is the number of blocks this peer wants from us.wanted- number of blocks this peer has that's wanted by others. For local state, this is the number of unique blocks any of our peers want. For remote peers, it is the number of blocks we want from them.