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

kad: Implement put_record_to and try_put_record_to #77

Merged
merged 11 commits into from
Apr 19, 2024

Conversation

lexnv
Copy link
Collaborator

@lexnv lexnv commented Apr 18, 2024

This PR implements the put_record_to and try_put_record_to to selectively pick peers to update their records.

The main use-case from substrate would be the following:

This PR provided peers to the engine if the peers are part of the kBucket. The first step of the discovery in substrate motivates this assumption. We can probably do things a bit more optimally since we know the peers part of the kBucket were discovered previously (or currently connected):

  • The query starts with a FindNodeContext, which in this case will do a peer discovery as well
  • We could implement a PutNodeContext which circumvents the need to discover the peers and just forwards a kad PUT_VALUE to those peers
    We'd have to double check that with libp2p as well (my brief looking over code points to this direction).

To unblock paritytech/polkadot-sdk#3786 we can merge this and then come back with a better / optimal solution for this

Builds on top of: #76

cc @paritytech/networking

@lexnv lexnv self-assigned this Apr 18, 2024
@lexnv lexnv requested a review from dmitry-markin April 18, 2024 09:49
Comment on lines 757 to 761
self.engine.start_put_record(
query_id,
record,
peers
);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going once again through start_put_record() implementation and FindNodeContext query used under the hood, this seems to be doing a slightly different thing that what's needed by authority-discovery. Seeding peers with some specific candidates would result in QueryType::PutRecord query initialized by that peers, but if FindNode collects more than 20 peers that are closer to the target than the original "seed" peers, the "seed" peers would end up not updated.

To update specific peers, we can go two routes:

  1. Update only peers if they are already in the routing table. For this, we just need to send KademliaMessage::put_value directly to peers from the routing table. This should be enough for authority-discivery needs, as the peers should be already in the routing table.
  2. Update peers, even if they are not in the routing table. Basically, do FindNode query for the needed peers first, followed by sending KademliaMessage::put_value to the discovered addresses. We likely need this to conform to libp2p put_record_to implementation, but can do in a follow-up.

src/protocol/libp2p/kademlia/mod.rs Outdated Show resolved Hide resolved
src/protocol/libp2p/kademlia/mod.rs Outdated Show resolved Hide resolved
src/protocol/libp2p/kademlia/mod.rs Outdated Show resolved Hide resolved
lexnv added 3 commits April 19, 2024 16:45
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
@lexnv lexnv merged commit c5238d6 into lexnv/expore-peer-id Apr 19, 2024
7 checks passed
lexnv added a commit that referenced this pull request Apr 19, 2024
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

Successfully merging this pull request may close these issues.

2 participants