From c04bbc8781b69fd3aee59c1ee03c37dd4a1403cf Mon Sep 17 00:00:00 2001 From: tv Date: Mon, 9 Nov 2026 04:21:12 +0000 Subject: paths: PINGs of a path take turns with the peer's The node's keepalives take turns between the two sides (`PeerState::keepalive_due_at`), but the paths layer pinged every path in use every `probe_every` (the keepalive interval, 30 s at least) whatever the peer did: a PING from the peer over the path didn't count. So both sides pinged each path every interval, often within a second of each other (seen on the dashboard: a PING answered, and our own PING right after it). Now a PING from the peer over a path is noted (`PathState::peer_probe`), and a path is pinged again (`rested`) an interval after the peer's PING, if that came last; after ours, an interval and a half while the peer pings too (its PING within two intervals before ours), so its turn comes first; else an interval. One exchange per interval goes over a path, as the measurements' "two keepalives per neighbour per interval" says, and each side measures every other interval; a shorter `--keepalive` measures more often. A path whose way out broke while the peer's PINGs still come in is found by our own PINGs half as often; a failed send or unanswered traffic (`suspect`) still pings at once. --- docs/glossary.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'docs/glossary.md') diff --git a/docs/glossary.md b/docs/glossary.md index 644279e..e8ccdee 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -93,7 +93,9 @@ is passed over for the next. (`--keepalive`): a PING and its PONG, and every third time a **STATUS** and its STATUS_REPLY instead, carrying the sender's heads (or a digest of them and some of them), epoch and readiness. The two sides of a pair take turns; the one that **leads** -the pair sends the first. +the pair sends the first. The paths layer's PINGs of a path take turns with the peer's +too, so each side measures a path's round trip every other interval: a shorter +`--keepalive` measures more often. **initial sync**: a joining node's first complete sync. It's **caught up** once a ready peer with non-empty heads has nothing left that it lacks. -- cgit v1.3.1