SequenceNumberRequest

Answers SequenceNumberEvent. One integer: a counter this connection keeps.

WHEN TO SEND IT

ONCE PER POLL, IMMEDIATELY, AND FROM NOWHERE ELSE. The client builds this message in exactly one place - inside the handler for the poll - and replies unconditionally, before anything else looks at the event. There is no timer and no proactive path.

WHAT THE COUNTER ACTUALLY COUNTS

NOT INBOUND MESSAGES. NOT EVENTS OF EVERY KIND. It counts the SequenceNumberEvent polls that have arrived on THIS connection, and nothing else touches it. The whole rule is two lines:

when the socket becomes active:   n = 0
when a poll arrives:              n = n + 1, then reply with n

Three consequences, all of them visible to the server:

IT RESTARTS AT EVERY RECONNECTION. The reset is bound to the socket becoming active, not to logging in, so a reconnect starts again from zero. Carrying a count across connections is wrong.

THE FIRST REPLY CARRIES 1, NEVER 0. The counter is incremented before the reply is built.

EACH CONNECTION HAS ITS OWN. If you hold two game sockets at once (see IdentificationRequest), each counts its own polls independently. There is no shared total.

A bot that hard-codes a constant, counts the wrong thing, restarts mid-connection or carries the number across a reconnect is producing traffic no real client produces - and this is the one number in the exchange the server can recompute exactly, because it sent every poll itself.

THIS COUNTER IS NOT THE ENVELOPE UID

They are different numbers living in different places, and confusing them is the easy mistake here. The counter is the payload. The uid is transport-level - and for this particular message the client does not allocate one at all: it writes the reply straight down the connection rather than through the normal request path, so the envelope goes out with the uid set to -1. BasicLatencyStatsRequest, answering the poll that arrives in the same frame, does carry a real uid. Two replies to one frame, two different envelope shapes.