What are the downsides if any to using a single RemoteFunction for all Network Traffic between Server and Client

So recently I have been exploring neater and more optimized ways to handle network communication between the Server and Client with minimal delay. Previously I used one Remote Function/Event per Function however recently I’ve switched over to using a single RemoteFunction for all Server to Client communication a visversa.

I’ve searched the topic but have gotten many mixed reviews, some saying it’s extremely bad to use a single RemoteFunction and some saying it has no impact.

If possible could I get some clarification on this and possibly and insight into how some of you guys handle said communication? Thanks!


As stated on the Developer Hub

" Be mindful in your usage of remote events and functions. If too many requests are made between the server and the client, or if too much data is sent at once, the game may begin to lag for connected players. "

The most discouraged type of communication is

From :


Hence sending too many requests does in fact cause latency problems.

Every time a remote event is fired or a remote function invoked,

a packet of data is sent over the network between the server and client. This packet is counted towards the 50 KB/sec limit. If too many packets are sent (remote event or function used often), or too much data is sent per packet (lots of large arguments to the event or function), the latency of the connected clients can be adversely affected.

I recommend , however , when using one event for each function, to use the Disconnect() method of the connection object returned by Connect() .
if that event is not going to be fired many times.

However using a single remote event for multiple scripts is never encouraged ,

for example when for whatever reason the RemoteEvent is fired, all functions depending on it will run at the same time , thus proving to give rise to another Latency issue, (dependent on the amount of functions that’ll run and what they will do) .


It’s also important to note that remote events do have limitations, of a 50KB/s of data sent per remote event sorry for the wrong info, it’s per client, meaning all the remote event traffic in one client grouped together shouldn’t surpass 50KB/s, but when you come to think of it, you rarely send huge piles of data to the client and especially receive from the client (exploiters), and even if you do, you’d barely hit this limit. When you send something over the network it’s all converted to a string during the sending (serialization) and then converted back to its original form, so that means you are able to send a 50KB chunks of text, which is basically a 51200 characters long string. That’s a lot.


I read somewhere on Twitter where Roblox staff confirmed that using a single remote event is (a bit) slower than having multiple. Just think of it as a queue for a cinema.

If there is only one person checking the tickets for 400 people it’s going to take longer, if there are two it will be faster. I’m not entirely sure if the analogy is correct up to this extent, but I think it’s valid to prove my point.


Go with whatever works for you.


You’ll be fine either way. Personally, I choose to automatically generate a Remote object for each “key” I use, but this is completely automatically handled through my Network module, which is an abstraction of RemoteEvents. If I wasn’t using my module, I would just use a single Remote object, because dealing with lots of instances for no reason is a waste of time. (I don’t understand why Remote objects are instances to begin with, this is entirely pointless and just creates more work).
I also replicate the behavior of RemoteFunctions using RemoteEvents, because RemoteFunctions suck.


As stated, there are many downsides to using a single RemoteFunction to control all your interactions between Server and Client. The most important one is the Latency issue, as stated. If every client and server is reliant on one, reused remote, you can imagine its usage on a queue. Each subsequent request is waiting on this remote’s callback before it can perform its necessary functionality. Especially when being used across multiple scripts for different functions. On top of this, the time can grow longer with more required overhead as you would have to do a lot of messy management to control the data you are sending and/or request through the remote. If there are any looping functions called when the remote is accessed, it can cause the overhead time to be further increased.
On top of all this, we can analyze from the exploitation side. Modern day exploits work by injecting a script from the client side. Since they are able to see your remotes from the clientside, they can fire them through their injected scripts. By having one remote control everything, you pretty much tell them that they only need to figure out one key to your game. And with an understanding of your remote, they can pretty much control everything your remote accesses.


A single RemoteFunction and RemoteEvent doesn’t equate to neatness. In some cases, it can actually lead to your processes becoming more muddled and confusing to work with, because now you’re also going to have to account for many different functions and parameters.

I never recommend working with single remote structures. Always have multiple hanging around - not for every single client-server interaction needed, but just enough. In cases where you can avoid using remotes and just handle things on the client or server, do so and avoid consuming bandwidth.

Typically you won’t experience any impact between using multiple or just one but they’re all bound to the same limitations so you might as well just do what makes you most comfortable. I prefer multiple for the sake of readability, organisation, functionality and so on.

RemoteEvents will inherently be bottlenecked by the time it takes to send a signal across an environment, whereas for a RemoteFunction the bottleneck is a round trip (send a message, execute some code, wait for a response to that message).


Honestly I agree with you on “just use a few for the sake of your code not getting hard to work with”, but I also have to say that if you are using a RemoteFunction/RemoteEvent for 2/3 functions with similar arguments (perhaps just one or two booleans) I think it’s much neater to just use a “Type” argument as it reduces the amount of instances you have in ReplicatedStorage.

Booleans as arguments/parameters are often indicative of code smells. You’re more than likely running into a case where you don’t even need a remote in the first place. I don’t recommend the type argument because that is a more isolated version of the larger problem that this thread presents.

I agree, but sometimes you may pass a string and a boolean for whatever reason, is how I should of worded that. But on the whole yes I agree, but using the same remote event for 2/3 things can be easier is my point.