So I understand how RemoteEvents and RemoteFunctions work themselves.
I’m just trying to understand Remotes better for optimization and overall functionality.
It would also help with simplifying code and reusing certain remotes/bindables.
I’ll separate my questions into 2 categories:
RemoteEvents:
When I fire a RemoteEvent, does it fire to every receiver function for that one RemoteEvent?
Is it a 1:N relationship?
(Assume that the receiver functions are in different scripts)
If it does:
How is it processed, are each of these function “receivers” ran concurrently or are they in sequence? Is it automatically separated among multiple threads?
By sequence, I mean running each receiver function one by one.
RemoteFunctions (Similar Questions):
When I fire a RemoteFunction, does it fire to every receiver function for that RemoteFunction?
Is it a 1:1 relationship?
(Assume again in different scripts with different receiver functions)
When it is processed, does it somehow run concurrently and able to track where it came from for the appropriate callback path?
Does it proceed throughout and wait for each callback one by one in sequence?
Remote events fire a signal, and any script that listens for this signal will respond. Functions connected to event signals will run on independent threads on every fire. These are synchronous by the nature of separate threads. For optimization, use these signals to note unpredictable changes in gameplay rather than predictable loops.
So for example, say you have a server script that counts down some number and sends signals to the clients so this countdown can be displayed in a UI. Send one signal to mark the start of a new countdown, and each client script can run its own countdown thread.
This way you only send one signal. This is O(1) where as a loop would be O(n). The number of scripts that receive the signal do not matter so much in optimization as much as how many times you fire the signal.
Now, remote functions are a bit different. The functions defined by these can be better named ‘Handler functions’, and there can only be one server handler function and one client handler function per remote function. So you only want to define the handler function in one script, however multiple scripts can use the same remote function. Remote functions can be concurrent in multiple threads, but not the same thread. Again the optimization notation is defined by the times called rather than the number of scripts that utilize it.
RemoteEvents incorporate signals so they pretty much work the same way as any other event you’ve worked with, except they cross the network boundary when sending their signals. For RemoteFunctions, the flow is a little different but it’s still about environment crossing.
RemoteEvents
Any connected listener (not a receiver) will be called when the event is fired. Think of it as some functions waiting until being signalled to run through the event being fired.
Lua is single-threaded so they can’t be ran concurrently, they are ran in sequence. Listeners are scheduled in such a way that this sequential resuming is virtually invisible and it does seem as though the listeners are called concurrently. I’ve asked about this before and you can see a response from a staff member about it here:
RemoteFunctions
A RemoteFunction cannot have several listeners - it, in fact, doesn’t have any. You can only define one function that will be called when the RemoteFunction is invoked and this is per environment (once for the server, once per client).
Like RemoteEvents, RemoteFunctions must be scheduled sequentially. I do not believe you can invoke while an active invoke is being processed - it either gets rejected or queued. I don’t remember, I don’t use RemoteFunctions at all honestly.
One last question on Remotes. When a RemoteEvent is fired, does the script wait for whichever fired listeners finish their functions before continuing throughout the script?
I know that a RemoteFunction must wait for a callback.
RemoteEvents work in the spirit of any standard event. They’re fired asynchronously, so a thread will not yield during its execution. The only exception is if you wait for the signal to fire, which then of course yes the thread will yield until the signal fires. Examples being: