Describe the problem related to your feature request.
In the Event loop schedule, this piece of code is executed as many times as the player sending the most packets sends packets.
fn run_event_loop_schedules(world: &mut World) {
world.run_schedule(EventLoopPreUpdate);
world.run_schedule(EventLoopUpdate);
world.run_schedule(EventLoopPostUpdate);
}
This means a player can send tens of thousands of packets per tick, severely lagging the server due to the large overhead of running the ~600 systems in these schedules.
What solution would you like?
Valence should process some maximum number of packets per client per tick. This should be configurable. Id start in crates/valence_network/src/packet_io.rs to see if a constraint can be easily intoduced there.
What alternative(s) have you considered?
PaperMC will kick players who send 500 packets in a 7-second period. IMO, valence can handle volumes higher than this, but we do need a limit. I'd rather the limit be tick-based, not time-based, especially in dynamic tick situations.
Additional context
Here is a PoC I have running. The version of the repo I use here is from my highly unstable fork for 1.21.5, so providing code won't be very useful, but it's effectively stresser.rs by an extra loop sending millions of head-rotation packets.
Describe the problem related to your feature request.
In the Event loop schedule, this piece of code is executed as many times as the player sending the most packets sends packets.
This means a player can send tens of thousands of packets per tick, severely lagging the server due to the large overhead of running the ~600 systems in these schedules.
What solution would you like?
Valence should process some maximum number of packets per client per tick. This should be configurable. Id start in
crates/valence_network/src/packet_io.rsto see if a constraint can be easily intoduced there.What alternative(s) have you considered?
PaperMC will kick players who send 500 packets in a 7-second period. IMO, valence can handle volumes higher than this, but we do need a limit. I'd rather the limit be tick-based, not time-based, especially in dynamic tick situations.
Additional context
Here is a PoC I have running. The version of the repo I use here is from my highly unstable fork for 1.21.5, so providing code won't be very useful, but it's effectively stresser.rs by an extra loop sending millions of head-rotation packets.