Long range thoughts

[James Browning]

On Fri, Feb 28, 2020 at 3:26 AM Hal Murray via devel <devel at ntpsec.org> wrote:
>
> Lots of handwaving here.
:::snip:::
> Can we break the current ntpd blob into smaller chunks?  How about:
>   NTP server
>   NTP client
>   NTS-KE server
>   ntpq client

I think you mean mode 6/7 server there. It might also be a
place to configure and read/write files.

> I don't have good proposals for how the ntpq client can get information from
> the other chunks.  The only info from the NTS-KE server is counters.  Shared
> memory would work fine.  Same for most of the NTP server.  The part of a NTP
> server that isn't counters is the MRU list.

If you are rotating the key, you would also need to synchronize
that.

> One of the interesting advantages of the one-big-blob approach is that all the
> parts are using the same version of things in memory.  For shared memory, we
> would have to work out some sort of versioning.  The ntpq client would have to
> be able to read all old versions.

If you hammer the bugs out of the initial release, you will
likely not need as many versions.

> Ignoring version problems, are there parts of the ntpq protocol (other than
> mru) that won't work with shared memory?  I'm assuming an array for the peer
> stuff.

I had a pitch I never got around to making that would enable
mru in a separate process. It sent the remote addresses to
the mode 6 server.

> The configure options to a server are simple enough that a simple parser would
> be good enough.  Perhaps that's only because I'm willing to discard frills and
> options from the configuration.  For example, most of the log files are client
> side.  I'm willing to make the few the server needs be day only with default
> names and link from name-without-date to the current name-with-date.

Yes, we will not get any flak from the naysayers or Stenn
for "throwing away perfectly good options".

> I haven't thought much about ntpq.  I'm willing to make a new protocol.

Perhaps a mode 6 replacement over https?