Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPLD Resolver: Service #465

Closed
aakoshh opened this issue Feb 24, 2023 · 0 comments · Fixed by consensus-shipyard/ipc-libs#55
Closed

IPLD Resolver: Service #465

aakoshh opened this issue Feb 24, 2023 · 0 comments · Fixed by consensus-shipyard/ipc-libs#55
Labels

Comments

@aakoshh
Copy link
Contributor

aakoshh commented Feb 24, 2023

Part of #475

Create an IPLD Resolver Service that:

  • Creates a Swarm with an IPLD Resolver Behaviour wrapping Add sorting imports #34 IPLD Resolver: Membership #467 and IPLD Resolver: Content #466
  • 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants