Ambiguity in kademlia DHT `PUT_VAL` response specification
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 1.8k
- Forks
- 320
- Avg merge
- 11d 15h
- Merged PRs (30d)
- 1
Description
The current specification describes the putval response as so:
PUT_VALUE: In the request record is set to the record to be stored and key on Message is set to equal key of the Record. The target node validates record, and if it is valid, it stores it in the datastore and as a response echoes the request.
This could be interpreted in several ways:
- always just echo the request RPC
- same as 1, but if the selected value to be entered changes, update the echo to include this change.
- 1, but only if there was a succesful insertion
- 2, but only if there was a sucessful insertion
- 3 or 4, but if it fails, respond with an error message, or some other form of error signal.
I'm currently going by 4, but I'm not sure if that's correct.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the linked kademlia DHT RPC Messages specification, focusing on the PUT_VALUE response wording. Compare the five interpretations in the issue and determine which response behavior the specification should state explicitly; done means the ambiguity is resolved in the specification.
Written by the indexing model from the issue text.
Assessment
- Domain
- distributed-systems, documentation, networking
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100