On 2008-03-11, Maarten Wiltink <[EMAIL PROTECTED]> wrote: > "Steve Kostecke" <[EMAIL PROTECTED]> wrote in message > >> 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.
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 authenticated association. >>> 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 <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
