The short answer
The engine does not arbitrate between "full resend" and "delta against an old baseline" at the moment it notices the client is stale. The decision is made implicitly by the acknowledgement window: the server keeps a bounded ring of recent snapshots per client and can only delta-encode against a baseline that still exists in that window. If the client's last acknowledged tick maps to a snapshot the server still holds, the server sends a delta against it. If the acknowledged tick has aged out of the window — or the client acknowledges nothing at all — there is no valid baseline to diff against, so the server is forced to send a full (non-delta) snapshot. Baseline recovery is therefore not a negotiation; it is a fallback triggered by baseline expiry.
What is confirmed vs. what is likely
Confirmed mechanics (well-established across Source-style networking):
- Clients acknowledge the most recent snapshot tick they received; the server tracks this per client.
- Delta compression requires both sides to hold the same baseline state. The server can only reference snapshots it has retained.
- The retention window is finite (on the order of a small number of snapshots, tied to tick rate and update rate). A client that stalls for longer than that window loses its usable baseline.
- When no valid baseline exists, the server sends a full update so the client can rebuild its entity state from scratch and resume acknowledging normally.
Likely, but version-sensitive: the exact window size, how aggressively expired baselines are dropped, and whether any intermediate "re-baseline against an older ack" path exists differ between GoldSrc, Source, and Source 2. Treat any claim about a specific title's internal thresholds as unverified unless you confirm it against that title's available SDK or engine code.
Why a delta against a very old ack is not used
Even if the server theoretically remembered an ancient baseline, delta-encoding against it is a bad trade: the delta would approach the size of a full snapshot anyway, every intermediate packet the client missed would be unaccounted for, and reliable-event ordering assumptions baked into the delta chain would no longer hold. A full snapshot is both simpler and usually no larger, so engines treat "baseline too old" and "baseline missing" as the same case: full resend, then resume delta compression once the client acknowledges the fresh baseline.
What this means for prediction reconciliation
On the client, a full snapshot after a partition forces a hard resynchronization: predicted state is discarded where it conflicts with authoritative state, and the client re-baselines its prediction history at the new tick. This is why players experience a visible "snap" after a prolonged stall — it is the full-resend path executing, not a separate recovery mode.
How to verify the behavior yourself
- Run a local listen server with net graph / net show-style diagnostics enabled for your title and observe the client's acknowledged tick versus the server's current tick.
- Simulate a stall (firewall drop, debugger pause, or packet-loss tool) longer than the snapshot window, then restore connectivity.
- Watch the first post-stall update: a full (uncompressed baseline) update is significantly larger than the steady-state deltas and is followed by normal-sized deltas once the client acks the new baseline.
- Repeat at shorter stalls to find the approximate window boundary for your title and tick rate.
One caveat: if you need the exact window constants or per-title thresholds, that is the missing detail worth pinning down — it changes only the tuning numbers, not the recovery rule itself.
sourceengine