Splitting ntpd

[Hal Murray]

Here are the cnhnks I have in mind:
  NTP server
  NTS-KE server

  NTP/NTS client
  refclocks

  monitoring/ntpq


I have debugged the lockclock mode so we now have a stand-alone NTP server.  
It gets the error data from the krenel.  (Or can/should.  I haven't checked 
that code.)  As just a server, ntpd is horribly bloated, but it's enough of a 
proof of concept that we can play with it.

The NTS-KE server needs to cooperate with the NTP server to get cookies.  
That's easy if they are co-packaged.  If we split them up, the KE server can 
read the cookie file and we can scp that to other machines.  It may be cleaner 
to split them when we get to paying attention to DoS-ing.


The key idea with the client side is to use threads.  Each thread would use 
its own socket.  Nobody would be listening on port 123.  That will take a lot 
of work.


I haven't thought much about splitting out refclocks.  I assume they should 
use Unix sockets to talk to the client.  We need some way for 
monitoring/debugging code to watch.  Maybe the data goes in shared memory too. 
 Or maybe the refclock opens several sockets.


For monitoring/ntpq, I think we can use shared memory.  They would be 
read-only by ntpq.  I picture ntpq running in two modes.  For starters, it 
looks directly into shared memory and only works when run on the target 
machine.  Then we split it into two parts connected via the network.

I want a simple and reliable way to update this area.  It's going to take at least 2 edits.  One to define the counter and one to bump it.  I picture a text file that gets translated into the structs for the code and also for the table that ntpq needs.


It isn't really part of splitting ntpd, but I think a clean sntp client will fit into this collection.


-- 
These are my opinions.  I hate spam.