= [../Setup Understanding the AM API using Named Data Networking] =
{{{
#!html
}}}
== 4 Wait for resources to be ready ==
You can tell whether your nodes are ''ready'' by using a script built on `omni` called `readyToLogin`.
{{{
#!html
-
Please use the command:
readyToLogin -a AM_NICKNAME SLICE_NAME
where (as before) AM_NICKNAME and SLICE_NAME are your aggregate
manager nickname and your slice name.
- If it reports that the sliver is not yet ready (for example, it might say that the status is "changing"), then wait a minute
or two and try again. Once everything is complete, readyToLogin
will give output that should look something like this:
...
rschr's geni_status is: ready (am_status:ready)
User example logs in to rschr using:
ssh -p 32768 -i /Users/example/.ssh/geni_key_portal example@pc1.utah.geniracks.net
User example logs in to collar using:
ssh -p 32769 -i /Users/example/.ssh/geni_key_portal example@pc1.utah.geniracks.net
...
}}}
== 5 Trying out the NDN application ==
In this experiment, you will be able to see the NDN in-network caching in action. Our experiment consists of the following nodes:
* A data source node, called {{{Custodian}}} that holds data in the namespace /nytimes
* A node, called {{{Internet Router}}} that forwards {{{Interest}}} and {{{Data}}} packets to and from the {{{Custodian}}}.
* A node, called {{{Campus Router}}} that forwards {{{Interest}}} and {{{Data}}} packets to and from the university nodes.
* A principal investigator node, called {{{PI}}} and a experimenter node, called {{{Experimenter}}} that will send {{{Interest}}} requests to the {{{Custodian}}} via UDP tunnels.
Download the scripts and Python codes to your host machine and extract it.
* [http://192.1.242.151/files/ndn-tutorial.gz ndn-tutorial.gz]
Or alternatively,
{{{
$ wget http://192.1.242.151/files/ndn-tutorial.gz
$ tar -xvf ndn-tutorial.gz
}}}
In the '''ndn-tutorial-config.sh''' configuration file, edit the fields according to your GENI username, SSH key, GENI Aggregate name, pc and port numbers. [[br]]
You can find this information in the {{{RSpec Viewer}}} tab in the {{{Node login information}}} section.[[br]]
Keep the quotes format unchanged, otherwise the script may not run.
Once the topology is up, run {{{copy-scripts.sh}}}, this will automatically transfer the necessary files to the nodes in our topology.
{{{
$ ./copy-scripts.sh
}}}
Login into the node {{{Custodian}}} and re-start the NDN Forwarding Daemon (NFD). This will make sure the content store is refreshed and the routes are cleared.
{{{
$ nfd-stop
$ nfd-start
}}}
wait until the shell prompt returns (~ a few seconds). The NFD is now up and running.
=== 5.1 Run the NDN application on the same node ===
You are now ready to start the producer application and register a namespace. ^([#hn note: you can try other namespaces as well])^[[br]]
The producer application will listen for {{{Interest}}} requests of a namespace {{{-n}}} and reply with {{{Data}}} packets.
{{{
$ python producer.py -n /nytimes
}}}
You should see a message
{{{
$ Registering prefix /nytimes
}}}
Open another terminal on the {{{Custodian}}} node and run
{{{
$ python consumer.py -u /nytimes/science
}}}
This will start the consumer application that will send {{{Interest}}} request packets to the producer. Take a moment to look at the entries in the NFD.
You are all set. Stop the producer application by {{{Ctrl + C}}} and stop the NFD
{{{
$ nfd-stop
}}}
=== 5.2 Run the NDN application on the entire topology ===
In this section, we are going to start the NFD and register the forwarding faces on the remaining nodes. We have automated these tasks for the {{{Campus-Router}}}, {{{Internet-Router}}}, and {{{PI}}} nodes using a script. On your host machine, do the following:
{{{
$ ./setup-app.sh
}}}
We are now ready to run our experiment.[[br]]
SSH to the {{{Custodian}}} node and start the {{{producer}}} application
{{{
$ python producer.py -n /nytimes
}}}
SSH to the {{{Experimenter}}} node and start the consumer application
{{{
$ python consumer.py -u /nytimes/science
}}}
This time the {{{Interest}}} request travels the entire topology, leaving breadcrumbs. The {{{Data}}} packet follows the breadcrumbs back to the {{{consumer}}}, leaving cached versions of the content. This is call in-network caching and it is one of the most important features in {{{Information Centric Networking (ICN)}}}
You can check this phenomenon by running the same consumer application in the {{{PI}}} node.
SSH to the {{{PI}}} node and start the consumer application
{{{
$ python consumer.py -u /nytimes/science
}}}
This time your {{{PI}}} node gets the content back, but nothing happens on the {{{Custodian}}} because the requested content is cached in the {{{Campus Router}}} node.
You can repeat the experiment with different namespaces
{{{
$ python consumer.py -u /nytimes/math
}}}
This time you see that the {{{Interest}}} request is served by the {{{Custodian}}}.
=== 5.3 (Optional) Visualize experiment data flows ===
To use the GENI Desktop to visualize the data flows in your network, continue with the instructions [wiki:GENIExperimenter/Tutorials/jacks/GettingStarted_PartII_ndn/Procedure/Execute/GEMINI here].
----
= [wiki:GENIExperimenter/Tutorials/jFed/GettingStarted_PartII_ndn/Procedure/Setup Setup] =
= [wiki:GENIExperimenter/Tutorials/jFed/GettingStarted_PartII_ndn/Procedure/Finish Next: Finish] =