How the relay works

A Blitz Relay session consists of a relay process, a game host, and clients connected to that host. The relay forwards packets and can run on a separate machine from the game. The game host runs the server side of your networking framework.

Connections and room codes

The game host and remote clients make outbound UDP connections to the relay. Only the relay needs an inbound UDP port. Players use a room code to join instead of entering the game host’s address.

A player-hosted session follows this sequence:

1. The host starts the server side of its Unity transport.
2. The relay creates an ephemeral room and returns its code.
3. Other players connect to the same relay and submit that code.
4. The relay forwards client traffic to the host and host traffic to the intended clients.

Each room code belongs to the relay process that created it. To join the room, players must connect to that process. Relays do not share rooms, even if they use the same connection key. Room codes are case-insensitive.

Clients do not connect directly to one another. To exchange data between players, use your networking framework to send it through the game host.

The two server roles

The relay server is the .NET process you deploy. The game server is the server side of Netcode for GameObjects (NGO), Fish-Networking, Mirror, or another framework. A player host runs the game server and plays locally. A dedicated game server runs without a local player. Both use a host connection to the relay.

The relay does not spawn networked objects, validate game rules, run matchmaking, or save matches. If you need these features, implement them in your game or backend. Your backend can use room information from the HTTP API to provide a lobby list.

Room lifetime

An ephemeral room exists while its host remains connected. When the host disconnects, the relay disconnects the room’s clients and removes the room.

Create a persistent room through the HTTP API. It can remain without a host, even when empty. When the room needs a host, the relay selects a connected client to reconnect as host. The first host of a new persistent room follows the same process.

A persistent room survives a host disconnect, not a relay restart. The relay stores all rooms in memory and loses them when the process restarts. For a comparison, see Choose a room type.

Game traffic

The relay supports reliable ordered, unreliable, and sequenced unreliable delivery. Both unreliable modes can lose packets. Sequenced delivery also discards older packets after a newer packet arrives. NGO exposes both unreliable modes. The Fish-Networking and Mirror transports expose reliable and ordinary unreliable delivery.

The relay adds a routing header to each game payload and removes or changes the header when forwarding the packet. Your networking framework encodes the game data.

Keep unreliable packets within the transport’s payload limit. LiteNetLib can fragment reliable traffic, but the relay can disconnect recipients whose reliable queues grow too large. For these limits, see Backpressure thresholds.

Host migration changes which peer sends and receives host traffic. It does not copy the former host’s authoritative game state. Before you use persistent rooms to continue a match after a host disconnect, read Handle host migration.