[ntp:questions] NTP client basic

Per Hedeland per at hedeland.org
Sun Mar 4 23:34:07 UTC 2007


In article <014301c75d93$aa58a3e0$0300a8c0 at LAPTOP>
peter.martinez at btinternet.com (Peter Martinez) writes:
>
>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.

UDP the protocol will *never* retransmit - since there are no acks in
the protocol, there's simply no basis for deciding to retransmit
anything. And since duplicates just "shouldn't happen", it wouldn't
really make sense for the (S)NTP spec to say specifically that they must
be ignored - should they occur after all, discarding them falls under
general "sanity check" procedure.

As I wrote, if you are actually seeing duplicates (and as others have
pointed out, there could be other explanations), it's most likely due to
faulty/misconfigured network equipment, or it could be someone actively
sending them in an (apparently successful) attempt to disrupt your
timekeeping. Whatever it is that is causing them, it isn't UDP.

>That's the only reason for raising the topic. I don't need any more help to 
>achieve my own objective. I am just puzzled by what I see might be a flaw.

Well, my elaboration was only in part meant to suggest how you could
avoid the problem - it was just as much an attempt to explain why
duplicates aren't an issue in the unlikely event that they actually do
occur.

--Per Hedeland
per at hedeland.org




More information about the questions mailing list