Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
I am sending quite a bit of data to and from a server, for a game I'm making.
I currently send location data like this:
sendToClient((("UID:" + cl.uid +";x:" + cl.x)));
sendToClient((("UID:" + cl.uid +";y:" + cl.y)));
sendToClient((("UID:" + cl.uid +";z:" + cl.z)));
Obviously it is sending the respective X, Y, and Z values.
Would it be more efficient to send data like this?
sendToClient((("UID:" + cl.uid +"|" + cl.x + "|" + cl.y + "|" + cl.z)));
A TCP segment has quite a lot of overhead. When you send a 10 byte message with one TCP packet you actually send:
resulting in 42 bytes of traffic for transporting 10 byte of data. So you only make use of less than 25% of your available bandwidth. And that does not yet account for the overhead which the lower-level protocols like Ethernet or PPPoE consume (but these are hard to estimate because there are so many alternatives).
Also, many small packets put more strain on routers, firewalls, switches and other network infrastructure equipment, so when you, your service provider and your users don't invest in high-quality hardware, this might turn into another bottleneck.
For that reason you should try to send all data you have available at once in one TCP segment.
Regarding handling packet loss: When you use TCP you don't need to worry about that. The protocol itself ensures that any lost packets are resent and packets are processed in order, so you can assume that all packets you send will arrive at the other side, and they will arrive in the order you send them. The price for this is that when there is packet loss, your player will experience considerable lag, because one dropped packet will halt the whole data-stream until it was re-requested and received.
When this is a problem, you can always use UDP. But then you need to find your own solution for lost and out-of-order messages (it at least guarantees that the messages which do arrive, arrive complete and undamaged).
One large one (within reason) is better.
As you said, packet loss is the main reason. Packets are generally sent in frames of a fixed size, so it is better to take up one frame with a big message than 10 frames with 10 small ones.
However with standard TCP, this isn't really an issue, unless you disable it. (It is called Nagle's algorithm, and for games you should disable it.) TCP will wait for a fixed timeout or until the package is "full". Where "full" is would be some slightly magic number, determined in part by the frame size.
recv() call for each send() call, which is what most people are looking for. Using a protocol that guarantees this, like UDP does though. "When all you have is TCP, everything looks like a stream"
\$\endgroup\$
Mar 20, 2015 at 2:15
All the previous answers are incorrect. In practice, it doesn't matter whether you issue one long send() call or several small send() calls.
As Phillip states, a TCP segment has some overhead, but as an application programmer, you have no control over how segments are generated. In simple terms:
One
send()call does not necessarily translate to one TCP segment.
The OS is completely free to buffer all of your data and send it in one segment, or take the long one and break it into several small segments.
This has several implications, but the most important one is that:
One
send()call, or one TCP segment does not necessarily translate to one successfulrecv()call on the other end
The reasoning behind this is that TCP is a stream protocol. TCP treats your data as a long stream of bytes, and has absolutely no concept of "packets". With send() you add bytes to that stream, and with recv() you get bytes off the other side. TCP will aggressively buffer and split your data wherever it sees fit to make sure your data gets to the other side as fast as possible.
If you want to send and receive "packets" with TCP, you have to implement packet start markers, length markers and so on. How about using a message oriented protocol like UDP instead? UDP guarantees one send() call translates to one sent datagram and to one recv() call!
When all you have is TCP, everything looks like a stream
recv(), you need to make your own buffering to compensate for that. I would rank it in the same difficulty as implementing reliability over UDP.
\$\endgroup\$
Mar 20, 2015 at 10:11
while(1) { uint16_t size; read(sock, &size, sizeof(size)); size = ntoh(size); char message[size]; read(sock, buffer, size); handleMessage(message); } (omitting error handling and partial reads for brevity but it does not change much). Doing this is a select does not add much more complexity and if you are using TCP you probably need to buffer the partial messages anyway. Implementing robust reliability over UDP is much more complicated than that.
\$\endgroup\$
Many small packages is fine. In fact, if you are worried about TCP overhead, just insert a bufferstream that collect up to 1500 chars (or whatever your TCP MTUs is, best to request it dynamically), and deal with the problem in one place. Doing so spares you the overhead of ~40 bytes for every extra package you would otherwise have created.
That said, it's still better to send less data, and building larger objects help there. Ofcourse it's smaller to send "UID:10|1|2|3 than to send UID:10;x:1UID:10;y:2UID:10;z:3. In fact, also at this point you should not be reinventing the wheel, use a library like protobuf that can decrease data like that to a 10 byte string or less.
Only thing you should not forget is to insert a Flush commands on your stream at relevant locations, because as soon as you stop adding data to your stream, it might wait infinite before it send anything. Really problematic when your client is waiting for that data, and your sever wont send anything new until the client send the next command.
Package loss is something you can affect here, marginally. Every byte you send can potentially be corrupted, and TCP will automatically request a retransmission. Smaller packages means a lower chance for every single package to be corrupted, but because they add up on the overhead, you send even more bytes, increasing the odds of a lost package even more. When a package is lost, TCP will buffer all succeeding data until the missing package is resend and received. This result in a large delay (ping). While the total loss in bandwidth because of package loss might be negligible, the higher ping would be undesirable for games.
Bottom line: Send as little data as possible, send large packages, and do not write your own low level methods to do so, but rely on well known libraries and methods like bufferstream and protobuf to handle the heavy lifting.
bufferstream is trivial, that's why I called it a method. You still want to handle it in one place, and not integrate your buffer logic with your message code. As for Object Serialization, I highly doubt you get something better than the thousands of man-hours others put in there, even if you DO try, I strongly suggest you benchmark your solution against known implementations.
\$\endgroup\$
Although being a neophyte to network programming myself, I would like to share my limited experience by adding a few points:
Concerning measurements, the metrics that should be considered are:
As mentioned, if you find out that you're not limited in a sense and could use UDP, go for that. There are some UDP-based implementations out there, so you don't have to reinvent the wheel or work against years of experience and proven experience. Such implementations worth mentioning are:
Conclusion: since a UDP implementation could outperform (by a factor of 3x) a TCP one, it makes sense to consider it, once you've identified your scenario to be UDP friendly. Be warned! Implementing the full TCP stack on top of UDP is always a bad idea.
