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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: could it possible to get pv from another subnet? |
From: | HaveF <[email protected]> |
To: | [email protected] |
Cc: | "[email protected]" <[email protected]> |
Date: | Wed, 15 Oct 2014 15:15:24 +0800 |
Hi, Michael,
Thank you for sharing your idea.
When I talk about fragile PC which installs gateway service instead of router(or switch) box,
I thought of redundancy.
If I use router/switch box, I can use the redundancy protocol to double(at least) the confidence
of the subnet’s connection. But when I use a PC, maybe I’ll lost that redundancy?
On Wed, Oct 15, 2014 at 2:54 PM, <[email protected]> wrote:
At Diamond we use numerous CA gateways between a variety of routable and unroutable subnets (primary, secondary, office, multiple beamline networks) and they work very well. They are not 100% reliable and there are frequently issues which arise from the gateway, but it’s still worth the hassle for the clean separation it provides between subnets. Also note that gateways can provide filtering (by regex on PV name) and can provide conditional control (again by regex) over which PVs can be written.
So from a system point of view I see no point in not using the CA gateway.
From: HaveF [mailto:[email protected]]
Sent: 15 October 2014 03:55
To: Hartman, Steven M.
Cc: EPICS Tech Talk
Subject: Re: could it possible to get pv from another subnet?
@Steven Hartman
I just check thegateway
solution. It need PC which has several network interface to handle IOCs
and clients.The image below is a typical connection between 3 private networks:
As we all know, the PC with software is not as reliable as the router box(if I set the
202.201.1.4
to the PC instead of a router).So, I guess, in my/your situation(ex: two private networks), if the gateway service is down, the whole pv under that gateway cannot
be seen in other private network. It seems very fragile. What do you think?
On Wed, Oct 15, 2014 at 9:26 AM, HaveF <[email protected]> wrote:
Thanks for all your comments.
Especially Steven Hartman, I suppose CA gateway is what I’m looking for.
The only reason I use the
camonitor
in other subnet is for simplifying
the question.Thank you all again :-D
On Wed, Oct 15, 2014 at 1:15 AM, Hartman, Steven M. <[email protected]> wrote:
On Oct 14, 2014, at 9:27 AM, Mark S. Engbretson <[email protected]> wrote:
> The network topology is set up so that you *DON"T* normally have any sort of
> interaction between the 2 . . . . so why now do you need interaction between
> the 2? What is so important that the camonitor system has to stay on that
> subnet instead of being put onto the other one?
I agree with Mark that HaveF would receive better responses if the request to tech-talk included a description of what they are trying to accomplish with this particular configuration. But I will jump in with a possible solution.
The network diagram in the initial post looks similar to a setup we have here at SNS. The accelerator controls network is in a private network. The individual beam line controls networks are in their own, separate private networks. On the controls network, there is a CA server (actually, many CA servers) which provides accelerator status PVs (beam energy, current, . . .) which is equivalent to your '192.168.1.200 CAS'. CA clients, equivalent to your '192.168.1.100 camonitor', on the beam line networks would like to be able to monitor some of these PVs.
The solution is a CA gateway on the equivalent of your 202.201.1.4 box which provides read-only access to the accelerator PVs, visible by the beam line clients.
http://www.aps.anl.gov/epics/extensions/gateway/index.php
--
Steven Hartman
[email protected]
--
--
Sincerely,
HaveF
--
--
Sincerely,
HaveF