[ntp:hackers] 4.2.5p203 adds ntpq dumpcfg command

Danny Mayer mayer at ntp.org
Sun Aug 23 01:51:45 UTC 2009

Hal Murray wrote:
>> That's right.  Returning the output to ntpq might be useful, but it's
>> challenging since you're dealing with small packets and a datagram
>> protocol with no guarantees of delivery or order.
> I was thinking of retrieving it 1 line at a time.

That is the correct way to do it.

> You already have to retransmit in case packets get lost and you already need 
> a sequence number so you can filter out delayed duplicates.  The order isn't 
> a problem.  You only ask for things one item at a time.

Not really. We don't do that with ntpq -p. The order *is* a problem
because subsequent lines have a modifier effects on previous lines. See
restrict for example.

> If you were going to spend a lot of time running this code over long slow 
> links, it might make sense to keep several packets in flight.  I don't see 
> that being appropriate here.

No, you don't want to do that. This is not something that is critical to
the running of ntpd.

> Actually, it would be an interesting experiment to see the size distribution 
> of config files (with and without comments) and how many of them 
> would/wouldn't work in a single but fragmented UDP packet and/or what 
> fraction fit into a single non-fragmented packet.

We don't want to get into the issues of packet fragmentation of UDP
packets. This is a huge discussion going on right now in the DNS
Extensions working group due to the increased requirements for operation
of DNSSEC. Don't even go there. In any case this is not a critical part
of ntpd.


More information about the hackers mailing list