[ntp:questions] Re: "Listen on" semantics
xntp at skopos.be
Thu Sep 21 09:41:51 UTC 2006
Maarten Wiltink wrote:
> "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
> go somewhere.
I must admit that I'm probably at the source of the confusion.
What I meant in this paragraph was not in a network sense, i.e. at
the transport or socket layer, but at the application layer. By "client"
(i.e. "time client") I meant to include all the magic that (x)ntpd uses
to determine the time from "time servers" at a higher stratum.
In the other parts of the discussion, I was using the terms indeed
in the network sense.
To make it [clearer|more confusing] : currently, the (x)ntpd "time
client" uses a "socket server" (listening) to receive its time info,
i.e. it operates in async mode. I would like to see it use a regular
"socket client" in synchroneous mode instead.
> 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.
Exactly. I don't care too much how the client and server are
implemented, in separate processes or in one single process, although
personally I'd go for separate if possible (KISS and security). But if
they are in a single process, I'd do want to be able to switch the
logical components (client, server, peer) on or off in the config file
to suit my needs.
> 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.
It certainly would make _me_ happy. What I miss in OpenNTPD is not
so much the reduced precision as the lack of ntpq.
In any case, I believe that "my" setup, i.e an stratum 3 server for
an internal network, is a typical setup. It's Not Good to force all
these admins to choose between better time and better security if they
can have both.
> Maarten Wiltink
BTW: thanks for the moral support!
More information about the questions