0
\$\begingroup\$

I'm building networked racing game right now. I'm using winsock with TCP/UDP socket and IOCP.

I'm having trouble with latency masking and I don't even know if my implementation is wrong.

So, I'm measuring latency between client and server with tcp packet. Server gives tcp packet with current time to client first and then client send back another tcp packet containing time value that received from server, and server would calculate the latency by (current_time - time_sent) / 2.

But as far as I know, tcp packet transfer time can be different every time based on network traffic and packet lose.

So, I'm wondering if I should use UDP packet for latency measure.

Can anyone give me advice for this one?

\$\endgroup\$
6
  • \$\begingroup\$ You may be interested in clock synchronization, Start timer in two clients [at] the same time, How to start the game at the same time across two phones, How to sync game tick in peer to peer game, Network client-server message exchange and clock synchronization help, and more you can find by typing "RTT" into the search box. \$\endgroup\$ Commented Apr 30, 2022 at 11:38
  • \$\begingroup\$ Glenn Fiedler's articles are usually offered as the recommended reading to get started in this area. In UDP vs. TCP, he makes this a heading: "Never use TCP for time critical data". Reliability and Congestion Avoidance over UDP includes a method for measuring round-trip time. Based on your reading of these articles and the Q&A above, are you able to solve your problem? If not, can you edit your question to clarify what you need beyond this documentation? \$\endgroup\$ Commented Apr 30, 2022 at 11:42
  • \$\begingroup\$ @DMGregory so.. should I use NTP? \$\endgroup\$ Commented Apr 30, 2022 at 12:46
  • \$\begingroup\$ @DMGregory It seems like what I'm doing is similar with NTP.. but my question is that how to know when ack packet comes with TCP? If I implement it with udp, I'm concerned about packet lose. \$\endgroup\$ Commented Apr 30, 2022 at 13:15
  • \$\begingroup\$ I'll repeat the above in bold this time: Never use TCP for time critical data. You do not care about packet loss for measuring RTT, because you can measure it continuously over multiple attempts, even tracking changes in RTT over the duration of your session. Each UDP time check packet can have a unique number in it. You only count those for which you receive a matching number from the server. Any that disappear, oh well, you can just discard them and use the response to the next one that gets through both ways instead. Dealing with dropped packets is discussed in the "Reliability" link. \$\endgroup\$ Commented Apr 30, 2022 at 13:34

2 Answers 2

Reset to default
1
\$\begingroup\$

It's irrelevant. You don't need to know how long "a packet" takes, you need to know how long that packet took. As you mentioned, you can have random latency spikes. Maybe your measurement packet didn't get delayed but then your actual game packet did. You need to be prepared for any packet to arrive late.

If your game has tight timing requirements then switching to UDP could be a better choice. You will still have to deal with latency spikes, because UDP packets are not immune to delay. They are just immune to delay caused by packet loss and retransmission. (The tradeoff is that you have to deal with the packet loss yourself)

If you want the average latency, then you should calculate the average of several measurements.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ That's what's beautiful about using UDP: you need to re-implement TCP features over UDP! \$\endgroup\$ Commented May 4, 2022 at 15:38
0
\$\begingroup\$

You really only want to use TCP if you're making a multiplayer browser game. In this case, you need to figure out the median of the RTT because, as you said, some packets can get stuck in network traffic. The median can help you get rid of the anomalous values of the curve and get a more realistic view of the player's latency.

But if you're using UDP, you can do this easily as DMGregory mentioned.

\$\endgroup\$
2
  • \$\begingroup\$ Answers shouldn't be in the comments because they're transient. You may copy-paste-adapt the content of the comment(s) into your own post. This way, if the user who commented decides to delete their comment(s), your answer is still valid. \$\endgroup\$ Commented May 4, 2022 at 14:50
  • \$\begingroup\$ (So instead of saying "you can do this easily as DMGregory mentioned", insert there what he did say about it.) \$\endgroup\$ Commented May 4, 2022 at 14:55

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.