+Adopted peers are pinged at regular intervals (using the
+.B PING
+administrative command; see
+.BR tripe-admin (5)).
+This process can be configured by assigning values to keys in the peer's
+database record. Some of these parameters are time intervals,
+expressed as a nonnegative integer followed optionally by
+.BR d ,
+.BR h ,
+.BR m ,
+or
+.B s
+for days, hours, minutes, or seconds, respectively; if no suffix is
+given, seconds are assumed.
+.PP
+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 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
+up. The default is 10 seconds.
+.TP
+.B retries
+An integer: how many failed attempts to make before deciding that the
+peer is unreachable and taking action. The default is 5 attempts.
+.PP
+The algorithm is as follows. Send up to
+.I retries
+pings; if a reply is received before the
+.I timeout
+then the peer is alive; wait
+.I every
+and check again. If no reply is received within the
+.IR timeout ,
+then try again up to
+.I retries
+times. If no attempt succeeds, the peer is declared unreachable. If
+the peer has a
+.B connect
+command (i.e., it connects dynamically) then another connection attempt
+is made. Otherwise the peer is killed.