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
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
The text was updated successfully, but these errors were encountered:
Copying from #1420
My suggestion to do this is to:
The text was updated successfully, but these errors were encountered: