# How confd interacts with the application?

**URL:** <https://dmap-community.ductus.global/t/how-confd-interacts-with-the-application/191>\
**Category:** Core Engine and APIs\
**Created:** [September 4, 2015, 5:40am UTC](https://dmap-community.ductus.global/t/how-confd-interacts-with-the-application/191 "2015-09-04T05:40:51Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![bharanidharans](https://avatars.discourse-cdn.com/v4/letter/b/a183cd/32.png) [@bharanidharans](https://dmap-community.ductus.global/u/bharanidharans)\
**Post date:** [September 4, 2015, 5:40am UTC](https://dmap-community.ductus.global/t/how-confd-interacts-with-the-application/191/1 "2015-09-04T05:40:51Z")

</div>

Dear Team,

I am looking into dhcpd example. Bit confused on how the netconf and confd will interact each other on the configuration changes…!  
Which api gets called during GET and SET through netconf.  
Please give an explanation with your dhcpd example under 1-2-3-start-query-model.

---

<div class="post-metadata">

**Author:** ![cohult](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/cohult/32/221_2.png) [@cohult](https://dmap-community.ductus.global/u/cohult)\
**Post date:** [September 4, 2015, 7:51am UTC](https://dmap-community.ductus.global/t/how-confd-interacts-with-the-application/191/2 "2015-09-04T07:51:24Z")

</div>

In the 1-2-3-start-query-model example all data is configuration data, i.e. no operational data (config false) is defined in the YANG data model. Hence, a `NETCONF <GET>` will not trigger the application in this example.

The setup is something like this:

```
+-------------+                      
| NETCONF/CLI | ConfD Compiler
| view | <---------------------
+-------------+ |
      | +----------+ 
      | 1-1 mapping | YANG |
      | | model |  
+------------+ +----------+ 
| CDB | ConfD Compiler |
| data store | <---------------------
+------------+
      |
      | CDB subscribe/read
      |
    +------------+
 +-------------| |
 | application |-+
 +-------------+

```

When performing a `NETCONF <GET>` running the 1-2-3 example, e.g. typing  
`$ netconf-console cmd-get-all.xml`  
we will retrieve the example configuration data (if you have set any) and ConfD status data from CDB. No data will be retrieved from the application in this example. All data is read from the ConfD Configuration DataBase (CDB).

Writing configuration, for example when you perform a `NETCONF <SET>` running this example, e.g. by typing  
`$ netconf-console cmd-set-dhcp-defaultLeaseTime-1h.xml`  
will trigger the example application since it registered as a subscriber for all configuration changes under the `/dhcp` path (see `dhcpd.yang`).

So, again, the data is set through a `NETCONF <SET>` transaction that writes the configuration data to the CDB running datastore. As part of the transaction when the data has been committed to CDB, ConfD will notify applications that are subscribing for this configuration update

Below a short summary on how the application registers as a subscriber and handle subscription notifications, taken from `dhcpd_conf.c` in the 1-2-3 example:

```
confd_init(); /* initialize the ConfD library */
socket(); /* create a new communication socket */
cdb_connect() /* connect the socket to ConfD for subscribing to configuration changes */
cdb_subscribe() /* register for subscribing to /dhcpd configuration changes */
cdb_subscribe_done() /* tell ConfD that we are ready to receive configuration change notifications */
... /* Now we start polling the socket for subscription update notifications */
cdb_read_subscription_socket() /* When the data arrive on the socket we read it to find out if we got an event matching our subscription */

socket(); /* create a new communication socket */
cdb_connect() /* connect the socket to ConfD for reading data */
cdb_start_session() /* start a session towards the ConfD CDB running configuration datastore */
cdb_set_namespace(() /* set the namespace of the data we want to read, here dhcpd */  
cdb_get_* (), cdb_num_instances(), cdb_pushd(), cdb_popd(), cdb_exists() ... /* we read the configuration data from CDB running datastore */
cdb_close() /* we close the read CDB running config data socket */
cdb_sync_subscription_socket() /* We tell ConfD over the subscription socket that our subscriber is done reading the updated configuration */
/* Here we go back to polling for configuration updates */

```

Checkout `$CONFD_DIR/examples.confd/cdb_subscription/iter_c` for what is, for most application use-cases, the most effective way of reading subscription data after configuration change notifications.

Checkout `$CONFD_DIR/examples.confd/intro/5-c_stats` or `7-c_actions` for intro examples on how the application can provide statistics and execute actions triggered by for example `NETCONF <GET>` and `<ACTION>` RPCs.

Also, don’t forget to checkout the README files that comes with the examples. They give you a good overview of what’s going on in the examples.