C# Socket, time elapsed during sending

I'd like to know if there was a way to know the time elapsed during the travel of a data on the network.

For example,开发者_如何转开发 I send a packet from computer A to computer B and C (so elapsed time might be different for each depending on the distance, etc), and I want to know the time between sending and receiving for each client (to synchronize exactly precize data).

Moreover, it is important to know that my client MUST work in asynchronous mode (that's not a problem).

Somebody knows how to do it?

KiTe.

Corvil is a well-known software specifically aiming at latency analysis.
For your analysis there are several different layers software and hardware-wise involved and thus it is very complex to implement.
When it comes to synchronizing, it is more important to have a trustworthy key like a sequence number - as you use TCP you have a large problem when there is a problem with losing a package as this triggers a requeue of several packags.

Unless all your nodes have synchronized clocks this would be near impossible to do. If you do have an accurate sync mechanism in place and can trust that the clocks are the same then you could just insert a timestamp into the packet when you send it from A and then in C you compare that to the current time.

But again, you need high res time sync for this approach to work.

What you could do if you just want to benchmark and get an idea of an average time is to make the packet bounce back. Basically, tell C to send the same packet back to B and then to A and in A you compare the original timestamp with the current time (which will be using the same clock). This will give you a round trip latency which you can divide by two to get one-way latency time.

If you are worried about the overhead added by sending messages back then you could do one (or both of) the following

1. Send a much smaller packet back. Basically an integer corresponding to the sequence number of the received message
2. Only send an ACK every Nth message. Should provide enough data to know "typical" latency time