Js5Configuration

the maximum number of bytes written per client per iteration

the minimum number of bytes that must be written into the channel before a flush occurs. Note that the flush will only occur if at least one group has been successfully written over, as there's no point in flushing a partial large group - the client cannot continue anyhow. Furthermore, flushing occurs if there's no more data to write, ignoring both the flushThresholdInBytes and flushThresholdInRequests thresholds in the process.

the number of full requests that must be written into this channel since the last flush before another flush can trigger. As explained before, a flush will take place if no more data can be written out, ignoring this threshold.

the behaviour type of what to do when the server returns a null response for a group request. By default, we warn about it (up to 100 times before disabling warnings) and drop that request. It should be noted that the client should never normally request for invalid groups - if that happens, it was either someone spoofing it, or the server sent something to the client, like opening an interface that does not exist, which led to the client making the request. In the case of latter, it should be noted that the client may begin to misbehave if it doesn't get a reply, particularly if the request it made was for an urgent group. A common side effect of this is seeing the "Please wait - loading..." screen indefinitely. The default behaviour is to warn the developers about it, with an upper cap of 100 warning messages before the warnings get turned off (to avoid flooding and causing performance degradation with logging if it is someone spoofing). These warning messages should help developers detect faulty code and fix it on the server's end, rather than needing to debug in the client.

the number of bytes to transfer from the 'pending' prefetch collection over to the 'being served' prefetch collection. This is a soft cap, meaning it will keep transferring groups until the moment that the sum of all transferred is equal to or above this value. It is worth noting that this will be uncapped when the user reaches the login screen, allowing for fast downloads of the cache if one chooses to sit on the login screen. Before reaching the login screen, however, the thresholds are still applied. Below are some numbers of how long it takes to transfer the entire OldSchool cache over via localhost using various thresholds: Uncapped - 1 minute, 20 seconds 16,384 bytes: 3 minutes, 30 seconds 8,192 bytes: 5 minutes, 52 seconds 4,096 bytes: 15 minutes, 26 seconds

the ratio for how much more data to write to logged in clients compared to those logged out. A ratio of 3 means that per iteration, any low priority client will receive blockSizeInBytes number of bytes, however any logged in client will receive blockSizeInBytes * 3 number of bytes. This effectively gives priority to those logged in, as they are in more of a need for data than anyone sitting on the loading screen.