[ntp:questions] Re: "Listen on" semantics
maarten at kittensandcats.net
Thu Sep 21 08:18:17 UTC 2006
"Harlan Stenn" <stenn at ntp.isc.org> wrote in message
news:ywn9k63y5gcl.fsf at ntp1.isc.org...
>> "Luc Pardon" <xntp at skopos.be> wrote in message
>> news:45110BAE.8040106 at skopos.be...
>>> What I want is not so much two copies of ntpd as a separation
>>> between client and server functionality.
>>> The client should keep my clock on track. The server should tell
>>> all my other systems what time it is.
> As I understand it, that is not the ntp model, that is the timed model.
You may be reading things into the terms 'client' and 'server' that
weren't there. (I think) the terms are being used strictly in a network
sense: a server is a process that only listens; a client is a process
that may _start_ conversations. No mention of all the intricate math
that goes on in a full NTP implementation; obviously it does have to
There is nothing that says Luc's proposed NTP client mustn't be a
continually running process; in fact, 'the NTP model' would require it
to. But the server part would not need to do all the NTP work itself.
It might simply assume (or check) that the clock is being disciplined,
and return packets as requested by remote clients.
The introduction of a 'client only' mode for NTP (not SNTP) would make
many people happy already. That could use ports in such a manner that
time service does not automatically become available from the machine,
and could try not to get in the way of a separate simple NTP time server.
The first version of such a separate NTP server could be _really_ simple.
After all, all it has to do is read the clock for anyone who asks. To
keep the clock running straight is the client's job.
At this point, people will shriek 'that's an SNTP server! Not NTP!' But
is it? What's the difference? The current definition seems to be that
to be an NTP server, you have to implement the client functionality (the
math) yourself. I think it's more important _that_ the math is being
done. _Where_ is not that important.
> OpenBSD's OpenNTP was, as I recall (and IMO), originally a malignantly
> broken SNTP implementation.
Malignantly, no less? Come off it. Sure, they made mistakes, but that
wasn't the intent. The intent was to build something with no exploits.
If the question is what comes first, working right or not getting rooted,
well, they _are_ OpenBSD.
(Wouldn't a client-mode real NTP, combined with an OpenSNTP server, be
the ideal configuration?)
More information about the questions