System.ArgumentOutOfRangeException: 索引和长度必须引用该字符串内的位置。 参数名: length 在 System.String.Substring(Int32 startIndex, Int32 length) 在 zhuanliShow.Bind() 基于全用户态QUIC协议的多模式文件传输方法技术_技高网

基于全用户态QUIC协议的多模式文件传输方法技术

技术编号:42524401 阅读:8 留言:0更新日期:2024-08-27 19:35
本发明专利技术公开了基于全用户态QUIC协议的多模式文件传输方法,涉及数字信息传输技术领域,包括客户端和服务端,客户端包括应用程序、QUIC协议、libevent事件通知库、用户态协议栈和DPDK,多模式文件传输方法包括如下步骤:客户端向服务端请求待传输文件信息,网卡接收服务端下发的数据包,网卡和协议栈之间通过DPDK进行数据包传递,协议栈与应用层之间依赖libevent进行数据包传递,然后应用层将数据包发送到客户端的应用程序,以实现客户端从服务端获取文件信息;该多模式文件传输方法实现了全用户态下的QUIC协议,提高了数据传输效率。

【技术实现步骤摘要】

本专利技术涉及数字信息传输,尤其涉及基于全用户态quic协议的多模式文件传输方法。


技术介绍

1、近些年,随着网络技术的发展,各行各业运作时所产生的数据爆炸式增长,单体文件的容量也在快速增长,文件传输压力陡增。作为网络的基本功能,文件传输对于用户的网络体验和工作效率至关重要,同时,文件传输也是用于检验传输协议性能和网络质量的关键指标。随着文件容量和网络带宽的快速增长,传统的文件传输协议也面临越来越多的问题,提高文件传输的效率迫在眉睫。

2、传统的文件传输方法主要是使用文件传输协议(file transfer protocol,ftp)。用户通过使用支持ftp的客户端连接到在远程的ftp服务端,向服务端发出命令,获取相应的文件。在客户端和服务端的交互过程中,文件和命令的传输均依赖于操作系统内核的传输控制协议(transmission control protocol, tcp)。然而,随着网络技术的发展,网络带宽的快速增长,基于操作系统内核的ftp暴露出以下关键问题,无法满足用户需求。

3、1)操作系统内核协议栈的tcp协议采用了非常保守的拥塞控制算法,比如reno、sack、cubic等,这些启发式拥塞控制算法通过检测丢包来判断网络拥塞,一旦发生丢包,会大幅度减少拥塞窗口,降低传输速率。然而,当下的网络环境,链路带宽高,无线链路占比越来越大,出现丢包不一定是网络拥塞导致的。因此,基于丢包的传统tcp拥塞算法表现不佳。

4、2)操作系统内核协议栈的版本升级依赖于操作系统的更新,难以快速迭代。特别是文件传输协议是基于客户端-服务端架构,仅对服务端系统进行升级,无法满足使用要求,还需要客户端进行同步的系统升级。这种制约使得新研发的更优异的技术无法快速部署到实际应用之中。

5、3)针对于大文件传输场景,传统的基于操作系统内核的数据包收发架构会成为性能瓶颈。第一,网卡在收到数据包后会向cpu发出硬中断,处理频繁的中断,cpu开销非常大;第二,数据包需要在内核协议栈解析,再拷贝到用户空间的应用层,拷贝过程耗时严重;第三,多核服务端跨核处理数据任务,容易导致缓存不命中,降低处理速度。在大文件传输场景下,短时间内会出现大量的巨型长数据包,这三个弊端产生的影响更加明显,严重降低传输效率。


技术实现思路

1、基于
技术介绍
存在的技术问题,本专利技术提出了基于全用户态quic协议的多模式文件传输方法,实现了全用户态下的quic协议,提高了数据传输效率。

2、本专利技术提出的基于全用户态quic协议的多模式文件传输方法,包括客户端和服务端,客户端包括应用程序、quic协议、libevent事件通知库、用户态协议栈和dpdk,多模式文件传输方法包括如下步骤:

3、s1、客户端向服务端请求待传输文件信息;

4、s2、客户端的网卡获取服务端下发的数据包并存入本地的缓冲区,客户端的dpdk通过轮询的方式从客户端的网卡中获取数据包,并将数据包封装到dpdk存放数据包的结构体链表的rte_mbuf结构体中,将dpdk存放数据包的结构体链表转换为用户态协议栈的结构体链表;

5、s3、客户端的应用层的quic协议先初始化事件并设置事件的回调函数,将初始化的事件添加到客户端的libevent事件通知库中,完成事件注册,libevent将libevent事件通知库中初始化后的事件挂载到等待链表中,进入无限循环,等待事件被触发,从用户态协议栈的结构体链表中解析出的数据包触发等待链表中的事件,被触发的事件从等待链表中脱离,变为就绪事件,libevent调用就绪事件的回调函数执行从用户态协议栈读取数据包,并将读取的数据包发送到客户端的应用程序,以实现客户端从服务端获取文件信息。

6、进一步地,所述rte_mbuf结构体头部存放标志信息,所述标志信息包括地址、包长度以及数据长度,在负载部分中预留出头尾空间由用户自定义,其他空间用于存放数据包,对于巨型长数据包,采用多个rte_mbuf结构体链接存储。

7、进一步地,用户态协议栈使用结构体mbuf存放数据包,结构体mbuf由头部和数据区组成,头部占20字节包含链表指针以及数据长度,数据区由108字节构成,用于存放协议首部和数据;

8、在dpdk存放数据包的结构体链表转换为用户态协议栈的结构体链表的转换过程中,更新结构体mbuf头部的控制信息,并在用户态协议栈的结构体链表的头部插入新的结构体,用于标志该批数据包的首部协议。

9、进一步地,客户端和服务端进行数据交互时,设置断点重传策略以保存传输过程中出现的断点信息,断点重传策略包括批量断点重传和单文件断点重传,单文件断点重传具体如下:

10、在客户端和服务端中分别设置窗口表,以保存断点;

11、客户端解析服务端下发的指令,得到需要续传的临时文件,读取出临时文件中文件断点所在分片,并封装成报文发送;

12、服务端解析报文并对解析出的文件进行分片,将分片后的文件挂载到分片链表,对分片链表进行遍历,将已经传过的分片丢弃,并且向客户端回复任务编号以及可以建立的最大连接数目;

13、客户端接收到最大连接数目以及任务编号之后,先按大小建立空白临时文件,按照最大连接数目建立连接,并发送请求分片的报文;

14、服务端接收到请求分片的报文之后,按照多进程摘取分片链表上的分片,并先发送当前文件分片信息,再发送文件分片内容;

15、客户端按照文件分片信息将文件分片内容多进程同时写入空白临时文件;

16、服务端发送最后一个分片时带有cmd_done指令;

17、客户端接收到cmd_done指令,在将文件分片内容全部写入后完成传输,将临时文件更改为正式文件名,实现单文件断点重传。

18、进一步地,在客户端和服务端中分别设置窗口表,以保存断点中,具体为:

19、服务端在发送时,将任务以及对应发送的分片序号存入发送窗口表之中,分片序号随文件分片信息一同发送;

20、在客户端传输时,生成一个发送与接收的窗口表,保存每个任务收到的分片序号;

21、客户端在文件读写时,将文件分片内容先写入本地内存,当进行本地内存刷新时,取序号连续的最大值对应的分片序号写入断点文件,以实现断点保存。

22、进一步地,批量断点重传具体如下:

23、(1)客户端接收命令行指令,解析指令以分离出有效配置信息,客户端配置参数,将目标服务端的相对路径写入报文之中,并发送给服务端,服务端基于接收到的报文找到目标路径位置,获取目标文件夹下的所有文件名,将文件名与目标路径拼接,写入报文并发送回客户端;

24、(2)客户端将报文返回的文件名转为本地目录加文件名的格式;

25、(3)遍历文件名列表是否为空,若不为空,进入步骤(4),若为空进入步骤(5);

26、(4)在客户端原目录下搜索文件是否存在,若存在则进本文档来自技高网...

【技术保护点】

1.基于全用户态QUIC协议的多模式文件传输方法,其特征在于,包括客户端和服务端,客户端包括应用程序、QUIC协议、libevent事件通知库、用户态协议栈和DPDK,多模式文件传输方法包括如下步骤:

2.根据权利要求1所述的基于全用户态QUIC协议的多模式文件传输方法,其特征在于,所述rte_mbuf结构体头部存放标志信息,所述标志信息包括地址、包长度以及数据长度,在负载部分中预留出头尾空间由用户自定义,其他空间用于存放数据包,对于巨型长数据包,采用多个rte_mbuf结构体链接存储。

3.根据权利要求1所述的基于全用户态QUIC协议的多模式文件传输方法,其特征在于,用户态协议栈使用结构体mbuf存放数据包,结构体mbuf由头部和数据区组成,头部占20字节包含链表指针以及数据长度,数据区由108字节构成,用于存放协议首部和数据;

4.根据权利要求1所述的基于全用户态QUIC协议的多模式文件传输方法,其特征在于,客户端和服务端进行数据交互时,设置断点重传策略以保存传输过程中出现的断点信息,断点重传策略包括批量断点重传和单文件断点重传,单文件断点重传具体如下:

5.根据权利要求4所述的基于全用户态QUIC协议的多模式文件传输方法,其特征在于,在客户端和服务端中分别设置窗口表,以保存断点中,具体为:

6.根据权利要求4所述的基于全用户态QUIC协议的多模式文件传输方法,其特征在于,批量断点重传具体如下:

7.根据权利要求1所述的基于全用户态QUIC协议的多模式文件传输方法,其特征在于,服务端与客户端之间进行小文件传输时,所述小文件为32MB以下的文件,通过如下传输策略进行传输:

8.根据权利要求1所述的基于全用户态QUIC协议的多模式文件传输方法,其特征在于,在写完一个文件块则交给客户端子进程解压中,客户端子进程对文件块的解压过程如下:

9.基于全用户态QUIC协议的多模式文件传输方法,其特征在于,包括客户端和服务端,服务端均包括应用程序、QUIC协议、libevent事件通知库、用户态协议栈和DPDK,多模式文件传输方法包括如下步骤:

...

【技术特征摘要】

1.基于全用户态quic协议的多模式文件传输方法,其特征在于,包括客户端和服务端,客户端包括应用程序、quic协议、libevent事件通知库、用户态协议栈和dpdk,多模式文件传输方法包括如下步骤:

2.根据权利要求1所述的基于全用户态quic协议的多模式文件传输方法,其特征在于,所述rte_mbuf结构体头部存放标志信息,所述标志信息包括地址、包长度以及数据长度,在负载部分中预留出头尾空间由用户自定义,其他空间用于存放数据包,对于巨型长数据包,采用多个rte_mbuf结构体链接存储。

3.根据权利要求1所述的基于全用户态quic协议的多模式文件传输方法,其特征在于,用户态协议栈使用结构体mbuf存放数据包,结构体mbuf由头部和数据区组成,头部占20字节包含链表指针以及数据长度,数据区由108字节构成,用于存放协议首部和数据;

4.根据权利要求1所述的基于全用户态quic协议的多模式文件传输方法,其特征在于,客户端和服务端进行数据交互时,设置断点重传策略以保存传输过程中出现的断...

【专利技术属性】
技术研发人员:郑烇钱礼强缪亚王嘉伟杨锋
申请(专利权)人:合肥综合性国家科学中心人工智能研究院安徽省人工智能实验室
类型:发明
国别省市:

网友询问留言 已有0条评论
  • 还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。

1