7
\$\begingroup\$

I'm working with a socket server and I'm trying to decide how to update all of the clients.

I'm currently sending few packets with entire objects serialized in JSON. In most cases this adds a lot of overheard in the form of unneeded data. This to me is a no brainer, get rid of the serialization and send only what is needed.

Lets say I have four server-side AIs. Should I send all four of the AIs in one giant update, therefore serializing only the needed data or should I send each one in a separate update?

\$\endgroup\$
2
  • 5
    \$\begingroup\$ Which would make you happier? \$\endgroup\$
    – Trevor Powell
    Commented Mar 12, 2013 at 2:25
  • \$\begingroup\$ I don't really like the idea of serialized anything going across the network, seems easily readable. With that said, in the case of updating X number of AI it may make sense since those updates will likely happen at the same time. So to answer your question, the most efficient way would make me happier which I believe would be to serialize them. \$\endgroup\$
    – seethru
    Commented Mar 12, 2013 at 2:37

2 Answers 2

Reset to default
12
\$\begingroup\$

When you send small messages, you have to be aware of the protocol overhead:

enter image description here

Imagine you are sending a 10 byte message.

A TCP header is 24 bytes, an UDP header is 8 bytes. Assuming you use UDP, you have 18 bytes in total.

But you also have the IP header, which is at least an additional 20 bytes in IPv4 or 40 bytes in IPv6. That's 38 bytes in total when you use IPv4.

And then you also have the ethernet frame around all that, which is (usually) another 42 bytes. So you are at 80 bytes. That's 7 times as much protocol overhead as the data you were sending.

As you see, sending small data messages is not very bandwidth-efficient because there is a fix-cost of 70 bytes of protocol overhead for each message.

to visualize this better, seventy bytes is as much data as this string

But delaying small messages just so you can send more at the same time is often not a good idea either, because this will make the game feel more laggy.

There is no golden hammer solution to finding the ideal compromise for this. But all data which is available at the same time should be sent in one message instead of separating it into multiple. There is nothing to gain and a lot to lose by adding unnecessary fragmentation on the application level.

(Image source: http://en.wikipedia.org/wiki/File:UDP_encapsulation.svg)

\$\endgroup\$
2
  • \$\begingroup\$ Thats exactly what I was looking for with my last comment. Thanks for the excellent info... I remember learning all this at one point many years ago but it apparently didnt stick. \$\endgroup\$
    – RobCurr
    Commented Mar 12, 2013 at 15:01
  • \$\begingroup\$ Can you provide any further context about the issues with fragmenting at the application level? \$\endgroup\$
    – Josh Bothun
    Commented Nov 30, 2013 at 10:39
0
\$\begingroup\$

Generally speaking, if the game is fairly large or sends a lot of updates you should pack your packets small. However, if your game is only small and just something to play around with and scalability isn't a huge concern - just do what works.

\$\endgroup\$
2
  • \$\begingroup\$ Is there any way to tell what is the optimum size of a packet assuming he is to go with the small packet idea. For instance is there a minimum size for a packet where he should try and use as much of it as possible? \$\endgroup\$
    – RobCurr
    Commented Mar 12, 2013 at 7:11
  • \$\begingroup\$ @RobCurr There are things like MaxMTU you can optimize for (maximum size of ethernet frames), but this can be affected by the configuration of every single router between server and client. You shouldn't really bother, because it's just too unpredictable and the effect is usually too small to notice. \$\endgroup\$
    – Philipp
    Commented Mar 12, 2013 at 13:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .