connections

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 when the pool has zero live connections. 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 immediately when the pool has zero live connections. 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. Radiator immediately selects the first idle connection. If every connection is busy, it selects the first connection with the lowest load. 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.

Related

• Backend Load Balancing - Server selection, pool management, and unreachable-server detection