Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Wed, 12 Dec 2007 10:43:26 -0700

> 
> 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. ?

One benefit of EPICS environment variables is their ability to make a site
wide default, and to configure the CA aspects of multiple tools with a
common interface - albeit a rather primitive one.

I suppose that one _could_ set them programmatically by calling putenv(),
but most of them _would_ need to be set before initializing the CA context.

CA's configuration was designed a long time ago so perhaps there is now an
open source library for configuration that we should use in the future. We
would of course remain backwards compatible to the past environment variable
based configuration if the new configuration interface isn't used. Perhaps
we should look at the XML related libraries.

> 
> 
> 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 program is based on the part of the CA client library that detects
beacon anomalies. It wouldn't be hard to provide an API where an application
registers to receive callbacks when an IOCs (beacon detected) state of
health changes, but this would arguably be a lower level and somewhat
redundant interface since the application would need to know the IP address
or dns name, and we already provide connectivity callback (verified more
reliably BTW with additional TCP-based polling) configured at a higher level
with channel name.

> 
> It would be nice if the ARRAY_SIZE_LIMIT thing be done differently?
> Maybe removed all-together? Or be implemented in a way that it can be
> easily changed on the fly inside a program - The documentation aint very
> clear if this env-var is read while the program is running or only on
> startup?

Sorry, that subtlety (that it _is_ only read during startup) probably is
somewhat unclear in the doc. Since we use free lists for the memory
management it would of course be difficult to change the carpet out during
the dance.

As mentioned in my talk at the last EPICS meeting, I am planning to fix the
memory management issues so that the array size limit can be eliminated or
at least it can have a very large default. My thoughts on this recently have
been that, at least for the server, an array size limit for incoming
requests should always exist so that a malicious client is prevented from
bringing the IOC to its knees, but hopefully in the future the default limit
can be very high. Another possibility might be supplying that type of limit
from the access control system.

> 
> 
> Then a question:
> Can somebody explain the relationship between.
> ca_flush_io
> ca_poll
> ca_pend_io
> ca_pend_event

My intent was that this is documented in the manual, but I should reread
that section. CA is an asynchronous batch oriented communication system.
This tends to allow for high performance, but its interactions are somewhat
more complex compared to round trip blocking communications interfaces.

In summary, the ca_pend_io function blocks until all ordinary (non-callback)
get requests (issued since the last call to ca_pend_io) complete or its
timeout expires. If, when creating a channel, one does not specify a
connection callback, then ca_pend_io will also block for this type of
channel to connect (if the channel is created after the last call to
ca_pend_io). This is the _only_ purpose of ca_pend_io.

The ca_flush_io function blocks until it finishes forcing all requests in
the output queue to be delivered to the client side input of the TCP
circuit. This is the _only_ purpose of ca_flush_io.

The ca_pend_event function is for use only in non-preemptive mode clients.
Its sole purpose is for periodically processing CA client library background
activities that wouldn't get a chance to run if the single thread of control
does not pass periodically through the CA client library. CA client library
background activities include, but are not limited to, sending search
requests, receiving search responses, receiving beacon messages, receiving
TCP messages, and calling callbacks. The ca_pend_event function waits for a
specified interval. If there is CA related labor to do it will use CPU
otherwise it will sleep for the specified interval. If the interval
parameter is zero it will be taken as a shortcut for an infinite interval.
The ca_poll function calls ca_pend_event with a very short, but not zero,
delay interval.

> And which ones of these I don't have to call in a enabled pre-emptive
> callback environment?

No polling is required if preemptive callback mode is enabled so the
ca_pend_event (and ca_poll) functions aren't useful for that type of client.
The ca_pend_io function is only useful to short lifespan types of clients
and is therefore not particularly useful in preemptive mode clients, and
certainly never useful other than in the main thread (the thread that
created the ca context). The ca_flush_io function will be quite useful in
preemptive mode (serving exactly the same function it serves in the other
mode).

> 
> And lastly - with the CA library.
> How do I control users - password ect in case of Access Control on IOC's ?

For now we trust the client's OS to authenticate the user before we check
his credentials in the access security system. We certainly could look at
stronger authentication based on for example Kerberos in the future.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System