I’ve been reading about remote event exhaustion and most of my scripts that I’ve made do not debounce server firing on the client (some of these scripts fire server on user input). I am passing no content over to the server, and all my debounces are handled on the server. However, many of the devs I’ve worked with have told me this is bad practice and will exhaust the remote event. Is this correct?
I’ve been using them for a long time and never had this exhaustion thing happen. Just make sure you queue data store requests and such and you should be fine.
1 Like
I’m sorry if I misunderstood you, but I’m talking about remote events?
1 Like
It is correct. If an exploiter comes out in your game and start firing up 20k times the remote event, you game’s gonna crash.
I don’t think that would be the case , cause if that were to be the case remote crashing servers would be verrry common
They aren’t common because developers are using something to limit the times a remote can be fired within a set time.
No you don’t understand what I mean, if you’re talking about what that remote event tells the server to do and it isn’t debounced on the server then sure. However if you’re talking about how developers are debouncing remote firing on client which is limiting it for exploiters too, exploiters have full control of the client, meaning any debounces on client are basically useless to restrict said exploiter.
Well, firing a quintillion of remotes wouldn’t make crash the server since you’d have a debounce before running the code. So for spamming remotes, roblox implemented “queue exhausts” to counter that and when it happens, only the exploiter is affected by that ^^ I think.
1 Like
I was talking about remote events. Nothing should get debounced on the server because other players’ remote requests may get dropped. What I was trying to tell you was: It totally depends on what the function connected to the remote does. If it makes a rate limited request, if it spawns something in the game, it must be queued, not debounced.
What I mean by queue is basically a debounce for every player in the game. Once they fire the server, their name must be added to a table with the time they fired on. If they fire again in like 5-6 seconds, you should then queue the request and wait until enough time has elapsed.
There is no hard “Bandwidth limit”, you could send gigabytes of data across the network using multiple events and roblox wouldn’t refuse to send it, however the user experience would be terrible, as roblox servers can only send a certain amount of data in a second.
This thread could be helpful: Is there a limit to how many times per second a remote can be fired?
Remote events are queued up to be sent 20 times per second, as (from what I know) roblox runs a 20TPS replication cycle, so a server will get a batch of them every 1/20th of a second. I’ve only ever had event exhaustion occur when there isn’t a handler for a remoteFunction.
Server debounces are somewhat useful, however sometimes someone may lag and send a lot of events within a short time and expect all of them to register, but due to debounces only one will register. Sometimes this is better than having exploiters, but most of the time it’s better to have a network system that can either handle the requests without issues or having a more generous debounce system, be that a queue like Aorda mentioned, which can become filled up if the debounce time is longer/equal to the time that the client waits, or something like I have described below, which might reject legit events if a player is lagging too heavily.
Generally, just try to keep network usage at or around 50kb/s.
This isn’t true. Using default roblox the user can crash a badly designed system, but when properly debounced (such as a counter that ticks up every time an event is fired and ticks down after a second, and if the counter is above a value then don’t process the request, or just light remote events that don’t run much code) you shouldn’t have issues with exploiters firing remote events to crash servers. There are ways to get server IPs and crash them that way, but no way to crash a server using only the roblox client and remote events.
4 Likes
Thank you for answering, I have been debouncing players server side with tables and using tick(), I’m just scared of the amount of requests that might cause anything
Sorry for the necrobump but this was pretty high in my google search, so I’m sure others are seeing this as well. There is a single glaring misconception that should be addressed:
Remote queue exhaustion is per player; it isn’t a cumulative “pot” that each player takes from. An exploiter who sends 20k requests will only ever affect their own gameplay. This will simply cause the server to start dropping requests for that specific player and the game will function normally for all the other players. If you’re worried about your datastore being accessed too much, then simply create a cache of the player’s data.
TL;DR
You don’t need to make your own queue if you’re worried about excessive remote spamming since it’s handled automatically, but you’ll obviously still need to debounce for purposes of cooldowns, sanity checks etc…
Side Note:
Some Denial of Service attacks target expensive operations on the server. An example avenue of attack could be: an open remote that fires a very long ray, then checks for parts in a large Region3 etc… The exploiter spams that remote to cause the server to use as many of its resources as possible in an attempt to cause lag, a crash, or a buffer overflow. An exploiter with two+ accounts would be a DDoS attack. In short: debounce first then perform any operations after your sanity checks.
26 Likes
I have experienced exhaustion once when I did not specify a value or something in a RemoteEvent (Sorry, I forgot exactly what I did lol). My server in studio was lagging EXTREMELY HARD. It’s very much possible that an exploiter can crash your game with one.
1 Like
This can happen if you don’t set a listener function.
2 Likes
Generally you won’t have a problem with firing a remote event many times. Its bandwidth is pretty large. If it does happen though, separate the load of functions from the event into 2 or 3. Most of the time its usually exploiters.