Nothing. Generally speaking, it is up to the application to detect that the connection to ConfD is closed (for whatever reason), and do one of
Terminate (as shown in the example for
confd_fd_ready() in the
confd_lib_dp(3) man page), with the assumption that it will be started again by some kind of process manager.
Close all sockets, if using the DP API call
confd_release_daemon(), and redo all initialization towards ConfD “from scratch”.
A demonstration of alternative 2 can be found in the
intro/9-c_threads example in the release.
Detecting the connection close is typically straightforward for a DP daemon that implements callbacks, since it will have the control and worker sockets in its
poll() will report a socket as “ready” when the connection is closed, and the subsequent call of
confd_fd_ready() will return
Of course a daemon that only does notification sending, and relies on ConfD’s builtin replay store, doesn’t have any callbacks - but it can use the same technique to detect connection close: use
poll() for e.g. the control socket, and since no callbacks will be invoked,
poll() reporting the socket as “ready” implies that the connection has been closed. The
notifier_builtin_replay_store.c program in the
netconf_notifications example uses this technique - it actually calls
confd_fd_ready(), which is also fine and perhaps clearer, even though the only possible outcome is that it returns
Per above, nothing happens “automatically” with the notification context as such when the connection is closed, but of course it holds the socket file descriptor provided via the
confd_register_notification_stream() call, and this socket can no longer be used for sending notifications to ConfD. If it is attempted anyway,
confd_notification_send() will fail with
CONFD_EOF - though the OS socket API doesn’t report the problem until (at least) the second attempt to write to the socket, and thus
confd_notification_send() will also not fail until the second call after the connection close.
In any case, this is an alternative way to detect the connection close if the control socket isn’t poll()ed. Note though that all notification contexts for a daemon are released by a call to
confd_release_daemon() - i.e. after that call, all pointers to notifications contexts are invalid, and a call of
confd_notification_send() with such a pointer is likely to result in a crash.
The registration will be “active” as long as the connection isn’t closed, i.e. provided that the connection close is detected and handled per above, such a check isn’t really necessary. To be “super-safe”, the
confd_notification_flush() function could perhaps be used, but it defeats the purpose of the notification sending being asynchronous from application to ConfD - i.e. the round-trips will limit the rate at which notifications can be sent.