<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 19, 2019 at 1:45 PM Hal Murray via devel <<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>There is probably something like a FAQ entry that explains that if you want to <br>
get time relevant data from A to B, you have to start by sending something <br>
from B to A, a nonce if nothing else.<br>
<br>
You could eliminate duplicates by having the sender include a sequence number. <br>
 You would have to add a dance to get started.<br>
<br>
I don't see how to protect against delays without sending something from B to <br>
A -- or knowing the time.<br></blockquote><div><br></div><div>Broadcast, manycast and multicast are server *discovery* methods, similar to pool.  Once discovered, the usual ping-pong happens.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
>> I'm not sad to see broadcast modes gone.  It was tangled up with a<br>
>> state machine which I never really understood.<br>
<br>
> And may no longer exist since Daniel's massive refactor of the protcol<br>
> engine! <br>
<br>
I removed the state machine after we had removed enough stuff (like broadcast <br>
and peers) so that the remaining cases were simple enough to understand.  That <br>
was a while ago.<br>
<br>
<br>
-- <br>
These are my opinions.  I hate spam.<br>
<br>
<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>