[ntp:questions] Re: "Listen on" semantics

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

> Groetjes,
> Maarten Wiltink
    BTW: thanks for the moral support!

     Groetjes terug,


More information about the questions mailing list