Long range thoughts

[Hal Murray]

devel at ntpsec.org said:
> I think you mean mode 6/7 server there. It might also be a place to configure
> and read/write files. 

Mode 7 is gone.

I'm willing to throw away mode 6 as long as we replace it with something that 
has roughly the same functionality as the current ntpq.

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

The NTS-KE server already writes the keys to disk.  The NTP server would read 
that on startup and monitor and auto-reload when the file is changed.

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

Mostly, I'm interested in counters.  I don't consider a missing counter to be 
a bug.  It's things like how much traffic is using IPv4 vs IPv6?  If you 
didn't anticipate that question, then you have to add new counters.


> 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. 

What do you mean by "mru in a separate process"?  I want something similar to 
the current mru that the ntp server calls to record statistics and/or 
implement restrictions/filters.  That has to be lightweight.  If you mean 
running the ntpq server (or the part that does mru) in a separate process, 
that's fine, but we have to work out the locking.

If we do away with the restrictions, then the ntp server doesn't need an 
answer.  We could do something like stuff the IP Address into a pipe and let 
some other process do the work.  But that has a syscall - the write to the 
pipe.  I'll bet it's faster to just do it.




-- 
These are my opinions.  I hate spam.