chiark / gitweb /
polypath asymmetric routing: Handle data packet dupes
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Wed, 15 May 2019 20:40:40 +0000 (21:40 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 18 May 2019 01:16:37 +0000 (02:16 +0100)
If polypath has asymmetric routing, where path A upload is faster than
path B, but path A download is completely broken, then we need to
retain both paths A and B in our list of transport peers.

Stepping back, we need to treat dupes of recent packets as evidence
that the peer is at that address, even though we do not pass the
packets to the netlink.

We don't want to do this for arbitrarily old data packets.  The
heuristic we use here is rather crude: packets which are more than
32 (by default) out of order are treated as too old.  This will be too
short if path A is a high-bandwidth link and path B is quite slow, and
it will be too long if the link is very idle.  Hopefully this will not
matter in practice.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
site.c

diff --git a/site.c b/site.c
index acbc2b62c99b9ed43e48b43a3d473becfdd404c3..51465011d1b6e1aa7a688eeae70d52d72653e1dc 100644 (file)
--- a/site.c
+++ b/site.c
@@ -1158,6 +1158,14 @@ static bool_t process_msg0(struct site *st, struct buffer_if *msg0,
     transform_apply_return problem;
 
     problem = decrypt_msg0(st,msg0,src);
+    if (problem==transform_apply_seqdupe) {
+       /* We recently received another copy of this packet, maybe due
+        * to polypath.  That's not a problem; indeed, for the
+        * purposes of transport address management it is a success.
+        * But we don't want to process the packet. */
+       transport_data_msgok(st,src);
+       return False;
+    }
     if (problem)
        return False;