chiark / gitweb /
peerdb/peers.in, svc/connect.8.in: Tweak dead-peer-detection parameters.
authorMark Wooding <mdw@distorted.org.uk>
Mon, 22 Dec 2014 20:32:58 +0000 (20:32 +0000)
committerMark Wooding <mdw@distorted.org.uk>
Fri, 8 May 2015 18:26:46 +0000 (19:26 +0100)
They're now different between dynamic and passive peers.  The manual
explains why they're set the way they are and provides some vaguely
useful commentary.

Also rearrange the other parameters a bit, now that we have multiple
inheritance.

peerdb/peers.in
svc/connect.8.in

index 53eef5b..b170157 100644 (file)
@@ -34,16 +34,6 @@ ifname = vpn-$(name)
 ;; script is good for Linux hosts.
 ifup = /usr/sbin/tripe-ifup
 
-;; every: interval for checking that this connection is alive.
-every = 2m
-
-;; timeout: how long to wait for a ping response before giving up.
-timeout = 10s
-
-;; retries: how many ping attempts to make before declaring the connection
-;; dead.
-retries = 5
-
 ;;;--------------------------------------------------------------------------
 ;;; Active-peers defaults.
 ;;;
@@ -68,13 +58,31 @@ host = override-me
 peer = INET $[$(host)] $(port)
 
 ;;;--------------------------------------------------------------------------
+;;; Temporary association defaults.
+;;;
+;;; These are settings common to both dynamic and passive peers.
+
+[@WATCH]
+@inherit = @GLOBAL
+
+;; watch: whether to watch this connection and drop it if it dies.
+watch = t
+
+;; timeout: how long to wait for a ping response before giving up.
+timeout = 10s
+
+;; retries: how many ping attempts to make before declaring the connection
+;; dead.
+retries = 5
+
+;;;--------------------------------------------------------------------------
 ;;; Dynamic-peers defaults.
 ;;;
 ;;; The parameters here affect peers to whom dynamic connections are made.
 ;;; The user and connect parameters probably need customizing.
 
 [@DYNAMIC]
-@inherit = @ACTIVE
+@inherit = @ACTIVE, @WATCH
 
 ;; cork: whether to wait for a key-exchange packet from the peer before
 ;; sending one of our own.
@@ -94,8 +102,8 @@ disconnect = ssh -q $(ssh-user)@$[$(host)] goodbye
 ;; least in the minds of intermediate stateful firewalls and NAT routers.
 keepalive = 2m
 
-;; watch: whether to watch this connection and retry it if it drops.
-watch = t
+;; every: interval for checking that this connection is alive.
+every = 30s
 
 ;;;--------------------------------------------------------------------------
 ;;; Passive-peers defaults.
@@ -105,7 +113,7 @@ watch = t
 ;;; of the parameters and these defaults are probably pretty good.
 
 [@PASSIVE]
-@inherit = @GLOBAL
+@inherit = @GLOBAL, @WATCH
 
 ;; peer: mark this entry as being a passive peer.
 peer = PASSIVE
@@ -118,7 +126,8 @@ mobile = t
 ;; the CONNECT service.
 user = $(name)
 
-;; watch: whether to watch this connection and drop it if it dies.
-watch = t
+;; every: interval for checking that this connection is alive: should be at
+;; least twice as long as the dynamic peer interval.
+every = 5m
 
 ;;;----- That's all, folks --------------------------------------------------
index 7021c6b..f06c1a2 100644 (file)
@@ -370,7 +370,30 @@ The parameters are as follows.
 .TP
 .B every
 A time interval: how often to ping the peer to ensure that it's still
-alive.  The default is 2 minutes.
+alive.  The default is 30 seconds for active dynamic peers, and 5
+minutes for passive peers.
+.IP
+The period for dynamic peers should be no longer than
+.I timeout
+\(mu
+.RI ( retries
+\- 1).  Consider an idle mobile peer which has its IP address changed
+just before its passive peer begins pinging.  The static peer's pings
+will go to the old address until it receives a ping back from the mobile
+peer.  Therefore, the static peer has to keep pinging until it would
+definitely have received an unsolicited ping from the mobile peer, and
+therefore be informed of the change of address.  And it's no use
+learning about the change of address just after sending the last ping to
+the old address, so the last retry doesn't count for the purposes of
+this calculation.
+.IP
+Besides, the consequences of failed pinging differ between dynamic and
+passive peers.  In the former case, a failure provokes a reconnection
+attempt, after which (hopefully) things will work again: it's probably a
+good thing to check frequently and fail fast.  In the latter case, the
+dynamic peer will certainly have to notice that it's been abandoned and
+arrange to retry, causing a communication failure where maybe there
+wasn't really one before.
 .TP
 .B timeout
 A time interval: how long to wait for a reply before retrying or giving