[ntp:hackers] Broadcast/multicast commands

Heiko Gerstung heiko.gerstung at meinberg.de
Mon Dec 17 12:21:31 UTC 2007


David L. Mills schrieb:
> 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.
>   
Wouldn't it be reasonable to add a "multicastclient" config option then? 
>From a semantic point of view I never liked to explain customers and 
users to "use broadcastclient to enable multicast mode".

Suggestion:
a) broadcastclient without parameters -> listen to broadcast addresses 
of all NICs
b) broadcastclient with one or more parameters -> listen to specified 
broadcast address(es)
c) multicastclient without parameters -> invalid (config error)
d) multicastclient with one or more parameters -> listen to specified 
multicast address(es)

Alternatively c) could be defined as "listen to default NTP multicast 
address".

Best Regards,
Heiko


> 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
>>>
>>>       
>
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers
>   



More information about the hackers mailing list