Configuration and Concurrency EN

English · 简体中文

Configuration and high concurrency

Keep the application reading and bound pending work first. Then evaluate MTU, socket sharding and batching. The defaults do not enable every throughput option.

MTU

let mut listener = RaknetListener::bind_with_maximum_mtu(&address, 1428).await?;
listener.listen().await;
let socket = RaknetSocket::connect_with_version_and_mtu(&address, 11, 1428).await?;
println!("Negotiated MTU: {}", socket.mtu());

This fragment shows server and client configuration; see the quick start for imports. The default nominal MTU is 1,400 B, allowed values are 61–1,492 B, and offline negotiation chooses the smaller endpoint limit. Nominal MTU reserves 28 B for IPv4/UDP headers. It is not the UDP payload size or path MTU discovery. Account for extra IPv6, VPN and tunnel headers.

Receive socket sharding (Linux)

use std::num::NonZeroUsize;
use rust_raknet::{RaknetListener, error::Result};

async fn make_listener() -> Result<RaknetListener> {
    let address = "127.0.0.1:19132".parse().unwrap();
    let mut listener = RaknetListener::bind_with_socket_shards(
        &address, NonZeroUsize::new(4).unwrap(),
    ).await?.with_accept_backlog(NonZeroUsize::new(512).unwrap());
    listener.listen().await;
    Ok(listener)
}

Linux SO_REUSEPORT distributes peer flows across receive sockets. Shards share the GUID, MOTD and pending accept queue and close as one listener. The shard count is 1–64, fixed for the listener's lifetime. The default is one. Provide enough runtime workers, for example four Tokio workers for four shards.

Sharding does not spread one hot connection across every core or guarantee perfectly even flow distribution. Upstream connections or application processing can still limit a proxy after improving frontend reception.

Buffers and backlog

bind() requests a 2 MiB UDP receive buffer; the OS may clamp it. bind_with_receive_buffer_size(&address, NonZeroUsize) requests a different size. from_std() preserves the supplied standard socket's settings. These APIs change only their sockets, not system limits.

The default accept backlog is 128. Set with_accept_backlog() before listen(); offline handshakes retry when the queue is full. This is not a maximum active-session count. Applications must track and manage an active connection limit themselves.

Two options disabled by default

Option	Behavior	What to evaluate
with_receive_batching(true) (Linux)	Receive up to 16 ready datagrams per call, without waiting to fill a batch	Busy throughput and sparse latency separately
with_idle_maintenance(true)	Pause periodic maintenance after 500 ms of quiet traffic and empty queues; resume on new work	Idle CPU, wake-up latency and busy workloads

These builder methods return Self; chain them before listen(). Existing clients can toggle idle maintenance with socket.set_idle_maintenance(true). Neither option was enabled in the current README benchmarks.

Optional send policy

The send policy guide documents configurable frame/byte flight limits, separate reliable/unreliable budgets and byte-based scheduling. It is an opt-in feature included in 1.1.0; default builds retain the original path. Evaluate its throughput and slow-message latency using both measured API modes.

See where to set options and choosing limits for client, accepted-server and proxy examples.

Application scheduling

1. Keep the accept loop responsive and process sessions in separate tasks.
2. Run both proxy directions concurrently so one blocked send does not stop reverse reception.
3. Bound uninterrupted work so other connections get scheduled; the proxy example yields after processing eight messages.
4. Budget application queues, connection setup and shutdown. Unbounded task counts hide overload rather than solving it.
5. Test connection distribution, idle ratios and slow receivers, not just more active echo connections.

Queue and receive limits · Concurrency evaluation · Listener source

Recovery policy · Complete configuration reference

Blocking API · API index · Errors and deadlines