Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Fri, 18 Dec 2015 15:20:51 -0500

On 12/18/2015 01:43 PM, Andrew Johnson wrote:
> On 12/18/2015 07:43 AM, Michael Davidsaver wrote:
>> Agreed.  Beacons should appear to come from the appropriate source 
>> address.  I should note that RSRV tries to put the correct
>> interface address in the message body (and succeeds in at least
>> some cases).
>>
>> http://bazaar.launchpad.net/~epics-core/epics-base/3.16/view/head:/src/ioc/rsrv/online_notify.c#L263
>>
>>
>>
>>> What are the consequences? Are there any?
>> I doubt there are any real consequences either to the present 
>> behavior, or to fixing it.
> The "Background:" description in Ralph's second message is helpful to
> understand what's going on, but it doesn't cover the whole story.
>
> Remember that beacons are received by the CA Repeater running on the
> client machine and forwarded to all its CA clients. The repeater
> should be listening on all interfaces [aside: it doesn't know anything
> about dynamic interfaces, there's another bug someone might want to
> think about], so it *will* get multiple copies of any IOC beacons
> where both the client machine and IOC have interfaces on more than one
> common subnets.

I'm fairly sure that if bound to 0.0.0.0 (ca caRepeater does) you will
see traffic from all interfaces, including those added after bind().

> A CA client program running on such a workstation will usually have
> EPICS_CA_ADDR_LIST set to only a subset of the interfaces to avoid the
> multiple PV warnings, but I'm pretty sure the client library will
> still be forwarded the beacons that arrive on all the network
> interfaces that the repeater is listening on.

carepeater registrations (really zero length packets) can't have
conditions, so it should see everything.  (which has some implicates for
cagateway)

> By the IOC always using its first IP address in all its beacons it
> reduces the work done by the above CA clients — they only need one
> indication from each IOC that it's healthy, so making these duplicates
> that can be very quickly discarded is better than getting a separate
> beacon for each interface the IOC is connected to.

Talking about "first IP address" is questionable since this isn't, to my
knowledge, ever explicitly configured, is probably not specified, and
likely unstable over OS upgrades (or even reboots).

> Thus I do not believe that this behaviour is a bug at all, and it
> should not be "fixed". It might be worth adding a note about this to
> the protocol documentation.

I don't see how "first interface" could be reasonable specified.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System