[S] Change in openvpn[master]: oob: Measure probe RTT for candidate-band selection

Attention is currently required from: plaisthos.

Hello plaisthos, 

I'd like you to reexamine a change. Please visit

    http://gerrit.openvpn.net/c/openvpn/+/1748?usp=email

to look at the new patch set (#16).


Change subject: oob: Measure probe RTT for candidate-band selection
......................................................................

oob: Measure probe RTT for candidate-band selection

Record each probe's round-trip time (per-target send timestamp vs reply
arrival) and feed it to oob_rank_probe_results(), where RTT forms the
candidate band: responders within the effective margin of the fastest compete
on weight, slower ones fall behind. Log the measured RTT and the effective
margin (with its source: client or server-advertised) at verb 4.

Before this the client never measured RTT, so every responder sat in the band
and selection was purely weighted-random; with real measurements the
latency-based candidate selection takes effect.

Change-Id: I375a41749060b7d006647bc27002c55436c8a8bb
Signed-off-by: Lev Stipakov <[email protected]>
---
M doc/man-sections/client-options.rst
M src/openvpn/oob_client.c
2 files changed, 26 insertions(+), 5 deletions(-)


  git pull ssh://gerrit.openvpn.net:29418/openvpn refs/changes/48/1748/16

diff --git a/doc/man-sections/client-options.rst b/doc/man-sections/client-options.rst
index 82e7b22..8cf14f9 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -608,9 +608,14 @@
   remote, and each answering server replies with its advertised priority
   and weight. Remotes are then reordered following DNS SRV (RFC 2782)
   semantics: servers that answered are tried before those that did not,
-  grouped by priority (lowest first); within a priority group, servers are
-  picked by weighted-random selection. Round-trip time is not yet taken
-  into account, so ``max-latency-diff`` has no effect for now.
+  grouped by priority (lowest first); within a priority group, servers
+  whose measured round-trip time is within ``max-latency-diff``
+  milliseconds of the fastest one are picked by weighted-random
+  selection, the others follow in round-trip-time order. When
+  ``max-latency-diff`` is not given, the margin advertised by the
+  answering server applies; a server advertising :code:`0` asks to be
+  compared on latency alone, so only the fastest server of its priority
+  group is treated as best.
 
   The probe is currently sent without control-channel wrapping, so it only
   works against a server configured without ``--tls-auth``,
diff --git a/src/openvpn/oob_client.c b/src/openvpn/oob_client.c
index 4b8c576..9bdc8cf 100644
--- a/src/openvpn/oob_client.c
+++ b/src/openvpn/oob_client.c
@@ -56,6 +56,7 @@
     struct sockaddr_storage dest;
     socklen_t destlen;
     bool sent;
+    struct timeval sent_at; /* when the probe was sent, for RTT measurement */
 };
 
 /* The probe uses one native socket per address family, so every remote is probed
@@ -177,7 +178,13 @@
             && addr_port_match((const struct openvpn_sockaddr *)(const void *)from,
                                (const struct openvpn_sockaddr *)(const void *)&targets[i].dest))
         {
+            struct timeval rcv;
+            openvpn_gettimeofday(&rcv, NULL);
+            long ms = (long)(rcv.tv_sec - targets[i].sent_at.tv_sec) * 1000
+                      + (rcv.tv_usec - targets[i].sent_at.tv_usec) / 1000;
+
             results[i].responded = true;
+            results[i].rtt_ms = (ms > 0) ? (unsigned int)ms : 0;
             results[i].reply = reply;
             break;
         }
@@ -432,6 +439,7 @@
             }
             else
             {
+                openvpn_gettimeofday(&targets[i].sent_at, NULL);
                 targets[i].destlen = destlen;
                 targets[i].sent = true;
                 sent_count++;
@@ -454,8 +462,16 @@
         if (results[i].responded)
         {
             responded++;
-            msg(D_LOW, "server-probe: %s:%s answered (priority %d, weight %d)", ce->remote,
-                ce->remote_port, results[i].reply.priority, results[i].reply.weight);
+            /* Effective candidate-band margin and where it came from: the
+             * client's own setting wins, else the server's advertised value. */
+            int client_margin = c->options.server_probe_latency_margin;
+            int margin = oob_effective_margin(&results[i], client_margin);
+            const char *margin_src = client_margin >= 0 ? "client" : "server-advertised";
+            msg(D_LOW,
+                "server-probe: %s:%s answered (priority %d, weight %d, rtt %u ms;"
+                " latency margin %d ms [%s])",
+                ce->remote, ce->remote_port, results[i].reply.priority, results[i].reply.weight,
+                results[i].rtt_ms, margin, margin_src);
         }
         else
         {

-- 
To view, visit http://gerrit.openvpn.net/c/openvpn/+/1748?usp=email
To unsubscribe, or for help writing mail filters, visit http://gerrit.openvpn.net/settings?usp=email

Gerrit-MessageType: newpatchset
Gerrit-Project: openvpn
Gerrit-Branch: master
Gerrit-Change-Id: I375a41749060b7d006647bc27002c55436c8a8bb
Gerrit-Change-Number: 1748
Gerrit-PatchSet: 16
Gerrit-Owner: stipa <[email protected]>
Gerrit-Reviewer: plaisthos <[email protected]>
Gerrit-CC: openvpn-devel <[email protected]>
Gerrit-Attention: plaisthos <[email protected]>

_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel