Skip to main content

Module datagram

Module datagram 

Source
Expand description

The replication datagram: entity updates that may be lost, duplicated, or reordered (a WebTransport datagram, or a relay of one).

A subscription on an unreliable transport gets spawns, despawns, and full frames as ordinary replication frames (crate::frame) on a reliable, ordered stream, and its updates in datagrams. Every datagram stands alone: an update carries the entity’s absolute quantized position, not a difference, so a lost datagram only delays what it held. The client acks the frame numbers it receives; the server keeps sending whatever changed since the last acked state until an ack covers it.

u8      version (2)
varint  frame number (per subscription, from 1)
varint  tick
varint  input ack: the highest client_seq the shard has processed
varint  stream tick: the tick of the last stream frame sent by this tick
f32 LE  precision
varint  parts: datagrams sent for this tick
varint  update count, then per entity (ids ascend, delta-coded):
          id, u16 LE spawn tick, u8 mask (1 x, 2 y, 4 z, 8 components),
          the axes in the mask (zigzag, absolute quantized),
          components when bit 8 is set (as in a frame)

Spawn tick. An update names the tick of the stream frame that spawned the entity (its low 16 bits), and the client applies it only to the entity spawned then. A late datagram for an entity that has since been despawned and spawned again under the same id, or one built before a full frame, changes nothing. Ticks travel in every frame header, so the two sides agree even when the server dropped frames the client never got, which counting spawns could not survive.

Acks. The client acks a datagram with its number and the tick of the last stream frame it had applied (ReplicaTable::stream_tick). An ack covers an entity only when that tick is at or after its spawn.

Order. The client keeps, per entity, the number of the last datagram it applied, and skips an update from an older one.

Whole ticks. Every tick without a full frame sends at least one datagram, and each names how many the tick has and the tick of the last stream frame sent by then. A tick is whole on the client when it has all of its datagrams and that stream frame. Only then does the client’s table hold the server’s state as of the tick, so only then does the input ack describe the table (prediction depends on that): the client applies a tick’s datagrams, and takes its ack, when the tick is whole or a later tick is.

Structs§

DatagramBuilder
Builds one datagram. Add updates in ascending id order.
DatagramSummary
What one datagram did.

Constants§

MAX_HEADER_LEN
Bytes before the first update, at most: version, four varints, the precision, the parts, and the update count.
VERSION

Functions§

encode_entry_into
Encode one update body (everything after the id): the spawn tick’s tag, mask, the axes given, and the component changes.
spawn_tag
The part of a spawn tick an update carries.