Muduo network programming example 5: measure the network latency of two machines

The method for measuring RTT is simple:
Host A sends A message to host B, which includes the local time when host A sends the message.
Host B immediately returns the message to host
After receiving the message, host A obtains the RTT by subtracting the current time from the time in the message.
The NTP protocol works similarly. However, apart from measuring the RTT, NTP also needs to know the time difference (clock offset) between the two machines to calibrate the time.

The above is the NTP protocol, RTT = (T4-T1)-(T3-T2), Time Difference = (T4 + T1)-(T2 + T3)/2. NTP requires that the one-way latency on the round-trip path should be equal as much as possible to reduce system errors. The accidental error is determined by the uncertainty of one-way delay.
In the roundtrip sample program I designed, the Protocol is simplified:

The simplified protocol takes less time because the server sends the message back to the client immediately after receiving the message, which takes less time (several microseconds) and basically does not affect the final result.
The message format I designed is a 16-byte fixed-length message:

Both T1 and T2 are muduo: Timestamp, an int64_t, indicating the number of microseconds from Epoch to the present.
To make the one-way round-trip time of a message close, the messages sent by the server and client are both 16 bytes, Which is symmetric.
Because it is a fixed-length message, codec can be used directly in message callback without having to use it.
While (buffer-> readableBytes ()> = frameLen) {...} can decode.
Ask the reader to think about the consequences of changing while to if?
The client sends messages at an interval of 200 ms and prints RTT and clock offset after receiving the messages. An example of one operation is as follows:

In this example, the clock between the client and the server is not fully aligned. The server's time is faster than 850 us, and the time difference can be measured using the roundtrip program. With this time difference, the message delay measured in the distributed system can be corrected.
For example, if the server sends a message at the time of 1.235000, the client receives the message at the time of 1.234300. if the message is calculated directly, the latency is-700us. This result must be wrong, because the server and client are not in a clock domain (this is a concept in a digital circuit), and their time is directly reduced without significance. If we have measured that the server is 700 us faster than the client, we can use this data for one correction:-850 + = 150us. This result is more realistic. Of course, in practice, clock offset must pass through a low-pass filter before it can be used, otherwise it may be too large.
Please think, why can't we use RTT/2 as one-way delay for sending and receiving messages between machines in two days?
There is no problem in using this program in the LAN. If it is used on the wide area network and the RTT is greater than 200 ms, the measurement result is incorrect due to the influence of the Nagle algorithm (the specific analysis is left for exercise, in this case, we need to set the TCP_NODELAY parameter so that the program can work normally on the wide area network.