EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: connections, beacons, ...: Only directory and TCP?
From: Kay-Uwe Kasemir <[email protected]>
To: EPICS Core Talk <[email protected]>
Date: Mon, 27 Jun 2005 14:29:33 -0400
Hi:

This is a level down from the API to the actual implementation,
but I think that we should be open to review how CA handles
connections:
Broadcasts to locate PVs,
beacons to monitor established connections and to
spot new servers.

At the SNS, there are ongoing problems with connections not
happening or taking a long time.
My point is that every single issue can be fixed,
but I think we're trying to be overly sophisticated
without real benefit.
Yes, it works great in most cases, by when it doesn't,
it's very hard to figure out what's wrong.

How about using a directory and then only TCP connections
with idle-messages to monitor the connection state?
- need to run a directory server
- directory server is bottleneck
+ a directory based on an existing protocol like LDAP
  can be populated and queried with several methods.
  You know what's in the directory, you get reproduceable answers.
+ there can be redundant LDAP directory servers
+ one can use ssh tunnels for the TCP connections
+ better debug messages are possible: "cannot access directory LDAP:123.0.0.1", "cannot access 'fred' on CAS 123.0.0.2:5001 where directory LDAP:123.0.0.1 reported it".

Thanks,
Kay

Begin forwarded message:
From: Janet Anderson <[email protected]>
Date: June 27, 2005 13:11:00 EDT
To: "Ernest L. Williams Jr." <[email protected]>
Subject: Re: How to inspect the nameserver's hash table?


Hi Ernest,

I am in the process of adding code to the nameserver to handle
CA gateways differently than regular iocs. Each pv from a CA
gateway has to be monitored separately because each pv can
connect/disconnect independently. I recently created a new
monitorAll variable to force the nameserver to monitor all
learned pvs (in main.cc around line 180) but this variable is
temporary until I am able to add some input data to identify
gateways.  We do not use the learn mode except for gateways
so I have hard coded  monitorAll to true (1).  In your case
when you want to learn about all iocs you will need to set
monitorAll to false (0) and recompile. Sorry about this but
code changes for the separate handling of gateways is not
fully implemented yet.

Janet


Replies:
Re: connections, beacons, ...: Only directory and TCP? Matthias Clausen

Navigate by Date:
Prev: Re: V4 design issue: Should primitive data types have well defined precisions? Marty Kraimer
Next: Re: dataAccess V4 Ca client propertyId questions Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: dataAccess V4 Ca client propertyId questions Ralph Lange
Next: Re: connections, beacons, ...: Only directory and TCP? Matthias Clausen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·