-
Notifications
You must be signed in to change notification settings - Fork 11
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
Conversation
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
src/protocol/libp2p/kademlia/mod.rs
Outdated
self.engine.start_put_record( | ||
query_id, | ||
record, | ||
peers | ||
); |
There was a problem hiding this comment.
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:
- 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. - Update peers, even if they are not in the routing table. Basically, do
FindNode
query for the needed peers first, followed by sendingKademliaMessage::put_value
to the discovered addresses. We likely need this to conform to libp2pput_record_to
implementation, but can do in a follow-up.
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
This PR implements the
put_record_to
andtry_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):
PutNodeContext
which circumvents the need to discover the peers and just forwards a kadPUT_VALUE
to those peersWe'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