PlayerSessionService

projects/{p}/locations/{l}/gameServers/{s}/connections/{connection}.

The game server this connection was made to.

Which of the game's ports the connection arrived on — "game", "query", "rcon". A server browser probing the query port every thirty seconds is not somebody playing, and without this the two are the same row.

"tcp" or "udp".

Source address as the proxy saw it, host:port.

A personal datum and treated as one: it is here because it is the only thing a connection and a log line have in common, which makes it the only way the two halves of this service correlate at all. See client_ip.

The host part of client_address, stored separately because it is what correlation matches on — a game announces a player's address without the ephemeral port, so the full pair never joins to anything.

Where the proxy forwarded it, host:port on the game server's own private address. Empty while the server is still starting, which is the state a connection to a hibernated server spends most of its life in.

Whether the game server was not running when this connection arrived.

The demand signal, and named for what the proxy can actually observe. It is not "this connection is the one that started the server" — which single connection won that race is Playpute's to know, and asking the proxy would be asking it to guess. Twenty friends joining a hibernated server at once all carry this, which is the honest description of what happened.

What it separates is the thing that matters: demand for a stopped server, from traffic to a running one. Almost every connection is the latter.

Unset while the connection is open.

How long the player waited before being spliced to a server: the gap between accepting the socket and having somewhere to send it.

Recorded because it is the number the product is judged on. Hibernation only works if a restore is faster than a boot, and this is the only place the platform observes what a player actually experienced rather than what a snapshot benchmark says.

The player session this connection is believed to belong to, when one was matched. Empty is the common case and not an error — see the package comment, and PlayerSession.connection.

projects/{p}/locations/{l}/gameServers/{s}/playerSessions/{session}.

The id is derived from the game server, the player and the join time, so one stay always has the same name.

The game that was running, carried through so a consumer can reason about a session without resolving the server.

Who. Every field on Player is optional because games disagree on what a player is; see plany.gamelog.v1.Player.

What this session is keyed on: the player's stable id where the game logs one, and its display name where it does not.

Surfaced rather than left implicit, because it is what "the same player" means here — and on a game that logs only a name, that is a weaker claim than it looks. A rename mid-session becomes two sessions.

When the server said they joined — the log line's own time, not when the platform got round to reading it. Extraction can lag by minutes after an outage, and a session timed by extraction is wrong by exactly that much.

Unset while active.

end_time - start_time, for an active session measured to now.

Whether this session may be acted on.

Copied from the event that opened it. PROVISIONAL means the template that recognised the join has not been promoted, so the session is published for anyone who wants to watch early and must not reach a bill.

The connection this session is believed to have arrived on.

Matched on source address within a window, and therefore a belief rather than a fact — which is why it is a link between two stored records and not a merge. Empty whenever the game did not log an address, which is most games.

The event this session was opened from, so a surprising session can be traced back to the line that caused it.

projects/{p}/locations/{l}/gameServers/{s}/presence. A singleton.

Active sessions: players the server said were on it and did not say left.

Open connections, which is a different and usually larger number. A query socket is a connection and not a player, and a player whose game opens two sockets is one player.

Connections open against a server with no active sessions at all.

The signal that matters while a server is starting: somebody is waiting and nobody is playing yet. Zero players and a non-zero count here is exactly "a hibernated server has demand", which is the state Playpute will act on.

Who, capped — see ListPresenceResponse. Empty on a fleet-wide listing, where the counts are the point and the names would be the response.

The most recent thing this service observed about the server: a join, a part, a connection either way.

The field an idle-shutdown policy should read, and deliberately not "last_session_end": a server with a player who joined an hour ago and has said nothing since is busy, and one whose last event was a disconnect two hours ago is not.

Whether any active session came from a template still being shadowed. A caller about to act on player_count — bill it, or keep a server alive on the strength of it — should refuse when this is true.

Display name as the server printed it. Unstable — Minecraft names change and Steam personas change hourly — so it is for humans, not for joins.

Stable identifier, when the game logs one: a Minecraft UUID, a SteamID64, an EOS product id. This is what a session is keyed on when it exists.

Which namespace player_id belongs to, e.g. "steam", "minecraft", "eos". Two games can both log a 17-digit number and mean different things.

Source address, when logged.

A personal datum, and a game server prints it unasked. It is kept because it is often the only stable identifier a game offers, and it is the field most likely to need suppressing per account — which is why it is separate rather than folded into attributes.