Are remote events a reliable form of communication?

Other than the queue filling up, is it possible for a remote event fired by the client to be dropped? Does Roblox handle reliability for us?

Remotes run over a variant of UDP with some TCP reliability features.
In theory, they shouldn’t drop.

9 Likes

I would like to add that if it’s really so essential that something the client sends not be dropped that you’re asking this question… then you should take a second look at your networking architecture.

The client could disconnect or fail / deliberately send you bad data / get hit by a meteor at any time. You shouldn’t be relying on them to do something that so strongly “must not fail”.

8 Likes

Is corrupted/incomplete data filtered by the server or is it processed and forwarded to Lua anyways?

As long as it’s still “valid” in terms of Roblox’s protocol, then yes. Just because it’s still a “valid” Roblox replication doesn’t mean it will necessarily be “valid” for your specific game’s networking architecture though.

An exploiter can do things other than send Remote calls that they weren’t supposed to, they can also not send Remote calls that they were supposed to send.

There are several design flaws with the API of remotes that should be considered:

  • Avoid calling RemoteFunction:InvokeClient. If we assume that a client is malicious, then that client can choose to avoid responding to the call, which will block the calling thread on the server indefinitely.

    How safe are RemoteFunctions?

  • Only have one listener connected to a RemoteEvent at a time (per peer). The design of RemoteEvents interacts poorly with the design of signals. That is, when multiple listeners are connected to the signal, all events will be received, but not necessarily by every listener.

    RemoteEvent fires before :connect returns

3 Likes

TL;DR if you know anything about networking:

  • RemoteEvent:Fire() === Socket.Send

  • RemoteEvent.Event === Socket.Receive

  • Basically just don’t use RemoteFunctions at all, or use them exceedingly sparingly

That much seemed obvious to me as soon as they were created. I guess it isn’t as obvious to someone who hasn’t otherwise played with networking code before.

5 Likes

I sometimes use RemoteFunctions from client to server, sometimes wrapped in a Promise. These are for actions the player takes that are clearly input -> output reactions, such as placing a new item on a boat.

I don’t think this is particularly unsafe as long as you’re aware a function may yield.

I basically only use RemoteFunctions for the “initial load” task from the client, when the client literally doesn’t have anything to do other than wait for the server to get the data it needs to start up. I think for most people it’s good advice to never use them for anything other than that, because they’re likely to tangle up nontrivial code with ugly race conditions (I don’t even trust myself to use them).

Using RemoteEvents can sometimes make the code more complicated than it needs to be at first glance, but really the comilications it adds probably existed with the RemoteFunctions too… you just weren’t thinking of them.

1 Like