Project

General

Profile

Actions

Feature #3793

closed

ndncatchunks version discovery: don't rely on timeouts

Added by Anonymous over 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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.


Related issues 1 (0 open1 closed)

Related to ndn-tools - Bug #4291: ndncatchunks: Reduce initial timeout of iterative version discoveryClosed

Actions
Actions #1

Updated by Junxiao Shi over 7 years ago

  • 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.

Actions #2

Updated by Anonymous over 7 years ago

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.

Actions #3

Updated by Junxiao Shi over 7 years ago

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.

Actions #4

Updated by Davide Pesavento over 7 years ago

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.

Actions #5

Updated by Anonymous over 7 years ago

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.

Actions #6

Updated by Anonymous over 7 years ago

Just as follow-up: Can anyone replicate my problem of getting 2 timeouts at the beginning instead of 1?

Actions #7

Updated by Davide Pesavento over 7 years ago

  • Tracker changed from Task to Feature
  • Start date deleted (10/02/2016)
Actions #8

Updated by Anonymous over 7 years ago

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?

Actions #9

Updated by Anonymous over 6 years ago

  • Related to Bug #4291: ndncatchunks: Reduce initial timeout of iterative version discovery added
Actions #10

Updated by Anonymous over 6 years ago

  • Status changed from New to Closed

Fixed well enough by #4291

Actions

Also available in: Atom PDF