Early integration of the DHT with smart-records #727
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a work in progress. It compiles, it passes a few tests, but it is not fully implemented. Expect messy code an lots of comments
Goal
Implement an early integration of the DHT with smart-records as described in libp2p/go-smart-record#33.
What is currently implemented
PutSmartValuethat gets closest peers and puts a smart-record in every peer in the path.GetSmartValueimplementation that performs a DHT lookup, gets the smart record from the closest peers, and locally aggregates the results to generate the final state of the smart-record.What is missing?
GetSmartValueare currently run till the end. No quorum or stop functions are used to terminate the lookup early. We probably want to let users choose how many smart-records to fetch before terminating. This needs to be implemented.GetValue, every request from a remote peer can optionally return a list of closest peers. This information is used to update the routing tables and (IIRC) put values if we find closest/better peers. In the current implementation we are completely skipping this part.sr_test.gois failing, so there is probably a bug or some subtlety I may be missing from the implementation (it fails because the query hits a single peer that doesn't have the record).I am leaving this draft here for future reference and for anyone to build upon, as I don't think I'll have time to finish it in the short-term. Do not hesitate to ping me if you need my support in any way.
//cc @petar