Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 1 Oct 2007 15:47:54 -0600

> My current understanding of the way CA clients is the following:
> When a client is started, it attempts to fetch the PV according the
> EPICS_CA_ADDR_LIST (default port if not explicit is
> EPICS_CA_SERVER_PORT)

This also depends on how you set EPICS_CA_AUTO_ADDR_LIST

> 
> If the client still cannot find a PV, it sends another search requests
> to all servers listed in EPICS_CA_ADDR_LIST. It continues doing at
> increasing intervals. At one point it will stop sending search
> requests.

The rate at which name resolution (search) requests are sent exponentially
backs off to a plateau rate. The value of this plateau has an impact on
network traffic because it determines the rate that clients search for
channel names that are miss-spelled or otherwise don't exist in a server.
Furthermore, for clients that are unable to see the beacon from a new
server, the plateau rate may also determine the maximum interval that the
client will wait until discovering a new server.

Starting with EPICS R3.14.7 this maximum search rate interval plateau in
seconds is determined by the EPICS_CA_MAX_SEARCH_PERIOD environment
variable.

> 
> Q: Are search request TCP based?

Negative, UDP based.

> 
> At that point the only thing that can wake it up is a beacon anomaly.

Starting with EPICS R3.14.7 it never stops searching, and the maximum search
rate interval plateau in seconds is determined by the
EPICS_CA_MAX_SEARCH_PERIOD environment variable.

So, starting with EPICS R3.14.7, the beacon anomaly impacts when the search
rate is increased, but it is not required to resume searching.

> 
> Q: Who/what detects beacon anomalies? Is it the caRepeater?
> 
> Beacon are sent by IOC server as soon as they are started.
> Beacon are UDP broadcasted by IOC server from EPICS_CA_SERVER_PORT to
> EPICS_CA_REPEATER_PORT at the frequency given by
> EPICS_CA_BEACON_PERIOD.
> 
> Q: Where are the beacon sent? IP address? Port? transport protocol?
> 
> If caRepeater daemon was spawned on client, it receives the beacons,
> detect a beacon anomaly and inform the registered clients that some new
> PVs are available.

Beacon anomalies are detected by the client library (in the client
application's process). The repeater daemon is just a fan-out engine.

> 
> Q: Is it possible that the caRepeater is not spawn? (for ex if not in
> client application path)

Yes 

> 
> Q: What happens if you have several caRepeater processes running on
> client? Do they maintain the same list of registered client processes?
> On some of my machines, I have several caRepeater processes...

There should be no more than one CA Repeater for any given port that a
repeater is configured to listen to. There can be briefly more than one, but
any subsequent repeaters spawned for a given port discover the redundancy
and exit. The client library is able to see if a repeater is running by
testing to see if the port is in use by a server already.

> 
> Q: How can I list all clients registered with a caRepeater?
> 

You can build the CA repeater to emit debug messages, you can build it debug
and attach to the process with a debugger, but otherwise you cant currently
see the list.

> Q: What if server and client do not have the same
> EPICS_CA_REPEATER_PORT? The beacon should not be sent by the IOC server
> to the right location of the repeater, is this correct?
> ( I think this is the problem I have)

The repeater listens for server beacons on the EPICS_CA_REPEATER_PORT port
it is configured with. It also receives client subscription requests on this
same port. The repeater the client subscribes with must be on the same host
as the client.

The client subscribes with the CA repeater using the EPICS_CA_REPEATER_PORT
it is configured with. 

The server sends beacons to the address list configured by
EPICS_CAS_AUTO_BEACON_ADDR_LIST and EPICS_CAS_BEACON_ADDR_LIST. If ports are
not configured there, then they are specified by EPICS_CAS_BEACON_PORT.

> 
> Q: Should the EPICS_CA_REPEATER_PORT be the same on all IOC servers and
> OPI clients?

It is possible for servers to send beacons to more than one set of
repeaters, but it isn't possible for clients to receive beacons from more
than one repeater (from repeaters on different ports).

> 
> Q: If the client had initially connected but then the IOC server goes
> down, is the procedure the same? When are state of health messages
> sent?

If the client does not see the beacon for EPICS_CA_CONN_TMO then it sends an
are-you-there request over the TCP circuit. If that request times out then
the circuit is marked as unresponsive, and the application's disconnect
handler is called. The client library will not call the application's
connect handler until a subsequent are-you-there request is replied to in a
timely fashion or the circuit disconnects and the channel is reconnected
over a new circuit.

PS: Multicasting is designed to make broadcast based protocols work better
in multi-subnet systems. We should look at adding support for multicasting
in the next release (but probably not in a R3.14 point release). Also,
support for a hierarchical distributed name resolution scheme like DNS would
be a good idea for very large installations.

HTH

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System