(sender?), As for symmetry in request/response being uncommon, you may consder ICMP Echo/Echo Reply and even TCP as uncommon, and that is curious.
The RFC describes formulas for computing the offset and delay. You consider this "***alone*** is the slowest way". You imply there are other ways to compute these values and all of them are faster. Please reveal some examples. You also hint that you want to collect samples as fast as possible. If you confine this to your own servers, be happy. If you do that with public servers, you may get a very rude Kiss-o'-Death packet and a complaint to the Internet Police. In addition, at least with my servers, you will be permanantly blacklisted. Dave [EMAIL PROTECTED] wrote: > On Dec 1, 3:07 pm, Joseph Gwinn <[EMAIL PROTECTED]> wrote: > >>In article >><[EMAIL PROTECTED]>, >> >> [EMAIL PROTECTED] wrote: >> >>>Does anybody know of any *practical* samples on how to >>>implement NTP/SNTP client?. The goal is to provide accurate >>>time for a program/client running on Windows Vista. >> >>>Specifically, what values to include in the the request message, >>>how to process the reply message, etc. >> >>>I am NOT asking how to send/receive UDP datagrams, or where >>>to find comprehensive descriptions like RFC documents, or how >>>to build or design user interfaces. >> >>>Only a narrow description focused on NTP/SNTP request/reply >>>datagrams for a simple PC client, preferably in C/C++ source >>>code. >> >>I've done this in an embedded realtime system. (No, the source code is >>not available.) >> >>In Appendix A of RFC-1305 you will find the format of the NTPv3 >>request/response packet. Send this packet to port 123 of the NTP >>server, and read the reply packet. It's pretty easy. >> > > > I saw this format. From data comm point of view it is very unusual > to have the same format for request and reply. > > Sending/receiving the packet to port 123 is the first thing I tried. > This is not an issue. The issue is to use all the values in > request and reply correctly and reliably. And the quickest > way is to get as many ***samples*** as possible, the > RFC doc ***alone*** is the slowest way. > > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
