retry
Shared retransmission policy for the sync and async RADIUS clients.
RADIUS retransmission timing is left to the implementation by RFC 5080
§2.2.1; both clients historically used a flat, jitter-free schedule
(timeout seconds between every retry). RetryPolicy keeps that
schedule as its default but lets a caller layer exponential backoff and
jitter on top — the same object is consumed by Client (sync) and
ClientAsync.
RetryPolicy
dataclass
How long a client waits between retransmissions.
Attributes:
| Name | Type | Description |
|---|---|---|
retries |
int
|
Maximum number of retransmissions before giving up. The
initial send is not counted — |
timeout |
float
|
Base wait, in seconds, before the first retry. |
backoff |
float
|
Multiplicative growth applied per retry. |
jitter |
float
|
Fractional uniform noise applied to each computed wait,
sampled from |
max_wait |
float
|
Hard ceiling, in seconds, on any single wait. Prevents a high backoff from producing pathologically long waits. |
Source code in pyrad2/retry.py
wait_for(attempt)
Return the wait, in seconds, before retry number attempt.
attempt is the count of retries already performed for this
request — 0 is the wait between the initial send and the
first retry, 1 is the wait between the first and second
retry, and so on.
Source code in pyrad2/retry.py
policy_from_legacy(retry_policy, retries, timeout)
Resolve constructor arguments into a single RetryPolicy.
Bridges the historical retries= / timeout= keyword pair with
the newer retry_policy= argument so both clients can share one
code path. An explicit retry_policy always wins; otherwise a
flat (no backoff, no jitter) policy is built from the legacy args.