Re: EPICS CA and PVA across subnets

[Jure Varlec via Tech-talk <tech-talk@aps.anl.gov>]

Hi,

Your table summarizes things well, although I would add another row: explicitly listing IOCs. If a client is only interested in a few IOCs, listing them all is less overhead than setting up other infrastructure, so this can be a good compromise for some people. CA will use TCP to search for names, so this option is compatible with all sorts of networks. Including, for example, forwarding the CA port over SSH.

That said, I have recently tried using PVA across networks and didn't have much success in my specific situation. Even when you add the IOC to EPICS_PVA_ADDR_LIST, PVA doesn't seem to use TCP to do name searches. I didn't have time for a deeper look, though I did skim over the protocol spec quickly. It looks to me that it can only use multicast for searches. Can someone confirm whether this is the case? If this is so, PVA name searches can't work over networks that aren't layer 2. Like, it won't work over most VPNs.

Best,
Jure

On 9/27/25 23:24, Mark Rivers via Tech-talk wrote:

Caution: This email originated from outside of Cosylab.

Folks,

 

A persistent issue with EPICS CA and PVA is the difficulties that arise when clients and IOCs are on different subnets.  The problem is particularly bad when a server hosts multiple IOCs, because then UDP unicast will find only one of those IOCS. The following table shows my understanding of different solutions:

 

Solution	Pros	Cons
Directed broadcast	Simple setup	Requires IT to permit and configure switches to allow broadcasts from the client subnet to reach the server subnet.
Nameservers	Eliminates UDP broadcasts	Complex setup, requires database of all PVs
Gateway	Allows access control	Complex setup, overhead
iptables	Fairly simple	Linux only; iptables being discontinued on recent Linux versions

 

My use case is beamlines where each one typically has a few client and server subnets, but there are many beamlines.  The complexity of gateways and nameservers is a barrier.

 

At the ICALEPCS meeting there was a poster on another solution called SnowSignal. 

https://github.com/isisneutronmuon/snowsignal

 

SnowSignal was designed to allow PVA UDP broadcasts between nodes in a Docker swarm.  It works using UDP relay.  A SnowSignal process on the client subnet listens for UDP broadcasts containing PVA channel searches.  It forwards those packets via UDP unicast to a SnowSignal process on the server subnet.  That SnowSignal process then converts them to broadcast messages on the server subnet.

 

SnowSignal is about 1500 lines of Python.

 

It seems to me that SnowSignal could be extended to also support CA, and should be usable in any network system, not just inside Docker swarms.

 

I think there might also be a way to optionally make it more efficient.  The SnowServer on the client network currently forwards all EPICS channel searches because it listens for broadcasts.  I would suggest that it could optionally be configured to only listen for UDP unicast channel searches.  The use case is when only a small number of clients need access to the remote subnet.  In that case they can set EPICS_CA_ADDR_LIST to the IP address of the SnowServer process.  It will then only forward the searches for clients that specify that EPICS_CA_ADDR_LIST, and not for all clients.  The optimization is something we currently do with Directed Broadcast.  Only clients that need to access PVs on the remote subnet add the remote subnet broadcast address to EPICS_CA_ADDR_LIST.

 

I’d be interested in hearing other’s thoughts about this.

 

Thanks,

Mark