it does not look like you have setup your response correctly
I believe thatâs not possible. The type solvers are just stupid.
would be great to see some kind of queue if packet isnât created yet. Is it going to be implemented ?
I donât have any planes to implemented queues
Hey you have 3 memory leaks, 2 major one minor and also a minor vulnerability. First memory leak is the time out function, you use Task.Delay to create a timeout function for both Fire and FireClient respectively but you never clean up the player threads entry. You can parse in the threads table and index, then clean it up in the timeout function to fix that. Second major memory leak is an overlook in your variable naming, in your remote.OnClientEvent you cleanup the thread entry like this threads[threadIndex] = nil but that doesnât actually cleanup anything because you overwrite the variable name âthreadsâ right beforehand. For the minor vulnerability you automatically assume the packet id is valid, an attacker can provide an initial invalid packet which will in turn prevent any other valid packets in the frame from being processed. Itâs minor because an attacker can still accomplish this affect by simply choosing what data is sent but it should still be addressed.
Leak 1:
Iâm not seeing the leak you speak of here playerThreads[player] is set to nil when the player leaves the server
Leak 2:
I see this one this would not cause a memory leak because once the id gets to 127 it will wrap back down to 0 but ill fix it thanks for pointing it out [setting to nil is mainly important for the server so that a client cant resume a already resumed thread]
Leak 3:
what is leak 3?
Vulnerability:
if the packet id is not valid the server will not know how many bytes it need skip to read the next packet so it has no choice but to reject the entire event this is not a vulnerability it just means the server expects the data to be perfect and if the client sends invalid data the event will be rejected this does not prevent other packets from other clients only the client sending invalid data
Leak 1:
Just because the playerThreads is set to nil when the player leaves doesnât mean the entries arenât filling up during the actual gameplay of the player. If the request times out, the thread will never be cleaned up until the player leaves and that is an issue.
Leak 2:
If it wraps back and re-uses same indexes that works 
Leak 3:
If i remember correctly it was related to not cleaning up pending tasks when the player leaves, I will double check later
leak 1: oh I see it now this also wraps round after 127 and reuses the same indexes so if it times out it will be overwritten there wont be a memory leak but there is a small vulnerability with the thread staying in the table so ill remove it
leak 3: if a player leaved before responding it will just timeout
Update 1.7
- Fixed vulnerability
if a thread times out and then you yield that same thread, client is no longer able to resume that yielded thread - Fire/FireClient will now skip thread ids if there in use
- Fire/FireClient will now error if you have more then 128 yielded threads
1 Like
The standard method of disconnecting a RBXScriptConnection doesnât work. Is there any other way?
self.NetworkConnection = Networking.OverrideMovement.OnClientEvent:Connect(function(OverrideToCall, Data)
self[OverrideToCall](Data)
end)
self.NetworkConnection:Disconnect()
I think this would be great here to do some checking and proper error explanation. I came across the same error and spent a good hour trying to figure out the issue before, thankfully, coming across this.
This should work Iâll double check when I get home
1 Like
I just tested this and it was working fine for me