Rate limiter module for Remotes

[Painshinratensei]

Not sure why but, could you explain why this would cause a memory leak?

[SovereignFrost]

Because the connection is not disconnected, it will be called more times than it should. If you keep firing the function the event is going to be ran another time.

I can’t really explain this too well, this thread is a good read.

Garbage Collection and Memory Leaks in Roblox - What you should know

This article is meant to teach you how to prevent memory leaks and how the Roblox lua garbage collector works. What is garbage collection? Garbage collection, for those who are new to the term, is the process that a lot of languages such as JavaScript, python, and lua use to clean up memory. When values are no longer being used, they get garbage collected thus freeing up any memory they used. What are memory leaks? Memory leaks may sound like something scary. It might sound like it means infor…

[ash877]

I thought roblox already monitors this. If a client over calls the remote then that player will get throttled not the others?

[RuizuKun_Dev (Kitsune)]

afaik it shouldn’t impact other clients, it doesn’t make sense to compromise other users when they aren’t involved.

Although Roblox does monitor this it’s for a different purpose and does a different thing, which that’s not the point of having this in your game, it’s to filter out Exploiters from Legitimate Clients.

[XandertjeKnal (Xander)]

Roblox has no way to know if a remote is being ‘over-throttled’ or not; some remotes are supposed to be fired a lot, some are not.

The point of throttling the remotes yourself is to reduce the stress on the server that may be caused when clients trigger a resource-heavy task multiple times (and too frequently!).

The point @RuizuKun_Dev made is also valid. When, for instance, an exploiter fires a remote too many times, it should not negatively impact the experience for the other players (by having the server crash or by disabling the function attached to the remote completely). This was the main motivation behind making and publishing this module.

[XandertjeKnal (Xander)]

This post has often been quoted in the context of other networking problems.
I recently wrote this reply for someone that goes more in-depth on ping, lag, and on how you could tackle some of the other networking problems related to guns in an FPS game:

How do I position an object accurately

This is a classic networking problem. There is nothing wrong with your code, but let me explain to you the issue you are dealing with: It takes a little bit of time before a message from the client reaches the server (ping). This can be anywhere between 50 ms to 300 ms in Roblox. (On triple-A games this is usually way lower.) I’m going to use a less than optimal 250 ms ping here to illustrate your problem. When your client (player) tells the server to make a part, it takes 125 ms to reach t…

[Gojinhan (HashCollision)]

Unless I misunderstand, isn’t this kind of completely pointless? Anybody can limit players from proceeding in the event with an if statement (and not having to wrap in a pointless function abstraction that uncessarily uses self )

To actually rate limit, i.e block the server from responding to a certain players request at all, is far different. Because as it stands if that player is exploiting and firing the remote hundreds of times a second, this will do nothing besides stop the server code from executing, in fact because of your module implementation you may end up causing server lag.

[XandertjeKnal (Xander)]

Yes, you indeed seem to misunderstand.

@Gojinhan

Because as it stands if that player is exploiting and firing the remote hundreds of times a second, this will do nothing besides stop the server code from executing

Indeed, this module limits the code on the server from executing if a rate is exceeded, therefore reducing stress on the server. This practice is very common and I recommend that you look more into the subject.

@Gojinhan

because of your module implementation, you may end up causing server lag

This claim is not true at all, all my module does is relatively inexpensive, e.g. manipulating a table. (As you can see in the source code.)

[Gojinhan (HashCollision)]

therefore reducing stress on the server.

This doesn’t reduce stress on the server, sure, it’ll stop the code you want to execute from executing, but you don’t seem to know what I mean. What I mean is, if they fire that remote hundreds of times, that event will still fire hundreds of times, that if statement will still conditionally check hundreds of times. Nothing has changed besides the extent to which the player proceeds to. And it’s already too far.

This claim is not true at all, all my module does is relatively inexpensive, e.g. manipulating a table. (As you can see in the source code.)

I’m pretty sure I said the wrong thing on this part, while you may not cause server lag per se, wrapping this in a, again uneeded function call that also doesn’t use self but has it there anyway. It will be more expensive than literally just having only an if statement.

So instead of making wrappers for something that doesn’t actually save any resources, (if anything, the opposite effect compared to standard implementation of this) I’d suggest you instead make a tutorial advising people on this practice of stopping remote abuse.

[Loominatrx]

Can you make RemoteFunction version of this module, please? Nice module, though!

[XandertjeKnal (Xander)]

The module works for both RemoteEvents and RemoteFunctions!
In the source code, there are detailed instructions on how to use my module + code examples.

[unix_system]

I think you’re confused about the expense of function calls - i.e. the lack thereof of any actual cost.

What you’re suggesting is sanity checks (I think?) - those should be included on top of a module like this. Using catch all solutions, like a rate limiting wrapper, is good practice because it acts as a safeguard against accidental failure to implement proper controls (the risk of accidentally allowing a DoS-style attack is increased by relying on sanity checks on every single remote, rather than wrapping them in a module which sorts it for you).

The cost to something like this is minimal, if not plain negligible, and the benefit is pretty clear from a security and performance perspective.

[d_ytme (Sammy)]

@XandertjeKnal

The module can be used on multiple scripts listening to the same remote at once without them counting as duplicates (and then filling up the number of requests the player can make). This is useful when dealing with packages or clones of scripts that all listen to the same remote.

It wasn’t clear from here if I could check if the player is being throttled from a LocalScript (to for instance notify them of this) without it limiting the amount of uses a player gets.

To be more precise, I’m thinking of adding a sort of “Panic Button” function to a custom chat script, and using this to not only prevent spamming remote events but also implement the delay of 20 seconds, or (0.1 allowed times per second)

[marc2534 (MerpButButter)]

Is it a good idea for example:
You make a cooldown on the client that lasts 1 second, then on the server you make it so if its fired more than 5 times a second you kick the player, is that a good idea?

[XandertjeKnal (Xander)]

The client firing more often than should be possible indeed seems like a sign of a client exploiting. Make sure to test your system enough to avoid false positives caused by a player’s slow or unstable internet connection. I’m unsure if Roblox queues up remote requests (and fires them rapidly when the connection is back) or ignores them in these cases.

In any case, it’s good practice to make sure nothing happens when the event is indeed exceeding its expected limits.

(Sorry for the late reply.)

[IDoLua (CantBeBothered)]

This is a very late response and I like Xander’s response above, but no you probably shouldn’t just be kicking players that fire a remote like that.

Let me put it into a reasonable ideal:

• Using this module, you can limit all players requests very simply.

• If you do it right, there’s no difference from an exploiter and someone with a really good macro or someone on a constant grind.

So rather than finding edge-case solutions for punishing the exploiters (who you cannot truly differentiate,) you should instead focus on making their exploits less harmful to the balance of your game.

[IConsumeCheddar (DerangedDevforumUser)]

sorry for the slight bump but i cant seem to get this working on my gun, it only works once for me

for context the gun is completely client sided and the bullets and audio are handled on the server

this is the server code:

FireGun.OnServerEvent:Connect(function(plr)
	local gun = plr.Character:FindFirstChildWhichIsA('Tool')
	if gun:FindFirstChild('GunModule') then
		if gun and FloodCheck:Check(plr, FireGun, require(gun.GunModule).commons.Rate) then
			if GunFires:FindFirstChild(gun.Name) then
				local sfx = GunFires:FindFirstChild(gun.Name)
				local firesound = sfx.Fire:Clone()
				firesound.Parent = gun.Handle
				firesound:Play()
				firesound.Ended:Connect(function()
					firesound:Destroy()
				end)
			else
				plr:Kick('Error: Could not locate cooresponding gun sound')
			end
		end
	else
		plr:Kick('Error: No gun module')
	end
end)

if you need more info let me know

[commitblue]

no, make the ratelimit both in client and server, and if server detecyed it reached that limit irs very obvious its an exploiter and you should kick it.

[XandertjeKnal (Xander)]

You should probably add some leeway in the rate of the flood check and not make it equal to the exact firing rate. This accounts for a variable networking delay etc.

I’d also recommend handling the sounds and effects on the client and not on the server. This will decrease latency and will make your guns feel more responsive.

With your supplied code, I’m unable to tell what’s preventing your gun from shooting a second time. Perhaps it’s the code running on the client? Perhaps Scripting support could help you out further? If after debugging, you believe it’s my module that’s the cause of the problem, then feel free to DM me and maybe we can help each other to fix it. (DMing for other help is fine too, but the scripting support forum is likely quicker.)

[IConsumeCheddar (DerangedDevforumUser)]

i’ve already fixed this issue, i just used a table with the players user id, though ill provide some answers if i want to use this in the future

@XandertjeKnal

You should probably add some leeway in the rate of the flood check and not make it equal to the exact firing rate. This accounts for a variable networking delay etc.

i have tested it in game with a friend and it seems like there isn’t noticeable a delay to the sound or bullets

@XandertjeKnal

I’d also recommend handling the sounds and effects on the client and not on the server. This will decrease latency and will make your guns feel more responsive.

yeah, i was just doing that temporarily since i just wanted to get the main system done first

@XandertjeKnal

Perhaps it’s the code running on the client?

i don’t think so, all the script did was fire a remote event with no parameters