Wiki » History » Revision 2
Revision 1 (Saurab Dulal, 04/09/2020 10:04 AM) → Revision 2/16 (Saurab Dulal, 04/09/2020 10:43 AM)
NDN Service Discovery (NDNSD) ============= NDNSD ## Repo protocol **Repo protocol** is a service discovery library semantics and operating process for persistent storage node in NDN. The operation of NDN based devices repo includes reading from, insertion to and applications. It uses the sync protocol deleting from data objects in NDN repository nodes. **Repo protocol** conforms to disseminate publication **[[Repo Protocol Specification|Repo Protocol Specification]]** for operating and discovery updates. Thus, it can also be viewed as controlling, including a wrapper library on top set of the sync libraries. repo management protocols: ### Assumption: - IP Multicast capable links on a subnet. - (Devices will use multicast face from NFD) - Devices already bootstrapped and have obtained authorized application names ### Design Goals: - Applications should be able to i) advertise services ii) look for **[[Repo Command]]** defines the service provided by others iii) select request and invoke the desired service. - The response formats of commands that can insert or remove data received via the discovery process from repo, and how these commands should be authentic signed and secure. ### Design specification authenticated. - All the devices in the network wanting to discover service, announce service or do both, run a discovery application written on top **[[Basic Repo Insertion Protocol]]** defines format of the discovery library capable insertion of adapting to different sync protocols. Basically, here the sync will be used as a Blackbox. - Depending upon the type single or collection of their service, they join a particular sync group. Data packets. e.g. , In addition to the printer application will use sync prefix to advertise their service. Evey sync group namespace will have a root-prefix that is either context-dependent (e.g. */dunn-hall/netlab/* ), local (e.g. */myhome/* ), or globally reachable (e.g. */uofm/dunn-hall/first-floor/* ) basic protocol, repo-ng implements several other insertion protocols: ``` Sync group prefix: /<root-prefix>/discovery/printer e.g. /dunn-hall/netlab/discovery/printer (locally reachable) /uofm/dunn-hall/first-floor/discovery/printer (globally reachable) ``` Note: our assumption is that the devices are already bootstrapped, and have obtained application name/s that they are allowed to publish the data under. Authorized application name can be: ``` e.g /uofm/library/iprint/<device-name>/ /uofm/dunn-hall/netlab/<device-name>/ ``` The device name is + **[[Watched Prefix Insertion Protocol]]** defines a unique name given protocol to each device by the bootstrapping protocol. - Applications willing to publish services will use the full-sync API provided by the sync protocol/s, and will publish insert continuously generated data under the application name prefix. The frequency of the publish interval can be periodic or as desired. Additionally, + **[[Tcp Bulk Insert Repo Insertion Protocol]]** defines a chronologically increasing sequence number is attached in each publication internally by the sync protocol. e.g. */uofm/library/iprint/printer-red/1* <- seq-number. - The updates are propagated by the sync simple TCP-based protocol to all other nodes listening insert Data packets in bulk (e.g., from a producer on the same sync prefix. And hence, the nodes in the network will be synchronized to the latest update. host) - Applications only trying to discover services will simply send **[[Repo Deletion Protocol]]** defines format of deletion of a sync interest (e.g. I: */dunn-hall/netlab/discovery/printer* ) single or collection of Data packets under certain prefix ## repo-ng **repo-ng** (repo-new generation) is an implementation of NDN persistent in-network storage conforming to the desired sync groups, **Repo protocol**. It uses [ndn-cxx](http://redmine.named-data.net/projects/ndn-cxx) as NDN client library and finds out all the latest updates by all the applications belonging to the same group. Example: Data for the above interest may look like database sqlite3 as underlying data storage. ### platform and libraries ``` Data (D): name = /dunn-hall/netlab/discovery/printer/ content: /printer-red/<seq-num>, /printer-blue/<seq-num> * [C++11](http://en.cppreference.com/w/), [code style guidelines](http://redmine.named-data.net/projects/nfd/wiki/CodeStyle) ``` Here * [Boost >=1.48.0](http://www.boost.org/doc/libs/1_48_0/), we use [|a limited set of Boost libraries](http://redmine.named-data.net/projects/nfd/wiki/Boost) * [Boost Unit Test Framework](http://www.boost.org/doc/libs/1_48_0/libs/test/doc/html/index.html), more information on [[unit testing](http://redmine.named-data.net/projects/nfd/wiki/UnitTesting) * [ndn-cxx](https://github.com/named-data/ndn-cxx), Extended version of NDN C++ client library * [waf build system](https://code.google.com/p/waf/) * [sqlite3](http://sqlite.org/) ### specific design * [[Database design|Database design]] * [[Software Structure|Software Structure]] * [[Tools|tools]] ### current supported functions Most parts of the sync protocol acts as a transport service propagating the updates. are supported in repo-ng. The application absolutely doesn’t have to deal with low-level network primitives while still leveraging following specifications are not supported in current version. * For deletion command, if EndBlockId is null in RepoCommandParameter, repo cannot response all the services offered by it via sync API. - Once the sync segmented data is received by an application, it can fetch the content specific to each update on the user prefix (/printer-red/<seq-num>). Additionally, sync can also piggyback the data content from StartBlockId * Command for each application prefix so that applications can avoid sending a separate interest to fetch content. This will also speed up checking deletion progress Trust model of command validation and access control have not been designed. All the whole process. - Applications willing to do both i.e. publish commands are validated in current version and discover services will perform both steps 3, 4 and 5. Basically, it will set an interest filter on the particular sync group prefix that it serves - meaning listening for an interest. And when it publishes an update, it will satisfy the pending sync interest. Similarly, it will also periodically (or as desired) send a sync interest to get the latest updates from all the nodes in the network. commands could pass. ### user experience * [repo-ng cheatsheet (2014)](http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20171202/84b3fec8/attachment-0001.pdf)