Js5Client

The possible client priority values.

A class for tracking partial JS5 group requests, allowing us to feed the groups sections at a time, instead of the full thing - this is due to the groups varying greatly in size and naively sending a group could open it up for attacks.

the channel handler context behind this client

the current priority of this client. If the client is logged in, they will have a higher priority and the service will by default write 3x as much data to that channel compared to any other client that is set to a low, logged-out priority.

Gets the next block response for this channel, typically a section of a cache group.

Checks that the client is not empty, meaning it has some requests, or a group is half-written.

Checks that the JS5 client isn't full and can accept more requests in both queues.

Checks if the client is ready by ensuring it can be written to, and there is some data to be written to the client.

Checks if the client needs flushing based on the input thresholds.

Pushes a JS5 request to this client, adding it to the end of the respective queue. If this is an urgent request, the request itself is removed from the prefetch list, if it exists. This is a one-way operation, however, as the client by default can only request duplicate requests via this manner. Any modifications to the client can by-pass this, but that is a non issue since we offer a fair JS5 service where the actual request doesn't matter and the number of bytes written is all the same to everyone connected.

Resets the number of bytes and groups written.

Sets this client in a high priority state, meaning it gets served more data than those that have a lower priority. The client switches to high priority when the player logs into the game.

Sets this client in a low priority mode, meaning it gets served less data than those that have a higher priority. This happens when a player logs out of the game.

Sets the pending encryption key for this client. Client sends this when it receives corrupt data for a group, in which case it will close the old socket first, allowing for a new one to be opened. In that new one, the encryption key is first sent out, followed by any requests it was previously waiting on, as those get transferred from the "awaiting response" over to the "awaiting to be requested" map.