In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Per Hedeland) writes: >In article <[EMAIL PROTECTED]> >[EMAIL PROTECTED] (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 [EMAIL PROTECTED] _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
