summaryrefslogtreecommitdiff
path: root/src/devices/nm-device.h
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2018-02-20 21:41:14 +0100
committerThomas Haller <thaller@redhat.com>2018-04-10 15:11:23 +0200
commit0a62a0e9039e49e05dae6af9a96c381629bccd58 (patch)
tree6a02f0caf28a33b5f7ed6678ed200e244ae29c2b /src/devices/nm-device.h
parente8e0ef6300526ab64eaba534c6b22b23631cf8a9 (diff)
connectivity: schedule connectivity timers per-device and probe for short outages
It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
Diffstat (limited to 'src/devices/nm-device.h')
-rw-r--r--src/devices/nm-device.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/src/devices/nm-device.h b/src/devices/nm-device.h
index 24d184657f..fd266d69ab 100644
--- a/src/devices/nm-device.h
+++ b/src/devices/nm-device.h
@@ -783,6 +783,8 @@ typedef void (*NMDeviceConnectivityCallback) (NMDevice *self,
GError *error,
gpointer user_data);
+void nm_device_check_connectivity_update_interval (NMDevice *self);
+
NMDeviceConnectivityHandle *nm_device_check_connectivity (NMDevice *self,
NMDeviceConnectivityCallback callback,
gpointer user_data);