[ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
kostecke at ntp.org
Tue Mar 11 18:40:57 UTC 2008
On 2008-03-11, Maarten Wiltink <maarten at kittensandcats.net> wrote:
> "Steve Kostecke" <kostecke at ntp.org> wrote in message
>> There is considerable overlap between an "NTP Client" and an "NTP
>> "NTP Clients" and "NTP Servers" both:
>> 1. Poll time sources (e.g. "NTP Servers", ref-clocks)
>> 2. Discipline the system clock
> This _is_ what I'd call the 'client part'. The server part would
> assume or require that the clock is being disciplined by a client
The main functional difference between an ntpd which is operating as an
"NTP Client" and one operating as an "NTP Server" is that latter
receives polls from clients, time stamps them and sends them back.
Currently NTP uses port 123/UDP for both the source and destination
port. What you are proposing would require the use of a different source
port to work on a single-homed host. This would result in a DOS when
polling a server that enforces the NTP port.
Another thing to consider is the fact that you would now have two
processes which both require high priority access to the system clock.
>> 3. Utilize NTP Authentication
> You may have a point there. But I have a feeling that they use it
> differently, one as a client and one as a server. (No surprise there.)
NTP Authentication authenticates the server to the client. So that code
is going to be used, albeit somewhat differently, by both ends of an
>>> The objection when raised earlier was that the server may be asked
>>> for statistics about things that happen in the client; ISTM this
>>> could be solved.
>> By adding another layer of complexity ...
> Yes. Decoupling always adds complexity at the interface. But as a
> software guy I appreciate the focus it adds to the decoupled modules.
That would make sense of there was a substantial difference between the
modules. In this case I doubt that the difference is all that great.
I'd point out that the source is available for anyone to modify, but
that statement seems to interpreted as an attempt to stifle discussion.
So I ... oops
>>> Also, the much-sought feature of re-resolving dried up associations
>>> could be done from a cron job with ntpq/ntpdc. Determining for certain
>>> what configuration to use might be a problem.
>> A 're-resolve' command in ntpq would be useful.
> I don't have the details handy, but aren't there already commands to
> remove and create associations? Probably only in ntpdc, though.
'addserver' & 'unconfig' are currently available only in ntpdc.
FWIW: ntpdc is version specific and it's use has been discouraged on
more than one occasion.
Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/
More information about the questions