On Mon, Jan 25, 2021, at 12:17 PM Hal Murray via devel <devel@ntpsec.org> wrote:
Actually, the inner quoted material is mine. > Unqualified thoughts said: > > 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. > I went through and checked the variable names back to NTPv1. It turns out NTPv2 would require 5 bytes difference and NTPv1 would require another 5. > You need a lock on that block in order to prevent the server from getting > half > the data from before an update and the other half from after the update. > (Remember, the old code was single threaded.) > I had this foolish notion that one could set up an extra storage space and an indicator. 1. indicator points nowhere and both storage spaces are empty. 2. client writes the template to a non indicated storage space. 3. client atomically change the indicator to that space. 4. servers use the indicated template 5. the client updates 6. go to set 2. 7. break at some point and exit. Which seems too simple not to be in use. So, it must not work generally. If NTPv3 needs anything that isn't in the NTPv3/4 block, we should add it > rather than creating another block of data. > I think it should generate another block at least on the side with the server then my early over-optimizing says that half the job of filling in fields could be done with a memory copy or three.
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
