i know that the maincloud has DDOS protection but ironically it doesn't have DOS protection from one client.
right now a single client can call a reducer so fast that it fills the reducer queue of 16k requests in an instance. right now the client get's disconnected but the server still runs ~7k of these requests before that happens (stdb is too fast for it's own good in this case)
i did it with a rust client that just has this
loop{
if !conn.is_active(){
sleep(Duration::from_millis(100));
} else {
match conn.reducers.transfer_money(1, 2, 1u64){
Ok(_) => {}
Err(e) => { println!("{}",e) }
}
}
}
now if i make the client wait a fraction so that the queue barely doesn't fill up, the perfect and simple DOS machine is created that the server doesn't detect on it's own.
i would say that creating a global rate limit of 300 requests/s per client is more than generaous enough for games and i would go even further to have a rate limit of 100 requests/s per reducer per client as even fast pase movement should never take more than 60 requests/s (normally probably not even 10 requests/s as the client only needs to send changes in the input and not realtime position updates).
i know that the maincloud has DDOS protection but ironically it doesn't have DOS protection from one client.
right now a single client can call a reducer so fast that it fills the reducer queue of 16k requests in an instance. right now the client get's disconnected but the server still runs ~7k of these requests before that happens (stdb is too fast for it's own good in this case)
i did it with a rust client that just has this
now if i make the client wait a fraction so that the queue barely doesn't fill up, the perfect and simple DOS machine is created that the server doesn't detect on it's own.
i would say that creating a global rate limit of 300 requests/s per client is more than generaous enough for games and i would go even further to have a rate limit of 100 requests/s per reducer per client as even fast pase movement should never take more than 60 requests/s (normally probably not even 10 requests/s as the client only needs to send changes in the input and not realtime position updates).