Game server engineering fundamentals

It means one process owns the only copy of game state that counts, and every other copy is a cache of it. Clients send input; they do not send outcomes. If a client reports that it is standing on a rooftop, the server checks whether the movement it received could have got it there and overwrites the client if not. The word matters because it defines a boundary of trust rather than a topology: you can run an authoritative simulation inside one of the players' own processes and it is still authoritative, and you can run a dedicated server that naively accepts positions from clients and it is not.

A listen server is one player's client also running the authoritative simulation, so that machine both plays and arbitrates. It costs nothing to host and it makes the host structurally advantaged: the host has zero network latency to the authority, sees state first, and can be modified with no server left to disagree. A dedicated server runs the simulation with no local player, usually in a data centre chosen for latency, so every participant is equally distant and the binary is under your control. Free-to-play and competitive titles pay for dedicated servers because the fairness and anti-cheat arguments are worth more than the hosting bill.

The reason is not raw overhead, it is what happens to a lost packet.

UDP, snapshots every 50ms, snapshot for t=200 is lost
  t=150 arrives -> render
  t=200 lost    -> skip it, nothing to do
  t=250 arrives -> render, world is current again

TCP, same loss
  t=150 arrives -> delivered
  t=200 lost    -> retransmit pending
  t=250 arrives -> HELD in the kernel, cannot be delivered out of order
  t=200 retransmit arrives -> now t=200 and t=250 both delivered
     the client receives a snapshot it no longer wants, late

The TCP column is head-of-line blocking. Because TCP guarantees ordered delivery, a snapshot that arrives on time is withheld until an older one it does not care about has been recovered, so a single loss delays everything behind it by at least a round trip. For state that is superseded every 50ms this is precisely wrong: the retransmitted snapshot is worthless by the time it lands, and waiting for it made the useful one late too.

UDP lets the application make that decision per message. State updates are sent unreliably and stale ones are simply dropped, while the small minority of messages that genuinely must arrive — a chat line, a match-start command, an entity spawn — get an application-level acknowledgement scheme layered on top. That is why almost every shipped game protocol is "UDP plus a reliability channel we wrote ourselves" rather than either protocol as it comes.

There is a second, smaller reason worth mentioning: TCP's congestion control interprets loss as a signal to slow down, which for a fixed-rate simulation stream means the game stops updating exactly when the network is already struggling.

A session is one bounded instance of play with a fixed roster: a match, a raid instance, a lobby. It has a lifecycle — created, filled, started, finished, torn down — and its state is discarded at the end, which is why session servers can be treated as disposable capacity. A shard is a long-lived world with persistent characters, where a player's identity and inventory live in one shard and cannot be trivially moved to another. The distinction drives the whole operational model: sessions scale by allocating more of them, whereas a shard scales only by being split or by having its population capped.

It removes server hosting cost entirely and can lower latency, because two players in the same city talk directly instead of both routing through a distant data centre. What it leaks is addressing and trust. Every participant learns every other participant's IP address, which is a real harassment and denial-of-service vector in competitive play. More fundamentally, with no neutral arbiter you either accept whatever peers assert or you make each peer verify the others, and both roads end at a modified client winning arguments. Peer-to-peer suits co-operative and casual play; it does not suit anything with a ranked ladder.

The three are routinely used interchangeably in conversation and mean different things.

tick      one step of the authoritative simulation, fixed duration
frame     one image the client draws, variable duration
snapshot  a network message describing state at the end of some tick

server at 60Hz tick, 20Hz send:
  ticks   1  2  3  4  5  6  7  8  9 ...    every 16.7ms
  sends      ^        ^        ^           every 50ms, one per 3 ticks

client at 144fps:
  frames  drawn every ~7ms, interpolating between the last two snapshots

Read the middle row first. The server simulated nine ticks and sent three snapshots, which means six of its ticks were never described to anyone. That is normal and intentional: simulation fidelity and bandwidth are separate budgets, and hit detection or physics stability may need a rate that the wire cannot afford.

The client row shows why the counts do not need to agree either. At 144fps the client draws roughly seven frames between snapshots, all of them invented by interpolating, and none of them corresponds to a tick at all. So "we run at 60 ticks" tells you about simulation accuracy, "we send at 20" tells you about bandwidth and about how much smoothing the client must do, and "it runs at 144fps" tells you nothing about either.

It is deciding, per client, which entities are worth sending. In a shared world with thousands of entities, sending everything to everyone is both unaffordable and a cheat vector, so the server maintains a relevance set per connection — typically by spatial partitioning into grids or cells, plus visibility and team rules — and only replicates entities inside it. The cost is that the relevance set has to be recomputed as players move, and its edges are visible: an entity entering relevance has no history to interpolate from, so it must be spawned rather than smoothly introduced, which is what causes things to pop into existence at the horizon.

A relay accepts packets from each participant and forwards them to the others without simulating anything. It solves two problems that have nothing to do with authority. First, connectivity: two players behind restrictive network address translation may be unable to establish a direct path, and a publicly addressable relay always can. Second, address privacy, since peers only ever see the relay's address. The cost is an extra hop of latency and the bandwidth bill for every packet in both directions, so relays are usually a fallback attempted only after direct connection fails.