Reconnect backoff: compare synchronized and jittered retries

Exact computed state

Retry only when its scheduled time arrives

Every client makes an immediate attempt at time zero. Failed attempts schedule another attempt using an exponentially growing upper bound: the initial bound, twice that bound, four times, and so on, limited by the maximum. Without jitter, the delay equals that bound. With full jitter, a seeded value selects an integer delay below the bound, with a one-millisecond minimum to keep this finite teaching scheduler advancing. An attempt succeeds only when its timestamp is at or after the configured server-recovery time. Recovery itself does not wake clients or bypass their waiting period.

Choose the clients and delay policy

Initial retry bound sets the first post-failure delay limit, and Maximum retry bound caps later limits. Server recovery time fixes when the synthetic server starts accepting attempts. Number of clients creates between one and twelve independent retry schedules. Deterministic jitter seed reproduces the same delay choices; it changes timing only when jitter is enabled. Use full jitter switches between sampled and fixed delays. Every parameter change rebuilds the complete record and pauses at the beginning. Client rows show actual attempt timestamps, with red failures and green successful connections; the shaded region begins when the server recovers.

Compare alignment and recovery latency

Disable jitter, select one client, initial bound one thousand milliseconds, cap sixteen thousand and recovery twelve thousand. Attempts occur at zero, one, three, seven and fifteen seconds, with success at fifteen. The client waits three seconds after the server recovers because its next retry was already scheduled. Increase the client count to eight; without jitter all eight follow the same timestamps. Enable jitter and compare the spread using the same recovery instant. Use recovery zero to verify that every client connects on its initial attempt with no scheduled retry. Reducing the cap can create more frequent attempts during a long outage, so a shorter delay is not automatically a better policy.

Interpret the plotted count carefully

Play reveals the record over sixty inspection seconds, not sixty seconds of network time. Pause holds the state; Step advances one inspection second; Restart rewinds; Speed changes playback; Inspect time scrubs the computed record. Restore defaults resets every input. The readable result reports observed attempts and the peak count within fixed one-second bins, including the synchronized initial attempts. It is not an estimate of server capacity, and bin boundaries can change apparent clustering. Exact timestamps and per-attempt bounds remain available in the inspector. Requests are assumed instantaneous and always succeed after recovery. The model omits connection timeout duration, retry budgets, rate limits, authentication failures and production randomness. A fixed seed supports comparisons; it is not suitable as a production jitter generator.