Reliability Modes EN

English · 简体中文

Five reliability modes

Reliability, ordering and replacement of stale state are separate choices. Define your message's meaning first, then choose its delivery mode.

Mode	Retransmission	Delivery semantics	Typical use
Unreliable	None	Best effort; loss and reordering are possible	Disposable sound effects, short visual effects, independent samples
UnreliableSequenced	None	Sequence filtering drops outdated messages	Frequent position snapshots, orientation, cursor position
Reliable	Until acknowledged	Reliable, without delivery ordering	Independent events and tasks identified by ID
ReliableOrdered	Until acknowledged	Send order within a channel	Command sequences, chat, state deltas, large messages
ReliableSequenced	Until acknowledged	Reliable frames with sequence filtering; stale state may be skipped	Complete state updates that replace earlier values

Reliable delivery requires a live connection. Handle failures when the connection closes. The word “reliable” in ReliableSequenced does not mean the application receives every historical update.

Unreliable: losing one is acceptable

A brief spark effect is an independent presentation event; missing it does not invalidate the next frame. Inventory changes, payments and required operations do not belong here.

UnreliableSequenced: do not restore an old position

Suppose complete position snapshots A, B and C are sent. If C arrives first, a late older snapshot should not move the character backwards. If C is lost, this mode does not recover it; the application usually keeps sending new updates.

Use self-contained snapshots. If B means “add 1 to A,” skipping an earlier delta can corrupt state.

Reliable: events must arrive, but order does not matter

Use this for independent resource notifications or task results. IDs let the application associate out-of-order results with requests. If the second operation depends on the first, choose ReliableOrdered or explicitly manage dependencies.

A transport acknowledgement is not a committed transaction. Business retries after reconnecting still need request IDs and application-level deduplication.

ReliableOrdered: order carries meaning

Examples include “create object → modify object → delete object,” chat history and delta synchronization. Later messages may wait for a missing earlier message: head-of-line blocking within that channel.

Use different channels for independent ordered flows:

socket.send_with_order_channel(&chat, Reliability::ReliableOrdered, 0).await?;
socket.send_with_order_channel(&world_update, Reliability::ReliableOrdered, 1).await?;

This is a sending fragment; both chat and world_update must begin with 0xfe. There is no ordering guarantee across channels. Channels share the connection window, CPU, socket and bandwidth; they are not isolated connections. Check channel limits when interoperating with other implementations; this example uses 0 and 1. Sequenced and ordered modes involve state in the same channel. Prefer separate channels for independent flows and verify mixed-mode peer behavior.

ReliableSequenced: the updated state matters

Use it for occasional configuration snapshots or an object's current target. Unacknowledged frames are retransmitted, but the receiver may skip outdated state. Do not use it for commands that must all execute or for a chain of deltas. Choose Reliable or ReliableOrdered when every message must be handled.

Large messages

Only ReliableOrdered automatically fragments in the current outgoing path. The other four modes return PacketSizeExceedMTU when a message exceeds their single-frame limit; they do not switch modes automatically.

The current implementation computes the application payload threshold as negotiated MTU minus 60 B. With the default nominal MTU of 1,400 B, that is 1,340 B, including the application's 0xfe byte. This is this implementation's threshold, not a universal RakNet limit.

For large snapshots, use ordered delivery or design application chunks with IDs, integrity checks, bounded reassembly and whole-snapshot replacement semantics. Treating each chunk as a replaceable sequenced update is not sufficient.

Message limits · Batching · Reliability source

For binary layouts, index semantics, fragmentation limits and retry algorithms, see the RakNet protocol reference.