- summary: Asks for a fresh API token for the in-client shop back end. Empty payload, sent on a timer.
- area: Game.Bak
- confidence: 0.92
Asks for a fresh API token for the in-client shop back end. Empty payload, sent on a timer.
- Kind request
- Area Game.Bak
- Named by stringtable
Refreshes the key for Ankama's in-client shop back end. Carries nothing.
THE TRIGGER IS TOKEN LIFECYCLE, NEVER USER ACTION, and the client's state machine has three parts worth reproducing:
in-flight latch one request at a time. The send routine sets a latch and
will not send a second while one is outstanding.
5,000 ms retry when it cannot send yet - the connection is not up - it
re-arms on a 5 second delay and tries again. A real
repeating cadence during bring-up.
3,600,000 ms after a successful answer, EXACTLY ONE HOUR before the
next refresh. A long session re-sends this hourly,
indefinitely.
Both constants are read straight out of the client, one in the send routine and one in the receive routine.
IT APPEARS DURING BRING-UP ALONGSIDE THE SOCIAL BURST, AND IT IS NOT PART OF IT.
A capture shows it in the same handful of milliseconds as
ContextCreationRequest and the four-request burst described under
FriendListRequest - but it comes from a different service on a different
trigger. Do not fold it into that sequence.
Nothing in gameplay depends on having the key.
When you may send it
- Requires
authenticatedobserved - Raised by: token lifecycle, never a user action: 3,600,000ms after each successful key, and a 5,000ms retry whenever the send cannot proceed; one in flight at a time proven
Related messages
- You will then receive
BakApiKeyEventobserved — the server answers with the key; observed in a live session
Recovered with score 145, confidence 0.92, margin 145 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: 0 of 0.
Aucun avis à afficher.