Customizable client side TCP keepalives and session monitoring thread

CMakeLists.txt

@@ -58,15 +58,15 @@ set(CMAKE_MACOSX_RPATH TRUE)
 # micro version is changed with a set of small changes or bugfixes anywhere in the project.
 set(LIBNETCONF2_MAJOR_VERSION 3)
 set(LIBNETCONF2_MINOR_VERSION 5)
-set(LIBNETCONF2_MICRO_VERSION 1)
+set(LIBNETCONF2_MICRO_VERSION 2)
 set(LIBNETCONF2_VERSION ${LIBNETCONF2_MAJOR_VERSION}.${LIBNETCONF2_MINOR_VERSION}.${LIBNETCONF2_MICRO_VERSION})
 
 # Version of the library
 # Major version is changed with every backward non-compatible API/ABI change in libyang, minor version changes
 # with backward compatible change and micro version is connected with any internal change of the library.
 set(LIBNETCONF2_MAJOR_SOVERSION 4)
 set(LIBNETCONF2_MINOR_SOVERSION 4)
-set(LIBNETCONF2_MICRO_SOVERSION 1)
+set(LIBNETCONF2_MICRO_SOVERSION 2)
 set(LIBNETCONF2_SOVERSION_FULL ${LIBNETCONF2_MAJOR_SOVERSION}.${LIBNETCONF2_MINOR_SOVERSION}.${LIBNETCONF2_MICRO_SOVERSION})
 set(LIBNETCONF2_SOVERSION ${LIBNETCONF2_MAJOR_SOVERSION})
 

FAQ.md

@@ -65,3 +65,13 @@ __A:__ No, it is not possible. There are currently 2 main types of certificates
    which is extracted from the certificate, is sent to the server instead of the whole certificate.
    This means that the `cert-to-name` process required by *NETCONF* can not take place. Specifically,
    OpenSSH certificates are missing important fields such as `Common Name`, `Subject Alternative Name` and so on.
+
+__Q: I have client-side keepalives and monitoring enabled, but it takes a long time for the client to detect that the connection was terminated:__
+__A:__ Assuming that the network connection is fine or is loopback, then this is the standard TCP behavior.
+   The client will not immediately detect that the connection was terminated unless
+   it tries to send some data or unless a specific timeout occurs.
+
+   Even though the server was terminated, its socket remains in a lingering state for some time and continues to reply to incoming
+   TCP keepalive packets. In particular, this timeout you're encountering is most likely affected by the `tcp_fin_timeout` kernel parameter,
+   which controls how long the TCP stack waits before timing out a half-closed connection after receiving a FIN packet.
+   The default value is typically 60 seconds, but it can be configured based on your needs.

src/session.c

@@ -857,6 +857,13 @@ nc_session_free(struct nc_session *session, void (*data_free)(void *))
         return;
     }
 
+    if (session->side == NC_CLIENT) {
+        if (session->flags & NC_SESSION_CLIENT_MONITORED) {
+            /* remove the session from the monitored list */
+            nc_client_monitoring_session_stop(session, 1);
+        }
+    }
+
     /* stop notification threads if any */
     if ((session->side == NC_CLIENT) && ATOMIC_LOAD_RELAXED(session->opts.client.ntf_thread_running)) {
         /* let the threads know they should quit */