Experimental Physics and
Industrial Control System

Matthias Clausen <[email protected]> · Mon, 27 Jun 2005 21:30:09 +0200

Hi,

I like the idea to change the default name resolution to 'a' name

server. LDAP seems to be a real good candidate.

Can't we define a clear interface for the name resolution and leave it

to the local site to use it's favorite candidate?

Of course there should be a default implementation. But a clear

interface would avoid the additional work to change the name service

afterwards.

I could Imagine the following functionalities:

Broadcast/ beacon - implemented (for small sites necessary) but not the

default

Name server - default implementation (i.e.  LDAP)
Name server - open api/interface  for other name services

From the application point of view it should/will be possible to

connect to several naming services and several data services. This way

it will be possible to query for device names from several subsystems -

or even control systems. Browsing through the name space is essential

for future applications. Native naming schemes known from the current

directory server (record on IOC) or even raw IP addresses could be part

of the naming services.

Most importantly the interface to the name service must be open and not

hidden. In terms of eclipse speak it would be an eclipse plugin and not

a hard coded part of the epics channel access library.

-Matthias

Kay-Uwe Kasemir wrote:

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

--
------------------------------------------------------------------------
Matthias Clausen                         Cryogenic Controls Group(MKS-2)
phone:  +49-40-8998-3256                Deutsches Elektronen Synchrotron
fax:    +49-40-8994-3256                                    Notkestr. 85
e-mail: [email protected]                           22607 Hamburg
WWW-MKS2.desy.de                                                 Germany
------------------------------------------------------------------------

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System