参考文献：

1. 官方CA协议说明 https://epics.anl.gov/base/R3-16/1-docs/CAproto/index.html#_concepts（本翻译的原文）

2. EPICS培训PPT EPICS_Introduction_PSI2011.ppt https://download.csdn.net/download/u013894429/10823381（找不到原文了，所以自己传了一个，官网很多培训资料可以下载）

 

CA协议

CA协议（Channel Access Protocal）是一个描述客户端与服务器之间如何传输数据的协议。在EPICS系统的实际应用中，由于多人协作的原因，可能有很多个CA客户端；而需要控制和记录的仪器也有很多，所以可能有多个CA服务器（参考图2理解）（常用的CA客户端类型有：EDM、MEDM、CSS、BOY等）。因此，需要在多个CA客户端和CA服务器之间进行数据传输（参考图1理解），两个需要通讯的终端如何取得联系？“网络+CA协议”解决了这个问题。

那么CA协议具体是个什么样的规定？大概分为2步：

第1步，客户端寻找目标服务器，遵循UDP协议，无连接协议。客户端有一个目标服务器地址列表，每次客户端寻找目标服务器时都会将搜索请求发送到这些目标地址，即图3左上角所示的1.Query：Broadcast(UDP)。这个地址列表可以是EPICS初始化时默认创建的连接到子网的地址列表，也可以是自定义的地址列表。详情请参考WAN环境或WAN Environent。如果地址列表中存在目标服务器，则该服务器会返回一个包含服务器IP地址和端口号的响应，即图3左上角所示的2.Reply:direct connection(UDP)；如果不存在，则返回异常消息。

第2步，建立一对一长连接，遵循TCP协议，面向连接的协议。这是在第1步返回了目标IP和端口号的基础上进行的。简单来说，就是找到目标地址和端口后，客户端与该服务器建立连接，然后传输数据。图3中“I do”之后的流程就是TCP连接了。

打个比方，“CA客户端们与CA服务器们”就像是“老师们与学生们”，老师们与学生们建了一个QQ群，“通过网络和QQ聊天”就是“通过网络和CA协议传输数据”。现考虑老师们和学生们都是在线的情况：语文老师在群里吼了一声“谁的座位是3号”，就好比一个CA客户端发送了一个搜索请求（UDP）。3号同学在群里答了一句：“我是3号”，就相当于CA服务器响应了一次（UDP）。语文老师接下来找3号同学私聊，拉了一个独立的私聊窗口（不是群聊窗口），就好比CA客户端与CA服务器建立TCP连接，开始传输数据。

 

通道变量

通道变量（PV）是可通过通道访问协议访问的可寻址数据单元。 每个PV都有一个唯一的名称字符串（用于访问这个PV单元），并且应该由单个通道服务器提供服务。 也就是说，每个客户端在搜索同一个PV变量时，都不能收到来自多个服务器（对此搜索）的回复。

 

“PV变量”和“记录(record)”的关系是什么？

其实它们本质是用来表示一个东西，不过是来自不同的角度表达。

PV变量是针对CA协议来说的，它是record中最主要的域（VALUE域），这个域的值一般与一个硬件的数据连接。如图5所示，field(INP, "#C3 S0 @")这句表示的就是：与实际硬件相连，并将该硬件的数据与VALUE域相关联。其中的INP定义EPICS调用哪个驱动去获取VALUE值。

记录(record)是针对实时数据库来说的，它是一个数据块存储单元，包括了很多域，其中主要的域为VALUE域。由于存储需要，其他也有很多辅助的域。一般一个record会指定一个硬件通道，并将该通道的数据域VALUE值相关联。图5（绿色背景部分）所示是创建一个记录的程序表述。

 

虚拟电路

CA客户端和服务器之间的TCP连接称为虚拟电路。
通常，每个客户端和服务器之间只打开一个电路。 但是，一个客户端可以向同一服务器打开多个电路。

 

TCP消息流

以下树形图说明了正常情况下（未发生错误时），一条CA消息在TCP连接时被发送的顺序。带框边框的节点是服务器发送的消息，椭圆边框是客户端发送的消息。 具有双边框的节点（例如“Open Socket”）本身不是消息。 相反，它们表示在发送某些消息之前必须满足的前提条件。

消息CA_ERROR可以由服务器响应于任何客户端消息而发送。

通道

通道是特定电路和PV名称之间的关联。

在内核中，通道是一个运行时分配的整数标识符对（CID和SID），用于代替PV名称，以避免字符串操作的开销。 客户端和服务器都必须维护与电路相关的所有开放通道的标识符列表。

这些标识符的范围是单个电路。 一个电路中的标识符不得用于任何其他电路。 此外，可以在两个不同的电路上连接的两个不同PV名称上使用相同的标识符序号。

频道的标识符在Message Identifiers这节中说明。

 

监听器

在通道上创建监听器，作为注册/订阅异步更改通知（发布）的手段。 可以过滤监听器以仅接收事件的子集（事件掩码），例如值的变化或警报变化。 可以为每个通道创建几个不同的监听器。

客户端不应该在同一个通道上使用相同的事件掩码创建两个监听器。

 

服务器信标

服务器信标是由服务器发出的UDP包，以示它们还存在。该信标自初始化起就开始连续发送，发送间隔从初始值逐渐增加至最大间隔值，然后一直以最大间隔持续发送信标。服务器以一定间隔持续发送信标，就好比人的心跳。发送这个信标的端口为5065端口（就把它记作心跳端口吧）。服务器信标由客户端接收。服务器信标还可用于恢复断开的虚拟电路连接。

另外，这里提一句，用于接收/发送数据的端口为5064端口（就把它记作数据端口吧）。不管是响应CA客户端的名称搜索请求时（UDP），还是建立TCP连接后开始传输数据时，都是使用这个数据端口。

【备注：此前两段为自己的理解和归纳，感谢韩利峰老师的指导，给予我很大帮助！】

 

服务器信标消息（CA_PROTO_RSRV_IS_UP）必须定期广播。信标消息包含服务器侦听的IP地址、TCP端口，及服务器监听的该IP端口下的有序信标ID。

当服务器变为活动状态时，必须立即开始发送信标，而且发送信标的间隔是逐渐增加的。

建议初始的信标发送间隔为0.02秒。在各个信标发送后，发送间隔应该逐渐增加，直至增加到最大间隔。

建议发送间隔增大的方式为：后一个间隔为前一个间隔的两倍。推荐的最大间隔为15秒。

当服务器发送信标时，它必须为发送的每条消息递增BeaconID字段。

CA客户端可以使用服务器的第一个信标作为触发器来重新发送以前未应答的CA_PROTO_SEARCH消息。

虽然它是历史性的，但客户端做超时决策时，不应该使用Beacons来为TCP电路，而应该使用CA_PROTO_ECHO消息。

希望检测新服务器的客户端应该保留所有服务器的列表以及收到的最后一个BeaconID和接收时间。当一段时间内没有接收到信标时，应该从该列表中删除服务器（推荐两个信标周期）。

 

中继器

详见 Repeater Operation

 

超时行为

CA客户端通常不应该自动重新连接已经无响应的电路，而CA客户端应该发送新的CA_PROTO_SEARCH请求。

有时CA客户端应该重新发送未回答的PV名称搜索。

必须注意避免由于重复查找和连接而导致过多的网络负载。 建议客户端在为每个PV重新发送CA_PROTO_SEARCH消息时实现指数增加的发送间隔（直至达到间隔最大值）。

当通道异常关闭或通过CA_PROTO_CREATE_CH_FAIL回复通道创建失败时，建议客户端在重新启动搜索之前实现超时。

 

版本兼容性

在不同版本之间，通道访问协议的某些方面发生了变化。 在本文档中，使用CA_VXYY标识通道访问版本。其中X是一位数，表示主要版本号；YY是一位或两位数，表示次要版本号。 声明CA_VXYY中的功能可用意味着任何支持版本XYY的客户端都必须支持该功能。 必须实现向后兼容所有版本，包括其声明的受支持的次要版本号。

 

示例1.通道访问版本号
CA_V43，表示版本4.3（主要版本4，次要版本3）。通道访问协议带有隐式主要版本4.次要版本以1开始。次要版本0不是有效版本。创建虚拟电路时，客户端和服务器都会发送其次要版本号。 电路的有效消息和语义由两个次要版本中较低的一个确定。

CA次要版本更改的部分历史记录：

 

异常

通道访问协议错误消息（CA_PROTO_ERROR）称为异常。 CA服务器通过发送异常来表明它无法处理客户端消息。

异常可能作为对任何客户端消息的响应，包括通常不会导致回复的消息。

异常消息携带了触发错误的客户端消息的头部信息。 因此，始终可以将异常与触发它的请求相关联。