Version 2 (modified by 10 years ago) (diff) | ,
---|
Understanding the AM API using Content Centric Networking
4 Wait for resources to be ready
Even though the createsliver
call succeeded, it does not mean you resources are ready to use. It takes the aggregate time to boot up the nodes, install your scripts and execute them.
You can tell whether your nodes are ready by using a script built on omni
called readyToLogin
.
-
Please use the command:
readyToLogin -a AM_URL
where (as before) AM_URL and SLICENAME 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 -i /Users/example/.ssh/geni_key_pg example@n143-03b.wall1.ilabt.iminds.be User example logs in to collab using: ssh -i /Users/example/.ssh/geni_key_pg example@n144-06a.wall1.ilabt.iminds.be ...
5 Trying out the CCN protocol
The install
and execute
services requested in our RSpec have
already started, and nodes in our experiment should be running the CCN (Content Centric Networking) protocol. Our experiment consists of:
- A data source (node
dsrc1
that holds precipitation data from the US National Oceanic and Atmospheric Administration (NOAA). - A researcher node
rsrchr
that gets data from the data source - A collaborator node
collab
that gets data from the researcher
Key features of the CCN protocol include:
- Data is accessed by name. In our case we use a program called client to get precipitation data by date range (e.g. precipitation between 1901/01/01 and 1901/01/02).
- All nodes cache data for a certain period of time. When a node receives a request for data, it checks its local cache. If the data is in it's cache, it returns that data. Otherwise, it forwards it on to its neighbor.
We verify this caching behavior by:
- Logging into the researcher node and using the client program to get precipitation data for a certain date range. The client displays how long it took to get the data.
- Retrieving the same data again and noting how we get it much faster since it comes out of a cache.
- Requesting data for different date range and see how long it took to retrieve the data.
- Requesting the data again and noting it is retrieved much faster.
If you have time, you can repeat the above steps on the collaborator node.
5.1 Run the CCN application
- Log into the node
rsrchr
using thessh
command returned byreadyToLogin
. - Once you are logged in, ask for precipitation data from 1 Jan 1902 to 2 Jan 1902:
$ /opt/ccnx-atmos/client.py Start Date in YYYY/MM/DD? 1902/01/01 End Date in YYYY/MM/DD? 1902/01/02
- You should see output that looks like:
Asking for /ndn/colostate.edu/netsec/pr_1902/01/01/00, Saving to pr_1902_01_01.tmp.nc Time for pr_1902_01_01.tmp.nc 1.09802699089= Asking for /ndn/colostate.edu/netsec/pr_1902/01/02/00, Saving to pr_1902_01_02.tmp.nc Time for pr_1902_01_02.tmp.nc 4.65998315811= Joining files.. Concat + write time 0.0735998153687 Wrote to pr_1902_1_1_1902_1_2.nc
Note that it took about 1.1 and 4.7 seconds respectively to retrieve data for Jan 1 and Jan 2
- Run the client again and request the same data. This time your output should look like:
Asking for /ndn/colostate.edu/netsec/pr_1902/01/01/00, Saving to pr_1902_01_01.tmp.nc Time for pr_1902_01_01.tmp.nc 0.0423700809479= Asking for /ndn/colostate.edu/netsec/pr_1902/01/02/00, Saving to pr_1902_01_02.tmp.nc Time for pr_1902_01_02.tmp.nc 0.0388598442078= Joining files.. Concat + write time 0.0237510204315 Wrote to pr_1902_1_1_1902_1_2.nc
Notice how much faster the data was retrieved this time. - If time permits, log into the collaborator node
collab
and run queries from there. (Pick dates in 1901 or 1902.) Notice different data retrieval times depending on whether the data came from the datasource, the cache atrsrchr
, or the local cache.