Could this also support CA

[MarkRivers]

I learned about SnowSignal at the ICALEPCS meeting this week. It seems very interesting.

I am looking for something exactly like this, but for CA, not PVA. My use case is not docker swarms, but rather simply being able to connect to CA PVs on a different subnet. If the server on the other network is running multiple IOCs then UDP unicast via EPICS_CA_ADDR_LIST cannot be used. This is a common problem.

It seems like it would be pretty easy to modify this to also work for CA, since one can already specify the broadcast port. It should just be the code that checks for whether the packet is really PVA that needs changing.

I do have a question about why there is code to filter out broadcast requests that come from the same MAC address that the UDP broadcast listener is running on:

SnowSignal/snowsignal/udp_relay_transmit.py

Line 141 in fafdb0a

# Do not process packets sourced from this machine

I would like to be able to run CA clients on the same machine as the SnowSignal process that is listening for UDP broadcasts. Why is that not allowed?

[Monarda]

First of all apologies for the late reply. I hadn't set up the notifications on this project properly so I only discovered this issue when I was looking for an old issue of my own.

I think it should be easy to make this possible to work with CA instead of PVA. My recollection is that it was originally protocol agnostic, and that this restriction to PVA was part of trying to track down an intermittent issue. That issue turned out to be improperly handling UDP packet fragmentation. Now that it is resolved it ought to be possible to make SnowSignal properly protocol agnostic again. I should be doing some development on SnowSignal to allow banning of CIDR ranges in the next two weeks, so I'll hopefully be able to roll the change in as part of that. (If you've looked at the code you'll have seen the change is trivial. It's the integration testing that's usually hard!)

The reason for the ban on UDP broadcast packets from the same machine is to prevent UDP broadcast storms. If an instance of SnowSignal receives a packet for rebroadcast it must not receive its own rebroadcast and send it other SnowSignal instances. Doing so would cause a loop as packets were constantly rebroadcast and thus a broadcast storm.

The original SnowSignal prototype used an LRU cache of IP header packet ids to discard received rebroadcasts. An alternative utility, UDP Broadcast Relay, uses a user defined id set in the TTL field of the IPv4 header of rebroadcast packets to discard its own UDP broadcasts and prevent a broadcast storm. So, it is possible to use other criteria to prevent broadcast storms, but it would be a bigger change and make SnowSignal more complex.

[Monarda]

A different source of embarrassment this time, I've done some testing and it looks like SnowSignal does already support Channel Access. Or, rather that it's already agnostic about the format of the UDP payload. To get SnowSignal to work with Channel Access I believe you will only need to default the default broadcast port. Something like:

python -m snowsignal.snowsignal -b 5065 --other-relays <OTHER_SNOWSIGNAL>

ought to work. I don't use a lot of CA so hopefully I've correctly identified the UDP port for the protocol as 5065.

(There isn't an equivalent of the --decode-pvaccess option for CA, but that should only matter for more complex debugging.)