Hal, In the far distant past, the most likely source of retransmissions was link-level retransmissions. In any case, the NTP on-wire protocol discards duplicates and bogus packets anyway. It does no good whatsoever to retransmit unanswered packets. If necessary, transmit a new packet with current timestamps.
Dave Hal Murray wrote: >>When the repeats still appeared in my own SNTP client implementation (now >>trapped, but logged), it seemed to me that I might have stumbled on a >>possible source of trouble. RFC2030 didn't seem to say that you MUST take >>steps to discard repeats which COULD arise in the underlying UDP protocol, >>it seemed to be saying that you could keep an eye on the xmit timestamp in >>the request - but it's not essential. RFC768 (which describes UDP) doesn't >>shed any light on whether a corrupted UDP packet could be repeated. > > > It's possible but very very unlikely for the network to duplicate > a packet. > > Is your code retransmitting if you don't get an answer? If so, a > likely explanation is that you aren't waiting long enough. In > any case, your code should filter out duplicates and/or process > them correctly. > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
