[ntp:questions] No libntp.so

Martin Burnicki martin.burnicki at meinberg.de
Fri Aug 29 08:58:05 UTC 2008

Hello Kay,

Kay Hayen wrote:
> Hello Martin, 
>>>thanks for the reply, you wrote:
>>>>As mentioned in another reply it depends on what ntpq has to do during
>>>>those 25 milliseconds. Please be aware that this may include DNS lookups
>>>>which might fail, so the the call would be take until the DNS lookup
>>>>times out.
>>>We are using "ntpq -n" which makes a huge difference for the peers
>>>command and make all DNS lookups obsolete. We are also not using DNS on
>>>these machines, but only a hosts file, so normally this couldn't play a
>>OK. However, if 25 milliseconds is still too long for other task you are
>>running you should do this asynchronously anyway.
> Yes, I agree, and I would say it's best to break up doquery() as I saw it into 
> a part that sends and a part that processes the reply later. That form of 
> async will match our other control flows nicely and avoid the response delays 
> to punch through.

Why splitting up doquery?

If you would ever have to send several queries in parallel and then
receive several replies you'd have to check which reply is associated to
which query.

If your programming environment supports threads then I'd suggest to
start one thread for each server to be queried.

In each thread you can send a request and then wait for a reply, and
after a reply has been received or a timeout has occurred you can either
exit that thread or just let it sleep for some minutes or whatever and
then loop back to send the next query.

The advantage of this is that you send the query from some free port and
you receive the reply on the same port, so the reply is automatically
associated to the correct request.

>>>I have not come to fully understand where the code is that is executed
>>>when I enter "peers", but it seemed that the encoding and decoding of
>>>packets could be found there at least.
>>Search the code for dopeers(), dogetpeers(), doprintpeers(). The packets
>>returned from ntpd already contain some ASCII text with the desired data.
> Thanks for the pointers, that's great. I looked through it down to doquery and 
> well, dunno how to say that correctly, I think it's good quality code to work 
> with.
> It appeared to be quiet achievable to have a "libntpq.[a|so]" made. Note that 
> I realized, that I actually want that instead.
> One probably should have to handle error printing somewhat differently, and 
> change a few things in order to allow to split the job (optionally) into a 
> sending and receiving part, and let the drawing parts use these.
> But for the peers command example that seemed relatively straightforward stuff 
> and nothing that would harm any code, or so the hope. :-)

Anyway, modifications to the public code base should be done in a way
which is useful for your kind of application but also doesn't change the
way ntpq works.

As mentioned above, my first idea would be to do the thread handling in
my application, and from my thread call a NTP library function which
sends a query, receives the reply packet(s), and returns a buffer with
the requested information to the caller.

>>>But checking now, the RFC 2553 is not the NTP one. Would you happen to
>>>know if the decoding/encoding of the packets are part of the library? I
>>>could not identify it right now.
>>This is mainly done in ntpq_subs.c which is not in the library. This is
>>why I think it would not help you just to distribute libntp as a .so file.
> Right. Seems what I actually want is (much) of the ntpq functionality in 
> a "libntpq.[a|so]", which probably also uses "libntp.a", but that won't ever 
> matter and be visible on installations. So I probably would choose the 
> subject now as "No libntpq (yet)."


>>>>IMHO it would not make much sense to provide the existing libntp as
>>>>shared object library. There is some ongoing work which will encapsulate
>>>>the ntpq functionality in a shared object library, so it would be easier
>>>>to use from an own application.
>>>Can you point me to that work? It seems like we would want to contribute
>>>to that effort then.
> [...]
>>You should discuss this with the guy who's working on this. I'll ask him
>>to contact you. [...]
> Yes, please do that, very welcome. We will have time available to work on 
> this, once we have reached our next milestone. And obviously we will want to 
> coordinate efforts and plans with him.

I'm sure you have seen Heiko has already posted in the news group. The
questions list is just a frontend to the news server.

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list