EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: caRepeater working practices
From: "Jeff Hill" <[email protected]>
To: "'Simon Rees'" <[email protected]>
Cc: "'EPICS Tech-Talk'" <[email protected]>
Date: Mon, 28 Jun 2004 13:31:54 -0600
Hello Simon,

> Is it considered standard practice to start a caRepeater daemon
> at machine boot time for any machine on which you might want to
> run CA clients ?  (If there are many potential machines this might
> be a bit of a burden to the system administrators).

The CA reference manual provides no advice on which is the best approach
partly because this is a system management issue, and therefore being out of
the direct control of the library designers we expect that many sites will
prefer to decide what to do on their own. Nevertheless, the documentation
should adequately explain the risks present with the two approaches. I just
looked at the CA repeater section of the latest CA reference manual, and it
*does* appear to adequately describe the relevant pitfalls present in EPICS
R3.14. I have extracted that section of the manual for review in case I have
missed something obvious. See attached.

Here is a summary of the two pitfalls I can see related to *not* starting
the ca repeater when the workstation is booted:

1) The repeater must be in the path of the account that starts the first ca
client. If not, this client will not have access to ca repeater
functionality.

2) If the first ca client is an IOC then other ca clients might become
dependent on the ca repeater embedded in the IOC. These clients might
subsequently loose ca repeater functionality if the IOC exits.

3) With older versions of EPICS there was the possibility of a ca client
that could not find the repeater in its path starting the repeater using the
fork system call, but this practice has been abandoned because it could
result in some very confusing issues associated with resource duplication
and process name duplication by the ca repeater process. This problem does
not exist in EPICS R3.14, but it does exist in earlier versions of the
software.

To the best of my knowledge there are not any risks present with the
start-the-ca-repeater-when-the work-station-boots approach other than
perhaps the relevant hassles for your system managers.

PS: When I get some time I plan to look at implementing multicasting
support, and that would hopefully eliminate need for a CA repeater
altogether (in systems configured to use only multicasting).

Jeff

When several client processes run on the same host it is not possible for
all of them to directly receive a copy of the server beacon messages when
the beacon messages are sent to unicast addresses, or when legacy IP kernels
are still in use. To avoid confusion over these restrictions a special UDP
server, the CA Repeater, is automatically spawned by the CA client library
when it is not found to be running. This program listens for server beacons
sent to the UDP port specified in the EPICS_CA_REPEATER_PORT parameter and
fans any beacons received out to any CA client program running on the same
host that have registered themselves with the CA Repeater. If the CA
Repeater is not already running on a workstation, then the "caRepeater"
program must be in your path before using the CA client library for the
first time.If a host based IOC is run on the same workstation with
standalone CA client processes, then it is probably best to start the
caRepeater process when the workstation is booted. Otherwise it is possible
for the standalone CA client processes to become dependent on a CA repeater
started within the confines of the host based IOC. As long as the host based
IOC continues to run there is nothing wrong with this situation, but
problems could arise if this host based IOC process exits before the
standalone client processes which are relying on its CA repeater for
services exit.
Since the repeater is intended to be shared by multiple clients then it
could be argued that it makes less sense to set up a CA repeater that
listens for beacons on only a subset of available network interfaces. In the
worst case situation the client library might see beacon anomalies from
servers that it is not interested in. Modifications to the CA repeater
forcing it to listen only on a subset of network interfaces might be
considered for a future release if there appear to be situations that
require it.

> -----Original Message-----
> From: Simon Rees [mailto:[email protected]]
> Sent: Monday, June 28, 2004 1:00 PM
> Cc: EPICS Tech-Talk
> Subject: caRepeater working practices
> 
> Dear all
> 
> Please excuse the naivety of this question but I am
> just getting to grips with EPICS here at the Isaac Newton
> Group of Telescopes. I have searched through the EPICS
> documentation and so far haven't found any definitive
> pointers.
> 
> Is it considered standard practice to start a caRepeater daemon
> at machine boot time for any machine on which you might want to
> run CA clients ?  (If there are many potential machines this might
> be a bit of a burden to the system administrators).
> 
> Alternatively, do most people just allow the first client
> which runs on the machine after reboot to spawn the caRepeater
> and for all subsequent clients on the same machine to use it ?
> 
> Here at ING we are running with R3.13.1; our clients typically
> run on Solaris 5.9 workstations.
> 
> Many thanks
> 
> Simon Rees
> Isaac Newton Group of Telescopes
> 
> 
> 
> 
> 
> 




Replies:
Re: caRepeater working practices Maren Purves
References:
caRepeater working practices Simon Rees

Navigate by Date:
Prev: caRepeater working practices Simon Rees
Next: Re: caRepeater working practices Billy R. Adams
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: caRepeater working practices Simon Rees
Next: Re: caRepeater working practices Maren Purves
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·