You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Has a run method to start listening on an address and poll the Swarm for events
Interprets certain events that need to go between the constituent behaviour protocols, e.g. when Membership raises an event about an agent serving a new subnet it didn't know about before, then the service would prompt Discovery to look up its peer ID to ensure it has the address if needed.
Has a command enum to accept tasks to do over a channel from the rest of the program. Command would arrive with response channels - these would be things like resolving up CIDs.
Has a command queue which it also polls (along with the Swarm) to look for internal requests.
Wraps the command queue into an async interface where the response channels are created and completed, for convenience. Instances of this interface can be shared out to the application and they can be cloned as well, and once the service is running, this is the only way to talk to it.
Configuration which aggregates the configs of all constituent behaviours.
When running the resolve command, it should ask Membership for the list of peer IDs serving data from a topic, ask Discovery for the list of connected/known addresses, then decide how many to pass to Resolve and in which order - connected first, known addresses last; but maybe just a few at a time to not span the network, e.g. if we know 100 agents serving data in a subnet, we can send bitswap requests to 10 of them, and if it fails, then another 10, etc. Note that the Bitswap library is clever enough to only send want-have first to all-but-one, and then want-block to one at a time, but we might want to keep even the want-have within a limit. At some point we might even ask the parent subnet members for the data - a fully Bitswap implementation would keep the wants and complete them later, but not libp2p-bitswap.
The text was updated successfully, but these errors were encountered:
Part of #475
Create an IPLD Resolver Service that:
Swarm
with an IPLD Resolver Behaviour wrapping Add sorting imports #34 IPLD Resolver: Membership #467 and IPLD Resolver: Content #466run
method to start listening on an address and poll theSwarm
for eventsMembership
raises an event about an agent serving a new subnet it didn't know about before, then the service would promptDiscovery
to look up its peer ID to ensure it has the address if needed.Swarm
) to look for internal requests.Membership
for the list of peer IDs serving data from a topic, askDiscovery
for the list of connected/known addresses, then decide how many to pass toResolve
and in which order - connected first, known addresses last; but maybe just a few at a time to not span the network, e.g. if we know 100 agents serving data in a subnet, we can send bitswap requests to 10 of them, and if it fails, then another 10, etc. Note that theBitswap
library is clever enough to only sendwant-have
first to all-but-one, and thenwant-block
to one at a time, but we might want to keep even thewant-have
within a limit. At some point we might even ask the parent subnet members for the data - a fully Bitswap implementation would keep the wants and complete them later, but notlibp2p-bitswap
.The text was updated successfully, but these errors were encountered: