NFD

client should allow configuration of name structure, selectors, guiders.

An example configuration looks like:

It translates to pseudo code like:

var rand = new Random();
var l2recentNonces = new FifoQueue({ capacity:200 });
var l4decimal = 0;

function createInterest() {
  var prob = rand.nextDouble(0, 1);
  if (prob < 0.10) {
    var name = new Name('/example');
    name.append(rand.nextBytes(4));
    var selectors = {
      MinSuffixComponents: 2
    };
    return new Interest(name, selectors);
  } else if (prob < 0.40) {
    var name = new Name('/example/A');
    var selectors = {
      MustBeFresh: 1
    };
    var guiders = {
      Nonce: rand.nextInt(0, Integer.MaxValue)
    };
    var probDuplicateNonce = rand.nextDouble(0, 1);
    if (probDuplicateNonce < 0.10) {
      guiders.Nonce = l2recentNonces[rand.nextInt(0, l2recentNonces.length)];
    }
    l2recentNonces.push(guiders.Nonce);
    return new Interest(name, selectors, guiders);
  } else if (prob < 0.95) {
    var name = new Name('/example');
    var selectors = {
      Exclude: new Exclude()
    };
    var excludeBoundary = rand.nextBytes(4);
    selectors.Exclude.excludeBefore(excludeBoundary);
    return new Interest(name, selectors);
  } else {
    var name = new Name('/example/B');
    name.append((++l4decimal).toString());
    var guiders = {
      Scope: 2
    };
    return new Interest(name, guiders);
  }
}

Detailed probability based traffic generation will require a test feed file which describes the interest generation and content response patterns. Therefore providing all options via command line would not be feasible.

The user will therefore need to specify traffic generation pattern such as shown in the example above in the for of a test feed file. The test feed file will include sections corresponding to interest/content configuration with a generation probability.

A sample instance of this section is for an interest configuration would be:

    GenerationProbabilityPercentage=10
    NameExact=/text/example
    NameAppendBytes=4
    MinSuffixComponents=2

The user will there need to know how to create a test feed file. Sample test feed file will be provided and README will detail available options.

The (commercial) product I used doesn't use a test feed file. It has GUI to input the parameters.
If we are doing this, the GUI could be a web page served from Node.js. This Node.js app can call a C++ program that executes the actual testing.

Yes I agree. A Web interface would be a better alternative to the configuration file. I will design a CPP interface which can be used to add multiple of such instances and then a callable run method which would initiate the test.

However I doubt when most test environment nodes would ideally be virtual machines with only terminal interfaces, a configuration file would be more feasible. If the utility of the web interface is just to provide a GUI, wouldn't conversion of web data to feed files be an better way of test scenario distribution?

Tesgine2000 actually have two components:

• a hardware box that has an Ethernet port on the back panel, and a 10G fiber port on the front panel
• a Windows native application that provides GUI for configuration, running on a PC connected to Ethernet

A session executes as follows:

1. User enters configuration on the Windows app.
2. Upon start, the Windows app uploads the configuration through Ethernet onto the hardware box
3. The hardware box sends packets out of the fiber port, and/or analyzes packets received on the fiber port
4. If analysis is enabled, the analysis results are transferred in realtime onto the PC and displayed by the Windows app

There must be some protocol or "test feed" between the Windows app and the hardware box, but I don't know what is used.

Tool Development Status:

Client Tool = 100%
Server Tool = 100%

The tools are ready for use and sample configuration files are provided.
However, the README file is yet to be updated.