Re: connections, beacons, ...: Only directory and TCP?

[Matthias Clausen <Matthias.Clausen@desy.de>]

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 <jba@aps.anl.gov>
> > Date: June 27, 2005 13:11:00 EDT
> > To: "Ernest L. Williams Jr." <ernesto@ornl.gov>
> > 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: Matthias.Clausen@desy.de                           22607 Hamburg
WWW-MKS2.desy.de                                                 Germany
------------------------------------------------------------------------