Any samples for NTP/SNTP client code? - NTP

This is a discussion on Any samples for NTP/SNTP client code? - NTP ; guuwwe@hotmail.com wrote: > 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. I believe ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: Any samples for NTP/SNTP client code?

  1. Re: Any samples for NTP/SNTP client code?

    guuwwe@hotmail.com wrote:
    > 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.


    I believe that the principal reason for having the same format for the
    received and the transmitted packet is so that the server can reply
    simply by modifying the received packet and transmitting the result.

    This means that there is no need to allocate memory for constructing the
    reply packet, no need to copy data from received to transmitted packet, etc.

    This could conceivably be done very close to (or indeed in) the
    hardware, but even if it is done in user space (as is the case in ntpd)
    this saves precious time, which is important in a timing application.

    Optimising the packet format for conveying just enough information (i.e.
    optimising for bandwidth) is of secondary importance (particularly given
    the overhead that IP already represents), and is in fact
    counterproductive in the light of the above argument.

    Hope this helps.

    Cheers, Jan

  2. Re: Any samples for NTP/SNTP client code?

    On Dec 3, 2:18 pm, Jan Ceuleers wrote:
    > guu...@hotmail.com wrote:
    > > 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.

    >
    > I believe that the principal reason for having the same format for the
    > received and the transmitted packet is so that the server can reply
    > simply by modifying the received packet and transmitting the result.
    >


    There is no need to ****reuse**** storage from a received request to
    create
    a response. Even during early 80's when NTP protocol was conceived
    this
    kind of explanation would not fly. Even if you really wanted to reuse
    you
    would simply define all the request-specifc fields at the beginning of
    the
    packet and the server would overlay the received request at the
    beginnging
    of the response, and all the rest would be the same. A client would
    send
    only request-specific fields and the server would send them all the
    fields.

    > This means that there is no need to allocate memory for constructing the
    > reply packet, no need to copy data from received to transmitted packet, etc.
    >


    As explained above, the same could be acomplished with a simple
    overlay.
    Besides, it is funny to talk about allocating memory of 48 bytes by a
    server
    designed around a single task of sending 48 bytes. It is like talking
    about
    UPS service renting a truck every time when it has to ship a single
    package.
    Even it does not make sense for a client. Definitely, you do not
    allocate
    ***dynamically*** memory that is used all the time.

    > This could conceivably be done very close to (or indeed in) the
    > hardware, but even if it is done in user space (as is the case in ntpd)
    > this saves precious time, which is important in a timing application.
    >


    I guarantee you that all the software servers incl. ntpd have so much
    cpu
    and memory waste in them that talking about optimizing/copying
    48 bytes is like cleaning up the streets of a major city with a
    single
    toothbrush, even during the 80s.

    > Optimising the packet format for conveying just enough information (i.e.
    > optimising for bandwidth) is of secondary importance (particularly given
    > the overhead that IP already represents), and is in fact
    > counterproductive in the light of the above argument.
    >


    Sending an empty response packet inside a request is like ordering a
    product
    by sending an empty box first. Such a bandwidth waste would not be
    tolerated
    during the 80s. Apparently, this went unnoticed during the 80s
    because the
    IP traffic was relatively small, and the IP traffic with time
    requests (NTP or otherwise)
    was even smaller. So nobody cared.



  3. Re: Any samples for NTP/SNTP client code?

    Martin Burnicki wrote:
    >
    > AFAIK the code in the SNTP subdirectory has not yet been ported to
    > Windows ...
    >
    > Martin


    We probably wron't try since that code is supposed to be rewritten. The
    effort doesn't justify the cost.

    Danny

  4. Re: Any samples for NTP/SNTP client code?

    (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

    ..guuwwe@hotmail.com wrote:

    > On Dec 1, 3:07 pm, Joseph Gwinn wrote:
    >
    >>In article
    >><90967f07-83ca-4d79-8acb-1c3056ce3...@l1g2000hsa.googlegroups.com>,
    >>
    >> guu...@hotmail.com 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.
    >
    >


  5. Re: Any samples for NTP/SNTP client code?

    guuwwe@hotmail.com wrote:
    > On Dec 3, 3:34 am, da...@ex.djwhome.demon.co.uk.invalid (David
    > Woolley) wrote:
    >> In article <17a3f3c2-3946-4fec-aaa0-6e18ee4e4...@n20g2000hsh.googlegroups.com>,
    >>
    >> guu...@hotmail.com wrote:
    >>> QueryPerformanceCounter() directly off the hardware. Windows
    >>> scheduling has no impact here, the drawbacks of tick counts do not

    >> Windows scheduling will cause uncertainty in the time you get from
    >> your SNTP requests which you use to calibrate the performance counters.
    >> (It will also cause uncertainties in the time of whatever real world
    >> event is associated with the times being recorded by your software.)
    >>

    >
    > Windows scheduling will NOT cause any bigger uncertainty than many
    > other factors including network delays or scheduling on my Linksys
    > router
    > (probably Unix-like OS) that relays all my incoming/outgoing IP
    > traffic.
    >


    Then you have no idea. There is plenty of evidence to disprove this. I
    have plenty of suspicious pieces that may be the cause of the issues
    including interrupts and message pumping.

    > The most important thing is that my code will be able to measure
    > fairly
    > consistently the time between sending a request and receiving a
    > reply
    > for ***all*** servers in microseconds. I will use at least five
    > servers.
    > It would not be possible with TICKS but it is possible with high
    > frequency
    > counters because they operate on different principle as stated. This
    > is the
    > key difference!!! Consequently, it will be possible to estimate the
    > drift of the
    > PC counter and come up with servers' polling frequencies that
    > satisfy my
    > reqs for accuracy.
    >
    > So do not make it more complicated than it is. The rest belongs to
    > the
    > algorithims I will use and you do not know them, and I am not ready
    > to
    > discusss them.
    >


    That's okay, we don't need to know. If you can prove you get better
    results then I'm sure you will let us know. We would welcome something
    better but you need to show it really is better for most (if not all)
    cases that ntp deals with.

    Danny

  6. Re: Any samples for NTP/SNTP client code?

    guuwwe@hotmail.com wrote:
    > On Dec 2, 9:34 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
    >> guu...@hotmail.com wrote:
    >>> On Dec 1, 3:07 pm, Joseph Gwinn wrote:
    >>>> In article
    >>>> <90967f07-83ca-4d79-8acb-1c3056ce3...@l1g2000hsa.googlegroups.com>,
    >>>> guu...@hotmail.com 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.
    >


    Correct. My error.

    > 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.
    >


    Read the NTPv4 draft:
    http://www.ietf.org/internet-drafts/...4-proto-08.txt

    which will tell you. If something is unclear or missing, send a message
    to the ntp working group.

    Danny

  7. Re: Any samples for NTP/SNTP client code?

    Jan Ceuleers wrote:
    > guuwwe@hotmail.com wrote:
    >> 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.

    >
    > I believe that the principal reason for having the same format for the
    > received and the transmitted packet is so that the server can reply
    > simply by modifying the received packet and transmitting the result.
    >
    > This means that there is no need to allocate memory for constructing the
    > reply packet, no need to copy data from received to transmitted packet, etc.


    This is also false. That's not what the code does. The recvbuf structure
    is not even the same size as the transmitbuf structure.

    Danny

  8. Re: Any samples for NTP/SNTP client code?

    Danny Mayer wrote:
    > Jan Ceuleers wrote:
    >> This means that there is no need to allocate memory for constructing the
    >> reply packet, no need to copy data from received to transmitted packet, etc.

    >
    > This is also false. That's not what the code does. The recvbuf structure
    > is not even the same size as the transmitbuf structure.


    I wasn't talking about the recvbuf and transmitbuf structures, but the
    socket receive and transmit buffers.

    Besides, transmitbuf appears to only exist in the Windows port.

    Jan


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2