Yes, UDP would take half the time that TCP takes. Doing a reliability wrapper around UDP is no different, its just making sure the packet actually gets received. You get the best of both worlds. Also, if a packet gets lost in TCP, basically everything is frozen until that lost packet is resent. UDP does not have this issue
The official lua documentation has all the information on it but as it so happens roblox just also released the buffer type which is a more intuitive way to read/write binary data.
As for compression, at the very least it gets rid of the overhead of various data types since you would be doing the work of serializing the data for the engine knowing better how your data structure looks like so you wouldnāt need to waste bytes to define what the next X bytes should be read as and allows you to use less bytes if you donāt need the precision of the Double-precision floating-point format or know that the variables you are serializing is an integer within a certain value range.
- A number sent directly via a remote event would use up 9 bytes since it would be sent as a FP64 with 1 byte of overhead which defines the remaining 8 bytes as a FP64
- A number serialized as a double would use up 8 bytes as you would get rid of the overhead in exchange for a small amount of overhead from the string itself
- A number serialized as a FP32 (which is what Vector3s use for example) would use up 4 bytes
- A number serialized as a unsigned short integer would only accept integers in the range from 0 to 2^16-1 and would only use up 2 bytes
- A number serialized as a signed byte would only accept integers in the range from -128 to 127 and only use up 1 byte
3 Likes
TCP takes a while because there IS that reliability and order wrapper with it. Making a TCP-like UDP with wrapper would result in the same, maybe worse performance as itās not native. I donāt see how UDP with wrappers to act like TCP would be better in any ways.
1 Like
Since nobody could provide an answer, I found one myself:
Yes, you can develop a protocol on UDP that simulates TCP. However, if you simulated TCP fully, it would technically have more overhead. Because TCP is implement as the packet and your simulated TCP is implemented in the body of the packet.
If you only need one or two features of TCP (such as basic ordering), then implementing it in UDP is useful.
Via StackOverflow. So thereās the answer, making full TCP out of UDP makes no sense unless youāre only using very few TCP-like features that would actually outweigh the cost of processing time and weights added to UDP caused by adding those extra layers.
A lot of the replies I got on my comments were very disjointed and sometimes didnāt even address what I said before, please remember to read the full thread before replying.
1 Like
Is there any notable performance difference or any other difference besides the reliability and order of it?
2 Likes
I donāt understand this. Is it just theres a little math.random() built in to it when it fires?
2 Likes
In a wayā¦ kind of. Rather the math.random() is built into the real world! When you send a message over a wire or wireless connection thereās a random chance it will get corrupted by noise or interrupted by other messages.
Normally with a RemoteEvent the engine does extra work for you to automatically re-send in the case where a message got lost, but that comes at the cost of extra latency. With an UnreliableRemoteEvent there is no automatic handling so you have to deal with potential unreliability, but in return you get lower latency.
11 Likes
It finally happened! Iām so excited to implement these in my games, canāt wait! Thanks to everyone that worked on this update! 
1 Like
If I am not mistaken, this should provide better performance and less latency/lag at the cost of being unreliable.
This remote event IS NOT intended to be an replacement for your weapons firing, button presses or player interaction.
This type remote event is what you would use for systems that make use of a buffer or where data is constantly being send over but there is no need for all data to arrive.
This type of remote event is what you would use for custom player movement.
The server does not need to know every move a player makes, when the game is experiencing lag, data is going to get dropped / lost to free up space and you predict player movement to compensate for that.
99% of the time you will not need and shouldnāt use this.
Itās usecases are very niche and specific but extremely useful for people who know what itās good for.
5 Likes
Thank you! That clears up a lot for me.
1 Like
Best uses would be constantly updating player position, Arm positions, Head position and other things that are constantly updated but have no crustal Impact on gameplay.
Unreliable events cost less bandwidth so they are best used for that.
1 Like
ROBLOX Corporation reminds you that the Unreliable Remote Event will never threaten to stab you and, in fact, cannot speak.
7 Likes
this is the best christmas present of the decade
1 Like
yes I love my remotes dangerous and unreliable
In all seriousness, this will be a very very small yet hugely impactful feature that will make it much easier to improve performance. Small things with large impacts are my favorite!
4 Likes
I really wish these had an event for packets being dropped. That way developers can choose to fire it again, which would effectively make it a regular remote event but without pausing networking if a packet gets dropped.
Also that 900 byte limit is a massive bottleneck for rollback netcode. I canāt really use this to fire game states to the client, only commands. I COULD technically split state replication up into multiple remote calls, but roblox lacks some fundamental features to make this efficient such as a way to figure out how many bytes a payload has prior to firing it.
Fun fact, this isnāt actually possible to include!
The only way to ensure reliable communications is the recipient sending an acknowledgement back to the sender when they get the message. If the sender gets no such acknowledgement they will eventually try resending the message. The longer the sender waits without getting an acknowledgement the more certain they become that the message was dropped, but thereās no particularly good point in time to say ānow I know it was lostā and fire the event.
7 Likes
What kind of game state?
Depending on what you actually need to send over, you could probably compact the data using the new buffer data type.
1 Like
What makes it useful for visual things such as particle emitters?
Secondly, what determines the bytes it carries, is it the arguments you send via the remote? i.e., if Iām sending a character model as an argument compared to a string as an argument?
2 Likes
This isnāt possible sadly, as mentioned by tnavarts. This is called the Two Generalsā problem.
4 Likes
Right now everyone are kind of just guessing what each datatype costs on a remote because they are not documented at all. Whether Roblox puts more effort on the documentation or gives us a tool to introspect remotes or whatnot. We just need something to help us catch bugs involving hitting the 900 bytes limit so
these things do not sneak into production.
3 Likes