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

Proposal for very early integration of Smart Records and the DHT #33

Open
adlrocha opened this issue Jun 7, 2021 · 0 comments
Open

Comments

@adlrocha
Copy link
Contributor

adlrocha commented Jun 7, 2021

As a matter of process, this work will likely span multiple repos (go-ipfs, go-ipfs-config, dht, go-smart-record, etc). In each repo we should push the reviewed work to a dedicated branch (not master), e.g. "feat/smartdht"

High-level structure of the plan:

  • (1) In repo go-libp2p-kad-dht, implement PutSmartValue function which is analogous
    to PutValue (https://github.com/libp2p/go-libp2p-kad-dht/blob/master/routing.go#L31).
    PutSmartValue would be identical to PutValue, except when the value is being put
    (https://github.com/libp2p/go-libp2p-kad-dht/blob/master/routing.go#L85), the
    code will entail connecting to the Smart Record (SR) service running on the peer's host
    and invoking an Update operation. Note that connecting to the SR service should not
    cost roundtrips, because our local host should already be connected there.

  • (2) In repo go-libp2p-kad-dht, implement GetSmartValue function which is analogous
    to GetValue (https://github.com/libp2p/go-libp2p-kad-dht/blob/master/routing.go#L103),
    but with a few implementation novelties/differences:

    • At the beginning of a GetSmartValue invocation, create an empty local Smart Record (SR) instance.
    • Start the lookup process.
    • Each time a new peer is discovered by the lookup process:
      • Connect to the SR service at the peer and perform a Get operation for the desired key
      • Take the value returned by the peer and insert it (using an SR.Update operation) into the local SR
    • When the lookup process completes,
      • Invoke a Get operation on the local SR and use the returned value as the final result.

The key point here is that we use a local instance of an SR, in order to canonically accomplish the merging of records (associated with the search key) coming from different peers!

  • (3) Rig the DHT implementation to run an SR service in parallel to the DHT service.
    In particular, when the DHT is started it should register two different libp2p protocols with the local host: one for the DHT service and one for the independent SR service.

Planning doc here: https://docs.google.com/document/d/14yOR02EbHbl44Y3fWz-Hvoy6-s1NnT48JRfBHgtSWIo/edit

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

No branches or pull requests

1 participant