[ntp:questions] NTP client basic

Per Hedeland per at hedeland.org
Sat Mar 3 11:46:05 UTC 2007


In article <esbm2f$rs$1 at hedeland.org> per at hedeland.org (Per Hedeland) writes:
>In article <017a01c75c3b$15cb2850$0300a8c0 at LAPTOP>
>peter.martinez at btinternet.com (Peter Martinez) writes:
>>
>>4) What's the usual way of suppressing duplicate replies? Comparing a local 
>>copy of the request's xmit timestamp with the reply's orig. timestamp seems 
>>the obvious.
>
>Yes, this is a good sanity check. I don't know if it's "usual" since I
>haven't studied the implementation of any SNTP clients. For NTP it's a
>non-issue per above, and even some rudimentary filtering in the SNTP
>case would have taken care of your problem - e.g. send (say) three
>packets (adequately spaced) and use the average after tossing any
>replies that are way off.

Addendum: The fact that your program even received the "late duplicate"
packets implies that it holds the UDP socket open continuously (which of
course implies that the program is running continuously). I think it's
pretty much an (unstated) assumption that SNTP clients would operate in
more of a one-shot mode, e.g. some OS service like Unix' 'crontab' fires
up the program at pre-set intervals, where it does its thing and exits.

In this case you're pretty much guaranteed that duplicates will be
dropped by the TCP/IP stack, since there's no program listening for them
when they arrive - or at worst that they will sit unprocessed in the
socket input queue when the program exits, and so get dropped anyway.
If you want your program to run continously, you can of course achieve
the same result by opening a new socket whenever you're about to send
(a) request(s), and close it when you're done receiving the reply/ies.

--Per Hedeland
per at hedeland.org




More information about the questions mailing list