[ntp:questions] NTP client basic

Richard B. gilbert rgilbert88 at comcast.net
Mon Mar 5 00:49:48 UTC 2007

Peter Martinez wrote:
>>From Peter Martinez:
> Per:  Thanks for your remarks. I see that I should have written "SNTP" 
> instead of "NTP" wherever this appears in my original posting. When I 
> encountered this problem initially, the third-party SNTP client package I 
> had used did indeed have the socket open continuously but only read it after 
> sending a request, so if there had been a spurious reply earlier, it would 
> thereafter read the reply to it's previous request!  On seeing that it did 
> this, I realised it was badly written, ditched it, and wrote my own, half 
> hoping that this would also stop the repeats themselves (which in any case 
> only show up in Belgium!)
> 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.
> 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.

My, limited, understanding of UDP is that there is NO guarantee of 
delivery; a packet is sent and it either gets to its destination or not. 
  The protocol does not know or care if the packet reached its 
destination.  You certainly should NOT retransmit if you don't get a 
reply.  The packet is stale and almost completely useless by the time 
you can be sure you will not get a reply.  Send a FRESH packet with a 
new originate time stamp.  UDP doesn't do error checking or retransmits 

Don't keep hammering away at a server that does not reply!  It won't 
help and it just clutters up the network.  See, for example:
for an extreme case!  It will be many years before the NTP world forgets 
this one.  You DON'T want to become famous this way! ;-)

The right ways to handle a non responsive server are to either give up 
or to double your poll interval after each N consecutive failures.  You 
can stop doubling when you hit MAXPOLL; a poll every 1024 seconds (about 
17 minutes) is not going to break anybody's network.

If you are receiving consecutive packets with identical time stamps from 
a server, consider it broken!

More information about the questions mailing list