On Dec 2, 9:34 pm, [EMAIL PROTECTED] (Danny Mayer) wrote: > [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. > > Why does that matter? The contents of the sending packet is slightly > different from the reply. The client sends a mode 4 packet and receives > back a mode 3 packet. The layout of the two packets are the same, the > contents are appropriate for the mode. >
Actually, the client sends mode 3 and server responds with mode 4. In my original post I made an issue of the same ***format*** of NTP/ SNTP request and reply. This is very unusual in data comm. Obviously, the requests and replies have to have different ***contents*** otherwise there would be no exchange of information. Just look at the NTP/SNTP request format and for ***every*** field explain why would a client send it to a server. Do not pick just one field like MODE, explain for ***all*** fields. > > 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.. > > Samples probably won't help that much. The draft NTPv4 spec should. You > can also look at ntpdate which also runs on Vista. Collecting sample > source code is one way to do it, why reinvent the wheel? > > Can you say why you want to write your own version of an SNTP client? We > are actually looking for someone to rewrite the one in the NTP > distribution. It has to run on all supported O/S's but it you want to > create one and donate it to us we'd be delighted. > I am already busy with my projects. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions