Project

General

Profile

Task #2106

Segmented retrieval example

Added by Junxiao Shi over 6 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Docs
Target version:
Start date:
Due date:
% Done:

70%

Estimated time:
6.00 h

Description

Develop a pair of example programs for segmented retrieval:

  • the producer ndnputchunks reads an input from stdin, and publishes it as segments
    • Name prefix is specified as command line argument, plus a version number from current timestamp
  • the consumer ndncatchunks retrieves segments and writes them to stdout
    • Name prefix is specified as command line argument
    • the latest version should be discovered
    • Interest pipelining should be used, and the maximum number of outstanding Interest is specified as command line argument
    • output should be in the order of segment number

Some code can be reused from tools/ndncatchunks3.cpp and tools/ndnputchunks3.cpp.

These tools should be deleted as part of this Task.


Related issues

Related to ndn-tools - Feature #3071: chunks: segmented file transferClosedAndrea Tosatto

Actions
#1

Updated by Anonymous over 6 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50
#2

Updated by Anonymous over 6 years ago

  • % Done changed from 50 to 70

I have written the initial code for the producer and consumer, but still need to test.

#3

Updated by Anonymous over 6 years ago

  • Status changed from In Progress to Code review
#4

Updated by Alex Afanasyev over 6 years ago

After this task we no longer going to have "ndncatchunks3" tool, which will only exist as an example. Are you sure that we do not need such tool?

#5

Updated by Anonymous over 6 years ago

No. In fact, I think I would prefer to keep the final applications under tools; they are somewhat analogous to wget.

#6

Updated by Junxiao Shi over 6 years ago

The old programs are broken. No one should be using them.

The fixed programs are useful as tools.
However, they shouldn't appear in ndn-cxx, given that ndn-tlv-peek and ndn-tlv-poke are in NFD.

I won't object if those programs are added as tools into NFD repository, but they still need to appear as examples in ndn-cxx.

#7

Updated by Anonymous over 6 years ago

I don't like the idea of having the same code in both ndn-cxx/examples and in NFD's tools. By definition, it doubles the maintenance load (both coding and reviewing) when something inevitably breaks.

There are a number of other tools in ndn-cxx/tools. Mostly ndnsec related things, but there's also tlvdump. Should these also be moved to NFD/tools? What distinguishes a ndn-cxx tool from an NFD tool?

NFD/tools is almost exclusively programs that only work with NFD and seems like the wrong place to put a retrieval client/server (or any of the ndn-cxx/tools).

#8

Updated by Junxiao Shi over 6 years ago

This matter deserves a broader discussion on nfd-dev mailing list. Please post a message on nfd-dev and I'll reply there.

#9

Updated by Alex Afanasyev over 6 years ago

Steve DiBenedetto wrote:

There are a number of other tools in ndn-cxx/tools. Mostly ndnsec related things, but there's also tlvdump. Should these also be moved to NFD/tools? What distinguishes a ndn-cxx tool from an NFD tool?

There are only these two: ndnsec (I'll move all header files under ndnsec-src/ later) and tlvdump. ndnsec is entirely about security library, which is irrelevant to NFD and manages security. tlvdump is about packet format and also not exactly relevant to NFD.

cat/putchunks is kind of irrelevant to either, so I have no strong opinion on where they should go. If they are general enough, they can be both tools and there could be README under examples folder to point to other examples. If they have some specifics that needs to be adjusted for specific use, then they should go to just examples.

As for tlv-peek and tlv-poke. I would move them to the library from NFD, as they more related to the library then NFD.

#10

Updated by Alex Afanasyev over 6 years ago

Steve DiBenedetto wrote:

I was also wondering whether the Engine classes would be useful things to have in the library itself (e.g. util/) until we have Ilya's API stuff.

This probably true. Assuming there are no specifics to ndncatchunks app, these classes could go to src/util, as we already have a number of tools there. Btw. Why do they need to have "virtual run" method and be inherited from "Engine" class?

#11

Updated by Anonymous over 6 years ago

I was thinking it could be useful to have a common interface. For example, you could pass an Engine derivative (or some composition) to something else to tell the receiver how it should go about retrieving Data. We currently pass Faces around and (maybe) use Interest templates. This would be a step towards generalization.

#12

Updated by Junxiao Shi over 6 years ago

http://gerrit.named-data.net/1581

I suggest delaying this Task until name discovery technical memo is complete.

An example is where newcomers learn how NDN applications should be designed.

One important feature illustrated in this example is how to discover the latest version.
The design of this feature should be consistent with name discovery technical memo.

#13

Updated by Anonymous over 6 years ago

I agree that this feature should be consistent with the name discovery technical memo. However, that document (as far as I can see) does not exist. In the absence of a finished document, I would prefer code review to be guided the following questions:

  1. Is the current approach reasonable?
  2. Is the document likely to specify a different approach for the scenario outlined in this task?

The tech memo cannot just appear out of thin air. We have to already know something about name discovery to write it. Could @Beichuan could summarize the key ideas/best practices?

#14

Updated by Junxiao Shi over 5 years ago

  • Related to Feature #3071: chunks: segmented file transfer added
#15

Updated by Junxiao Shi over 5 years ago

The fixed programs are useful as tools.

Now we have ndn-tools repository and they can be imported as chunks tool in #3071.

#16

Updated by Junxiao Shi over 5 years ago

Beichuan reveals at 20150727 conference call that the name discovery technical memo will be ready in August 2015.

Alex can decide whether we need this as an example, in addition to the tool in #3071.

#17

Updated by Alex Afanasyev over 5 years ago

  • Status changed from Code review to Rejected

There is no need to have a separate example.

Also available in: Atom PDF