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

iroh: provider list for the downloader #1470

Closed
divagant-martian opened this issue Sep 11, 2023 · 1 comment
Closed

iroh: provider list for the downloader #1470

divagant-martian opened this issue Sep 11, 2023 · 1 comment

Comments

@divagant-martian
Copy link
Contributor

divagant-martian commented Sep 11, 2023

Copying from #1420

Prioritizing candidates per role: Provider and Candidate

A nice extension, as discussed at some point, is to differentiate candidates we know have the data, from those that might have the data. This has added benefit that when a peer is available to perform another download under the concurrency limits, a hash we know they have could be downloaded right away instead of waiting for the delay. At this point making this doesn't make sense because we will likely attempt a download before the peer has retrieved the data themselves. To implement this, we would need to add the notifications of fully downloaded hashes as available into gossip first.

My suggestion to do this is to:

  • Add a new message kind to gossip that informs connected peers that some data is available. This would only be done for peers in the tree
  • Said notification would be triggered when the data has just been downloaded. An ideal world would make this notification come from the DB itself as the one and only source of truth since downloads can occur via other mechanisms different to the downloader. A potentially easier approach would be to produce this notification from the downloader itself since it clearly knows when a download has been successfully concluded.
  • Upon receiving the gossip notification of a new provider available this can be used to prioritize them to retrieve the data as mentioned in the original future work
  • A nice property of this is reusing existing known connections that are already bounded by the gossip parameters and generate an effective propagation of actually available data
@Frando Frando mentioned this issue Sep 12, 2023
3 tasks
@divagant-martian
Copy link
Contributor Author

closed by #1420

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

1 participant