[ntp:hackers] Broadcast/multicast commands

Danny Mayer mayer at ntp.isc.org
Mon Dec 10 04:38:12 UTC 2007


Dave,

The real trouble here is that currently broadcastclient takes no
arguments (if you ignore novolley) and enables ntpd to accept broadcast
packets from all network NIC cards. multicastclient on the other hand
requires a multicast IP address and it's an error to omit the IP address
and only that address is configured to access broadcast packets sent to
that multicast address. This is different from broadcastclient. That's
why it's hard to implement a merger between the two options.

Danny

David L. Mills wrote:
> Danny,
> 
> The message was a trial ballon; I have no intention to cut code.
> 
> I want the novolley option to go away in any case. I had assumed you 
> could tell from the address whether it was a IPv4 broadcast or multicast 
> or IPv6 broadcast. At least the broadcast command can do that.
> 
> Dave
> 
> Danny Mayer wrote:
> 
>> Dave,
>>
>> You cannot obsolete the multicastclient option. That option takes a
>> multicast address while broadcastclient does not. Even worse, for
>> multicast you need to deal with both IPv4 and IPv6 multicast addresses.
>> The novolley parameter happens to be a strange one since it can be any
>> argument that uses novolley. You will break a lot of operating ntpd
>> servers if you do this.
>>
>> In short, this won't work. You are *not* dealing with a single address
>> and you *must* specify it and configure to a specific multicast address
>> when setting up multicast.
>>
>> Danny
>>
>> David L. Mills wrote:
>>
>>> Guys,
>>>
>>> Occasionally I get requests to enable broadcast reception on a specific
>>> local subnet when a client is connected to more than one. This applies
>>> expecially to certain redundant configurations. Right now, the broadcast
>>> command is used for both IPv4 broadcast and multicast and IPv6 broadcast
>>> configurations, but separate broacastclient and multicastclient commands
>>> are necessary.
>>>
>>> It would be nice if the broadcastclient command could be used for all
>>> configurations supported by the broadcast command. Howeve, this appears
>>> to be in conflict with the current syntax, which takes a single argument
>>> in the broadcast command to suppress the delay volley. This function can
>>> now alternatedly be controlled by the broadcast delay command. If the
>>> above functionality can be implemented, I propose to eliminate the 
>>> argument.
>>>
>>> In summary, the broadcast commend semantics remains the same. The
>>> multicastclient functionality is moved to the broadcastclient and the
>>> multicastclient command removed. Multiple broadcast client addresses are
>>> supported in the same broadcastclient command. The default in this
>>> command is to listen to all interfaces as it does now.
>>>
>>> The resullt would be a lot cleaner and more obvious to the newbie, as
>>> well as provided useful functionality in multi-homed redundant
>>> configurations.
>>>
>>> Dave
>>> _______________________________________________
>>> hackers mailing list
>>> hackers at lists.ntp.org
>>> https://lists.ntp.org/mailman/listinfo/hackers
>>>
> 
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers
> 



More information about the hackers mailing list