Investigate high bandwidth at high tick rate

[UkoeHB]

Servers send an empty payload every tick. Investigate why this happens and fix it if possible.

Workaround: reduce your server's tick rate. In a Bevy app you can use bevy::app::ScheduleRunnerPlugin::run_loop.

[cab]

i'm new to the code, and this might be an intentional part of the netcode protocol, but: it seems like the "empty" payload being sent is a Packet::Ack.

whenever a packet is sent pending_acks is set to sequence..sequence + 1 here. that range will never return false for is_empty here.

because of this, there is always a new Packet::Ack to send, even if all packets have actually been acked. would that make sense at all?

[UkoeHB]

It looks intentional and seems to be part of replay protection. The next step would be verifying that the reference implementation of netcode also does this.

A possible solution would be setting a max rate for sending empty acks in remote_connection.

[UkoeHB]

More info from @lucaspoffo:

Yeah it's intentional, if no packets are being sent, both will be exchanging acks between them.

I have made draft that adds a delay for this to reduce this workload and add a delay to acks:
lucaspoffo#156
the ack can act as a keep alive as you think @Koe, this PR seems to work pretty well, but never finished it and tested completed, I think the rrt calculation were being messed up since before, there was never a delay in acks.

Also see the QUIC ack protocol, which renet's ack protocol is derived from.