Throttle inactive clients

[UkoeHB]

If a client is not sending acks but they are still connected, then the server should gradually throttle replication updates. Otherwise a malicious client can abuse replication to waste server resources.

An easy method would be 'double the tick gap between updates every X updates' (with X as config) and reset when a non-stale ack shows up. So for X = 3 and an ack in tick 0, you'd get updates on ticks: 1, 2, 3, 5, 7, 9, 13, 17, 21.

EDIT: The throttling needs to take into account client reconnects, since their ack tick will reset to zero. It may also be worthwhile to throttle clients who reconnect too frequently.

[UkoeHB]

Since some game devs may want to replicate at a lower rate than their server tick rate, we could add a 'baseline tick gap' config value that defaults to 1.

[Shatur]

Overwatch also implements variable tick rate.

[UkoeHB]

With per-tick replication we can design throttling along two dimensions: age of an unreplicated tick and time since last ack. New ticks will normally be replicated in bursts that peter out (since you only need a few packet re-sends to guarantee very high probability of packet transmission), and the burst profile density will decline as the ack gap widens (to account for inactive clients).

In fact, we could allow users to inject the throttling algorithm and provide a sensible default. We could even go all the way and allow users to define a custom SystemParam in order to inject arbitrary data (would require making the replication plugin generic).

[UkoeHB]

With manual packet fragmentation we now replicate spawns/insertions/despawns/mappings in a reliable channel, and component updates in an unreliable custom-acked channel. The reliable messages cannot be directly throttled because all that data has to be sent and can't be compressed. We can however indirectly throttle them by adjusting the renet resend time on the client, which is zero seconds by default.

[UkoeHB]

Superseded by #184.