在网络游戏中使用哪种方法正确发送/接收数据（UDP，但为什么不使用TCP）

Question

I have a C++ application with GUI that runs (on PC 1) just like a network game, and receives data packets from another computer (2) via WiFi (ad-hoc, so it's quite reliable) at fairly regular intervals (like 40ms), once per loop on program (2). I use send/read.

Here is the problem:
- Packets are not always fully sent (but apparently you can simply keep send() ing the remaining data until all is sent, and thats works well)
- More importantly , packets are stacked in the socket during (1)'s loop until the read() occurs, and then there is no way to distinguish packets in the big stream of data, or know if you were already in the middle of a packet.

I tried to fix this with ID headers (you find an ID as first bytes and you know the length of the packet), but I often get lost (unknown ID : we are not at the beginning of the packet) and am forced to ignore all the remaining data.

So my question is:
Why do packets stack? (generally I have 400B of data whereas my packets are <100B long and fps (1) and (2) are not very different)
How can I have a more reliable way to receive actual packets, say, 80% of packets (discarding packet loss, it's not a question of UDP/TCP)?

Would a separate thread for receiving packets work? (on (1), the server)

How do real-time network games to that (including multiple client management)?

Thanks in advance.

(Sorry I do not have the code here, but I tried to be as clear as I could)

Answer 1

Well:

1) UDP transfers MESSAGES, but is unreliable.

2) TCP transfers BYTE STREAMS, and is reliable.

UDP cannot reliably transfer messages. Anything more reliable requires a protocol on top of UDP.

TCP cannot transfer messages unless they are one byte long. Anything more complex requires a protocol on top of TCP.

Answer 2

• Why do packets stack? (generally I have 400B of data whereas my packets are <100B long and fps (1) and (2) are not very different)

Because the time to send packets across the net varies, it typically does not make sense to send packets at a high rate, so most networking libraries (eg RakNet) will queue up packets and do a send every 10 ms.

In the case of TCP, there is Nagle's algorithm which is a more principled way of doing the same thing. You can turn Nagle's off by setting the NO_DELAY TCP flag.

• How can I have a more reliable way to receive actual packets, say, 80% of packets (discarding packet loss, it's not a question of UDP/TCP)?

If you use TCP, you will receive all of the packets and in the right order. The penalty for using TCP is if a packet is dropped, the packets after it wait until that packet can be resent before they are processed. This results in a noticeable delay, so any games that use TCP have sophisticated prediction techniques to hide this delay and other techniques to smoothly "catch up" once the missing packet arrives.

If you use UDP, you can implement a layer on top that gives you reliability but without the ordering if the order of the packets doesn't matter by sending a counter with each packet and having the receiver repeatedly notify the sender of gaps in the counts. You can also implement ordering by doing something similar. Of course, if you enforce both, then you are creating your own TCP layer. See http://www.jenkinssoftware.com/raknet/manual/reliabilitytypes.html for more details.

Answer 3

What you describe is what would happen if you are using TCP without a protocol on top of it to structure your transmitted data. Your idea of using an ID header and packet length is one such protocol. If you send a 4-byte ID followed by a 4-byte length followed by X number of bytes, then the receiver knows that it has to read 4 bytes followed by 4 bytes followed by X bytes to receive a complete packet. It doesn't get much simplier than that. The fact that you are still having problems reading packets with such a simple protocol suggests that your underlying socket reading code is flawed to begin with. Without seeing your actual code, it is difficult to tell you what you are doing wrong.