Wiki » History » Revision 13
Revision 12 (Saurab Dulal, 04/11/2020 02:04 PM) → Revision 13/16 (Saurab Dulal, 04/11/2020 02:14 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 a 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.
### Design-Specification:
1. All the devices in the network looking to i) discover service ii) announce service ii) do both, run 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 upon service type it wants to advertise, will join a sync group. e.g., a printer application will use sync prefix (e.g. /\<root-prefix>/discovery/printer ) specific to printers to advertise their service.
2. Evey sync group namespace will have a root-prefix prefix. e.g. */dunn-hall/netlab/* , */myhome/*, */uofm/dunn-hall/first-floor/*.
e.g /dunn-hall/netlab/discovery/\<device-name> / ---> /dunn-hall/netlab/discovery/printer1
/uofm/dunn-hall/netlab/\<device-name> / ---> /uofm/dunn-hall/netlab/printer1/ ;the device name is a unique name given to each device by the bootstrapping protocol.
**Note:** our assumption is that the devices are already bootstrapped, and have obtained a unique application name/s that they are allowed to publish the data under.
4. Applications will use the API provided by the discovery library to publish under the application name prefix. The frequency of the publish interval is controlled entirely by the discovery application. The current producer API consists of following properties,
| Property | Description |
|------------------ |-------------|
| Service Name | Broader service producer is interested 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 publication or update timestamp|
| Service lifetime | How long will service be active?|
| Callback | Publish status to application callback from discovery|
5. Once 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. Start listening to the corresponding application name prefix.
Note: 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.
6. 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.
7. 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, will use the consumer API of the discovery library to send its query with the service name and required flags.
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 to all the application names and fetches the corresponding details. (these details are bundled up in a TLV and are sent by the corresponding producer (2.7). For more details, refer to the technical details section below).
3. And finally, sends the corresponding details of each application to the consumer in the callback.
**Example:**
Sync interest (e.g. I: /dunn-hall/netlab/discovery/printer )
Sync Data:
```
Data (D): name = /dunn-hall/netlab/discovery/printer/
content: /printer-red/<seq-num>,
/printer-blue/<seq-num>
```
Iteratively fetching for each application name:
```
Interest (I): /printer-red/
Data (D): name = /printer-red/
Content: <Info>: “HP Laserjet 400”, <Status>: Active
4. 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** Both
1. Application register as both ie. consumer and producer, is pretty much similar to the producer. But in addition, unlike producer, whenever an update in the sync group is received via sync protocol, discovery lib will iteratively fetch the updates and send 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 as a transport service propagating the updates. It gives great relief to the application. It can absolutely avoid dealing with low-level network primitives while still leveraging all the services offered by it via sync API.