CN112436924B - 一种数据传输方法及电子设备 - Google Patents

一种数据传输方法及电子设备 Download PDF

Info

Publication number
CN112436924B
CN112436924B CN202011287215.8A CN202011287215A CN112436924B CN 112436924 B CN112436924 B CN 112436924B CN 202011287215 A CN202011287215 A CN 202011287215A CN 112436924 B CN112436924 B CN 112436924B
Authority
CN
China
Prior art keywords
message
transmission
application
transmission channel
time
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.)
Active
Application number
CN202011287215.8A
Other languages
English (en)
Other versions
CN112436924A (zh
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.)
Lenovo Beijing Ltd
Original Assignee
Lenovo Beijing 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 Lenovo Beijing Ltd filed Critical Lenovo Beijing Ltd
Priority to CN202011287215.8A priority Critical patent/CN112436924B/zh
Publication of CN112436924A publication Critical patent/CN112436924A/zh
Application granted granted Critical
Publication of CN112436924B publication Critical patent/CN112436924B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/1607Details of the supervisory signal
    • H04L1/1685Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055Physical resource allocation for ACK/NACK
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

本申请公开了一种数据传输方法及电子设备,方法应用于第一设备中配置的应用接收端,方法包括:通过第一传输通道接收当前的报文传输周期对应的报文集合中的数据报文;至少根据第一传输通道上的传输时延参数和报文传输周期的开始时刻,获得在第一传输通道上报文传输周期对应的接收边界时刻;报文传输周期为第二设备中配置的应用发送端通过第一传输通道发送数据报文的周期;在当前时刻到达接收边界时刻时,获得报文集合中没有被应用接收端接收到的目标数据报文;获得目标数据报文对应的应答报文;至少将应答报文向应用发送端进行传输,以使得应用发送端同时通过第一传输通道和第二传输通道向应用接收端重新发送应答报文对应的目标数据报文。

Description

一种数据传输方法及电子设备
技术领域
本申请涉及通信技术领域,尤其涉及一种数据传输方法及电子设备。
背景技术
在边缘计算的很多应用场景中需要服务器与终端间建立低时延、大带宽、高可靠的无线传输通道。例如高清视频上传、增强现实AR(Augmented Reality)应用中的终端姿态、视频和深度数据上传以及云渲染视频数据下发等。现有的实现一般使用wifi承载,其速率高,保证时延较低,但wifi连接的可靠性不高,时延波动大,移动性差,例如,当终端在wifi的连接点之间漫游时,会出现50-100ms的中断。
为了解决wifi传输可靠性的问题,目前通常采用将wifi与4G技术结合的多通道传输技术,即采用多路径传输控制协议MPTCP(MultiPath Transmission Control Protocol)协议在wifi和4G两个信道上分别建立传输控制协议TCP(Transmission ControlProtocol)子连接,优先使用wifi的TCP子连接进行通信,当TCP的ACK报文指示需要重传时,会在wifi和4G两个信道上同时重传,接收端实现去重和排序。但是,由于采用MPTCP协议需要操作***及网络协议栈支持,而且使用TCP协议会带来TCP协议的一系列问题,无法保证实时视频等应用的低时延。
因此,亟需一种能够兼顾低时延和高可靠的数据传输方案。
发明内容
有鉴于此,本申请提供一种数据传输方法及电子设备,如下:
一种数据传输方法,应用于第一设备中配置的应用接收端,所述方法包括:
通过第一传输通道接收当前的报文传输周期对应的报文集合中的数据报文,所述报文集合中包含多个数据报文;
至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻,获得在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为第二设备中配置的应用发送端通过所述第一传输通道发送数据报文的周期;
在当前时刻到达所述接收边界时刻时,获得所述报文集合中没有被所述应用接收端接收到的目标数据报文;
获得所述目标数据报文对应的应答报文;
至少将所述应答报文向所述应用发送端进行传输,以使得所述应用发送端同时通过所述第一传输通道和第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文。
上述方法,优选的,所述第一传输通道上的传输时延参数至少包含发送时延均值和时延抖动均值;
其中,所述传输时延参数通过在所述第一传输通道传输多个测试报文获得。
上述方法,优选的,至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻,获得在所述第一传输通道上报文传输周期对应的接收边界时刻,包括:
至少根据所述报文传输周期的开始时刻、所述报文传输周期对应的报文总数量、所述传输时延参数和所述第一传输通道上的传输速率,获得在所述第一传输通道上所述报文传输周期对应的接收边界时刻。
上述方法,优选的,所述数据报文的报头中至少包含:
所述报文传输周期对应的报文总数量、所述报文传输周期的周期标识、所述报文传输周期的开始时刻和所述报文传输周期对应的报文集合中所包含数据报文的报文标识,所述报文标识用于所述应用接收端对所述数据报文进行去重处理。
上述方法,优选的,还包括:
至少根据所述第二传输通道的传输时延参数,获得所述应用接收端的最晚重传反馈时刻;
其中,所述最晚重传反馈时刻用于指示所述应用接收端在所述最晚重传反馈时刻或者在所述最晚重传反馈时刻之前的时刻将所述应答报文向所述应用发送端进行传输。
上述方法,优选的,所述最晚重传反馈时刻至少根据最大允许时延、所述第一传输通道的发送时延和/或所述第二传输通道上的发送时延、所述报文传输周期的报文总数量和所述第二传输通道的传输速率获得。
上述方法,优选的,所述方法还包括:
在当前时刻到达所述报文传输周期对应的最晚接收时刻时,判断所述报文集合中是否存在没有被所述应用接收端接收到的数据报文;所述最晚接收时刻根据最大允许时延获得;
如果存在没有被所述应用接收端接收到的数据报文,向所述应用接收端对应的应用传输报文通知,所述报文通知至少用于表征所述报文传输周期内存在数据报文未接收到。
一种数据传输方法,应用于第二设备中配置的应用发送端,所述方法包括:
通过第一传输通道向第一设备中配置的应用接收端传输当前的报文传输周期对应的报文集合中的数据报文;
在接收到所述应用接收端发送的应答报文之后,在本地缓存队列中重新读取所述应答报文对应的目标数据报文;
其中,所述应答报文为所述应用接收端在当前时刻到达所述报文传输周期对应的接收边界时刻时所获得的没有被所述应用接收端接收到的目标数据报文对应的应答报文;所述接收边界时刻为所述应用发送端在通过所述第一传输通道接收到当前的报文传输周期对应的报文集合的数据报文之后至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻所获得的在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为所述应用发送端通过所述第一传输通道发送报文集合的周期,所述报文集合中包含多个数据报文;
同时通过所述第一传输通道和所述第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文。
一种电子设备,包括:
存储器,用于存储应用程序和所述应用程序运行所产生的数据;
处理器,用于执行所述应用程序,以实现:在所述电子设备中配置应用接收端,所述应用接收端用于:
通过第一传输通道接收当前的报文传输周期对应的报文集合中的数据报文,所述报文集合中包含多个数据报文;
至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻,获得在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为其他设备中配置的应用发送端通过所述第一传输通道发送数据报文的周期;
在当前时刻到达所述接收边界时刻时,获得所述报文集合中没有被所述应用接收端接收到的目标数据报文;
获得所述目标数据报文对应的应答报文;
至少将所述应答报文向所述应用发送端进行传输,以使得所述应用发送端同时通过所述第一传输通道和第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文。
一种电子设备,包括:
存储器,用于存储应用程序和所述应用程序运行所产生的数据;
处理器,用于执行所述应用程序,以实现:在所述电子设备中配置应用发送端,所述应用发送端用于:
通过第一传输通道向其他设备中配置的应用接收端传输当前的报文传输周期对应的报文集合中的数据报文;
在接收到所述应用接收端发送的应答报文之后,在本地缓存队列中重新读取所述应答报文对应的目标数据报文;
其中,所述应答报文为所述应用接收端在当前时刻到达所述报文传输周期对应的接收边界时刻时所获得的没有被所述应用接收端接收到的目标数据报文对应的应答报文;所述接收边界时刻为所述应用发送端在通过所述第一传输通道接收到当前的报文传输周期对应的报文集合的数据报文之后至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻所获得的在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为所述应用发送端通过所述第一传输通道发送报文集合的周期,所述报文集合中包含多个数据报文;
同时通过所述第一传输通道和所述第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文。
从上述技术方案可以看出,本申请公开的一种数据传输方法及电子设备中,在应用接收端通过第一传输通道接收应用发送端在当前的报文传输周期对应的报文集合中的数据报文之后,根据第一传输通道上的传输时延参数和报文传输周期的开始时刻预测出第一传输通道上该报文传输周期对应的接收边界时刻,由此在当前时刻到达接收边界时刻时就可以通过获取没有被应用接收端接收到的目标数据报文来生成相应的应答报文,进而在将应答报文传输给应用发送端之后,应用发送端可以同时通过第一传输通道和第二传输通道向应用接收端重新发送应答报文所对应的目标数据报文。可见,本申请中应用接收端在接收应用发送端传输的数据报文的过程中,预测当前的报文传输周期所对应的接收边界时刻,从而及时在接收边界时刻通过应答报文通知应用发送端进行数据报文的重传,从而在保证数据报文传输可靠性的同时减少数据报文的重传时延,从而实现兼顾低时延和高可靠的数据传输。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例一提供的一种数据传输方法的流程图;
图2-图5分别为本申请实施例的示例图;
图6为本申请实施例二提供的一种数据传输方法的流程图;
图7为本申请实施例三提供的一种电子设备的结构示意图;
图8为本申请实施例四提供的一种电子设备的结构示意图;
图9-图13分别为本申请适用于AR终端和服务器之间的数据传输时的示例图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
参考图1,为本申请实施例一提供的一种数据传输方法的实现流程图,该方法可以适用于第一设备中配置的应用接收端,这里的第一设备可以理解为需要进行数据报文接收的电子设备,相应的,需要进行数据报文发送的电子设备可以记为第二设备,如图2中所示,第一设备和第二设备分别可以为手机、pad、AR终端、服务器等中的任意一种。本实施例中的第一设备上配置有应用服务端,即用于接收数据报文的应用接收端,如视频播放的服务端,第二设备上配置有应用客户端,即用于发送数据报文的应用发送端,如视频播放的客户端,在应用客户端和应用服务端之间具有可以不同类型的第一传输通道和第二传输通道,均可以进行数据报文的发送和接收。其中,第一传输通道和第二传输通道为按照传输特性所划分的不同类型的传输通道,第一传输通道和第二传输通道的传输特性不同,例如,第一传输通道为传输带宽较高但传输准确率较低的通道类型,如WiFi等类型的传输通道,而第二传输通道为传输带宽较低但传输准确率较高的通道类型,如4G或5G等类型的传输通道。本实施例中的技术方案主要用于实现低时延和高可靠的数据传输。
具体的,本实施例中的方法可以包括以下步骤:
步骤101:通过第一传输通道接收当前的报文传输周期对应的报文集合中的数据报文。
其中,报文传输周期为第二设备中配置的应用发送端通过所述第一传输通道发送数据报文的周期,如图3中所示,应用发送端对第二设备中待发送的数据报文依次按照报文发送周期进行发送,在每个报文传输周期,应用发送端依次发送报文传输周期对应的报文集合中的数据报文,该报文集合中包含多个数据报文,每个报文传输周期中所传输的数据报文中均具有其所在报文传输周期的周期标识,周期标识表征该数据报文所对应的报文传输周期。
需要说明的是,第二设备中的应用发送端在传输数据报文时,首先通过第一传输通道即低时延高带宽的传输通道如WiFi等向应用接收端传输第二设备中的数据报文,基于此,第一设备中的应用接收端通过第一传输通道接收数据报文。
步骤102:至少根据第一传输通道上的传输时延参数和报文传输周期的开始时刻,获得在第一传输通道上报文传输周期对应的接收边界时刻。
其中,第一传输通道上的传输时延参数是指采用第一传输通道进行数据报文的传输时的时延参数,本实施例中的传输时延参数可以包含有第一传输通道的发送时延均值和时延抖动均值,其中的发送时延均值是指第一传输通道上的平均发送时延,时延抖动均值是指第一传输通道上的发送时延的抖动均值。具体的,传输时延参数可以通过在第一传输通道传输多个测试报文获得。如下:
应用发送端通过第一传输通道向应用接收端依次传输多个测试报文,而应用接收端通过第一传输通道接收应用发送端传输的多个测试报文,基于此,应用接收端可以根据测试报文的接收时刻以及测试报文中的报文时间戳,来获得第一传输通道上的多个发送时延,再根据这些发送时延求平均,得到发送时延均值,并根据这些发送时延中相邻发送时延之间的差值或抖动值来求平均,得到时延抖动均值;而应用发送端可以通过第一传输通道接收到应用接收端所反馈来的传输时延参数;
同理,第二传输通道上的传输时延参数也可以通过在第二传输通道上传输多个测试报文得到,例如:
应用发送端通过第二传输通道向应用接收端依次传输多个测试报文,而应用接收端通过第二传输通道接收应用发送端传输的多个测试报文,基于此,应用接收端可以根据测试报文的接收时刻以及测试报文中的报文时间戳,来获得第二传输通道上的多个发送时延,再根据这些发送时延求平均,得到发送时延均值,并根据这些发送时延中相邻发送时延之间的差值或抖动值来求平均,得到时延抖动均值;而应用发送端可以通过第二传输通道接收到应用接收端所反馈来的传输时延参数。
基于此,应用接收端能够预先获得到第一传输通道的传输时延参数和第二传输通道上的传输时延参数。
另外,本实施例中可以在接收到的数据报文的报头中读取到其所属报文传输周期的开始时刻,该开始时刻可以理解为其所属报文传输周期的第一个数据报文的开始传输的时刻,即第一个数据报文中的报文传输时间戳对应的时刻。
基于此,本实施例中可以至少根据第一传输通道的传输时延参数对报文传输周期的开始时刻进行计算,进而获得到在第一传输通道上报文传输周期对应的接收边界时刻。这里的接收边界时刻是指预测的理论上应该接收到数据报文的结束时刻。具体的,本实施例中在接收到当前的报文传输周期中的数据报文之后,就可以对接收该报文传输周期对应的所有数据报文的结束时刻进行预测,具体可以根据报文传输周期的开始时刻、报文传输周期对应的报文总数量、传输时延参数和第一传输通道上的传输速率等信息,通过计算来获得在第一传输通道上报文传输周期对应的接收边界时刻。
例如,本实施例中在接收到报文传输周期对应的第一个数据报文的情况下,开始预测接收该报文传输周期的最后一个数据报文的接收边界时刻,具体的:在报文传输周期的开始时刻的基础上,叠加第一传输通道上的发送时延均值之后,再叠加该报文传输周期的剩余报文数量(即报文总数量-1)所需要的剩余时长,其中,剩余时长可以将剩余报文数量与报文传输时长均值进行相乘所得到,这里的报文传输时长均值可以在第一传输通道的时延抖动均值的基础上叠加最大传输单元在第一传输通道上的传输时长得到,即如下公式(1)所示:
接收边界时刻=开始时刻+发送时延均值+(报文总数量-1)*(时延抖动均值+最大传输单元/第一传输通道的传输速率)公式(1)
其中,公式(1)中的发送时延均值和时延抖动均值可以为第一传输通道上的传输时延参数。最大传输单元为传输通道上所能够传输的最大的数据包,即MTU(MaximumTransmission Unit)。
再如,本实施例中在接收到报文周期对应的第x个数据报文的情况下,继续预测接收该报文周期的最后一个数据报文的接收边界时刻,具体的:在报文传输周期的开始时刻的基础上,叠加第一传输通道上的发送时延均值后,再叠加该报文传输周期的剩余报文数量(即报文总数量-x)所需要的剩余时长,如下公式(2)所示:
接收边界时刻=开始时刻+发送时延均值+(报文总数量-x)*(时延抖动均值+最大传输单元/第一传输通道的传输速率)公式(2)
具体实现中,应用接收端可以在当前的报文传输周期中已经接收到的数据报文的报头中读取上以上所需要的各项信息,其中,应用发送端发送给应用接收端的数据报文的报头中至少包含有:报文传输周期对应的报文总数量、报文传输周期的周期标识、报文传输周期的开始时刻和报文传输周期对应的报文集合中所包含数据报文的报文标识如报文编号等,这里的报文标识主要用于对报文传输周期中对应的数据报文进行区别标识,也用于对报文传输周期对应的数据报文之间建立关联,例如,通过报文编号将数据报文关联起来。基于此,报文标识可以用于应用接收端对数据报文进行去重处理,还可以用于应用接收端来确定没有被接收到的数据报文。
步骤103:在当前时刻到达接收边界时刻时,获得报文集合中没有被应用接收端接收到的目标数据报文。
其中,本实施例中获得到接收边界时刻之后,持续监测当前时刻是否到达接收边界时刻,在当前时刻到达接收边界时刻时,就可以获得当前的报文传输周期对应的报文集合中没有被应用接收端接收到的目标数据报文。
需要说明的是,本实施例中应用接收端可以通过对已经接收到的数据报文的报头中的信息进行解析,就可以确定没有被接收到的目标数据报文。例如,应用接收端可以提取已经接收到的数据报文的报头中的报文编号,再对这些报文编号进行解析,进而筛选出存在缺失的报文编号,而这些缺失的报文编号对应的数据报文即为没有接收到的目标数据报文。
当然,如果报文集合中的所有数据报文均被应用接收端接收,那么无需执行步骤103及后续步骤。
步骤104:获得目标数据报文对应的应答报文。
其中,本实施例中可以根据目标数据报文的报文标识生成相应的应答报文,例如,将没有被接收到的目标数据报文的报文标识如报文编号等添加到NACK(N-Acknowledgecharacter)报文中,以此表征应用接收端没有接收到这些报文编号所对应的数据报文。
步骤105:至少将应答报文向应用发送端进行传输,以使得应用发送端同时通过第一传输通道和第二传输通道向应用接收端重新发送应答报文对应的目标数据报文。
其中,应用接收端可以通过第一传输通道和/或第二传输通道将应用报文向应用发送端进行传输,由此,在应用发送端接收到应用接收端所发送来的应答报文之后,应用发送端根据应答报文中的报文标识如报文编号等在其本地缓存队列中重新读取这些报文编号对应的目标数据报文,再通过第一传输通道和第二传输通道将目标数据报文重新发送给应用接收端,应用接收端在通过第一传输通道和第二传输通道接收到目标数据报文之后,对目标数据报文进行去重处理,就可以得到完整的当前的报文传输周期所对应的报文集合。
或者,在另一种实现方式中,本实施例中可以在当前时刻到达接收边界时刻时,获得报文集合中已经被应用接收端接收到的数据报文,基于此,再生成这些已经被接收到的数据报文对应的应答报文,例如,将已经被接收到的数据报文的报文编号添加到ACK(Acknowledge character)报文中,以此表征应用接收端已经接收到这些报文编号所对应的数据报文。相应的,在应用发送端接收到这些应答报文如ACK报文之后,可以通过对ACK报文中的报文编号和应用发送端的本地缓存队列中的数据报文的报文编号进行比对,就可以确定已经被应用接收端所接收到的数据报文以及没有被应用接收端所接收到的数据报文,基于此,应用发送端可以在本地缓存队列中重新读取没有被应用接收端所接收到的数据报文,即目标数据报文,再将目标数据报文通过第一传输通道和第二传输通道重新发送给应用接收端,应用接收端在通过第一传输通道和第二传输通道接收到目标数据报文之后,对目标数据报文进行去重处理,就可以得到完整的当前的报文传输周期所对应的报文集合。
需要说明的是,本实施例中的接收边界时刻可以采用应用接收端在接收到报文传输周期对应的第一个数据报文之后所获得到的接收边界时刻,或者,也可以采用应用接收端在接收到报文传输周期对应的中间个数据报文之后所获得到的接收边界时刻,或者,也可以采用应用接收端在每接收到一个数据报文之后所获得的接收边界时刻中的最小值,也就是说,应用接收端每接收到一个数据报文,都会做一次接收边界时刻的预测,并更新一次接收边界时刻,而更新接收边界时刻时,可以将当前预测到的接收边界时刻与原来的接收边界时刻进行比较,进而将更靠前即时刻更小的时刻作为新的接收边界时刻,由此,采用最靠前的接收边界时刻能够使得应用接收端更加及时的向应用发送端反馈没有被接收到的数据报文的应答报文,从而进一步降低传输时延。
由上述方案可知,本申请实施例一提供的一种数据传输方法中,在应用接收端通过第一传输通道接收应用发送端在当前的报文传输周期对应的报文集合中的数据报文之后,根据第一传输通道上的传输时延参数和报文传输周期的开始时刻预测出第一传输通道上该报文传输周期对应的接收边界时刻,由此在当前时刻到达接收边界时刻时就可以通过获取没有被应用接收端接收到的目标数据报文来生成相应的应答报文,进而在将应答报文传输给应用发送端之后,应用发送端可以同时通过第一传输通道和第二传输通道向应用接收端重新发送应答报文所对应的目标数据报文。可见,本实施例中应用接收端在接收应用发送端传输的数据报文的过程中,预测当前的报文传输周期所对应的接收边界时刻,从而及时在接收边界时刻通过应答报文通知应用发送端进行数据报文的重传,从而在保证数据报文传输可靠性的同时减少数据报文的重传时延,从而实现兼顾低时延和高可靠的数据传输。
需要说明的是,本实施例中以第一设备为服务端以第二设备为客户端为例进行说明的实施例,在其他实施例中,第一设备也可以作为客户端,相应的,第二设备可以作为服务端,由第一设备通过其配置的应用发送端向第二设备通过第一传输通道和第二传输通道进行数据报文的传输,而第二设备通过其配置的应用接收端接收第一设备传输来的数据报文。
在一种实现方式中,第一设备中可以只配置有应用接收端,第一设备中的应用接收端向第二设备中的应用发送端传输数据报文,第一设备中的应用接收端也可以作为应用发送端接收第二设备中的应用接收端所传输的数据报文,如图4中所示;
在另一种实现方式中,第一设备中可以分别配置有应用发送端和应用接收端,第一设备中的应用发送端向第二设备中的应用接收端传输数据报文,第一设备中的应用接收端接收第二设备中的应用发送端所传输的数据报文,如图5中所示。
而第二设备中应用发送端和应用接收端的配置可以与第一设备中相同或不同,即:第二设备中也可以只配置有应用发送端,用于向第一设备传输数据报文,此时第二设备中的应用发送端也可以作为应用接收端,用于接收第一设备所传输的数据报文;或者,第二设备中也可以分别配置有应用发送端和应用接收端,第二设备中的应用发送端向第一设备中的应用接收端传输数据报文,第二设备中的应用接收端接收第一设备中的应用发送端所传输的数据报文,参考图4和图5中所示。
在一种实现方式中,应用接收端还可以至少根据第二传输通道的传输时延参数,获得应用接收端的最晚重传反馈时刻,而最晚重传反馈时刻用于指示应用接收端在最晚重传反馈时刻或者在最晚重传反馈时刻之前的时刻将应答报文通过第一传输通道和/或第二传输通道向应用发送端进行传输。
也就是说,应用接收端的最晚重传反馈时刻表征:为了保证数据报文的传输时延在最大允许时延之内,应用接收端最晚可以在该最晚重传反馈时刻向应用发送端反馈应答报文,以使得应用发送端能够及时将需要重传的目标数据报文通过更可靠的第二传输通道和更低时延的第一传输通道传输给应用接收端,从而保证应用发送端的报文传输周期内的数据报文能够在最大允许时延的范围内传输到应用接收端。
具体的,本实施例中可以通过对第二传输通道的传输时延参数如发送时延等数据进行处理,来得到最晚重传反馈时刻。例如,应用接收端可以根据预设的最大允许时延、第一传输通道上的发送时延和/或第二传输通道上的发送时延、报文总数量和第二传输通道上的传输速率来获得最晚重传反馈时刻。具体如下:
本实施例中,应用接收端根据最大允许时延和当前的报文传输周期的开始时刻确定当前的报文传说周期的最晚接收时刻,该最晚接收时刻为允许接收当前的报文传输周期的数据报文的最晚时刻,超过这一最晚接收时刻,可以认为后续所接收到的数据报文为无效报文;之后,应用接收端在最晚接收时刻的基础上,扣除往返传输时延之后,再扣除报文传输周期中对应的剩余报文数量在第二传输通道上的传输剩余时长,由此得到最晚重传反馈时刻。其中的往返传输时延为在第一传输通道和/或第二传输通道上的发送时延的叠加,需要说明的是,往返传输时延具体可以为第一传输通道上的发送时延的两倍,或者也可以为第二传输通道上的发送时延的两倍,或者也可以为第一传输通道上的发送时延叠加第二传输通道上的发送时延。而传输剩余时长可以通过将剩余报文数量乘以最大传输单元在第二传输通道上的传输时长来获得,最大传输单元在第二传输通道上的传输时长可以通过将最大传输单元除以第二传输通道上的传输速率来得到,以如下公式(3)表示:
最晚重传反馈时刻=最晚接收时刻-第二传输通道上的往返传输时延-(最大传输单元/第二传输通道上的传输速率)*当前的报文传输周期中的剩余报文数量公式(3)
在另一种实现方式中,最晚重传反馈时延具有初值,初值可以为:在最晚接收时刻的基础上,扣除往返传输时延之后,再扣除具有最大报文数量的报文传输周期在第二传输通道上的传输时长和报文传输周期对应的周期时长内所能够发送的最大传输单元的总数在第二传输通道上的传输时长之间的最大值,由此得到最晚重传反馈时刻,以如下公式(4)表示:
初值=最晚接收时刻-第二传输通道上的往返传输时延-(MTU/第二传输通道上的传输速率)*MAX(报文传输周期的最大报文数,业务流速率*周期时长/MTU)公式(4)
需要说明的是,本实施例中的传输速率可以通过物理层速率进行折算,从而获得到应用程上相应传输通道的传输速率,或者,本实施例中的传输速率采用预设值。
基于此,本实施例中还可以将当前的报文周期对应的接收边界时刻与最晚重传反馈时刻进行比较,进而将更小即时刻更早的时刻作为接收边界时刻,即向应用发送端反馈没有接收到的数据报文的时刻。
进一步的,本实施例中应用接收端在当前时刻到达报文传输周期对应的最晚接收时刻时,还可以判断报文集合中是否存在没有被应用接收端接收到的数据报文,例如,应用接收端通过对接收到的数据报文的报头信息进行提取,进而根据报头中的报文标识如报文编号等确定是否存在数据报文缺失,如果存在没有被应用接收端接收到的数据报文,那么应用接收端向应用接收端对应的应用传输报文通知,该报文通知至少用于表征报文传输周期内存在报文未接收到,即没有完整接收该报文传输周期内的所有数据报文,如果报文传输到周期对应的所有数据报文均被应用接收端接收到,那么应用接收端将接收到的该报文传输周期内的所有数据报文进行重组后传输给应用接收端对应的应用,如手机或pad上的视频播放应用等。
另外,应用接收端在开始接收当前的报文传输周期内的数据报文之后,可以与应用发送端之间进行周期同步,例如,应用接收端根据已经接收到的数据报文的报头上的周期标识如周期编号、报文总数量、周期开始时间戳和周期内的报文编号等来实现周期同步。例如,在已经得到周期的开始时刻之后,根据预设的最大允许时延获得该周期的最晚接收时刻,同时确定下一个周期的开始边界。
参考图6,为本申请实施例二提供的一种数据传输方法的实现流程图,该方法可以适用于第二设备中配置的应用发送端,如图2中所示的第二设备中的应用发送端。本实施例中的技术方案主要用于实现低时延和高可靠的数据传输。
具体的,本实施例中的方法可以包括以下步骤:
步骤601:通过第一传输通道向第一设备中配置的应用接收端传输当前的报文传输周期对应的报文集合中的数据报文。
步骤602:接收所述应用接收端发送的应答报文。
步骤603:在本地缓存队列中重新读取应答报文对应的目标数据报文。
其中,所述应答报文为所述应用接收端在当前时刻到达所述报文传输周期对应的接收边界时刻时所获得的没有被所述应用接收端接收到的目标数据报文对应的应答报文;所述接收边界时刻为所述应用发送端在通过所述第一传输通道接收到当前的报文传输周期对应的报文集合的数据报文之后至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻所获得的在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为所述应用发送端通过所述第一传输通道发送报文集合的周期,所述报文集合中包含多个数据报文;
步骤604:同时通过第一传输通道和第二传输通道向应用接收端重新发送应答报文对应的目标数据报文。
由上述方案可知,本申请实施例二提供的一种数据传输方法中,在应用接收端通过第一传输通道接收应用发送端在当前的报文传输周期对应的报文集合中的数据报文之后,根据第一传输通道上的传输时延参数和报文传输周期的开始时刻预测出第一传输通道上该报文传输周期对应的接收边界时刻,由此在当前时刻到达接收边界时刻时就可以通过获取没有被应用接收端接收到的目标数据报文来生成相应的应答报文,进而在将应答报文传输给应用发送端之后,应用发送端根据所接收到的应答报文在本地缓存队列中重新读取相应的目标数据报文,之后,应用发送端可以同时通过第一传输通道和第二传输通道向应用接收端重新发送应答报文所对应的目标数据报文。可见,本申请中应用接收端在接收应用发送端传输的数据报文的过程中,预测当前的报文传输周期所对应的接收边界时刻,从而及时在接收边界时刻通过应答报文通知应用发送端进行数据报文的重传,从而在保证数据报文传输可靠性的同时减少数据报文的重传时延,从而实现兼顾低时延和高可靠的数据传输。
参考图7,为本申请实施例三提供的一种电子设备的结构示意图,该电子设备可以为进行数据报文接收的设备,如手机、pad、AR终端或服务器等,如图2中所示的第一设备。本实施例中的技术方案主要用于实现低时延和高可靠的数据传输。
具体的,本实施例中的电子设备可以包括以下结构:
存储器701,用于存储应用程序和所述应用程序运行所产生的数据;
处理器702,用于执行所述应用程序,以实现:在所述电子设备中配置应用接收端,所述应用接收端用于:
通过第一传输通道接收当前的报文传输周期对应的报文集合中的数据报文,所述报文集合中包含多个数据报文;
至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻,获得在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为其他设备中配置的应用发送端通过所述第一传输通道发送数据报文的周期;
在当前时刻到达所述接收边界时刻时,获得所述报文集合中没有被所述应用接收端接收到的目标数据报文;
获得所述目标数据报文对应的应答报文;
至少将所述应答报文向所述应用发送端进行传输,以使得所述应用发送端同时通过所述第一传输通道和第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文。
当前,本实施例中的电子设备中还可以包含能够进行数据报文传输的通信模块703,如WiFi模块和4G模块,WiFi模块用于实现第一传输通道,4G模块用于实现第二传输通道。
从上述技术方案可以看出,本申请实施例三提供的一种电子设备中,在应用接收端通过第一传输通道接收应用发送端在当前的报文传输周期对应的报文集合中的数据报文之后,根据第一传输通道上的传输时延参数和报文传输周期的开始时刻预测出第一传输通道上该报文传输周期对应的接收边界时刻,由此在当前时刻到达接收边界时刻时就可以通过获取没有被应用接收端接收到的目标数据报文来生成相应的应答报文,进而在将应答报文传输给应用发送端之后,应用发送端可以同时通过第一传输通道和第二传输通道向应用接收端重新发送应答报文所对应的目标数据报文。可见,本实施例中应用接收端在接收应用发送端传输的数据报文的过程中,预测当前的报文传输周期所对应的接收边界时刻,从而及时在接收边界时刻通过应答报文通知应用发送端进行数据报文的重传,从而在保证数据报文传输可靠性的同时减少数据报文的重传时延,从而实现兼顾低时延和高可靠的数据传输。
需要说明的是,本实施例中处理器的具体实现可以参考前文中的相应内容,此处不再详述。
参考图8,为本申请实施例四提供的一种电子设备的结构示意图,该电子设备可以为进行数据报文发送的设备,如手机、pad、AR终端或服务器等,如图2中所示的第二设备。本实施例中的技术方案主要用于实现低时延和高可靠的数据传输。
具体的,本实施例中的电子设备可以包括以下结构:
存储器801,用于存储应用程序和所述应用程序运行所产生的数据;
处理器802,用于执行所述应用程序,以实现:在所述电子设备中配置应用发送端,所述应用发送端用于:
通过第一传输通道向其他设备中配置的应用接收端传输当前的报文传输周期对应的报文集合中的数据报文;
在接收到所述应用接收端发送的应答报文之后,在本地缓存队列中重新读取所述应答报文对应的目标数据报文;
其中,所述应答报文为所述应用接收端在当前时刻到达所述报文传输周期对应的接收边界时刻时所获得的没有被所述应用接收端接收到的目标数据报文对应的应答报文;所述接收边界时刻为所述应用发送端在通过所述第一传输通道接收到当前的报文传输周期对应的报文集合的数据报文之后至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻所获得的在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为所述应用发送端通过所述第一传输通道发送报文集合的周期,所述报文集合中包含多个数据报文;
同时通过所述第一传输通道和所述第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文。
当前,本实施例中的电子设备中还可以包含能够进行数据报文传输的通信模块803,如WiFi模块和4G模块,WiFi模块用于实现第一传输通道,4G模块用于实现第二传输通道。
由上述方案可知,本申请实施例四提供的一种电子设备中,在应用接收端通过第一传输通道接收应用发送端在当前的报文传输周期对应的报文集合中的数据报文之后,根据第一传输通道上的传输时延参数和报文传输周期的开始时刻预测出第一传输通道上该报文传输周期对应的接收边界时刻,由此在当前时刻到达接收边界时刻时就可以通过获取没有被应用接收端接收到的目标数据报文来生成相应的应答报文,进而在将应答报文传输给应用发送端之后,应用发送端根据所接收到的应答报文在本地缓存队列中重新读取相应的目标数据报文,之后,应用发送端可以同时通过第一传输通道和第二传输通道向应用接收端重新发送应答报文所对应的目标数据报文。可见,本实施例中应用接收端在接收应用发送端传输的数据报文的过程中,预测当前的报文传输周期所对应的接收边界时刻,从而及时在接收边界时刻通过应答报文通知应用发送端进行数据报文的重传,从而在保证数据报文传输可靠性的同时减少数据报文的重传时延,从而实现兼顾低时延和高可靠的数据传输。
需要说明的是,本实施例中处理器的具体实现可以参考前文中的相应内容,此处不再详述。
以下以AR终端和服务器之间进行数据报文传输为例,对本申请的技术方案进行举例说明:
本申请中针对由于使用TCP协议无法保证实时视频等应用的时延的技术问题,提出以下方案:
本申请中,将多个传输通道分为两类,其中一类为大带宽、低资费、低可靠通道,例如wifi或家庭宽带的传输通道,另一类为高资费、高可靠通道,例如4G或5G或专线的传输通道。本申请中将前者作为主用通道,也可以简称为主通道,即前文中的第一传输通道,后者作为备用通道,即第二传输通道。在本申请中,数据报文优先在设定的主用通道中传输,当主用通道故障使得数据报文的传输时延超过设定时间,那么再在备用通道上重传。
本申请中由应用根据自身业务周期(报文传输周期)产生和发送数据的特点,在应用接收端根据近期正确接收报文的时延和抖动,预测下一周期报文的接收窗口(如接收边界时刻),如果在接收窗口内未收到报文或只收到部分报文,则及时通知发送端在主、辅通道上重发该周期的残缺报文,即降低了重传时延又节省了辅通道的流量。
基于此,本申请中可以在用户空间实现,有利于使用和部署。具体实现中,本申请优先使用低资费的通道传输报文,当出现错误时,再使用高资费高可靠的通道重传,大大降低了成本和对备用通道容量的要求。而且,本申请中根据时延保证计算的重发时机,可以在保证时延的前提下,节省不必要的重发。另外,由于实时视频流等应用的数据报文有较高的时效性,超过指定时延的报文不再有价值,因此本申请中只是通过高可靠的通道重发一次,减少了信道恶劣情况下拥塞的可能性。最重要的是,本申请中充分利用应用实时业务流的周期性来预测接收窗口,及时反馈和重发丢失的报文,减小了重发时延又节省了辅通道的流量。
具体实现中,本申请中的应用可以为实时视频、音频、传感器数据(XR应用中的姿态数据)等,它们的特点为数据是周期产生和周期发送的,对传输的实时性要求较高,通常通过用户数据报协议UDP(UserDatagramProtocol)协议发送,但由于单纯的UDP协议无法满足其传输可靠性的需求,需要通过其他措施来满足需求。而在当前的无线移动应用场景中,终端具备了wifi、4G/5G等多种制式或双频wifi等的多通道传输方式。本申请中的应用发送端、应用接收端为具备多通道通信能力的端点设备。它们通过主辅通道和下面描述的重传机制来保证通信链路的实时性和可靠性。
如图9中所示,端点设备(电子设备)可以只包含应用发送端或应用接收端,也可以即包含应用发送端又包含应用接收端。为了描述方便,下面假设其中一个端点设备为信源设备只包含应用发送端,可以简称为发送端,另一个为信宿设备只包含应用接收端,可以简称为接收端。每个端点设备上都有主通道和辅通道两类通信信道。其中主通道带宽宽、资费低、可靠性差(例如wifi、互联网宽带等)。辅通道带宽较窄、资费高、可靠性高(例如4G/5G、专线等)。
本申请中,在正式业务开展前应用发送端和接收端之间会协商业务的周期和速率等参数,除此之外,在本申请里接收端还会在发送端的配合下测量主、备通道的时延和抖动,用于之后的业务通信。
某个端点设备发起业务请求前,预先设定好该设备的主、辅通道(通过源、目的IP以及源目的端口组成的4元组区分)。通过其主通道向对端设备发起业务请求(可以采用TCP协议,并保持长连接)。业务请求流程中除了交互具体应用的参数信息外,还包含单个业务流的主、辅通道4元组的协商、单个业务流的周期、最大允许时延以及主辅通道的时延和抖动测量。例如终端向视频服务器请求实时视频,终端上的视频应用设定主通道为wifi(IP地址为192.168.0.2终端的),辅通道为4G(IP地址为10.0.0.2),终端上的视频应用优先通过wifi接口向视频服务器指定主通道地址(假设为192.168.0.3,服务器的)和端口(5050)发起业务请求,期间通过特定的应用层信令告知服务器其视频流主通道的地址为192.168.0.2,端口为辅通道的地址为10.0.0.2。进一步协商终端和服务器主备通道的端口地址。
然后在主备通道上由未来的应用发送端向接收端(即服务器向终端)连续发送M个测试报文(报文包含时间戳),接收端测量主备通道上从发送端到接收端的传输平均时延Tsd和平均抖动Jsd。然后再由接收端向发送端连续发送M个测试报文(也可以理解为是心跳报文),发送端测量主备通道上从接收端到发送端的传输时延Tds和平均抖动Jds。时延的测量方法类似RTCP协议的时延计算:
1、在发送端设置rtp包的时间戳公式为:ts_current_90000hz=(当前***时间ms-start_time_ms)*90000.0/1000.0;
2、在接收端根据这个公式可以估算出一个rtp的延迟delay=lastest_recv_time-(last_rtp_recv_time+(lastest_rtp_ts-last_rtp_ts)/90)。
其中,平均时延需要对M个测试报文的时延取平均得到平均时延。而时延抖动的计算是基于计算相邻报文的时延差值的绝对值统计,计算均值得到。
另外,接收端还会与发送端对齐本地时间的差值,用于后续业务周期边界的对齐。
本申请中,在正式业务阶段,应用发送端以业务周期发送突发的业务流报文,并优先采用主通道发送。应用接收端通过接收到的第一个周期的报文与发送端实现周期同步(周期边界对齐)。在接收第N周期的报文前,会根据之前测得的平均时延和抖动均值、方差,预测对应接收通道上第N周期报文的接收窗口。如果在该接收窗口内未收到完整报文,则会向发送端反馈缺失的报文序号(报文编号),等待发送端重发这些报文并进行处理。同时会继续统计主通道的时延和抖动,用于后续周期的报文预测和接收。
为了让接收端能监控时延、识别每个周期的突发报文,应用发送端需要将周期编号、本周期报文总数、周期开始时间戳和周期内的报文序号等信息加载在每个报文头上。由于本申请假设实时的应用业务报文承载在UDP协议上,为了避免IP层的分片和重组带来的时延和报文损失,应用层需确保报文长度加额外的报文头后小于MTU。应用接收端从对应socket上收到报文后,立即根据其报文头信息进行处理。如果还未与发送端实现周期同步,则通过报文头上的周期编号、本周期报文总数、周期开始时间戳和周期内的报文序号来实现同步(已得到该周期的开始边界,并根据预设的最大允许时延得到该周期的最晚接收时间,同时确定了下一周期的开始边界)。如果已同步则根据之前计算的平均时延和抖动方差,结合该周期的报文数量预测该周期的接收窗边界,并根据辅通道的往返传输时延更新该周期的最晚重传反馈时间。计算公式如下:
本周期预测接收窗边界=本周期开始时间+平均时延+(本周期报文数-1)*(时延抖动均值+MTU/主通道传输速率)。
本周期最晚重传反馈时间=本周期最晚接收时间-辅通道往返传输时延-(MTU/辅通道传输速率)*本周期未收到报文数。
本周期最晚重传反馈时间初值=本周期最晚接收时间-辅通道往返传输时延-(MTU/辅通道传输速率)*Max(统计单周期最大报文数,业务流速率*周期时长/MTU)。
其中,主通道的平均时延、时延抖动均值可以通过计算每个周期内报文的平均时延和时延抖动均值采用滑动平均的方式反映最近一段时间主通道的信道状态。辅通道的传输速率可以通过访问设备的辅通道管理接口获取(例如wifi可以直接得到实时的物理层速率,通过大致折算可以得到应用层传输速率;4G\5G的应用层传输速率可以通过物理层参数带宽和信噪比估算),也可以通过最近的辅通道上的通信统计得到或者简单的预置一个服务等级保证值(SLA)。基于此,将该周期的预测接收窗边界与该周期最晚重传反馈时间进行比较,取最早的时间作为本周期的反馈时间,如图10中所示。
基于此,接收端一边继续接收、解析本周期报文的包头,一边检测本周期的反馈时间是否到达。如果本周期的反馈时间到,且有未收到的报文,则组织NACK报文通过主、辅通道向发送端反馈本周期的周期序号和本周期报文收到情况的bitmap(收到置1,未收到置0)。如果本周期未收到任何报文,则反馈全0。如果已收到了所有报文,则无需反馈。接收端继续从主辅通道接收本周期报文并丢弃重复收到的报文,直到本周期最晚接收时间到达或本周期所有报文已接收,此时将收齐的报文重组后送往应用上层。如果直到本周期最晚接收时间仍未收齐本周期所有报文则丢弃本周期的报文,并通知应用上层。由于接收周期N的报文可能和周期N+1及之后周期的报文发生部分重合,因此在接收端需要根据以上描述的流程同时处理多个周期的报文接收。
发送端收到NACK报文后,从主、辅通道上重发未收到的报文,报文头信息保持和原报文相同。发送端通过简单的缓存最近L个周期的报文,来保证重传报文的可获得性。
另外,主辅通道上可以通过心跳报文的传输实现状态监测:
由于业务流和TCP长连接心跳都是通过主通道周期发送,因此主通道不需要额外的监测。
而辅通道由端点设备中作为接收端的设备周期向对端发送(一般为秒级以上)心跳报文保持连接。对端通过辅通道发送心跳应答。
端点设备在辅通道于设定的N个周期内未收到心跳或心跳应答报文,则认为该通道挂起。通道挂起后仍然尝试在该通道上发送和接收心跳或心跳应答,如果再次收到心跳或心跳应答,则该通道恢复正常。
端点设备通过心跳和心跳应答测量辅通道的往返时延和速率。为了尽量准确测量辅通道速率,心跳报文被填充到MTU长度。
停止业务类似于业务请求,其中一个端点设备通过主通道使用TCP协议向对端的业务请求端口发送停止业务请求,得到确认后,即停止业务流的发送和接收。
其中,NACK报文的结构如图11中所示,NACK报文中包含IP头、UDP头、报文类型(如数据报文、应答报文或控制报文等报文类型)、周期序号和bitmap等字段,其中,报文类型字段为ACK类型的指定值,例如0x01等。业务流报文的结构如图12中所示,业务流报文中除了包含有IP头和UDP头之外,还包含有报文类型、报文头和业务流数据包等字段,其中,报文类型字段为数据类型的指定值,例如0x00等。心跳报文中除了包含有IP头和UDP头之外,还包含有报文类型、序号、时间戳和padding等字段,如图13中所示,其中,报文类型字段为心跳类型的指定值,例如0x02。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下,在其它实施例中实现。因此,本申请将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种数据传输方法,应用于第一设备中配置的应用接收端,所述方法包括:
通过第一传输通道接收当前的报文传输周期对应的报文集合中的数据报文,所述报文集合中包含多个数据报文;
至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻,获得在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为第二设备中配置的应用发送端通过所述第一传输通道发送数据报文的周期;
在当前时刻到达所述接收边界时刻时,获得所述报文集合中没有被所述应用接收端接收到的目标数据报文;
获得所述目标数据报文对应的应答报文;
至少将所述应答报文向所述应用发送端进行传输,以使得所述应用发送端同时通过所述第一传输通道和第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文,所述第一传输通道和第二传输通道的传输特性不同,所述传输特性包括时延和传输带宽。
2.根据权利要求1所述的方法,所述第一传输通道上的传输时延参数至少包含发送时延均值和时延抖动均值;
其中,所述传输时延参数通过在所述第一传输通道传输多个测试报文获得。
3.根据权利要求1或2所述的方法,至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻,获得在所述第一传输通道上报文传输周期对应的接收边界时刻,包括:
至少根据所述报文传输周期的开始时刻、所述报文传输周期对应的报文总数量、所述传输时延参数和所述第一传输通道上的传输速率,获得在所述第一传输通道上所述报文传输周期对应的接收边界时刻。
4.根据权利要求3所述的方法,所述数据报文的报头中至少包含:
所述报文传输周期对应的报文总数量、所述报文传输周期的周期标识、所述报文传输周期的开始时刻和所述报文传输周期对应的报文集合中所包含数据报文的报文标识,所述报文标识用于所述应用接收端对所述数据报文进行去重处理。
5.根据权利要求1所述的方法,还包括:
至少根据所述第二传输通道的传输时延参数,获得所述应用接收端的最晚重传反馈时刻;
其中,所述最晚重传反馈时刻用于指示所述应用接收端在所述最晚重传反馈时刻或者在所述最晚重传反馈时刻之前的时刻将所述应答报文向所述应用发送端进行传输。
6.根据权利要求5所述的方法,所述最晚重传反馈时刻至少根据最大允许时延、所述第一传输通道的发送时延和/或所述第二传输通道上的发送时延、所述报文传输周期的报文总数量和所述第二传输通道的传输速率获得。
7.根据权利要求5所述的方法,所述方法还包括:
在当前时刻到达所述报文传输周期对应的最晚接收时刻时,判断所述报文集合中是否存在没有被所述应用接收端接收到的数据报文;所述最晚接收时刻根据最大允许时延获得;
如果存在没有被所述应用接收端接收到的数据报文,向所述应用接收端对应的应用传输报文通知,所述报文通知至少用于表征所述报文传输周期内存在数据报文未接收到。
8.一种数据传输方法,应用于第二设备中配置的应用发送端,所述方法包括:
通过第一传输通道向第一设备中配置的应用接收端传输当前的报文传输周期对应的报文集合中的数据报文;
在接收到所述应用接收端发送的应答报文之后,在本地缓存队列中重新读取所述应答报文对应的目标数据报文;
其中,所述应答报文为所述应用接收端在当前时刻到达所述报文传输周期对应的接收边界时刻时所获得的没有被所述应用接收端接收到的目标数据报文对应的应答报文;所述接收边界时刻为所述应用发送端在通过所述第一传输通道接收到当前的报文传输周期对应的报文集合的数据报文之后至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻所获得的在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为所述应用发送端通过所述第一传输通道发送报文集合的周期,所述报文集合中包含多个数据报文;
同时通过所述第一传输通道和第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文,所述第一传输通道和第二传输通道的传输特性不同,所述传输特性包括时延和传输带宽。
9.一种电子设备,包括:
存储器,用于存储应用程序和所述应用程序运行所产生的数据;
处理器,用于执行所述应用程序,以实现:在所述电子设备中配置应用接收端,所述应用接收端用于:
通过第一传输通道接收当前的报文传输周期对应的报文集合中的数据报文,所述报文集合中包含多个数据报文;
至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻,获得在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为其他设备中配置的应用发送端通过所述第一传输通道发送数据报文的周期;
在当前时刻到达所述接收边界时刻时,获得所述报文集合中没有被所述应用接收端接收到的目标数据报文;
获得所述目标数据报文对应的应答报文;
至少将所述应答报文向所述应用发送端进行传输,以使得所述应用发送端同时通过所述第一传输通道和第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文,所述第一传输通道和第二传输通道的传输特性不同,所述传输特性包括时延和传输带宽。
10.一种电子设备,包括:
存储器,用于存储应用程序和所述应用程序运行所产生的数据;
处理器,用于执行所述应用程序,以实现:在所述电子设备中配置应用发送端,所述应用发送端用于:
通过第一传输通道向其他设备中配置的应用接收端传输当前的报文传输周期对应的报文集合中的数据报文;
在接收到所述应用接收端发送的应答报文之后,在本地缓存队列中重新读取所述应答报文对应的目标数据报文;
其中,所述应答报文为所述应用接收端在当前时刻到达所述报文传输周期对应的接收边界时刻时所获得的没有被所述应用接收端接收到的目标数据报文对应的应答报文;所述接收边界时刻为所述应用发送端在通过所述第一传输通道接收到当前的报文传输周期对应的报文集合的数据报文之后至少根据第一传输通道上的传输时延参数和所述报文传输周期的开始时刻所获得的在所述第一传输通道上报文传输周期对应的接收边界时刻;所述报文传输周期为所述应用发送端通过所述第一传输通道发送报文集合的周期,所述报文集合中包含多个数据报文;
同时通过所述第一传输通道和第二传输通道向所述应用接收端重新发送所述应答报文对应的目标数据报文,所述第一传输通道和第二传输通道的传输特性不同,所述传输特性包括时延和传输带宽。
CN202011287215.8A 2020-11-17 2020-11-17 一种数据传输方法及电子设备 Active CN112436924B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011287215.8A CN112436924B (zh) 2020-11-17 2020-11-17 一种数据传输方法及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011287215.8A CN112436924B (zh) 2020-11-17 2020-11-17 一种数据传输方法及电子设备

Publications (2)

Publication Number Publication Date
CN112436924A CN112436924A (zh) 2021-03-02
CN112436924B true CN112436924B (zh) 2022-04-22

Family

ID=74700234

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011287215.8A Active CN112436924B (zh) 2020-11-17 2020-11-17 一种数据传输方法及电子设备

Country Status (1)

Country Link
CN (1) CN112436924B (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113242113A (zh) * 2021-04-30 2021-08-10 北京汇钧科技有限公司 数据传输控制方法、装置、电子设备及存储介质
CN114401076A (zh) * 2021-11-30 2022-04-26 中国铁路通信信号股份有限公司 一种降低以太网数据传输晃动的方法和装置
CN115065442B (zh) * 2022-08-16 2022-11-18 深圳星云智联科技有限公司 数据传输方法及相关装置
CN115733710B (zh) * 2022-11-18 2024-04-26 苏州挚途科技有限公司 报文发送方法、目标节点、非目标节点与报文传输***
CN116450380A (zh) * 2023-06-09 2023-07-18 北京集度科技有限公司 一种消息处理方法、电子设备及计算机可读存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109039552A (zh) * 2018-09-20 2018-12-18 郑州云海信息技术有限公司 一种数据恢复方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101741524B (zh) * 2008-11-21 2012-07-11 电信科学技术研究院 一种确定最小重传时间间隔的方法、***和装置
CN102608979B (zh) * 2012-03-21 2013-11-27 山东省科学院自动化研究所 Can总线调度分析及监控***
US9503837B2 (en) * 2012-10-08 2016-11-22 Lg Electronics Inc. Method and apparatus for performing HARQ process in wireless communication system
WO2015048361A1 (en) * 2013-09-30 2015-04-02 Apple Inc. Delayed and bundled retransmissions for low bandwidth applications
US10568092B2 (en) * 2017-02-17 2020-02-18 Qualcomm Incorporated Scheduling and/or scheduling configuration
EP3787324B1 (en) * 2018-04-26 2022-10-12 Beijing Xiaomi Mobile Software Co., Ltd. Harq feedback method and apparatus
CN108809859A (zh) * 2018-07-05 2018-11-13 清华大学 一种面向数据包截止时间的传输层控制方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109039552A (zh) * 2018-09-20 2018-12-18 郑州云海信息技术有限公司 一种数据恢复方法及装置

Also Published As

Publication number Publication date
CN112436924A (zh) 2021-03-02

Similar Documents

Publication Publication Date Title
CN112436924B (zh) 一种数据传输方法及电子设备
US11611498B2 (en) Round-trip time evaluation system, method, and apparatus
US9655003B2 (en) Systems and methods for improved wireless interface aggregation
EP3322145B1 (en) Method, server side and system for computing bandwidth of network transmission of streaming media
EP1568180B1 (en) A method for enhancing transmission quality of streaming media
US9325628B2 (en) Packet handling method, forwarding device and system
EP3075110B1 (en) Controlling a transmission control protocol window size
CN106210924B (zh) 视频网络传输控制方法和***
CN112436994B (zh) 一种数据传输方法及电子设备
US9167473B2 (en) Communication processing method, apparatus and gateway device
JP2014143760A (ja) 通信装置、通信システム、およびデータ通信の中継方法
WO2011093835A1 (en) A method and apparatus for parsing a network abstraction-layer for reliable data communication
KR20130082070A (ko) 통신 장치 및 통신 방법
WO2012006744A1 (en) A system and method for transmission of data signals over a wireless network
US20150237104A1 (en) Communication system, communication apparatus, and communication method
CN111435866B (zh) 数据传输方法及相关装置
JP3492602B2 (ja) データ送信装置及びデータ受信装置
US20130003524A1 (en) Selective Caching in a Packet Network and Packet Loss Repair Using Selective Caching
Hisamatsu et al. Non bandwidth-intrusive video streaming over TCP
CN113424578B (zh) 一种传输控制协议加速方法和装置
JP2016054333A (ja) データ転送制御装置、方法及びプログラム
JP5375625B2 (ja) 中継通信装置および通信制御方法
JP3594196B1 (ja) データ伝送装置およびデータ伝送方法
Radovanovic et al. Improving TCP performance over last-hop wireless networks for live video delivery
CN114866523A (zh) 一种基于udp的视频快速传输方法及***

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
GR01 Patent grant
GR01 Patent grant