Wiki » History » Revision 8
Revision 7 (Saurab Dulal, 04/09/2020 01:10 PM) → Revision 8/16 (Saurab Dulal, 04/10/2020 02:15 PM)
NDN Service Discovery (NDNSD)
=============
NDNSD is a service discovery library for NDN based devices and applications. It uses the sync protocol to disseminate publication and discovery updates. Thus, it can also be viewed as a wrapper library on top of the sync libraries.
[Assumption] (#Assumption)
[Design Goals] (#Design-Goals)
[Design specification] (#Design-Specification)
[Technical specification] (#Technical-Specification)
### 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 the service provided by others iii) select and invoke the desired service.
- The data received via the discovery process should be authentic and secure.
1. ### Design Specification:
- All the devices in the network looking to i) discover service ii) announce service ii) do both, run runs a discovery application written on top of the discovery library capable of adapting to different sync protocols. Basically, here the sync will be used as a Blackbox.
2. **Producer**
1. Application joining as a producer, depending
- Depending upon service the type it wants to advertise, will of their service, they join a particular sync group. e.g., a printer application will use sync prefix specific to printers to advertise their service.
2. 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/* )
```
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. The authorized Authorized application name can be:
```
e.g /uofm/library/iprint/<device-name>/
/uofm/dunn-hall/netlab/<device-name>/
```
The device name is a unique name given to each device by the bootstrapping protocol.
3. Additionally, applications can also query the network
- Applications willing to know about all the publish services (technically sync groups) available in the network and can choose among the right ones. How does this work?
A well-known sync group */\<root-prefix>/discovery* (anchor group) will keep track of all the services available in the network. When an application tries to join a sync group, it can fetch all the available groups and choose the right one to join. If a right group doesn’t exist, or if it wants to create a new one, it can easily do so. Once created, */\<root-prefix>/discovery* will also be updated to include this new group. This feature has several benefits but most importantly it will help consumers/producers search for a specific group/s and join without requiring out-of-band knowledge.
(In future, anchor group can also keep track of services and the respective sync protocol they are using)
4. Applications will use the full synchronization API provided by the discovery library to sync protocol/s, and will publish data under the application name prefix. The frequency of the publish interval can be periodic or as desired, and is controlled entirely by the discovery application. The current producer API consists of following properties,
| Property | Description |
|--|--|
| Service Name | Broader service producer Additionally, a chronologically increasing sequence number is interested attached in e.g. printer|
| Application Prefix | Legitimate name of producer obtained from the bootstrap |
| Flags | List of flags such as protocol choice, application type, etc.|
| Service Info | Information about the service, can be json file or text|
| Timestamp | Service each publication or update timestamp|
| Service lifetime | How long will service be active?|
| Callback | Publish status to application callback from discovery|
5. Once internally by the publish are received from the producer, discovery lib perform the following tasks
1. Store or update the published information i.e. service name, info, application prefix, timestamp and lifetime locally. This will be later used to serve the request that comes for the application name.
2. Join or create a new sync group from the service name.
3. protocol. Start listening on the corresponding application name prefix.
Note: e.g. */uofm/library/iprint/printer-red/1* <- seq-number.
- The reason behind the discovery library listening on application prefix is to hide the network level abstraction from the application while still leveraging the full network primitives.
1. The updates are propagated by discovery with the help sync protocol to all other nodes listening on the same sync group prefix. And hence, all the nodes in the network will be synchronized to the latest update.
2. When the producer receives an interest for the application prefix it is listening on it performs the following tasks:
1. Check if the service has expired.
Status = current_time()
- publish_time() > lifetime ? EXPIRED : ACTIVE
2. Bundles up the info and status in a TLV and sends it back.
3. If the prefix has expired since a long time, send an application NACK. (need more discussion)
3. **Consumer**
1. Applications only trying to discover a particular service, services will use the consumer API of the discovery library to simply send its query with the service name and required flags. Additionally, if the consumer doesn’t know the exact service name, it can ask the discovery library for all the available service names and choose the right one. This is facilitated by steps 2.c.
2. The current consumer API looks like following,
| Property | Description |
|--|--|
| Service Name | Service consumer is interested to discover|
| Flags | List of flags such as protocol choice, application type, etc |
| Callback | Callback containing application details i.e. service name, info, and status (active or passive) for each name from the sync data. |
3. Once the query is received by the discovery lib, it performs the following tasks
1. Constructs a sync interest from the service name and fetches the sync data containing all the application names under a particular sync group (service)
2. Iteratively sends interest (e.g. I: */dunn-hall/netlab/discovery/printer* ) to all the application names desired sync groups, and fetches find out all the corresponding details. (these details are bundled up in a TLV and are sent latest updates by all the corresponding producer (2.g). For more details, refer applications belonging to the technical details section below).
3. same group. And finally, sends Example: Data for the corresponding details of each application to the consumer in the callback.
**Example:**
Sync above interest (e.g. I: /dunn-hall/netlab/discovery/printer )
Sync Data:
may look like
```
Data (D): name = /dunn-hall/netlab/discovery/printer/
content: /printer-red/<seq-num>,
/printer-blue/<seq-num>
```
Iteratively fetching for
Here the sync protocol acts as a transport service propagating the updates. The application absolutely doesn’t have to deal with low-level network primitives while still leveraging all the services offered by it via sync API.
- Once the sync data is received by an application, it can fetch the content specific to each application name:
```
Interest (I): /printer-red/
Data (D): name = /printer-red/
Content: <Info>: “HP Laserjet 400”, <Status>: Active
4. update on the user prefix (/printer-red/<seq-num>). Additionally, sync can also piggyback the data content for each application prefix so that consumer applications can avoid sending a separate interest to fetch content. This will also speed up the whole process. (redmine: [5089](https://redmine.named-data.net/issues/5089))
5. Both
1. Application register as
- Applications willing to do both ie. consumer i.e. publish and producer, is pretty much similar to that of producer. But in addition, unlike producer, whenever discover services will perform both steps 3, 4 and 5. Basically, it will set an update in interest filter on the particular sync group is received via sync protocol, discovery lib prefix that it serves - meaning listening for an interest. And when it publishes an update, it will iteratively fetch satisfy the updates and send pending sync interest. Similarly, it back to the application.
2. Application to be considered both specifically needs to be the part of the same sync group.
Throughout this process, the sync protocol acts will also periodically (or as desired) send a transport service propagating the updates. It gives great relief sync interest to get the application. It can absolutely avoid dealing with low-level network primitives while still leveraging latest updates from all the services offered by it via sync API. nodes in the network.
### [Design specification] (#design-specification):