The package consists of different implementations of name-content binding validation algorithms for the NI URI format that SAIL members published earlier in http://tools.ietf.org/html/draft-farrell-decade-ni-00 and http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 and additional protocol and NetInf router/client implementations.

An overview of the different implementations and their functionalities:

• c: NI URI format, HTTP convergence layer
• curl: patch for curl to handle NI names
• ruby: NI URI format, HTTP and UDP convergence layers, standalone NetInf router
• python: NI URI format, HTTP convergence layer, standalone NetInf server
• java: NI URI format, HTTP convergence layer, NI proxy with local cache, GET/REGISTER/PUBLISH clients.
• php: HTTP convergence layer
• clojure: NI URI format
• wget: patch for wget to handle NI names
• sh: scripts to generate NI names for a web server environment

SAIL is using these components for the development of prototypes for specific ICN scenarios, for example content distribution to large crowds. This is a joint effort  by multiple partners that involves the developing and interop-testing of implementations of NI URI processing as well as NetInf protocol functionality.

The software is licensed under Apache-2.0 (http://www.apache.org/licenses/LICENSE-2.0) and is available at https://sourceforge.net/projects/netinf/.

Note: The published OpenNetInf code currently uses a previous NetInf naming format that is currently not compliant to the new NI URI format as defined in the Internet drafts above. However, the general naming concepts are equivalent and can be translated into each other.

Details about the new code release will follow in a separate post.

First, I will shortly describe what the search component is doing. If we speak about resolution, we mean resolving from an Identifier to the actual Information Object. The resolution controller and its services are also responsible for storing Information Objects in the node. The search controller and its services are responsible for returning Identifiers from a given search query. It is important to note that, in order to get the actual Information Object, the client has to send another request with the Identifier he just received to the resolution controller.

The interesting thing now is, how these search queries are constructed. Only one of the two datamodels used in Netinf (RDF and Impl) are needed for this construction. If you look at an Information Object in RDF, you see triplets. We chose to use the XML Serialization of those RDF resources as transmission format. For example, a DataObject might look like this. For further information regarding RDF and triplets, please refer to Wikipedia.

There is a special query language for RDF, named SPARQL. In SPARQL, you can specify which information you want to retrieve from the RDF data that is queried. As a search service always returns Identifiers, a part of the query is already predefined in the search controller code. Whatever you send to the controller will be prepended by

SELECT ?id WHERE {?bNode <http://rdf.netinf.org/2009/netinf-rdf/1.0/#transportedIO> ?id.

The rest of the query has to use ?id as a variable name for the Information Object. An example for a query would be (thanks to Petteri Pöyhönen for finding it)

?id netinf:owner ?bNode2.

which returns any Information Object that has an owner. More complicated queries are possible, too. Petteri Pöyhönen describes them as follows:

Here is the test setup what we have used for doing simple tests for queries.

We created 2 new IOs where both had attribute named as "http://rdf.netinf.org/2009/netinf-rdf/1.0/#keywords".



For first IO, the value of this keywords attribute was "String:A B C D"

and for another "String:E D G"



Now, to search all IOs with the "default" owner named attribute, input the following string to the GUI;

?id netinf:owner ?bNode2.

To search all IOs that has string "D" in their keywords attribute value field, input to the GUI;

?id netinf:keywords ?bNode2. ?bNode2 netinf:attributeValue ?kw. FILTER(regex(str(?kw),"D")).

This results the list of two our new IO IDs having matching keywords attribute. Note: you can replace "bNode2" and "kw" with some other unique IDs/strings in the query; e.g.

?id netinf:keywords ?xyz. ?xyz netinf:attributeValue ?abc. FILTER(regex(str(?abc),"D")).

Note: I have not tried this but I believe it works like that unless there are some reserved words/strings that cannot be used as variable IDs/names, i.e. ID/name starting with ?.



The command "

?id netinf:keywords ?bNode2. ?bNode2 netinf:attributeValue ?kw. FILTER(regex(str(?kw),"A")).

" only returns the ID of the 1st IO and respectively "

?id netinf:keywords ?bNode2. ?bNode2 netinf:attributeValue ?kw. FILTER(regex(str(?kw),"G")).

" returns the ID of the 2nd IO.



... and so on. The query is pretty straightforward to modify once you have the correct basic format/syntax.

Thanks again for that info and good luck and a lot of fun to everybody working with OpenNetinf!

• Checked out (Mercurial) copy of the OpenNetinf repository
• Eclipse IDE with required Plug-ins, all sources and libraries imported
• Auto-Build system for easy deployment of OpenNetinf as JAR files
• Central configuration file for scenario deployment

The VM will be available from this site soon