Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Wed, 12 Dec 2007 13:32:12 +0100

Hello Heinrich,
trying to comment on at least some of your questions....
Wouldn't it be nice to specify the EPICS_CA_* values firstly through
functions in the library rather than environment variables only.

And then secondly on a per-connection basis.

So you can have seperate setup for every PV connection. ?

(Note that there is one connection between a CA client (your
application) and the CA server (IOC), which is shared for all PVs on
that server, so "for every PV" is different from "for every connection".)
This is not easy to implement. I've been missing this a couple of times
for the CA Gateway, though. Would be nice.
Name resolution is done by UDP broadcasts or directed UDP messages, and
it is highly optimized: many PV names are broadcast in one UDP message.
In case of EPICS_CA_ADDR_LIST being set, the UDP messages are sent only
to the specified IP addresses, but still many names in one message. As
UDP is not reliable, a burst of UDP messages is sent for a single name
resolution broadcast.

If you allow to specify a different EPICS_CA_ADDR_LIST for every PV, you
would either have identify different CA domains (each with a different
setting) and put any new PV connection into the matching domain (create
a new one for a new config) or send the usual burst of UDPs for every
single PV that is needed. The first option is tricky, the second would
easily overload the network and the IOCs.

Jeff definitely has a better inside view on this issue.
Is it possible to link casw into a program somehow? So that your
client program can monitor the status of a specific IOC?

The casw source is part of base - feel free to link it into one of your
programs .... :-)
I would say there are better ways to monitor IOC health than beacon
regularity. Beacons are sent with relatively low priority - you may have
situations where you see a beacon anomaly while the IOC is busy, but
still doing fine. Also bad configuration on an additional IOC may look
like a beacon anomaly on yours.
If you install vxStats (or the Linux version done by the SLS for soft
IOCs), you can monitor things like CPU load, FD and memory usage. Or
load a calc record that just counts up and monitor it. All this gives
you more and faster health info than casw.
Also have a look at the Nagios plugin that Mauro Giacchini wrote - maybe
that is a good point to start from. You can monitor a bunch of records
(see above), ping the IOC, and use all the nifty Nagios stuff like
configuring what emails to send in case of alarm, schedule downtimes
etc. pp. That fits very nicely into the Nagios approach to constantly
monitor all your infrastructure and services within one tool.
It could also be an idea to have a casw based device support that
reports beacon anomalies. Fixed configuration specifies the IOC to look
for, record is counting up whenever it sees one. Additional calc records
can be used to get the anomaly rate and raise alarms.
And lastly - with the CA library.
How do I control users - password ect in case of Access Control on IOC's ?

You don't.

There are no passwords in Access Control.

User and Host information is taken from the UID and hostname the client
runs on.

There's a detailed discussion of Access Control in the Application
Developer's Guide. ;-)
Cheers,
Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System