https://wiki-ext.aps.anl.gov/epics/api.php?action=feedcontributions&feedformat=atom&user=JeffHillEPICSWIKI - User contributions [en]2026-07-14T11:01:41ZUser contributionsMediaWiki 1.36.1https://wiki-ext.aps.anl.gov/epics/index.php?title=V4_CA_Interfaces&diff=2708V4 CA Interfaces2005-07-07T23:16:35Z<p>JeffHill: /* Channel */</p>
<hr />
<div>= CA Preliminary 2nd Generation Interfaces =<br />
<br />
== C++ Namespace ==<br />
<br />
All of the following will be in namespace ??????<br />
<br />
== Exceptions ==<br />
<br />
The following base class will be used for all exceptions thrown by the library and or passed to exception callbacks to communicate asynchronous failure. The c++ <code>dynamic_cast</code>will be used to test for a particular, concrete condition.<br />
<br />
class diagnostic : public std::exception {<br />
public: <br />
enum severity_t { <br />
sevWarning, sevError, sevFatal };<br />
virtual severity_t severity () const = 0;<br />
virtual context ( stringSegment & ) const = 0;<br />
};<br />
<br />
== Event Specifications ==<br />
<br />
This interface will be used to specify a set of events.<br />
<br />
class eventSpec {<br />
public:<br />
virtual bool operator == ( <br />
epicsGuard &, const eventSpec & ) const = 0; <br />
virtual bool compare ( <br />
epicsGuard &, <br />
const eventSpec & comparand, <br />
const eventSpec & select ) const = 0; <br />
virtual bool isEmpty ( <br />
epicsGuard & ) const = 0;<br />
virtual void show ( <br />
epicsGuard &, unsigned level ) const = 0; <br />
virtual void include (<br />
epicsGuard &, const eventSpec & ) = 0; <br />
virtual void exclude ( <br />
epicsGuard &, const eventSpec & ) = 0; <br />
virtual void excludeAll ( <br />
epicsGuard & ) = 0;<br />
};<br />
<br />
== Subscription Event Specification ==<br />
<br />
This interface is used to specify what events will and will not be present if a subscription update is triggered.<br />
<br />
It is hoped that one subscription specification might be shared by several subscriptions in the server.<br />
<br />
class subscrEventSpec {<br />
public: <br />
// subscrSpec is by default is a dont care w.r.t<br />
// the eventSpec space<br />
virtual void require ( <br />
epicsGuard &, const eventSpec & ) = 0;<br />
virtual void prohibit ( <br />
epicsGuard &, const eventSpec & ) = 0;<br />
virtual bool isMatch ( <br />
epicsGuard &, const eventSpec & ) const = 0;<br />
virtual void show ( <br />
epicsGuard &, unsigned level ) const = 0;<br />
};<br />
<br />
== Subscription Filter Specification ==<br />
<br />
It is hoped that one subscription filter might be shared by several subscriptions installed into a service.<br />
<br />
Should (can) a subscription spec be a property catalog?<br />
<br />
class subscrFilterSpec {<br />
public:<br />
// updates no less frequently than specified<br />
virtual void setPeriodMinimum (<br />
epicsGuard &, double periodInSeconds ) = 0;<br />
// updates no more frequently than specified<br />
virtual void setPeriodMaximum (<br />
epicsGuard &, double periodInSeconds ) = 0;<br />
// delta between updates no less than specified<br />
virtual void setPercentChangeMinimum ( <br />
epicsGuard &, double percentChange ) = 0;<br />
// delta between updates no more than specified <br />
virtual void setPercentChangeMaximum ( <br />
epicsGuard &, double percentChange ) = 0;<br />
// when data acquisition system can pluck data at an offset<br />
virtual void setTriggerTimeOffset ( <br />
epicsGuard &, double delayInSeconds ) = 0;<br />
// number of intermediate values saved when busy<br />
// before replacing last entry on queue<br />
virtual void setEventQueueLength ( <br />
epicsGuard &, unsigned length ) = 0;<br />
// when supported by data store, specify<br />
// retrieval of values from the past<br />
virtual void setTimeWindow ( <br />
epicsGuard &, epicsTime & begin, epicsTime & end ) = 0;<br />
};<br />
<br />
== Write Request ==<br />
<br />
class writeCompletionNotify { <br />
public:<br />
virtual void success ( <br />
epicsGuard & ) = 0; <br />
virtual void exception ( <br />
epicsGuard &, const diagnostic & ) = 0;<br />
};<br />
<br />
class writeRequest {<br />
public:<br />
virtual void write ( <br />
epicsGuard &, const propertyCatalog & ) = 0;<br />
virtual void write ( <br />
epicsGuard &, const propertyCatalog &, <br />
writeCompletionNotify & ) = 0;<br />
virtual void cancel ( <br />
epicsGuard & ) = 0;<br />
virtual void show ( <br />
epicsGuard &, unsigned level ) const = 0;<br />
};<br />
<br />
== Read Request ==<br />
<br />
class readCompletionNotify {<br />
public:<br />
virtual void success ( <br />
epicsGuard &, const propertyCatalog & ) = 0;<br />
virtual void exception (<br />
epicsGuard &, const diagnostic & ) = 0;<br />
};<br />
<br />
class readRequest {<br />
public:<br />
virtual void read (<br />
epicsGuard &, readCompletionNotify & ) = 0;<br />
virtual void cancel (<br />
epicsGuard & ) = 0;<br />
virtual void show (<br />
epicsGuard &, unsigned level ) const = 0;<br />
};<br />
<br />
== Subscription Request ==<br />
<br />
class subscriptionUpdateNotify {<br />
public:<br />
virtual void update (<br />
epicsGuard &, const eventSpec &, <br />
const propertyCatalog & ) = 0; <br />
virtual void exception (<br />
epicsGuard &, const diagnostic & ) = 0;<br />
};<br />
<br />
class subscriptionRequest {<br />
virtual void subscribe ( <br />
epicsGuard &, subscriptionUpdateNotify & ) = 0;<br />
virtual void cancel ( <br />
epicsGuard & ) = 0;<br />
virtual void show ( <br />
epicsGuard &, unsigned level ) const = 0;<br />
};<br />
<br />
== Channel ==<br />
<br />
The old interface assumed that when a channel is deleted then all related IO is also deleted. This requires an IO list in every channelwith attendent potential for redundant overhead. As a baseline, I intend to eliminate this practice, and therefore, a channel reference is not passed to the IO completion callback.<br />
<br />
Users can subscribe for many different types of properties and events and therefore there might no longer be any need for native type/count returning functions in channel ( they can subscribe for "dimension", "bounds", "valueBehavior", "readAccess", "writeAccess", "confirmationRequested" properties ). This is also related to connect / disconnect notify callbacks specified when creating channel(they can subscribe for "state" property).<br />
<br />
// I am actively considering abandoning this in favor of allowing <br />
// them to subscribe when the channel is created.<br />
class channelStateNotify {<br />
public:<br />
virtual void connectNotify () = 0;<br />
virtual void responsiveNotify () = 0;<br />
virtual void unresponsiveNotify () = 0;<br />
virtual void disconnectNotify () = 0;<br />
};<br />
<br />
class channel {<br />
public:<br />
typedef unsigned priLevel_t;<br />
static const priLevel_t priorityMax;<br />
static const priLevel_t priorityMin;<br />
<br />
virtual writeRequest & createWriteRequest (<br />
epicsGuard &, <br />
const propertyCatalogRegistration & ) = 0;<br />
virtual void destroyWriteRequest (<br />
epicsGuard &, writeRequest & ) = 0;<br />
virtual readRequest & createReadRequest (<br />
epicsGuard &, const propertyCatalogRegistration & ) = 0;<br />
// receive property description list, but not all<br />
// property values (avoid large arrays)? Does this identify a<br />
// interface defect in data access<br />
// does an array of property id's need to be passed here so that <br />
// they can specify a starting point in the hierarchy?<br />
virtual readRequest & createAllPropertiesReadRequest (<br />
epicsGuard & ) = 0;<br />
virtual void destroyReadRequest <br />
epicsGuard &, readRequest & ) = 0;<br />
virtual subscriptionRequest & createSubscriptionRequest (<br />
epicsGuard &, const propertyCatalogRegistration & ) = 0;<br />
virtual void destroySubscriptionRequest (<br />
epicsGuard &, subscriptionRequest & ) = 0;<br />
virtual void name (<br />
epicsGuard &, stringSegment & ) const = 0;<br />
virtual void show (<br />
epicsGuard &, unsigned level ) const = 0;<br />
virtual bool isConnected (<br />
epicsGuard & ) const = 0;<br />
virtual unsigned serviceName (<br />
epicsGuard &, stringSegment & ) const () = 0;<br />
virtual void flush (<br />
epicsGuard & ) = 0;<br />
// exceptions<br />
class badType : public diagnostic {};<br />
class propertyValueOutOfBounds {} : public diagnostic {};<br />
class invalidEventSelection {} : public diagnostic {};<br />
class noWriteAccess {} : public diagnostic {}; <br />
class noReadAccess {} : public diagnostic {};<br />
class unsupportedByService {} : public diagnostic {};<br />
class requestTimedOut {} : public diagnostic {};<br />
class unresponsive {} : public diagnostic {};<br />
class disconnect {} : public diagnostic {};<br />
}<br />
<br />
== Channel Factory ==<br />
<br />
class channelFactory {<br />
virtual cacChannel & createChannel (<br />
epicsGuard &, const stringSegment & name, channelStateNotify &,<br />
cacChannel::priLevel_t = cacChannel::priorityMin ) = 0;<br />
virtual cacChannel & destroyChannel (<br />
epicsGuard &, cacChannel & ) = 0;<br />
// exceptions<br />
class priorityOutOfBounds {} : public diagnostic {};<br />
};<br />
<br />
== Event Specification Factory ==<br />
<br />
class eventSpecFactory {<br />
virtual eventSpec & createEventSpec (<br />
epicsGuard &, const stringSegment & eventName ) = 0;<br />
virtual eventSpec & createChannelTriggeredEventSpec (<br />
epicsGuard &, const stringSegment & triggerExpression ) = 0;<br />
virtual void destroyEventSpec (<br />
epicsGuard &, eventSpec & ) = 0;<br />
};<br />
<br />
class subscrSpecFactory { <br />
virtual subscrFilterSpec & createSubscrFilterSpec ( <br />
epicsGuard & ) = 0;<br />
virtual void destroySubscrFilterSpec (<br />
epicsGuard &, subscrFilterSpec & ) = 0;<br />
virtual subscrEventSpec & createSubscrEventSpec ( <br />
epicsGuard & ) = 0;<br />
virtual void destroySubscrEventSpec (<br />
epicsGuard &, subscrEventSpec & ) = 0;<br />
};<br />
<br />
== Property Catalog Registration ==<br />
<br />
class propertyCatalogRegistration;<br />
<br />
Perhaps its a defect that to register a data structure with a large array we must present a propertyCatalog which has reserved that much space, and therefore should a <code>propertyCatalog</code> have a "traverseStructure()" interface ?<br />
<br />
class propertyCatalogRegistry {<br />
virtual class propertyCatalogRegistration & createRegistration (<br />
epicsGuard &, const propertyCatalog & ) = 0;<br />
virtual void destroyRegistration ( <br />
epicsGuard &, propertyCatalogRegistration & ) = 0; <br />
};<br />
<br />
== Name Service Interface ==<br />
<br />
A name service might also have subscription capabilities?<br />
<br />
How does a name service differ from an ordinary service where each channel has an address property, and subordinate properties conveying the various different address formats? How do we accomodate a failover service address. Is this a subordinate property?<br />
<br />
class nameLookupNotify {<br />
virtual void success (<br />
epicsGuard &, const propertyCatalog & address,<br />
const stringSegment & match, bool last ) = 0;<br />
virtual void exception (<br />
epicsGuard &, const diagnostic & ) = 0;<br />
};<br />
<br />
class nameLookupRequest {<br />
virtual void lookup (<br />
epicsGuard &, const stringSegment & name,<br />
const nameLookupNotify & ) = 0;<br />
virtual void cancel (<br />
epicsGuard & ) = 0;<br />
virtual void show (<br />
epicsGuard &, unsigned level ) const;<br />
};<br />
<br />
class nameService {<br />
virtual nameLookupRequest & createNameLookupRequest (<br />
epicsGuard & ) = 0;<br />
// not supported by all name services?<br />
virtual nameLookupRequest & <br />
createRegularExpressionNameLookupRequest ( <br />
epicsGuard & ) = 0;<br />
virtual void destroyNameLookupRequest (<br />
epicsGuard &, nameRequest & ) = 0;<br />
};<br />
<br />
== Client Context ==<br />
<br />
The name "clientContext" should possibly be changed.<br />
<br />
class clientContext :<br />
public eventSpecFactory,<br />
public subscrSpecFactory,<br />
public propertyCatalogRegistry {<br />
};<br />
<br />
== Service ==<br />
<br />
A service might failover to a backup service, but currently there appears to be no need to reveal this in public interfaces?<br />
<br />
The relation between a name service, channelFactory, service, and genericService to each other are areas which are under active consideration.<br />
<br />
class service : <br />
public channelFactory, <br />
public nameService { <br />
virtual void flush ( <br />
epicsGuard & ) = 0; <br />
virtual void show ( <br />
epicsGuard &, unsigned level ) const = 0; <br />
// exceptions<br />
class disconnect {} : public diagnostic {}; <br />
};<br />
<br />
= Server =<br />
<br />
This interface is passed to the service factory.<br />
<br />
class server : <br />
public eventSpecFactory {<br />
public:<br />
virtual void serviceExceptionNotify (<br />
epicsGuard &, diagnostic & ) = 0;<br />
// for attaching thread private variables<br />
// in preparation for asynchronous callback<br />
// from a service thread<br />
virtual void serviceThreadInitiateNotify (<br />
epicsGuard & ) = 0;<br />
virtual void serviceThreadExitNotify (<br />
epicsGuard & ) = 0;<br />
// for implementing non-preemptive callback<br />
// **** probably not needed if guard is based on a pure virtual mutex interface<br />
// **** and given that they can use thread private variables<br />
//virtual void serviceCallbackProcessingInitiateNotify (<br />
// epicsGuard & ) = 0;<br />
//virtual void serviceCallbackProcessingCompleteNotify (<br />
// epicsGuard & ) = 0;<br />
};<br />
<br />
== Generic Service ==<br />
<br />
A <code>genericService</code> is a special service granting homogenous access to multiple underlying services of different types. When an application creates a channel they might not need to know what service is the factory for the channel. Likewise, when they delete a channel they would not need to remember that the channel is recycled with the same service that created it. A <code>genericService</code> will attempt to initially locate the appropriate service, and should a connected service disconnect, attempt to transparently find a new one. A <code>genericService</code> might hide the need to recreate a channel or an IO request when a service disconnects from client applications. This would be accomplished by creating a channel that is a handle to a service specific channel, and an IO request that is a handle to a service specific IO request.<br />
<br />
class genericServiceFactory {<br />
public:<br />
virtual service & createGenericService (<br />
epicsGuard &, epicsMutex &,<br />
serviceStateChangeNotify &,<br />
serviceLocator & ) = 0;<br />
virtual void destroyGenericService (<br />
epicsGuard &, service & ) = 0;<br />
};<br />
<br />
== Network Server/Service Interfaces ==<br />
<br />
These interfaces may be accessed with the <code>dynamic_cast</code> operator<br />
<br />
class beaconGenerator {<br />
public:<br />
virtual void generateBeaconAnomaly (<br />
epicsGuard & ) = 0;<br />
};<br />
<br />
class beaconAnomalyDetectorStateChangeNotify {<br />
public:<br />
virtual unsigned beaconAnomalyDetectNotify (<br />
epicsGuard &, const propertyCatalog & ) const = 0;<br />
};<br />
<br />
// only access to this will be using dynamic_cast<br />
class networkChannelDiagnostics {<br />
virtual unsigned searchAttempts (<br />
epicsGuard & ) const = 0;<br />
};<br />
<br />
// only access to this will be using dynamic_cast<br />
class networkCircuitDiagnostics {<br />
virtual double estimatedBeaconPeriod (<br />
epicsGuard & ) const; <br />
// negative DBL_MAX if UKN<br />
virtual double receiveWatchdogDelayToExperation (<br />
epicsGuard & ) const; <br />
// negative DBL_MAX if UKN<br />
virtual unsigned protocolRevision (<br />
epicsGuard & ) const;<br />
};<br />
<br />
// only access to this will be using dynamic_cast<br />
class serviceDiagnostics {<br />
public:<br />
epicsShareFunc unsigned subscriptionEventsPosted () const;<br />
epicsShareFunc unsigned subscriptionEventsProcessed () const;<br />
};<br />
<br />
// only access to this will be using dynamic_cast<br />
class beaconAnomalyDetectorDiagnostics {<br />
public:<br />
virtual unsigned beaconAnomaliesDetected (<br />
epicsGuard & ) const = 0;<br />
};<br />
<br />
== Oustanding Issues ==<br />
<br />
Locking issues. To what degree are we forcing everything to use the same lock? What will be the minimal locking granularity?<br />
<br />
How much of the class name should be in the pure virtual function name for uniqueness?<br />
<br />
Unification with the PCAS interface requires more work. In particulant posting and event registration.<br />
<br />
What type of string interface will be used, and how will this be unified with the database?</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=V4_Name_Server&diff=358V4 Name Server2005-07-06T21:34:31Z<p>JeffHill: /* JOH: For comparison purposes, here is the performance of CA's built-in name resolution. */</p>
<hr />
<div>== Directory Server ==<br />
<br />
EPICS ChannelAccess currently uses a broadcast mechanism for resolving<br />
channel names.<br />
Advantages:<br />
* Minimal if not zero initial setup.<br />
* At least initially very fast, because a client can send multiple name requests in one network packet, all servers receive it simultaneously and can answer to known names.<br />
<br />
Disadvantages:<br />
* Unclear how to extend this service to redundant servers, archived data, ...<br />
* Currently, no wildcard searches.<br />
* Currently, no statistics on available number of channels, types of records, ...<br />
* Bigger installations run into problems with broadcast traffic:<br />
** All devices see the requests, even though only one server has a given channel name.<br />
** Continued searches for unresolved names to overcome UDP limitations.<br />
<br />
As Larry Hoff pointed out, we really want a ''Directory'' server for<br />
EPICS, something beyond a name server. A directory will not only map PV<br />
names to IP addresses of ChannelAccess servers, but also support<br />
* wildcard searches, reports on number of channels per IOC etc.<br />
* redundant servers<br />
* info about reduntant IOCs with the same PV, archived data for a PV<br />
* backup/restore locations for a PV<br />
* PV meta information like engineer-in-charge, CA security rules, ...<br />
<br />
== Channels, Records, PVs, Properties ==<br />
We currently have records with fields and channels with properties.<br />
Each field of a record can become a channel name,<br />
the field itself ends up in the 'value' property of the channel,<br />
and the record decides how to fill the remaining properties.<br />
<br />
Will the directory list all record names or all possible channels?<br />
I think only record names.<br />
<br />
Will it include the record type? Not enough information if we add user-defined fields.<br />
Will it lists all fields of a record?<br />
<br />
I think for now that only listing record names is enough in order to allow<br />
connections.<br />
<br />
The CA client would then have to query the CA server for all the available properties<br />
of a PV, and note that properties might even change at runtime when we allow<br />
online add & delete.<br />
<br />
Whenever a tool like a command-line 'caget' or the 'probe' GUI requires a PV name,<br />
it needs to be decided what properties "fred" would access. In the past, it was equal<br />
to "fred.VAL". There is much more detail in the 'view' section of the<br />
[[V4 DBD Statement Syntax]].<br />
<br />
== LDAP, Directory, RDB, Schema, Entries, dn, cn, dc, ... ==<br />
<br />
The ''Lightweight Directory Access Protocol'' (LDAP) is a network protocol.<br />
It defines how to access data over the network, regardless of language<br />
or underlying data storage. In contrast, RDBs like Oracle or MySQL define the<br />
data storage and SQL dialect, while the network access to the data is then<br />
added almost as an afterthought.<br />
<br />
LDAP is meant as a Directory for simple attribute-based information<br />
for fast, high volume lookup. Simple search filters are supported:<br />
Patterns, "and", "or". In contrast to RDBs, there is no support for<br />
arbitrary relations between entries, there are no transactions nor rollback.<br />
<br />
There are open-source servers for LDAP, and client libraries for<br />
C, Perl, Java and other languages. MacOSX, Linux, Windows 2000<br />
already include LDAP clients. MS ActiveDirectory uses LDAP.<br />
<br />
LDAP requires the data to be organized into hierarchical ''Entries''.<br />
Each Entry has a globally unique ''Distinguished Name'' (dn),<br />
and various ''Attributes'', that is Type/Value pairs.<br />
The ''Schema'' defines which attributes an entry must have and which ones<br />
it might have. There are existing schemas for DNS-type data or personell<br />
information, including types like ''Common Name'' (cn) or ''Domain Component'' (dc),<br />
but one can add custom schemata. Values might include binary data, e.g. images.<br />
<br />
=== Mapping EPICS PV Information to LDAP ===<br />
<br />
Each LDAP entry must have a unique name (dn). EPICS PVs must be unique as well,<br />
but only within the search domain currently defined by the EPICS_CA_ADDR_LIST.<br />
It might make sense to synchronize LDAP servers across these boundaries,<br />
in which case the LDAP dn will have to include more than just the PV name.<br />
For example, one could have a PV "fred" in both the accelerator and office network<br />
of the SNS, and enter them into an SNS-wide LDAP directory like this:<br />
<br />
fred.linac.sns.epics: cas="linacioc1:5065"<br />
fred.office.sns.epics: cas="testioc47.sns.ornl.gov:7987", description="Fred's test PV"<br />
<br />
In this example, the directory includes the ChannelAccess server for both PVs,<br />
and in one case also a description.<br />
<br />
While an EPICS-specific tool might present the data as shown above,<br />
most generic LDAP tools and APIs use the ''LDAP Data Interchange Format'' (LDIF).<br />
In LDIF, part of the above data could look like this:<br />
<br />
dn: dc=epics<br />
objectclass: dcObject<br />
objectclass: organization<br />
o: Root of all EPICS PVs<br />
dc: epics<br />
<br />
dn: dc=sns,dc=epics<br />
# Details omitted; similar to previous entry<br />
<br />
dn: dc=linac,dc=sns,dc=epics<br />
objectclass: dcObject<br />
objectclass: organization<br />
o: Root of all EPICS PVs in the SNS Linac<br />
dc: linac<br />
<br />
dn: cn=fred,dc=linac,dc=sns,dc=epics<br />
objectclass: ProcessVariable<br />
cn: fred<br />
cas: linacioc1:5065 <br />
<br />
Some points I had to learn:<br />
* Each entry has an objectclass. The schema for "ProcessVariable" would for example require a "cn" attribute, with optional "cas", "description" and maybe other attributes.<br>The schema would also determine if searches for PV names are case-sensitive or not.<br />
* The hierarchical path "fred.linac.sns.epics" translates into a dn "cn=fred,dc=linac,dc=sns,dc=epics" which lists the relative dn of the entry itself and all path elements.<br />
* Each path element must exists, so to bootstrap one has to create entries "dc=epics" and "dc=sns,dc=epics" etc., for which I used the pre-defined "organization" schema.<br />
* To locate the PV 'fred', any of the following LDAP searches would work:<br />
** Scope "base" with base "cn=fred,dc=linac,dc=sns,dc=epics".<br />
** Scope "one" with base "dc=linac,dc=sns,dc=epics" and filter "(cn=fred)".<br />
** Scope "one" with base "dc=linac,dc=sns,dc=epics" and filter "(cn=f*d)",<br>though this might return more records which happen to match the pattern.<br />
** Scope "sub" with base "dc=sns,dc=epics" and filter "(cn=fred)",<br>which would also return an entry with dn "cn=fred,dc=office,dc=sns,dc=epics".<br />
** There is a filter option "~=" for 'approximately equal'. Unclear what exactly defines approximate, but this might be very handy for detecing typos.<br />
<br />
=== OpenLDAP ===<br />
<br />
OpenLDAP [http://www.openldap.org] is an open-source LDAP<br />
client library for C and an LDAP server which can store the<br />
actual data in /dev/null, a BerkeleyDB, SQL, Perl, a remote LDAP server.<br />
<br />
OpenLDAP includes authentication and encrypted (SSL) transport,<br />
replication (single master -> multiple slaves),<br />
and referrals from one server to another one which has more details.<br />
<br />
=== EPICS PV Tests ===<br />
<br />
Using OpenLDAP-stable-20050429 and perl-ldap-0.3202 on a 1.3 GHz PowerBook G4<br />
with 780 MB RAM under MacOS X 10.3.8, I used a perl script to create<br />
PV entries, search them, and remove them.<br />
In addition, the 'ldapsearch' that comes with RedHat Enterprise AS 3 was<br />
used to check remote accessibillity.<br />
<br />
When trying to list all PVs with an appropriate search pattern,<br />
the default server configuration limits the response to 500 answers.<br />
This was changed such that 'paged' searches which keep requesting data<br />
in increments of e.g. 500 entries are allowed to continue until all data is retrieved.<br />
From the command-line tool, that's done like this:<br />
ldapsearch -x -LLL -E pr=10/noprompt -b 'dc=epics' '(cn=testpv*)' cas<br />
<br />
== Performance ==<br />
<br />
Based on the default OpenLDAP server config with an additional<br />
index "cn pres,eq" on the common name of the PVs,<br />
PVs with names 'testrec0000000001', 'testrec0000000002' etc.<br />
were added, then looked up one-by-one via their exact name,<br />
and finially deleted one by one.<br />
<br />
When using a C++ test client based on the OpenLDAP library,<br />
the results for smaller numbers are:<br />
Add 10000 records : 22.76 secs<br />
Locate 10000 records : 6.49 secs<br />
Delete 10000 records : 22.20 secs<br />
<br />
In another test, a very rough estimated PV count of the SNS linac<br />
was used:<br />
Add 200000 records : 675.89 secs (38.74 CPU)<br />
Locate 200000 records : 142.85 secs (27.91 CPU)<br />
Delete 200000 records : 807.28 secs (37.28 CPU)<br />
<br />
Those 200000 records use about 900MB of file space.<br />
The results indicate that one can add 300 .. 440 records/sec,<br />
locate 1400.. 1540 records/sec and delete 250..450 records/sec.<br />
Without an index, the addition and deletion will be faster<br />
at the expense of lookup times.<br />
<br />
A typical SNS LLRF IOCs has 2300 records.<br />
On startup, sending those to the directory server would take around 7 seconds.<br />
A typical SNS LLRF overview screen has about 400 PVs,<br />
and current connection times vary from less than a second to<br />
several tens of seconds, depending on how well the search requests<br />
reach the IOCs.<br />
Resolving their CA servers would take about 0.3 seconds with LDAP,<br />
which would then be followed by the time required to actually connect<br />
to those servers.<br />
<br />
In previous test using perl, the individual PV search actually used an LDIF<br />
filter with exact match like 'testrec0000000001'. In addition, all PVs matching<br />
a filter 'testrec*' were retrieved, and no index was used:<br />
Adding 1000 records: 4 wallclock secs ( 2.29 usr + 0.14 sys = 2.43 CPU)<br />
Locating 1000 records: 49 wallclock secs ( 4.10 usr + 0.21 sys = 4.31 CPU)<br />
Match all 1000: 1 wallclock secs ( 1.18 usr + 0.02 sys = 1.20 CPU)<br />
Delete 1000 records: 4 wallclock secs ( 1.35 usr + 0.14 sys = 1.49 CPU)<br />
<br />
When locating individual records via the complete LDIF base without a filter,<br />
the search is much faster:<br />
Locating 1000 records: 5 wallclock secs ( 3.20 usr + 0.18 sys = 3.38 CPU)<br />
<br />
When adding an "index cn pres,eq" to the server config, the results are the<br />
same for both the filter and the base search case.<br />
No difference observed when tripling the cachesize from the default of 1000.<br />
The behavior scales linearly with the number of channels,<br />
always a little over 200 additions or lookups per second:<br />
Adding 10000 records: 47 wallclock secs (21.72 usr + 1.28 sys = 23.00 CPU)<br />
Locating 10000 records: 44 wallclock secs (32.20 usr + 1.55 sys = 33.75 CPU)<br />
Match all 10000: 15 wallclock secs (12.15 usr + 0.64 sys = 12.79 CPU)<br />
Delete 10000 records: 38 wallclock secs (15.41 usr + 1.16 sys = 16.57 CPU)<br />
<br />
Adding 50000 records: 243 wallclock secs (110.36 usr + 7.18 sys = 117.54 CPU)<br />
Locating 50000 records: 226 wallclock secs (164.97 usr + 7.67 sys = 172.64 CPU)<br />
Match all 50000: 80 wallclock secs (63.09 usr + 3.42 sys = 66.51 CPU)<br />
Delete 50000 records: 219 wallclock secs (82.11 usr + 6.61 sys = 88.72 CPU)<br />
<br />
Adding 200000 records: 1293 wallclock secs (483.65 usr + 33.20 sys = 516.85 CPU)<br />
<br />
"index cn,dc pres,eq,approx,sub" takes longer to insert/delete<br />
without improved search performance:<br />
Adding 10000 records: 104 wallclock secs (26.25 usr + 1.67 sys = 27.92 CPU)<br />
Locating 10000 records: 45 wallclock secs (32.86 usr + 1.55 sys = 34.41 CPU)<br />
Match all 10000: 15 wallclock secs (12.31 usr + 0.47 sys = 12.78 CPU)<br />
Delete 10000 records: 97 wallclock secs (17.89 usr + 1.34 sys = 19.23 CPU)<br />
<br />
The CPU load is a rough 50/50 split between the perl and slapd processes.<br />
The perl ldap library is 100% perl, including the network handling and<br />
quite some data conversions from arrays into hashes and back,<br />
so a pure C client might be a little faster.<br />
<br />
Though an index slows down the insertion of PVs, it speeds up certain<br />
retrieval methods, as probably desired for an EPICS directory server.<br />
The search mechanism is based on round-trip requests.<br />
Searching PVs one PV name at a time is slower than requesting all<br />
PVs that match a pattern. Unfortunately, typical CA clients will<br />
have to request data for specific PV names, not by pattern.<br />
<br />
==== JOH: For comparison purposes, here is the performance of CA's built-in name resolution. ====<br />
<br />
Testing with 100000 channels named joh:bill<br />
channel connect test<br />
Elapsed Per Item = 0.00001683 sec, 59427.3 Items per sec, 31.4 Mbps<br />
Search tries per chan - mean=1.000930 std dev=0.030482 min=1.000000 max=2.000000<br />
<br />
=== To be investigated ===<br />
<br />
* How to access it from vxWorks<br />
* How does an LDAP server used for EPICS cooperate with existing LDAP servers for DNS, email etc. Should it be one and the same? Use special port numbers for 'EPICS' LDAP?<br />
* API: What type of API would EPICS tools use? Whatever LDAP library they use? An 'EPICS wrapper' around LDAP? Gasper suggested to look at the Java JNDI API for inspiration.<br />
* Common Database headaches:<br />
** To simply get a PV into LDAP, one has to check if this PV already exists and then either 'add' or 'modify'.<br />
** What if a channel is no longer available? An IOC shutting down could remove PVs from the LDAP server, but an IOC that crashes won't.<br />
* Replication: How to use it, how fast is it etc.<br />
* Authentication and encryption: How hard is it to configure?</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=V4_Name_Server&diff=355V4 Name Server2005-07-06T20:12:10Z<p>JeffHill: </p>
<hr />
<div>== Directory Server ==<br />
<br />
EPICS ChannelAccess currently uses a broadcast mechanism for resolving<br />
channel names.<br />
Advantages:<br />
* Minimal if not zero initial setup.<br />
* At least initially very fast, because a client can send multiple name requests in one network packet, all servers receive it simultaneously and can answer to known names.<br />
<br />
Disadvantages:<br />
* Unclear how to extend this service to redundant servers, archived data, ...<br />
* Currently, no wildcard searches.<br />
* Currently, no statistics on available number of channels, types of records, ...<br />
* Bigger installations run into problems with broadcast traffic:<br />
** All devices see the requests, even though only one server has a given channel name.<br />
** Continued searches for unresolved names to overcome UDP limitations.<br />
<br />
As Larry Hoff pointed out, we really want a ''Directory'' server for<br />
EPICS, something beyond a name server. A directory will not only map PV<br />
names to IP addresses of ChannelAccess servers, but also support<br />
* wildcard searches, reports on number of channels per IOC etc.<br />
* redundant servers<br />
* info about reduntant IOCs with the same PV, archived data for a PV<br />
* backup/restore locations for a PV<br />
* PV meta information like engineer-in-charge, CA security rules, ...<br />
<br />
== Channels, Records, PVs, Properties ==<br />
We currently have records with fields and channels with properties.<br />
Each field of a record can become a channel name,<br />
the field itself ends up in the 'value' property of the channel,<br />
and the record decides how to fill the remaining properties.<br />
<br />
Will the directory list all record names or all possible channels?<br />
I think only record names.<br />
<br />
Will it include the record type? Not enough information if we add user-defined fields.<br />
Will it lists all fields of a record?<br />
<br />
I think for now that only listing record names is enough in order to allow<br />
connections.<br />
<br />
The CA client would then have to query the CA server for all the available properties<br />
of a PV, and note that properties might even change at runtime when we allow<br />
online add & delete.<br />
<br />
Whenever a tool like a command-line 'caget' or the 'probe' GUI requires a PV name,<br />
it needs to be decided what properties "fred" would access. In the past, it was equal<br />
to "fred.VAL". There is much more detail in the 'view' section of the<br />
[[V4 DBD Statement Syntax]].<br />
<br />
== LDAP, Directory, RDB, Schema, Entries, dn, cn, dc, ... ==<br />
<br />
The ''Lightweight Directory Access Protocol'' (LDAP) is a network protocol.<br />
It defines how to access data over the network, regardless of language<br />
or underlying data storage. In contrast, RDBs like Oracle or MySQL define the<br />
data storage and SQL dialect, while the network access to the data is then<br />
added almost as an afterthought.<br />
<br />
LDAP is meant as a Directory for simple attribute-based information<br />
for fast, high volume lookup. Simple search filters are supported:<br />
Patterns, "and", "or". In contrast to RDBs, there is no support for<br />
arbitrary relations between entries, there are no transactions nor rollback.<br />
<br />
There are open-source servers for LDAP, and client libraries for<br />
C, Perl, Java and other languages. MacOSX, Linux, Windows 2000<br />
already include LDAP clients. MS ActiveDirectory uses LDAP.<br />
<br />
LDAP requires the data to be organized into hierarchical ''Entries''.<br />
Each Entry has a globally unique ''Distinguished Name'' (dn),<br />
and various ''Attributes'', that is Type/Value pairs.<br />
The ''Schema'' defines which attributes an entry must have and which ones<br />
it might have. There are existing schemas for DNS-type data or personell<br />
information, including types like ''Common Name'' (cn) or ''Domain Component'' (dc),<br />
but one can add custom schemata. Values might include binary data, e.g. images.<br />
<br />
=== Mapping EPICS PV Information to LDAP ===<br />
<br />
Each LDAP entry must have a unique name (dn). EPICS PVs must be unique as well,<br />
but only within the search domain currently defined by the EPICS_CA_ADDR_LIST.<br />
It might make sense to synchronize LDAP servers across these boundaries,<br />
in which case the LDAP dn will have to include more than just the PV name.<br />
For example, one could have a PV "fred" in both the accelerator and office network<br />
of the SNS, and enter them into an SNS-wide LDAP directory like this:<br />
<br />
fred.linac.sns.epics: cas="linacioc1:5065"<br />
fred.office.sns.epics: cas="testioc47.sns.ornl.gov:7987", description="Fred's test PV"<br />
<br />
In this example, the directory includes the ChannelAccess server for both PVs,<br />
and in one case also a description.<br />
<br />
While an EPICS-specific tool might present the data as shown above,<br />
most generic LDAP tools and APIs use the ''LDAP Data Interchange Format'' (LDIF).<br />
In LDIF, part of the above data could look like this:<br />
<br />
dn: dc=epics<br />
objectclass: dcObject<br />
objectclass: organization<br />
o: Root of all EPICS PVs<br />
dc: epics<br />
<br />
dn: dc=sns,dc=epics<br />
# Details omitted; similar to previous entry<br />
<br />
dn: dc=linac,dc=sns,dc=epics<br />
objectclass: dcObject<br />
objectclass: organization<br />
o: Root of all EPICS PVs in the SNS Linac<br />
dc: linac<br />
<br />
dn: cn=fred,dc=linac,dc=sns,dc=epics<br />
objectclass: ProcessVariable<br />
cn: fred<br />
cas: linacioc1:5065 <br />
<br />
Some points I had to learn:<br />
* Each entry has an objectclass. The schema for "ProcessVariable" would for example require a "cn" attribute, with optional "cas", "description" and maybe other attributes.<br>The schema would also determine if searches for PV names are case-sensitive or not.<br />
* The hierarchical path "fred.linac.sns.epics" translates into a dn "cn=fred,dc=linac,dc=sns,dc=epics" which lists the relative dn of the entry itself and all path elements.<br />
* Each path element must exists, so to bootstrap one has to create entries "dc=epics" and "dc=sns,dc=epics" etc., for which I used the pre-defined "organization" schema.<br />
* To locate the PV 'fred', any of the following LDAP searches would work:<br />
** Scope "base" with base "cn=fred,dc=linac,dc=sns,dc=epics".<br />
** Scope "one" with base "dc=linac,dc=sns,dc=epics" and filter "(cn=fred)".<br />
** Scope "one" with base "dc=linac,dc=sns,dc=epics" and filter "(cn=f*d)",<br>though this might return more records which happen to match the pattern.<br />
** Scope "sub" with base "dc=sns,dc=epics" and filter "(cn=fred)",<br>which would also return an entry with dn "cn=fred,dc=office,dc=sns,dc=epics".<br />
** There is a filter option "~=" for 'approximately equal'. Unclear what exactly defines approximate, but this might be very handy for detecing typos.<br />
<br />
=== OpenLDAP ===<br />
<br />
OpenLDAP [http://www.openldap.org] is an open-source LDAP<br />
client library for C and an LDAP server which can store the<br />
actual data in /dev/null, a BerkeleyDB, SQL, Perl, a remote LDAP server.<br />
<br />
OpenLDAP includes authentication and encrypted (SSL) transport,<br />
replication (single master -> multiple slaves),<br />
and referrals from one server to another one which has more details.<br />
<br />
=== EPICS PV Tests ===<br />
<br />
Using OpenLDAP-stable-20050429 and perl-ldap-0.3202 on a 1.3 GHz PowerBook G4<br />
with 780 MB RAM under MacOS X 10.3.8, I used a perl script to create<br />
PV entries, search them, and remove them.<br />
In addition, the 'ldapsearch' that comes with RedHat Enterprise AS 3 was<br />
used to check remote accessibillity.<br />
<br />
When trying to list all PVs with an appropriate search pattern,<br />
the default server configuration limits the response to 500 answers.<br />
This was changed such that 'paged' searches which keep requesting data<br />
in increments of e.g. 500 entries are allowed to continue until all data is retrieved.<br />
From the command-line tool, that's done like this:<br />
ldapsearch -x -LLL -E pr=10/noprompt -b 'dc=epics' '(cn=testpv*)' cas<br />
<br />
== Performance ==<br />
<br />
Based on the default OpenLDAP server config with an additional<br />
index "cn pres,eq" on the common name of the PVs,<br />
PVs with names 'testrec0000000001', 'testrec0000000002' etc.<br />
were added, then looked up one-by-one via their exact name,<br />
and finially deleted one by one.<br />
<br />
When using a C++ test client based on the OpenLDAP library,<br />
the results for smaller numbers are:<br />
Add 10000 records : 22.76 secs<br />
Locate 10000 records : 6.49 secs<br />
Delete 10000 records : 22.20 secs<br />
<br />
In another test, a very rough estimated PV count of the SNS linac<br />
was used:<br />
Add 200000 records : 675.89 secs (38.74 CPU)<br />
Locate 200000 records : 142.85 secs (27.91 CPU)<br />
Delete 200000 records : 807.28 secs (37.28 CPU)<br />
<br />
Those 200000 records use about 900MB of file space.<br />
The results indicate that one can add 300 .. 440 records/sec,<br />
locate 1400.. 1540 records/sec and delete 250..450 records/sec.<br />
Without an index, the addition and deletion will be faster<br />
at the expense of lookup times.<br />
<br />
A typical SNS LLRF IOCs has 2300 records.<br />
On startup, sending those to the directory server would take around 7 seconds.<br />
A typical SNS LLRF overview screen has about 400 PVs,<br />
and current connection times vary from less than a second to<br />
several tens of seconds, depending on how well the search requests<br />
reach the IOCs.<br />
Resolving their CA servers would take about 0.3 seconds with LDAP,<br />
which would then be followed by the time required to actually connect<br />
to those servers.<br />
<br />
In previous test using perl, the individual PV search actually used an LDIF<br />
filter with exact match like 'testrec0000000001'. In addition, all PVs matching<br />
a filter 'testrec*' were retrieved, and no index was used:<br />
Adding 1000 records: 4 wallclock secs ( 2.29 usr + 0.14 sys = 2.43 CPU)<br />
Locating 1000 records: 49 wallclock secs ( 4.10 usr + 0.21 sys = 4.31 CPU)<br />
Match all 1000: 1 wallclock secs ( 1.18 usr + 0.02 sys = 1.20 CPU)<br />
Delete 1000 records: 4 wallclock secs ( 1.35 usr + 0.14 sys = 1.49 CPU)<br />
<br />
When locating individual records via the complete LDIF base without a filter,<br />
the search is much faster:<br />
Locating 1000 records: 5 wallclock secs ( 3.20 usr + 0.18 sys = 3.38 CPU)<br />
<br />
When adding an "index cn pres,eq" to the server config, the results are the<br />
same for both the filter and the base search case.<br />
No difference observed when tripling the cachesize from the default of 1000.<br />
The behavior scales linearly with the number of channels,<br />
always a little over 200 additions or lookups per second:<br />
Adding 10000 records: 47 wallclock secs (21.72 usr + 1.28 sys = 23.00 CPU)<br />
Locating 10000 records: 44 wallclock secs (32.20 usr + 1.55 sys = 33.75 CPU)<br />
Match all 10000: 15 wallclock secs (12.15 usr + 0.64 sys = 12.79 CPU)<br />
Delete 10000 records: 38 wallclock secs (15.41 usr + 1.16 sys = 16.57 CPU)<br />
<br />
Adding 50000 records: 243 wallclock secs (110.36 usr + 7.18 sys = 117.54 CPU)<br />
Locating 50000 records: 226 wallclock secs (164.97 usr + 7.67 sys = 172.64 CPU)<br />
Match all 50000: 80 wallclock secs (63.09 usr + 3.42 sys = 66.51 CPU)<br />
Delete 50000 records: 219 wallclock secs (82.11 usr + 6.61 sys = 88.72 CPU)<br />
<br />
Adding 200000 records: 1293 wallclock secs (483.65 usr + 33.20 sys = 516.85 CPU)<br />
<br />
"index cn,dc pres,eq,approx,sub" takes longer to insert/delete<br />
without improved search performance:<br />
Adding 10000 records: 104 wallclock secs (26.25 usr + 1.67 sys = 27.92 CPU)<br />
Locating 10000 records: 45 wallclock secs (32.86 usr + 1.55 sys = 34.41 CPU)<br />
Match all 10000: 15 wallclock secs (12.31 usr + 0.47 sys = 12.78 CPU)<br />
Delete 10000 records: 97 wallclock secs (17.89 usr + 1.34 sys = 19.23 CPU)<br />
<br />
The CPU load is a rough 50/50 split between the perl and slapd processes.<br />
The perl ldap library is 100% perl, including the network handling and<br />
quite some data conversions from arrays into hashes and back,<br />
so a pure C client might be a little faster.<br />
<br />
Though an index slows down the insertion of PVs, it speeds up certain<br />
retrieval methods, as probably desired for an EPICS directory server.<br />
The search mechanism is based on round-trip requests.<br />
Searching PVs one PV name at a time is slower than requesting all<br />
PVs that match a pattern. Unfortunately, typical CA clients will<br />
have to request data for specific PV names, not by pattern.<br />
<br />
==== JOH: For comparison purposes, here is the performance of CA's built-in name resolution. ====<br />
<br />
Testing with 10000 channels named joh:bill<br />
channel connect test<br />
Elapsed Per Item = 0.00002349 sec, 42570.2 Items per sec, 22.5 Mbps<br />
Search tries per chan - mean=1.006200 std dev=0.078496 min=1.000000 max=2.000000<br />
<br />
=== To be investigated ===<br />
<br />
* How to access it from vxWorks<br />
* How does an LDAP server used for EPICS cooperate with existing LDAP servers for DNS, email etc. Should it be one and the same? Use special port numbers for 'EPICS' LDAP?<br />
* API: What type of API would EPICS tools use? Whatever LDAP library they use? An 'EPICS wrapper' around LDAP? Gasper suggested to look at the Java JNDI API for inspiration.<br />
* Common Database headaches:<br />
** To simply get a PV into LDAP, one has to check if this PV already exists and then either 'add' or 'modify'.<br />
** What if a channel is no longer available? An IOC shutting down could remove PVs from the LDAP server, but an IOC that crashes won't.<br />
* Replication: How to use it, how fast is it etc.<br />
* Authentication and encryption: How hard is it to configure?</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=V4_Name_Server&diff=354V4 Name Server2005-07-06T20:07:08Z<p>JeffHill: </p>
<hr />
<div>== Directory Server ==<br />
<br />
EPICS ChannelAccess currently uses a broadcast mechanism for resolving<br />
channel names.<br />
Advantages:<br />
* Minimal if not zero initial setup.<br />
* At least initially very fast, because a client can send multiple name requests in one network packet, all servers receive it simultaneously and can answer to known names.<br />
<br />
Disadvantages:<br />
* Unclear how to extend this service to redundant servers, archived data, ...<br />
* Currently, no wildcard searches.<br />
* Currently, no statistics on available number of channels, types of records, ...<br />
* Bigger installations run into problems with broadcast traffic:<br />
** All devices see the requests, even though only one server has a given channel name.<br />
** Continued searches for unresolved names to overcome UDP limitations.<br />
<br />
As Larry Hoff pointed out, we really want a ''Directory'' server for<br />
EPICS, something beyond a name server. A directory will not only map PV<br />
names to IP addresses of ChannelAccess servers, but also support<br />
* wildcard searches, reports on number of channels per IOC etc.<br />
* redundant servers<br />
* info about reduntant IOCs with the same PV, archived data for a PV<br />
* backup/restore locations for a PV<br />
* PV meta information like engineer-in-charge, CA security rules, ...<br />
<br />
== Channels, Records, PVs, Properties ==<br />
We currently have records with fields and channels with properties.<br />
Each field of a record can become a channel name,<br />
the field itself ends up in the 'value' property of the channel,<br />
and the record decides how to fill the remaining properties.<br />
<br />
Will the directory list all record names or all possible channels?<br />
I think only record names.<br />
<br />
Will it include the record type? Not enough information if we add user-defined fields.<br />
Will it lists all fields of a record?<br />
<br />
I think for now that only listing record names is enough in order to allow<br />
connections.<br />
<br />
The CA client would then have to query the CA server for all the available properties<br />
of a PV, and note that properties might even change at runtime when we allow<br />
online add & delete.<br />
<br />
Whenever a tool like a command-line 'caget' or the 'probe' GUI requires a PV name,<br />
it needs to be decided what properties "fred" would access. In the past, it was equal<br />
to "fred.VAL". There is much more detail in the 'view' section of the<br />
[[V4 DBD Statement Syntax]].<br />
<br />
== LDAP, Directory, RDB, Schema, Entries, dn, cn, dc, ... ==<br />
<br />
The ''Lightweight Directory Access Protocol'' (LDAP) is a network protocol.<br />
It defines how to access data over the network, regardless of language<br />
or underlying data storage. In contrast, RDBs like Oracle or MySQL define the<br />
data storage and SQL dialect, while the network access to the data is then<br />
added almost as an afterthought.<br />
<br />
LDAP is meant as a Directory for simple attribute-based information<br />
for fast, high volume lookup. Simple search filters are supported:<br />
Patterns, "and", "or". In contrast to RDBs, there is no support for<br />
arbitrary relations between entries, there are no transactions nor rollback.<br />
<br />
There are open-source servers for LDAP, and client libraries for<br />
C, Perl, Java and other languages. MacOSX, Linux, Windows 2000<br />
already include LDAP clients. MS ActiveDirectory uses LDAP.<br />
<br />
LDAP requires the data to be organized into hierarchical ''Entries''.<br />
Each Entry has a globally unique ''Distinguished Name'' (dn),<br />
and various ''Attributes'', that is Type/Value pairs.<br />
The ''Schema'' defines which attributes an entry must have and which ones<br />
it might have. There are existing schemas for DNS-type data or personell<br />
information, including types like ''Common Name'' (cn) or ''Domain Component'' (dc),<br />
but one can add custom schemata. Values might include binary data, e.g. images.<br />
<br />
=== Mapping EPICS PV Information to LDAP ===<br />
<br />
Each LDAP entry must have a unique name (dn). EPICS PVs must be unique as well,<br />
but only within the search domain currently defined by the EPICS_CA_ADDR_LIST.<br />
It might make sense to synchronize LDAP servers across these boundaries,<br />
in which case the LDAP dn will have to include more than just the PV name.<br />
For example, one could have a PV "fred" in both the accelerator and office network<br />
of the SNS, and enter them into an SNS-wide LDAP directory like this:<br />
<br />
fred.linac.sns.epics: cas="linacioc1:5065"<br />
fred.office.sns.epics: cas="testioc47.sns.ornl.gov:7987", description="Fred's test PV"<br />
<br />
In this example, the directory includes the ChannelAccess server for both PVs,<br />
and in one case also a description.<br />
<br />
While an EPICS-specific tool might present the data as shown above,<br />
most generic LDAP tools and APIs use the ''LDAP Data Interchange Format'' (LDIF).<br />
In LDIF, part of the above data could look like this:<br />
<br />
dn: dc=epics<br />
objectclass: dcObject<br />
objectclass: organization<br />
o: Root of all EPICS PVs<br />
dc: epics<br />
<br />
dn: dc=sns,dc=epics<br />
# Details omitted; similar to previous entry<br />
<br />
dn: dc=linac,dc=sns,dc=epics<br />
objectclass: dcObject<br />
objectclass: organization<br />
o: Root of all EPICS PVs in the SNS Linac<br />
dc: linac<br />
<br />
dn: cn=fred,dc=linac,dc=sns,dc=epics<br />
objectclass: ProcessVariable<br />
cn: fred<br />
cas: linacioc1:5065 <br />
<br />
Some points I had to learn:<br />
* Each entry has an objectclass. The schema for "ProcessVariable" would for example require a "cn" attribute, with optional "cas", "description" and maybe other attributes.<br>The schema would also determine if searches for PV names are case-sensitive or not.<br />
* The hierarchical path "fred.linac.sns.epics" translates into a dn "cn=fred,dc=linac,dc=sns,dc=epics" which lists the relative dn of the entry itself and all path elements.<br />
* Each path element must exists, so to bootstrap one has to create entries "dc=epics" and "dc=sns,dc=epics" etc., for which I used the pre-defined "organization" schema.<br />
* To locate the PV 'fred', any of the following LDAP searches would work:<br />
** Scope "base" with base "cn=fred,dc=linac,dc=sns,dc=epics".<br />
** Scope "one" with base "dc=linac,dc=sns,dc=epics" and filter "(cn=fred)".<br />
** Scope "one" with base "dc=linac,dc=sns,dc=epics" and filter "(cn=f*d)",<br>though this might return more records which happen to match the pattern.<br />
** Scope "sub" with base "dc=sns,dc=epics" and filter "(cn=fred)",<br>which would also return an entry with dn "cn=fred,dc=office,dc=sns,dc=epics".<br />
** There is a filter option "~=" for 'approximately equal'. Unclear what exactly defines approximate, but this might be very handy for detecing typos.<br />
<br />
=== OpenLDAP ===<br />
<br />
OpenLDAP [http://www.openldap.org] is an open-source LDAP<br />
client library for C and an LDAP server which can store the<br />
actual data in /dev/null, a BerkeleyDB, SQL, Perl, a remote LDAP server.<br />
<br />
OpenLDAP includes authentication and encrypted (SSL) transport,<br />
replication (single master -> multiple slaves),<br />
and referrals from one server to another one which has more details.<br />
<br />
=== EPICS PV Tests ===<br />
<br />
Using OpenLDAP-stable-20050429 and perl-ldap-0.3202 on a 1.3 GHz PowerBook G4<br />
with 780 MB RAM under MacOS X 10.3.8, I used a perl script to create<br />
PV entries, search them, and remove them.<br />
In addition, the 'ldapsearch' that comes with RedHat Enterprise AS 3 was<br />
used to check remote accessibillity.<br />
<br />
When trying to list all PVs with an appropriate search pattern,<br />
the default server configuration limits the response to 500 answers.<br />
This was changed such that 'paged' searches which keep requesting data<br />
in increments of e.g. 500 entries are allowed to continue until all data is retrieved.<br />
From the command-line tool, that's done like this:<br />
ldapsearch -x -LLL -E pr=10/noprompt -b 'dc=epics' '(cn=testpv*)' cas<br />
<br />
== Performance ==<br />
<br />
Based on the default OpenLDAP server config with an additional<br />
index "cn pres,eq" on the common name of the PVs,<br />
PVs with names 'testrec0000000001', 'testrec0000000002' etc.<br />
were added, then looked up one-by-one via their exact name,<br />
and finially deleted one by one.<br />
<br />
When using a C++ test client based on the OpenLDAP library,<br />
the results for smaller numbers are:<br />
Add 10000 records : 22.76 secs<br />
Locate 10000 records : 6.49 secs<br />
Delete 10000 records : 22.20 secs<br />
<br />
In another test, a very rough estimated PV count of the SNS linac<br />
was used:<br />
Add 200000 records : 675.89 secs (38.74 CPU)<br />
Locate 200000 records : 142.85 secs (27.91 CPU)<br />
Delete 200000 records : 807.28 secs (37.28 CPU)<br />
<br />
Those 200000 records use about 900MB of file space.<br />
The results indicate that one can add 300 .. 440 records/sec,<br />
locate 1400.. 1540 records/sec and delete 250..450 records/sec.<br />
Without an index, the addition and deletion will be faster<br />
at the expense of lookup times.<br />
<br />
A typical SNS LLRF IOCs has 2300 records.<br />
On startup, sending those to the directory server would take around 7 seconds.<br />
A typical SNS LLRF overview screen has about 400 PVs,<br />
and current connection times vary from less than a second to<br />
several tens of seconds, depending on how well the search requests<br />
reach the IOCs.<br />
Resolving their CA servers would take about 0.3 seconds with LDAP,<br />
which would then be followed by the time required to actually connect<br />
to those servers.<br />
<br />
In previous test using perl, the individual PV search actually used an LDIF<br />
filter with exact match like 'testrec0000000001'. In addition, all PVs matching<br />
a filter 'testrec*' were retrieved, and no index was used:<br />
Adding 1000 records: 4 wallclock secs ( 2.29 usr + 0.14 sys = 2.43 CPU)<br />
Locating 1000 records: 49 wallclock secs ( 4.10 usr + 0.21 sys = 4.31 CPU)<br />
Match all 1000: 1 wallclock secs ( 1.18 usr + 0.02 sys = 1.20 CPU)<br />
Delete 1000 records: 4 wallclock secs ( 1.35 usr + 0.14 sys = 1.49 CPU)<br />
<br />
When locating individual records via the complete LDIF base without a filter,<br />
the search is much faster:<br />
Locating 1000 records: 5 wallclock secs ( 3.20 usr + 0.18 sys = 3.38 CPU)<br />
<br />
When adding an "index cn pres,eq" to the server config, the results are the<br />
same for both the filter and the base search case.<br />
No difference observed when tripling the cachesize from the default of 1000.<br />
The behavior scales linearly with the number of channels,<br />
always a little over 200 additions or lookups per second:<br />
Adding 10000 records: 47 wallclock secs (21.72 usr + 1.28 sys = 23.00 CPU)<br />
Locating 10000 records: 44 wallclock secs (32.20 usr + 1.55 sys = 33.75 CPU)<br />
Match all 10000: 15 wallclock secs (12.15 usr + 0.64 sys = 12.79 CPU)<br />
Delete 10000 records: 38 wallclock secs (15.41 usr + 1.16 sys = 16.57 CPU)<br />
<br />
Adding 50000 records: 243 wallclock secs (110.36 usr + 7.18 sys = 117.54 CPU)<br />
Locating 50000 records: 226 wallclock secs (164.97 usr + 7.67 sys = 172.64 CPU)<br />
Match all 50000: 80 wallclock secs (63.09 usr + 3.42 sys = 66.51 CPU)<br />
Delete 50000 records: 219 wallclock secs (82.11 usr + 6.61 sys = 88.72 CPU)<br />
<br />
Adding 200000 records: 1293 wallclock secs (483.65 usr + 33.20 sys = 516.85 CPU)<br />
<br />
"index cn,dc pres,eq,approx,sub" takes longer to insert/delete<br />
without improved search performance:<br />
Adding 10000 records: 104 wallclock secs (26.25 usr + 1.67 sys = 27.92 CPU)<br />
Locating 10000 records: 45 wallclock secs (32.86 usr + 1.55 sys = 34.41 CPU)<br />
Match all 10000: 15 wallclock secs (12.31 usr + 0.47 sys = 12.78 CPU)<br />
Delete 10000 records: 97 wallclock secs (17.89 usr + 1.34 sys = 19.23 CPU)<br />
<br />
The CPU load is a rough 50/50 split between the perl and slapd processes.<br />
The perl ldap library is 100% perl, including the network handling and<br />
quite some data conversions from arrays into hashes and back,<br />
so a pure C client might be a little faster.<br />
<br />
Though an index slows down the insertion of PVs, it speeds up certain<br />
retrieval methods, as probably desired for an EPICS directory server.<br />
The search mechanism is based on round-trip requests.<br />
Searching PVs one PV name at a time is slower than requesting all<br />
PVs that match a pattern. Unfortunately, typical CA clients will<br />
have to request data for specific PV names, not by pattern.<br />
<br />
JOH: For comparison purposes, here is the performance of CA's built-in name resolution. <br />
<br />
Testing with 10000 channels named joh:bill<br />
<br />
channel connect test<br />
<br />
Elapsed Per Item = 0.00002349 sec, 42570.2 Items per sec, 22.5 Mbps<br />
<br />
Search tries per chan - mean=1.006200 std dev=0.078496 min=1.000000 max=2.000000<br />
<br />
=== To be investigated ===<br />
<br />
* How to access it from vxWorks<br />
* How does an LDAP server used for EPICS cooperate with existing LDAP servers for DNS, email etc. Should it be one and the same? Use special port numbers for 'EPICS' LDAP?<br />
* API: What type of API would EPICS tools use? Whatever LDAP library they use? An 'EPICS wrapper' around LDAP? Gasper suggested to look at the Java JNDI API for inspiration.<br />
* Common Database headaches:<br />
** To simply get a PV into LDAP, one has to check if this PV already exists and then either 'add' or 'modify'.<br />
** What if a channel is no longer available? An IOC shutting down could remove PVs from the LDAP server, but an IOC that crashes won't.<br />
* Replication: How to use it, how fast is it etc.<br />
* Authentication and encryption: How hard is it to configure?</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Design:_epicsTypes&diff=2744Talk:V4 Design: epicsTypes2005-06-16T16:33:20Z<p>JeffHill: more comments</p>
<hr />
<div>Here are my comments<br />
<br />
1) All of the readers here probably already know that I feel that the unsigned types in C are useful. Well written code range checks operands, and unsigned operands typically require less range checking. When problems occur it's because users convert between signed and unsigned types without proper range checking. Since data access has this range checking built in (after considerable effort on mine and Ralph's part I will add) then conversion problems are possibly no longer an issue.<br />
<br />
2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should have the goal of using the same interfaces for each of the fundamental data types?<br />
<br />
3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn’t this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory. Note that fragmentation isnt just a binary condition (memory of a particular size is or isnt available). Fragmentation is also an efficency isssue because most random sized block memory allocators require searching for the best sized free block. Note that one of my goals for V4 is to no longer require EPICS_CA_MAX_ARRAY_BYTES.<br />
<br />
More comments:<br />
<br />
> > In any case, it seems <br />
> > that we should have the goal of using the same interfaces for each of <br />
> > the fundamental data types?<br />
> Agreed about the goal, but your interfaces don't necessarily take into <br />
> account all of our requirements, and we think some of your interfaces <br />
> are stricter than they need to be, which harms performance. I suspect <br />
> we would have few problems implementing most of your interfaces on top <br />
> of ours, but adopting ours should be more efficient since you don't have <br />
> to do everything one character or element at a time - we expose a whole <br />
> segment at once.<br />
<br />
1) I think that the above comment applies only to strings as all other types in data access are accessed in chunks - allowing the highest level of performance. <br />
<br />
2) The data access string interface StringSegment certainly does force all string access through a stream interface indexed int wide getChar/putChar. I wanted to support all character widths through one interface. I was inclined to conclude that if they are communicating in strings they can't be too concerned about performance. I was also, I admit, not thinking about UTF-8.<br />
<br />
3) Since your interface allows writing multiple characters to the string at a time doesn’t this force a UTF-8 implementation of complex characters (contrary to what I seem to recall reading in your doc)? <br />
<br />
4) Forcing UTF-8 probably isn’t a bad idea. I would be amenable to just saying that if we will have wide characters they will be UTF-8. This would be a real nice simplification of course when compressing the data for the CA protocol. The StringSegment interface in data access certainly could be revised to allow blocks of characters to be read/written in UTF-8 format (assuming that all strings are streams of octets).<br />
<br />
5) We should carefully consider implementations and interfaces, and how they may become dependent on each other. Of course, for review, interfaces are pure virtual and implementations have data in them. For fundamental types we should be careful about making implementation dependent on implementations because we can end up with code maintenance issues (been there, done that). I notice that EpicsEnum is an implementation and it is based on EpicsString - another implementation. In contrast, the data access StringSegment interface is just an interface. Another example is EpicsArray which is admitted to not be type safe. That might be fine as an internal scaffolding for an array, but when crossing boundaries between components the interface presented by data access might be more appropriate because it *is* type safe.<br />
<br />
6) I used a stream type of interface as a foundation for the StringSegment interface. This appears to be a nice approach in my IMHO. By the way, I did look at basing strings on stream strings in the C++ standard library but gave up on that when I realized that most implementations were calling malloc in the stream objects constructor - too much overhead for temporary object mapping protocol streams so that they can cross interfaces. The fundamental problem here by the way is that the standard library made the core stream an implementation, and not an interface.<br />
<br />
7) Dejavu. I am always defining interfaces without epics in their name which are subsequently superseded by revised interfaces that do. Who owns this EPICS name anyways? This is vaguely reminiscent of IBM calling there computer the "personal computer" and Microsoft calling there window system "windows" - whoever owns the most generic name wins :-). Is it somewhat redundant to have to type epics every time that I type an interface name? Should there be a C++ namespace called "epics"? Is that too course of a granularity for a name space, and possibly also too limiting for generic things like fundamental types (is this buffer only useable with EPICS)?<br />
<br />
8) I notice that some of these classes hand off pointers to internal storage. EpicsBuffer does this of course when we are granted access to a buffer segment, and some of the other do it also when they return a pointer to the buffer creator (it should probably be a reference that is returned). The problem is that users may continue to use handles to internal objects after the object that owns them (and manages there existence) don’t exist. Admittedly, a buffer is a very low level object and you might make exceptions for performance reasons. However, when these C++ systems become large and complex object lifespan mistakes seem to be one of the primary failure modes. In any case I tried to avoid this in data access by making all buffer internal access occur only during the duration of the callback. It's clear in the callback that we can only access the incoming arguments for the duration of the callback. The performance is the same because we still have direct access to large chunks.<br />
<br />
9) I really do feel that using unsigned types for integers that should never be negative is best. Oh well, perhaps I am the only one yelling this out from the bottom of a well, and no one is listening anyways.<br />
<br />
> Go back and read the section on the EpicsBuffer interface again; <br />
> none of our classes require contiguous buffer storage. <br />
<br />
Sorry, after reflecting more carefully on the code snippets (yes, I do that too) I now understand what is being done. This buffer thingy is an implementation, and not an interface, and yes it does allow segmented storage.<br />
<br />
> Since we never really write down and agree what all the detailed <br />
> requirements are, but just present each other with code snippets that <br />
> implement our view of them, I think we're going to continue to have <br />
> disagreements like these. It would speed things up immensely if we <br />
> could first agree in writing on what we are going to accomplish *before* <br />
> we actually start implementing it (and I plead as guilty as everyone <br />
> else on that charge).<br />
<br />
I think that this is another way of expressing a desire for better coordination of the overall design process. Coordination is good and more of it can't be worse than the current situation (almost none). However, dialog like this shouldn’t be seen as a problem either. Coordination without dialog (multiple voices) would probably be worse.<br />
<br />
> The current definition of epicsTypes does NOT include unsigned <br />
> types. The reason is Java. If we allow unsigned types it makes <br />
> it very difficult to complely support Java.<br />
<br />
There is possibly another way of looking at this. With Java we must use an integer type that has sufficient range to hold the magnitude of the integer number used in C. This statement is true irregardless of whether the C type is a signed or unsigned integer. Data Access will of course detect problems where the integer magnitude in the server does not map to the range of the data type of the client, and report them as exception call backs. We use unsigned integer types because their domain fits better with the arithmetic that is being conducted, and not because of their slightly higher positive range. Relying on the extra range would be flying too close to the trees IMHO. With bit fields if we have the option to address the bit field by its offset and length then we will almost never need to perform arithmetic directly on an unsigned 32 or 64 bit field. That’s a good thing. Otherwise Java might find itself pickled when communicating with hardware ;-)<br />
<br />
> I am again haunted by Doug's request for "hello world".<br />
<br />
If we provide some basic types ala db_access.h that are already interfaced by data access then data access shouldn’t need to be seen by naïve users. No doubt that we will layer a caGet and a caPut which will take "hello world" as a parameter.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Design:_epicsTypes&diff=289Talk:V4 Design: epicsTypes2005-06-15T23:16:43Z<p>JeffHill: </p>
<hr />
<div>Here are my comments<br />
<br />
1) All of the readers here probably already know that I feel that the unsigned types in C are useful. Well written code range checks operands, and unsigned operands typically require less range checking. When problems occur it's because users convert between signed and unsigned types without proper range checking. Since data access has this range checking built in (after considerable effort on mine and Ralph's part I will add) then conversion problems are possibly no longer an issue.<br />
<br />
2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should have the goal of using the same interfaces for each of the fundamental data types?<br />
<br />
3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn’t this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory. Note that fragmentation isnt just a binary condition (memory of a particular size is or isnt available). Fragmentation is also an efficency isssue because most random sized block memory allocators require searching for the best sized free block. Note that one of my goals for V4 is to no longer require EPICS_CA_MAX_ARRAY_BYTES.<br />
<br />
More comments:<br />
<br />
> > In any case, it seems <br />
> > that we should have the goal of using the same interfaces for each of <br />
> > the fundamental data types?<br />
> Agreed about the goal, but your interfaces don't necessarily take into <br />
> account all of our requirements, and we think some of your interfaces <br />
> are stricter than they need to be, which harms performance. I suspect <br />
> we would have few problems implementing most of your interfaces on top <br />
> of ours, but adopting ours should be more efficient since you don't have <br />
> to do everything one character or element at a time - we expose a whole <br />
> segment at once.<br />
<br />
1) I think that the above comment applies only to strings as all other types in data access are accessed in chunks - allowing the highest level of performance. <br />
<br />
2) The data access string interface StringSegment certainly does force all string access through a stream interface indexed int wide getChar/putChar. I wanted to support all character widths through one interface. I was inclined to conclude that if they are communicating in strings they can't be too concerned about performance. I was also, I admit, not thinking about UTF-8.<br />
<br />
3) Since your interface allows writing multiple characters to the string at a time doesn’t this force a UTF-8 implementation of complex characters (contrary to what I seem to recall reading in your doc)? <br />
<br />
4) Forcing UTF-8 probably isn’t a bad idea. I would be amenable to just saying that if we will have wide characters they will be UTF-8. This would be a real nice simplification of course when compressing the data for the CA protocol. The StringSegment interface in data access certainly could be revised to allow blocks of characters to be read/written in UTF-8 format (assuming that all strings are streams of octets).<br />
<br />
5) We should carefully consider implementations and interfaces, and how they may become dependent on each other. Of course, for review, interfaces are pure virtual and implementations have data in them. For fundamental types we should be careful about making implementation dependent on implementations because we can end up with code maintenance issues (been there, done that). I notice that EpicsEnum is an implementation and it is based on EpicsString - another implementation. In contrast, the data access StringSegment interface is just an interface. Another example is EpicsArray which is admitted to not be type safe. That might be fine as an internal scaffolding for an array, but when crossing boundaries between components the interface presented by data access might be more appropriate because it *is* type safe.<br />
<br />
6) I used a stream type of interface as a foundation for the StringSegment interface. This appears to be a nice approach in my IMHO. By the way, I did look at basing strings on stream strings in the C++ standard library but gave up on that when I realized that most implementations were calling malloc in the stream objects constructor - too much overhead for temporary object mapping protocol streams so that they can cross interfaces. The fundamental problem here by the way is that the standard library made the core stream an implementation, and not an interface.<br />
<br />
7) Dejavu. I am always defining interfaces without epics in their name which are subsequently superseded by revised interfaces that do. Who owns this EPICS name anyways? This is vaguely reminiscent of IBM calling there computer the "personal computer" and Microsoft calling there window system "windows" - whoever owns the most generic name wins :-). Is it somewhat redundant to have to type epics every time that I type an interface name? Should there be a C++ namespace called "epics"? Is that too course of a granularity for a name space, and possibly also too limiting for generic things like fundamental types (is this buffer only useable with EPICS)?<br />
<br />
8) I notice that some of these classes hand off pointers to internal storage. EpicsBuffer does this of course when we are granted access to a buffer segment, and some of the other do it also when they return a pointer to the buffer creator (it should probably be a reference that is returned). The problem is that users may continue to use handles to internal objects after the object that owns them (and manages there existence) don’t exist. Admittedly, a buffer is a very low level object and you might make exceptions for performance reasons. However, when these C++ systems become large and complex object lifespan mistakes seem to be one of the primary failure modes. In any case I tried to avoid this in data access by making all buffer internal access occur only during the duration of the callback. It's clear in the callback that we can only access the incoming arguments for the duration of the callback. The performance is the same because we still have direct access to large chunks.<br />
<br />
9) I really do feel that using unsigned types for integers that should never be negative is best. Oh well, perhaps I am the only one yelling this out from the bottom of a well, and no one is listening anyways.<br />
<br />
> Go back and read the section on the EpicsBuffer interface again; <br />
> none of our classes require contiguous buffer storage. <br />
<br />
Sorry, after reflecting more carefully on the code snippets (yes, I do that too) I now understand what is being done. This buffer thingy is an implementation, and not an interface, and yes it does allow segmented storage.<br />
<br />
> Since we never really write down and agree what all the detailed <br />
> requirements are, but just present each other with code snippets that <br />
> implement our view of them, I think we're going to continue to have <br />
> disagreements like these. It would speed things up immensely if we <br />
> could first agree in writing on what we are going to accomplish *before* <br />
> we actually start implementing it (and I plead as guilty as everyone <br />
> else on that charge).<br />
<br />
I think that this is another way of expressing a desire for better coordination of the overall design process. Coordination is good and more of it can't be worse than the current situation (almost none). However, dialog like this shouldn’t be seen as a problem either. Coordination without dialog (multiple voices) would probably be worse.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Design:_epicsTypes&diff=288Talk:V4 Design: epicsTypes2005-06-14T22:07:20Z<p>JeffHill: </p>
<hr />
<div>Here are my comments<br />
<br />
1) All of the readers here probably already know that I feel that the unsigned types in C are useful. Well written code range checks operands, and unsigned operands typically require less range checking. When problems occur it's because users convert between signed and unsigned types without proper range checking. Since data access has this range checking built in (after considerable effort on mine and Ralph's part I will add) then conversion problems are possibly no longer an issue.<br />
<br />
2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should have the goal of using the same interfaces for each of the fundamental data types?<br />
<br />
3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn’t this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory. Note that fragmentation isnt just a binary condition (memory of a particular size is or isnt available). Fragmentation is also an efficency isssue because most random sized block memory allocators require searching for the best sized free block. Note that one of my goals for V4 is to no longer require EPICS_CA_MAX_ARRAY_BYTES.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Design:_epicsTypes&diff=282Talk:V4 Design: epicsTypes2005-06-14T22:06:32Z<p>JeffHill: </p>
<hr />
<div>Here are my comments<br />
<br />
1) All of the readers here probably already know that I feel that the unsigned types in C are useful. Well written code range checks operands, and unsigned operands typically require less range checking. When problems occur it's because users convert between signed and unsigned types without proper range checking. Since data access has this range checking built in (after considerable effort on mine and Ralph's part I will add) then conversion problems are possibly no longer an issue.<br />
<br />
2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should have the goal of using the same interfaces for each of the fundamental data types?<br />
<br />
3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn’t this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory. Note that fragmentation isnt just a binary condition (memory of a particular size is or isnt available). Fragmentation is also an efficency isssue because most random sized block memory allocators require searching for the best sized free block.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Design:_epicsTypes&diff=281Talk:V4 Design: epicsTypes2005-06-14T21:46:29Z<p>JeffHill: </p>
<hr />
<div>Here are my comments<br />
<br />
1) As we are all already aware I feel that the unsigned types in C are useful. When problems occur it's because users convert between signed and unsigned types without proper range checking. Since data access has this range checking built in (after considerable effort on mine and Ralph's part I will add) then conversion problems are possibly no longer an issue.<br />
<br />
2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should have the goal of using the same interfaces for each type of commonly used data.<br />
<br />
3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn’t this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Design:_epicsTypes&diff=280Talk:V4 Design: epicsTypes2005-06-14T21:44:48Z<p>JeffHill: my comments</p>
<hr />
<div>Here are my comments<br />
<br />
1) As we are all already aware I feel that the unsigned types in C are useful. When problems occur it's because users convert between signed and unsigned types without proper range checking. Since data access has this range checking built in (after considerable effort on mine and Ralph's part I will add) then conversion problems are possibly no longer an issue.<br />
<br />
2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should the goal of using the same interfaces for each type of commonly used data.<br />
<br />
3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn’t this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_CA_Interfaces&diff=2728Talk:V4 CA Interfaces2005-05-20T19:35:03Z<p>JeffHill: </p>
<hr />
<div>Some comments from Andrew Johnson:<br />
<br />
In your presentation about CA V4, you included the method <br />
channel::createAllPropertiesReadRequest(). I agree that we need a way <br />
to be able to read all of the properties available from the server for a <br />
particular PV name, but I want more flexibility than just being able to <br />
put that wild-card at the top of my request.<br />
<br />
I think we need the ability to be able to subscribe with a property <br />
catalog having a specific set of properties at one level but to <br />
wild-card a sub-property catalog at some level below. Is this currently <br />
possible? If not, please consider this a request to add that <br />
capability, which might then remove the need for the seperate <br />
createAllPropertiesReadRequest() method. I'm only looking for you to <br />
support "*", no pattern matching or regex stuff.<br />
<br />
Some comments from Jeff Hill:<br />
<br />
During our meeting I raised a question; do we may need a Data Access interface allowing traversal of the structure of the property hierarchy, learning the native type of the properties, but not require instances of the properties?<br />
<br />
There may be legitimate situations where the property catalog egg must come before the property catalog chicken. Furthermore, it might be inconvenient from a memory management perspective to require an instance of an array before it is really used. I think that this negative could be perhaps minimized if we state in the CA manual that the array bounds alone will be examined, and the array elements will not be traversed, when scanning a property catalog to learn its structure.<br />
<br />
Probably the only negative associated with adding a property catalog structure traverse capability to the interface would be that the application would need to provide one additional function. They are already providing an immutable traverse, a mutable traverse function, and an immutable find function. What is vexing is that in many situations all three of the traverse functions are nearly identical. Personally, I don’t like to see common code managed with cut and paste. I am even less fond of that eventuality should it be repeated for many, many data structures in a proliferation of applications. <br />
<br />
So I had a look at what level of Data Access library support might be provided so that they need write the guts of the traverse function only once. The following is an example of how they might structure their application. There are still three traverse functions because cross library binding requires the virtual base class interfaced technique, but now they can use a template to implement the traversing only once.<br />
<br />
This level of complication appears to be reasonable for end user applications. <br />
<br />
<pre><br />
<br />
PropertyId propertyX;<br />
PropertyId propertyY;<br />
PropertyId propertyZ;<br />
PropertyId propertyI;<br />
<br />
class MyContainer : private PropertyCatalog {<br />
public:<br />
<br />
private:<br />
int x;<br />
float y;<br />
double z;<br />
char i;<br />
static void traverse ( <br />
PropertyDescriptionViewer & );<br />
void traverse ( <br />
PropertyManipulator & );<br />
void traverse ( <br />
PropertyViewer & ) const;<br />
bool find ( <br />
const PropertyId & id, PropertyViewer & ) const;<br />
template < class REFERENCE, class MANIPULATOR ><br />
static void traverseTempl ( <br />
const REFERENCE &, MANIPULATOR & );<br />
};<br />
<br />
template < class REFERENCE, class MANIPULATOR ><br />
inline void MyContainer::traverseTempl ( <br />
const REFERENCE & ref, MANIPULATOR & manipulator )<br />
{<br />
ref.reveal ( <br />
manipulator, propertyX, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyY, & MyContainer::y );<br />
ref.reveal ( <br />
manipulator, propertyZ, & MyContainer::z );<br />
ref.reveal ( <br />
manipulator, propertyI, & MyContainer::i );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyManipulator & manipulator ) <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < MyContainer > ( *this ), manipulator );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyViewer & viewer ) const <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < const MyContainer > ( *this ), viewer );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyDescriptionViewer & viewer )<br />
{<br />
MyContainer::traverseTempl ( reference < void > (), viewer );<br />
}<br />
<br />
bool MyContainer::find ( <br />
const PropertyId & id, <br />
PropertyManipulator < Property > & manipulator ) const <br />
{<br />
bool status = false;<br />
if ( id == propertyX ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyX, this->x ) );<br />
status = true;<br />
}<br />
else ( id == propertyY ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyY, this->y ) );<br />
status = true;<br />
}<br />
return status;<br />
}<br />
<br />
</pre></div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_CA_Interfaces&diff=187Talk:V4 CA Interfaces2005-05-20T19:32:31Z<p>JeffHill: </p>
<hr />
<div>Some comments from Andrew Johnson:<br />
<br />
In your presentation about CA V4, you included the method <br />
channel::createAllPropertiesReadRequest(). I agree that we need a way <br />
to be able to read all of the properties available from the server for a <br />
particular PV name, but I want more flexibility than just being able to <br />
put that wild-card at the top of my request.<br />
<br />
I think we need the ability to be able to subscribe with a property <br />
catalog having a specific set of properties at one level but to <br />
wild-card a sub-property catalog at some level below. Is this currently <br />
possible? If not, please consider this a request to add that <br />
capability, which might then remove the need for the seperate <br />
createAllPropertiesReadRequest() method. I'm only looking for you to <br />
support "*", no pattern matching or regex stuff.<br />
<br />
Some comments from Jeff Hill:<br />
<br />
During our meeting I raised a question; do we may need a Data Access interface allowing traversal of the structure of the property hierarchy, learning the native type of the properties, but not require instances of the properties?<br />
<br />
There may be legitimate situations where the property catalog egg must come before the property catalog chicken. Furthermore, it might be inconvenient from a memory management perspective to require an instance of an array before it is really used. I think that this negative could be perhaps minimized if we state in the CA manual that the array bounds alone will be examined, and the array elements will not be traversed, when scanning a property catalog to learn its structure.<br />
<br />
Probably the only negative associated with adding a property catalog structure traverse capability to the interface would be that the application would need to provide one additional function. They are already providing an immutable traverse, a mutable traverse function, and an immutable find function. What is vexing is that in many situations all three of the traverse functions are nearly identical. Personally, I don’t like to see common code managed with cut and paste. I am even less fond of that eventuality should it be repeated for many, many data structures in a proliferation of applications. <br />
<br />
So I had a look at what level of Data Access library support might be provided so that they need write the guts of the traverse function only once. The following is an example of how they might structure their application. There are still three traverse functions because cross library binding requires the virtual base class interfaced technique, but now they can use a template to implement the traversing only once.<br />
<br />
This level of complication appears to be reasonable for end user applications. <br />
<br />
<pre><br />
<br />
PropertyId propertyX;<br />
PropertyId propertyY;<br />
PropertyId propertyZ;<br />
PropertyId propertyI;<br />
<br />
class MyContainer : private PropertyCatalog {<br />
public:<br />
<br />
private:<br />
int x;<br />
float y;<br />
double z;<br />
char i;<br />
static void traverse ( <br />
PropertyDescriptionViewer & );<br />
void traverse ( <br />
PropertyManipulator & );<br />
void traverse ( <br />
PropertyViewer & ) const;<br />
bool find ( <br />
const PropertyId & id, PropertyViewer & ) const;<br />
template < class REFERENCE, class MANIPULATOR ><br />
static void traverseTempl ( <br />
const REFERENCE &, MANIPULATOR & );<br />
};<br />
<br />
template < class REFERENCE, class MANIPULATOR ><br />
inline void MyContainer::traverseTempl ( <br />
const REFERENCE & ref, MANIPULATOR & manipulator )<br />
{<br />
ref.reveal ( <br />
manipulator, propertyX, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyY, & MyContainer::y );<br />
ref.reveal ( <br />
manipulator, propertyZ, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyI, & MyContainer::i );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyManipulator & manipulator ) <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < MyContainer > ( *this ), manipulator );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyViewer & viewer ) const <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < const MyContainer > ( *this ), viewer );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyDescriptionViewer & viewer )<br />
{<br />
MyContainer::traverseTempl ( reference < void > (), viewer );<br />
}<br />
<br />
bool MyContainer::find ( <br />
const PropertyId & id, <br />
PropertyManipulator < Property > & manipulator ) const <br />
{<br />
bool status = false;<br />
if ( id == propertyX ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyX, this->x ) );<br />
status = true;<br />
}<br />
else ( id == propertyY ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyY, this->y ) );<br />
status = true;<br />
}<br />
return status;<br />
}<br />
<br />
</pre></div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_CA_Interfaces&diff=186Talk:V4 CA Interfaces2005-05-20T19:31:05Z<p>JeffHill: </p>
<hr />
<div>Some comments from Andrew Johnson:<br />
<br />
In your presentation about CA V4, you included the method <br />
channel::createAllPropertiesReadRequest(). I agree that we need a way <br />
to be able to read all of the properties available from the server for a <br />
particular PV name, but I want more flexibility than just being able to <br />
put that wild-card at the top of my request.<br />
<br />
I think we need the ability to be able to subscribe with a property <br />
catalog having a specific set of properties at one level but to <br />
wild-card a sub-property catalog at some level below. Is this currently <br />
possible? If not, please consider this a request to add that <br />
capability, which might then remove the need for the seperate <br />
createAllPropertiesReadRequest() method. I'm only looking for you to <br />
support "*", no pattern matching or regex stuff.<br />
<br />
Some comments from Jeff Hill:<br />
<br />
During our meeting I raised a question; do we may need a Data Access interface allowing traversal of the structure of the property hierarchy, learning the native type of the properties, but not require instances of the properties?<br />
<br />
There may be legitimate situations where the property catalog egg must come before the property catalog chicken. Furthermore, it might be quite inconvenient from a memory management perspective to require an instance of an array before it is really used. I think that this negative could be perhaps minimized if we state in the CA manual that the array bounds alone will be examined, and the array elements will not be traversed, when scanning a property catalog to learn its structure.<br />
<br />
Probably the only negative associated with adding a property catalog structure traverse capability to the interface would be that the application would need to provide one additional function. They are already providing an immutable traverse, a mutable traverse function, and an immutable find function. What is vexing is that in many situations all three of the traverse functions are nearly identical. Personally, I don’t like to see common code managed with cut and paste. I am even less fond of that eventuality should it be repeated for many, many data structures in a proliferation of applications. <br />
<br />
So I had a look at what level of Data Access library support might be provided so that they need write the guts of the traverse function only once. The following is an example of how they might structure their application. There are still three traverse functions because cross library binding requires the virtual base class interfaced technique, but now they can use a template to implement the traversing only once.<br />
<br />
This level of complication appears to be reasonable for end user applications. <br />
<br />
<pre><br />
<br />
PropertyId propertyX;<br />
PropertyId propertyY;<br />
PropertyId propertyZ;<br />
PropertyId propertyI;<br />
<br />
class MyContainer : private PropertyCatalog {<br />
public:<br />
<br />
private:<br />
int x;<br />
float y;<br />
double z;<br />
char i;<br />
static void traverse ( <br />
PropertyDescriptionViewer & );<br />
void traverse ( <br />
PropertyManipulator & );<br />
void traverse ( <br />
PropertyViewer & ) const;<br />
bool find ( <br />
const PropertyId & id, PropertyViewer & ) const;<br />
template < class REFERENCE, class MANIPULATOR ><br />
static void traverseTempl ( <br />
const REFERENCE &, MANIPULATOR & );<br />
};<br />
<br />
template < class REFERENCE, class MANIPULATOR ><br />
inline void MyContainer::traverseTempl ( <br />
const REFERENCE & ref, MANIPULATOR & manipulator )<br />
{<br />
ref.reveal ( <br />
manipulator, propertyX, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyY, & MyContainer::y );<br />
ref.reveal ( <br />
manipulator, propertyZ, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyI, & MyContainer::i );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyManipulator & manipulator ) <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < MyContainer > ( *this ), manipulator );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyViewer & viewer ) const <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < const MyContainer > ( *this ), viewer );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyDescriptionViewer & viewer )<br />
{<br />
MyContainer::traverseTempl ( reference < void > (), viewer );<br />
}<br />
<br />
bool MyContainer::find ( <br />
const PropertyId & id, <br />
PropertyManipulator < Property > & manipulator ) const <br />
{<br />
bool status = false;<br />
if ( id == propertyX ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyX, this->x ) );<br />
status = true;<br />
}<br />
else ( id == propertyY ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyY, this->y ) );<br />
status = true;<br />
}<br />
return status;<br />
}<br />
<br />
</pre></div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_CA_Interfaces&diff=185Talk:V4 CA Interfaces2005-05-20T19:25:05Z<p>JeffHill: </p>
<hr />
<div>Some comments from Andrew Johnson:<br />
<br />
In your presentation about CA V4, you included the method <br />
channel::createAllPropertiesReadRequest(). I agree that we need a way <br />
to be able to read all of the properties available from the server for a <br />
particular PV name, but I want more flexibility than just being able to <br />
put that wild-card at the top of my request.<br />
<br />
I think we need the ability to be able to subscribe with a property <br />
catalog having a specific set of properties at one level but to <br />
wild-card a sub-property catalog at some level below. Is this currently <br />
possible? If not, please consider this a request to add that <br />
capability, which might then remove the need for the seperate <br />
createAllPropertiesReadRequest() method. I'm only looking for you to <br />
support "*", no pattern matching or regex stuff.<br />
<br />
Some comments from Jeff Hill:<br />
<br />
During our meeting I raised a question; do we may need a Data Access interface allowing traversal of the structure of the property hierarchy, learning the native type of the properties, but not require instances of the properties?<br />
<br />
There may be legitimate situations where the property catalog egg must come before the property catalog chicken. Furthermore, it might be quite inconvenient from a memory management perspective to require an instance of an array before it is really used. I think that this negative could be perhaps minimized if we state in the CA manual that the array bounds alone will be examined, and the array elements will not be traversed, when scanning a property catalog to learn its structure.<br />
<br />
Probably the only negative associated with adding a property catalog structure traverse capability to the interface would be that the application would need to provide one additional function. They are already providing an immutable traverse, a mutable traverse function, and an immutable find function. What is vexing is that in many situations all three of the traverse functions are nearly identical. Personally, I don’t like to see common code managed with cut and paste. I am even less fond of that eventuality should it be repeated for many, many data structures in a proliferation of applications. <br />
<br />
So I had a look at what level of Data Access library support might be provided so that they need write the guts of the traverse function once. The following is an example of how they might structure their application. There are still three traverse functions because cross library binding requires the virtual base class interfaced technique, but now they can use a template to implement the traversing only once.<br />
<br />
This level of complication appears to be reasonable for end user applications. <br />
<br />
<pre><br />
<br />
PropertyId propertyX;<br />
PropertyId propertyY;<br />
PropertyId propertyZ;<br />
PropertyId propertyI;<br />
<br />
class MyContainer : private PropertyCatalog {<br />
public:<br />
<br />
private:<br />
int x;<br />
float y;<br />
double z;<br />
char i;<br />
static void traverse ( <br />
PropertyDescriptionViewer & );<br />
void traverse ( <br />
PropertyManipulator & );<br />
void traverse ( <br />
PropertyViewer & ) const;<br />
bool find ( <br />
const PropertyId & id, PropertyViewer & ) const;<br />
template < class REFERENCE, class MANIPULATOR ><br />
static void traverseTempl ( <br />
const REFERENCE &, MANIPULATOR & );<br />
};<br />
<br />
template < class REFERENCE, class MANIPULATOR ><br />
inline void MyContainer::traverseTempl ( <br />
const REFERENCE & ref, MANIPULATOR & manipulator )<br />
{<br />
ref.reveal ( <br />
manipulator, propertyX, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyY, & MyContainer::y );<br />
ref.reveal ( <br />
manipulator, propertyZ, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyI, & MyContainer::i );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyManipulator & manipulator ) <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < MyContainer > ( *this ), manipulator );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyViewer & viewer ) const <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < const MyContainer > ( *this ), viewer );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyDescriptionViewer & viewer )<br />
{<br />
MyContainer::traverseTempl ( reference < void > (), viewer );<br />
}<br />
<br />
bool MyContainer::find ( <br />
const PropertyId & id, <br />
PropertyManipulator < Property > & manipulator ) const <br />
{<br />
bool status = false;<br />
if ( id == propertyX ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyX, this->x ) );<br />
status = true;<br />
}<br />
else ( id == propertyY ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyY, this->y ) );<br />
status = true;<br />
}<br />
return status;<br />
}<br />
<br />
</pre></div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_CA_Interfaces&diff=184Talk:V4 CA Interfaces2005-05-20T19:22:50Z<p>JeffHill: </p>
<hr />
<div>Some comments from Andrew Johnson:<br />
<br />
In your presentation about CA V4, you included the method <br />
channel::createAllPropertiesReadRequest(). I agree that we need a way <br />
to be able to read all of the properties available from the server for a <br />
particular PV name, but I want more flexibility than just being able to <br />
put that wild-card at the top of my request.<br />
<br />
I think we need the ability to be able to subscribe with a property <br />
catalog having a specific set of properties at one level but to <br />
wild-card a sub-property catalog at some level below. Is this currently <br />
possible? If not, please consider this a request to add that <br />
capability, which might then remove the need for the seperate <br />
createAllPropertiesReadRequest() method. I'm only looking for you to <br />
support "*", no pattern matching or regex stuff.<br />
<br />
Some comments from Jeff Hill:<br />
<br />
During our meeting I raised a question; do we may need a Data Access interface allowing traversal of the structure of the property hierarchy, learning the native type of the properties, but not require instances of the properties?<br />
<br />
There may be legitimate situations where the property catalog egg must come before the property catalog chicken. Furthermore, it might be quite inconvenient from a memory management perspective to require an instance of an array before it is really used. I think that this negative could be perhaps minimized if we state in the CA manual that the array bounds alone will be examined, and the array elements will not be traversed, when scanning a property catalog to learn its structure.<br />
<br />
Probably the only negative associated with adding a property catalog structure traverse capability to the interface would be that the application would need to provide one additional function. They are already providing an immutable traverse, a mutable traverse function, and an immutable find function. What is vexing is that all three of the traverse functions are nearly identical. Personally, I don’t like to see common code managed with cut and paste. I am even less fond of that eventuality should it be repeated for many, many data structures in a proliferation of applications. <br />
<br />
So I had a look at what level of Data Access library support might be provided so that they need write the guts of the traverse function once. The following is an example of how they might structure their application. There are still three traverse functions because cross library binding requires the virtual base class interfaced technique, but now they can use a template to implement the traversing only once.<br />
<br />
This level of complication appears to be reasonable for end user applications. <br />
<br />
<pre><br />
<br />
PropertyId propertyX;<br />
PropertyId propertyY;<br />
PropertyId propertyZ;<br />
PropertyId propertyI;<br />
<br />
class MyContainer : private PropertyCatalog {<br />
public:<br />
<br />
private:<br />
int x;<br />
float y;<br />
double z;<br />
char i;<br />
static void traverse ( <br />
PropertyDescriptionViewer & );<br />
void traverse ( <br />
PropertyManipulator & );<br />
void traverse ( <br />
PropertyViewer & ) const;<br />
bool find ( <br />
const PropertyId & id, PropertyViewer & ) const;<br />
template < class REFERENCE, class MANIPULATOR ><br />
static void traverseTempl ( <br />
const REFERENCE &, MANIPULATOR & );<br />
};<br />
<br />
template < class REFERENCE, class MANIPULATOR ><br />
inline void MyContainer::traverseTempl ( <br />
const REFERENCE & ref, MANIPULATOR & manipulator )<br />
{<br />
ref.reveal ( <br />
manipulator, propertyX, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyY, & MyContainer::y );<br />
ref.reveal ( <br />
manipulator, propertyZ, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyI, & MyContainer::i );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyManipulator & manipulator ) <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < MyContainer > ( *this ), manipulator );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyViewer & viewer ) const <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < const MyContainer > ( *this ), viewer );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyDescriptionViewer & viewer )<br />
{<br />
MyContainer::traverseTempl ( reference < void > (), viewer );<br />
}<br />
<br />
bool MyContainer::find ( <br />
const PropertyId & id, <br />
PropertyManipulator < Property > & manipulator ) const <br />
{<br />
bool status = false;<br />
if ( id == propertyX ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyX, this->x ) );<br />
status = true;<br />
}<br />
else ( id == propertyY ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyY, this->y ) );<br />
status = true;<br />
}<br />
return status;<br />
}<br />
<br />
</pre></div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_CA_Interfaces&diff=183Talk:V4 CA Interfaces2005-05-20T19:21:18Z<p>JeffHill: </p>
<hr />
<div>Some comments from Andrew Johnson:<br />
<br />
In your presentation about CA V4, you included the method <br />
channel::createAllPropertiesReadRequest(). I agree that we need a way <br />
to be able to read all of the properties available from the server for a <br />
particular PV name, but I want more flexibility than just being able to <br />
put that wild-card at the top of my request.<br />
<br />
I think we need the ability to be able to subscribe with a property <br />
catalog having a specific set of properties at one level but to <br />
wild-card a sub-property catalog at some level below. Is this currently <br />
possible? If not, please consider this a request to add that <br />
capability, which might then remove the need for the seperate <br />
createAllPropertiesReadRequest() method. I'm only looking for you to <br />
support "*", no pattern matching or regex stuff.<br />
<br />
Some comments from Jeff Hill:<br />
<br />
During our meeting I raised a question; do we may need a Data Access interface allowing traversal of the structure of the property hierarchy, learning the native type of the properties, but not require instances of the properties?<br />
<br />
There may be legitimate situations where the property catalog egg must come before the property catalog chicken. Furthermore, it might be quite inconvenient from a memory management perspective to require an instance of an array before it is really used. I think that this negative could be perhaps minimized if we state in the CA manual that the array bounds alone will be examined, and the array elements will not be traversed, when scanning a property catalog to learn its structure.<br />
<br />
Probably the only negative associated with adding a property catalog structure traverse capability to the interface would be that the application would need to provide one additional function. They are already providing an immutable traverse, a mutable traverse function, and an immutable find function. What is vexing is that all three of the traverse functions are nearly identical. Personally, I don’t like to see common code managed with cut and paste. I am even less fond of that eventuality should it be repeated for many, many data structures in a proliferation of applications. <br />
<br />
So I had a look at what level of Data Access library support might be provided so that they need write the guts of the traverse function once. The following is an example of how they might structure their application. There are still three traverse functions because cross library binding requires the virtual base class interfaced technique, but now they can use a template to implement the traversing only once.<br />
<br />
This level of complication appears to be reasonable for end user applications. <br />
<br />
<pre><br />
<br />
PropertyId propertyX;<br />
PropertyId propertyY;<br />
PropertyId propertyZ;<br />
PropertyId propertyI;<br />
<br />
class MyContainer : private PropertyCatalog {<br />
public:<br />
<br />
private:<br />
int x;<br />
float y;<br />
double z;<br />
char i;<br />
static void traverse ( <br />
PropertyDescriptionViewer & );<br />
void traverse ( <br />
PropertyManipulator & );<br />
void traverse ( <br />
PropertyViewer & ) const;<br />
bool find ( <br />
const PropertyId & id, PropertyViewer & ) const;<br />
template < class REFERENCE, class MANIPULATOR ><br />
static void traverseTempl ( <br />
const REFERENCE &, MANIPULATOR & );<br />
};<br />
<br />
template < class REFERENCE, class MANIPULATOR ><br />
inline void MyContainer::traverseTempl ( <br />
const REFERENCE & ref, MANIPULATOR & manipulator )<br />
{<br />
ref.reveal ( <br />
manipulator, propertyX, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyY, & MyContainer::y );<br />
ref.reveal ( <br />
manipulator, propertyZ, & MyContainer::x );<br />
ref.reveal ( <br />
manipulator, propertyI, & MyContainer::i );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyManipulator & manipulator ) <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < MyContainer > ( *this ), manipulator );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyViewer & viewer ) const <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < const MyContainer > ( *this ), viewer );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyDescriptionViewer & viewer )<br />
{<br />
MyContainer::traverseTempl ( reference < void > (), viewer );<br />
}<br />
<br />
bool MyContainer::find ( <br />
const PropertyId & id, <br />
PropertyManipulator < Property > & manipulator ) const <br />
{<br />
bool status = false;<br />
if ( id == propertyX ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyX, this->x ) );<br />
status = true;<br />
}<br />
else ( id == propertyY ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyY, this->y ) );<br />
status = true;<br />
}<br />
return status;<br />
}<br />
<br />
</pre><br />
<br />
Here are the interface details.<br />
<br />
<pre><br />
<br />
class PropertyId;<br />
class ArraySegment;<br />
class StringSegment;<br />
class EnumStateSet;<br />
class PropertyCatalog;<br />
class PropertyCatalog;<br />
class Time;<br />
<br />
class PropertyId {<br />
};<br />
<br />
extern class PropertyCatalog & voidCatalog;<br />
<br />
class PropertyViewer {<br />
public:<br />
virtual void reveal ( const PropertyId &, <br />
const double &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
const int &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
const unsigned int &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
const long &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
const unsigned long &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
const Time &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
const StringSegment &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
const EnumStateSet & ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
const ArraySegment &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
const PropertyCatalog & ) = 0;<br />
};<br />
<br />
template < class T ><br />
class TypedVoid {<br />
};<br />
<br />
class PropertyDescriptionViewer {<br />
public:<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < float > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < double > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < char > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < signed char > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < unsigned char > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < short > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < unsigned short > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < int > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < unsigned int > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < long > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < unsigned long > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < Time > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < StringSegment > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < EnumStateSet > & ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < ArraySegment > &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
TypedVoid < PropertyCatalog > & ) = 0;<br />
};<br />
<br />
class PropertyManipulator {<br />
public:<br />
virtual void reveal ( const PropertyId &, <br />
float &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
double &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
char &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
signed char &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
unsigned char &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
short &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
unsigned short &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
int &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
unsigned int &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
long &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
unsigned long &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
Time &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
StringSegment &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
EnumStateSet & ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
ArraySegment &, const PropertyCatalog & = voidCatalog ) = 0;<br />
virtual void reveal ( const PropertyId &, <br />
PropertyCatalog & ) = 0;<br />
};<br />
<br />
class PropertyCatalog {<br />
public:<br />
virtual void traverse ( <br />
PropertyManipulator & ) = 0;<br />
virtual void traverse ( <br />
PropertyViewer & ) const = 0;<br />
// false returned when the property does not exist, otherwise true<br />
virtual bool find ( <br />
const PropertyId & id, PropertyViewer & ) const = 0;<br />
};<br />
<br />
// ----------------- void property catalog implementation ---------------------------<br />
<br />
class VoidContainer : public PropertyCatalog {<br />
void traverse ( <br />
PropertyManipulator & ) {}<br />
void traverse ( <br />
PropertyViewer & ) const {}<br />
// false returned when the property does not exist, otherwise true<br />
bool find ( <br />
const PropertyId & id, PropertyViewer & ) const <br />
{<br />
return false;<br />
}<br />
};<br />
<br />
VoidContainer aVoidContainer;<br />
class PropertyCatalog & voidCatalog = aVoidContainer;<br />
<br />
// --------------------------- begin reference implemenation --------------------------<br />
<br />
template < class T ><br />
class reference<br />
{<br />
public:<br />
reference ( T & ref ) : <br />
_ref ( ref ) <br />
{<br />
}<br />
template < class M ><br />
void reveal ( <br />
PropertyManipulator & manipulator,<br />
const PropertyId & id, M ( T :: * p ), <br />
PropertyCatalog & subordinates = voidCatalog ) const<br />
{<br />
manipulator.reveal (<br />
id, _ref.*p, subordinates );<br />
}<br />
private:<br />
T & _ref;<br />
};<br />
<br />
template < class T ><br />
class reference < const T ><br />
{<br />
public:<br />
reference ( const T & ref ) : <br />
_ref ( ref ) <br />
{<br />
}<br />
template < class M ><br />
void reveal ( <br />
PropertyViewer & viewer,<br />
const PropertyId & id, M ( T :: * p ), <br />
const PropertyCatalog & subordinates = voidCatalog ) const<br />
{<br />
viewer.reveal (<br />
id, _ref.*p, subordinates );<br />
}<br />
private:<br />
const T & _ref;<br />
};<br />
<br />
template <><br />
class reference < void ><br />
{<br />
public:<br />
template < class T, class M ><br />
void reveal ( <br />
PropertyDescriptionViewer & viewer,<br />
const PropertyId & id, M ( T :: * p ), <br />
const PropertyCatalog & subordinates = voidCatalog ) const<br />
{<br />
viewer.reveal (<br />
id, TypedVoid < M > (), subordinates );<br />
}<br />
};<br />
<br />
</pre></div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_CA_Interfaces&diff=182Talk:V4 CA Interfaces2005-05-20T17:01:21Z<p>JeffHill: </p>
<hr />
<div>Some comments from Andrew Johnson:<br />
<br />
In your presentation about CA V4, you included the method <br />
channel::createAllPropertiesReadRequest(). I agree that we need a way <br />
to be able to read all of the properties available from the server for a <br />
particular PV name, but I want more flexibility than just being able to <br />
put that wild-card at the top of my request.<br />
<br />
I think we need the ability to be able to subscribe with a property <br />
catalog having a specific set of properties at one level but to <br />
wild-card a sub-property catalog at some level below. Is this currently <br />
possible? If not, please consider this a request to add that <br />
capability, which might then remove the need for the seperate <br />
createAllPropertiesReadRequest() method. I'm only looking for you to <br />
support "*", no pattern matching or regex stuff.<br />
<br />
<br />
Some comments from Jeff Hill:<br />
<br />
During our meeting I raised a question; do we may need a Data Access interface allowing traversal of the structure of the property hierarchy, learning the native type of the properties, but not require instances of the properties?<br />
<br />
There may be legitimate situations where the property catalog egg must come before the property catalog chicken. Furthermore, it might be quite inconvenient from a memory management perspective to require an instance of an array before it is really used. I think that this negative could be perhaps minimized if we state in the CA manual that the array bounds alone will be examined, and the array elements will not be traversed, when scanning a property catalog to learn its structure.<br />
<br />
Probably the only negative associated with adding a property catalog structure traverse capability to the interface would be that the application would need to provide one additional function. They are already providing an immutable traverse, a mutable traverse function, and an immutable find function. What is not really right is that all three of the traverse functions are nearly identical. Personally, I don’t like to see common code managed with cut and paste.<br />
<br />
So I had a look at what level of Data Access library support might be provided so that they might avoid needing to write three traverse functions. The following is an example of how they might structure their application. This level of complication appears to be reasonable for end user applications. <br />
<br />
PropertyId propertyX;<br />
PropertyId propertyY;<br />
<br />
class MyContainer : <br />
private PropertyCatalog {<br />
int x;<br />
float y;<br />
static void traverse ( <br />
PropertyDescriptionViewer & );<br />
void traverse ( <br />
PropertyManipulator & );<br />
void traverse ( <br />
PropertyViewer & ) const;<br />
bool find ( <br />
const PropertyId & id, PropertyViewer & ) const;<br />
template < class REFERENCE, class MANIPULATOR ><br />
static void traverseTempl ( <br />
const REFERENCE &, MANIPULATOR & );<br />
};<br />
<br />
template < class REFERENCE, class MANIPULATOR ><br />
void MyContainer::traverseTempl ( <br />
const REFERENCE & ref, MANIPULATOR & manipulator )<br />
{<br />
manipulator.reveal ( <br />
ref.propertyFactory ( propertyX, & MyContainer::x ) );<br />
manipulator.reveal ( <br />
ref.propertyFactory ( propertyY, & MyContainer::y ) );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyManipulator & manipulator ) <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < MyContainer > ( *this ), manipulator );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyViewer & viewer ) const <br />
{<br />
MyContainer::traverseTempl ( <br />
reference < const MyContainer > ( *this ), viewer );<br />
}<br />
<br />
void MyContainer::traverse ( <br />
PropertyDescriptionViewer & viewer )<br />
{<br />
MyContainer::traverseTempl ( reference < void > (), viewer );<br />
}<br />
<br />
bool MyContainer::find ( <br />
const PropertyId & id, <br />
PropertyManipulator < Property > & manipulator ) const <br />
{<br />
bool status = false;<br />
if ( id == propertyX ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyX, this->x ) );<br />
status = true;<br />
}<br />
else ( id == propertyY ) {<br />
manipulator.reveal ( <br />
Property < const int > ( propertyY, this->y ) );<br />
status = true;<br />
}<br />
return status;<br />
}<br />
<br />
Here is a summary of the changes:<br />
* A new "static void traverse ( PropertyDescriptionViewer & );" in the application. This interface might be bound at run time with an ordinary function pointer, and not bound through a pure virtual base. Since data description is accessed through a static member function then ordinary function pointers appear to be a plausible way to bind to this interface. There may not be justification to juxtapose an additional layer of overhead for a virtual interface. That might be necessary only if there was more than one function of this type.<br />
<br />
* To allow all three traverse functions to be implemented with a template the properties are revealed using three new property handle types corresponding to the three types of traversal supported. <br />
<br />
Here are the slightly revised Data Access interfaces. <br />
<br />
enum propertyHandleType {<br />
phMutable,<br />
phImmutable,<br />
phDescription<br />
};<br />
<br />
template < propertyHandleType PHT, class T > <br />
class PropertyHandle;<br />
<br />
template < class T > <br />
class PropertyHandle < phMutable, T > {<br />
public:<br />
PropertyHandle ( <br />
const PropertyId & id, T & value, <br />
PropertyCatalog & subordinate = voidContainer );<br />
T & value () const;<br />
const PropertyId & id () const;<br />
PropertyCatalog & subordinate () const;<br />
private:<br />
T & _scalar;<br />
const PropertyId & _id;<br />
PropertyCatalog & _subordinateProperties;<br />
};<br />
<br />
template < class T > <br />
class PropertyHandle < phImmutable, T > {<br />
public:<br />
PropertyHandle ( <br />
const PropertyId & id, const T & value, <br />
const PropertyCatalog & subordinate = voidContainer );<br />
const T & value () const;<br />
const PropertyId & id () const;<br />
const PropertyCatalog & subordinate () const;<br />
private:<br />
const T & _scalar;<br />
const PropertyId & _id;<br />
const PropertyCatalog & _subordinateProperties;<br />
};<br />
<br />
template < class T > <br />
class PropertyHandle < phDescription, T > {<br />
public:<br />
PropertyHandle ( const PropertyId & id, <br />
const PropertyCatalog & = voidContainer );<br />
const PropertyId & id () const;<br />
const PropertyCatalog & subordinate () const;<br />
private:<br />
const PropertyId & _id;<br />
const PropertyCatalog & _subordinateProperties;<br />
};<br />
<br />
template < <br />
propertyHandleType PHT, <br />
template < propertyHandleType PHT, class T > class PROP_HANDLE ><br />
class PropertyManipulatorBase {<br />
public:<br />
virtual void reveal ( const PROP_HANDLE < PHT, float > & ) = 0;<br />
virtual void reveal ( const PROP_HANDLE < PHT, double > & ) = 0;<br />
virtual void reveal ( const PROP_HANDLE < PHT, char > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, signed char > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, unsigned char > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, short > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, unsigned short > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, int > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, unsigned int > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, long > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, unsigned long > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, Time > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, StringSegment > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, EnumStateSet > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, ArraySegment > & ) = 0; <br />
virtual void reveal ( const PROP_HANDLE < PHT, PropertyCatalog > & ) = 0; <br />
};<br />
<br />
class PropertyManipulator :<br />
public PropertyManipulatorBase < phMutable, PropertyHandle > {<br />
};<br />
<br />
class PropertyViewer :<br />
public PropertyManipulatorBase < phImmutable, PropertyHandle > {<br />
};<br />
<br />
class PropertyDescriptionViewer :<br />
public PropertyManipulatorBase < phDescription, PropertyHandle > {<br />
};<br />
<br />
class PropertyCatalog {<br />
public:<br />
virtual void traverse ( <br />
PropertyManipulator & ) = 0;<br />
virtual void traverse ( <br />
PropertyViewer & ) const = 0;<br />
// false returned when the property does not exist, otherwise true<br />
virtual bool find ( <br />
const PropertyId & id, PropertyViewer & ) const = 0;<br />
};</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=User:JeffHill&diff=2729User:JeffHill2005-05-17T17:46:45Z<p>JeffHill: </p>
<hr />
<div>[[V4_CA_Interfaces]]</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_CA_Interfaces&diff=147Talk:V4 CA Interfaces2005-05-17T17:32:52Z<p>JeffHill: </p>
<hr />
<div>From Andrew Johnson:<br />
<br />
In your presentation about CA V4, you included the method <br />
channel::createAllPropertiesReadRequest(). I agree that we need a way <br />
to be able to read all of the properties available from the server for a <br />
particular PV name, but I want more flexibility than just being able to <br />
put that wild-cared at the top of my request.<br />
<br />
I think we need the ability to be able to subscribe with a property <br />
catalog having a specific set of properties at the top level but to <br />
wild-card a sub-property catalog at the level below. Is this currently <br />
possible? If not, please consider this a request to add that <br />
capability, which might then remove the need for the seperate <br />
createAllPropertiesReadRequest() method. I'm only looking for you to <br />
support "*", no pattern matching or regex stuff.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Standard_Properties_and_Events&diff=2727Talk:V4 Standard Properties and Events2005-05-17T17:14:09Z<p>JeffHill: </p>
<hr />
<div># I think that it is important from the start to clearly define the timestamp, alarmSeverity, alarmStatus, units etc to be subordinates of the value property. Therefore they would be one level further down in the hierarchy. Specifically, if value is 1.1 then timestamp should be 1.1.1 and alarmSeverity should be 1.1.2 etc. Same thing with bullet delineated lists - the value property might be further over to the left and things below it should be on tab stop to the right. This approach allows multiple values to be in the same record. For example, we might have an "xPosition" and a "yPosition". The paradigm where the limits and the value are at the same level in the hierarchy fits from a C programmers perspective because that is how one tends to make u p structures, but it tends to break down when designing external interfaces for the system. For example, one might have a single property named "xPosition" that is a double. Later, when adding limits for "xPosition", a backwards incompatible property hierarchy change has to occur when this double is changed to an "xPosition" container that has a double in it who's property name is "value". <br />
# Hopefully, we can avoid having to place "value", which does not convey any additional meaning, in any V4 channel name. For example we might have channel names like the following.<br />
#* single value channel names<br />
#** analogDevice10<br />
#** analogDevice10/timestamp<br />
#** analogDevice10/diplayLimits/high<br />
#* dual value channel names<br />
#** axisDevice10/xPosition<br />
#** axisDevice10/yPosition<br />
#** axisDevice10/xPosition/timestamp<br />
#** axisDevice10/xPosition/diplayLimits/high<br />
#*Should a user supply any of the following channel names they would not find a matching service to connect to (hopefully there would be an error message identifying the available choices when they specify a leaf missing from the hierarchy).<br />
#** axisDevice10<br />
#** axisDevice10/timestamp<br />
# Perhaps we should use "." (a dot) only for backwards compatibility and use a "/" (slash) to denote 4.0 hierarchy? For example a CA channel name might look like "myChannel/timeStamp", "myChannel/xPosition/diplayLimits/high", or "myChannel.HOPR". Just thinking out loud here.<br />
# I'm not sure how hierarchies of properties interact with this concept of a view. I see that a view is intended to be a very general approach with the option for an application specific plug in interpreting the view parameters so I should probably wait to see what you will define in the doc later. Nevertheless, I am still wondering if you will allow hierarchy in the channel name prior to specifying the view for the end leaf?<br />
# The need for a list of fields appears to be driven by (A) backwards compatibility (see comment about "." above) and (B) the need to have an unambiguous list of all properties necessary to maintain a backup of the state of a record with the option of restoring it later. Related to (B) I certainly do understand the issue that portions of the records state could show up multiple times in the generalized property hierarchy. A negative related to placing the concept of fields in public interfaces is of course additional complexity and with complexity confusion, potential for code bloat, and training class bloat. Perhaps one solution would be to add a capability to make an "all properties read" request that is further constrained to send internal state only once, and thereby eliminate leaves in the property hierarchy that might be redundant when expressing the internal state. Just thinking out loud again here.<br />
# It might be best to avoid more than four properties at any given level in the hierarchy. There can be important performance advantages associated with that organization from a dataAccess interfacing perspective, and perhaps this will make the code, and documentation, more modular as well.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Standard_Properties_and_Events&diff=136Talk:V4 Standard Properties and Events2005-05-17T17:10:42Z<p>JeffHill: </p>
<hr />
<div># I think that it is important from the start to clearly define the timestamp, alarmSeverity, alarmStatus, units etc to be subordinates of the value property. Therefore they would be one level further down in the hierarchy. Specifically, if value is 1.1 then timestamp should be 1.1.1 and alarmSeverity should be 1.1.2 etc. Same thing with bullet delineated lists - the value property might be further over to the left and things below it should be on tab stop to the right. This approach allows multiple values to be in the same record. For example, we might have an "xPosition" and a "yPosition". The paradigm where the limits and the value are at the same level in the hierarchy fits from a C programmers perspective because that is how one tends to make u p structures, but it tends to break down when designing external interfaces for the system. For example, one might have a single property named "xPosition" that is a double. Later, when adding limits for "xPosition", a backwards incompatible property hierarchy change has to occur when this double is changed to an "xPosition" container that has a double in it who's property name is "value". <br />
# Hopefully, we can avoid having to place "value", which does not convey any additional meaning, in any V4 channel name. For example we might have channel names like the following.<br />
* single value channel names<br />
** analogDevice10<br />
** analogDevice10/timestamp<br />
** analogDevice10/diplayLimits/high<br />
* dual value channel names<br />
** axisDevice10/xPosition<br />
** axisDevice10/yPosition<br />
** axisDevice10/xPosition/timestamp<br />
** axisDevice10/xPosition/diplayLimits/high<br />
*Should a user supply any of the following channel names they would not find a matching service to connect to (hopefully there would be an error message identifying the available choices when they specify a leaf missing from the hierarchy).<br />
** axisDevice10<br />
** axisDevice10/timestamp<br />
# Perhaps we should use "." (a dot) only for backwards compatibility and use a "/" (slash) to denote 4.0 hierarchy? For example a CA channel name might look like "myChannel/timeStamp", "myChannel/xPosition/diplayLimits/high", or "myChannel.HOPR". Just thinking out loud here.<br />
# I'm not sure how hierarchies of properties interact with this concept of a view. I see that a view is intended to be a very general approach with the option for an application specific plug in interpreting the view parameters so I should probably wait to see what you will define in the doc later. Nevertheless, I am still wondering if you will allow hierarchy in the channel name prior to specifying the view for the end leaf?<br />
# The need for a list of fields appears to be driven by (A) backwards compatibility (see comment about "." above) and (B) the need to have an unambiguous list of all properties necessary to maintain a backup of the state of a record with the option of restoring it later. Related to (B) I certainly do understand the issue that portions of the records state could show up multiple times in the generalized property hierarchy. A negative related to placing the concept of fields in public interfaces is of course additional complexity and with complexity confusion, potential for code bloat, and training class bloat. Perhaps one solution would be to add a capability to make an "all properties read" request that is further constrained to send internal state only once, and thereby eliminate leaves in the property hierarchy that might be redundant when expressing the internal state. Just thinking out loud again here.<br />
# It might be best to avoid more than four properties at any given level in the hierarchy. There can be important performance advantages associated with that organization from a dataAccess interfacing perspective, and perhaps this will make the code, and documentation, more modular as well.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Standard_Properties_and_Events&diff=135Talk:V4 Standard Properties and Events2005-05-17T17:00:56Z<p>JeffHill: </p>
<hr />
<div>1) I think that it is important from the start to clearly define the timestamp, alarmSeverity, alarmStatus, units etc to be subordinates of the value property. Therefore they would be one level further down in the hierarchy. Specifically, if value is 1.1 then timestamp should be 1.1.1 and alarmSeverity should be 1.1.2 etc. Same thing with bullet delineated lists - the value property might be further over to the left and things below it should be on tab stop to the right. This approach allows multiple values to be in the same record. For example, we might have an "xPosition" and a "yPosition". The paradigm where the limits and the value are at the same level in the hierarchy fits from a C programmers perspective because that is how one tends to make u p structures, but it tends to break down when designing external interfaces for the system. For example, one might have a single property named "xPosition" that is a double. Later, when adding limits for "xPosition", a backwards incompatible property hierarchy change has to occur when this double is changed to an "xPosition" container that has a double in it who's property name is "value". <br />
<br />
2) Hopefully, we can avoid having to place "value", which does not convey any additional meaning, in any V4 channel name. For example we might have channel names like <br />
<br />
* analogDevice10<br />
* analogDevice10/timestamp<br />
* analogDevice10/diplayLimits/high<br />
<br />
* axisDevice10/xPosition<br />
* axisDevice10/xPosition/timestamp<br />
* axisDevice10/xPosition/diplayLimits/high<br />
<br />
Should a user supply any of the following channel names they would not find a matching service to connect to (hopefully there would be an error message identifying the available choices when they specify a leaf missing from the hierarchy).<br />
<br />
* axisDevice10<br />
* axisDevice10/timestamp<br />
<br />
3) Perhaps we should use "." (a dot) only for backwards compatibility and use a "/" (slash) to denote 4.0 hierarchy? For example a CA channel name might look like "myChannel/timeStamp", "myChannel/xPosition/diplayLimits/high", or "myChannel.HOPR". Just thinking out loud here.<br />
<br />
4) I'm not sure how hierarchies of properties interact with this concept of a view. I see that a view is intended to be a very general approach with the option for an application specific plug in interpreting the view parameters so I should probably wait to see what you will define in the doc later. Nevertheless, I am still wondering if you will allow hierarchy in the channel name prior to specifying the view for the end leaf?<br />
<br />
4) The need for a list of fields appears to be driven by (A) backwards compatibility (see comment about "." above) and (B) the need to have an unambiguous list of all properties necessary to maintain a backup of the state of a record with the option of restoring it later. Related to (B) I certainly do understand the issue that portions of the records state could show up multiple times in the generalized property hierarchy. A negative related to placing the concept of fields in public interfaces is of course additional complexity and with complexity confusion, potential for code bloat, and training class bloat. Perhaps one solution would be to add a capability to make an "all properties read" request that is further constrained to send internal state only once, and thereby eliminate leaves in the property hierarchy that might be redundant when expressing the internal state. Just thinking out loud again here.<br />
<br />
5) It might be best to avoid more than four properties at any given level in the hierarchy. There can be important performance advantages associated with that organization from a dataAccess interfacing perspective, and perhaps this will make the code, and documentation, more modular as well.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Talk:V4_Standard_Properties_and_Events&diff=134Talk:V4 Standard Properties and Events2005-05-17T16:56:30Z<p>JeffHill: </p>
<hr />
<div>1) I think that it is important from the start to clearly define the timestamp, alarmSeverity, alarmStatus, units etc to be subordinates of the value property. Therefore they would be one level further down in the hierarchy. Specifically, if value is 1.1 then timestamp should be 1.1.1 and alarmSeverity should be 1.1.2 etc. Same thing with bullet delineated lists - the value property might be further over to the left and things below it should be on tab stop to the right. This approach allows multiple values to be in the same record. For example, we might have an "xPosition" and a "yPosition". The paradigm where the limits and the value are at the same level in the hierarchy fits from a C programmers perspective because that is how one tends to make u p structures, but it tends to break down when designing external interfaces for the system. For example, one might have a single property named "xPosition" that is a double. Later, when adding limits for "xPosition", a backwards incompatible property hierarchy change has to occur when this double is changed to an "xPosition" container that has a double in it who's property name is "value". <br />
<br />
2) Hopefully, we can avoid having to place "value", which does not convey any additional meaning, in any V4 channel name. For example we might have channel names like <br />
<br />
analogDevice10<br />
analogDevice10/timestamp<br />
analogDevice10/diplayLimits/high<br />
<br />
axisDevice10/xPosition<br />
axisDevice10/xPosition/timestamp<br />
axisDevice10/xPosition/diplayLimits/high<br />
<br />
Should a user supply any of the following channel names they would not find a matching service to connect to (hopefully there would be an error message identifying the available choices when they specify a leaf missing from the hierarchy).<br />
<br />
axisDevice10<br />
axisDevice10/timestamp<br />
<br />
3) Perhaps we should use "." (a dot) only for backwards compatibility and use a "/" (slash) to denote 4.0 hierarchy? For example a CA channel name might look like "myChannel/timeStamp", "myChannel/xPosition/diplayLimits/high", or "myChannel.HOPR". Just thinking out loud here.<br />
<br />
4) I'm not sure how hierarchies of properties interact with this concept of a view. I see that a view is intended to be a very general approach with the option for an application specific plug in interpreting the view parameters so I should probably wait to see what you will define in the doc later. Nevertheless, I am still wondering if you will allow hierarchy in the channel name prior to specifying the view for the end leaf?<br />
<br />
4) The need for a list of fields appears to be driven by (A) backwards compatibility (see comment about "." above) and (B) the need to have an unambiguous list of all properties necessary to maintain a backup of the state of a record with the option of restoring it later. Related to (B) I certainly do understand the issue that portions of the records state could show up multiple times in the generalized property hierarchy. A negative related to placing the concept of fields in public interfaces is of course additional complexity and with complexity confusion, potential for code bloat, and training class bloat. Perhaps one solution would be to add a capability to make an "all properties read" request that is further constrained to send internal state only once, and thereby eliminate leaves in the property hierarchy that might be redundant when expressing the internal state. Just thinking out loud again here.<br />
<br />
5) It might be best to avoid more than four properties at any given level in the hierarchy. There can be important performance advantages associated with that organization from a dataAccess interfacing perspective, and perhaps this will make the code, and documentation, more modular as well.</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Evolution_of_EPICS_Core&diff=1348Evolution of EPICS Core2005-05-10T23:56:49Z<p>JeffHill: /* '''V???? – Avccess Security Upgrades''' */</p>
<hr />
<div>== '''V4 – Executive Summary''' ==<br />
*Provide online add/delete of I/O to support continuous operation.<br />
*Provide redundant control of remote I/O to support improved reliability.<br />
*Provide name introspection and domain control in support of seamless *integration of large control systems<br />
*Provide triggers, filters, and rate limits to improve resource use of network and client side processing<br />
*Provide hierarchical devices to support higher level view of application in the front-end processors.<br />
*Provide automatic backup and restore to support bump-less reboot and synchronization of redundant controllers.<br />
*Provide atomic read, write, and write with read-back to multiple channels to support synchronized access of arbitrary sets of channels.<br />
*Support international users with uni-code and time.<br />
*Remove limitations on string lengths, device states, number of input links to support arbitrary sizes.<br />
*Internationalize Time Stamps<br />
<br />
== '''V4 – Structure and Array Support''' ==<br />
*Allows definition and access to complex devices and multi-dimensional arrays<br />
*Name hierarchy in Channel Access<br />
**<arbitrary string>.structure. Element[n]<br />
**e.g. Arc3PwrSupply.readback.status, ArcPwrSupply.readback.value<br />
*Device description in database<br />
*Support arbitrary number of inputs to calculations and subroutines.<br />
*Support multi-state devices of an arbitrary number of states<br />
<br />
== '''V4 – Data Acquisition Capabilities''' ==<br />
*New subscription parameters<br />
**Rate limit<br />
**Value changes (as before but also % change)<br />
**Triggers<br />
**Filters<br />
**Examples<br />
**Send BPM at 1 Hz (where 1 Hz across IOCs is the same)<br />
**Send BPM when trigger specifies that this pulse is e-<br />
**Send RF reading when filter says that vacuum is higher than 10e-6 torr<br />
*Allows more accurate requests for data on client applications <br />
*Reduces the amount of network and client CPU usage<br />
*Specify priority for circuit - QOS<br />
<br />
== '''V4 – Device Read/Write Operations''' ==<br />
*Allows multiple fields to be read/written as an atomic operation <br />
*Reads/Writes can be triggered<br />
**e.g. Put( Corr1.K, Corr2.K, Corr3.K, on trigger event)<br />
**All puts take place when the trigger event occurs<br />
*Write with return data support (Command/Response)<br />
*Ramping/arb function outputs – given two end points<br />
<br />
== '''V4 – Name Resolution Extensions''' ==<br />
*Allow wildcard searches <br />
*Allow request to send all names supported in the IOC<br />
*Support redundancy by allowing connections to specify that they are not active<br />
*Support multiple name servers by allowing connections to specify how close to the source they are.<br />
*Name aliasing supported.<br />
<br />
== '''V4 – Online Add / Delete''' ==<br />
*Support hardware address change during operation <br />
*Allow new record instances to be loaded at any time<br />
*Support addition of hardware of an already supported type (64x)<br />
*Support addition of new hardware during operation.<br />
*Remove records during operation.<br />
<br />
== '''V4 – Redundancy: Multiple masters of remote I/O''' ==<br />
*Support name responses from multiple controllers of the same database.<br />
*Support request for all fields from a primary database to its backup.<br />
*Support a request for all fields that have changed since the last synchronization of the backup to the primary.<br />
*Support a mechanism for switching from the primary to the backup.<br />
*Provide a mechanism for synchronizing primary and the backup.<br />
*Support multiple communication paths that provide<br />
**an isolated network for synchronization traffic<br />
**redundant checks to synchronize switch over behavior.<br />
*Provide a mechanism to start/stop scanning<br />
*Provide a mechanism to start/stop sequences<br />
*Provide a mechanism to start/stop drivers from scanning<br />
<br />
== '''V4 – Support Large / Multi-segmented Control System''' ==<br />
*Support load balancing between multiple data sources (1st order gateway, 2nd order gateway, IOC, and load).<br />
*Support domain control independent of network topology<br />
**Beamline data is not available to the control room<br />
**Only insertion gap and beam quality information is available to the beamline controls from the ring control room.<br />
<br />
=='''V4 – Extendable Metadata / Properties''' ==<br />
*Metadata can be extendable –<br />
**Add array dimensions<br />
**Add time base to an array<br />
**Application programmers can add metadata<br />
*Specify metadata by field rather than record<br />
**Only get metadata when it is meaningful<br />
**No display limits for the high display limit<br />
*Calc and subroutine records have arrays of inputs<br />
**No limit to the number of variables<br />
<br />
=='''V4 – Channel Access Diagnostics'''==<br />
*Server Diagnostics<br />
**Connections<br />
**Channels<br />
**Events per second<br />
**State of Health<br />
**Beacon Periodicity<br />
**Etc…<br />
*Client Diagnostics<br />
**Number of connections/server per client<br />
**Number of channels<br />
**Events per second<br />
**State of connection<br />
**Etc…..<br />
<br />
=='''V4 – Limitations Remediation'''==<br />
*Multi-line text <br />
*Variable length strings<br />
**Removes current limitations of 40 characters<br />
**Reduces size of memory use in most cases<br />
**Reduces network traffic in most cases<br />
*Unicode<br />
**Support alternate character sets<br />
*Multidimensional arrays<br />
*Variable size arrays<br />
<br />
=='''V4 – Time Stamp Internationalization'''==<br />
*Support ISO 8601 Format<br />
**Year-month-date-hours-minutes-seconds-fractional seconds<br />
**Country specific time stamps<br />
*Support Locale Settings for conversions<br />
**,02 as 2 hundreds of a second<br />
<br />
=='''V???? – Access Security Upgrades'''==<br />
*Kerberos style authentication<br />
*User specific CA client resource consumption quotas in access security system<br />
*Confirmation requested hint (no mods w/o poping an are-you-sure dialog box)</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Evolution_of_EPICS_Core&diff=76Evolution of EPICS Core2005-05-10T23:55:04Z<p>JeffHill: /* '''V???? – Resource Consumption Quotas''' */</p>
<hr />
<div>== '''V4 – Executive Summary''' ==<br />
*Provide online add/delete of I/O to support continuous operation.<br />
*Provide redundant control of remote I/O to support improved reliability.<br />
*Provide name introspection and domain control in support of seamless *integration of large control systems<br />
*Provide triggers, filters, and rate limits to improve resource use of network and client side processing<br />
*Provide hierarchical devices to support higher level view of application in the front-end processors.<br />
*Provide automatic backup and restore to support bump-less reboot and synchronization of redundant controllers.<br />
*Provide atomic read, write, and write with read-back to multiple channels to support synchronized access of arbitrary sets of channels.<br />
*Support international users with uni-code and time.<br />
*Remove limitations on string lengths, device states, number of input links to support arbitrary sizes.<br />
*Internationalize Time Stamps<br />
<br />
== '''V4 – Structure and Array Support''' ==<br />
*Allows definition and access to complex devices and multi-dimensional arrays<br />
*Name hierarchy in Channel Access<br />
**<arbitrary string>.structure. Element[n]<br />
**e.g. Arc3PwrSupply.readback.status, ArcPwrSupply.readback.value<br />
*Device description in database<br />
*Support arbitrary number of inputs to calculations and subroutines.<br />
*Support multi-state devices of an arbitrary number of states<br />
<br />
== '''V4 – Data Acquisition Capabilities''' ==<br />
*New subscription parameters<br />
**Rate limit<br />
**Value changes (as before but also % change)<br />
**Triggers<br />
**Filters<br />
**Examples<br />
**Send BPM at 1 Hz (where 1 Hz across IOCs is the same)<br />
**Send BPM when trigger specifies that this pulse is e-<br />
**Send RF reading when filter says that vacuum is higher than 10e-6 torr<br />
*Allows more accurate requests for data on client applications <br />
*Reduces the amount of network and client CPU usage<br />
*Specify priority for circuit - QOS<br />
<br />
== '''V4 – Device Read/Write Operations''' ==<br />
*Allows multiple fields to be read/written as an atomic operation <br />
*Reads/Writes can be triggered<br />
**e.g. Put( Corr1.K, Corr2.K, Corr3.K, on trigger event)<br />
**All puts take place when the trigger event occurs<br />
*Write with return data support (Command/Response)<br />
*Ramping/arb function outputs – given two end points<br />
<br />
== '''V4 – Name Resolution Extensions''' ==<br />
*Allow wildcard searches <br />
*Allow request to send all names supported in the IOC<br />
*Support redundancy by allowing connections to specify that they are not active<br />
*Support multiple name servers by allowing connections to specify how close to the source they are.<br />
*Name aliasing supported.<br />
<br />
== '''V4 – Online Add / Delete''' ==<br />
*Support hardware address change during operation <br />
*Allow new record instances to be loaded at any time<br />
*Support addition of hardware of an already supported type (64x)<br />
*Support addition of new hardware during operation.<br />
*Remove records during operation.<br />
<br />
== '''V4 – Redundancy: Multiple masters of remote I/O''' ==<br />
*Support name responses from multiple controllers of the same database.<br />
*Support request for all fields from a primary database to its backup.<br />
*Support a request for all fields that have changed since the last synchronization of the backup to the primary.<br />
*Support a mechanism for switching from the primary to the backup.<br />
*Provide a mechanism for synchronizing primary and the backup.<br />
*Support multiple communication paths that provide<br />
**an isolated network for synchronization traffic<br />
**redundant checks to synchronize switch over behavior.<br />
*Provide a mechanism to start/stop scanning<br />
*Provide a mechanism to start/stop sequences<br />
*Provide a mechanism to start/stop drivers from scanning<br />
<br />
== '''V4 – Support Large / Multi-segmented Control System''' ==<br />
*Support load balancing between multiple data sources (1st order gateway, 2nd order gateway, IOC, and load).<br />
*Support domain control independent of network topology<br />
**Beamline data is not available to the control room<br />
**Only insertion gap and beam quality information is available to the beamline controls from the ring control room.<br />
<br />
=='''V4 – Extendable Metadata / Properties''' ==<br />
*Metadata can be extendable –<br />
**Add array dimensions<br />
**Add time base to an array<br />
**Application programmers can add metadata<br />
*Specify metadata by field rather than record<br />
**Only get metadata when it is meaningful<br />
**No display limits for the high display limit<br />
*Calc and subroutine records have arrays of inputs<br />
**No limit to the number of variables<br />
<br />
=='''V4 – Channel Access Diagnostics'''==<br />
*Server Diagnostics<br />
**Connections<br />
**Channels<br />
**Events per second<br />
**State of Health<br />
**Beacon Periodicity<br />
**Etc…<br />
*Client Diagnostics<br />
**Number of connections/server per client<br />
**Number of channels<br />
**Events per second<br />
**State of connection<br />
**Etc…..<br />
<br />
=='''V4 – Limitations Remediation'''==<br />
*Multi-line text <br />
*Variable length strings<br />
**Removes current limitations of 40 characters<br />
**Reduces size of memory use in most cases<br />
**Reduces network traffic in most cases<br />
*Unicode<br />
**Support alternate character sets<br />
*Multidimensional arrays<br />
*Variable size arrays<br />
<br />
=='''V4 – Time Stamp Internationalization'''==<br />
*Support ISO 8601 Format<br />
**Year-month-date-hours-minutes-seconds-fractional seconds<br />
**Country specific time stamps<br />
*Support Locale Settings for conversions<br />
**,02 as 2 hundreds of a second<br />
<br />
=='''V???? – Avccess Security Upgrades'''==<br />
*Kerberos style authentication<br />
*User specific CA client resource consumption quotas in access security system<br />
*Confirmation requested hint (no mods w/o poping an are-you-sure dialog box)</div>JeffHillhttps://wiki-ext.aps.anl.gov/epics/index.php?title=Evolution_of_EPICS_Core&diff=75Evolution of EPICS Core2005-05-10T23:25:50Z<p>JeffHill: </p>
<hr />
<div>== '''V4 – Executive Summary''' ==<br />
*Provide online add/delete of I/O to support continuous operation.<br />
*Provide redundant control of remote I/O to support improved reliability.<br />
*Provide name introspection and domain control in support of seamless *integration of large control systems<br />
*Provide triggers, filters, and rate limits to improve resource use of network and client side processing<br />
*Provide hierarchical devices to support higher level view of application in the front-end processors.<br />
*Provide automatic backup and restore to support bump-less reboot and synchronization of redundant controllers.<br />
*Provide atomic read, write, and write with read-back to multiple channels to support synchronized access of arbitrary sets of channels.<br />
*Support international users with uni-code and time.<br />
*Remove limitations on string lengths, device states, number of input links to support arbitrary sizes.<br />
*Internationalize Time Stamps<br />
<br />
== '''V4 – Structure and Array Support''' ==<br />
*Allows definition and access to complex devices and multi-dimensional arrays<br />
*Name hierarchy in Channel Access<br />
**<arbitrary string>.structure. Element[n]<br />
**e.g. Arc3PwrSupply.readback.status, ArcPwrSupply.readback.value<br />
*Device description in database<br />
*Support arbitrary number of inputs to calculations and subroutines.<br />
*Support multi-state devices of an arbitrary number of states<br />
<br />
== '''V4 – Data Acquisition Capabilities''' ==<br />
*New subscription parameters<br />
**Rate limit<br />
**Value changes (as before but also % change)<br />
**Triggers<br />
**Filters<br />
**Examples<br />
**Send BPM at 1 Hz (where 1 Hz across IOCs is the same)<br />
**Send BPM when trigger specifies that this pulse is e-<br />
**Send RF reading when filter says that vacuum is higher than 10e-6 torr<br />
*Allows more accurate requests for data on client applications <br />
*Reduces the amount of network and client CPU usage<br />
*Specify priority for circuit - QOS<br />
<br />
== '''V4 – Device Read/Write Operations''' ==<br />
*Allows multiple fields to be read/written as an atomic operation <br />
*Reads/Writes can be triggered<br />
**e.g. Put( Corr1.K, Corr2.K, Corr3.K, on trigger event)<br />
**All puts take place when the trigger event occurs<br />
*Write with return data support (Command/Response)<br />
*Ramping/arb function outputs – given two end points<br />
<br />
== '''V4 – Name Resolution Extensions''' ==<br />
*Allow wildcard searches <br />
*Allow request to send all names supported in the IOC<br />
*Support redundancy by allowing connections to specify that they are not active<br />
*Support multiple name servers by allowing connections to specify how close to the source they are.<br />
*Name aliasing supported.<br />
<br />
== '''V4 – Online Add / Delete''' ==<br />
*Support hardware address change during operation <br />
*Allow new record instances to be loaded at any time<br />
*Support addition of hardware of an already supported type (64x)<br />
*Support addition of new hardware during operation.<br />
*Remove records during operation.<br />
<br />
== '''V4 – Redundancy: Multiple masters of remote I/O''' ==<br />
*Support name responses from multiple controllers of the same database.<br />
*Support request for all fields from a primary database to its backup.<br />
*Support a request for all fields that have changed since the last synchronization of the backup to the primary.<br />
*Support a mechanism for switching from the primary to the backup.<br />
*Provide a mechanism for synchronizing primary and the backup.<br />
*Support multiple communication paths that provide<br />
**an isolated network for synchronization traffic<br />
**redundant checks to synchronize switch over behavior.<br />
*Provide a mechanism to start/stop scanning<br />
*Provide a mechanism to start/stop sequences<br />
*Provide a mechanism to start/stop drivers from scanning<br />
<br />
== '''V4 – Support Large / Multi-segmented Control System''' ==<br />
*Support load balancing between multiple data sources (1st order gateway, 2nd order gateway, IOC, and load).<br />
*Support domain control independent of network topology<br />
**Beamline data is not available to the control room<br />
**Only insertion gap and beam quality information is available to the beamline controls from the ring control room.<br />
<br />
=='''V4 – Extendable Metadata / Properties''' ==<br />
*Metadata can be extendable –<br />
**Add array dimensions<br />
**Add time base to an array<br />
**Application programmers can add metadata<br />
*Specify metadata by field rather than record<br />
**Only get metadata when it is meaningful<br />
**No display limits for the high display limit<br />
*Calc and subroutine records have arrays of inputs<br />
**No limit to the number of variables<br />
<br />
=='''V4 – Channel Access Diagnostics'''==<br />
*Server Diagnostics<br />
**Connections<br />
**Channels<br />
**Events per second<br />
**State of Health<br />
**Beacon Periodicity<br />
**Etc…<br />
*Client Diagnostics<br />
**Number of connections/server per client<br />
**Number of channels<br />
**Events per second<br />
**State of connection<br />
**Etc…..<br />
<br />
=='''V4 – Limitations Remediation'''==<br />
*Multi-line text <br />
*Variable length strings<br />
**Removes current limitations of 40 characters<br />
**Reduces size of memory use in most cases<br />
**Reduces network traffic in most cases<br />
*Unicode<br />
**Support alternate character sets<br />
*Multidimensional arrays<br />
*Variable size arrays<br />
<br />
=='''V4 – Time Stamp Internationalization'''==<br />
*Support ISO 8601 Format<br />
**Year-month-date-hours-minutes-seconds-fractional seconds<br />
**Country specific time stamps<br />
*Support Locale Settings for conversions<br />
**,02 as 2 hundreds of a second<br />
<br />
=='''V???? – Resource Consumption Quotas'''==<br />
*User specific CA client resource consumption quotas in access security system</div>JeffHill