Peers should cache provider information to spread it around the network.
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- distributed-systems, networking
Research direction
Start by tracing the FindProviders flow and the point where peers discover providers for content. Compare caching records after discovery with recording the source peer in the end service when a block is received, then define how provider expiration is preserved. Done means popular provider records are distributed without living forever and downloads can resume after restart.
Written by the indexing model from the issue text.
Description
After finding new providers for a piece of content, peers should store those providers locally. This:
- Speeds up future (initial) find provider queries for the same thing.
- Distributes frequently requested provider records around the network.
However, I'm a bit concerned about provider record expiration given a FindProviders call won't actually return when the provider record was initially submitted. This means that popular provider records would live forever.
One solution is to do this (record that some peer provides some content/service) inside the end service itself. For example, when we get a block from a peer, we could locally record a provider record for the peer from which we got the block. This would, incidentally, help us resume downloading a file if we restart.
- Dominant language
- No language data
- Stars
- 38
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from libp2p/notes
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
DHT
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
manticoresoftware/manticoresearch#4980 ·
Maintainers usually reply within 1 day
-
help wanted priority:low type:bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
crazy-goat/rabbit-stream#653 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 2 days