Bug #3981
closed
ndncatchunks: wrong Nack handling in DiscoverVersionIterative
Added by Junxiao Shi over 7 years ago.
Updated over 5 years ago.
Description
Steps to reproduce:
nfd-start
ndnputchunks -v -f 20000 /demo/NFD/city-hash.cpp < ./NFD/core/city-hash.cpp
ndncatchunks -v /demo/NFD/city-hash.cpp
, retrieval succeeds
- kill the process in step2
ndncatchunks -v /demo/NFD/city-hash.cpp
(within 20 seconds of step3)
Expected: step5 retrieval succeeds, because Data is in ContentStore and not stale
Actual: ERROR: Could not retrieve data for /demo/NFD/city-hash.cpp, reason: NoRoute
If we prevent Nack-NoRoute by setting best-route v1 strategy, step5 retrieval succeeds as expected.
- Tracker changed from Feature to Bug
- Assignee set to Shuo Yang
This is a bug. A network Nack should never result in a worse outcome than a timeout.
Copying Beichuan's argument.
A consumer never knows whether its request will hits the producer or not. Thus the so-called “latest” version is the latest version that is available from the network, not necessarily from the producer. When the producer is not available, the discovery should return the latest version it can find, in this case, the version in the CS. While NACK-NoRoute is fine, the consumer should treat this NACK the same way as it treats a timeout, and concludes that the last version it got is the latest version it can find.
- % Done changed from 0 to 80
- Status changed from New to In Progress
- Assignee changed from Shuo Yang to Anonymous
- Status changed from In Progress to Feedback
- % Done changed from 80 to 0
- Status changed from Feedback to New
- Priority changed from Normal to Low
- Subject changed from chunks: wrong Nack handling in DiscoverVersionIterative to ndncatchunks: wrong Nack handling in DiscoverVersionIterative
- Assignee deleted (
Anonymous)
- Status changed from New to Rejected
DiscoverVersionIterative
has been removed in #4556
Also available in: Atom
PDF