Lets say you have two Remote Events, Remote Event A, and Remote Event B. If the client fired Remote Event A at 1000ms ping, and then 500ms later, the clients ping dropped to 50ms, and then Remote Event B was fired, would the server receive and process Remote Event A or Remote Event B’s first.
This is relevant to a system I am currently working on and I appreciate any replies, thanks.
This isn’t an answer, but, you should never ever rely on RemoteEvents, especially not on their asynchronous aspects, to uphold predictable behavior. That’s not their purpose, raw networking is meant for fast & cheap signalling. It just doesn’t have enough guarantees to be trusted in such ways.
Instead I’d suggest taking advantage of replication, syncing state via properties, attributes, etc.
If the remotes fire constantly and in short intervals for client ping to be an issue, you may want to consider UnreliableRemoteEvent that is basically a simpler version of normal remotes that acts as a packet with a slight chance of loss (instead of guaranteed receiving like normal events). This can be used for things such as transmitting frames of a live video, or the shots of a player gun, or the position of a moving client object (like their character). Basically any sort of data that is transmitted frequently and can be “fixed” through the use of prediction systems. If you implement such prediction systems, you will also be able to handle the timing issue more effectively (for example if the client throws a ball, and you get a remote with a position that is directly opposite to the current velocity of the ball, as if it is back in time, you can assume it’s a delayed packet, and ignore it).
You can think of it as multiple clients sending claims of their current situation very frequently to the server, and the server, using clever math, figures out the missing parts and the current state the game should be in.
Also to quote a useful part of the documentation page of unreliable remotes:
These events are not resent if they are lost and they do not wait for previously fired events to arrive before being processed, potentially resulting in reduced latency and network traffic. When you need ordering and reliability, use a RemoteEvent instead.
So according to that, if you want ordering you should use normal remote events. However, if you plan to spam it, you should switch to unreliable events and prediction mechanisms as mentioned above.
RemoteEvents are ordered by default.
In the server, your connection to the remote, say B, will not run before A if you fired it first no matter the ping.
Thanks for the help, everyone, I appreciate it lots.
Roblox remote events do have predictable behavior and are ordered
RemoteEvents themselves may be, but that’s not my point. Networking inherently involves entropy, which is not ordered, not predictable, nor deterministic. The mere existence of UnreliableRemoteEvents only supports this, because it is Roblox admitting that they have to go above and beyond to make sure a RemoteEvent is delivered. Yet RemoteEvents can still be dropped, because they are meant to be signals (i.e “this happened”), not replicators (i.e “this is the current state”). Which means no matter how “reliable” they are, they’ll always be susceptible to entropy.
In this case the OP clearly has hard state dependency on the order of events. Which can cause catastrophic state corruption if/when an event is dropped. That’s why replication exists, and is most likely a better fit for the OP’s use case.
RemoteFunctions can also be an option. They stall until the server responds. This can be useful in some situations where you don’t want to proceed on the client until the server has responded. If the function times out then you know the connection is unstable.
Messages from the same remote (RemoteEvent) are guaranteed to be ordered and reliable… BUT there is no guarantee that the call order of two different remotes will also be ordered on receive.
As far as I know they use a shared queue, supporting their predictability and allowing for ease of use. But I could be mistaken.