"Steve Kostecke" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 2008-03-11, Maarten Wiltink <[EMAIL PROTECTED]> wrote:
>> As a software guy, I've wondered before about the monolithic nature of >> the NTP package. Splitting it into a client and server part might make >> some people (think OpenBSD) very happy. > > There is considerable overlap between an "NTP Client" and an "NTP > Server". > > "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 implementation. > 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.) [...] >> 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. >> 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. Groetjes, Maarten Wiltink _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
