[ntp:questions] No libntp.so

Martin Burnicki martin.burnicki at meinberg.de
Thu Aug 28 11:35:20 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 role.

OK. However, if 25 milliseconds is still too long for other task you are
running you should do this asynchronously anyway.

>>>As we would like do other important stuff in the same process, we would
>>>like to do that faster. So I had a look at the source and found that ntpq
>>>is using a libntp.a that nobody seems to package though. There is no
>>>libntp.so either, we had searched for those initially, but no luck.
>>Libntp just contains a couple of functions which are shared between several
>>programs of the NTP package, e.g. ntpd, ntpq and others. It is used during
>>the build process of the package in order to save compiule time.
>>
>>Even if you would be made available als shared object file it would not
>>provide the full ntpq functionality.
> 
> 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.

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

>>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.
> 
>>However, those calls may also block, so the basic requirement to call those
>>functions from an own tread/task would be unchanged.
> 
> One would hope that it could provide both kinds of APIs by allowing us to poll 
> on the reply receiving socket. That's not normally very hard to refactor code 
> that waits for a reply to give back control and continue when the reply comes 
> in. Provided of course, the protocol allows questions and replies to be 
> matched by another criterion than sequence, can they?

You should discuss this with the guy who's working on this. I'll ask him
to contact you. BTW, I wonder why your post to which I'm just replying
is not yet shown by the public news servers?

>>>The question of course would be: Will you merge such Makefile patches
>>>from us in the first place. And do you see any reason why this should not
>>>be done like this. After all, it has not been done for a long time
>>>already, so possibly this is on purpose?
>>>
>>>Obviously we hope you will allow us to be good Free Software citizens and
>>>let us drop the fork down the road. Will you?
>>The question is not basically whether a patch is accepted. In the first
>>place the question is whether a patch makes sense at all. As already
>>mentioned above I think it does not much sense just to provide libntp
>>as .so file.
> 
> If it's only based on the fact that the NTP code isn't ready yet, we will be 
> happy as it seems that we can work with you to get it there. 
> 
> It seems I was overly optimistic when I saw the listing of libntp directory, 
> because it included an RFC in file name. Too bad that's not the NTP RFC. :-/

Right. The RFC for NTPv3 is 1305. See at the bottom of:
http://www.meinberg.de/english/info/ntp.htm

For NTPv4 there's no RFC but an IEEE draft. See:
http://www.ietf.org/proceedings/05nov/ntp.html


Best regards,

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list