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. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
