Initial content discovery #260
Conversation
Signed-off-by: ljedrz <ljedrz@gmail.com>
…ry one Signed-off-by: ljedrz <ljedrz@gmail.com>
Signed-off-by: ljedrz <ljedrz@gmail.com>
Signed-off-by: ljedrz <ljedrz@gmail.com>
Signed-off-by: ljedrz <ljedrz@gmail.com>
Signed-off-by: ljedrz <ljedrz@gmail.com>
ljedrz
force-pushed
the
actual_content_discovery
branch
from
cd18ba6
to
a4be9cd
Compare
| // FIXME: it would probably be best if this could return a SubscriptionFuture, so | ||
| // that the put_block operation truly finishes only when the block is already being | ||
| // provided; it is, however, pretty tricky in terms of internal communication between | ||
| // Ipfs and IpfsFuture objects - it would currently require some extra back-and-forth | ||
| pub fn provide_block(&mut self, cid: Cid) { |
There was a problem hiding this comment.
I am not 100% with you on this FIXME but no need to change it now. To elaborate:
"Not 100% with you" as in is that the saving blocks should be as decoupled as possible and providing should only happen for some subset of blocks: possibly only the pinned roots, or pinned roots and their subroots or anything more complex would need to be provided for. Where "subroots" would be the roots of the files in a pinned larger directory structure for the invidiual files.
Decoupling providing and put_block because providing can be quite expensive, and we might not want to do them concurrently at all. Additionally not sure if it's a good idea to plan to use start_providing unless we can come up with a really nice backend for the kademlia store. Otherwise we could just use the simpler "push" API and handle the timing ourselves.
|
Flaky #134 with the readme-doctest again. |
|
Build succeeded: |
An initial implementation of content discovery via DHT, where a
get_blockrequest that doesn't succeed locally results in a call toKademlia::get_providers. It also fixes (AKA fixes in most cases) the previously prototyped display of Kademlia content keys, in this caseCids.cc #10