RemoteEvents do not guarantee delivery

Sometimes, RemoteEvents which are fired are no longer be received by the server.

And honestly now remote events are a combination of some of the worse parts of UDP and TCP so I’m kind of salty.

edit:

9 Likes

It looks like this feature is to prevent exploiters from hacking games.

However, this is a significant issue with anti-exploit systems which assume reliable delivery of remote events, including ordered events. I think a lot of games might kick players if they loose a remove event.

As far as I know ordered-reliable delivery is a contract of remote events.

5 Likes

This has been a major issue for me to the point that I had to find another way to get important messages across. It’d be great if we could have some Roblox engineer comment on this issue.

That is unfortunately not true

I misinterpreted the below quote based on misinformation in a different thread! See reply below

https://devforum.roblox.com/t/topic/30169/6

2 Likes

Well in that case it’s clear that they don’t want us using Remote Events how we’re using them, but they also give us no viable alternative. So I’m going to push for this: UDP RemoteEvent - #2 by GollyGreg
And then recommend that remote events are changed to guaranteed order and delivery

2 Likes

That comment is a little out of context. It was explaining that we don’t use TCP and that simple UDP usage could result in “most up to date” being backwards in some cases. Roblox uses a protocol on top of UDP that handles reordering/retransmission (and multiple ordering channels).

The remote events should be reliable and ordered /wrt other datamodel changes sent from the client including other remote events sent from the client.

The remote events should not be dropped when this message is displayed. the current behavior should be to queue them and process them at some rate. It is possible that the events lose relevance over time and might become invalid.

4 Likes

Okay good to know that they’re guaranteed in order.
Why delay reception when we can delay reception in Lua and do a better job of it by rejecting and ordering requests as we deem fit?

3 Likes

that is an option. It would need to make sense when included with engine remote events as well as remote events that game devs don’t have access to.

1 Like

To add a bit more context to this. I was using the unofficial FPS unlocker when this happened, which I believe also increases the rate of which the client sends events to the server in general due to the task scheduler not running the typical enforced 60hz rate.

1 Like