Player Session Persistence: Why Reconnection Logic Is Harder Than It Looks

Most multiplayer game implementations handle disconnection as a permanent event. Player drops? Mark them absent, maybe freeze them in place for a grace period, then remove them from the session. Simple, clean, well-understood behavior.

The problem is that mobile networks, unstable home connections, and ISP routing hiccups mean brief disconnections are common and involuntary. A player who loses connection for 8 seconds on a mobile network didn't choose to leave the match — they just hit a dead zone in their commute. Kicking them permanently from the session is a bad experience that's technically preventable.

Building reconnection that actually works requires solving several interlocking problems, none of which are particularly hard on their own but which interact in ways that trip up most implementations.

The session reservation window

When a player disconnects, you need a decision: how long do you hold their slot in the active match before treating them as permanently gone? The answer depends on your game type and what the disconnection means for other players.

In a 5v5 competitive match, a disconnected player creates a 4v5 situation. Playing 4v5 for 30 seconds while waiting for reconnection is tolerable. Playing 4v5 for 3 minutes is not. Your reservation window should be long enough to capture the majority of involuntary disconnections (which are typically under 30 seconds) without creating unacceptable gameplay imbalance.

We typically recommend 45–60 second reservation windows for competitive modes, shorter for game types where an absent player has less impact. The reservation should hold the player's slot, their in-game state (position, health, equipment), and their team assignment. Nothing should be deallocated during the window.

State divergence during absence

This is where reconnection gets hard. While the player is disconnected, the match continues. Other players move, game state changes, events happen. When the disconnected player rejoins, they need to be synchronized to current game state — which is potentially 45 seconds of divergence from when they dropped.

For a player's own entity, the server needs to decide what happened during absence. The two common approaches are: pause the entity (freeze the player in place), or run the entity on AI (the server controls them as a bot). Freezing is simpler but creates an exploitable obstacle in the game world. AI control is more realistic but requires bot logic that may not exist in your codebase.

The third option — remove the entity from the active simulation during absence — requires clean "player gone" and "player returned" event handling that updates all other clients. This is typically the most correct solution for games where player absence should be meaningful, but it requires every other client to handle entity removal and re-injection cleanly.

State delivery on reconnect

When the player reconnects within the reservation window, you need to send them current full game state — not just the delta since their disconnect. Their client doesn't have the intermediate state, so incremental updates won't work.

Full state snapshots are large. In a dense game with 32 players, full state might be 50–200KB depending on serialization efficiency. Delivering this on reconnect adds a 1–3 second resync window where the client is loading state and can't participate. That's acceptable. What's not acceptable is sending the snapshot inefficiently — if your server serializes full state synchronously in the game loop to serve a reconnecting player, you're adding latency for all other players in that session.

Snapshots for reconnect delivery should be generated asynchronously, ideally maintained as periodic cached state that's always available for delivery without on-demand serialization. We maintain a 2-second-old full state snapshot for each active session, refreshed every 2 seconds in a background thread. Reconnecting players receive the latest cached snapshot, which is at most 2 seconds stale, then receive incremental updates to bring them current.

Token-based session identity

The reconnecting client needs a way to prove it's the same player that was in the match, not a new connection trying to steal a slot. Session tokens handle this.

At match start, the server generates a cryptographically random session token for each player and sends it to them along with the initial connection acknowledgment. If the player disconnects and reconnects, they present this token. The server validates it against the reserved slot and restores the connection.

Tokens should be single-use-per-connection — once a player presents a token and reconnects, issue a new token for subsequent reconnections. This prevents token replay attacks where a different device tries to take over an active session.

The multi-device reconnect edge case

On mobile, players sometimes switch between WiFi and cellular mid-session. From the server's perspective, this looks like a disconnect from one IP and a reconnect from a different IP. The token-based approach handles this correctly — the identity is in the token, not the source IP. But it requires your connection management layer to not tie session identity to IP address, which some older game networking implementations do.

If your server validates connections partly by IP, mobile reconnection will fail silently. Players will hit the reconnect screen, see "Reconnecting..." indefinitely, and eventually be kicked when the reservation window expires. They'll think it's a network problem on their end. It's an assumption in your code.

What good reconnection looks like in practice

Under 30-second disconnections: invisible to other players, player rejoins mid-match with 1–3 second resync delay, no match disruption. 30–60 second disconnections: visible absence to other players (entity frozen or removed), player rejoins before reservation expires, game continues. Over 60 seconds: player is removed from session, treated as intentional leave, handled by your disconnect penalty system.

The engineering is not glamorous. It's state management, edge case handling, and token plumbing. But players who can reconnect are players who don't leave a negative review about getting kicked by their own crappy WiFi.