Wiki » History » Version 2
Saurab Dulal, 04/09/2020 10:43 AM
1 | 1 | Saurab Dulal | NDN Service Discovery (NDNSD) |
---|---|---|---|
2 | ============= |
||
3 | |||
4 | 2 | Saurab Dulal | 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. |
5 | 1 | Saurab Dulal | |
6 | 2 | Saurab Dulal | ### Assumption: |
7 | - IP Multicast capable links on a subnet. |
||
8 | - (Devices will use multicast face from NFD) |
||
9 | - Devices already bootstrapped and have obtained authorized application names |
||
10 | 1 | Saurab Dulal | |
11 | 2 | Saurab Dulal | ### Design Goals: |
12 | - Applications should be able to i) advertise services ii) look for the service provided by others iii) select and invoke the desired service. |
||
13 | - The data received via the discovery process should be authentic and secure. |
||
14 | 1 | Saurab Dulal | |
15 | 2 | Saurab Dulal | ### Design specification |
16 | 1 | Saurab Dulal | |
17 | |||
18 | 2 | Saurab Dulal | - All the devices in the network wanting to discover service, announce service or 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. |
19 | 1 | Saurab Dulal | |
20 | 2 | Saurab Dulal | - Depending upon the type of their service, they join a particular sync group. e.g. , 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/* ) |
21 | 1 | Saurab Dulal | |
22 | 2 | Saurab Dulal | ``` |
23 | Sync group prefix: /<root-prefix>/discovery/printer |
||
24 | e.g. /dunn-hall/netlab/discovery/printer (locally reachable) |
||
25 | /uofm/dunn-hall/first-floor/discovery/printer (globally reachable) |
||
26 | ``` |
||
27 | 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: |
||
28 | ``` |
||
29 | e.g /uofm/library/iprint/<device-name>/ |
||
30 | /uofm/dunn-hall/netlab/<device-name>/ |
||
31 | ``` |
||
32 | The device name is a unique name given to each device by the bootstrapping protocol. |
||
33 | 1 | Saurab Dulal | |
34 | 2 | Saurab Dulal | - Applications willing to publish services will use the full-sync API provided by the sync protocol/s, and will publish data under the application name prefix. The frequency of the publish interval can be periodic or as desired. Additionally, 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. |
35 | 1 | Saurab Dulal | |
36 | 2 | Saurab Dulal | - The updates are propagated by the sync protocol to all other nodes listening on the same sync prefix. And hence, the nodes in the network will be synchronized to the latest update. |
37 | 1 | Saurab Dulal | |
38 | 2 | Saurab Dulal | - Applications only trying to discover services will simply send a sync interest (e.g. I: */dunn-hall/netlab/discovery/printer* ) to the desired sync groups, 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 |
39 | ``` |
||
40 | Data (D): name = /dunn-hall/netlab/discovery/printer/ |
||
41 | content: /printer-red/<seq-num>, |
||
42 | /printer-blue/<seq-num> |
||
43 | ``` |
||
44 | 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. |
||
45 | 1 | Saurab Dulal | |
46 | 2 | Saurab Dulal | - Once the sync 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 for each application prefix so that applications can avoid sending a separate interest to fetch content. This will also speed up the whole process. |
47 | 1 | Saurab Dulal | |
48 | 2 | Saurab Dulal | - Applications willing to do both i.e. publish 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. |