- summary: Presents an authentication ticket on a freshly opened game-server socket; always the first frame written on that connection.
- area: Game.Connection
- confidence: 0.92
Presents an authentication ticket on a freshly opened game-server socket; always the first frame written on that connection.
- Kind request
- Area Game.Connection
- Named by beta, gamemapping
THE FIRST FRAME ON EVERY GAME-SERVER SOCKET. Nothing else is accepted until it is answered, and the client does not wait for the socket to finish opening before writing it: the message is built inside the connect routine and handed to the connection object while the TCP handshake is still in flight. The connection queues it and flushes it the instant the channel goes live.
WHEN TO SEND IT
There are exactly two moments, and both are the opening of a NEW socket.
1. ENTERING A SERVER. The trigger is NOT the login server's server-selection reply. That reply only hands you three things - a ticket, a host, and a LIST of candidate ports - which the client stores. The client then lets the LOGIN connection close, and only once that socket is gone does it dial the game host and send this message. A capture of a full sign-in therefore shows two connections that do not overlap.
2. TRANSFERRING TO A FIGHT SERVER. A second game connection, opened ALONGSIDE the
first, which stays up. The server sends a transfer message carrying its own host,
its own ticket and its own port list; the client opens a second socket, sends this
message on it, and from then on drives both connections at once. The destination is
a dedicated arena server - see ServerType.KOLIZEUM.
THE PORT LIST IS A CANDIDATE LIST, NOT A CHOICE. You are given several ports for one host. The client takes its configured port when that port is in the list and the first one otherwise; on a failed connect it drops that port and retries the next, until the list is empty. The identification request is NOT rebuilt per attempt - it is queued once, on the connection object, and written on whichever attempt succeeds. The number of TCP attempts and the number of identification requests are not the same number.
THE TICKET IS NOT SOMETHING YOU CAN INVENT. It comes from an exchange on an earlier, separate connection, and the two moments above use two DIFFERENT tickets: entering a server uses the one from the server-selection reply, the fight transfer uses the one carried by the transfer message. They are not interchangeable.
ONE SESSION, TWO SOCKETS. Because the fight transfer identifies on a second socket while the first one is still authenticated, "already authenticated" does not mean "must not send this". What is illegal is sending it TWICE ON ONE SOCKET. Scope the rule to the connection, not to the session.
BEWARE THE NAME COLLISION. A message called IdentificationRequest exists in BOTH protocols: one in the Connection protocol (login server) and this one in the Game protocol. They are different messages with different payloads, and a single sign-in sends both.
DO NOT COPY FIELD NUMBERS FROM AN OLDER SCHEMA. This message has been renumbered - the reference build carries the ticket and the locale as fields 1 and 2, the current build does not. Read the numbers off this page.
Acceptance is followed immediately by a burst of state events in the same millisecond
- server settings, optional features, account capabilities and rights, trust status -
ending with ServerSessionReadyEvent.
When you may send it
- Requires
transport_establishedobserved - Raised by: a client-side state change - one of the two connect routines opening a game-server socket, either entering a server (after the login connection has closed) or transferring to a fight server (a second socket beside the first). The message is built inside that routine and queued on the connection before the TCP handshake finishes, so it leaves as the first frame the moment the socket goes live proven
State it changes
- Establishes
authenticatedobserved — acceptance opens the session; every later message is gated on it
Related messages
- You will then receive
ServerSessionReadyEventobserved — the session value the challenge exchange is built on; 1 of 1 login capture - You will then receive
ServerSettingsEventobserved — server identity and settings, in the same inbound burst - You will then receive
OptionalFeaturesEventobserved — which optional features this server enables - You will then receive
TrustStatusEventobserved — whether the server considers the client trusted - You will receive one of
AuthenticationTicketAcceptedEventobserved — the ticket was accepted - You will receive one of
AuthenticationTicketRefusedEventobserved — the ticket was rejected
Fields
| # | Field | Type | Meaning | You set it |
|---|---|---|---|---|
| 1 | ticket_key | string | The authentication ticket for THIS connection, issued by the exchange that sent you here. Two different tickets are in play. Entering a server uses the one carried by the login server's server-selection reply; transferring to a fight server uses the one carried by the transfer message. They are not interchangeable, and neither can be derived from anything you already hold. | required |
| 2 | language_code | string | The client's current locale, e.g. fr or en. The server uses it to localise the text it sends back. Observed: frRead from the client's one global locale at the moment of connecting, so every connection of a session carries the same value. | required |
Recovered with score 135, confidence 0.92, margin 135 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 2 of 2.
Aucun avis à afficher.