Why you should Avoid net.WriteTable and which alternatives if cant

[JustPlayerDE]

Suggestion:

Alternatives to net.Write and net.ReadTable and why you should avoid sending tables if possible.

example alternative:

-- More optimised way of sending tables via net messages
-- Writes the table like net.ReadTable(), but its using Data for the entire content instead of WriteType for each key/value
-- and also compresses the table
local function WriteTable(table)
    local data = util.Compress(util.TableToJSON(table))
    net.WriteUInt(#data, 32)
    net.WriteData(data, #data)
end

-- Returns the table like net.ReadTable()
local function ReadTable()
    len = net.ReadUInt(32)

    return util.JSONToTable(util.Decompress(net.ReadData(len)))
end

Gamemode:

None

Relevant resources:

https://wiki.facepunch.com/gmod/net.WriteTable

[JustPlayerDE]

(and maybe a small notice that you should never allow sending tables from client to server because this can crash or lag servers if not done correctly)

[patrickratzow]

Your suggestion has serious issues with CPU usage if it's called often.

You should just not rely on networking a table in the first place, just network each part of the table individually, and reconstruct the table on the client. Networking tables can be done with smaller tables.

I tested your method and have some comparisons to make.

net.WriteTable (raw): 15896 bits net.WriteTable (compressed): 3783 bits Sending each part individually and reconstructing the table: 1683 bits

This is only the network length, and does not account for the large CPU overhead of compression if called very often.

[patrickratzow]

Also, not to mention util.TableToJSON has issues with sid64s.

If you use a sid64 as a key in the table it'll be converted to a number in the JSON. When you transform the JSON to a table later on it'll stay a number and lose precision due to its size.

In practice, this means that the networked sid64 is useless as it's not actually equal to a string sid64 due to precision loss.

[FoksVHox]

Your suggestion has serious issues with CPU usage if it's called often.

You should just not rely on networking a table in the first place, just network each part of the table individually, and reconstruct the table on the client. Networking tables can be done with smaller tables.

I tested your method and have some comparisons to make.

net.WriteTable (raw): 15896 bits

net.WriteTable (compressed): 3783 bits

Sending each part individually and reconstructing the table: 1683 bits

This is only the network length, and does not account for the large CPU overhead of compression if called very often.

That is why he suggests a video on the why you shouldn’t network a table.....

[patrickratzow]

Just pointing out that his suggestion sometimes would be a very bad choice, and you should be aware of its consequences. Using it uses a lot less development time, but you still have less efficiency & higher CPU usage.

[JustPlayerDE]

Just pointing out that his suggestion sometimes would be a very bad choice, and you should be aware of its consequences. Using it uses a lot less development time, but you still have less efficiency & higher CPU usage.

the CPU usage is not really the issue here if you need to send tables so often tho

again: the main goal is to avoid sending tables, i just gave one example how you could do it if you still need to

[NoSharp]

Net.WriteTable isn't inherently bad. It's bad if you don't validate it. In some instances, you need to use it and honestly net.WriteData is often used as a short cut to proper networking, which isn't an improvement.

[patrickratzow]

Needing to use net.WriteTable means your data structure is badly made. WriteTable is okay for small tables, but for anything beyond a dozen entries is just being lazy.