peerdb/peers.in, svc/connect.8.in: Tweak dead-peer-detection parameters.

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.

diff --git a/peerdb/peers.in b/peerdb/peers.in
index 53eef5b..b170157 100644 (file)
--- a/peerdb/peers.in
+++ b/peerdb/peers.in
@@ -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 --------------------------------------------------

diff --git a/svc/connect.8.in b/svc/connect.8.in
index 7021c6b..f06c1a2 100644 (file)
--- a/svc/connect.8.in
+++ b/svc/connect.8.in
@@ -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