In EPICS 4, a client must supply a channel provider when connecting to data identified by a channel name.
The client will know the list of providers which are available for it to use, but will not know which provider it should use for a given channel name. In some cases more than one provider could be used.
This document describes how a client determines which provider is used for a given channel name.
For more information about EPICS, please refer to the home page of the Experimental Physics and Industrial Control System.
This is the 30 April 2012 version of the EPICS 4 Channel Provider document. This is the first draft of the document
This is a first draft and has not received any comments/feedback It does not clearly state what behaviour is mandatory, what is recommended and what is optional. In particular, for a given implementation
This version is an editor's draft towards the First Public Working Draft. The First Public Working Draft will be intended for the EPICS community to review and comment. Resulting comments will drive subsequent revisions of the Normative Types specification and the EPICS V4 Working Group's reference implementations of software that helps create, populate and exchange Normative Type PVData.
Comments are welcome, though bear in mind this is a pre-public release version.
The terms MUST, MUST NOT, SHOULD, SHOULD NOT, REQUIRED, and MAY when highlighted (through style sheets, and in uppercase in the source) are used in accordance with RFC 2119 [RFC2119]. The term NOT REQUIRED (not defined in RFC 2119) indicates exemption.
EPICS 4 pvData provides structured data types bib:pvdata. A client can connect to data identified by a channel name and once connected to perform operations which access the data (get, put, rpc, etc.). A channel which connects to the data is created by a channel provider. The pvAccess channel provider provides access for pvData using the pvAccess protocol bib:pvaccess. The caV3 provider provides access using the EPICS base CAV3. Other providers are possible, e.g. TINI or TANGO.
In order to connect to data identified by a channel name an channel access client must know which provider to use. The client knows the list of providers available to it, however it does not know which provider to use for a given channel name. A client may broadcast on multiple provider ports to establish which provider to use, however multiple replies may be received, with each reply implying a different provider. Specifically, this will happen when a channel is hosted by an V3 IOC that has both a V3 and V4 server on it. In this case responses may be received on both the pvAccess and V3 channel access ports.
A number of methods exist for determinining which provider to use to connect to a channel.
The client application layer can: