Experimental Physics and
Industrial Control System

Pierrick M Hanlet via Tech-talk <[email protected]> · Wed, 22 Jan 2020 23:48:45 +0000

Perhaps, with help, I could work on this at the code-a-thon.
Pierrick

On 1/22/20 5:01 PM, Michael Davidsaver via Tech-talk wrote:
> Thanks for the details.
>
> On 1/22/20 12:52 PM, James G Smedinghoff wrote:
>> caRepeater did not join the beacon IGMP multicast group,
> Ah, yes.  This is an oversight.  (there had to be something)
>
>> so I used a multicast address for the
>> beacons which the client node was already listening to.
>  From my, likely incomplete, understanding of mcast this seems like it shouldn't work.
> Routing packets to a host is certainly necessary, however the IP stack shouldn't pass
> them along to a particular socket unless that socket has joined the appropriate group.
>
> Still the path forward is clear.  caRepeater needs to process EPICS_CAS_BEACON_ADDR_LIST
> and join any mcast groups listed.  addAddrToChannelAccessAddressList() from addrList.h can
> do most of this.
>
> If you, or someone at FNAL is interested in having a go,
> I think the change would be made to 'sock' just above:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_epics-2Dbase_epics-2Dbase_blob_468f965dc2753e7a381dcc09dd9b5656e3149ac2_modules_ca_src_client_repeater.cpp-23L520&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=lWgMUJ9IIDH_eCcPLDGLwQ&m=WZqbF9QfLagwsy3viHZphbrj0nKr-Pp1AgsGSSQtnbA&s=TDS-qdOEPBAbboWMYbPcCsqcmvMSpiLbDCXmqeuB4xo&e=
>
>
>
> On 1/22/20 12:52 PM, James G Smedinghoff wrote:
>> On 1/22/2020 1:24 PM, Michael Davidsaver wrote:
>>> On 1/22/20 8:18 AM, Denise Finstrom via Tech-talk wrote:
>>>> Hello,
>>>>
>>>> Is there an equivalent to EPICS_CA_MCAST_TTL for the pvAccess protocol?
>>> There isn't one.  PVA doesn't (yet) support search by mcast.
>>>
>>> Were you able to make this work with CA?  What does your network topology look
>>> like?  (how many hops)  Did you encounter any problems?
>> Yes, I was able to use multicasts for CA search and beacons by defining environment variables.
>> On the client:
>>
>> EPICS_CA_ADDR_LIST=<multicast address1>
>> EPICS_CA_AUTO_ADDR_LIST=NO
>> EPICS_CA_MCAST_TTL=20
>>
>>
>> On the IOC:
>>
>> EPICS_CAS_INTF_ADDR_LIST=<multicast address1>
>> EPICS_CAS_BEACON_ADDR_LIST=<multicast address2>
>> EPICS_CAS_AUTO_BEACON_ADDR_LIST=NO
>> EPICS_CA_MCAST_TTL=20
>>
>> caRepeater did not join the beacon IGMP multicast group, so I used a multicast address for the
>> beacons which the client node was already listening to.
>>
>> The control system has a large central router which is connected to about a dozen 256 address subnets.
>> Each subnet is only 1 hop from the others. More hops would be needed to get to non-controls subnets
>> or the internet.
>>
>> Jim
>>> Adding this was a project of mine a few years ago.  I've actually never been
>>> certain that it would work at scale since I don't have access to a large
>>> network with mcast routing enabled for testing.  Nor have I had any feedback
>>> from users until now.  So adding this feature to the PVA protocol code hasn't
>>> been a priority for me.
>>>
>>>
>>>> We are attempting to use multicast for PV search and haven't found a way to change TTL values when using pvAccess. When we set EPICS_PVA_ADDR_LIST to a multicast address, the multicast goes out with a TTL of one and doesn't get routed to other subnets. We are successfully using multicast for PV search with the CA protocol and EPICS_CA_MCAST_TTL. We are looking to do the same with pvAccess, but the EPICS_PVA_MCAST_TTL environment variable doesn't seem to exist. We are using base-7.0.3.1. Any advice would be appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> Denise

-- 
Pierrick Hanlet
Fermi National Accelerator
Accelerator Front End Controls
+1-630-840-5555 -- lab
+1-312-687-4980 -- mobile

"Whether you think you can or think you can't, you're right" -- Henry Ford

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System