CN113132062A - 报文传输方法及电子设备 - Google Patents

报文传输方法及电子设备 Download PDF

Info

Publication number
CN113132062A
CN113132062A CN201911419211.8A CN201911419211A CN113132062A CN 113132062 A CN113132062 A CN 113132062A CN 201911419211 A CN201911419211 A CN 201911419211A CN 113132062 A CN113132062 A CN 113132062A
Authority
CN
China
Prior art keywords
message
service
sending
packet
response
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
CN201911419211.8A
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201911419211.8A priority Critical patent/CN113132062A/zh
Priority to PCT/CN2020/140904 priority patent/WO2021136278A1/zh
Priority to EP20909335.0A priority patent/EP4075697B1/en
Publication of CN113132062A publication Critical patent/CN113132062A/zh
Priority to US17/852,679 priority patent/US20220329519A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/56Routing software
    • H04L45/566Routing instructions carried by the data packet, e.g. active networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • 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/1628List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
    • 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/1635Cumulative acknowledgement, i.e. the acknowledgement message applying to all previous messages
    • 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
    • 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
    • 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
    • H04L1/188Time-out mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894Packet rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/42Centralised routing
    • 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]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0829Packet loss
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0829Packet loss
    • H04L43/0841Round trip packet loss

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请涉及通信技术领域,公开了一种报文传输方法及电子设备。本申请公开的报文传输方法中,业务报文中设置应答报文索取字段,发送设备可以设置所发送的业务报文的应答报文索取字段的值。当需要接收设备发送应答报文时,发送设备修改后续发送的业务报文的应答报文索取字段的值,以触发接收设备向发送设备发送应答报文。这样使得接收设备能够按照发送设备的需求向发送设备发送应答报文,从而在确保传输可靠性的前提下,能够减少应答报文的数量,进而能够节省资源。

Description

报文传输方法及电子设备
技术领域
本申请实施例涉及通信技术领域,尤其涉及一种报文传输方法及电子设备。
背景技术
可靠传输是采用确认机制保证业务报文在发送端和接收端精确传输的传输机制。可靠传输机制的原理在于,发送设备向接收设备发送业务报文。接收设备若接收到相应业务报文,可以向发送设备发送确认(acknowledgement,ACK)报文。接收设备若未接收到相应业务报文,可以向发送设备发送否认(negative acknowledgement,NACK)报文。本申请中可以将ACK报文和NACK报文统称为应答报文。发送设备可以根据应答报文确定传输成功率以及重传机制等,以确保业务报文传输的可靠性。
一种现有的可靠传输机制中,接收设备对应发送端发送的每个业务报文,均生成应答报文并将应答报文发送到发送设备。这样不仅使得接收设备需要消耗大量资源,而且还会占用大量传输资源。
发明内容
本申请提供了一种报文传输方法及电子设备,能够解决现有报文传输方法占用资源多的问题。
第一方面,本申请提供了一种报文传输方法,包括:发送设备向接收设备发送至少一个第一类业务报文,所述第一类业务报文的应答报文索取字段的值是第一值,所述应答报文索取字段用于指示所述接收设备是否向所述发送设备发送应答报文;若需要获取所述应答报文,所述发送设备向所述接收设备发送至少一个第二类业务报文,所述第二类业务报文的应答报文索取字段的值是第二值;所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文。
本申请实施例中,发送设备可以与接收设备协商,为业务报文设置应答报文索取字段。发送设备可以根据是否需要获取应答报文,修改业务报文的应答报文索取字段的值。基于此,在不需要获取应答报文的场景中,发送设备例如向接收设备发送的是第一类业务报文,第一类业务报文的应答报文索取字段的值是第一值。在需要获取应答报文的场景中,发送设备例如向接收设备发送第二类业务报文,第二类业务报文的应答报文索取字段的值是第二值。即,在需要获取应答报文的场景中,发送设备修改后续发送的业务报文的应答报文索取字段的值。之后,发送设备可以接收到接收设备针对第二类业务报文的应答报文。可见,发送设备可以在需要获取应答报文时,通过更改业务报文的应答报文索取字段的值告知接收设备。这样,能够减少接收设备生成和发送的应答报文的数量,进而节省接收设备的资源和传输资源。
在一种可能的设计中,所述发送设备向所述接收设备发送至少一个第二类业务报文,包括:所述发送设备向所述接收设备发送一个所述第二类业务报文。采用本实现方式,在需要获取应答报文的场景下,发送设备可以改变即将发送的一个业务报文的应答报文索取字段的值,从而触发接收设备发送应答报文。这样可以只通过一个业务报文的应答报文索取字段的值的更改告知接收设备。
在一种可能的设计中,所述发送设备向所述接收设备发送至少一个第二类业务报文,包括:所述发送设备向所述接收设备发送第一预设数量的所述第二类业务报文,所述第一预设数量是大于或者等于2的整数。其中,业务报文在发送过程中,可能存在丢失等风险。因此,只有一个业务报文的应答报文索取字段的值与其他业务报文不同,将导致发送设备无法及时获取到应答报文。基于此,在需要获取应答报文的场景下,发送设备可以发送第一预设数量的第二类业务报文,从而在存在一定丢包率的情况下,确保接收设备能够接收到第二类业务报文,进而,使得发送设备能够及时接收到应答报文。
在一种可能的设计中,所述发送设备向所述接收设备发送至少一个第二类业务报文,包括:所述发送设备向所述接收设备发送第一预设时间段内的所述第二类业务报文,所述第一预设时间段小于一个RTT。采用本实现方式,在存在一定丢包率的情况下,确保接收设备能够接收到第二类业务报文,进而,使得发送设备能够及时接收到应答报文。
在一种可能的设计中,所述发送设备向所述接收设备发送至少一个第二类业务报文,包括:在下一次需要获取所述应答报文之前,所述发送设备持续向所述接收设备发送所述第二类业务报文。采用本实现方式,在存在一定丢包率的情况下,确保接收设备能够接收到第二类业务报文,进而,使得发送设备能够及时接收到应答报文。
在一种可能的设计中,所述发送设备向所述接收设备发送至少一个第二类业务报文之后,在下一次需要获取所述应答报文之前,还包括:所述发送设备向所述接收设备发送至少一个第三类业务报文,所述第三类业务报文的应答报文索取字段的值是第三值,所述第三值与所述第二值不同。采用本实现方式,在需要获取应答报文的场景下,发送设备可以改变后续至少一个业务报文的应答报文索取字段的值,从而触发接收设备发送应答报文。
在一种可能的设计中,发送设备向接收设备发送至少一个第一类业务报文之后,向所述接收设备发送至少一个第二类业务报文之前,还包括:所述发送设备检测正在计时的往返时延RTT是否计时结束,所述RTT是指所述发送设备发送业务报文到所述发送设备接收到来自于所述接收设备的与所述业务报文对应的应答报文的总时长;若正在计时的RTT计时结束,所述发送设备确定需要获取所述应答报文。应答报文可以用于发送设备测量通信链路的RTT、计算RTO、判断网络状况和丢包原因、以及清空重传队列等。基于此,本申请实施例中,发送设备可以根据以上需求的至少一个确定是否需要获取应答报文。
在一种可能的设计中,发送设备向接收设备发送至少一个第一类业务报文之后,向所述接收设备发送至少一个第二类业务报文之前,还包括:所述发送设备检测待重传业务报文的总数量是否达到第二预设数量;若所述待重传业务报文的总数量达到所述第二预设数量,所述发送设备确定需要获取所述应答报文。应答报文可以用于发送设备测量通信链路的RTT、计算RTO、判断网络状况和丢包原因、以及清空重传队列等。基于此,本申请实施例中,发送设备可以根据以上需求的至少一个确定是否需要获取应答报文。
在一种可能的设计中,所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文,包括:所述发送设备从所述接收设备接收一个应答报文。采用本实现方式,发送设备通过更改业务报文的应答报文索取字段的值,触发接收设备对应多个业务报文只发送一个应答报文,从而能够节省接收设备生成应答报文的资源。
在一种可能的设计中,所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文,包括:所述发送设备从所述接收设备接收至少两个应答报文,所述至少两个应答报文包含的内容相同。采用本实现方式,发送设备通过更改业务报文的应答报文索取字段的值,触发接收设备发送至少两个应答报文,从而使得发送设备能够及时接收到应答报文。
在一种可能的设计中,所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文,包括:所述发送设备从所述接收设备接收至少两个应答报文,所述至少两个应答报文包含的内容相互之间均不相同。采用本实现方式,发送设备通过更改业务报文的应答报文索取字段的值,触发接收设备发送至少两个应答报文,从而使得发送设备能够及时接收到应答报文。
第二方面,本申请提供了一种报文传输方法,包括:接收设备从发送设备接收至少一个第一类业务报文,所述第一类业务报文的应答报文索取字段的值是第一值,所述应答报文索取字段用于指示所述接收设备是否向所述发送设备发送应答报文;所述接收设备从所述发送设备接收至少一个第二类业务报文,所述第二类业务报文的应答报文索取字段的值是第二值;所述接收设备向所述发送设备发送针对所述第二类业务报文的至少一个应答报文。
本申请接收设备接收到业务报文之后,可以读取业务报文的应答报文索取字段的值,然后,与所接收的上一个业务报文的应答报文索取字段的值比较。若二者相同,接收设备不向发送设备发送应答报文。若二者不相同,接收设备向发送设备发送应答报文。例如,接收设备接收到任一第一类业务报文时,所接收的第一类业务报文的应答报文索取字段的值是第一值,与之前接收的第一类业务报文的应答报文索取字段的值相同,则不向发送设备发送应答报文。接收设备接收到第二类业务报文时,第二类业务报文的应答报文索取字段的值是第二值,第二值与第一值不不同,接收设备向发送设备发送应答报文。这样,接收设备能够按照发送设备的需求向发送设备发送应答报文,从而能够减少生成和发送的应答报文的数量,进而节省接收设备的资源和传输资源。
在一种可能的设计中,所述接收设备向所述发送设备发送针对所述第二类业务报文的至少一个应答报文,包括:所述接收设备向所述发送设备发送针对所述第二类业务报文的一个应答报文。采用本实现方式,接收设备能够根据发送设备的需求,对应多个业务报文只发送一个应答报文,从而能够节省接收设备生成应答报文的资源。
在一种可能的设计中,所述接收设备向所述发送设备发送针对所述第二类业务报文的至少一个应答报文,包括:所述接收设备向所述发送设备发送针对所述第二类业务报文的至少两个应答报文,所述至少两个应答报文包含的内容相同。应答报文在传输过程中可能存在丢失等风险。因此,接收设备只向发送设备发送一个应答报文,可能使得发送设备无法接收到应答报文。基于此,接收设备在生成一个应答报文之后,将该应答报文向发送设备发送至少两次。这样能够确保发送设备接收到应答报文。
在一种可能的设计中,所述接收设备向所述发送设备发送针对所述第二类业务报文的至少一个应答报文,包括:所述接收设备向所述发送设备发送针对所述第二类业务报文的至少两个应答报文,所述至少两个应答报文包含的内容相互之间均不相同。本实施例中,接收设备在接收到第一个第二类业务报文之后,可以向发送设备发送针对第一个第二类业务报文的第一应答报文。接收设备在接收到第二个第二类业务报文之后,可以向发送设备发送针对第二个第二类业务报文的第二应答报文。这样能够确保发送设备接收到应答报文。
在一种可能的设计中,接收设备从发送设备接收至少一个第三类业务报文,所述第三类业务报文的应答报文索取字段的值是第三值,所述第三值与所述第二值不同;所述接收设备针对所述第三类业务报文不向所述发送设备发送应答报文。采用本实现方式,接收设备只在发送设备的需要获取应答报文时,向发送设备发送应答报文。这样,能够减少接收设备生成和发送的应答报文的数量,从而节省资源。
第三方面,本申请提供了一种发送设备,该发送设备具有实现上述方法中发送设备行为的功能。所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。在一个可能的设计中,上述发送设备的结构中包括发送器和接收器,所述发送器用于实现上述发送设备与接收设备之间的业务报文的发送,所述接收器用于实现上述发送设备与接收设备之间的应答报文的接收。所述发送设备还可以包括处理器和存储器,所述处理器被配置为处理该发送设备执行上述方法中除了报文收发之外的功能,所述存储器用于与处理器耦合,其保存该发送设备必要的程序指令和数据。
第四方面,本申请提供了一种接收设备,该接收设备具有实现上述方法中接收设备行为的功能。所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。在一个可能的设计中,上述接收设备的结构中包括发送器和接收器,所述发送器用于实现上述接收设备与发送设备之间的应答报文的发送,所述接收器用于实现上述接收设备与发送设备之间的业务报文的接收。所述接收设备还可以包括处理器和存储器,所述处理器被配置为处理该接收设备执行上述方法中除了报文收发之外的功能,所述存储器用于与处理器耦合,其保存该接收设备必要的程序指令和数据。
第五方面,本申请提供了一种计算机存储介质,该计算机存储介质中存储有指令,当所述指令在计算机上运行时,使得计算机执行第一方面、第二方面、第一方面的各种可能的实现方式、及第二方面的各种可能的实现方式中的报文传输方法的部分或全部步骤。
第六方面,本申请提供了一种计算机程序产品,该计算机程序产品在计算机上运行时,使得计算机执行第一方面、第二方面、第一方面的各种可能的实现方式、及第二方面的各种可能的实现方式中的报文传输方法的部分或全部步骤。
为解决现有技术的问题,本申请技术方案中,业务报文中包含应答报文索取字段。基于此,发送设备可以向接收设备发送第一类业务报文,第一类业务报文的应答报文索取字段的值是第一值。当需要接收设备发送应答报文时,发送设备向接收设备发送第二类业务报文,第二类业务报文的应答报文索取字段的值是第二值。相应的,接收设备接收第二类业务报文之后,确定第二值与第一值不同。进而,接收设备响应第二类业务报文的触发,向发送设备发送应答报文。这样使得接收设备能够按照发送设备的需求向发送设备发送应答报文,从而在确保传输可靠性的前提下,能够减少应答报文的数量,进而,能够节省资源。
附图说明
图1为本申请提供的报文传输的场景示意图;
图2为本申请提供的报文传输方法10的示例性信令交互图;
图3A为本申请提供的发送第二类业务报文的第一种示例性场景示意图;
图3B为本申请提供的发送第二类业务报文的第二种示例性场景示意图;
图3C为本申请提供的发送第二类业务报文的第三种示例性场景示意图;
图3D为本申请提供的发送第二类业务报文的第四种示例性场景示意图;
图4A为本申请提供的无线网络架构41的场景示意图;
图4B为本申请提供的分段网络架构42的场景示意图;
图4C为本申请提供的端到端网络架构43的场景示意图;
图5为本申请提供的分段网络架构50的示意图;
图6为本申请提供的报文传输方法20的信令交互图;
图7A为本申请提供的发送设备70的结构示意图;
图7B为本申请提供的发送设备71的结构示意图;
图8A为本申请提供的接收设备80的结构示意图;
图8B为本申请提供的接收设备81的结构示意图。
具体实施方式
下面将结合本申请中的附图,对本申请的技术方案进行清楚地描述。
本申请以下实施例中所使用的术语只是为了描述特定实施例的目的,而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样,单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式,除非其上下文中明确地有相反指示。还应当理解,尽管在以下实施例中可能采用术语第一、第二等来描述某一类对象,但所述对象不应限于这些术语。这些术语仅用来将该类对象的具体对象进行区分。例如,以下实施例中可能采用术语第一、第二等来描述业务报文,但业务报文不应限于这些术语。这些术语仅用来将应答报文索取字段的值不同的业务报文进行区分。以下实施例中可能采用术语第一、第二等来描述的其他类对象同理,此处不再赘述。
以下结合附图对本申请实施例的技术场景进行说明。
如图1所示,本申请涉及发送设备和接收设备。发送设备与接收设备建立通信连接之后,发送设备可以用于向接收设备发送业务报文。接收设备可以用于根据所述业务报文的接收情况生成应答报文,之后,将该应答报文发送到发送设备。其中,应答报文是发送设备与接收设备之间进行可靠性传输的必要的技术特征。
本申请涉及的发送设备可以是支持报文传输协议的电子设备。发送设备支持的传输协议包括但不限于传输控制协议(transmission control protocol,TCP)等可靠性传输协议。一些实施例中,该发送设备可以是发送业务报文的源设备。另一些实施例中,该发送设备可以是代理设备。该代理设备用于将来自于源设备的业务报文转发到接收设备,还用于向源设备发送应答报文。该应答报文是代理设备对来自于源设备的业务报文的应答。其他一些实施例中,该发送设备可以是分段网络中除接收节点之外的任一节点设备(包括源设备)。示例性的,发送设备可以是智能手机、平板电脑、车载设备、二层交换机(layer2switches)、三层交换机(layer 3switches)、路由器或者调制解调器等。
本申请涉及的接收设备可以是支持报文传输协议的电子设备。本实施例中,接收设备所使用的报文传输协议例如与发送设备所使用的报文传输协议相同。与发送设备相对应的,一些实施例中,发送设备是端到端场景中的源设备,接收设备则可以是端到端场景中的目的设备。另一些实施例中,发送设备是代理设备的场景下,接收设备可以是目的设备。其他一些实施例中,发送设备是分段网络中的任一节点设备,相应的,接收设备可以是该分段网络中发送设备的下一跳节点设备(包括目的设备)。示例性的,接收设备可以是智能手机、平板电脑、车载设备、二层交换机(layer 2switches)、三层交换机(layer 3switches)、路由器或者调制解调器等。
本申请涉及的应答报文包括ACK报文和NACK报文。其中,ACK报文用于指示接收设备对发送设备发送的业务报文接受无误。NACK报文用于指示接收设备对发送设备发送的业务报文存在接收错误,例如未接收到某个业务报文,并要求发送设备重新发送存在接收错误的业务报文。示例性的,本申请涉及的传输场景是可靠性传输场景。基于此,发送设备可以为每个业务报文分配一个序列号。业务报文的序列号随业务报文的发送顺序顺次增大。进而,一些实施例中,接收设备例如对序列号1至10的业务报文均接收无误,接收设备生成ACK报文,该ACK报文可以包含确认序列号(acknowledgment number),该ACK报文的确认序列号是11,以告知发送设备应该接收序列号是11的业务报文。另一些实施例中,接收设备例如接收到序列号是1、2、4和6的业务报文,未接收到序列号是3和序列号是5的业务报文,接收设备生成NACK报文。NACK报文中包括用于指示未成功接收的报文的字段,该字段中可以包括序列号3和序列号5,以告知发送设备重新发送序列号是3的业务报文和序列号是5的业务报文。
结合图1示意的实施场景,一种典型的报文发送方法中,接收设备在接收到一个业务报文之后,可以检测是否有其他数据需要发送到发送设备。若有其他数据需要发送到发送设备,将需要发送的数据和应答报文一起发送到发送设备。若没有其他数据需要发送到发送设备,则延迟预设时间之后,将应答报文发送到发送设备。这样虽然能够减少接收设备向发送设备发送应答报文的数量,但是能够减少的数量很有限,导致生成并发送应答报文占用的资源仍然较高。
本申请提供了一种报文传输方法及电子设备,其中,本申请涉及的业务报文中包含应答报文索取字段。当需要接收设备发送应答报文时,发送设备修改即将发送的业务报文中应答报文索取字段的值。相应的,接收设备确定所接收的业务报文的应答报文索取字段的值与上一次接收的业务报文的应答报文索取字段的值不同,则生成并向发送设备发送应答报文。这样使得接收设备能够按照发送设备的需求向发送设备发送应答报文,从而在确保传输可靠性的前提下,能够减少应答报文的数量,进而,能够节省资源。
本申请实施例还可以适用于面向未来的其他通信技术。本申请描述的网络架构以及业务场景是为了更加清楚的说明本申请的技术方案,并不构成对本申请提供的技术方案的限定,本领域普通技术人员可知,随着网络架构的演变和新业务场景的出现,本申请提供的技术方案对于类似的技术问题,同样适用。
以下对本申请涉及的报文传输方法的实施例进行示例性说明。
首先,对本申请实施例涉及的技术术语进行说明。
业务报文是承载发送设备向接收设备发送的数据包的报文。业务报文不仅包含待发送的数据包,还可以包括传输数据包过程中需要执行的业务,例如包括协议分析,信息过滤,数据报文加密,查表,路由等业务。本申请实施例中,业务报文的报头中包括应答报文索取字段。示例性的,本申请实施例中,业务报文中设置应答报文索取字段的操作,可以由发送设备与接收设备协商实现。
往返时延(round-trip time,RTT)是指发送设备发送业务报文的时刻起,到发送设备接收到来自于接收设备的与业务报文对应的应答报文的时刻之间的总时长。
重传超时时间(retransmission timeout,RTO)是发送设备发送业务报文的时刻起,至发送设备接收到该报文的ACK报文的最大允许时长。若在该最大允许时长内未接收到相应ACK报文,发送设备对该业务报文执行重传操作。
重传队列是已经发送的业务报文和需要重传的业务报文形成的队列。发送设备接收到重传队列中业务报文对应的ACK报文之后,将相应业务报文从重传队列中清除。
应答报文是为了保证传输的可靠性,接收设备对于业务报文接收情况的应答。应答报文例如可以是TCP报文,可以包括ACK报文和NACK报文。其中,ACK报文用于指示接收设备对发送设备发送的业务报文接受无误。NACK报文用于指示接收设备对发送设备发送的业务报文存在接收错误,并要求发送设备重新发送存在接收错误的业务报文。
应答报文索取字段的值用于指示接收设备是否向发送设备发送应答报文。应答报文索取字段例如与业务报文的序列号设置在同一层的报头中。应答报文索取字段的值可以由发送设备设置。应答报文索取字段可以是至少一个比特位。示例性的,在传输业务报文之前,发送设备可以设置应答报文索取字段的初始值。例如,应答报文索取字段是一个比特位,发送设备例如将应答报文索取字段的初始值设置为0。
参见图2,图2是本申请提供的报文传输方法10的信令交互图。报文传输方法10(以下简称方法10)包括以下步骤:
步骤S11,发送设备向接收设备发送至少一个第一类业务报文。
其中,第一类业务报文的应答报文索取字段的值是第一值。第一值例如是0或者1。
一些实施例中,第一类业务报文是发送设备向接收设备发送的第一批业务报文。该实施例中,第一值是应答报文索取字段的初始值,例如是0。另一些实施例中,第一类业务报文是任意一次需要获取应答报文之前,发送设备发送的最后一类业务报文。该实施例中,第一值可以根据实施场景的不同而不同,详见下述实施例的说明,此处不再详述。
步骤S12,若需要获取应答报文,发送设备向接收设备发送至少一个第二类业务报文。
其中,第二类业务报文的应答报文索取字段的值是第二值。一些实施例中,第一值是0,第二值则是1。另一些实施例中,第一值是1,第二值则是0。
需要指出的是,在可靠性传输场景中,应答报文除了指示接收设备对于业务报文的接收情况,还可以用于发送设备测量通信链路的RTT、计算RTO、判断网络状况和丢包原因、以及清空重传队列等。基于此,发送设备可以将需要根据应答报文进行以上至少一种操作的场景,确定为需要获取应答报文的场景。例如,发送设备将需要根据应答报文测量RTT的场景,确定为需要获取应答报文的场景。再如,发送设备将需要清空重传队列的场景,确定为需要获取应答报文的场景。
示例性的,一些实施例中,发送设备可以检测正在计时的RTT是否计时结束。若正在计时的RTT计时结束,发送设备确定需要获取所述应答报文,之后,向接收设备发送至少一个第二类业务报文。若正在计时的RTT计时未结束,发送设备继续发送第一类业务报文。另一些实施例中,发送设备检测待重传业务报文的总数量是否达到第二预设数量。若待重传业务报文的总数量达到第二预设数量,发送设备确定需要获取所述应答报文,之后,向接收设备发送至少一个第二类业务报文。若待重传业务报文的总数量未达到第二预设数量,发送设备继续发送第一类业务报文。
在实际操作中,发送设备可以在发送每个业务报文之后,判断是否需要获取应答报文。之后,发送设备可以根据判断结果,确定即将发送的业务报文。
可以理解的是,上述确定是否需要获取应答报文的条件,仅是示意性描述,对本申请实施例涉及的方案不构成限制。另一些实施例中,发送设备还可以根据网络状况确定是否需要获取应答报文。例如,发送设备确定需要检测网络状况时,确定需要获取应答报文。此处不再详述。
进一步的,在确定需要获取应答报文之后,发送设备至少更改即将发送的业务报文的应答报文索取字段的值,实现向接收设备发送至少一个第二类业务报文,以触发接收设备向发送设备发送应答报文。
以下对步骤S12的实现方式进行示例性说明。
实施方式一:发送设备向接收设备发送一个第二类业务报文。之后,在下一次需要获取应答报文之前,发送设备向接收设备发送的均是第三类业务报文。第三类业务报文的应答报文索取字段的值例如是第三值。
一些实施例中,若应答报文索取字段是一个比特位,那么,第三值可以与第一值相同。另一些实施例中,若应答报文索取字段大于一个比特位,那么,第三值与第二值不同。示例性,第三值可以与第一值相同,也可以与第一值也不相同。例如,应答报文索取字段是两个比特位,第一值例如可以是00,第二值例如可以是01,第二值例如可以是10。
如图3A所示,其中,每个方框例如表示一个业务报文,每个方框中值例如是该业务报文的应答报文索取字段的值。发送设备按照图示箭头指示的顺序发送业务报文。示例性的,在不需要获取应答报文的场景下,发送设备发送业务报文01、业务报文02和业务报文03。相应的,业务报文01、业务报文02和业务报文03即为本申请所述的第一类业务报文。本实施例中,第一类业务报文的应答报文索取字段的值例如是0。进一步的,在发送业务报文03之后,发送设备确定需要获取应答报文,则将业务报文04的应答报文索取字段的值设置为1。相应的,业务报文04本申请所述的第二类业务报文。之后,发送设备可以将业务报文05等的应答报文索取字段的值再次设置为0,直到下一次需要获取应答报文。本实施例中,将业务报文05至下一次需要获取应答报文的业务报文,称为第三类业务报文。
需要指出的是,图3A是以应答报文索取字段是一个比特位为例进行的说明,因此,图3A中业务报文05等的应答报文索取字段的值再次设置为0。在其他实施例中,若应答报文索取字段大于一个比特位,那么,发送设备所设置的第三类业务报文的应答报文索取字段的值与第二值不同即可。本申请对此不做限制。
可见,采用本实现方式,在需要获取应答报文的场景下,发送设备可以改变即将发送的一个业务报文的应答报文索取字段的值,从而触发接收设备发送应答报文。只通过一个业务报文的应答报文索取字段的值的更改告知接收设备。
然而,业务报文在发送过程中,可能存在丢失等风险。因此,只有一个业务报文(例如上述业务报文04)的应答报文索取字段的值与其他业务报文不同,若该业务报文(例如上述业务报文04)未被接收设备接收到,发送设备将无法及时获取到应答报文。为了解决该问题,本申请实施例还公开了实施方式二和实施方式三。
实施例二:发送设备向接收设备发送第一预设数量的第二类业务报文,之后,在下一次需要获取应答报文之前,发送设备向接收设备发送的均是第三类业务报文。第三类业务报文的应答报文索取字段的值例如是第三值。其中,第一预设数量是大于或者等于2的整数。第三类业务报文以及第三值的实现方式如实施方式一所述。
如图3B所示,图3B中方框、方框中的值以及箭头的含义,均如图3A示意的实施例所述,此处不再赘述。示例性的,发送设备所发送的第一类业务报文同样包括业务报文01、业务报文02和业务报文03,且发送设备在发送业务报文03之后需要获取应答报文。进而,发送设备发送的第二类业务报文例如包括业务报文04、业务报文05和业务报文06,业务报文04、业务报文05和业务报文06的应答报文索取字段的值均是1。之后,直到下一次需要获取应答报文之前,发送设备发送第三类业务报文,即业务报文07至下一次需要获取应答报文之前业务报文均是第三类业务报文。
一种可能的实现方式中,第一预设数量可以由技术人员预先设置。示例性的,第一预设数量例如可以根据需要获取应答报文的条件以及丢包率设置,以在具备一定丢包率的前提下,确保接收设备能够接收到至少一个第二类业务报文。例如,每两次获取应答报文之间,发送设备发送100个业务报文,当前的丢包率例如是4%,第一预设数量例如可以是5。
另一种可能的实现方式中,第一预设数量的业务报文同样是第一预设时间端内的业务报文。第一预设时间段可以由技术人员确定。示例性的,发送设备例如每个RTT获取一次应答报文,那么,发送设备例如可以在一个RTT的前一半的时间段内发送第二业务报文,后一半的时间段内发送第三业务报文。
可以理解的是,上述第一预设数量的确定方法仅是示意性描述,对本申请实施例不构成限制。在其他一些实施例中,第一预设数量的还可以通过其他方式确定。此处不再详述。
可见,采用本实现方式,在需要获取应答报文的场景下,发送设备可以发送第一预设数量的第二类业务报文,从而在存在一定丢包率的情况下,确保接收设备能够接收到第二类业务报文,进而,使得发送设备能够及时接收到应答报文。
可以理解的是,实施方式一和实施方式二仅是示意性描述,对本申请实施例的实现方式不构成限制。本申请实施例还可以包含其他实现方式。
实施方式三:在下一次需要获取应答报文之前,发送设备可以持续向接收设备发送第二类业务报文。
如图3C所示,图3C中方框、方框中的值、箭头的含义,均如图3A和图3B示意的实施例所述。本实施例中,发送设备发送业务报文01、业务报文02和业务报文03之后,例如第一次需要获取应答报文,之后,发送设备发送业务报文04、业务报文05、业务报文06和业务报文07。本实施例场景中,第一类业务报文包括业务报文01、业务报文02和业务报文03,第一值是0。第二类业务报文包括业务报文04、业务报文05、业务报文06和业务报文07,第二值是1。进一步的,发送设备发送业务报文04、业务报文05、业务报文06和业务报文07之后,例如第二次需要获取应答报文,之后,发送设备发送的业务报文包括业务报文08。相应的,本实施例中,第一类业务报文包括业务报文04、业务报文05、业务报文06和业务报文07,第一值是1。本实施例中,第二类业务报文包括业务报文08,第二值是0。
需要指出的是,图3C是以应答报文索取字段是一个比特位为例进行的说明,因此,图3C中业务报文08的应答报文索取字段的值再次设置为0。在其他实施例中,若应答报文索取字段大于一个比特位,发送设备每次确定需要获取应答报文之后,将本轮中第二类业务报文的应答报文索取字段的值,设置为与本轮中第一类业务报文的应答报文索取字段的值不同即可。本申请对此不做限制。
如图3D所示,图3D中方框、方框中的值、箭头、各业务报文、以及需要获取应答报文的时刻的含义,均如图3C示意的实施例所述。本实施例中,应答报文索取字段例如是两个比特位。基于此,发送设备第一次需要获取应发报文之前,业务报文01、业务报文02和业务报文03的应答报文索取字段的值均是00。在第一次确定需要获取应答报文之后,发送设备发送业务报文04、业务报文05、业务报文06和业务报文07。业务报文04、业务报文05、业务报文06和业务报文07的应答报文索取字段的值均是01。在第二次需要获取应答报文之后,发送设备发送的业务报文包括业务报文08。业务报文08的应答报文索取字段的值10。
此外,采用本实现方式,第二类业务报文包括一次需要获取应答报文的条件之后,至下一次需要获取应答报文之前的所有业务报文,从而能够确保接收设备一定能够接收到第二类业务报文,进而,确保发送设备能够接收到应答报文。
可以理解的是,图3A至图3D仅是示意性描述,对本申请的实现方式不构成限制。在其他一些实施例中,发送设备所发送的第一类业务报文的数量,以及发送设备所发送的第二类业务报文的数量,均可以与上述所述不同。另外,一些其他的实施场景中,第一值和第二值也可以与上述示例不同。此处不再详述。
步骤S13,接收设备向发送设备发送针对第二类业务报文的至少一个应答报文。
其中,所述“针对第二类业务报文的至少一个应答报文”是指响应第二类业务报文的触发所发送的应答报文。
在实际实现中,接收设备接收到业务报文之后,可以读取业务报文的应答报文索取字段的值,然后,与所接收的第一类业务报文的应答报文索取字段的值比较。若二者相同,接收设备不回复发送设备应答报文。若二者不相同,接收设备生成至少一个应答报文,然后,将该至少一个应答报文发送到发送设备。例如,结合上述图3A至图3D示意的实施例,接收设备接收到第二类业务报文之后,生成至少一个应答报文。接收设备接收到第三类业务报文之后,不生成应答报文。
根据可靠性传输的应答机制可知,接收设备可以根据业务报文的序列号判断对业务报文的接收情况。基于此,一些实施例中,若接收设备成功接收到生成应答报文之前的所有业务报文,接收设备生成ACK报文作为应答报文。该ACK报文包含一个序列号,该序列号是接收设备即将接收的第一业务报文的序列号。另一些实施例中,若生成应答报文之前,接收设备未接收到至少一个业务报文,接收设备生成NACK报文作为应答报文。该NACK报文中包含全部未接收到的业务报文的序列号。
以下结合上述对应答报文的说明,对步骤S13的实现方式进行示例性说明。
实施方式一:接收设备针对第二类业务报文生成一个应答报文。
示例性的,接收设备可以在接收到第二类业务报文之后,检测是否成功接收步骤S11涉及的至少一个第一类业务报文至该第二类业务报文的所有业务报文,然后,根据检测结果生成ACK报文或者NACK报文,之后,接收设备将所生成的应答报文发送到发送设备。可选的,接收设备可以在接收到第一个第二类业务报文之后,向发送设备发送应答报文。
例如,结合图3A至图3D中的任意图示对应的实施例,接收设备在接收到业务报文04之后,确定需要向发送设备发送应答报文。然后,接收设备根据业务报文的序列号判断是否成功接收到业务报文01、业务报文02、业务报文03和业务报文04。若成功接收到业务报文01、业务报文02和业务报文03,接收设备生成ACK报文作为应答报文,该ACK报文包含的序列号与业务报文05的序列号相同。之后,接收设备向发送设备发送该ACK报文。若未接收到业务报文01和业务报文03,接收设备生成NACK报文作为应答报文,NACK报文中包含业务报文01的序列号和业务报文03的序列号。之后,接收设备向发送设备发送该NACK报文。
采用本实现方式,接收设备能够响应业务报文的应答报文索取字段的值的更改,对应多个业务报文只发送一个应答报文,从而能够节省接收设备生成应答报文的资源。
与业务报文的传输类似的,应答报文的传输也可能存在丢失等风险。因此,本步骤的实施方式一中,接收设备只向发送设备发送一个应答报文,若该应答报文丢失,发送设备将无法获取到应答报文。为了解决该问题,本申请实施例还可以通过下述实施方式实现本步骤。
实施方式二:接收设备针对第二类业务报文生成至少两个应答报文,至少两个应答报文包含的内容相同。
示例性的,本实现方式中,接收设备在接收到第二类业务报文之后,依然可以只生成一个应答报文。之后,接收设备可以将该应答报文向发送设备发送至少两次。这样能够确保发送设备接收到应答报文。其中,本实施方式中,接收设备生成应答报文的方式可参考实施方式一所述,此处不再详述。
需要指出的是,本实施方式中,接收设备向发送设备发送应答报文的次数,可以由技术人员根据丢包率确定,以确保发送设备能够接收到至少一个应答报文为参考。例如,接收设备向发送设备发送3次应答报文。
实施方式三:接收设备针对第二类业务报文生成至少两个应答报文。本实施例中,至少两个应答报文包含的内容相互之间均不相同。
示例性的,本实现方式中,接收设备在接收到第一个第二类业务报文之后,可以针对第一个第二类业务报文生成第一应答报文,然后,将第一应答报文发送到发送设备。接收设备在接收到第二个第二类业务报文之后,可以针对第二个第二类业务报文生成第二应答报文,然后,将第二应答报文发送到发送设备。依此类推。其中,发送设备针对每个第二类业务报文生成应答报文的方式,可参考本步骤实现方式一的相关描述,此处不再详述。
一些实施例中,若接收设备接收到第一个第二类业务报文及其之前的所有报文,接收设备生成第一ACK报文,第一ACK报文包含的序列号与第一个第二类业务报文的序列号相同。同理,若接收设备成功接收第二个第二类业务报文及其之前的所有报文,接收设备生成第二ACK报文,第二ACK报文包含的序列号与第三个第二类业务报文的序列号相同。
例如,结合图3B至图3D中任意图示对应的实施例,接收设备在接收到业务报文04之后,确定成功接收到业务报文01、业务报文02、业务报文03和业务报文04,之后,接收设备生成第一ACK报文作为应答报文,该第一ACK报文包含的序列号与业务报文05的序列号相同。之后,接收设备向发送设备发送该第二ACK报文。接收设备在接收到业务报文05之后,确定成功接收到业务报文01、业务报文02、业务报文03、业务报文04和业务报文05,之后,接收设备生成第二ACK报文作为应答报文,该第二ACK报文包含的序列号与业务报文06的序列号相同。之后,接收设备向发送设备发送该第二ACK报文。
可以理解的是,本步骤所述的实施方式仅是示意性描述,对本申请实施例不构成限制。在其他一些实施例中,接收设备还可以采用其他方式发送应答报文。另外,实施方式二和实施方式三中,接收设备发送的应答报文的数量,也可以灵活设置。此处不再详述。
综上,本申请涉及的业务报文中包含应答报文索取字段,发送设备可以设置所发送的业务报文的应答报文索取字段的值。当需要接收设备发送应答报文时,发送设备修改即将发送的业务报文中应答报文索取字段的值,以使即将发送的业务报文中应答报文索取字段的值至少与上次发送的业务报文中应答报文索取字段的值不同。相应的,接收设备接收业务报文之后,若确定所接收的业务报文的应答报文索取字段的值与上一次接收的业务报文的应答报文索取字段的值不同,则生成并向发送设备发送应答报文。这样使得接收设备能够按照发送设备的需求向发送设备发送应答报文,从而在确保传输可靠性的前提下,能够减少应答报文的数量,进而,能够节省资源。
需要指出的是,上述方法10可以适用于可靠性传输的任意实施场景,例如无线网络实施场景、分段网络实施场景和端到端实施场景等。
图4A示意了一种无线网络架构41的场景示意图。无线网络架构41例如包括源设备、传输设备、代理设备和目的设备。其中,代理设备分别与源设备和目的设备连接。代理设备可以用于通过传输设备接收源设备发送的业务报文,还用于按照常规频率通过传输设备向源设备发送应答报文。代理设备用于为所接收的业务报文设置应答报文索取字段,以及设置应答报文索取字段的值,然后,将设置应答报文索取字段的业务报文发送到目的设备。代理设备还用于接收目标设备响应代理设备的需求所发送的应答报文。一些实施例中,代理设备可以按照现有技术向源设备发送应答报文。
可见,本实施例中,代理设备可以用于实现方法10所述实施例中发送设备的功能,目标设备可以用于实现方法10所述实施例中接收设备的功能。基于此,代理设备与目标设备之间的信息交互涉及的实施例,详见方法10的描述,此处不再赘述。
图4A示意的实现方式中,目标设备根据代理设备的需求反馈应答报文,从而能够节省目标设备的资源。此外,本实施例中,由代理设备为业务报文设置应答报文索取字段,从而无须修改源设备端的传输协议栈。
图4B示意了一种分段网络架构42的场景示意图。分段网络架构42包括顺次连接的源设备、第一节点设备、第二节点设备、目的设备。其中,源设备到目的设备之间的网络包括源设备到第一节点设备的网段、第一节点设备到第二节点设备的网段、和第二节点设备到目的设备的网段。源设备向目的设备发送业务报文的过程中,业务报文经由第一节点设备和第二节点设备发送到目的设备。并且在业务报文传输过程中,第一节点设备向源设备发送应答报文。第二节点设备向第一节点设备发送应答报文。目的设备向第二节点设备发送应答报文。
基于此,本实施例中,每个网段的上游节点可以用于实现方法10所述实施例中发送设备的功能,相应网段的下游节点可以用于实现方法10所述实施例中接收设备的功能。每个网段均适用于方法10所述的实施例。
分段网络中每个节点设备的资源有限。基于此,采用本实现方式,每个节点设备在其上游节点设备有需要时才反馈应答报文,不仅能够节省生成应答报文占用的资源,而且整条网络需要传输的应答报文的总数量减少,还能够节省整条网络的传输资源。
图4C示意了一种端到端网络架构43的场景示意图。端到端网络架构43包括发送设备和接收设备。本实施例中,发送设备可以用于实现方法10所述实施例中发送设备的功能,接收设备可以用于实现方法10所述实施例中接收设备的功能。
图4C示意的实施例中,发送设备例如管理传输协议涉及的拥塞控制协议。其中,发送设备通常根据应答报文所对应的业务报文的数量,调整拥塞控制算法。例如,接收设备每接收到两个业务报文,对应该两业务报文生成一个应答报文。本申请描述为应答报文则对应两个业务报文。进一步的,发送设备例如每接收一个应答报文,将拥塞窗口增加i个字节,i是大于等于1的整数。其中,i的具体值根据实施场景的不同而不同。而本申请实施例中,一个应答报文可以对应多个业务报文。例如,一个应答报文对应100个业务报文。相应的,发送设备每接收一个应答报文,可以将拥塞窗口增加50i个字节。同理,若一个应答报文对应80个业务报文,发送设备每接收一个应答报文,可以将拥塞窗口增加40i个字节。依此类推,此处不再一一举例。
可以理解的是,图4A至图4C是示意性描述,对本申请的技术方案不构成限制。在其他一些实施例中,本申请技术方案还可以适用于其他实施场景。另外,本说明书并未示出本申请适用的全部实施场景,在其他实施场景下,采用基于本申请技术思想的其他实施手段,同样属于本申请的保护范畴。
以下以分段网络的实施场景为例,对本申请的报文传输方法进行示例性说明。
如图5所示,一种分段网络架构50包括顺次连接的源设备m、节点设备x、节点设备y、节点设备z和目的设备n。其中,源设备m到目的设备n的网络包括源设备m和节点设备x形成的第一网段、节点设备x和节点设备y形成的第二网段、节点设备y和节点设备z形成的第三网段、节点设备z和目的设备n形成的第四网段。源设备m向目的设备n发送的业务报文,经由第一网段、第二网段、第三网段和第四网段到达目的设备n。在业务报文传输过程中,每个网段中的上游节点设备向该网段中的下游节点设备发送业务报文,且该网段中的下游节点设备向该网段中的上游节点设备发送应答报文。分段网络架构50例如支持TCP传输协议。
可以理解的是,图5是示意性描述,对本申请的技术方案不构成限制。在其他一些实施例中,分段网络可以包含更多或者更少的节点设备。相应的,分段网络可以包含更多或者更少的网段,此处不再详述。
图6是本申请提供的报文传输方法20的信令交互图。报文传输方法20(以下简称方法20)例如应用于图5中的第二网段。
方法20包括以下步骤:
步骤S21,节点设备x与节点设备y确定在业务报文中设置应答报文索取字段。
其中,节点设备x与节点设备y例如通过TCP三次握手的操作,确定在业务报文中设置应答报文索取字段。节点设备x与节点设备y执行TCP三次握手的操作,此处不再详述。
本实施例中,应答报文索取字段例如是一个比特位。节点设备x还可以在确定应答报文索取字段的初始值是0。
之后,节点设备x从源设备m接收到业务报文,然后,节点设备x执行以下步骤。
步骤S22,节点设备x确定不需要获取应答报文,向节点y发送业务报文a1,业务报文a1的应答报文索取字段的值是0。
其中,节点设备x例如以是否需要清空重传队列为依据,判断是否需要获取应答报文。本实施例中,清空重传队列的条件例如是重传队列中业务报文的总数量达到5。当前重传队列中业务报文的总数量例如是0。相应的,节点设备x确定不需要获取应答报文。
业务报文a1例如是节点设备x向节点设备y发送的第一个业务报文。节点设备x向节点设备y发送业务报文a1之后,节点设备x将业务报文a1添加到重传队列中。基于此,步骤S22之后,重传队列中业务报文的总数量是1。
步骤S23,节点设备y确定业务报文a1的应答报文索取字段的值,与节点y接收的上一个业务报文的应答报文索取字段的值相同,不向节点设备x发送应答报文。
业务报文a1例如是节点y接收到的第一个业务报文,所以,在此之前,节点y未接收到任何业务报文。本实施例中,节点y不向节点设备x发送应答报文。相应的,可以视为节点y接收的上一个业务报文的应答报文索取字段的值是0。
进一步的,如图6所示,之后,节点设备x例如继续向节点设备y发送了业务报文a2、业务报文a3、业务报文a4和业务报文a5。与步骤S22类似的,节点设备x每发送一个业务报文之前,检测是否需要获取应答报文。由于节点设备x发送业务报文a2、业务报文a3、业务报文a4和业务报文a5时,重传队列中业务报文的总数量均小于5,所以,以上场景中,节点设备x均不需要获取应答报文,业务报文a2、业务报文a3、业务报文a4和业务报文a5的应答报文索取字段的值均是0。此处不再详述。
相应的,节点设备y每接收到业务报文a2、业务报文a3、业务报文a4和业务报文a5中的一个,均读取其中的应答报文索取字段的值,然后,与节点设备y上一次接收到的业务报文的应答报文索取字段的值比较,以确定是否相同。由于业务报文a1至业务报文a5中,每个业务报文的应答报文索取字段的值均是0,即目前与其上一个业务报文的应答报文索取字段的值相同,所以,节点设备y可以一直不向节点设备x发送应答报文。
步骤S24,节点设备x确定需要获取应答报文,向节点y发送业务报文b1,业务报文b1的应答报文索取字段的值是1。
进一步的,在发送业务报文a5之后,重传队列中业务报文的总数量达到5,节点设备x需要清空重传队列,所以,节点设备x需要获取应答报文。进而,节点设备x将业务报文b1的应答报文索取字段的值是1。
步骤S25,节点设备y确定业务报文b1的应答报文索取字段的值与业务报文a5的应答报文索取字段的值不同,向节点设备x发送第一应答报文。
本实施例中,节点设备y在接收到业务报文b1之后,例如根据业务报文的序列号检测是否成功接收到了业务报文a1至业务报文b1。若成功接收到了业务报文a1至业务报文b1,生成第一ACK报文,第一ACK报文中包含业务报文b2的序列号。若未接收到了部分业务报文,例如未接收到业务报文a3,生成第一NACK报文,第一NACK报文中包含业务报文a3的序列号。
相应的,节点设备x若接收到第一ACK报文,将重传队列中的业务报文全部清除。重传队列中业务报文的总数量再次为0。节点设备x若接收到第一NACK报文,将重传队列中除了业务报文a3的业务报文全部清除,重传队列中业务报文的总数量变为1。
本实施例中,节点设备y向节点设备x发送一个应答报文。在其他实施方式中,节点设备y可以将应答报文向节点设备x发送多次。此处不再详述。
之后,节点设备x根据重传队列中业务报文的总数量的最新值,确定不需要获取应答报文,则可以继续发送业务报文b2、业务报文b3、业务报文b4等。其中,业务报文b2、业务报文b3和业务报文b4的应答报文索取字段的值均是1。
同理,节点设备y接收到业务报文b2、业务报文b3和业务报文b4中任一业务报文之后,比较所接收业务报文的应答报文索取字段的值与上一个业务报文的应答报文索取字段的值。由于比较结果均是相同,所以不发送应答报文。
步骤S26,节点设备x确定需要获取应答报文,向节点y发送业务报文c1,业务报文c1的应答报文索取字段的值是0。
例如,节点设备x在发送业务报文b5之后,需要清空重传队列,进而,需要获取应答报文。之后,节点设备x生成业务报文c1。
需要指出的是,图6是以应答报文索取字段是一个比特位为例进行的说明,因此,业务报文c1的应答报文索取字段的值是0。若实际实现时,应答报文索取字段大于一个比特位,业务报文c1的应答报文索取字段的值,可以不同于业务报文a1至业务报文b5中任一报文的应答报文索取字段的值。例如,图3D示意的实施例所述。
步骤S27,节点设备y确定业务报文c1的应答报文索取字段的值与上一个业务报文的应答报文索取字段的值不同,向节点设备x发送第二应答报文。
本步骤中,节点设备y接收的上一个业务报文例如是业务报文b5,业务报文b5的应答报文索取字段的值是1。
本步骤中,节点设备y检测是否成功结合到业务报文b2至业务报文c1中的每个业务报文,然后,根据检测结果生成第二应答报文。此处不再详述。
进一步的,节点设备x和节点设备y之间后续的信令交互过程,与步骤S22至步骤S27所述相似。此处不再详述。
图6仅是以图5中的第二网段为例进行的描述。该实施例同样适用于图5中的其他网段。当然,同一设备在不同网段中执行的功能不同。例如,图6示意的实施例中,节点设备x用作发送设备,所以执行发送设备的功能,若在第一网段中,节点设备x用作接收设备,执行接收设备(即图6中节点设备y)的功能。同理,图6示意的实施例中,节点设备y用作接收设备,所以执行接收设备的功能,若在第三网段中,节点设备y用作发送设备,执行发送设备(即图6中节点设备x)的功能。
可以理解的是,图6示意的报文传输方法仅是一种示意性描述,对本申请的报文传输方法不构成限制。在其他一些实施例中,接收设备例如可以向发送设备发送多个应答报文,等。详见上述实施例的记载,此处不详述。
此外,图6示意的操作方式不仅适用于分段网络的实施场景,还适用于其他可靠性传输场景,例如无线网络和端到端。其他实施场景的具体实现方式,详见上述各实施例的描述,此处不再详述。
可见,本申请实施例中,业务报文中包含应答报文索取字段,发送设备可以设置所发送的业务报文的应答报文索取字段的值。当需要接收设备发送应答报文时,发送设备修改即将发送的业务报文中应答报文索取字段的值,以使即将发送的业务报文中应答报文索取字段的值至少与上次发送的业务报文中应答报文索取字段的值不同。相应的,接收设备接收业务报文之后,若确定所接收的业务报文的应答报文索取字段的值与上一次接收的业务报文的应答报文索取字段的值不同,则生成并向发送设备发送应答报文。这样使得接收设备能够按照发送设备的需求向发送设备发送应答报文,从而在确保传输可靠性的前提下,能够减少应答报文的数量,进而,能够节省资源。
上述实施例分别从各个设备本身、以及从各个设备之间交互的角度对本申请实施例提供的报文传输方法的各实施例进行了介绍。例如,各设备为了实现上述功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
例如,上述发送设备可以通过功能模块的形式来实现上述相应的功能。示例性的,发送设备可以包括发送模块、接收模块和处理模块。所述发送模块可以用于执行上述方法10和方法20中业务报文的发送操作。所述接收模块可以用于执行上述方法10和方法20中应答报文的接收操作。所述处理模块可以用于执行上述方法10和方法20中除了报文收发之外的操作,例如确定是否需要获取应答报文。
可以理解的是,以上各个模块的划分仅仅是一种逻辑功能的划分,实际实现时,所述发送模块的功能可以集成到发送器,所述接收模块的功能可以集成到接收器实现。如图7A所示,图7A是本申请发送设备70的示例性结构示意图。该发送设备70包括发送器701和接收器702。所述发送器701可以执行上述方法10和方法20中业务报文的发送操作。所述接收器702可以执行上述方法10和方法20中应答报文的接收操作。
例如,在一个实施例中,该发送器701可以用于向接收设备发送至少一个第一类业务报文,所述第一类业务报文的应答报文索取字段的值是第一值,所述应答报文索取字段用于指示所述接收设备是否向所述发送设备发送应答报文。在需要获取所述应答报文时,该发送器701还可以用于向所述接收设备发送至少一个第二类业务报文,所述第二类业务报文的应答报文索取字段的值是第二值。该接收器702可以用于从所述接收设备接收针对所述第二类业务报文的至少一个应答报文。
在另一个实施例中,发送设备70还可以包括处理器。该处理器可以用于执行上述方法10和方法20中除了报文收发之外的操作,例如确定是否需要获取应答报文。
具体内容可以参考方法10和方法20对应的实施例中相关部分的描述,此处不再赘述。
图7A是从独立功能实体的角度对本申请的发送设备进行描述。在另一种实施场景中,各独立运行的功能实体可以集成在一个硬件实体中,例如芯片。相应的,如图7B所示,本实施场景中,发送设备71可以包括处理器711、收发器712和存储器713。其中,存储器713可以用于存储发送设备71预装的程序/代码,也可以存储用于处理器711执行时的代码等。
应理解,本申请的发送设备71可对应于本申请的方法10和方法20对应的实施例中的发送设备,其中收发器712用于执行方法10和方法20对应的实施例中的报文接收和发送,处理器711用于执行上述方法10和方法20对应的实施例中所述发送设备除了报文的接收和发送之外的其它处理。在此不再赘述。
上述接收设备可以通过功能模块的形式来实现上述相应的功能。示例性的,接收设备可以包括发送模块、接收模块和处理模块。所述发送模块可以用于执行上述方法10和方法20中应答报文的发送操作。所述接收模块可以用于执行上述方法10和方法20中业务报文的接收操作。所述处理模块可以用于执行上述方法10和方法20中除了报文收发之外的操作,例如比较两业务报文的应答报文索取字段的值是否相同。
可以理解的是,以上各个模块的划分仅仅是一种逻辑功能的划分,实际实现时,所述发送模块的功能可以集成到发送器,所述接收模块的功能可以集成到接收器实现。如图8A所示,图8A是本申请接收设备80的示例性结构示意图。该接收设备80包括发送器801和接收器802。所述发送器801可以执行上述方法10和方法20中应答报文的发送操作。所述接收器802可以执行上述方法10和方法20中业务报文的接收操作。
例如,在一个实施例中,该接收器802可以用于从发送设备接收至少一个第一类业务报文,所述第一类业务报文的应答报文索取字段的值是第一值,所述应答报文索取字段用于指示所述接收设备是否向所述发送设备发送应答报文。该接收器802还可以用于从所述发送设备接收至少一个第二类业务报文,所述第二类业务报文的应答报文索取字段的值是第二值。该发送器801可以用于向所述发送设备发送针对所述第二类业务报文的至少一个应答报文。
具体内容可以参考方法10和方法20对应的实施例中相关部分的描述,此处不再赘述。
图8A是从独立功能实体的角度对本申请的发送设备进行描述。在另一种实施场景中,各独立运行的功能实体可以集成在一个硬件实体中,例如芯片。相应的,如图8B所示,本实施场景中,接收设备81可以包括处理器811、收发器812和存储器813。其中,存储器813可以用于存储接收设备81预装的程序/代码,也可以存储用于处理器811执行时的代码等。
应理解,本申请的接收设备81可对应于本申请的方法10和方法20对应的实施例中的接收设备,其中收发器812用于执行方法10和方法20对应的实施例中的报文接收和发送,处理器811用于执行上述方法10和方法20对应的实施例中所述接收设备除了报文的接收和发送之外的其它处理。在此不再赘述。
具体实现中,对应发送设备和接收设备,本申请还分别提供一种计算机存储介质,其中,设置在任意设备中的计算机存储介质可存储有程序,该程序执行时,可实施包括方法10和方法20提供的报文传输方法的各实施例中的部分或全部步骤。任意设备中的存储介质均可为磁碟、光盘、只读存储记忆体(read-only memory,ROM)或随机存储记忆体(randomaccess memory,RAM)等。
本申请中,收发器可以是有线收发器,无线收发器或其组合。有线收发器例如可以为以太网接口。以太网接口可以是光接口,电接口或其组合。无线收发器例如可以为无线局域网收发器,蜂窝网络收发器或其组合。处理器可以是中央处理器(central processingunit,CPU),网络处理器(network processor,NP)或者CPU和NP的组合。处理器还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integratedcircuit,ASIC),可编程逻辑器件(programmable logic device,PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device,CPLD),现场可编程逻辑门阵列(field-programmable gate array,FPGA),通用阵列逻辑(generic array logic,GAL)或其任意组合。存储器可以包括易失性存储器(volatile memory),例如随机存取存储器(random-access memory,RAM);存储器也可以包括非易失性存储器(non-volatilememory),例如只读存储器(read-only memory,ROM),快闪存储器(flash memory),硬盘(hard disk drive,HDD)或固态硬盘(solid-state drive,SSD);存储器还可以包括上述种类的存储器的组合。
图7B和图8B中还可以包括总线接口,总线接口可以包括任意数量的互联的总线和桥,具体由处理器代表的一个或多个处理器和存储器代表的存储器的各种电路链接在一起。总线接口还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。收发器提供用于在传输介质上与各种其他设备通信的单元。处理器负责管理总线架构和通常的处理,存储器可以存储处理器在执行操作时所使用的数据。
本领域技术任何还可以了解到本申请实施例列出的各种说明性逻辑块(illustrative logical block)和步骤(step)可以通过电子硬件、电脑软件,或两者的结合进行实现。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用,可以使用各种方法实现所述的功能,但这种实现不应被理解为超出本申请实施例保护的范围。
本申请实施例中所描述的各种说明性的逻辑单元和电路可以通过通用处理器,数字信号处理器,专用集成电路(ASIC),现场可编程门阵列(FPGA)或其它可编程逻辑装置,离散门或晶体管逻辑,离散硬件部件,或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器,可选地,该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现,例如数字信号处理器和微处理器,多个微处理器,一个或多个微处理器联合一个数字信号处理器核,或任何其它类似的配置来实现。
本申请实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件单元、或者这两者的结合。软件单元可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地,存储媒介可以与处理器连接,以使得处理器可以从存储媒介中读取信息,并可以向存储媒介存写信息。可选地,存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中,ASIC可以设置于电子设备中。可选地,处理器和存储媒介也可以设置于电子设备中的不同的部件中。
应理解,在本申请的各种实施例中,各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对实施例的实施过程构成任何限定。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或报文中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或报文中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、报文中心等报文存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘(solidstate disk,SSD))等。
本说明书的各个部分均采用递进的方式进行描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点介绍的都是与其他实施例不同之处。尤其,对于装置和系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例部分的说明即可。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

Claims (28)

1.一种报文传输方法,其特征在于,包括:
发送设备向接收设备发送至少一个第一类业务报文,所述第一类业务报文的应答报文索取字段的值是第一值,所述应答报文索取字段用于指示所述接收设备是否向所述发送设备发送应答报文;
若需要获取所述应答报文,所述发送设备向所述接收设备发送至少一个第二类业务报文,所述第二类业务报文的应答报文索取字段的值是第二值;
所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文。
2.如权利要求1所述的方法,其特征在于,所述发送设备向所述接收设备发送至少一个第二类业务报文,包括:
所述发送设备向所述接收设备发送一个所述第二类业务报文。
3.如权利要求1所述的方法,其特征在于,所述发送设备向所述接收设备发送至少一个第二类业务报文,包括:
所述发送设备向所述接收设备发送第一预设数量的所述第二类业务报文,所述第一预设数量是大于或者等于2的整数。
4.如权利要求1所述的方法,其特征在于,所述发送设备向所述接收设备发送至少一个第二类业务报文,包括:
在下一次需要获取所述应答报文之前,所述发送设备持续向所述接收设备发送所述第二类业务报文。
5.如权利要求2或3所述的方法,其特征在于,所述发送设备向所述接收设备发送至少一个第二类业务报文之后,在下一次需要获取所述应答报文之前,还包括:
所述发送设备向所述接收设备发送至少一个第三类业务报文,所述第三类业务报文的应答报文索取字段的值是第三值,所述第三值与所述第二值不同。
6.如权利要求1至5中任一项所述的方法,其特征在于,发送设备向接收设备发送至少一个第一类业务报文之后,向所述接收设备发送至少一个第二类业务报文之前,还包括:
所述发送设备检测正在计时的往返时延RTT是否计时结束,所述RTT是指所述发送设备发送业务报文到所述发送设备接收到来自于所述接收设备的与所述业务报文对应的应答报文的总时长;
若正在计时的RTT计时结束,所述发送设备确定需要获取所述应答报文。
7.如权利要求1至5中任一项所述的方法,其特征在于,发送设备向接收设备发送至少一个第一类业务报文之后,向所述接收设备发送至少一个第二类业务报文之前,还包括:
所述发送设备检测待重传业务报文的总数量是否达到第二预设数量;
若所述待重传业务报文的总数量达到所述第二预设数量,所述发送设备确定需要获取所述应答报文。
8.如权利要求1至7中任一项所述的方法,其特征在于,所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文,包括:
所述发送设备从所述接收设备接收一个应答报文。
9.如权利要求1至7中任一项所述的方法,其特征在于,所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文,包括:
所述发送设备从所述接收设备接收至少两个应答报文,所述至少两个应答报文包含的内容相同。
10.如权利要求1至7中任一项所述的方法,其特征在于,所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文,包括:
所述发送设备从所述接收设备接收至少两个应答报文,所述至少两个应答报文包含的内容相互之间均不相同。
11.一种报文传输方法,其特征在于,包括:
接收设备从发送设备接收至少一个第一类业务报文,所述第一类业务报文的应答报文索取字段的值是第一值,所述应答报文索取字段用于指示所述接收设备是否向所述发送设备发送应答报文;
所述接收设备从所述发送设备接收至少一个第二类业务报文,所述第二类业务报文的应答报文索取字段的值是第二值;
所述接收设备向所述发送设备发送针对所述第二类业务报文的至少一个应答报文。
12.如权利要求11所述的方法,其特征在于,所述接收设备向所述发送设备发送针对所述第二类业务报文的至少一个应答报文,包括:
所述接收设备向所述发送设备发送针对所述第二类业务报文的一个应答报文。
13.如权利要求11所述的方法,其特征在于,所述接收设备向所述发送设备发送针对所述第二类业务报文的至少一个应答报文,包括:
所述接收设备向所述发送设备发送针对所述第二类业务报文的至少两个应答报文,所述至少两个应答报文包含的内容相同。
14.如权利要求11所述的方法,其特征在于,所述接收设备向所述发送设备发送针对所述第二类业务报文的至少一个应答报文,包括:
所述接收设备向所述发送设备发送针对所述第二类业务报文的至少两个应答报文,所述至少两个应答报文包含的内容相互之间均不相同。
15.一种发送设备,其特征在于,包括发送器和接收器,其中,
所述发送器,用于向接收设备发送至少一个第一类业务报文,所述第一类业务报文的应答报文索取字段的值是第一值,所述应答报文索取字段用于指示所述接收设备是否向所述发送设备发送应答报文;
所述发送器,还用于在需要获取所述应答报文时,向所述接收设备发送至少一个第二类业务报文,所述第二类业务报文的应答报文索取字段的值是第二值;
所述接收器,用于从所述接收设备接收针对所述第二类业务报文的至少一个应答报文。
16.如权利要求15所述的发送设备,其特征在于,
所述发送器,还用于向所述接收设备发送一个所述第二类业务报文。
17.如权利要求15所述的发送设备,其特征在于,所述发送设备向所述接收设备发送至少一个第二类业务报文,包括:
所述发送器,还用于向所述接收设备发送第一预设数量的所述第二类业务报文,所述第一预设数量是大于或者等于2的整数。
18.如权利要求15所述的发送设备,其特征在于,
所述发送器,还用于在下一次需要获取所述应答报文之前,持续向所述接收设备发送所述第二类业务报文。
19.如权利要求16或17所述的发送设备,其特征在于,
所述发送器,还用于向所述接收设备发送至少一个第二类业务报文之后,在下一次需要获取所述应答报文之前,向所述接收设备发送至少一个第三类业务报文,所述第三类业务报文的应答报文索取字段的值是第三值,所述第三值与所述第二值不同。
20.如权利要求15至19中任一项所述的发送设备,其特征在于,所述发送设备还包括处理器,
所述处理器,用于检测正在计时的往返时延RTT是否计时结束,所述RTT是指所述发送设备发送业务报文到所述发送设备接收到来自于所述接收设备的与所述业务报文对应的应答报文的总时长;
所述处理器,还用于在正在计时的RTT计时结束时,确定需要获取所述应答报文。
21.如权利要求15至19中任一项所述的发送设备,其特征在于,所述发送设备还包括处理器,
所述处理器,用于检测待重传业务报文的总数量是否达到第二预设数量;
所述处理器,还用于在所述待重传业务报文的总数量达到所述第二预设数量时,确定需要获取所述应答报文。
22.如权利要求15至21中任一项所述的发送设备,其特征在于,所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文,包括:
所述发送设备从所述接收设备接收一个应答报文。
23.如权利要求15至21中任一项所述的发送设备,其特征在于,所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文,包括:
所述接收器,还用于从所述接收设备接收至少两个应答报文,所述至少两个应答报文包含的内容相同。
24.如权利要求15至21中任一项所述的发送设备,其特征在于,所述发送设备从所述接收设备接收针对所述第二类业务报文的至少一个应答报文,包括:
所述接收器,还用于从所述接收设备接收至少两个应答报文,所述至少两个应答报文包含的内容相互之间均不相同。
25.一种接收设备,其特征在于,包括接收器和发送器,其中,
所述接收器,用于从发送设备接收至少一个第一类业务报文,所述第一类业务报文的应答报文索取字段的值是第一值,所述应答报文索取字段用于指示所述接收设备是否向所述发送设备发送应答报文;
所述接收器,还用于从所述发送设备接收至少一个第二类业务报文,所述第二类业务报文的应答报文索取字段的值是第二值;
所述发送器,用于向所述发送设备发送针对所述第二类业务报文的至少一个应答报文。
26.如权利要求25所述的接收设备,其特征在于,
所述发送器,还用于向所述发送设备发送针对所述第二类业务报文的一个应答报文。
27.如权利要求25所述的接收设备,其特征在于,
所述发送器,还用于向所述发送设备发送针对所述第二类业务报文的至少两个应答报文,所述至少两个应答报文包含的内容相同。
28.如权利要求25所述的接收设备,其特征在于,
所述发送器,还用于向所述发送设备发送针对所述第二类业务报文的至少两个应答报文,所述至少两个应答报文包含的内容相互之间均不相同。
CN201911419211.8A 2019-12-31 2019-12-31 报文传输方法及电子设备 Pending CN113132062A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201911419211.8A CN113132062A (zh) 2019-12-31 2019-12-31 报文传输方法及电子设备
PCT/CN2020/140904 WO2021136278A1 (zh) 2019-12-31 2020-12-29 报文传输方法及电子设备
EP20909335.0A EP4075697B1 (en) 2019-12-31 2020-12-29 Message transmission method and electronic device
US17/852,679 US20220329519A1 (en) 2019-12-31 2022-06-29 Packet transmission method and electronic device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911419211.8A CN113132062A (zh) 2019-12-31 2019-12-31 报文传输方法及电子设备

Publications (1)

Publication Number Publication Date
CN113132062A true CN113132062A (zh) 2021-07-16

Family

ID=76687299

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911419211.8A Pending CN113132062A (zh) 2019-12-31 2019-12-31 报文传输方法及电子设备

Country Status (4)

Country Link
US (1) US20220329519A1 (zh)
EP (1) EP4075697B1 (zh)
CN (1) CN113132062A (zh)
WO (1) WO2021136278A1 (zh)

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030023746A1 (en) * 2001-07-26 2003-01-30 Koninklijke Philips Electronics N.V. Method for reliable and efficient support of congestion control in nack-based protocols
CN1567915A (zh) * 2003-07-02 2005-01-19 明基电通股份有限公司 一种无线传输控制协议/网际协议报头设定传输方法
US9608789B2 (en) * 2012-05-11 2017-03-28 Interdigital Patent Holdings, Inc. Method and apparatus for transmitting acknowledgements in response to received frames
US10374776B2 (en) * 2014-11-20 2019-08-06 Industrial Technology Research Institute Base station, user equipment for integrating multiple rats using carrier aggregation and methods thereof
WO2016204574A1 (ko) * 2015-06-17 2016-12-22 주식회사 윌러스표준기술연구소 복수의 무선 통신 단말로부터 데이터를 수신하는 무선 통신 방법 및 무선 통신 단말
US10142253B2 (en) * 2015-11-06 2018-11-27 Hfi Innovation Inc. Method for efficient reliable transmission
KR102371187B1 (ko) * 2017-03-20 2022-03-07 광동 오포 모바일 텔레커뮤니케이션즈 코포레이션 리미티드 제어 시그널링을 전송하는 방법, 기지국 및 단말기
CN108829629B (zh) * 2018-06-19 2020-12-01 夏华涛 通讯方法和装置
CN111082898B (zh) * 2018-10-19 2022-08-26 华为技术有限公司 一种报文处理方法和装置

Also Published As

Publication number Publication date
WO2021136278A1 (zh) 2021-07-08
US20220329519A1 (en) 2022-10-13
EP4075697B1 (en) 2024-08-21
EP4075697A1 (en) 2022-10-19
EP4075697A4 (en) 2023-01-25

Similar Documents

Publication Publication Date Title
CN108881008B (zh) 一种数据传输的方法、装置和系统
JP5523350B2 (ja) Tcpフロー制御のための方法及び装置
EP2978171B1 (en) Communication method, communication device, and communication program
JP4456608B2 (ja) 端末における確認応答メッセージの処理
JP2014524092A (ja) 単一ソケットポイントツーマルチポイント性能による高信頼性仮想双方向データストリーム通信のためのシステムおよび方法
CN110677221B (zh) 重传控制方法、通信接口和电子设备
EP2673933A1 (en) Mechanisms to improve the transmission control protocol performance in wireless networks
KR102046792B1 (ko) 송신 노드로부터 목적지 노드로의 데이터 전송 방법
KR20130082070A (ko) 통신 장치 및 통신 방법
CN113259391B (zh) 应用于多级节点网络的数据传输方法和装置
JP3377994B2 (ja) データ配信管理装置およびデータ配信管理方法
EP3490293A1 (en) Data transmission method, data receiving device, and data sending device
US9590913B2 (en) System and method for reducing bandwidth usage of a network
CN113938431B (zh) 突发数据包传输方法、装置和电子设备
US20060262738A1 (en) Administering acknowledgment messages in the transmission control protocol
CN113259490A (zh) 基于udp传输协议的多级节点网络数据传输方法
CN113347681A (zh) 数据传输方法、装置、存储介质及电子装置
CN113595920B (zh) 网络拥塞控制方法及设备
CN102638392B (zh) 数据传输方法及设备、系统
EP3562108B1 (en) Load sharing between hybrid tunnels
CN113132062A (zh) 报文传输方法及电子设备
CN113950099B (zh) 一种网络拥塞控制方法及设备
CN110247742A (zh) 一种通信方法、接入热点设备和终端设备
EP1505759A2 (en) Method and device for transmitting/receiving data using acknowledged transport layer protocols
CN112153664A (zh) 参数优化方法、装置、基站、服务器及存储介质

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