1 realtime runtime profile and transport adaptation
forgejo-actions edited this page 2026-07-11 10:33:50 +00:00

Realtime Runtime Profile And Transport Adaptation

Realtime runtime profiles describe how a game-server session should use streams, datagrams, compression, movement cadence, liveness, and adaptive replication. They are the shared contract between endpoint capabilities, negotiated client behavior, and runtime transport decisions.

How It Works

The server starts from an endpoint profile, folds in negotiated client capabilities, and stores a session runtime profile. That profile controls whether the session can use datagrams, which traffic remains stream-only, when bootstrap compression is allowed, heartbeat expectations, movement cadence, and how the server reacts to QUIC liveness or quality samples.

Transport code uses the profile when choosing send paths and recovery behavior. Movement and AOI systems use it to keep tick cadence, snapshot size, and bandwidth pressure aligned with the active transport mode.

How To Use It

Read the current session profile before adding a realtime feature that changes packet cadence, liveness, compression, or datagram reliance. Add new fields at the profile boundary, then update negotiation, compatibility defaults, session-stream use, and protocol fixtures together.

For local or degraded clients, prefer profile-driven stream fallback over special-case transport branches.

Invariants

Profile defaults must be safe for clients that know nothing about new fields. A session must not advertise a transport behavior that the endpoint cannot support. Liveness, heartbeat, movement cadence, and replication budgets must move together so a degraded network does not receive an impossible stream of snapshots.

Debugging

Inspect negotiated profile values when a session falls back to streams, stops receiving datagrams, or sees heartbeat disconnects. Compare QUIC RTT/loss samples, transport health, and profile-derived send policy. If bootstrap compression fails, confirm both sides agree on the compression profile and fallback behavior.

Examples

A stream-only fallback profile should still allow login, bootstrap, chat, and reliable gameplay actions while suppressing datagram-only replication. A zstd bootstrap profile should compress large activation snapshots only after negotiation says the client supports it.