A Decision Is Expensive; Remembering It Is Not
The last two lessons built a careful decision: read the peer's identity over the tailnet, read this Mac's interfaces, ask the routing table about every advertised address, sort what survives, and send a real health request down each candidate until one answers. That is the right way to decide. It is also far too slow to do before every request. A Loomis grid asks for 384 thumbnails in a burst, and a sync lists thousands of files; nobody wants three subprocesses and a probe in front of each one.
So Delta remembers. RouteBook keeps one chosen Route per peer, with the time it was chosen and the reason it was chosen in a sentence. The interesting part is not that it caches, but how long each kind of belief is allowed to live, and what makes it die early.
Three Clocks
| Belief | Lives | Why that long |
|---|---|---|
| The chosen route | 60 s | Long enough that a burst rides one decision, short enough that the network's real state wins within a minute |
| A LAN route is still on-link | re-proved every 10 s | A pulled cable or a laptop carried out the door is noticed within ten seconds |
| This Mac's interfaces | 10 s memo | Three subprocesses per read; re-read no faster than anything can physically change |
When a kept LAN route is older than ten seconds since its last proof, get does not re-run the whole decision. It asks one cheap question: does route -n get on the route's address still name the same interface, with no gateway? If yes, the proof is renewed and the route is returned. If no, the full selection runs again. A tailnet route is not re-proved at all within its minute: being away is the safe answer, and there is nothing cheap to check.
The Asymmetry Is Deliberate
Walk through a laptop's day. At the desk, its route to the service host is Thunderbolt. The owner unplugs and walks out. Within ten seconds the next request finds the bridge no longer on-link, selects again, finds no on-link address at all, and switches to the tailnet with the reason away: no address of the peer is on-link with an active physical interface here. If a request happens to be in flight when the cable comes out, it fails, and the failure drops the route at once (next lesson); the ten seconds are a ceiling, not a delay.
Coming home is slower. The kept tailnet route lives out its full minute before anything re-examines it, so for up to sixty seconds the laptop keeps using the tunnel while a cable sits right there. That is the right side to be wrong on. Using the slow road for a minute costs time; using a fast road that has gone away costs a timeout on every request and, on a foreign network, dials a stranger. When the owner wants the fast road now, delta route @pippa --refresh forgets the kept choice and decides again on the spot.
One Decision Per Peer, Shared
Selection takes a lock per peer, so when 384 thumbnail requests arrive at the same instant on a cold book, one of them does the identity read and the probes while the other 383 wait on the lock, then all find the fresh route and go. Without that lock, a burst would probe the peer hundreds of times in parallel, which is exactly the kind of connection storm that broke SSH in the first place (track 1). Different peers have different locks, so a slow decision about one Mac never blocks requests to another.
Overrides, and a Question That Never Waits
Two escape hatches sit in front of the clocks. DELTA_FORCE_ROUTE, or a routes entry in this Mac's own host config, can pin a peer to the tailnet: that is how the bench measures the away road from inside the house. And the CLI's --tailnet flag does the same for a single command. A peer that is this Mac never reaches the book at all: it is local, with no network. Finally, known(peer) answers "which route is in use?" without choosing: a reply served from the cache names its route in a header, and that header must never wait on a probe or on an eight-second connect to a Mac that is asleep.
The Book Keeps Its Own History
A route book that only knew the current answer would be useless the morning after something went wrong. Delta's keeps a second map beside the routes: failures, the last reason each peer's LAN route was dropped or each candidate failed its probe. delta status prints every kept route with its kind, address and reason, and the full health document carries both maps. So the question "why has the laptop been on the tunnel all afternoon?" has an answer written down at the moment it happened, in the words of the check that failed.