0

I'm trying to determine how long it takes a packet to be sent from client1 -> server -> client2 in order to account for lag compensation. However, it seems as though localtime cannot be relied on. I was doing some testing with a friend and for some reason his machine time in seconds was off by 5 seconds (he was 5 seconds behind). When checking DateTime.UtcNow() everything was the same except for the seconds and I was wondering if there is a more reliable way to approaching this problem?

forgemaster
  • 63
  • 8
  • Thanks I modified my post, and yes I'm sending the timestamp as part of the payload. – forgemaster Oct 11 '20 at 22:44
  • [Additional negotiation in the TCP Timestamp Option field during the TCP handshake](https://www.networkdatapedia.com/post/2018/10/08/how-tcp-works-the-timestamp-option). TCP actually has a Timestamp. The concept is that the sender sends a packet with its own Timestamp value (not necessarily a value representing a date/time), the receiver echoes it back and adds its own. It's the round-trip value that is calculated, though: the sender evaluates its own, so does the receiver. So you don't need to sync the clocks... You can see that with Wireshark (or similar tools). – Jimi Oct 11 '20 at 22:47
  • _[How do I obtain the latency between server and client in C#?](https://stackoverflow.com/a/788619/585968)_ –  Oct 11 '20 at 23:11

1 Answers1

1

I think I understand what you are trying to do, if you want to measure the flight time of packets you need to setup a controlled environment.

Method 1

Set up a ping/pong to the server, put a time stamp on the packet and have the server echo it back to you. Use Ticks as timestamp and you will get a very high level of accuracy

Client 1 -> Server -> Client 1

Method 2

Time synchronisation, if you are both running windows servers, the simplest way is to right click on the time in the task bar, select "Adjust Date/Time" then click on the "Sync Now" button. If you want to script it the you can use powershell to run

Start-Process cmd -ArgumentList '/s,/c,C:\Windows\System32\net.exe start w32time & w32tm /resync' -Verb runAs

This will force each server to sync with a time server, won't be perfect, but you will get a general idea of the time. Put a Ticks value on the packet and have client 2 compare it to their ticks.

Alternative

I think a better alternative would be for each client to measure its latency to the server, i.e.

Client 1 -> Server -> Client 1 => Measure round trip time

Client 2 -> Server -> Client 2 => Measure round trip time

Client 1 -> Server -> Client 2 => Client 1 tells client 2 its server latency

Client 2 -> Server -> Client 1 => Client 2 tells client 1 its server latency

At this point client 1 and 2 should be about to guess how long a packet is going to take. You will need to perform this test fairly regularly as the internet is a constantly changing beast.

Xavier
  • 1,383
  • 7
  • 6