-
Notifications
You must be signed in to change notification settings - Fork 20
kademlia: Workaround for dealing with not implemented PUT_VALUE
ACKs
#430
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
base: dm-put-record-success
Are you sure you want to change the base?
kademlia: Workaround for dealing with not implemented PUT_VALUE
ACKs
#430
Conversation
PUT_VALUE
ACKs implementationPUT_VALUE
ACKs
let query_id = match action { | ||
// `SendFindNode` includes `FIND_NODE`, `GET_VALUE` and `GET_PROVIDERS` | ||
// queries. | ||
PeerAction::SendFindNode(query_id) |
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.
nit: Maybe we could add the fn query_id()
in the PeerAction?
|
||
/// Send message and ignore sending errors. | ||
/// | ||
/// This is a hackish way of dealing with older litep2p nodes not exppecting receiving |
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.
nit: typo in exppecting
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.
LGTM!
Because previously litep2p didn't send/receive
PUT_VALUE
ACKs, we can't just enable this mechanism — this would lead to failures when older remote peers don't behave up to spec. This PR deals with this situation by implementing a workaround to handle such peers:PUT_VALUE
send successes instead of ACK responses to determine the query success.PUT_VALUE
ACK message.This should be seen as a temporary measure until most of the networks updates to litep2p with
PUT_VALUE
ACK support (this PR or newer). Suggested timing is in a year after releasing the version with this PR. This is tracked by issue #429.Builds upon #427.