[ntp:questions] No libntp.so

Martin Burnicki martin.burnicki at meinberg.de
Thu Aug 28 13:39:16 UTC 2008


Kay,

Kay Hayen wrote:
> Hello Uwe,
> Use Klein wrote:
>> Kay Hayen wrote:
>> > We were considering to use an expect wrapper (python-expect) to channel
>> > the data to us, and it would certainly improve the results. But I see
>> > no reason to use that workaround at all. Why should we make ntpq draw
>> > ASCII art only to parse it and endure the changes between your
>> > releases?
>>
>> I personally don't release anything.

Kay, I think your mentioning of "your releases" made Uwe thik you are
assuming he's involved in the NTP release cycles, but he's not.
 
> I didn't say so. In German I would have said "Dnderungen zwischen Euren
> Releases" 

Auch mit "Euren Releases" ist Uwe angesprochen. See above.

[...]
> But given the choice, we would prefer to use a libntp. What's wrong with
> that,
> except that you don't find it necessary? On the pro-side there is:
> 
> a) A significant reduction in lines of code used which can only lead to
> less bugs.
> b) The CPU used to make one set of queries will be lower potentially
> enabling a higher frequency of checks achieving lower latency in detecting
> NTP problems.

The problem is that libntp is only used internally to build other
components. It does not provide all the functionality provided by "ntpq
-np" since lots of ntpq stuff is in the ntpq-specific source modules.

Ntpq sends queries to ntpd, and ntpd replies with a long string of
"variable=value" pairs. Ntpq then parses that string and displays the
relevant information in a user-friendly way.

A shared object library which supports ntpq-like queries must contain the
basic functions of ntpq, i.e. send queries to ntpd and receive and assemble
the replies which may arrive in multiple UDP packets.

I think for external applications like the one you're going to write it
would not be required first to print the results to a billboard and then
parse that billboard. It would be more convenient to have a function which
returns a string buffer with the var=val pairs, or another function which
retrieves and only returns the value of a specific variable from that
buffer.

Which functionality exactly would be provided by such a library, and how
those functions are called to avoid naming conflicts should be subject to
discussions.

BTW, do you know the NTP time server monitor?
http://www.meinberg.de/english/sw/time-server-monitor.htm

That Windows program can monitor several NTP servers, and it uses an a DLL
which encapsulates the ntpq functionality as described above. However, this
contains some inofficial modifications of the NTP source code, i.e. those
modifications are not in the public code base.

The goal of the ongoing work on such an official library (which I've
mentioned earlier) is to get those modifications to a proper state which
can be submitted to the NTP code base.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list