Unqualified thoughts
James Browning
jamesb.fe80 at gmail.com
Fri Jan 29 10:14:24 UTC 2021
On Mon, Jan 25, 2021, at 12:17 PM Hal Murray via devel <devel at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20210129/5f3d0221/attachment.htm>
More information about the devel
mailing list