protocols/kad/behaviour: Return peers independent of record existence #1544
Conversation
This file contains 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
A node receiving a `GetRecord` request first checks whether it has the given record. If it does have the record it does not return closer nodes. A node that knows the record for the given key is likely within a neighborhood of nodes that know the record as well. In addition the node likely knows its neighboorhood well. When querying for a key with a quorum of 1 the above behavior of only returning the record but not any close peers is fine. Once one queries with a higher quorum having a node respond with the record as well as close nodes is likely going to speed up the query, given that the returned peers probably know the record as well.
romanb
approved these changes
Apr 7, 2020
mxinden
added a commit
to mxinden/rust-libp2p
that referenced
this pull request
Apr 8, 2020
…libp2p#1544) A node receiving a `GetRecord` request first checks whether it has the given record. If it does have the record it does not return closer nodes. A node that knows the record for the given key is likely within a neighborhood of nodes that know the record as well. In addition the node likely knows its neighboorhood well. When querying for a key with a quorum of 1 the above behavior of only returning the record but not any close peers is fine. Once one queries with a higher quorum having a node respond with the record as well as close nodes is likely going to speed up the query, given that the returned peers probably know the record as well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A node receiving a
GetRecordrequest first checks whether it has the given record. If it does have the record it does not return closer nodes. (See https://github.com/libp2p/rust-libp2p/blob/master/protocols/kad/src/behaviour.rs#L1268-L1287)A node that knows the record for the given key is likely within a neighborhood of nodes that know the record as well. In addition the node likely knows its neighboorhood well.
When querying for a key with a quorum of 1 the above behavior of only returning the record but not any close peers is fine. Once one queries with a higher quorum having a node respond with the record as well as close nodes is likely going to speed up the query, given that the returned peers probably know the record as well.
This patch aligns the behavior of the
GetRecordrequest with theGetProviderReqbehavior.As far as I can tell the Golang implementation follows the same suggested behavior.
What do you think @romanb