Skip to content

kad: Expose the peer that provided the kad record #76

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

Merged
merged 3 commits into from
Apr 18, 2024

Conversation

lexnv
Copy link
Collaborator

@lexnv lexnv commented Apr 17, 2024

This PR exposes the Peer ID that provided the kademlia record

  • The PeerRecord wrapper is introduced over a kad Record and contains the peer that provided the said record
  • GetRecordSuccess event is extended to provide to the end user the PeerRecord

While 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

lexnv added 3 commits April 17, 2024 19:50
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
@lexnv lexnv self-assigned this Apr 17, 2024
@lexnv lexnv merged commit d7fa12b into master Apr 18, 2024
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 <alexandru.vasile@parity.io>
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 <alexandru.vasile@parity.io>
Co-authored-by: Dmitry Markin <dmitry@markin.tech>
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