UDP delay potential

Question

I have an application consisting of numerous systems using UDP clients in remote locations. All clients send UDP packets to a central location for processing. In my application, it is imperative that the central location knows at what time the packet was sent by the remote location.

From a design point of view, would it be “safe” to assume that a central location can mark packets as they arrive and use this as “sent time”? Since the application uses UDP, should packets either arrive immediately or not at all? Another option is to set up time synchronization at each remote location. The disadvantage of this is that then I will need to constantly make sure that time synchronization works on each of the potentially hundreds of remote locations.

My question is whether the timestamp of UDP packets in a central location to determine the "sent time" is a potential flaw. Is UDP delay possible?

Answer 1

To resolve seconds, you can use time stamping when you receive a packet, but you still need to use a sequence number to block reordered or duplicated packets.

This can make your remote stations less complicated because they won’t need a clock with battery synchronization or synchronization.

For millisecond resolution, you want to calculate the round trip time (RTT) and use this offset for the clock on the receiver.

Unless you use Precision Time Protocol (PTP) in a controlled environment, you can never trust the clock of remote hosts.

Answer 2

There is always a delay in transmission, and UDP packets do not have guaranteed delivery, and they are not guaranteed to arrive in sequence.

, .

Answer 3

- , . UDP , , "" ( - - ).

acking, , () , .

acking, , , - .