kad: Expose the peer that provided the kad record #76
Merged
Conversation
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
dmitry-markin
approved these changes
Apr 18, 2024
4 tasks
lexnv
added a commit
that referenced
this pull request
Apr 19, 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: - A peer is discovered to have an outdated authority record (needs #76) - Update the record with the latest authority record available (part of this PR) 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](https://github.com/paritytech/litep2p/blob/96e827b54f9f937c6d0489bef6a438b48cf50e58/src/protocol/libp2p/kademlia/query/find_node.rs#L37), 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 --------- Signed-off-by: Alexandru Vasile <[email protected]>
lexnv
added a commit
that referenced
this pull request
Apr 19, 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: - A peer is discovered to have an outdated authority record (needs #76) - Update the record with the latest authority record available (part of this PR) 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](https://github.com/paritytech/litep2p/blob/96e827b54f9f937c6d0489bef6a438b48cf50e58/src/protocol/libp2p/kademlia/query/find_node.rs#L37), 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 --------- --------- Signed-off-by: Alexandru Vasile <[email protected]> Co-authored-by: Dmitry Markin <[email protected]>
Intel-driver
added a commit
to Intel-driver/litep2p
that referenced
this pull request
Dec 24, 2025
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: - A peer is discovered to have an outdated authority record (needs paritytech/litep2p#76) - Update the record with the latest authority record available (part of this PR) 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](https://github.com/paritytech/litep2p/blob/96e827b54f9f937c6d0489bef6a438b48cf50e58/src/protocol/libp2p/kademlia/query/find_node.rs#L37), 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: paritytech/litep2p#76 cc @paritytech/networking --------- --------- Signed-off-by: Alexandru Vasile <[email protected]> Co-authored-by: Dmitry Markin <[email protected]>
This file contains hidden or 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
2 participants
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 exposes the Peer ID that provided the kademlia record
PeerRecordwrapper is introduced over a kadRecordand contains the peer that provided the said recordGetRecordSuccessevent is extended to provide to the end user thePeerRecordWhile at it, have extended a test to check that the peer id is propagated through queries
Created to unblock paritytech/polkadot-sdk#3786
cc @paritytech/networking