中文名 | 报文滤波 | 外文名 | Message Filtering |
---|---|---|---|
定 义 | 实现点对点、单对多等数据传输 | 寄存器 | 32位 |
CAN控制器 | CAN2.0A和CAN2.0B | 应用学科 | 计算机原理 |
验收滤波寄存器是一组用于控制验收滤波器工作模式及LUT格式的32位寄存器,起始地址为OxE003C000,在它们的相应位写入不同的数值就可以实现对验收滤波器的设置。
寄存器AFMR决定验收滤波器的工作模式,它只有前3位有效,通过4种组合,可以使验收滤波器工作于不同模式。在设置验收滤波相关的寄存器和LUT表格的内容时,首先须将AFMR寄存器中的AccBP位置1,实际上,只要向AFMR寄存器中写入0x03,将其设置为旁路模式就可以了。如果AccBP位没有置1,仅有LUT中标识符的禁能位可以修改,如果只需禁能或使能某个Cell所指定的标识符过滤,就可通过向LUT中相应的Cell写入一1或0来实现。
传统方案
传统CAN总线解决方案中通常采用PHILIPS公司的独立CAN控制器SJA 1000。SJA1000同时兼容CAN 2.0A和CAN 2.0B两种技术规范,它有两种滤波模式:单滤波模式和双滤波模式。无论哪一种模式,都只有当接收信息中的识别位和验收滤波器预定义的值相同时,CAN控制器才允许将该信息存入接收缓冲区。
SJA1000中,验收滤波器由验收代码寄存器(ACR)和验收屏蔽寄存器(AMR)来定义,这两个8位的寄存器相配合工作,AMR为0的位,ACR与之对应的位必须和CAN报文标识符的对应位完全相同才予以接收,而AMR为1的位,则屏蔽掉ACR与之对应的位,即CAN报文中对应的位可为0也可为1。实际上,这种验收滤波方案只能满足一些规律性较高的或个数较少的标识符的过滤,无法对更为复杂的任意标识符进行过滤,这无疑会增加系统软件设计及运行时的负担。
LPC2000的滤波原理及过程分析
PHILIPS公司的LPC2000系列ARM微控制器内嵌2或4个CAN控制器,都有先进的验收滤波器。概括性地描述LPC2000对CA N报文的验收滤波流程:CAN控制器监听所有来自CAN总线上的报文,当一个报文到达时,CAN控制器执行快速的硬件搜索算法,将收到的CAN报文标识符与验收过滤RAM中存储的标识符进行匹配。如果没有匹配,则丢弃该报文,这个过程不会对CAN控制器产生中断,应用代码仍然正常执行;如果有匹配的标识符,CAN控制器将通过置位集中接收状态寄存器中的相应位产生中断,中断服务程序将该报文从CAN控制器的寄存器复制到RAM中,并通过置位CAN命令寄存器的相应位来释放CAN控制器的接收寄存器。
4. 综合前置机的报文处理
综合前置机所处理的所有金融交易都以交易报文为基础。报文格式的制定应参考ISO 8583标准,包含各种交易可能具有的所有信息。
(1)交易报文的格式
报文的第一部分为报文类型,1字节长。系统交易处理主控进程根据报文类型,指定相应的报文处理程序。报文的第二部分为报文内容,长度不定。它是金融交易的具体内容,它的产生由发送报文的系统主机完成。
(2)通知类报文
报文接收进程收到通知类报文后,对报文内容进行整理,然后将报文发送到系统主消息队列,交易处理主控进程收到报文后,根据报文类型,将其指派到相应的通知报文处理程序进行处理,之后将报文转发到报文发送进程,报文发送后,本次交易结束。
(3)请求/响应类报文
报文接收进程1收到交易请求报文后,对报文内容进行整理,然后将报文发送到系统主消息队列,交易处理主控进程收到请求报文后,根据报文类型,将其指派到相应的请求报文处理程序进行处理,之后将报文转发到报文发送进程2,报文发送后,交易请求处理结束。系统主机收到交易请求后,进行处理并发出交易响应到报文接收进程2,该进程对报文内容进行整理后,将响应报文发送到系统主消息队列,交易处理主控进程收到响应报文后,根据报文类型,将其指派到相应的响应报文处理程序进行处理,之后将报文转发到报文发送进程1,报文发送后,本次交易处理结束。
(4)交易请求直接拒绝的处理
综合前置机可对交易请求进行预处理,拒绝不合要求的交易请求。这样,在前置机阶段就对交易请求直接作出拒绝响应,因而在一定程度上减轻了系统负荷。报文接收进程1收到交易请求报文后,对报文内容进行整理,然后将报文发送到系统主消息队列,交易处理主控进程收到报文后,根据报文类型,将其指派到相应的交易请求处理程序进行处理,之后将拒绝响应报文转发到报文发送进程1,报文发送后,本次交易结束。
GRE 封装后的报文格式为 :
Delivery Header |
GRE Header |
Payload packet |
Delivery Header:封装的外部协议报文头(如IP报文头),即隧道所处网络的协议数据头,是实现一种协议报文穿越另一种协议网络的传输工具。
GRE Header:对数据报文进行封装后加入的数据,包含GRE协议本身以及和负载协议有关的一些信息。
Payload Packet:进入隧道之前的网络层数据报文,将作为隧道报文的有效负载,该报文的协议号将作为GRE头部字段中的ProtocolType字段。GRE头部信息具有如图所示的结构。
一个最简单的GRE头部只有4个字节,即在C、K、S等标志们都为0的情况下,GRE头部仅包含第0到31位的信息。前4个bit位都为标志位,分别表示了头部后来的字段是否有效;ProtocolType字段标识PayloadPacket的协议类型,一般情况下,该协议字段与以太网帧的类型字段值相同 。
需要封装和传输的数据报文,称之为净荷(Payload),净荷的协议类型为乘客协议(Passenger Protocol)。系统收到一个净荷后,首先使用封装协议(Encapsulation Protocol)对这个净荷进行GRE 封装,即把乘客协议报文进行了“包装”,加上了一个GRE 头部成为GRE 报文;然后再把封装好的原始报文和GRE 头部封装在IP 报文中,这样就可完全由IP 层负责此报文的前向转发(Forwarding)。通常把这个负责前向转发的IP 协议称为传输协议(Delivery Protocol 或者Transport Protocol)。根据传输协议的不同,可以分为GRE over IPv4 和GRE over IPv6 两种隧道模式。
DHCP option 82又称为DHCP中继代理信息选项(Relay Agent Information Option),是DHCP报文中的一个选项,其编号为82。rfc3046定义了option 82,选项位置在option 255之前而在其它option之后。
Code:表示中继代理信息选项的序号,rfc3046定义为82,option 82即由此得名。
Len:为代理信息域(Agent Information Field)的字节个数,不包括Code和Len字段的两个字节。
Option 82可以由多个sub-option 组成,每个option 82选项至少要有一个子选项.
SubOpt:为子选项编号,其中代理电路ID(即Circuit ID)子选项编号为1,代理远程ID(即 Remote ID)子选项编号为2。
Len:为Sub-option Value的字节个数,不包括SubOpt和Len字段的两个字节。
option82子选项2:option82子选项2定义了代理远程ID(即 Remote ID),代理远程ID是指接收到DHCP请求报文的接入交换机的vlan MAC地址。子选项2通常与子选项1共同使用来标识DHCP客户端的信息。
DHCP请求报文:指由DHCP客户端发起的报文,希望DHCP服务器响应后分配IP地址和其它配置信息。DHCP请求报文一般有四种,分别为DHCP_DISCOVER报文、DHCP_REQUEST报文、DHCP_RELEASE报文和DHCP_INFORM报文。中继代理只针对DHCP请求报文添加option 82选项并转发给服务器。本文实现的DHCP中继对这四种请求报文都添加option 82选项。
DHCP应答报文:指由DHCP服务器响应客户端发起的请求报文,包含配置信息或指示回应结果的DHCP响应报文,DHCP应答报文一般有DHCP_OFFER报文,DHCP_ACK报文和DHCP_NAK报文。2100433B