Unqualified thoughts

[James Browning]

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.

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.

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.

IIRC there was a draft over at IETF to have the client port hop instead of
sticking to 123/UDP.

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.

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.

* RFC1059 https://tools.ietf.org/html/rfc1059
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20210125/8ccc1da7/attachment.htm>