[ntp:hackers] Broadcast/multicast commands

David L. Mills mills at udel.edu
Thu Dec 13 19:38:09 UTC 2007


Danny,

We are suffering a semantic oscillator here. A broadcastclient with no 
arguments means listen on the broadast address of all attached IPv4 
subnets. With one or more IPv4 broadcast addresses, listen only on those 
addresses. With one or more IPv4 multicast addresses, listen on those 
addresses, too. With one or more IPv5 addresses, listen for them, too. 
 From a purely semantic point of view, a mixure of all of these is 
meaningful. It is possible, maybe likely, that the present 
implementation couldn't handle this without a serious fight, but the 
semantics should be meaningful.

Dave

Danny Mayer wrote:

> 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