Radiator Server Documentation — v10.34.2

connections

Selection values accept both underscore and hyphen spellings. Prefer first_available and least_outstanding.

Use the connections { ... } block to configure the RADIUS backend server connection pool.

server "PRIMARY" {
    secret "mysecret";

    connections {
        max 10;
        min 1;
        window 256;
        idle_timeout 5m;
        selection least_outstanding;
    }

    connect { protocol tls; host "primary.example.com"; port 2083; tls { ... } }
}

Parameters

max

Maximum number of backend connections Radiator may keep open to the RADIUS backend server.

Radiator reuses existing live connections as long as they can still accept more requests. New connections are opened only when every current connection has reached its configured window and the pool is still below this limit. This setting controls the socket pool size, not a request count.

Default: 10.

min

Minimum number of connections to keep open.

Use min 1; or higher to keep warm connections ready and to enable fast skip. With a connectionless transport, opening a socket does not prove that the remote server is reachable. The reachability signal is therefore weaker than with a connection-oriented transport.

When min is greater than zero, Radiator opens connections to the backend server in the background immediately after startup and keeps the pool at this floor. For connection-oriented transports, this removes the first-request handshake cost and lets Radiator skip a server after a request confirms that it cannot be reached. With a connectionless transport, the warm-socket part still applies, but Radiator learns remote reachability from real requests or Status-Server checks.

The min value controls how many connection tasks and sockets are immediately available for parallel packet processing. A small min concentrates traffic on a small number of connections until their configured window is in use and the pool grows toward max. Increase min when the workload needs parallel transmission across multiple warm connections.

Default: 0.

The RADIUS warm-pool maintainer uses fixed internal pacing:

  • Connect attempt timeout: 5 seconds.
  • Retry interval: 1 second between attempts when the floor is not yet met.

These values are not configurable for RADIUS backends.

Known limitation: if min is very close to max, background reconnect attempts and request-triggered growth can briefly overshoot the configured max limit during recovery. A small floor such as 1 or 2 reduces this risk, but also limits warm connection-level parallelism.

window

Maximum number of requests that may be in flight on one backend connection. Valid values are 1 through 65535.

For a RADIUS/1.0 window above 256, Radiator adds a hop-by-hop Proxy-State value to correlate requests. The backend must return Proxy-State values unchanged and in order. Radiator removes its value before post-proxy processing. RADIUS/1.1 uses its 32-bit Token field.

Lower the window when the backend should not receive a large queue of concurrent work through one socket. Once every existing connection reaches the window, Radiator opens another connection up to max. With least_outstanding, the window also bounds each connection's share while work is spread across the pool.

The pool's theoretical in-flight capacity is max multiplied by window. Its immediately warm capacity is min multiplied by window.

Default: 256.

idle_timeout

Maximum idle lifetime for a backend connection.

This parameter accepts duration units. When no unit suffix is provided, the value is interpreted as seconds.

Default: none. Idle connections remain open until the server closes them.

selection

Controls how Radiator assigns requests to connections in this server's pool.

  • least_outstanding uses the connection with the fewest in-flight requests. When multiple connections have the same lowest load, Radiator Server rotates evenly among them. This also spreads sequential requests across idle connections. Use this value to spread traffic across warm backend connections.
  • first_available packs requests onto as few connections as their RADIUS identifier capacity permits. Use it with idle_timeout when keeping backend connections open is expensive and unused connections should close quickly.

Warning: first_available uses as few connections as their configured window allows. This packing can limit packet-processing parallelism even when the pool contains idle connections.

Default: least_outstanding.

This setting selects a connection inside one server block. The backend-level server_selection setting selects among multiple server blocks.

Context

Valid inside a RADIUS backend server block and inside a radius_dns_sd server_template block.

Constraints

min must not exceed max. window must be between 1 and 65535. Configuration parsing fails when either constraint is violated.