Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: Questions regarding CA protocol specification and phylosophy
From: Michael Davidsaver <mdavidsaver@gmail.com>
To: Diego Sanz <dshernan80@gmail.com>, Andrew Johnson <anj@aps.anl.gov>
Cc: EPICS Tech Talk <tech-talk@aps.anl.gov>
Date: Wed, 13 Sep 2017 09:48:15 -0500
On 09/13/2017 08:52 AM, Diego Sanz wrote:
> Dear EPICS community, I would like to ask you a set of questions related
> with the same topic, but for not creating different topic threads, I
> think that all of them can be treated in this one.
> 
> Following CA theory on http://www.aps.anl.gov/epics/docs/CAproto.html

FYI, the most recent version of this document is published

http://www.aps.anl.gov/epics/base/R3-16/0-docs/CAproto/index.html

@Andrew, any chance of replacing the older version, or otherwise noting
that it has been superseded?

> and trying to understand how data packages flow between IOCs and EPICS
> clients, I have the following questions.
> 
> Glossary: CA-1: port 5064; CA-2: port 5065
> 
> 
> 1. Theoretically, I can run 2 or more IOCs in the same host for the same
> IP. The first IOC takes CA-1-TCP for PV values data transmission with
> the clients, and the second one must take another port (e.j., 33003) so
> 33003-TCP for the same purpose. Besides both IOCs will be listening on
> the same UDP port CA-1. Now I lunch a #caget PVname where the
> EPICS_CA_ADDR_LIST is the same IP, and it works for one of the IOCs and
> not for the other. I do the same with CSS, and occurs the same... only
> one of the IOC PVs are reachable. Is there any other configuration
> regarding this issue?

The distinction is in the reception handling of UDP broadcast vs.
unicast packets when multiple sockets are bound to the same
interface+port number.  Broadcasts are received by all sockets, while
unicast by only one (which one is OS dependent).


> 2. CA theory says that the repeater process shall manage the
> communication between IOCs and clients (due to the problem of only one
> process can listen by one port on the same host). I suppose that when I
> run camonitor o caget, the caRepeater (that listen by CA-2 UDP port)  is
> in charge of that. Besides, every IOC sends a Beacon message to say to
> the repeater that it is alive. But, all the EPICS clients shall work in
> that way? If I kill caRepeter, and I launch the CSS, there is no process
> on the system listening by CA-2 UDP... this is normal? where is the
> repeater standalon process working? 

CAJ (java client) has it's own caRepeater equivalent (cf.
src/com/cosylab/epics/caj/CARepeater.java)

Also, recent libca, and CAJ, can generally work without receiving
beacons.  A consequence is that clients may take longer to re-connect
after an IOC (re)start.  Beacon "anomalies" (new server or sequence
counter reset) can reset the search interval.

References:
Questions regarding CA protocol specification and phylosophy Diego Sanz

Navigate by Date:
Prev: Re: Questions regarding CA protocol specification and phylosophy Dirk Zimoch
Next: Re: Questions regarding CA protocol specification and phylosophy Diego Sanz
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: Re: Questions regarding CA protocol specification and phylosophy Kasemir, Kay
Next: mbboDirect record and SHFT field Rod Nussbaumer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 14 Sep 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·