I would like to remove support for ntpdc's mode 7 management from ntpd in ntp-dev soon.
What is wrong with ntpdc's mode 7 on-wire protocol? It's complex, fragile, and requires a large amount of tedious, error-prone marshalling and unmarshalling code in both ntpd and ntpdc. Moreover, with the release in the next day or so of 4.2.7p191, I claim it is wholly redundant with ntpq. That is, I believe as of ntpd 4.2.7p191, everything that can be done via ntpdc and its mode 7 management traffic can now be accomplished with the simpler and safer mode 6 requests issued by ntpq. Please file bugs or otherwise alert us if you find otherwise. (As an aside, in 4.2.6 and earlier, mode 7 management packets are issued by ntpd's intres DNS code to spin up server associations after resolving an IP address, via 127.0.0.1:123. That means in 4.2.6, simply ripping out support for mode 7 would also rip out support for specifying servers by name rather than numeric IP address. Since early in the 4.2.7 cycle, the new intres code in ntpd does not rely on mode 7, incidentally also enabling IPv6-only operation in theory.) Why is ntpq's mode 6 protocol preferable? It is largely text-based, where mode 7 uses binary requests and responses each requiring lengthy, error-prone marshalling and byte-swapping code in both ntpd and ntpdc. Typically new capability can be added to ntpq without any protocol work, while each addition or change to ntpdc typically requires new binary request and response packet definitions. Also, thanks to the preference for ntpq, ntpdc has not been as well maintained, though it's fared better than ntpdate. To see for yourself the inflexibility and resultant code bloat of the mode 7 protocol, take a look at either ntpdc/ntpdc_ops.c or ntpd/ntp_request.c focusing on how support was added for IPv6's 128-bit addresses on top of the existing 32-bit IPv4 provisions. Unlike the situation with ntpdate, I do not propose removing the ntpdc code anytime soon. It will retain utility for managing older ntpd instances for some time to come, as with 4.2.6 and earlier, some management capabilities were only available via ntpdc (for example, querying network interfaces used by ntpd, or fetching the recent client address list). On the other hand, I'm strongly in favor of losing the mode 7 support code in ntpd/ntp_request.c, which is voluminous, error-prone, and redundant. One way forward would be to simply rip out ntp_request.c and call it done. Some might be happier with a transition period where support for mode 7 could be explicitly configured, such as with a hypothetical "enable ntpdc" in ntp.conf. I would prefer the former, but as a ntpd maintainer my perspective is biased. What do you think? Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
