Packet Performance Questions - Multiple Single Packets to one batch

[DevOverflow 1]

Dear Community,

I'm currently working on a small personal project and i am stuck.
Right now, I’m sending small packets of information from the client to the game, and while the data transfer works fine, I’d like to improve performance.
At the moment, I'm sending multiple small packets one by one specifically, for example, I send inventory item information using a loop that sends 10 separate packets, one for each inventory cell.
What I’d like to do instead is send one larger packet that contains all 10 inventory cells at once. I’ve tried a few different approaches, but I’m not quite sure how to structure and process the combined data correctly on the receiving end.
If anyone has experience with this kind of optimization or advice on how to properly serialize and handle a batch of data in one packet, I’d really appreciate your input!
Thanks in advance!

Best Regards,
DevOverflow

[Metin2 Dev 12287]

 You not mentioned if  your actual batch of packest are static or dynamic ? Try compress packets using lz4 and a use dynamic packet.

Edited April 12, 2025 by Metin2 Dev

[Gurgarath 3706]

6 hours ago, Punszz said:

 You not mentioned if  your actual batch of packest are static or dynamic ? Try compress packets using lz4 and a use dynamic packet.

If he sends a batch it is more likely dynamic. Unless he likes, defer sending and spams static packets all at once which could be considered bad practice. Compressing LZ4 packets is more often than not not useful, as the compression / decompression overhead on a 20 bytes packet is way worse than just sending the packet raw. Only packets worth compressing are probably the biggest one and they are often DG packets or custom CG / GC big packets like a ranking or stuff like that.

On the part where I kept the default networking, I usually prefer to send dynamic packets of large data (using a "vector", that we can send if we make it an array or data or reconstruct it on the server) where it makes sense, rather than sending multiple small packets, this at least removes stuttering on the client (and risk to get kicked out because you send too many burst packets). But if you really go for a new approach, there are thousands of better options than what we have now, like msquic, a modern TCP implementation, packet serialization and so on. But it requires extensive work and sometimes multi-threading if you want to do it right, which is something that will lead you to hours of TSAN.

Edited April 13, 2025 by Gurgarath

[Endymion 399]

Based on what you’ve written, it’s unlikely to make much of a difference. The ::Send(...) function simply writes data into a buffer to be sent on the next tick, so from the server’s perspective, it doesn’t change much. It really depends on what you're trying to achieve. For example, take a look at how opening a shop via a bundle works. In that case, the server needs complete information about all items, so sending each item in a separate packet wouldn’t make much sense.

Edited April 13, 2025 by Endymion

[DevOverflow 1]

9 hours ago, Gurgarath said:

If he sends a batch it is more likely dynamic. Unless he likes, defer sending and spams static packets all at once which could be considered bad practice. Compressing LZ4 packets is more often than not not useful, as the compression / decompression overhead on a 20 bytes packet is way worse than just sending the packet raw. Only packets worth compressing are probably the biggest one and they are often DG packets or custom CG / GC big packets like a ranking or stuff like that.

On the part where I kept the default networking, I usually prefer to send dynamic packets of large data (using a "vector", that we can send if we make it an array or data or reconstruct it on the server) where it makes sense, rather than sending multiple small packets, this at least removes stuttering on the client (and risk to get kicked out because you send too many burst packets). But if you really go for a new approach, there are thousands of better options than what we have now, like msquic, a modern TCP implementation, packet serialization and so on. But it requires extensive work and sometimes multi-threading if you want to do it right, which is something that will lead you to hours of TSAN.

Thank you for your Answer. I will try it out!

[Metin2 Dev 12287]

17 hours ago, Gurgarath said:

If he sends a batch it is more likely dynamic. Unless he likes, defer sending and spams static packets all at once which could be considered bad practice. Compressing LZ4 packets is more often than not not useful, as the compression / decompression overhead on a 20 bytes packet is way worse than just sending the packet raw. Only packets worth compressing are probably the biggest one and they are often DG packets or custom CG / GC big packets like a ranking or stuff like that.

On the part where I kept the default networking, I usually prefer to send dynamic packets of large data (using a "vector", that we can send if we make it an array or data or reconstruct it on the server) where it makes sense, rather than sending multiple small packets, this at least removes stuttering on the client (and risk to get kicked out because you send too many burst packets). But if you really go for a new approach, there are thousands of better options than what we have now, like msquic, a modern TCP implementation, packet serialization and so on. But it requires extensive work and sometimes multi-threading if you want to do it right, which is something that will lead you to hours of TSAN.

Aand what i said? Sending a compressed vector and reconstruct on client.. Compression is really worth..  i

[DevOverflow 1]

On 4/13/2025 at 8:08 AM, Gurgarath said:

If he sends a batch it is more likely dynamic. Unless he likes, defer sending and spams static packets all at once which could be considered bad practice. Compressing LZ4 packets is more often than not not useful, as the compression / decompression overhead on a 20 bytes packet is way worse than just sending the packet raw. Only packets worth compressing are probably the biggest one and they are often DG packets or custom CG / GC big packets like a ranking or stuff like that.

On the part where I kept the default networking, I usually prefer to send dynamic packets of large data (using a "vector", that we can send if we make it an array or data or reconstruct it on the server) where it makes sense, rather than sending multiple small packets, this at least removes stuttering on the client (and risk to get kicked out because you send too many burst packets). But if you really go for a new approach, there are thousands of better options than what we have now, like msquic, a modern TCP implementation, packet serialization and so on. But it requires extensive work and sometimes multi-threading if you want to do it right, which is something that will lead you to hours of TSAN.

Thank you for your answer. Your answer worked perfectly and solved my problem. I really appreciate your help!