Don Becker wrote: > Danny, > > Thank you for the reply. > > Your description of the polling and broadcast mechanisms do not match what > is described in David Mills book "Computer Network Time Synchronization", > 2006. Section 2.4 of the book, in describing the broadcast process, > indicates that the client will use the burst feature to set the system > clock, authenticate the server, and compute the offset between the broadcast > time and the client time. It goes on to say that once the offset is > computed the client sends no further messages. >
I'm sorry I didn't catch that, it's not quite correct. You are also mixing things specifically between the standard client/server packets and the broadcast/multicast packets. > You indicate that the delay information from the polls should not be used > with the broadcast messages. > (1) How is the delay for the broadcast messages computed then? can you > reconcile your statement with the David Mills description in the literature? The normal operation is to set up broadcast/multicast with authentication. When you do that, the first *cast packet that the client receives triggers an authentication exchange using NTP packets. Those authentication packets are standard client/server NTP packets with authentication extension sections. The client can then use the delay information from the exchange to calculate the *cast delays. > (2) You mention that NTP broadcast messages can come in from servers that > have not been polled. The NTP daemon should not use messages from unknown > servers becasue (a) the server has not been authenticated and (b) there is > no knowledge of the network delay from the server. If the broadcast/multicast packets has an authentication section and the client is set up to require authentication, the unknown server's address is kept, an authentication exchange described above is conducted and the delay is calculated as a result of that. Note that ALL broadcast servers are unknown initially. The client has no initial knowledge of which system is a broadcast server. > > The description from the book is close to what I need, my only problem is > that the client NEVER polls again. I think that never is too long a time on > a standalone, autonomous network. > Actually it does. The book is slightly wrong. The authentication protocol requires that the keys be refreshed once per day, see http://www.eecis.udel.edu/%7emills/autokey.html for some details. > I have no NTP experience and am relying on documents and feedback from > veterans such as yourself. > The above reference should help you. Danny _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
