<div dir="ltr">I think it would be a not-very-good idea to add a bottleneck er mutex to threading NTPsec, Linux worked hard to kill off their global lock IIRC.<br><br>A 24 block byte should suffice for the client-supplied data to the NTPv3/4 server threads, NTPv2 would probably need the same with perhaps a dozen bytes differing.<br><br>Port 4460/UDP should be a possible place to move mode 6 handling to. If atomic operations can be assured ala C11 then the server threads can serve most data types without locks. I suspect the MRU list would be different.<br><br>IIRC there was a draft over at IETF to have the client port hop instead of sticking to 123/UDP.<br><br><div>I think we should stop supporting NTPv1 at all rather than wrongly. Having looked at the RFC* I can tell you that it did not have mode flags. Instead, the packet mode was determined by the origin and destination ports.<br><br>I have a local branch where I have attempted to implement singlesock without success. The result crashed on routing updates, reliably failed to respond to IPv6 in a couple of cases, and messed up the stats. Also, I did not even try making it thread friendly.</div><div><br></div><div><div>* RFC1059 <a href="https://tools.ietf.org/html/rfc1059" target="_blank">https://tools.ietf.org/html/rfc1059</a></div></div></div>