Should I use JSON Encode/Decode when sending data from the client to the server or vice versa?
How much would this alleviate the stress on the network due to sending to much data?
Why doesn’t everyone use this?
What are the down sides??
I would first think why I need to send this much data and look for ways to reduce the amount of data being sent or send data in smaller parts with longer delays.
Another option could be to serialize the data?
“Roblox server can only send and receive about 50 KB/sec of data to each client, not including physics updates.” Remote Functions & Events
In any case sending a large amount of data to the server or client is not the best idea to start with. If you can compress the data then this might help but it is a trade off between saving network and using more processing power for both devices.
Not as far as I know. In any case you would use the console to check for network usage over time. It is also possible to simulate IncomingReplicationLag by going to File -> Settings -> Network -> IncomingReplicationLag Fighting Against Lag.
hope this helps.
1 Like
Roblox already encodes data sent over RemoteEvents in JSON. Doing this yourself would just make things slower.
EDIT: This is incorrect, as @Anaminus said JSON is not used for remote event serialization.
6 Likes
If you’re working with remote events, you shouldn’t have a need to encode a table or any arguments in JSON. It’s certainly not necessary. You can already access tables just ust fine on either end that is receiving the argument.
If you’re concerned about lag which should not be an issue if you are not exceeding 50KB/s, put your remotes elsewhere. Have “local networking” - your client and server aside are only applicable to a single client and they call only their own remotes.
JSONEncode, as far as I’ve seen, has really only been used to double down on data for DataStore values, but I haven’t seen it used outside of that. Irrelevant though. No one encodes their arguments because there’s no reason to. As for downsides, you’ll probably get slower results over not using JSON methods.
Wait, Roblox does that? I thought raw tables are sent. Does printing a table argument not yield a table variant, thus not being JSON?
1 Like
It automatically marshals and demarshals the table for you. I don’t know if it is actually JSON or a JSON-like format, but either way encoding and decoding it yourself would be unnecessary work.
3 Likes
Doing this is like wearing two pairs of sunglasses at once. As has already been mentioned, RemoteEvents already use JSON the packet serializer (thanks Anaminus) to encode and decode tables sent over the network. There are a few ramifications:
- If a table has an associated metatable, the metatable will be lost.
- Keys may not be mixed; i.e. they must all be strings or must all be integers:
local myMixedTable = { -- bad! [1] = "myValue", ["myKey"] = "myValue" } local myDenseArray = { -- good! [1] = "myValue", [2] = "myValue" } local myTable = { -- also good! ["myUniqueKey"] = "myValue", ["anotherUniqueKey"] = "myValue" } - arrays must be dense, i.e. they may not contain “holes”
That’s datastores. Values passed through remotes are encoded with the packet serializer. The behavior of the two APIs appears to be similar because they involve the same Array and Dictionary reflection types.
9 Likes
Was just about to say, because you can send circular references in remote events, which doesnt work with json.
So should i JSON my data when sending it to remotes???
You shouldn’t need to. As people have already said on this thread, any data that you pass through a remote should be able to be accessed on either end, be it a table or string or whatever. JSON-encoding your data will just make it slower.
1 Like
If you’re sending a lot of info at once to the client, you’re better off compressing it on one end and de-compressing it on the other end.
In my case, I send the information for every item in my game’s market to the client when it first joins the game, then it de-compresses the information and stores the item info locally. This allows me to have a shop client that is smooth + fast for people with lower end devices / internet connections.
No, you shouldn’t. You’re not going to beat Roblox’s packet serialization, except maybe compression (I’m not sure if Roblox already does this, though they easily could). Even then, JSON is a terrible format for this purpose.
There’s a reason why the encoder/decoder is located under HttpService. Stick to using JSON only for communicating with external web APIs. In all other cases on Roblox where JSON could potentially be used, there’s already a better way to do it.
2 Likes
JSON is generally more compressed than XML, but is still horribly bulky. Does anyone know what type of compression is used on rbx files sent to roblox clients? Like the one found here for the default black baseplate place: https://assetgame.roblox.com/Asset/?id=95206881
The headers say gzip encoding, but they must have specified a different compression method as most tools wont decompress it.
As for conserving space… JSON wont do that for you. Make a custom application-level format that is pretty dense (don’t use strings for numbers, shorten tags, ext) and then run gzip over it. Any server will be able to decode it if you use these RFC’s: gzip, DEFLATE (gzip’s default compression method supported everywhere)
Edit: Look like these things have already been implemented in pure Lua (without a C library to help) found here: GitHub - davidm/lua-compress-deflatelua: DEFLATE (RFC1951)/gunzip implemented in pure Lua I’d also note that compression is a speed to memory trade off.
Edit 2: Unfortunately the link above says they only implement decompression of deflate, so that probably wont do since we are trying to send compressed data.
Edit 3: PostAsync has a boolean compress argument that should work to send compressed data.
Edit 4: +1 to @zeuxcg on this (proposal to expose compression utilities)
1 Like