I couldn’t come up with a better title so let me explain:
Is there some kind of optimization going on in the background for data sent via RemoteEvents?
I have a RemoteEvent that is fired very frequently and thus was looking for ways of optimizing it.
I was wondering whether it made sense to for example restrict a number to a maximum integer value of 255, so 8 bits assuming that the data is then translated into binary.
Not really, but there’s not really a way for them to. You basically want to make sure you send as little data as possible. Roblox caps client to server (and vice versa) to 50kbs/s not including physics. That’s 853 bytes per network frame (tied to fps).
That doesn’t mean you can send that much because Roblox is already sending some, but you can send a decent but before throttling kicks in. Once you start going over this limit data is queued to be sent. Sending too much data for too long will increase a players ping over time for seemingly no reason. This is actually a problem a lot of big games run into and if you’ve ever seen a game which appears to be having massive server lag try opening network stats and check if the data being sent is more than 50 kbps.
Chiming in here, but I thought the rate was 60kb/s. Has the limit changed or has 50 always been the limit? Could’ve sworn it was 60.
Obviously I understand the concept but I don’t think that it relates to my question. In my original post I kind of imply that I am trying to lower the amount of data I’m sending.
Now the question is whether ROBLOX does optimization as you would find it in other programming languages where different data types take up a different amount of space in RAM (think tinyint, smallint, bigint).
If ROBLOX just assumes any number sent over RemoteEvents is a 32 bit integer then obviously there is no point in me to artificially limit the number to one that would at max take up 8 bits over 32.
There exists a soft limit at 50 kb/s at which point stuff like physics replication starts getting throttled.
For remote events such a limit doesn’t exist and you can send as much stuff as fast as you want as long as the client can handle it, which is actually quite dangerous if you replicate stuff constantly since as @Hexcede described stuff gets queued up on the server once you go past the maximum download speed of the client and as a result the ping rises, possibly even ad infinitum as long as the constant datastream is larger than the downloadspeed of the client.
Certain datatypes get compressed like cframes, integers on the other hand will not get compressed like that.
If you want to use compression to decrease your network traffic you would have to do this yourself.
For example using an obscure datatype like Vector3int16 instead of Vector3 will roughly halve your networktraffic as long as you are only sending integers between -32768 and 32767.
If you only want 8 bit numbers you could compress them into strings using string.char which should in theory take up even less bandwidth.
I don’t think that my example counts as compression since it doesn’t need to be decompressed to be usable. I assume that the data ROBLOX sends is translated into binary. Of course that assumption may be completely wrong so I hope someone can shed some light on that.
Let’s take my example number of 255 (the max integer value of 8 bit) which we are sending over a RemoteEvent:
Option A → ROBLOX does not optimize this number and translates it to a 32 bit integer which looks like this 0000 0000 0000 0000 0000 0000 1111 1111
Option B → ROBLOX optimizes this integer realizing it fits within 8 bits and sends this instead 1111 1111
That is considerably less data that needs to be sent under my assumption.
That is a very good tip, thanks! Unfortunately it is very much just theory until someone qualified can confirm it.
Roblox assumes that the number is a 32bits unsigned integer at all times. It does not attempt to do any kind of compression when firing remote events.
In order for Roblox to send datatypes they must be converted into a safe format. My assumption is Roblox sends numbers similar to how they do in their custom number format used in rbxm files. Strings I would assume also send this way. Both formats are relatively efficient which is why they are used. I don’t think that what you’re asking about is documented anywhere and I doubt that anyone except Roblox staff members can answer your question.
You can do some simple testing to see how much data each data type takes by sending the same data over and over and watching the network usage.
Also @colbert2677, this data limit is currently 50 kbps according to documentation here: Custom Events and Callbacks | Documentation - Roblox Creator Hub. I’m not sure if this was different at some point but supposedly this is the current bandwidth.
I know for a fact Roblox supports 64 bit floats being sent over the network. I believe all Roblox numbers are 64 bit now and depending on if the number is integer-like or decimal-like it will be converted into integer/float formats. Also I can almost guarantee compression takes place somewhere. Try sending an 853b string over the network every few network frames and watch the data usage. Usually this doesn’t get anywhere near what you’d expect for non-compressed data.
As far as I know, generally compression is used in most large-scale game engines especially if the game engine is targeting low end devices and internet. I suppose you could check if compression takes place by monitoring traffic Roblox sends and attempting to analyze the data.
I did a simple test in an emty place by sending an integer between 0 and 2147483647 via RemoteEvent and it seems to confirm what @arissgr said.
There is no visible difference in throughput however there is quite a significant improvement when using string.char- Obviously this only applies to a number of up to 255 (Thanks to @Flostrus).
Hmm well I may be wrong. Also @Flostrus I know its a soft limit, I explained that data is queued after 853 bytes per network frame.
Citation? I’m fairly sure they are passed as 64 bit floating point numbers since that’s what Lua numbers are.
