Long range thoughts

[Hal Murray]

Lots of handwaving here.

I'd like the server to run multi-threaded.

At a talk at Stanford yesterday, the speaker liked Rust.  He called it Safe C, 
good for embedded systems.  A simple NTP server (no client, no ntpq server) is 
simple enough for an embedded environment.  (When I run out of other things to 
do, I'll probably give it a try.)

There was discussion on the IETF NTP list of having the client use a separate 
port.  The idea is to make it harder to attack a client only system.  (There 
may be a draft RFC.)

Can we break the current ntpd blob into smaller chunks?  How about:
  NTP server
  NTP client
  NTS-KE server
  ntpq client

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.

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.

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.

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.

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

Mumble.  Any of that make any sense?


-- 
These are my opinions.  I hate spam.