Question: Using pvagw like a MQTT broker

[jembishop]

Hi there, bit of a left field question.

In some ways the pvagw acts like a MQTT broker in that it will broadcast a PV update issued by one client, to all other listening clients. One could consider an EPICS setup which ensures all PV access goes through the PVAGateway, even devices on the same network.

Operating the pvagw in a "MQTT broker" style mode has some potentially nice properties:

• You don't need to worry about the udp broadcast aspect of EPICS, which can sometimes be difficult to deal with
• The api for hosting your own reactive PV and listening to another external pv can be unified. I.E you can just do ctx.monitor to create a python server that listens to a PV and reacts. You do not have to have a p4p server "owning" the PVs as such.
• You can use all the features of the PVAGateway such as logging, access controls etc

The downside is this disables direct communication between devices. But in many contexts with slow controls system, that isn't as big of an issue, and the benefits of only using just the pvagateway can outweigh this.

I haven't actually tried this, but I suspect this could work by configuring the PVAGateway to point at the same network it listens to. So my question would be, would this mode of using the PVAGateway be officially supported and do you think its a feasible idea?

[mdavidsaver]

In some ways the pvagw acts like a MQTT broker ...

One usage of a PVA or CA gateway is to reduce traffic or otherwise "shield" an IOC from a large number of clients. This is what I was trying to communicate with the graphics in the manual.

... I suspect this could work by configuring the PVAGateway to point at the same network it listens to ...

Such router-on-a-stick typologies can be accomplished with gateway(s) listening and serving on the same interface, but different ports. For example, the loopback.conf configuration I use for testing pvagw.

Take care when planning a deployment with multiple pvagw instances. While one pvagw process is smart enough not to connect to itself, multiple processes can form loops.

The downside is this disables direct communication between devices ...

This sort of situation is where the peer-to-peer design of EPICS can distinguish itself from a strict broker based system. Forcing some clients to communication to a group of IOCs through a gateway does not prevent direct communication between those IOCs.

• You don't need to worry about the udp broadcast aspect of EPICS, which can sometimes be difficult to deal with

With compatible clients (PVXS and core.pva) this is accomplished by setting EPICS_PVA_AUTO_ADDR_LIST=NO and EPICS_PVA_NAME_SERVERS=mypvaga.host. I find this handy with ssh port forwarding.

[jembishop]

Thanks @mdavidsaver, this was informative advice.