Skip to content

Send Thread

The Send Thread is responsible for transmitting state updates from the server to all connected clients.\ It operates independently from the game loop, ensuring that network output never blocks or delays gameplay simulation.

This thread handles serialization, packet construction, and UDP transmission based on the latest delta-state snapshot generated by the Game Loop Thread. It also broadcasts discrete event packets such as EntitySpawn, EntityDestroyed, and PlayerDisconnected to keep clients authoritative and consistent.

1. Responsibilities

The Send Thread manages outgoing network communication. Its tasks include:

  • Reading the most recent delta-state snapshot produced by the Game Loop Thread.
  • Serializing this snapshot into a compact binary format.
  • Constructing UDP packets following the server’s protocol specification.
  • Sending packets to all connected clients at a consistent rate.
  • Updating per-client sequence counters.
  • Managing bandwidth and throttling if necessary.

The Send Thread does not compute gameplay logic or modify ECS state.

2. Interaction with the Game Loop

The Game Loop produces a delta-state structure at the end of every simulation tick.\ This structure is placed into a shared buffer accessible by the Send Thread.

Key rules:

  • The Game Loop never waits for the Send Thread.
  • The Send Thread always uses the latest available snapshot.
  • Older snapshots may be discarded automatically.
  • Access to the snapshot buffer is synchronized to avoid race conditions, typically via double-buffering or a memory fence.

This decoupling ensures that slow clients or network congestion never impact simulation timing.

3. Snapshot Serialization

The Send Thread converts internal ECS data into compact binary packets.\ A typical snapshot contains:

  • Updated transforms (only if changed since last tick).
  • New entities created this frame.
  • Entities destroyed this frame.
  • Updated health values.
  • Missile creation or removal.
  • AI-triggered spawns or events.

Serialization rules depend on the protocol but typically include:

  • Fixed-size header containing message type, server tick index, and sequence ID.
  • Variable-size payload containing updates.
  • Delta-compression techniques to reduce bandwidth usage.

The Send Thread does not modify the snapshot; it only transforms it into network-ready packets.

4. UDP Transmission

The Send Thread handles all outgoing messages via the server’s UDP socket.\ Since UDP is connectionless:

  • Packets are sent independently to each client.
  • No delivery guarantee is assumed.
  • No acknowledgement is required at this stage.

The thread iterates over all connected clients and sends the serialized snapshot to each of them using their registered addresses.

A per-client sequence counter is incremented with each update, allowing clients to detect out-of-order or duplicated packets.

5. Non-Blocking Design

It is critical that outgoing communication does not interfere with gameplay.

The Send Thread must never:

  • Sleep excessively
  • Block on socket operations
  • Depend on the Receive Thread
  • Hold long locks on shared data
  • Wait for client acknowledgments

If a client becomes slow or unreachable, packets for that client may be skipped or rate-limited, but the simulation proceeds normally.

6. Error Handling

The thread is designed to continue functioning even in poor network conditions.\ Typical error cases include:

  • Client address no longer reachable
  • Packet construction failure
  • Temporary network congestion
  • Out-of-order transmissions on the client side

In all cases:

  • The Send Thread keeps running
  • The server simulation is unaffected
  • Clients are expected to recover or resynchronize using future snapshots

The Send Thread does not attempt to repair or resend old snapshots. That responsibility lies with the client-side prediction and reconciliation logic.

7. Summary

The Send Thread is the server’s dedicated output pipeline.\ It ensures that:

  • The simulation loop is never blocked by network operations.
  • All clients receive consistent, timely updates.
  • State snapshots are serialized efficiently and transmitted reliably via UDP.
  • Slow or unstable clients do not impact the authoritative simulation.

Its design maintains the server’s responsiveness, stability, and determinism under all operating conditions.