Experimental Physics and
Industrial Control System

To monitor the health and status of these gateways I have what I would
refer to as "reverse gateways" since the gateway statistics can be seen
from only one side. These reverse gateways are specifically set up to
allow only PVs of interest through them as well as having a CA_ADDR_LIST
with only the other machine IPs that contain PVs of interest. All other
PVs are denied through the reverse gateway to avoid loops.

Additionally I have 2 PV gateways running connecting multiple subnets
to the accelerator control subnet. In this case it is up to each CA
client to set the EPICS_CA_ADDR_LIST to point to the gateway that they
want to use.

I know of 1 place where someone is using 2 gateways for all CA clients.
The only thing that I have seen with this is that the client may get a
message about multiple servers with the same name and then default to
only 1 of them. As near as I can tell this works on the premise that
"he who answers first wins". So, in this situation you really don't know
which PVs are going through which gateway without getting a report from
the gateway. Also, I'm not sure what would happen to the client if the
particular gateway serving a PV stops .... would the client be able
to automatically get the PV from the other gateway ?? I'm not sure.

Again we are running about 40 gateways, of these about 22 or so are
forward gateways and the rest are reverse gateways; by the above
definitions. Also, we are running 2 PV nameservers in conjunction with
2 of our gateways; this helps to keep "unknown" PVs from getting through
to the accelerator subnet; like if someone forgot to make a
substitution.

I would be happy to discuss further details about configuration of
gateways but I cannot intelligently comment on the actual code
operation and implementation.

Hope this helps,
Marty

Hello Artem,

As far as I understand gateway does not have any "internal state", which
is needed to be synchronized.

The gateway maintains shadow copies of the PV's that its clients are
watching. These shadow PVs are used to propagate publish and subscribe
semantics through the gateway. As I recall it's a GW configurable option
whether gets are serviced from these cache PVs, or alternatively, if they
are to be forwarded directly to the IOCs.

In principal, the net functional impact from introducing a gateway might
only be some propagation delay between the client and the IOC. There might
also be, only for PVs that change at a very high frequency, an increased
probability for certain transitional subscription updates to be discarded.
All of this depends on how much load the gateway experiences which leads us
to another functional difference of a gateway based EPICS system; the
gateways tends to introduce bottle necks from a loading perspective. Also,
the gateway has a less robust implementation compared the rest of EPICS.
This is maybe in large part due to its being based on the "portable CA
server" which is a less commonly used component of EPICS. Nevertheless, the
gateway is used at many sites in production installations, and the gateway
is being continually refined as fringe problems are identified and fixed.
The mantis bug tracker system on the EPICS home page can be used a general
guide to the stability of the software.

I wonder, what problems could occur if we have multiple CA-servers on the
same network? Are there any CA related problems ?
In our case those CA-servers are gateways with the same configuration.

Of course setting up multiple servers (IOCs) all sharing the same network is
a very normal configuration with EPICS. However, with what I will call
bi-directional gateways, one has to be careful about introducing PV
resolution infinite loops. You might end up with what I will call
bi-directional gateways if you have a gateway granting access into subnet A
from subnet B, and also a gateway granting access into subnet B from subnet
A. In that situation you will need to be very careful to configure the
gateways so that they will ignore name resolution attempts coming from a
gateway going in the opposite direction. Of course, more complex PV
resolution looping situations are possible if there are complex CA gateway
based paths between subnets. Hopefully Ken or Ralph might have included a
brief explanation of how to avoid these situations in the gateway
documentation?

Best Regards,

Jeff

-----Original Message-----
From: Artem Kazakov [mailto:[email protected]]
Sent: Thursday, November 23, 2006 8:56 PM
To: [email protected]
Subject: CA question

Hello Jeff!

Could you please help me understand one particular thing about CA.
Here at KEK we are thinking about implementing redundant gateway.
As far as I understand gateway does not have any "internal state", which
is needed to be synchronized.

I wonder, what problems could occur if we have multiple CA-servers on the
same network? Are there any CA related problems ?
In our case those CA-servers are gateways with the same configuration.

Thanks in advance and regards,
Artem Kazakov.

Replies:

RE: CA gateway question Jeff Hill

References:

RE: CA gateway question Jeff Hill

Navigate by Date:

Prev: RE: CA gateway question Jeff Hill

Next: EDM X-Y graph rescaling Chestnut, Ronald P.

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  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: RE: CA gateway question Jeff Hill

Next: RE: CA gateway question Jeff Hill

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  2018  2019  2020  2021  2022  2023  2024