CN117278486A - 一种可靠udp组播的fpga硬件加速系统及方法 - Google Patents

一种可靠udp组播的fpga硬件加速系统及方法 Download PDF

Info

Publication number
CN117278486A
CN117278486A CN202311220047.4A CN202311220047A CN117278486A CN 117278486 A CN117278486 A CN 117278486A CN 202311220047 A CN202311220047 A CN 202311220047A CN 117278486 A CN117278486 A CN 117278486A
Authority
CN
China
Prior art keywords
data packet
message
module
sending
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311220047.4A
Other languages
English (en)
Inventor
王银
阎如斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kochi Xi'an Electronic Information Technology Co ltd
Original Assignee
Kochi Xi'an Electronic Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kochi Xi'an Electronic Information Technology Co ltd filed Critical Kochi Xi'an Electronic Information Technology Co ltd
Priority to CN202311220047.4A priority Critical patent/CN117278486A/zh
Publication of CN117278486A publication Critical patent/CN117278486A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/36Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/43Assembling or disassembling of packets, e.g. segmentation and reassembly [SAR]
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/50Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Abstract

一种可靠UDP组播的FPGA硬件加速系统及方法,包括消息处理模块、数据包发送模块、数据包接收模块、数据包处理模块、发送历史缓存模块、接收缓存模块和消息恢复模块;消息处理模块连接数据包发送模块,数据包发送模块连接发送历史缓存模块,发送历史缓存模块连接数据包处理模块和消息恢复模块;数据包处理模块通过接收缓存模块连接数据包接收模块,数据包接收模块和消息恢复模块连接。本发明通过FPGA硬件加速的方式,将UDP可靠性的传输机制使用硬件实现,使得计算能力和运行速度提高了上千倍,解决了软件的延时,同时提高了客户的体验。

Description

一种可靠UDP组播的FPGA硬件加速系统及方法
技术领域
本发明属于UDP组播处理技术领域,特别涉及一种可靠UDP组播的FPGA硬件加速系统及方法。
背景技术
近年来,各银行在外汇交易市场迅速发展,交易系统报价数量和成交数量不断攀升,市场成员对交易系统的直连接口需求日益增加,交易系统与会员接口连接通过接入节点(网关)。
目前接入节点存在问题有:
1、接入服务器需求量大。中心会员数量较多,会员节点、接入节点和后台节点拓扑呈倒三角状,导致后台数据堵塞等待,处理速度较慢。
2、出口容量有限,协议转换延时较长。会员与中心系统间互联采用金融行业标准IMIX协议,具有较高的可读性,但文本转换效率较低。
3、目前TCP/UDP/IP协议依赖操作系统协议栈,可靠UDP组播处理采用软件实现,延时较大,在高吞吐场景时对CPU有较多占用,吞吐率提升有限。
发明内容
本发明的目的在于提供一种可靠UDP组播的FPGA硬件加速系统及方法,以解决处理速度较慢、出口容量有限,协议转换延时较长、吞吐率提升有限的问题。
为实现上述目的,本发明采用以下技术方案:
一种可靠UDP组播的FPGA硬件加速系统,包括消息处理模块、数据包发送模块、数据包接收模块、数据包处理模块、发送历史缓存模块、接收缓存模块和消息恢复模块;消息处理模块连接数据包发送模块,数据包发送模块连接发送历史缓存模块,发送历史缓存模块连接数据包处理模块和消息恢复模块;数据包处理模块通过接收缓存模块连接数据包接收模块,数据包接收模块和消息恢复模块连接;
消息处理模块用于接收用户消息,并对消息拆包及处理数据包;
数据包发送模块用于数据包的发生和心跳生成;
数据包接收模块用于接收正常或恢复的组播和点播数据包、心跳消息、消息重传请求数据包及消息重传请求失败数据包;
数据包处理模块用于接收缓存,收到发来的数据包将其读入自己的缓存,传递给数据包序列号检测模块,进行数据验证;
消息恢复模块用于比较重传数据包和发送历史缓存模块的范围,判断是否将数据包通过数据包发送模块发送到网络。
进一步的,数据包接收模块包括数据包序列检测单元、乱序缓存单元、错误数据包处理单元、乱序数据包处理单元、心跳数据包处理单元、新数据流产生单元、接收重传请求单元和接收通道队列单元;新数据流产生单元、心跳数据包处理单元、乱序缓存单元、乱序数据包处理单元、错误数据包处理单元、接收通道队列单元和接收重传请求单元均连接到数据包序列检测单元。
进一步的,消息处理模块包括消息发送单元、消息拆包单元、消息组包单元和长消息缓存单元;新数据流产生单元和接收重传请求单元均连接消息处理模块;接收通道队列单元连接到消息组包单元,消息组包单元连接长消息缓存单元。
进一步的,数据包发送模块包括数据包发送单元和心跳生成器;消息拆包单元连接数据包发送单元。
进一步的,数据包处理模块包括数据包接收单元、数据包发送单元和心跳超时处理单元;数据包发送单元连接发送历史缓存模块、数据包发送模块的数据包发送单元和消息恢复模块;数据包接收单元连接心跳超时处理单元、接收缓存模块和消息恢复模块。
进一步的,数据包接收单元、数据包发送单元连接到网络。
进一步的,消息恢复模块包括重传请求发送单元、重传请求超时单元、重传请求接收单元、重传队列单元和发送重传请求单元;重传队列单元、发送重传请求单元、发送历史缓存模块、数据包处理模块的数据包接收单元及数据包发送单元均连接到重传请求接收单元;重传请求发送单元连接数据包接收模块的新数据流产生单元和心跳数据包处理单元。
进一步的,一种可靠UDP组播的FPGA硬件加速方法,包括:
消息发送:
消息处理模块接收到应用程序发送过来的一则消息,如果消息的长度大于设置的数据包的大小,将消息拆解成多组数据,分别对多组数据添加一个消息头,按顺序依次发给数据包发送模块;如果消息的长度不大于设置的数据包的大小,将消息数据添加一个消息头,直接发给数据包发送模块;
数据包发送模块接收到消息处理模块发来的数据,对每一组数据都添加数据包头,并在数据包头的序列号字段填写上最新的序列号,然后将打包好的数据包发送给数据包处理模块,同时也发送给发送历史缓存模块备份,待重传使用;数据包发送模块按照设置的时间,定时产生心跳数据包,定时发送给数据包处理模块;
数据包处理模块接收到数据包发送模块发来的数据包,添加数据包校验位以后,通过网卡发送到网络;
消息接收:
数据包处理模块接收到网络上的数据包,如果接收到重传请求,将数据包发送给消息恢复模块,否则按顺序依次将数据包存入接收缓存模块;
数据包接收模块将数据包从接收缓存模块中读出,对数据包进行如下检查:
数据包长度检查:如果长度不正常,发送坏包事件给消息处理模块,消息处理模块将坏包事件发送给应用程序;
数据包类型检查:如果是NACK数据包,发送数据丢失事件给消息处理模块;
对数据包的序列号进行检查:如果序列号正确,再判断是心跳包直接丢弃,是数据包的话去掉数据包头,发送给消息处理模块,消息处理模块判断如果是完整消息,去掉消息头发送给应用程序,如果此次数据包不能组成一个完整消息,将消息缓存起来,待多组数据包组合后成为完整消息,再发送给应用程序;
如果序列号不正确,且是心跳包,发送心跳包间隙事件给消息处理模块,消息处理模块将数据包丢失事件发送给应用程序,同时发起重传请求给消息恢复模块;
如果序列号不正确,且是数据包,发送数据包间隙事件给消息处理模块,消息处理模块将数据包丢失事件发送给应用程序,同时发起重传请求给消息恢复模块,并将接收到的数据包暂存到乱序缓存中;
Stream ID检查:如果Stream ID是之前没有的,是一个新的Stream ID,发送NewStream ID事件给消息处理模块,消息处理模块将New Stream ID事件发送给应用程序;
消息恢复:
消息恢复模块接收到数据包处理模块的重传请求数据包,放入重传请求队列,然后在发送历史缓存模块查找请求发送的数据包,如果能找到,将发送历史缓存模块的数据包发送给数据包处理模块,数据包处理模块将数据包发送到网络;如果不能找到,发送NACK数据包给数据包处理模块,数据包处理模块将数据包发送到网络;
消息恢复模块接收到数据包接收模块的心跳包间隙重传请求,或者数据包间隙重传请求,产生重传请求数据包,发送给数据包处理模块,数据包处理模块将数据包发送到网络;如果相同的重传请求超过设置的最大次数,则不再发送此重传请求。
与现有技术相比,本发明有以下技术效果:
FPGA的硬件描述语言Verilog设计,采用了多通道(512ch)并行执行。FPGA的内部结构是通用的硬件逻辑电路,通过Verilog编程使其实现需要的专用硬件逻辑电路,硬件逻辑电路可以实现并行执行,不像软件指令串行执行,多通道并行执行可以解决多节点的问题。
每个通道的模块之间数据流的最大延时是5个时钟周期,即20ns。相比于软件运行的速度,使得计算能力和运行速度提高了上千倍,80%的协议转换都在FPGA硬件电路中完成,解决了延时较长的问题。
FPGA硬件加速系统不像软件一样依赖于操作系统,完全脱离于CPU的独立加速系统,不占用CPU,可靠UDP组播的数据包编号、反馈重传、丢包重发、心跳监测等复杂费时的功能,全部放在FPGA硬件中实现,大大的减少了延时,并提高了吞吐率。
附图说明
图1为可靠UDP组播的FPGA硬件加速系统框图。
图2为本发明整体流程图。
具体实施方式
以下结合附图对本发明进一步说明:
一种可靠UDP组播的FPGA硬件加速系统,主要包括消息接收和消息发送。
消息接收功能包括:接收正常组播消息和点播消息、错误数据包处理、有乱序数据包处理、心跳消息处理、新数据流产生、重传请求NACK消息处理等。
消息发送功能包括:发送正常的组播和点播数据包、心跳消息、消息重传处理、消息重传请求等。
如图1所示,可靠UDP组播的FPGA硬件加速分为以下7个功能模块:
消息处理模块(Message Processor)
消息发送(Message Sender)
消息拆包(Message Disassembler)
消息组包(Message Assembler)
长消息缓存(Long Message Buffer)
事件处理(Event Handle)
数据包发送模块(Packet Sender)
数据包发送(Packet Sender)
心跳生成器(Heartbeat Generator)
数据包接收模块(Packet RX)
数据包序列检测(Packet Sequencer)
乱序缓存(Sequencer Gap Buffer)
错误数据包处理(Bad Packet Handle)
乱序数据包处理(Sequencer Packet Handle)
心跳数据包处理(Heartbeat Packet Handle)
新数据流产生(New Stream)
接收重传请求NACK(Receive Re-transmission Request NACK)
接收通道队列(RX Channel Queue)
数据包处理模块(Packet Processor)
数据包接收(Receive Packet)
数据包发送(Send Packet)
心跳超时处理(Heartbeat timeout)
发送历史缓存模块(History Buffer)
接收缓存模块(RX Buffer)
消息恢复模块(Message Recovery Handler)
重传请求发送(Re-transmission Request TX)
重传请求超时(Re-transmission Request timeout)
重传请求接收(Re-transmission Request RX)
重传队列(Re-transmission Queue)
发送重传请求NACK(Send Re-transmission Request NACK)
消息接收:
消息接收是由网络端通过网口接收至FPGA数据加速器卡,FPGA将接收到的消息校验后按固定格式组包成消息信息,对于乱序数据包,存储到sequence gap buffer中用于重新排序数据包,最终将组包后的消息通过PCIe 3.0 16 lane接口上传到服务器应用程序。消息接收功能包括:接收正常或恢复的组播和点播数据包、心跳消息、消息重传请求数据包、消息重传请求失败数据包等。
正常组播消息与点播消息:
这里主要描述设计DEP Messaging如何从通道收到一个消息,并传递给应用。
当某个通道接收到组播消息时,DEP Messaging从网络中读取数据包,并组成一个完整的消息。最后,DEP Messaging通知应用消息,收到了消息。
对于点对点消息,处理方式是一致的,只是在数据序列号检测模块,会根据目的应用名称(Target Instance Name这是包头字段),进行筛选,之后才通知应用。
具体流程:
1.接收缓存从网络拿到网络包数据
2.数据包处理模块从接收缓存,收到网络上发来的数据包将其读入自己的缓存
3.数据包处理模块将数据包传递给数据包序列号检测模块,进行数据验证
4.数据包序列号检测模块做以下检测
A对于数据包每一个域进行检测
1.包长
2.包类型
3.数据包序列号
4.Stream ID
5.Instance Name(sender)
6.Session ID
7.消息类型
8.消息长度
B确保数据包之间是有序的
C对于Target Instance Name进行检测(如果是组播消息)
5.如果数据包检测通过,数据包处理模块通知消息处理模块,收到有效数据包,如果没有通过,则详细看后面章节对于无效数据包的处理
6.消息处理模块收到数据包接收信号后,获取有效数据包
7.消息处理模块将数据包传递给消息组包模块
8.消息组包模块,将数据包组成完整的消息
9.如果收到一个完整的消息,则以事件通知应用
10.如果收到的数据包不足以拼成完整的消息,则缓存在FPGA(FPGA longMessage buffer)中,等收完了再通知应用程序
错误数据包的处理:
这部分主要描述设计DEP Messaging如何处理收到错误的数据包。
由于网络原因或者对端发送应用程序错误,DEP Messaging可能会收到错误的数据包。DEP Messaging需要丢弃掉这些错误的数据包,并继续接收正确的数据包。
具体流程:
1.数据包处理模块从接收缓存,收到网络上发来的数据包
2.数据包处理模块将其读入自己的缓存
3.数据包处理模块数据包传递给数据包序列号检测模块,进行数据验证
4.数据包序列号检测模块进行数据包验证
5.验证如果失败,则以out of band事件,通知到应用程序
以下条件,被认为是一个错误的数据包
A数据包长度字段,和实际收到的数据包长度不一致
B数据包类型,消息类型字段,不是有效值
C数据包序列号,超过了设定的序列号的最大值。
乱序数据包:
这部分设计数据包如果有乱序的情况下,DEP Messaging如何处理。
当数据包在网络中传输时,有可能会发生乱序和丢包的情况。DEP Messaging必须要允许这样的情况发生,并保证按照数据包发送者发出的顺序,去组成一个完整的消息。
具体流程:
1.数据包处理模块从接收缓存,收到网络上发来的数据包
2.数据包处理模块将其读入自己的缓存
3.数据包处理模块数据包传递给数据包序列号检测模块,进行数据验证
4.数据包序列号检测模块进行数据包验证
A数据包头字段与消息包头字段
B数据包是否为有序
5.当序列号不连续情况发生时,乱序的包暂时被缓存于乱序缓存中
6.数据包处理模块发送重传请求,给消息的发送者。
心跳消息:
这部分主要描述设计DEP Messaging如何处理心跳消息。
DEP Messaging发布者间歇性的通过每一个发送通道,发出心跳消息。在发送通道创建完成后(由配置模块得到通道创建使能),知道DEP Messaging关闭,都要保持发送心跳消息。心跳消息用于接收者判断stream的状态。当消息接收者在一段时间内没有收到心跳消息,则表示这个stream已经关闭。
心跳消息携带了最后发出的数据包的序列号。消息接收者可以以此来判断stream中消息是否发生了数据包的丢失。
具体流程:
1.数据包处理模块从接收缓存,收到网络上发来的数据包
2.数据包处理模块将其读入自己的缓存
3.如果这个数据包为一个心跳消息,则只进行处理不进行组包(心跳包长度必定小于MTU,因此不需要组包过程),数据包处理模块将此数据包传递到数据包序列号检测模块,通过携带的序列号字段,和最后一次收到指定通道收到的数据包序列号,去判断是否发生了包级别的丢失。
4.如果没有发现有丢包或者乱序,数据包序列号检测模块继续判断stream ID与sequence number是否保持约束关系,保持约束关系则不作处理。
5.如果发现有丢包或者乱序,数据包处理模块将发送向消息发送者发起重传请求。
心跳或数据超时:
这部分主要描述设计DEP Messaging如何处理心跳消息超时。
具体流程:
1.数据包处理模块中有一个计时模块(timer)
2.计时模块主动检查最后收到的数据包,是否已经超时,即一段时间内没有心跳消息也没有数据消息被接收到
3.一段时间内没有新的心跳包或数据包,序列号检测模块删除此通道的数据流信息,清空数据包序列号,清空乱序缓存,等待新的数据流产生。
新数据流的产生:
这部分主要设计DEP Messaging如何处理心跳和数据包,来得到一个新的数据流(Stream)。
DEP Messaging用指定通道的心跳和数据包,来发现一个通道的新数据流。如果指定通道接收到了一个新的stream ID,消息接收模块则认为这是此通道所产生的一个新的数据流。
具体流程:
1.数据包处理模块从接收缓存,收到网络上发来的数据包
2.数据包处理模块将其读入自己的缓存
3.如果是数据消息或者是心跳消息,包处理模块将数据包
4.如果碰到了一个新的stream ID,表示所占用通道的发送者正在用一个新的stream ID在传送消息。应用将被通知此通道有一个新的数据流。
重传请求:
这部分主要描述设计DEP Messaging如何处理重传请求数据包,当接收者发现有丢包情况出现时会向DEP Messaging发送重传请求数据包,DEP Messaging需要处理该数据包,帮助接受者恢复所请求的数据包数据。
如过恢复不成功,则通知软件该事件。
具体流程:
1.数据包处理模块从网络中得到数据包
2.数据包处理模块从接收缓存,收到网络上发来的数据包
3.数据包处理模块将其读入自己的缓存
4.如果这个数据包为一个重传请求数据包,则只进行处理,不进行组包。
5.消息恢复模块需要将重传数据包范围与history buffer中范围相比较
a、如果重传数据包范围在history buffer内,则将数据包通过数据包发送模块发送到网络。
b、如果重传数据包范围不在history buffer内,则将该事件通知到软件,复位相关模块。
重传请求NACK消息:
这部分主要描述设计DEP Messaging如何处理重传请求NACK消息,当网络中发生丢包情况,消息接收者将会通过数据包序列号检测模块检测出丢包,并像上一个章节所描述的那样发出消息重传消息。
当消息发布者不能恢复这些消息时,就会给消息接收发送重传请求NACK消息,消息恢复者将会将此事件上报给软件,并需要软件重置数据包序列号检测模块和消息组包模块的状态。
具体流程:
1.数据包处理模块从网络中得到数据包
2.当收到重传请求NACK消息后,只进行处理不进行组包,数据包处理模块将数据流的状态从乱序等待/丢包等待,改变为正常
3.数据包序列号检测模块将重置数据包组包模块的状态,丢弃要组包的数据包。
各个功能模块的实现:
Message assembler模块的主要功能是把数据包组成消息,即包级到消息级的转换,它和Message disassembler刚好是相逆的过程。
如果得到的有效数据包消息不是完整的消息,如何判断后续收到的数据包可以组成完整的消息,在packet processor模块可以判断出接收到的数据包是否可以组成一条完整的消息,在packet processor判断出一条完整的消息后,送出一个信号给Messageassembler,这样Message assembler就可以在接收到这些数据包后,把所有接收到的数据包的有效数据包消息长度相加,看是否是和message length相等,相等则表示得到的有效数据包可以组成完整的消息。如果不相等,则表示前面的判断有错,这种情况几乎不会发生,除非设计错误。这个的具体流程图和下面的画到一起。
如果得到的有效数据包消息不是完整的消息,继续接收下一个数据包时,如何处理上一个数据包得到的有效消息,如果一个消息分多个数据包发送,可以将上一个得到的有效数据包消息暂时储存起来,这个储存设计可以不用DDR,用fifo暂存一下就可以,直到收到的有效数据包消息可以组成完整的用户消息时,再把数据从fifo中读出即可。
数据包处理模块是直接与网络传输接口,提供向网络发送数据包和从网络接收数据包的功能的模块。
Packet process在dep messaging中属于最主要的模块之一,它既可以收也可以发,其中packet sender,packet sequencer,sequence gap buffer以及rx channel queue(实际设计可能没有这个模块)等模块属于Packet process的子模块,这些子模块的功能集合到一起,就构成了Packet process模块的功能。
作为接收模块,Packet process需要从rx buffer中接收数据包,内部的packetsequencer对接收到的数据包进行验证,如果验证通过,则把数据包放到rx channelqueue,验证不通过的时候,需要接收重传请求是否成功的标志即nack。
作为发送模块,Packet process需要把验证正确的数据包发送给消息组包模块,如果验证不通过,则需要发送重传请求。
所以根据Packet process的功能可以看出,设计Packet process模块时只需留出接口,处理好与其交互模块的接口时序即可。
数据包序列号检测的功能是确保接收到的数据包按发送顺序排列。数据包序列号检测利用包中的序列号维护顺序并检测序列间隔。
Packet sequencer的主要功能是对数据包进行序列号检测,判断数据包在网络传输中是否发生乱序或丢包,以此来保证接收到数据包的正确性。
序列间隙缓冲区是用于临时存储序列外数据包信息的缓冲区。缓冲区的数据结构为循环缓冲区。
Sequence Gap Buffer的主要作用是消息缓存,存储使用的是ddr4,在设计的时候,直接调用ddr4的IP,需要先把ddr4的接口时序设计好,确保存储没有问题,再做模块功能的详细设计。
首先确认sequence gap buffer的使用场景,只有在packet sequencer检测数据包出现了乱序或者数据包丢失的时候才会用到sequence gap buffer,如果packetsequencer检测数据包没有问题,则不需要用到sequence gap buffer。所以sequence gapbuffer的设计需要分为数据包乱序和数据包丢失两种场景设计。
这里有个重点要关注,如何区分数据包是丢失还是乱序,这个可以通过在initialconfig模块进行一个阈值的配置来对缓存的数据包进行检查,例如,当收到的数据包为1,2,5,4,6的时候,需要判断收到的数据包是丢失了还是乱序,这个时候,根据在配置模块设置的阈值(假设阈值为十),让该模块继续接收十个数据包,如果后续收到的十个数据包中有3,则判断数据包为乱序,sequence gap buffer自己给数据包排序。反之后续收到的十个数据包没有3,则判断数据包为丢包,需要发送重传请求。
消息重传模块需要处理恢复请求和恢复请求失败两种情况。消息重传模块与消息恢复模块配合工作。
在处理恢请求失败的情况时,是由于DEP Message向网络发送重传请求数据包后,网络由于恢复不了该数据包,所以向DEP Message发送恢复请求失败数据包。当DEPMessage收到恢复请求失败数据包后,将会将此事件上报给软件,并需要重置数据包序列号检测模块和消息组包模块的状态。
在处理恢请求的情况时,是由于网络检测到丢包情况,网络通过网口向DEPMessage发送重传请求数据包。当数据包处理模块检测到该数据包是重传请求数据包,消息重传模块采样重传请求数据包,将重传所需的起始和结束编号解析出来,发送到消息恢复模块中。
消息重传模块在时钟上升沿采样,低电平复位。当消息重传模块接收到恢复请求失败有效标志后,需要进行判断recovery_fail_req是否为高电平。
如果recovery_fail_req为高电平,表明接收到恢复请求失败有效数据包,则重传失败上报软件事件信号recovery_fail_event,高电平表示该事件有效,重置数据包序列号检测模块和消息组包模块的状态reset_pkt信号均置为高电平。
如果recovery_fail_req为低电平,则重传失败上报软件事件recovery_fail_event信号、重置数据包序列号检测模块和消息组包模块的状态reset_pkt信号均置为低电平。
如果recovery_req为高电平,表明接收到恢复请求有效数据包,此时从数据包处理模块得到恢复请求编号范围recreq_numrange_in[7:0],将恢复请求编号转发给消息恢复模块。消息恢复模块会将此范围与history buffer中的数据编号进行对比并帮助网络端恢复。
如果recovery_req为低电平,恢复请求编号为0,此时消息恢复模块会判断恢复请求有效标志。
如果pkt_dropout为高电平,表明数据包序列号检测模块检测到丢包,此时从数据包处理模块得到数据包丢包范围pkt_dropout_numrange[7:0],将此丢包范围发送给数据恢复模块。
如果pkt_dropout为低电平,此时数据包丢包范围pkt_dropout_numrange[7:0]为0,将此丢包范围发送给数据恢复模块,消息恢复模块此时判断数据丢包标志为无效,不需要发送数据恢复包。
接收计时器用在检测心跳包在stream关闭前是否超时,心跳包间隔最大时间限制在配置信息中,当数据包处理模块检测到心跳包到来时,计时器开始计时,当计时大于心跳包间隔最大时间时且当前stream未关闭,则输出一个心跳超时信号。
接收计时器还要用于检测重传恢复数据包是否超时,重传恢复数据包时间间隔限制在配置信息中,当数据包处理模块检测到恢复数据包到来时,计时器开始计时,当计时大于恢复数据包间隔最大时间时且当前stream未关闭,则输出一个重传超时信号。
接收计时器还要用于检测数据包是否超时,数据包时间间隔限制在配置信息中,当数据包处理模块检测到数据包到来时,计时器开始计时,当计时大于数据包间隔最大时间时且当前stream未关闭,则输出一个数据包超时信号。
在FPGA上电后,等待外部配置设备发送配置信息。配置信息包括:每个packet的最大长度(max-Byte),源地址(默认源地址)、目的地址、通道ID、通道分配、通道使能、通道端口、重传请求地址、组播重传数据端口、组播重传请求端口、单播重传数据端口、单播重传请求端口等信息。初始化配置模块将以上信息存储到FPGA内部的bram中,之后在需要读取配置信息时,从bram将信息读取出来。初始化配置完成后输出初始化配置完成标志信号。
消息发送:
消息的发送是由服务器应用程序发出,通过PCIe 3.0 16lane接口下发至FPGA数据加速器卡,FPGA将接收到的消息拆包后,打包成固定格式的数据包通过网口发至网络,同时将其存入历史缓存。消息发送功能包括:发送正常的组播和点播数据包、心跳消息、消息重传处理、消息重传请求等。
这个部分主要介绍DEP Messaging如何通过一个通道去发送数据消息。点对点的数据消息的处理方式和组播消息基本一致,只是点播消息需要提供Target Instance名称。
具体流程:
1.应用程序通过PCIe来发送消息到消息处理模块
2.消息发送模块将整个消息传递给消息拆包模块,消息拆包模块根据消息长度和MTU拆分成若干个消息包
3.对于每个拆包后的消息包,添加一个消息头(Message Header)
4.消息发送模块把消息包传递给数据包发送模块
5.数据包发送模块给每个数据包添加数据包头(Packet Header),并在数据包头的序列号字段填写上最新的序列号(每个数据包递增1)
6.数据包发送模块把要发送出去的数据包存入历史缓存,以便用于重传请求的响应
7.数据包发送模块将数据包传递给数据处理模块
8.数据包处理模块将数据包通过网口发送到网络上
消息发送(心跳消息)
FPGA采用定时器,定期的发送心跳消息,以通知消息接收者通道中数据流的状态与最新的数据包序列号
具体流程:
1.心跳发送模块根据配置的心跳间隔来通知消息发送模块来发送心跳消息(FPGA自己组包)
2.对于存在于每一个通道的数据流,都有自己的一套心跳机制
3.数据包发送模块根据心跳消息的格式准备好心跳消息
4.数据包处理模块将准备好的心跳数据包发送到网络上。
消息发送(消息重传处理)
这部分主要描述DEP Messaging如何处理重传请求消息,以及如何处理重传请求所需要的数据包。
当FPGA接收到了重传请求,FPGA调用消息恢复处理模块将会从历史缓存中找到相应的数据包,并重新发送数据包。
具体流程:
重传请求处理:
1.数据包处理模块收到了重传请求,重传消息包格式见后章节
2.数据包处理模块将请求传递给消息恢复模块
3.消息恢复模块试图在历史缓存中根据序列号,定位到希望重新发送的数据包的位置(根据重传请求数据包中的Begin Sequence,End Sequence)
4.如果所请求的数据包还存在于历史缓存中(因为历史缓存是一个环形缓存,新的数据包可能会覆盖原有的数据包),消息恢复模块将准备发送这些丢失的数据包(具体见“发送重传数据包”流程)
5.如果所请求的数据包不存在于历史缓存中,消息恢复模块将产生一个恢复请求NACK消息,通过数据包处理模块,发送回给重传请求者,表示此次恢复不成功。
发送重传数据包:
1.消息恢复模块准备好发送所请求的丢失数据包给数据包发送模块
2.数据包发送模块将这些数据包发送至网络。
消息发送(消息重传请求)
这部分主要描述DEP Messaging如何发送重传请求消息。
当FPGA在消息接收时发现了有丢包和乱序的情况,会向消息的发布者发送消息重传请求,消息的发布者收到消息重传请求后,将会从消息的发布者的历史缓存中找到相应的数据包,重新发送消息。由于种种原因,多次发送信息重传请求后,仍然有数据丢包,无法组成完整的消息,此时判断为重传请求超时,停止发送重传请求。同时,消息恢复模块发送重传请求超时事件给应用程序。
具体流程:
1.FPGA消息接收时发现了有丢包和乱序的情况
2.FPGA调用消息恢复模块向消息的发布者发送消息重传请求
3.等待发送者补发的数据包
4.如果发送者将重传请求的数据包全部补发并完全接收到,将停止发送重传请求。如果因为各种原因,多次(次数可配置)发送重传请求,都无法接收到,或者是接收到了NACK数据包,则判断为重传请求超时,停止发送重传请求
5.消息恢复模块发送重传请求超时事件给应用程序,并重置RX Buffer、SequenceGap Buffer。
各个功能模块的实现:
消息处理模块接收来自应用程序发送给网口的message,并将消息发送给数据包发送模块。该模块被调用来创建传输通道都会创建一个单独的消息发送模块(messagesender),每个Message Sender表示一个具有序列的独立数据流,每个Message Sender都将把消息发送给数据包发送模块(Packet Sender)。
消息处理模块包括消息发送模块和消息拆包模块。
消息拆包模块的作用是:从应用程序接收到的一个的消息,根据bram中消息长度和MTU信息,将该消息分割成多个消息片段,并将每个片段加上消息头。
数据包发送模块其中一个功能是将消息发送模块发送过来的若干消息段,按照规定的数据格式添加上数据包头,然后将完整的若干个数据包保存在历史缓存(HistoryBuffer),并发送给数据包处理模块。另一个功能就是将心跳消息,按照规定的数据格式,添加上心跳数据包头,并发送给数据包处理模块。
心跳产生模块是产生心跳数据包主要模块,利用了FPGA创建了一个定时器的功能。心跳产生模块主要是由FPGA自身生成,首先根据配置中对心跳间隔时间的设置创建一个定时器,当定时到了以后产生一个timer_come_flag,再由数据包格式生成一个心跳消息发送给数据包发送模块。
数据包处理模块将数据包发送模块发送过来的数据,发送到网络上。
消息恢复模块是可靠UDP中比较重要的部分,分为接收和发送两个模式。如果接收到了重传请求,就意味着接收者没有正确接收到FPGA发送到网络的数据包,此时消息恢复模块要检查历史缓存是否存在重传请求中数据,如果存在并将其重新发送,如果不存在,发送NACK数据包给重传请求者。如果FPGA没有接收到正确的数据包(乱序或者丢包),那么就发送重传请求给发送者请求重传,如果在规定的重传请求次数内(重传次数可以由应用程序配置),通过重传请求后,可以接收到了正确完整的数据,那么就停止重传请求,恢复为正常传输状态;如果在规定的重传请求次数内没有接收到正确完整的数据或者接收到NACK数据包,那么就认为是重传请求超时,以事件的形式通知应用程序,并停止重传请求,恢复为正常传输状态。
接收重传请求:
1.数据包处理模块接收到重传请求
2.数据包处理模块将重传请求数据发送给消息处理模块
3.消息处理模块把本次的重传请求数据存入重传队列,存入时首先判断本次的重传请求是否已经在重传队列中,如果已经存在,则只需要在重传队列的次数记录中自动加1;如果不存在,将本次重传请求存入重传队列,并在对应的重传队列的次数写1.
4.消息恢复模块根据队列中的次数记录数据最大者,在历史缓存中查找重传请求者需要重传的数据包
5.如果历史缓存中可以找到重传请求者需要重传的数据包,那么同时消息处理模块通知历史缓存,将数据发送给数据处理模块,数据处理模块通过网口模块发送到网络
6.如果历史缓存中找不到重传请求者需要重传的数据包,消息处理模块发送NACK数据包给数据处理模块,数据处理模块通过网口模块发送到网络
7.消息处理模块将重传队列中的本条重传请求删除
发送重传请求:
1.Packet Sequencer检测接收数据,如果发现有乱序和丢包
2.如果是心跳数据包检测为乱序和丢包,那么通知消息恢复模块
3.如果是数据接收时检测为乱序和丢包,那么通知消息恢复模块,并将接收到的数据暂存在乱序缓存(Sequence Gap Buffer),乱序缓存r由Block Memory IP生成,以序列号为地址保存数据,这样很方便指导那个序列号对应的数据包丢失,将来通过重传请求得到的补发数据包也可以很方便根据序列号,存入其对应地址。
4.消息恢复模块接收到了乱序和丢包,并判断是乱序和丢包序列号,如果只是乱序而数据包完整,那么通过乱序缓存调整为正确的序列,按照正常处理即可;如果判读是丢包现象,消息处理模块生成重传请求数据包
5.消息处理模块将重传请求数据包发送给数据包处理模块
6.数据包处理模块将重传请求数据包,通过网口模块发送到网络,向发送者请求重传
7.如果在规定的重传请求次数内(重传次数可以由应用程序配置),通过重传请求后,可以接收到了正确完整的数据,并将接收到的数据补充在乱序缓存中,由乱序缓存发送到接收通道队列,那么就停止重传请求,恢复为正常传输状态;
如果在规定的重传请求次数内没有接收到正确完整的数据或者接收到NACK数据包,那么就认为是重传请求超时,以事件的形式通知应用程序,并停止重传请求,复位乱序缓存(Sequence Gap Buffer)和接收缓存(RX Buffer),恢复为正常传输状态。
所谓的加速就是之前这部分功能由上位机软件实现,软件是基于linux操作系统,linux的操作系统在任务切换与中断响应的实时性都大于25us。本系统采用FPGA硬件加速的方式,使用硬件描述语言Verilog,从1至7任意一项的任何模块之间的数据流都控制在5个时钟周期之内,系统的设计主频为250MHz,即一个时钟周期为4ns,所以模块之间的数据流延时最大为20ns,使得计算能力和运行速度提高了上千倍。
可靠UDP组播的FPGA硬件加速系统,除支持标准的UDP协议外,并在原来的基础上增加可靠性通信机制,包括对数据包进行编号,通信时发现乱序和丢包时反馈重发并建立丢包重传等机制。同时,辅以心跳机制,监测网络连接状态。数据包编号、反馈重传、丢包重发、心跳监测等复杂费时的功能,都在FPGA硬件中实现。

Claims (8)

1.一种可靠UDP组播的FPGA硬件加速系统,其特征在于,包括消息处理模块、数据包发送模块、数据包接收模块、数据包处理模块、发送历史缓存模块、接收缓存模块和消息恢复模块;消息处理模块连接数据包发送模块,数据包发送模块连接发送历史缓存模块,发送历史缓存模块连接数据包处理模块和消息恢复模块;数据包处理模块通过接收缓存模块连接数据包接收模块,数据包接收模块和消息恢复模块连接;
消息处理模块用于接收用户消息,并对消息拆包及处理数据包;
数据包发送模块用于数据包的发生和心跳生成;
数据包接收模块用于接收正常或恢复的组播和点播数据包、心跳消息、消息重传请求数据包及消息重传请求失败数据包;
数据包处理模块用于接收缓存,收到发来的数据包将其读入自己的缓存,传递给数据包序列号检测模块,进行数据验证;
消息恢复模块用于比较重传数据包和发送历史缓存模块的范围,判断是否将数据包通过数据包发送模块发送到网络。
2.根据权利要求1所述的一种可靠UDP组播的FPGA硬件加速系统,其特征在于,数据包接收模块包括数据包序列检测单元、乱序缓存单元、错误数据包处理单元、乱序数据包处理单元、心跳数据包处理单元、新数据流产生单元、接收重传请求单元和接收通道队列单元;新数据流产生单元、心跳数据包处理单元、乱序缓存单元、乱序数据包处理单元、错误数据包处理单元、接收通道队列单元和接收重传请求单元均连接到数据包序列检测单元。
3.根据权利要求2所述的一种可靠UDP组播的FPGA硬件加速系统,其特征在于,消息处理模块包括消息发送单元、消息拆包单元、消息组包单元和长消息缓存单元;新数据流产生单元和接收重传请求单元均连接消息处理模块;接收通道队列单元连接到消息组包单元,消息组包单元连接长消息缓存单元。
4.根据权利要求3所述的一种可靠UDP组播的FPGA硬件加速系统,其特征在于,数据包发送模块包括数据包发送单元和心跳生成器;消息拆包单元连接数据包发送单元。
5.根据权利要求4所述的一种可靠UDP组播的FPGA硬件加速系统,其特征在于,数据包处理模块包括数据包接收单元、数据包发送单元和心跳超时处理单元;数据包发送单元连接发送历史缓存模块、数据包发送模块的数据包发送单元和消息恢复模块;数据包接收单元连接心跳超时处理单元、接收缓存模块和消息恢复模块。
6.根据权利要求5所述的一种可靠UDP组播的FPGA硬件加速系统,其特征在于,数据包接收单元、数据包发送单元连接到网络。
7.根据权利要求5所述的一种可靠UDP组播的FPGA硬件加速系统,其特征在于,消息恢复模块包括重传请求发送单元、重传请求超时单元、重传请求接收单元、重传队列单元和发送重传请求单元;重传队列单元、发送重传请求单元、发送历史缓存模块、数据包处理模块的数据包接收单元及数据包发送单元均连接到重传请求接收单元;重传请求发送单元连接数据包接收模块的新数据流产生单元和心跳数据包处理单元。
8.一种可靠UDP组播的FPGA硬件加速方法,其特征在于,基于权利要求1至7任意一项所述的一种可靠UDP组播的FPGA硬件加速系统,包括:
消息发送:
消息处理模块接收到应用程序发送过来的一则消息,如果消息的长度大于设置的数据包的大小,将消息拆解成多组数据,分别对多组数据添加一个消息头,按顺序依次发给数据包发送模块;如果消息的长度不大于设置的数据包的大小,将消息数据添加一个消息头,直接发给数据包发送模块;
数据包发送模块接收到消息处理模块发来的数据,对每一组数据都添加数据包头,并在数据包头的序列号字段填写上最新的序列号,然后将打包好的数据包发送给数据包处理模块,同时也发送给发送历史缓存模块备份,待重传使用;数据包发送模块按照设置的时间,定时产生心跳数据包,定时发送给数据包处理模块;
数据包处理模块接收到数据包发送模块发来的数据包,添加数据包校验位以后,通过网卡发送到网络;
消息接收:
数据包处理模块接收到网络上的数据包,如果接收到重传请求,将数据包发送给消息恢复模块,否则按顺序依次将数据包存入接收缓存模块;
数据包接收模块将数据包从接收缓存模块中读出,对数据包进行如下检查:
数据包长度检查:如果长度不正常,发送坏包事件给消息处理模块,消息处理模块将坏包事件发送给应用程序;
数据包类型检查:如果是NACK数据包,发送数据丢失事件给消息处理模块;
对数据包的序列号进行检查:如果序列号正确,再判断是心跳包直接丢弃,是数据包的话去掉数据包头,发送给消息处理模块,消息处理模块判断如果是完整消息,去掉消息头发送给应用程序,如果此次数据包不能组成一个完整消息,将消息缓存起来,待多组数据包组合后成为完整消息,再发送给应用程序;
如果序列号不正确,且是心跳包,发送心跳包间隙事件给消息处理模块,消息处理模块将数据包丢失事件发送给应用程序,同时发起重传请求给消息恢复模块;
如果序列号不正确,且是数据包,发送数据包间隙事件给消息处理模块,消息处理模块将数据包丢失事件发送给应用程序,同时发起重传请求给消息恢复模块,并将接收到的数据包暂存到乱序缓存中;
Stream ID检查:如果Stream ID是之前没有的,是一个新的Stream ID,发送NewStream ID事件给消息处理模块,消息处理模块将New Stream ID事件发送给应用程序;
消息恢复:
消息恢复模块接收到数据包处理模块的重传请求数据包,放入重传请求队列,然后在发送历史缓存模块查找请求发送的数据包,如果能找到,将发送历史缓存模块的数据包发送给数据包处理模块,数据包处理模块将数据包发送到网络;如果不能找到,发送NACK数据包给数据包处理模块,数据包处理模块将数据包发送到网络;
消息恢复模块接收到数据包接收模块的心跳包间隙重传请求,或者数据包间隙重传请求,产生重传请求数据包,发送给数据包处理模块,数据包处理模块将数据包发送到网络;如果相同的重传请求超过设置的最大次数,则不再发送此重传请求。
CN202311220047.4A 2023-09-20 2023-09-20 一种可靠udp组播的fpga硬件加速系统及方法 Pending CN117278486A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311220047.4A CN117278486A (zh) 2023-09-20 2023-09-20 一种可靠udp组播的fpga硬件加速系统及方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311220047.4A CN117278486A (zh) 2023-09-20 2023-09-20 一种可靠udp组播的fpga硬件加速系统及方法

Publications (1)

Publication Number Publication Date
CN117278486A true CN117278486A (zh) 2023-12-22

Family

ID=89208767

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311220047.4A Pending CN117278486A (zh) 2023-09-20 2023-09-20 一种可靠udp组播的fpga硬件加速系统及方法

Country Status (1)

Country Link
CN (1) CN117278486A (zh)

Similar Documents

Publication Publication Date Title
US11381514B2 (en) Methods and apparatus for early delivery of data link layer packets
CN113728596A (zh) 在网络接口控制器(nic)中促进对幂等操作进行高效管理的系统和方法
US6393023B1 (en) System and method for acknowledging receipt of messages within a packet based communication network
US10430374B2 (en) Selective acknowledgement of RDMA packets
US7693070B2 (en) Congestion reducing reliable transport packet retry engine
US7142539B2 (en) TCP receiver acceleration
US7876751B2 (en) Reliable link layer packet retry
US10791054B2 (en) Flow control and congestion management for acceleration components configured to accelerate a service
CN104025525A (zh) 网络元件关于分组丢弃的通知
US8792512B2 (en) Reliable message transport network
CN104038322A (zh) 中间节点、通信网络及其数据传输控制方法
CN110121868B (zh) 通过被配置为加速服务的加速组件的消息传输
CN103368703B (zh) 数据包重传方法、数据包接收方法及装置
CN112350897B (zh) 基于动态连接端到端可靠传输协议的网络测试装置
RU2651242C1 (ru) Способ передачи данных
US9306769B2 (en) Cell-based link-level retry scheme
WO2008057831A2 (en) Large scale multi-processor system with a link-level interconnect providing in-order packet delivery
CN117278486A (zh) 一种可靠udp组播的fpga硬件加速系统及方法
WO2022000208A1 (zh) 一种数据重传方法和装置
CN113612737A (zh) 一种基于分组与重传机制的长报文可靠传输方法
CN117640511B (zh) 一种有线通信系统及其通信芯片、通信方法及介质
Watson Chapter 7. IPC interface and end-to-end (transport) protocol design issues
Varney The analysis and extension of an existing data link protocol

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination