WO2016033948A1 - 一种发送窗口流量控制方法和终端 - Google Patents

一种发送窗口流量控制方法和终端 Download PDF

Info

Publication number
WO2016033948A1
WO2016033948A1 PCT/CN2015/072936 CN2015072936W WO2016033948A1 WO 2016033948 A1 WO2016033948 A1 WO 2016033948A1 CN 2015072936 W CN2015072936 W CN 2015072936W WO 2016033948 A1 WO2016033948 A1 WO 2016033948A1
Authority
WO
WIPO (PCT)
Prior art keywords
window
size
receiving
sending
receiver
Prior art date
Application number
PCT/CN2015/072936
Other languages
English (en)
French (fr)
Inventor
张国良
尹胜生
刘松涛
林鹏
孙文杰
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2016033948A1 publication Critical patent/WO2016033948A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the invention relates to a reliable user datagram protocol (Reliable UDP, RUDP), in particular to a method and a terminal for controlling a transmission window flow under the RUDP protocol.
  • Reliable UDP reliable user datagram protocol
  • RUDP reliable user datagram protocol
  • TCP Transmission Control Protocol
  • AIMD Additional Increase Multiplicative Decrease
  • RTT the round-trip time of TCP packets
  • BDP network bandwidth delay products
  • UDP User Datagram Protocol
  • UDP is a message-based transport protocol designed to support network applications that need to transfer data between computers. By using port numbers to reserve their respective data transmission channels for different applications, the UDP protocol enables support for simultaneous transmission and reception of data for multiple applications at the same time.
  • the UDP protocol is a transmission protocol that does not need to establish a connection. It has the advantages of high efficiency, high speed and low resource consumption. It can significantly improve the efficiency of system transmission of data in message-based communication and real-time systems.
  • UDP does not guarantee a reliable transmission mechanism for transmitting data, and cannot satisfy the reliability requirements of application transmission data and messages.
  • the window flow control mode under the relevant RUDP sets the send window and the retransmission queue on the sending side, when located When the total number of data packets in the retransmission queue exceeds the size of the sending window, the data packet is stopped. In the window flow control mode, once the size of the sending window is set, it cannot be modified later. When there are fewer data packets in the retransmission queue, the sending window cannot be increased and the number of sending data packets is increased. When there are many data packets in the queue, the transmission window cannot be reduced, and the number of data packets sent is reduced. The flow control effect is poor.
  • the technical problem to be solved by the present invention is to provide a transmission window flow control method and terminal to solve the technical problem of how to dynamically control the transmission window traffic.
  • a method for transmitting window flow control comprising:
  • the sender sends a message requesting the size of the receiver window to the receiver
  • the receiving end sends the determined size of the receiver window to the sending end
  • the transmitting end adjusts the size of the sending window according to the size of the receiver window, and performs flow control through the adjusted sending window.
  • the step of determining, by the receiving end, the size of the receiving window according to the receiving window size and the out-of-order queue size includes:
  • the receiving end sums the lengths of the receiving window and the out-of-order queue, and uses the summation result as the size of the receiving window.
  • the step of the sending end adjusting the sending window size according to the determined receiver window size includes:
  • the sending end subtracts the length of the transmitting end retransmission queue from the sum of the lengths of the receiving window and the out-of-order queue as the length of the sending window.
  • the message is a first reliable user datagram protocol (RUDP) packet, and the message is provided with a field for requesting a size of the receiver window;
  • RUDP first reliable user datagram protocol
  • the receiving end sends the determined size of the receiver window to the sending end by using a second RUDP packet, where the second RUDP packet is provided with a field that identifies the size of the receiving window.
  • a transmitting end performing transmission window flow control, the transmitting end comprising: a transmitting unit, a receiving unit, and a window flow control unit, wherein
  • the sending unit is configured to: send a message requesting the size of the receiver window to the receiving end;
  • the receiving unit is configured to: receive the receiver window size from the receiving end;
  • the window flow control unit is configured to: adjust a size of the sending window according to the size of the receiving window, and perform flow control through the adjusted sending window.
  • the window flow control unit is configured to adjust the send window size according to the receiver window size as follows:
  • the receiver window size is the sum of the lengths of the receiving window and the out-of-order queue
  • the result of subtracting the length of the transmitting end retransmission queue from the sum of the lengths of the receiving window and the out-of-order queue is taken as the length of the sending window.
  • the message is a first reliable user datagram protocol (RUDP) packet, and the message is provided with a field for requesting a size of the receiver window;
  • RUDP first reliable user datagram protocol
  • the receiving unit is configured to receive the receiver window size from the receiving end according to the following manner: sending the determined receiver window size to the sending end by using the second RUDP packet, the second RUDP packet A field is set in which the size of the recipient window is set.
  • a receiving end that assists in sending window flow control includes: a receiving unit, a receiving side window size calculating unit, and a sending unit, wherein:
  • the receiving unit is configured to: receive a message requesting a size of the receiver window from the sending end;
  • the receiver window size calculation unit is configured to: determine a receiver window size according to a receiving window size and an out-of-order queue size;
  • the sending unit is configured to: send the determined size of the receiver window to the sending end.
  • the receiver window size calculation unit is configured to determine the receiver window size according to the receiving window size and the out-of-order queue size as follows:
  • the lengths of the receiving window and the out-of-order queue are summed, and the summation result is taken as the size of the receiving window.
  • the message is a first reliable user datagram protocol (RUDP) packet, and the message is provided with a field for requesting a size of the receiver window;
  • RUDP first reliable user datagram protocol
  • the sending unit is configured to send the determined size of the receiver window to the sending end according to the following manner: sending the determined size of the receiving window to the sending end by using a second RUDP message, the second A field identifying the size of the recipient window is set in the RUDP packet.
  • a computer program comprising program instructions that, when executed by a computer, cause the computer to perform any of the above methods of transmitting window flow control.
  • the transmitting end of the above technical solution can flexibly adjust the sending window according to the size of the receiving window, and realize dynamic control of the sending traffic.
  • FIG. 1 is a flowchart of a method for controlling a flow rate of a transmission window according to an embodiment of the present invention
  • FIG. 2 is a schematic diagram of an improved RUDP format of the embodiment
  • FIG. 3 is a block diagram showing a component of a transmitting end for performing transmission window flow control according to the embodiment
  • FIG. 4 is a block diagram showing the components of the receiving end of the flow control of the transmission window in the embodiment.
  • FIG. 1 is a flowchart of a method for controlling a transmission window flow according to an embodiment of the present invention.
  • S101 sends a message to the receiving end requesting the size of the receiver window
  • the format of the packet sent by the sending end to the receiving end is as shown in FIG. 2, and the sent message is filled in the “message body” field.
  • the main difference between the packet and the related RUDP packet is that the identifier of the receiving receiver window is increased. Field; in order to distinguish from the related RUDP message format, the message format shown in Figure 2 is represented in the SRUDP message format;
  • the transmitting end of the S104 adjusts the size of the sending window according to the determined size of the receiving window, and performs flow control through the adjusted sending window.
  • the window related information of the sender includes:
  • A indicates the size of the maximum send window MaxSndWind of the sender
  • B indicates the size of the send window CurSndWind of the sender, and B is used to control the send to the receiver. The number of messages sent, the number of messages sent to the receiving end cannot exceed B;
  • C indicates the retransmission queue size of the sender, RetranQueSize, and C indicates that the retransmission queue is used to buffer the number of messages that have been sent by the sender. If the sender receives a response to the sent message from the response message from the receiver, the slave retransmits the queue. Clear the corresponding message,
  • the sending queue indicates the sending queue size SndQueSize of the sending end; the sending queue caches the message that needs to be sent by the upper layer. When the connection meets the sending condition, the message in the sending queue will be sent and transferred to the retransmission queue; the sending queue may be a linked list;
  • the window related information of the receiving end includes:
  • a indicates the maximum receiving window MaxRcvWind size of the receiving end
  • b indicates the receiving window CurRcvWind size of the receiving end, b is used to control the number of messages received from the transmitting end, and the number of messages received from the transmitting end cannot exceed b;
  • c indicates the out-of-order queue size UnOrderQueSize of the receiving end.
  • the out-of-order queue is used to buffer the message arriving at the receiving end in advance; for example, the sending end sends the messages s1, s2, s3, and s4 in sequence, and the receiving end is caused by message loss or network delay. First receive s4. That s4 will be temporarily stored in the out-of-order queue;
  • d indicates the order queue size OrdQueSize of the receiving end.
  • the in-order queue is used to cache all messages that arrive at the local end in sequence. It is an instantaneous queue. The life cycle starts from the ordered message transferred from the out-of-order queue, and ends in an ordered message. To the application process.
  • the sending queue is only temporary, the message is sent to the driver layer to release the occupied space.
  • the sequential queue is only temporary. The message is sent to the upper application to release the occupied space. Therefore, the sending queue size D and the sequential queue size d depend on each node. Process processing efficiency, with uncertainty, is not used for window control.
  • the receiving end may send (b+c) as the receiver window size to the sending end; in the above step S104, the transmitting end adjusts the sending window size according to the determined receiver window size, and adjusts
  • the following steps of the flow control for the transmission window include: the sender then uses the result of (b+c)-C as the length of the transmission window, that is, the size of the transmission window.
  • the embodiment of the invention also discloses a computer program, comprising program instructions, which when executed by a computer, enable the computer to perform any of the above methods for sending window flow control.
  • the embodiment of the invention also discloses a carrier carrying the computer program.
  • Step 1 Successfully build the chain
  • Step 2 The sender writes the first message in the sending queue of the sending queue to the message body field of the SRUDP packet, and fills in the header of the SRUDP packet, where PackNo indicates the number of messages sent, which is the previous one.
  • the PackNo of the SRUDP packet is incremented by one;
  • AckNO is the sequence number of the largest message in the in-order queue learned by the sender from the receiving end;
  • Step 3 The sending end sends the SRUDP packet, and starts a retransmission timer.
  • Step 4 The receiving end receives the SRUDP packet, and updates the out-of-order queue and/or the in-order queue according to the PackNo in the SRUDP packet, and simultaneously determines whether it is necessary to immediately respond to the sent message, if it is not required to immediately respond to the sent message. Continue to determine whether the message in the in-order queue needs to be sent to the application process. If not, proceed to step four; if necessary, immediately respond to the sent message or determine that the message in the in-order queue needs to be sent to the application process. , perform step five;
  • Step 5 The receiving end fills in the response message, and writes the sum of the receiving window size and the out-of-order queue size into a field in the response message that identifies the size of the receiver window; AckNO is the message sequence number of the response; PackNo indicates the number of messages sent, The PackNo of the previous response message is incremented by one; the receiving end sends the filled response message; the response message may be an SRUDP message that the receiving end that does not include the “message body” field separately responds to the sending end, or may include a “message body” User data;
  • Step 6 The sender receives the response message and determines whether the retransmission timer expires. If there is no timeout, the retransmission timer is stopped, and the sender will reply the AckNO in the message with the message in the retransmission queue. The maximum number is compared. If the two are equal, all the messages sent by the sender receive the response from the receiver, and step 8 is performed. If the two are not equal, the message from 1 to AckNO in the retransmission queue is deleted, and the sender resets. Resend the timer, and perform step 6; after receiving the application message, if the retransmission timer expires, go to step 7;
  • Step 7 The sender sends the first message from the retransmission queue to the SRUDP packet, and performs step three.
  • Step 8 Clear the retransmission queue, determine the size of the sending window according to the received field of the identifier receiving window size, and continue to send data according to the re-determined sending window size.
  • FIG. 3 is a block diagram of a transmitting end component of a transmission window flow control according to the embodiment.
  • the transmitting end includes: a sending unit 301, a receiving unit 302, and a window flow control unit 303, where
  • the sending unit 301 is configured to: send a message requesting the size of the receiver window to the receiving end;
  • the receiving unit 302 is configured to: receive the receiver window size from the receiving end;
  • the window flow control unit 303 is configured to: adjust a size of the sending window according to the size of the receiving window, and perform flow control through the adjusted sending window;
  • the window flow control unit 303 is configured to adjust the send window size according to the receiver window size as follows:
  • the size of the receiving window is the sum of the lengths of the receiving window and the out-of-order queue
  • the result of subtracting the length of the transmitting end retransmission queue from the sum of the receiving window and the length of the out-of-order queue is used as the length of the sending window. , that is, the size of the sending window;
  • the transmitting end uses the Reliable User Datagram Protocol (RUDP) to transmit data to the receiving end, and adds a field for identifying the size of the receiving window in the RUDP message, as shown in FIG. 2 .
  • RUDP Reliable User Datagram Protocol
  • FIG. 4 is a block diagram showing the components of the receiving end of the flow control of the transmission window in the embodiment.
  • the receiving end includes: a receiving unit 401, a receiver window size calculating unit 402, and a sending unit 403, where:
  • the receiving unit 401 is configured to: receive a message requesting a size of the receiver window from the sending end;
  • the receiver window size calculation unit 402 is configured to: determine a size of the receiver window according to the size of the receiving window and the size of the out-of-order queue;
  • the receiver window size calculation unit 402 is configured to determine the receiver window size according to the receiving window size and the out-of-order queue size as follows:
  • the sending unit 403 is configured to: send the determined receiver window size to the sending end.
  • the receiving end uses the Reliable User Datagram Protocol (RUDP) to transmit data to the sending end, and adds a field for identifying the size of the receiving window in the RUDP message, as shown in FIG. 2 .
  • RUDP Reliable User Datagram Protocol
  • the transmitting end of the above technical solution can flexibly adjust the sending window according to the size of the receiving window, and realize dynamic control of the sending traffic. Therefore, the present invention has strong industrial applicability.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

一种RUDP协议下的发送窗口流量控制方法，所述方法包括：发送端向接收端发送消息的同时向接收端请求接收方窗口的大小；接收端接收所述消息，根据接收窗口大小和乱序队列大小确定接收方窗口大小；接收端将确定的接收方窗口大小发送至发送端；发送端根据所述确定的接收方窗口大小调整发送窗口大小，通过调整后的发送窗口进行流量控制。上述技术方案实现了对发送窗口流量进行动态控制。

Description

一种发送窗口流量控制方法和终端 技术领域
本发明涉及可靠的用户数据报协议(Reliable UDP，RUDP)，尤其涉及一种RUDP协议下的发送窗口流量控制方法和终端。
背景技术
目前保证数据可靠通信一般是采用传输控制协议(Transmission Control Protocol，TCP)。但这种协议不能很好的适应当前网络应用对数据传输的高效性和带宽适应性的要求。TCP协议中的AIMD(Additive Increase Multiplicative Decrease)算法虽然减少了TCP拥塞窗口，但不能快速的恢复可用带宽。另外，TCP拥塞控制中的不公平的RTT(TCP分组的往返时间)造成了拥有不同RTT的并发TCP流不公平地分享带宽。随着网络带宽延时产品(BDP)的增加，TCP的RTT的算法严重的限制了TCP协议在广域网分布式计算的效率。
传输层的另一个广泛使用的协议是用户数据报协议(UDP)。UDP是基于消息的传输协议，主要用来支持需要在计算机之间传输数据的网络应用。通过使用端口号为不同的应用保留其各自的数据传输通道，UDP协议可以实现对同一时刻内多项应用同时发送和接收数据的支持。UDP协议是不需建立连接的一种传输协议，具有效率高、速度快和占用资源少等优点，在基于消息通信和实时系统中可以显著提高系统传输数据的效率。但是UDP没有保障可靠传送数据的传输机制，不能满足应用程序传输数据、消息的可靠性要求。
为实现支持高性能数据传输，本领域相关技术人员将TCP和UDP的优点相结合，在UDP之上增加了一些保证数据可靠传递的控制机制，产生了RUDP(Reliable UDP)。
RUDP承载在UDP之上，它的可靠性通过重传和应答机制来保证的。相关RUDP下的窗口流量控制方式在发送侧设置发送窗口和重传队列，当位于 重传队列的数据报文总数超过了发送窗口的大小时，停止发送数据报文。这种窗口流量控制方式中，发送窗口大小一经设置，后续无法修改，当位于重传队列的数据报文较少时，无法增大发送窗口以及时增加发送数据报文的数量；当位于重传队列的数据报文较多时，也无法缩小发送窗口以及时减少发送数据报文的数量，流量控制效果差。
发明内容
本发明要解决的技术问题是提供一种发送窗口流量控制方法和终端，以解决如何实现对发送窗口流量进行动态控制的技术问题。
为解决上述技术问题，采用如下技术方案；
一种发送窗口流量控制的方法，所述方法包括：
发送端向接收端发送请求接收方窗口大小的消息；
所述接收端接收所述消息，根据接收窗口大小和乱序队列大小确定所述接收方窗口大小；
所述接收端将确定的所述接收方窗口大小发送至所述发送端；
所述发送端根据所述接收方窗口大小调整发送窗口大小，通过调整后的发送窗口进行流量控制。
可选地，所述接收端根据接收窗口大小和乱序队列大小确定接收方窗口大小的步骤包括：
所述接收端对接收窗口和乱序队列的长度求和，将求和结果作为接收方窗口的大小。
可选地，所述发送端根据所述确定的接收方窗口大小调整发送窗口大小的步骤包括：
所述发送端将所述接收窗口和乱序队列的长度之和减去发送端重传队列的长度后的结果作为发送窗口的长度。
可选地，所述消息为第一可靠用户数据报协议(RUDP)报文，所述消息中设置有用于请求接收方窗口的大小的字段；
所述接收端通过第二RUDP报文将确定的所述接收方窗口大小发送至所述发送端，该第二RUDP报文中设置有标识接收方窗口大小的字段。
一种进行发送窗口流量控制的发送端，所述发送端包括：发送单元、接收单元和窗口流量控制单元，其中，
所述发送单元设置成：向接收端发送请求接收方窗口大小的消息；
所述接收单元设置成：从所述接收端接收所述接收方窗口大小；
所述窗口流量控制单元设置成：根据所述接收方窗口大小调整发送窗口大小，通过调整后的发送窗口进行流量控制。
可选地，所述窗口流量控制单元设置成按照如下方式根据所述接收方窗口大小调整发送窗口大小：
当所述接收方窗口大小为接收窗口和乱序队列的长度求和时，将所述接收窗口和乱序队列的长度之和减去发送端重传队列的长度后的结果作为发送窗口的长度。
可选地，所述消息为第一可靠用户数据报协议(RUDP)报文，所述消息中设置有用于请求接收方窗口的大小的字段；
所述接收单元设置成按照如下方式从所述接收端接收所述接收方窗口大小：通过第二RUDP报文将确定的所述接收方窗口大小发送至所述发送端，该第二RUDP报文中设置有标识接收方窗口大小的字段。
一种协助发送窗口流量控制的接收端，所述接收端包括：接收单元、接收方窗口大小计算单元、发送单元，其中：
所述接收单元设置成：从发送端接收请求接收方窗口大小的消息；
所述接收方窗口大小计算单元设置成：根据接收窗口大小和乱序队列大小确定接收方窗口大小；
所述发送单元设置成：将确定的所述接收方窗口大小发送给所述发送端。
可选地，所述接收方窗口大小计算单元设置成按照如下方式根据接收窗口大小和乱序队列大小确定接收方窗口大小：
对接收窗口和乱序队列的长度求和，将求和结果作为所述接收方窗口大小。
可选地，其中，
所述消息为第一可靠用户数据报协议(RUDP)报文，所述消息中设置有用于请求接收方窗口的大小的字段；
所述发送单元设置成按照如下方式将确定的所述接收方窗口大小发送给所述发送端：通过第二RUDP报文将确定的所述接收方窗口大小发送至所述发送端，该第二RUDP报文中设置有标识接收方窗口大小的字段。
一种计算机程序，包括程序指令，当该程序指令被计算机执行时，使得该计算机可执行上述任意的发送窗口流量控制的方法。
一种载有所述的计算机程序的载体。
上述技术方案发送端可根据接收方窗口的大小灵活调整发送窗口，实现了对发送流量的动态控制。
附图概述
图1为本实施例的发送窗口流量控制方法流程图；
图2为本实施例改进的RUDP格式示意图；
图3为本实施例的进行发送窗口流量控制的发送端组成模块图；
图4为本实施例的协助发送窗口流量控制的接收端组成模块图。
本发明的较佳实施方式
下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在 不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
图1为本实施例的发送窗口流量控制方法流程图。
S101发送端向接收端发送请求接收方窗口大小的消息；
可选地，发送端向接收端发送的报文格式如图2所示，发送的消息填充在“message body”字段，该报文和相关RUDP报文的主要区别在于增加了标识接收方窗口大小的字段；为与相关的RUDP消息格式相区分，以SRUDP消息格式表示如图2所示的消息格式；
图2中SRUDP消息类型如表1所示：
Figure PCTCN2015072936-appb-000001
S102接收端接收所述消息，根据接收窗口大小和乱序队列大小确定接收方窗口大小；
S103接收端将确定的接收方窗口大小发送至发送端；
S104发送端根据所述确定的接收方窗口大小调整发送窗口大小，通过调整后的发送窗口进行流量控制。
假设：
发送端的窗口相关信息包括：
A:表示发送端的最大发送窗口MaxSndWind的大小；
B:表示发送端的发送窗口CurSndWind的大小，B用于控制向接收端发 送的消息的数目，向接收端发送消息的数目不能超过B；
C:表示发送端的重传队列大小RetranQueSize，C表示重传队列用于缓存发送端已经发送的消息数目，如果发送端从来自接收端的应答消息中接收到对发送消息的应答，则从重传队列中清除相应的消息，
D:表示发送端的发送队列大小SndQueSize；发送队列缓存上层需要发送的消息，在连接满足发送条件的时候，发送队列中的消息将被发送并转移到重传队列；发送队列可以是一个链表；
接收端的窗口相关信息包括：
a：表示接收端的最大接收窗口MaxRcvWind大小；
b:表示接收端的接收窗口CurRcvWind大小，b用于控制从发送端接收的消息的数目，从发送端接收消息的数目不能超过b；
c:表示接收端的乱序队列大小UnOrderQueSize，乱序队列用于缓存提前到达接收端的消息；如，发送端按序发送消息s1、s2、s3、s4，由于消息丢失或网络延时，导致接收端先收到s4.那s4会暂存到乱序队列中；
d：表示接收端的按序队列大小OrdQueSize，按序队列用于缓存所有按序到达本端的消息，它是个瞬时队列，生命周期起于乱序队列转过来的有序消息，止于有序消息发送到应用进程。
其中，A＝B+C+D；         式1
a＝b+c+d；               式2
由于发送队列只是临时存在，消息发送到驱动层即释放占用空间，按序队列也只是临时存在，消息发送到上层应用即释放占用空间，因此发送队列大小D与按序队列大小d依赖于各个节点进程处理效率，具有不确定性，不用于窗口控制。
为保证发送与接收数据的均衡，需要：
B+C＝b+c                 式3
结合式1～式3，可得
B＝(b+c)-C               式4
因此上述步骤S103中，接收端可将(b+c)作为所述接收方窗口大小发送至发送端；上述步骤S104中，发送端根据所述确定的接收方窗口大小调整发送窗口大小，通过调整后的发送窗口进行流量控制的步骤包括：发送端再将(b+c)-C的结果作为发送窗口的长度，也即发送窗口的大小。
本发明实施例还公开了一种计算机程序，包括程序指令，当该程序指令被计算机执行时，使得该计算机可执行上述任意的发送窗口流量控制的方法。
本发明实施例还公开了一种载有所述的计算机程序的载体。
下面以一个具体的应用示例对上述实施例进行进一步详细说明。
步骤一：成功建链；
步骤二：发送端将发送队列中位于发送窗口的第一条消息写入SRUDP报文的“message body”字段，同时填写SRUDP报文的消息头，其中，PackNo表示发送的消息数，为上一个SRUDP报文的PackNo加1；AckNO为发送端从接收端获知的按序队列中的最大消息的序号；
步骤三：发送端发送所述SRUDP报文，启动重传定时器；
步骤四：接收端接收所述SRUDP报文，根据SRUDP报文中的PackNo更新乱序队列和/或按序队列，同时判断是否需要立刻对发送消息进行应答，如果不需要立刻对发送消息进行应答，继续判断是否需要将按序队列中的消息向应用进程发送，如果不需要，则继续执行步骤四；如果需要立刻对发送消息进行应答或者判断出需要将按序队列中的消息向应用进程发送，执行步骤五；
步骤五：接收端填写应答消息，将接收窗口大小和乱序队列大小之和写入应答消息中标识接收方窗口大小的字段；AckNO为此次应答的消息序号；PackNo表示发送的消息数，为上一个应答消息的PackNo加1；接收端发送填写好的应答消息；所述应答消息可以为不包含“message body”字段的接收端单独应答发送端的SRUDP消息，也可以为包含“message body”的用户数据；
步骤六：发送端接收到应答消息，判断重传定时器是否超时，如果没有超时，停止重传定时器，发送端将应答消息中的AckNO与重传队列中消息的 最大序号相比较，如果两者相等，说明发送端所有发送的消息都接收到接收端的应答，执行步骤八；如果两者不相等，删除重传队列中从1～AckNO的消息，发送端重置重传定时器，执行步骤六；发送端接收到应用消息后，如果重传定时器超时，执行步骤七；
步骤七：发送端从重传队列中取出第一条消息写入SRUDP报文，执行步骤三，
步骤八：清空重传队列，根据接收的标识接收方窗口大小的字段确定发送窗口大小，根据重新确定的发送窗口大小继续发送数据。
图3为本实施例的进行发送窗口流量控制的发送端组成模块图。
该发送端包括：发送单元301、接收单元302和窗口流量控制单元303，其中，
所述发送单元301，设置成：向接收端发送请求接收方窗口大小的消息；
所述接收单元302，设置成：从接收端接收所述接收方窗口大小；
所述窗口流量控制单元303，设置成：根据所述接收方窗口大小调整发送窗口大小，通过调整后的发送窗口进行流量控制；
可选地，所述窗口流量控制单元303设置成按照如下方式根据所述接收方窗口大小调整发送窗口大小：
当接收方窗口大小为接收窗口和乱序队列的长度求和时，将所述接收端的接收窗口和乱序队列的长度之和减去发送端重传队列的长度后的结果作为发送窗口的长度，也即所述发送窗口的大小；
可选地，发送端使用可靠用户数据报协议(RUDP)向接收端传输数据，并且在RUDP报文中增加用于标识接收方窗口的大小的字段，如图2所示。
图4为本实施例的协助发送窗口流量控制的接收端组成模块图。
该接收端包括：接收单元401、接收方窗口大小计算单元402、发送单元403，其中：
所述接收单元401，设置成：从发送端接收请求接收方窗口大小的消息；
所述接收方窗口大小计算单元402，设置成：根据接收窗口大小和乱序队列大小确定接收方窗口大小；
可选地，所述接收方窗口大小计算单元402，设置成按照如下方式根据接收窗口大小和乱序队列大小确定接收方窗口大小：
对接收窗口和乱序队列的长度求和，将求和结果作为接收方窗口长度，也即所述接收方窗口大小；
所述发送单元403，设置成：将确定的接收方窗口大小向发送端发送。
可选地，接收端使用可靠用户数据报协议(RUDP)向发送端传输数据，并且在RUDP报文中增加用于标识接收方窗口的大小的字段，如图2所示。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现，相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。
需要说明的是，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
工业实用性
上述技术方案发送端可根据接收方窗口的大小灵活调整发送窗口，实现了对发送流量的动态控制。因此本发明具有很强的工业实用性。

Claims (12)

  1. 一种发送窗口流量控制的方法，所述方法包括：
    发送端向接收端发送请求接收方窗口大小的消息；
    所述接收端接收所述消息，根据接收窗口大小和乱序队列大小确定所述接收方窗口大小；
    所述接收端将确定的所述接收方窗口大小发送至所述发送端；
    所述发送端根据所述接收方窗口大小调整发送窗口大小，通过调整后的发送窗口进行流量控制。
  2. 如权利要求1所述的发送窗口流量控制的方法，其中，所述接收端根据接收窗口大小和乱序队列大小确定接收方窗口大小的步骤包括：
    所述接收端对接收窗口和乱序队列的长度求和，将求和结果作为接收方窗口的大小。
  3. 如权利要求2所述的发送窗口流量控制的方法，其中，所述发送端根据所述确定的接收方窗口大小调整发送窗口大小的步骤包括：
    所述发送端将所述接收窗口和乱序队列的长度之和减去发送端重传队列的长度后的结果作为发送窗口的长度。
  4. 如权利要求1～3中任一项所述的发送窗口流量控制的方法，其中，
    所述消息为第一可靠用户数据报协议(RUDP)报文，所述消息中设置有用于请求接收方窗口的大小的字段；
    所述接收端通过第二RUDP报文将确定的所述接收方窗口大小发送至所述发送端，该第二RUDP报文中设置有标识接收方窗口大小的字段。
  5. 一种进行发送窗口流量控制的发送端，所述发送端包括：发送单元、接收单元和窗口流量控制单元，其中，
    所述发送单元设置成：向接收端发送请求接收方窗口大小的消息；
    所述接收单元设置成：从所述接收端接收所述接收方窗口大小；
    所述窗口流量控制单元设置成：根据所述接收方窗口大小调整发送窗口大小，通过调整后的发送窗口进行流量控制。
  6. 如权利要求5所述的进行发送窗口流量控制的发送端，其中，所述窗口流量控制单元设置成按照如下方式根据所述接收方窗口大小调整发送窗口大小：
    当所述接收方窗口大小为接收窗口和乱序队列的长度求和时，将所述接收窗口和乱序队列的长度之和减去发送端重传队列的长度后的结果作为发送窗口的长度。
  7. 如权利要求5或6所述的进行发送窗口流量控制的发送端，其中，
    所述消息为第一可靠用户数据报协议(RUDP)报文，所述消息中设置有用于请求接收方窗口的大小的字段；
    所述接收单元设置成按照如下方式从所述接收端接收所述接收方窗口大小：通过第二RUDP报文将确定的所述接收方窗口大小发送至所述发送端，该第二RUDP报文中设置有标识接收方窗口大小的字段。
  8. 一种协助发送窗口流量控制的接收端，所述接收端包括：接收单元、接收方窗口大小计算单元、发送单元，其中：
    所述接收单元设置成：从发送端接收请求接收方窗口大小的消息；
    所述接收方窗口大小计算单元设置成：根据接收窗口大小和乱序队列大小确定接收方窗口大小；
    所述发送单元设置成：将确定的所述接收方窗口大小发送给所述发送端。
  9. 如权利要求8所述的协助发送窗口流量控制的接收端，其中，所述接收方窗口大小计算单元设置成按照如下方式根据接收窗口大小和乱序队列大小确定接收方窗口大小：
    对接收窗口和乱序队列的长度求和，将求和结果作为所述接收方窗口大小。
  10. 如权利要求8～9中任一项所述的协助发送窗口流量控制的接收端，其中，
    所述消息为第一可靠用户数据报协议(RUDP)报文，所述消息中设置有用于请求接收方窗口的大小的字段；
    所述发送单元设置成按照如下方式将确定的所述接收方窗口大小发送给所述发送端：通过第二RUDP报文将确定的所述接收方窗口大小发送至所述发送端，该第二RUDP报文中设置有标识接收方窗口大小的字段。
  11. 一种计算机程序，包括程序指令，当该程序指令被计算机执行时，使得该计算机可执行权利要求1-4中任一项所述的发送窗口流量控制的方法。
  12. 一种载有如权利要求11所述的计算机程序的载体。
PCT/CN2015/072936 2014-09-02 2015-02-12 一种发送窗口流量控制方法和终端 WO2016033948A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410443894.1A CN105376173B (zh) 2014-09-02 2014-09-02 一种发送窗口流量控制方法和终端
CN201410443894.1 2014-09-02

Publications (1)

Publication Number Publication Date
WO2016033948A1 true WO2016033948A1 (zh) 2016-03-10

Family

ID=55377991

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/072936 WO2016033948A1 (zh) 2014-09-02 2015-02-12 一种发送窗口流量控制方法和终端

Country Status (2)

Country Link
CN (1) CN105376173B (zh)
WO (1) WO2016033948A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113612737A (zh) * 2021-07-20 2021-11-05 天津七所精密机电技术有限公司 一种基于分组与重传机制的长报文可靠传输方法
CN114979172A (zh) * 2021-02-23 2022-08-30 腾讯科技（深圳）有限公司 数据传输方法、装置、设备以及存储介质

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111769968A (zh) * 2016-11-04 2020-10-13 华为技术有限公司 一种混合接入网络中处理报文的方法及网络设备
CN108092908B (zh) * 2016-11-23 2020-06-26 华为技术有限公司 控制流量的方法和发送端设备
CN107018086B (zh) * 2017-04-24 2019-09-24 中南大学 一种数据中心网络中基于数据包优先级的传输控制方法
CN109525502B (zh) * 2017-09-19 2022-09-13 宏碁股份有限公司 可靠用户封包协定装置及滑动窗参数的动态调整方法
CN107708199B (zh) * 2017-09-26 2021-01-26 南京哈卢信息科技有限公司 一种提高低功耗无线蜂窝网下行可靠性的方法
CN109729119A (zh) * 2017-10-30 2019-05-07 中兴通讯股份有限公司 一种协调数据同步数据的方法、装置、设备及存储介质
CN107819853B (zh) * 2017-11-13 2019-08-16 中国联合网络通信集团有限公司 一种数据传输方法及装置
CN110830472B (zh) * 2019-11-07 2021-09-24 西北工业大学 基于tcp/ip协议的灵活数据传输协议的灵活数据传输方法
CN112994851B (zh) * 2021-01-26 2022-03-29 中国科学院信息工程研究所 一种支持差异化可协商的并行数据通信方法及装置
CN114449057A (zh) * 2022-01-28 2022-05-06 北京威视锐科技有限公司 一种数据传输方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1921364A (zh) * 2005-08-25 2007-02-28 中兴通讯股份有限公司 基于消息的可靠传输层的并包发送和自适应窗口缩放方法
US20100017519A1 (en) * 2008-07-15 2010-01-21 Zhu Han Method and apparatus for dynamically determining connection establishment mechanism based on the relative locations
CN102045362A (zh) * 2010-12-21 2011-05-04 北京高森明晨信息科技有限公司 一种基于udp协议的数据传输方法和系统
WO2013178044A1 (zh) * 2012-05-30 2013-12-05 华为技术有限公司 一种数据传输方法、装置及系统

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7161978B2 (en) * 2001-08-29 2007-01-09 Texas Instruments Incorporated Transmit and receive window synchronization
CN101088243A (zh) * 2004-12-22 2007-12-12 艾利森电话股份有限公司 使用重复确认的数据流控制
CN1992582B (zh) * 2005-12-31 2011-05-25 中兴通讯股份有限公司 宽带信令链路自适应可变滑动接收窗口的实现方法
CN101212401B (zh) * 2006-12-29 2010-06-09 中兴通讯股份有限公司 面向网格的可配置数据传输方法及系统
CN101159520A (zh) * 2007-10-29 2008-04-09 中兴通讯股份有限公司 数据传输方法
CN101170504B (zh) * 2007-12-03 2010-06-02 北京天碁科技有限公司 无线链路控制层窗口流量的调整方法
CN101944982B (zh) * 2010-08-11 2013-04-10 南昌市恒鑫电子技术有限公司 基于时间驱动滑动窗口协议的流媒体实时转发方法
CN102469088A (zh) * 2010-11-17 2012-05-23 郑州威科姆科技股份有限公司 基于udp协议的大量数据传输方法
CN103780971A (zh) * 2012-10-23 2014-05-07 北京网动网络科技股份有限公司 一种互联网条件下基于rudp的实时视频传输方法
CN103067301A (zh) * 2013-01-17 2013-04-24 广东石油化工学院 基于用户数据报协议的快速可靠的拥塞控制改进算法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1921364A (zh) * 2005-08-25 2007-02-28 中兴通讯股份有限公司 基于消息的可靠传输层的并包发送和自适应窗口缩放方法
US20100017519A1 (en) * 2008-07-15 2010-01-21 Zhu Han Method and apparatus for dynamically determining connection establishment mechanism based on the relative locations
CN102045362A (zh) * 2010-12-21 2011-05-04 北京高森明晨信息科技有限公司 一种基于udp协议的数据传输方法和系统
WO2013178044A1 (zh) * 2012-05-30 2013-12-05 华为技术有限公司 一种数据传输方法、装置及系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114979172A (zh) * 2021-02-23 2022-08-30 腾讯科技（深圳）有限公司 数据传输方法、装置、设备以及存储介质
CN113612737A (zh) * 2021-07-20 2021-11-05 天津七所精密机电技术有限公司 一种基于分组与重传机制的长报文可靠传输方法

Also Published As

Publication number Publication date
CN105376173B (zh) 2020-04-28
CN105376173A (zh) 2016-03-02

Similar Documents

Publication Publication Date Title
WO2016033948A1 (zh) 一种发送窗口流量控制方法和终端
US10630749B2 (en) Timely delivery of real-time media problem when TCP must be used
US20180004705A1 (en) Selective acknowledgment of RDMA packets
CN108540380B (zh) 多子流网络传输方法及装置
EP3761591A1 (en) Tcp link configuration method, apparatus, and computer program product
JP2019506072A (ja) データ伝送方法および関連するデバイス
WO2022121469A1 (zh) 一种流量控制方法、装置、设备及可读存储介质
WO2013101942A1 (en) Tcp congestion control for large latency networks
WO2018121535A1 (zh) 一种负载均衡处理方法及装置
Chen et al. Mp-rdma: enabling rdma with multi-path transport in datacenters
WO2019001484A1 (zh) 一种实现发送端调速的方法、装置和系统
US10148543B2 (en) Connection-oriented communication devices with round trip time estimation
JP5832335B2 (ja) 通信装置および通信システム
US20240098034A1 (en) Out-of-order packet processing
US7869366B1 (en) Application-aware rate control
WO2018157819A1 (zh) 多子流网络传输方法及装置
US20150288763A1 (en) Remote asymmetric tcp connection offload over rdma
US10461892B2 (en) Low latency communications
JP2017011580A (ja) 通信装置およびその制御方法、プログラム
US20140204737A1 (en) Reducing round-trip times for tcp communications
US20110238858A1 (en) Traffic shaping device
JP2006148727A (ja) アプリケーションモニタ装置
CN117813595A (zh) 用于远程直接存储器访问的设备和方法
US20210273889A1 (en) Communication control apparatus, method, program, and non-transitory computer readable recording medium
US20140369189A1 (en) Method of controlling packet transmission in network system and network system transmitting packet using pseudo-tcp agent

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15837955

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15837955

Country of ref document: EP

Kind code of ref document: A1