Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · Tue, 02 Oct 2007 08:55:43 -0700

On Mon, 2007-10-01 at 15:47 -0600, Jeff Hill wrote:
> > 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.

Also, note that there is a Channel Access Name Server and it works well.
Ask Janet Anderson for details.

> 
> HTH
> 
> Jeff
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System