<div dir="ltr"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 28, 2020, 12:17 AM Hal Murray via devel <<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I've been thinking about how to make ntpd serve lots and lots of clients.<br>
<br>
I think that requires the server to be multi-threaded, especially if we want <br>
to support NTS.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
----------<br>
<br>
I think we should split ntpd into 3 chunks: client, server, and mode6.  <br>
Currently, they are all tangled up at the receive packet processing.  I don't <br>
mean 3 separate programs, but won't rule that out.  The main idea is to <br>
understand where they interact.<br>
<br>
There is a draft RFC to have the client use something other than port 123.  <br>
Splitting the client and server gets that.<br>
<br>
Using threads will clean up the packet processing at the cost of adding locks. <br>
 I think the locks will be simple -- after we understand where they interact.<br></blockquote><div><br></div><div>bottlenecks. I think the way to do that would be to have the client<br>export some variables, and the servers import them. Depending on how<br>far back/forward you want to support It could be as little as 22bytes<br>to much longer. v2 would require at least 16 more bytes, v1 eight<br>more than that, rfc958 (v0?) is sufficiently old/different that I<br>would not recommend humoring it. I'm probably not reading things<br>correctly though.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The client can stay single threaded.  I haven't looked carefully, but the <br>
server doesn't need much data from the client side so I'm pretty sure we can <br>
make a clean handoff with a simple lock.  The server only reads that data.<br>
<br>
It's possible that it might be easy and clean to split the client and server <br>
into separate programs.  The client feeds a lot of into to the kernel where <br>
the server can get it back.  I'll have to check on what that covers.<br></blockquote><div><br></div><div>I'm not sure that would work very well. I think the only values in<br>the packet that could be pulled from the kernel are the time and<br>precision, which needs to be converted.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It will probably help to rearrange the header files, something like network, <br>
utility, client, and server.<br>
<br>
If we start using threads, it will be easy to give each refclock a thread.  <br>
Again, the critical step will be understanding how it interacts with the main <br>
client side thread.  For example, the server side doesn't need to know <br>
anything about the peer struct.<br></blockquote><div><br></div><div>I think it would be possible to farm out associations to external<br>processes and have them communicate data for sets of associations<br>via SHM or something. It should be possible to have sets for other<br>protocols, time receivers, server peer responses, LAN machines, the<br>pool w/ daily/weekly expiration for the worst/eldest, and so forth.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Humm.  I wonder if the client side gets cleaner if we have a thread per <br>
server.  That's probably a big step toward fixing the 1 second polling mess <br>
that keeps laptops from power saving.<br>
<br>
I haven't thought much about mode6.  I'm willing to discuss anything.  We <br>
could shift to TCP to avoid the DDoS amplification issues.  If we stick with <br>
UDP, we need a new port number.  The current code is mostly ASCII on the wire. <br>
 Should we fix the rest of the binary data?  Note that there are 2 parts to <br>
mode6, the client (peers) and the server (mrulist).<br></blockquote><div><br></div>I think it should be possible to mostly replace mode 6 w/ essentially<br>a web-UI and have the various components reply to questions via JSON<br>and SHM, with ALPN running an updated version of mode 6 over the same<br>port.<br><br>config, mrulist, system, peer, and refclock I think. config would be<br>more complicated with it split up, also mrulist if multiple servers.<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--------------<br>
<br>
When I started typing this, I was focused on the socket level interface.  The current receive dispatching seems pretty ugly to me.  Splitting the client and server was a way to clean that up.  And I wanted many threads for the server.  But the list above kept getting longer as I typed things in.<br>
<br>
Maybe we should start from scratch.  Why bother with a Go translator?<br></blockquote><div><br></div><div>I think we'd have to give up the name. Also, the output of ccgo3(?) <br>was rubbish and will not translate (mostly unneeded) long doubles.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe we should go help with chrony.<br></blockquote><div><br></div><div>I think a fair number of people have wandered off.<br></div></div></div></div>
</div>