ReloginRequest

CARRIES NO PAYLOAD. There is nothing to fill in - constructing it and sending it IS the request. Send it BEFORE you hand this connection over, then read ReloginTokenEvent.

WHEN TO SEND IT

WHEN YOU ARE ABOUT TO LEAVE THIS GAME SERVER, and not otherwise. In the real client every path into it is a menu confirmation:

go back to server choice          -> ReloginRequest
confirm a change of server        -> ReloginRequest
confirm a change of character     -> ReloginRequest
confirm server + character        -> ReloginRequest

Nothing in gameplay sends it. It is not a keepalive, it is not periodic, and it has nothing to do with PingRequest despite sitting beside it in the protocol.

ONE AT A TIME. The client refuses to send a second request while an answer is still outstanding - it raises an error popup instead of asking again. Do not pipeline this and do not retry it while you are still waiting; if you never got an answer to the first one, the connection is the problem, not the request.

THE CLIENT PARKS WHAT YOU ASKED FOR. It remembers the action that provoked the request, sends this, and only replays that action once the token has been stored. That ordering is the whole point of the exchange: if you act on the server change before the answer lands, you leave without the token you asked for and gain nothing.

WHAT COMES BACK

ReloginTokenEvent, with a grant flag and a token. Both branches are real - read that record before implementing either.

MATCH IT BY TYPE, NOT BY UID. This goes out on the uncorrelated send path, so its envelope uid is -1 and there is no response to pair against it. Watch for the event.

SENDING IT IS OPTIONAL. Skip it and nothing breaks here; the next connection simply has to authenticate in full instead of presenting a token. What is not optional, if you do send it, is waiting for the answer before you move.