Reliable and unreliable game messages: choose guarantees by meaning

Classify the consequence of loss

A transport's reliable mode retransmits missing data while a connection remains viable; unreliable delivery may lose messages. Ordering is a separate property that an API can combine with reliability. Choose guarantees according to message meaning: a newer complete position state may replace an older one, while a purchase request needs a definite accepted or rejected result. Neither category determines whether the server should trust its contents.

Separate packet acknowledgments from action results

Sequence numbers identify packets or messages within their defined stream. A packet acknowledgment says that transport data arrived; it does not prove the game validated or committed an action. Fiedler's protocol discussion also explains why missing acknowledgments create uncertainty and why repeated application data needs its own identity. [1]

Give important commands a scoped identifier and return an application result. If retries or reconnect recovery can repeat a command, retain its result for the supported retry window. Validate the request and record its effect and deduplication result consistently. A reliable socket alone does not provide exactly-once execution across crashes.

Worked example: old state and a repeated command

Suppose complete movement state 41 places an avatar at coordinate 8, and state 42 places it at coordinate 9. If 42 arrives before 41, a freshness-based receiver keeps coordinate 9 and discards the older state. This policy requires self-contained updates or a valid reconstruction baseline; discarding arbitrary deltas can break state reconstruction.

Separately, a client submits command 17 to collect an item. The server validates it, grants the item and records the result. If command 17 is retried because the application response was lost, the server returns that recorded result without granting another item. The command identifier and the movement sequence solve different problems and should not share accidental semantics.

Isolate ordering dependencies and budget traffic

Reliable ordered delivery can hold later messages behind a missing earlier message in the same stream. Valve's connection lanes let independent traffic avoid sharing that ordering dependency: reliable messages are ordered within a lane, with no corresponding guarantee across lanes. Never split causally dependent operations across lanes without explicit dependency handling. [2]

Keep transient state separate from bulk transfers where the transport supports it. Bound send queues, monitor message age and let congestion control pace traffic. Repeatedly enqueueing obsolete reliable states can create a growing delay even when eventual delivery works. Compact or replace unsent state only where its semantics permit.

Test the delivery contract

Inject loss, duplication, reordering and disconnects. Check stale-state rejection, command deduplication, queue limits and recovery after reconnecting. Define identifier scope, sequence wrap handling and how long results remain available. Reliability cannot make an expired command useful, authorize an invalid request or guarantee completion after a permanent disconnect. Expose pending, confirmed and failed outcomes to gameplay where those distinctions matter.

Sources

• [1] Reliability and Congestion Avoidance over UDP — Glenn Fiedler, Gaffer On Games.
• [2] GameNetworkingSockets Interface: Message Delivery and Connection Lanes — Valve Software, original API source.