Feature #3793
closed
ndncatchunks version discovery: don't rely on timeouts
Added by Anonymous over 7 years ago.
Updated over 6 years ago.
Description
ndncatchunks currently produces at least one timeout before starting to fetch actual data (for version discovery or freshness check):
klaus@laptop:~$ ndncatchunks -v /bla > /dev/null
Data: Name: /bla/%FD%00%00%01W%87r%9B%E9/%00%00
MetaInfo: ContentType: 0, FreshnessPeriod: 10000 milliseconds, FinalBlockId: %00%02
Content: (size: 4400)
Signature: (type: 1, value_length: 256)
Discovered version = 1475446217705
Timeout for Interest /bla?ndn.MinSuffixComponents=3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=2012873900&ndn.Exclude=,%FD%00%00%01W%87r%9B%E9
Timeout for Interest /bla?ndn.MinSuffixComponents=3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=2617007607&ndn.Exclude=,%FD%00%00%01W%87r%9B%E9
Found data with the latest version: 1475446217705
Requesting segment #1
Received segment #1
Requesting segment #2
Received segment #2
For smaller file retrievals, the 2 second timeout takes up the majority of the download completion time.
I suggest that we design ndncatchunks in a way that doesn't require timeouts. Maybe we can do the version discovery with a manifest or use version 1 by default and make it optional to check for the latest version.
- Subject changed from ndncatchunks: Remove reliance on timeouts to ndncatchunks version discovery: don't rely on timeouts
This is a consequence of using iterative version discovery. Choosing a different version discovery procedure, such as fixed, removes the timeout.
Okay, this seems related to #3771.
It looks like the problem wasn't the fixed version discovery per se, but rather that it wasn't intuitively usable (that user need to know the naming conventions of the version number).
Maybe we can assure that
ndncatchunks -d fixed /file
retrieves the first version of the file and allow a simple way to specify other versions?
Currently this command returns
ERROR: The specified name must contain a version component when using fixed version discovery
which isn't helpful at all.
I disagree with making changes to the semantics of existing version discovery procedures.
However, it's okay to make a new version discovery procedure that takes the first version without waiting for timeouts.
It's worth noting that such a version discovery procedure has higher chance of failure: when a version found in an intermediate cache is chosen, it's likely that this isn't the latest version and no producer is serving this version; in case network caches do not have every segment, the retrieval will fail.
I also disagree with changing the iterative discovery. This is exactly how it's supposed to behave, by design. You can implement a different discovery algorithm as a separate -d option.
Note that you can use --retries-iterative=0 to use the first discovered version immediately, without waiting for any timeouts.
I agree. This isn't a problem about the iterative version discovery, but more about the usability of the fixed version discover as noted in comment #2.
Note that you can use --retries-iterative=0 to use the first discovered version immediately, without waiting for any timeouts.
This didn't work for me. It only reduced the number from 2 timeouts (shown above) to 1 timeout.
Just as follow-up: Can anyone replicate my problem of getting 2 timeouts at the beginning instead of 1?
- Tracker changed from Task to Feature
- Start date deleted (
10/02/2016)
I want to push this issue. There needs to be a better way of version discovery than relying on timeouts each time.
During the hackathon, I think Alex mentioned that you can get the latest version via selectors. Is that possible?
- Related to Bug #4291: ndncatchunks: Reduce initial timeout of iterative version discovery added
- Status changed from New to Closed
Fixed well enough by #4291
Also available in: Atom
PDF
Updated by 
Updated by