CN104301079A - 使用重复确认的数据流控制 - Google Patents
使用重复确认的数据流控制 Download PDFInfo
- Publication number
- CN104301079A CN104301079A CN201410552877.1A CN201410552877A CN104301079A CN 104301079 A CN104301079 A CN 104301079A CN 201410552877 A CN201410552877 A CN 201410552877A CN 104301079 A CN104301079 A CN 104301079A
- Authority
- CN
- China
- Prior art keywords
- data segment
- data
- sequence
- transmit leg
- duplicate
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements 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/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1858—Transmission or retransmission of more than one copy of acknowledgement message
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements 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/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
本发明描述了一种控制一定量数据从给定通信协议的发送方流到接收方的方法。该方法包括将该一定量的数据分成多个数据段,其中,数据段在序列中排序。段按所述序列顺序发送到接收方。接收方确认正确接收的数据段,并识别按序列正确顺序接收的序列最后正确接收的数据段。发送方设置为在它接收阈值数量的重复确认时,执行重新传输。触发重新传输的阈值数量是一个基于接收窗口大小确定的自适应参数,接收窗口大小表示接收方缓冲区空间中可存储的数据段数量。
Description
技术领域
本发明涉及控制一定量数据从给定通信协议的发送方流到接收方的方法。
背景技术
在通信领域,数据传输技术已为人熟知,在这些技术中,要传送的一定量数据分成多个数据段,数据段在序列中排序。这些数据段随后按所述序列的顺序传送。
此过程在通信的所谓发送方进行,而通信由包含处理此类数据段的规则的预定协议控制。与预定协议相关联的接收实体称为接收方。协议、协议层次结构、分层和协议方的概念在技术领域已为人熟知,例如,请参阅“TCP/IP详解卷一:协议”(参见“TCP/IPIllustrated Volume1,The Protocols”byW.Richard Stevens,Addison Wesley1994)。TCP/IP协议套件中熟知的传输控制协议(TCP)是将要发送的数据安排成段序列的此类协议一个示例。
一般情况下,各个段将置于具有给定协议定义结构的数据单元中以便发送。这些数据单元可在不同协议上下文中具有不同名称,如分组、帧、协议数据单元、信元等。在本说明中,术语“数据单元”将一般用于涵盖任一此类定义的数据结构。本说明书将交互使用术语“段”和“数据单元”。
发送方将数据单元向下传递到更低层,例如,TCP发送方将TCP段经IP层传递到链路层,并且在接收端,接收方将从更低层接收数据单元。定义数据单元,例如,定义开始和结束的预定结构允许接收方识别各个段。
可注意到的是,根据OSI分层概念,传递到较低层的数据如何处理和传输到该处并不重要。也就是说,给定发送方将比特流向下传递,并且接收方接收比特流,其中,此比特流包含某些识别要素,如帧边界指示符,而接收方可借助于这些要素识别各个数据单元和各个段。
为确保数据可靠传输,许多协议提供数据单元重新传输功能,这意味着必要时可重传该序列的段。一般情况下,这将借助于确认技术而得以实现,这意味着通过接收方发回发送方的适当确认消息,接收方确认对数据单元的正确接收。一旦发送方收到此类确认消息,它便可适当地继续发送其他数据单元,或者如果未收到确认消息或收到非确认消息,则可由发送方重传接收方未正确接收的数据单元。
几个机制已为人熟知,借助于这些机制,假定发送方得到数据单元或段丢失已发生的指示,从而可进行适当的重新传输。一个此类熟知的功能是重新传输超时,它意味着在发送数据单元后监视计时器,并且在预定量的时间过去后未收到给定数据单元的确认时,假设数据单元已丢失,并相应地进行重传。
另一个此类机制是统计重复确认。重复确认是将以前已经确认的数据段识别为最后正确接收的数据段的一种确认。也说是说,诸如TCP等许多协议具有一种用于接收方的确认生成机制,用于为序列每个正确接收段发送出确认消息,而确认识别按序列顺序最后正确接收的数据段。换而言之,例如,如果第一到第四数据段已接收并确认,并且随后第五个数据段到达,则接收方将发送出该第五段的确认。如果之后第七和第八段正确到达,则接收方将再次发送出一个或两个确认消息,但这些确认消息将只识别第五个段,这是因为第五个段是按该序列顺序正确接收的最后段。也说是说,接收方预期第六段到达,并且即使它正确接收第六段后的段,它仍将继续确认第五段。因此,如果发送方收到重复确认,则这向发送方指示数据单元已丢失。
根据上述机制,确认消息只确认按序列顺序正确接收的最后数据单元,因此,在使用该机制的协议中,即使位于所述序列中后面的数据单元已收到,但在发送方收到预定数量的重复确认时,重新传输机制仍会实现以执行重新传输。在TCP中,对应的机制称为“快速重传”,其中,在收到三个重复确认后执行重新传输。TCP中快速重传机制的详细说明可在Stevens所述上述书籍中第21.7章节中找到。
本发明解决的基本问题
上述接收数据单元已丢失指示的所有此类机制具有的问题是发送方只接收数据单元丢失的间接指示,并且实际上预定触发事件(超时或预定数量的重复确认)的出现不一定表示数据单元确实丢失。在通过网络输送与序列中后面段相关联的数据单元的同时,这些触发事件也会虚假产生,例如,数据单元在传输网络中被延迟。此类现象也称为重新排序。
发明目的
本发明的目的是全面改进发送方中处理段的重新传输的可能性。
发明内容
本发明的此目的通过一种控制数据段序列从发送方流到接收方的方法而得以解决,包括:按序列顺序将数据段从发送方传送到接收方;从接收方接收确认消息,其中,确认消息指示按序列正确顺序正确接收数据段;数据段已接收但不是按序列正确顺序接收时,在发送方接收来自接收方的重复确认消息,接收的重复确认消息与按数据段序列顺序最后正确接收的分组相关联;在发送方收到的重复确认消息数量达到基于接收窗口大小确定的重复确认消息阈值时,判定已发送但未确认的数据段已丢失,接收窗口大小对应于接收方缓冲区空间中可存储的数据段数量;以及重传确定丢失的数据段。
相应地,发送方可通过考虑接收方的情况而设置重复确认消息阈值。
根据另一实施例,设置重复确认阈值,使得确定丢失的数据段在数据段序列中在某个时间点之前被重传,选择所述时间点,使得指示该确定丢失的数据段(即重传的数据段)的正确接收的确认消息预期在传送序号超出该确定丢失的数据段的序号接收窗口大小的数据段之前在发送方被接收。相应地,阈值可始终保持为使接收方资源得到最佳利用的值。
根据另一实施例,基于由接收窗口大小与未确认内容大小之间的差构成的可使用窗口大小,确定重复确认消息阈值,未确认内容大小表示尚未确认的已传送数据段数量。
更进一步说,可基于可使用窗口大小与未确认内容大小之间的差确定重复确认消息阈值。
根据另一实施例,在接收第一个重复消息前一个时刻,将重复确认消息阈值确定为值1与通过计算
(接收窗口大小-(k×未确认内容大小))
而得到的值中的较大值,其中,k是浮动量。有利的情况下,k=2。
更进一步说,可将重复确认消息阈值确定为
接收窗口大小-(2×未确认内容大小)+N,
N构成满足以下条件的可调参数
(2×未确定内容大小)-接收窗口大小+1<N<3。
根据另一实施例,在确定接收窗口大小变化时更新重复确认消息阈值。
或者,至少在每第一次收到数据段之一的重复确认消息时,可更新重复确认阈值。这种情况下,可调参数N最好可设为5。
在另一替代选择中,每次收到确认消息时更新重复确认消息阈值。
根据另一实施例,在发送方受阻而无法传送以前未发送的数据段时,重传确定丢失的数据段。
在此实施例中,如果满足以下条件之一,则可视为发送方受阻:以前未发送的数据段数量超过接收窗口大小;以前未发送的数据段数量超过发送窗口大小;或者构成数据段源的应用未提供用于传输的数据段。
一种计算机程序在计算机上执行时可设置为执行至少以上操作之一。
一种计算机可读存储器可存储该计算机程序。
更进一步地说,本发明的目的通过一种控制数据段序列从发送方流到接收方的通信装置而得以解决,包括:按序列顺序将数据段从发送方传送到接收方的组件;从接收方接收确认消息的组件,其中,确认消息指示按序列正确顺序正确接收数据段;数据段已接收但不是按序列正确顺序接收时,在发送方接收来自接收方的重复确认消息的组件,接收的重复确认消息与按数据段序列顺序最后正确接收的分组相关联;在重复确认消息数量达到基于接收窗口大小确定的重复确认阈值时,判定已发送但未确认的数据段已丢失的组件,接收窗口大小对应于接收方缓冲区空间中可存储的数据段数量;以及重传确定丢失的数据段的组件。
附图说明
图1示出根据本发明实施例,控制数据序列流动的方法的操作;
图2示出根据本发明实施例,确定重复确认阈值的操作;
图3示出根据本发明另一实施例,控制数据段从发送方流到接收方的操作,特别是概括了重传未确认数据段的流程;
图4示出根据本发明实施例,更新重复确认阈值的操作;
图5示出根据本发明实施例,更新重复确认阈值的操作;以及
图6示出控制数据段流动的通信装置,该通信装置至少充当发送方;以及
图7示出在发送方与接收方之间数据段和确认消息流动的详细图示,以示出重复确认阈值的确定。
具体实施方式
本发明适用于给定通信协议的任一实现,而要发送到该实现的一定量数据分成多个数据段,并且所述数据段在序列中排序,其中,数据段按所述序列的顺序从发送方发送到接收方;其中,接收方将确认发送到发送方,所述确认指示按序列正确顺序的正确接收,使得确认消息指示按序列正确顺序接收的所述序列的最后正确接收的数据段;以及其中,如果发送方接收阈值数量的确认消息,而每个消息标识的数据段与按正确顺序接收的段中最后正确接收的数据段相同,则重传紧跟在收到其重复确认的段后的段。
此类协议的一个示例为TCP。然而,明显可注意到,具有上述特征的任何其他通信协议只要适合实现本发明概念,则本发明也适用于这些协议。
根据本发明,确认消息的阈值数量,即,重复确认阈值是基于接收窗口大小确定的参数,接收窗口大小表示在接收方缓冲区空间中可存储的数据段数量。
如前面已经叙述的一样,重复确认阈值因此是一个与发送方的判定相关联的参数,该判定是关于在假设给定段(要接收用于其的重复确认)已丢失前的等待时长。根据本发明解决方案,据此阈值是可修改的,由于本发明解决方案的原因,可使此判定本身自适应并因此变得更灵活。
图1示出根据本发明实施例,控制发送方与接收方(未示出)之间数据段流动的操作。
在第一操作101中,假定发送方执行按某一给定顺序将数据段传送到接收方的普通例程。例如,数据段连续编号,如01、02、03、04、05、06...,并且安排为在发送方按有序编号的顺序传输。例如,正如本领域中熟知的一样,有序编号可适当地对应于数据源数据段的输出。应当理解,数据段可承载任一种类的有效负荷数据,即,与任一种类应用或格式有关的数据,如话音数据、在通信会话中计算机装置之间的数据交换、视频数据、音频数据及诸如此类。
接收方(图1中未示出)接收数据段并通过返回到发送方的确认消息确认数据段的接收。在操作102中,来自接收方的这些确认消息在发送方接收。如果操作正常,并且按顺序传送的数据段在接收方以相同的顺序接收,则每个数据分组可通过确认消息进行确认,并且发送方知道数据段按序列的正确顺序接收。已从发送方传送并正确确认的数据段由于不需要重新传输,因此,这些已传送数据段可被丢弃,例如,从发送方的传送缓冲区中删除。
一般地说,每个正确接收,即无误差且按序列顺序接收的数据段将在接收方触发确认消息,该消息返回到发送方。如果在一个正确接收的数据段之后,接收了不按序列顺序的数据段,即传送数据段中发生了延迟或故障,则最后正确接收数据段的确认消息会重复发送,并且该重复的确认消息称为重复确认消息。
在上述示例中,如果由于一个原因或其他原因,数据段未按传送序列的正确顺序接收,例如,数据段05在段01、02、03后但在数据段04前接收,接收方因此不会向发送方返回确认消息。相反,接收方向发送方传送重复确认消息,指示数据段已接收但不是按序列的顺序接收。重复确认消息与数据段序列顺序中最后正确接收的分组相关联。在数据段04之前接收数据段05的上述示例中,重复确认消息将指示按序列顺序正确接收的最后数据段为数据段03。
在操作103中在接收方接收的重复确认消息因此通知发送方,如果证实或确定在从发送方到接收方的传输路径期间确实丢失了在最后正确接收分组后的分组,则可能需要重新传输此数据分组。因此,对于在操作103中接收的重复确认消息指示的最后正确接收数据分组后传送的所有那些数据分组,发送方可以不从发送缓冲区丢弃它们。
然而,发送方继续将数据段传送到接收方,并因此假定在更长时期内在接收方仍未收到上述示例的数据段04,接收方继续为每个接收数据段传送重复确认消息。相应地,发送方接收越来越多的重复确认消息,并且对于每个重复确认消息,未确认数据段确实丢失的可能性在增大。
在操作104中,发送方现在判定重复确认消息的数量是否达到或超过在发送方适当设置(如后面所述)的重复确认消息阈值。如果在操作104中,判定为“否”,指示重复确认消息阈值尚未达到,则操作流程返回操作101,即,发送方继续按序列顺序传送数据段。
然而,如果在操作104中判定为“是”,指示重复确认消息阈值已达到或超出,则在操作105中,发送方判定已发送但未确认的数据段已丢失。继续上述示例,通过指示按序列顺序最后正确接收的数据段为数据段3的重复确认消息,发送方将判定数据段4确实已丢失。
在操作106中,重传确定丢失的数据段,即示例中的数据段04。重新传输例如可通过根据TCP协议的快速重传执行。
当然,适当设置重复确认消息阈值极其重要,要牢记,太早重新传输数据分组会引起不必要的业务量,并且如果限制重传数据段的时间太长,则由于已传送但未确认的所有数据段必须保持在发送方、接收方的缓冲区中,因而会阻止进一步传输。
最重要的是,要获得极佳的流控制,可根据接收方接收窗口大小设置重复确认消息阈值,接收窗口大小构成在接收方缓冲区空间中可存储的数据段数量。接收窗口大小例如可由接收方通过确认消息报告,使得发送方始终了解接收窗口的当前大小。
更精确地说,应设置阈值,使得在任何时间点都不会由于在发送方到达最大允许的传送但未确认的数据段而禁止传输数据段,此最大数量等于接收窗口大小。注意,根据滑动窗口协议,如果最早确认数据段的序号与下一要传输数据段序号之间的差未超过接收窗口大小,则只可安排传输根据通信协议的发送方数据段。
上述内容说明了一个实施例,其中,重复确认阈值的计算使用接收窗口大小。要注意的是,即使在此不进一步描述,也可另外基于发送方的情况,例如发送方某个窗口大小而使重复确认阈值进一步被修改以进一步改进重复确认阈值的设置。
在下述内容中,将按照图2描述本发明又一实施例。图2示出用于适当设置重复确认消息阈值的操作。
如上所述,阈值要适当选择,从而可确实避免接收方的缓冲区溢出,并还可确实避免来自发送方的数据段传输停止。已发送但未确认的数据段数量要超过接收窗口大小时在发送方会发生传输停止或阻塞。
要满足这些条件,必须始终确保在最早未确认数据段之后已传送的数据段及包括该数据段的数量不超过发送方接收窗口大小。
相应地,如果某个数据段尚未确认,则此数据段的重新传输要安排在某个时间点,在该时间点仍允许正确接收此数据段重新传输的确认在安排具有某个序号的数据段传输前到达发送方,而如果重传数据段的正确确认未收到,该传输可能导致接收方缓冲区溢出。
换而言之,需要执行未确认数据段的重新传输,使得在自未确认数据段以后已传送的数据段及包括该未确认数据段的数量超过接收窗口大小前,在发送方预期要收到与此重新传输有关的确认。如果此条件未得到满足,则发送方将不允许传送其他数据分组,并且连接将停止。
在图2的操作201中,判定是否应根据后面描述的条件更新重复确认消息阈值。如果判定为“是”,则在操作202中,根据以上所述设置重复确认消息阈值,使得确定丢失的数据段在数据段序列中在某个时间点或其之前重传,选择所述时间点,使得指示该确定丢失的数据段的正确接收的确认消息预期在安排序号超出该确定丢失的数据段的序号接收窗口大小的数据段以供传输之前在发送方被接收。相应地,可避免发送方被禁止传送其他数据段的情况。
这种情况下,可避免数据传输中的窗口停止,并还可避免接收缓冲区溢出。
图3示出描述本发明实施例的流程图。流程图的左侧与一般的流控制有关,但由于本发明不涉及一般类型的流控制,例如,如TCP或任何其他流控制协议提供的流控制原因,此部分只以示意图方式显示为虚线。图的右侧公开了处理重复确认的过程。也说是说,在一般流控制期间收到确认(ACK)(参见操作301)时,这会触发处理重复确认的过程。
在操作302中,确定确认是否为重复确认。也说是说,确定识别按序列正确顺序接收的序列最后正确接收数据段的特定确认的次数N,并断定此数量N是否大于1。如果不大于1,则ACK不是重复ACK,并且过程返回一般流控制。
如果操作302的结果指示确认是重复确认,则过程转到操作303,在该操作中,确定N(ACK)是否达到重复确认阈值Th。视实现而定,N(ACK)等于重复确认阈值时可视为达到重复确认阈值。或者,N(ACK)大于重复确认阈值时可视为达到重复确认阈值。
此操作可以任一适当的方式实现,例如,通过简单地保持最后确认段的记录并设置相关联计数器,使得在新接收确认与以前的确认相同(即,重复确认)时,计数器值增加1,并且如果新确认识别在最后接收确认中识别的段后的段,则计数器值重置为1。
在图3的示例中,N(ACK)指示发送方已接收给定确认ACK的次数。换而言之,N=1表示给定段的确认是初次接收,并且数字N>1指示它是重复确认。
如果操作303确定确认的数量达到阈值,则在操作305中重传最早未确认的段。最早未确认的段因而紧跟在重复确认中识别的段之后。另一方面,如果操作303的结果是否定的,则流程继续到操作304以便也考虑发送方的情况。
在操作304中,确定发送方是否由于在发送方发生的条件而受阻,无法传送数据段。在上连接中的受阻表示发送方不可或无法传送数据段到接收方。
根据示例,如果以前未发送数据段的数量超过接收窗口大小,则可视为发送方受阻。例如,由于误差或无法预料的条件的原因,可能选择大的重复确认阈值,并且可能达到接收窗口大小。这种情况可称为接收端被限制。
根据另一示例,如果以前未发送数据段的数量超过发送窗口大小,则可视为发送方受阻。例如,发送方的传送缓冲区可以为共享存储器区域,具有大小减少的用于存储数据段的空间,如低于接收窗口大小。这种情况可称为发送端被限制。
根据另一示例,构成数据段源的应用不为传输提供数据段时可视为发送方受阻。例如,数据段可动态生成,例如有关某个网页,并且应用可暂时停止生成新的数据段。此外,应用可能只是目前无其他数据段要传输。这种情况可称为应用被限制。
如果在操作304中确定发送方受阻而无法传送数据段,则在操作305中重传最早未确认的段。
如果在操作304中确定发送方未受阻,可传送数据段,则在操作306中传送序列中紧跟在重复确认中识别的段之后的段后的下一段。
在操作305或306后,过程返回一般流控制。
要注意的是,操作304可以为可选操作,并且在替代选择中,如果在操作303中的判定为“否”,则流程可转为返回一般流程,或者继续到操作306以传送序列中的下一数据段。
可以注意到,图3的实施例只是一个示例,并且该示例可按多种方式变化。技术人员将理解,操作也可按不同的方式安排。另外,操作306只是一个示例,这是因为本发明并未具体涉及在重复确认阈值超过后的过程。换而言之,可按任一适当或适合的方式选择超过重复确认阈值后的过程,其中,将进一步继续论述TCP类似协议的不同可能性。
同样地,一般流控制中对重复确认的响应不是本发明所必需的。例如,在操作303的结果为表示重复确认已接收但重复确认的数量尚未达到阈值的否定结果后,一般流控制可停止发送任何其他段,或者可同样良好地继续发送其他段。
重复确认阈值可按任一适合或所需的方式设置或更新。例如,它可基于用于修改阈值的一个或多个值被定期更新。换而言之,定期测量或确定这些一个或多个值,并相应地更新阈值Th。该过程在图3所示外的范围,在一个独立过程中进行。因此,此独立过程定期更新适当存储的Th值,并且操作303和304只访问或调用Th的当前值。另一方面,也可能在预定的触发事件发生时更新Th。一个可能性可以是仅在用于修改Th的一个或多个值中一个或多个值已更改时才更新Th。此类过程将同样独立于图3所示,并且操作303和304将只是访问或调用Th当前值。
然而,指定的触发事件也可以为图4所示过程的一部分。也就是说,可能在与确认接收相关联的触发事件发生时执行Th更新。例如,可在每第一次接收重复ACK时更新Th。这在图4中示出,图中,与图3中所用相同的标号指相同的操作。换而言之,图4所示的操作401和402在如图3所示操作302与303之间实现。在操作302确定已收到重复确认后,操作401确定该重复确认是否为第一重复确认,也说是说,N(ACK)是否等于2,并且如果情况如此,则在操作402中更新Th。在操作401或402后,执行操作303并且所有其他操作已经结合图3论述,因而不必做其他论述。
也可能在每次重复确认时执行Th更新。这在图5中示出。也说是说,更新操作501在操作302后执行,使得每个重复确认引起Th更新。
另一个在图中未示出的替代选择是,也可在每个确认时更新阈值Th。换而言之,更新操作可在图3的操作301与302之间实现。另一变化可以是在涉及未解决数据段的每个ACK时,即仅对N(ACK)=1情况下的此类确认更新阈值Th。因此,更新操作可在图3中操作302的否定输出时实现。
如上所述,只要适合或需要便可进行重新确认阈值Th的更新。同样地,如上所述,通过将接收方的接收窗口大小考虑在内,可在任何适当或适合的基础上进行更新。
在下述内容中,将按照图6描述本发明又一实施例。图6示出控制在发送方与接收方之间例如利用TCP协议或任何其他适合的通信协议传送的数据段流动的发送方元件。
图6示出发送方600,如任何种类型的计算装置,例如,台式计算机、膝上型计算机、诸如PDA或移动电话等移动计算机装置及诸如此类。本发明同样适用于有线范围数据交换及无线或至少部分无线数据传输。
发送方包括传送/重传组件601,用于如按照前面实施例所述,按序列的顺序将数据段从发送方传送到接收方,并重传确定丢失的数据段。
此外,发送方包括接收组件602,用于从接收方接收确认消息,在数据段按序列的正确顺序正确接收时这是确认消息,并且在数据段已接收但不是按序列的正确顺序接收时用于从接收方接收重复确认消息,接收的重复确认消息与按数据段序列顺序最后正确接收的数据段相关联。
此外,发送方包括分组丢失确定组件603,用于在重复确认消息数量达到基于接收窗口大小确定的重复确认消息阈值时,判定已发送但未确认的数据段已丢失,接收窗口大小对应于在接收方缓冲区空间中可以存储的数据段数量。分组丢失确定组件可通过从接收方接收的确认消息或通过任何其他手段,获得有关接收窗口大小的信息。
此外,分组丢失确定组件可适用于:设置重复确认阈值,使得确定丢失的数据段在数据段序列中在某个时间点被重传,选择所述时间点,使得指示该确定丢失的数据段(即重传的数据段)的正确接收的确认消息预期在传送序号超出该确定丢失的数据段的序号接收窗口大小的数据段之前在发送方被接收。
在下述内容中,将按照图6描述本发明又一实施例。
图7示出用于通过使用TCP协议示例来进一步说明确定重复确认消息阈值的原理的详细实施例。
图7示出例如按照前面实施例所述的发送方和接收方。
在发送方,示出了标记为01、02、03...30,要传输到接收方的数据段序列,包括被认为在传输路径上丢失或延迟过长的数据段01的重新传输。根据下述原因,数据段01在数据段22后重传。
在图7实施例中,重复确认阈值基于接收窗口大小设置,并且更精确地说,其被设置,使得确定丢失的数据段在数据段序列中在某个时间点被重传,选择所述时间点,使得指示该确定丢失的数据段的正确接收的确认消息预期在传送序号超出该确定丢失的数据段的序号接收窗口大小的数据段之前在发送方被接收。重传数据段01的时间点构成在发送方将发生停止前可能的最近时间点。因此,在应避免进一步延迟的传输,即进一步增大的重复确认阈值的同时,一般将可能实现更少的延迟,即,减小的重复确认阈值。
在本情况中,接收窗口大小假设为30,即,接收缓冲区具有30个存储位置用于数据段。这意味着对于数据段传输,仅在收到第一数据段的确认后才可传送第31个数据段。
在图7示例中,如上所述并且如虚线箭头所示,假设在发送方作为第一数据段传送的数据段01沿传输路径丢失。假设数据02、03等正确传送和接收。
相应地,由于数据段01在接收方缺失,因此,在接收方数据段02的接收将触发返回第一重复确认消息(DUPACK),假设在数据分组10传输后及数据分组11传输前在发送方接收该消息。此DUPACK延迟与传输延迟、处理延迟等相关联。类似地,由于数据段01继续缺失,因此,在接收方所有随后的数据段接收将触发重复确认消息从接收方传输到发送方,如图7左侧所示,接收方接收越来越多的重复确认消息。如果发送方将继续按序列顺序传送数据段而不重传第一数据段01,则最后将传送数据段30,并且由于将达到接收窗口大小而将不得不停止传输。换而言之,由于30个数据段的确认未解决,30个数据段从数据段01开始并包括该数据段,因此,将不允许在数据段30后的其他传输。例如,已发送但未确认的数据段数量要超过接收窗口大小时在发送方会发生传输停止或阻塞。
为避免此情况,如图所示,在收到第14个传送的数据分组,即数据分组14触发的第13个重复确认消息后,重传第一个数据分组01,以便在数据段31要传送前允许重传的数据段01的确认有足够的时间到达发送方。相应地,数据段01应正好或最迟在接收第13个重复确认消息后在数据段22后传送,以避免数据段30后数据段序列传输的停止。
因此,除非接受传输停止或通过其他手段避免传输停止,否则,必须避免此示例中在第13个重复确认消息后重传数据段01。更早的传输不会引起任何停止,但增加了由于可能不必要的重新传输而引起的网络业务量。换而言之,如图7所示,应等待尽可能长才重传数据段01,从而可避免在传输的发送方出现停止。
有利的是,因此基于由接收窗口大小与未确认内容大小之间的差构成的可使用窗口大小,确定重复确认消息阈值,未确认内容大小表示尚未确认的已传送数据段数量。例如,如果假定在传送数据段10时计算重复确认消息阈值,则未确认内容大小,即已传送但尚未确认的数据段为10。此外,如图所示的可使用窗口定义为接收窗口大小减去发送窗口大小,即,为已发送但未确认的数据段最低序号的发送窗口左缘与尚未发送的数据段最低序号的发送窗口右缘之间的差。换而言之,可使用窗口为在任一给定时间点,在条件允许时接收方变得受限前TCP发送端可发送的数据量。
更进一步说,优选是可基于可使用窗口大小与未确认内容大小之间的差设置重复确认阈值。更精确地说,根据另一示例,如果再次假定正好在接收第一重复确认消息前,即在传送数据段10时计算重复确认阈值,则满足图7所示和以上所述条件的重复确认消息阈值为
可使用窗口大小+2-(未确认内容大小-1)这等于
可使用窗口大小-未确认内容大小+3。
在另一替代选择中,假定在接收第一重复确认消息时,即在传送数据段11时计算重复确认阈值,请参阅用于更新阈值的前面实施例,可使用窗口大小将减少1,未确认内容大小将增加1,并且因此重复确认阈值将计算为
可使用窗口-未确认内容大小+5。更一般地说,重复确认阈值可计算为
可使用窗口大小-未确认内容大小+N并且在上述条件下
可使用窗口=接收窗口-未确认内容大小得出重复确认阈值为
接收窗口大小-2×未确认内容大小或者仍更一般地说,
接收窗口大小-(k×未确认内容大小)其中,k为浮动量。
更进一步说,根据另一示例,如果假定如图7所示在接收第一个重复确认消息前一个操作计算重复确认阈值,则重复确认阈值确定为
接收窗口大小-(2×未确认内容大小)+N,N构成满足以下条件的可调参数
(2×未确定内容大小)-接收窗口大小+1<N<3。同样地,如上所述,如果在一个操作后,即,在接收第一个重复确认消息时计算重复确认阈值,则N<3要替换为N<5。有利地是,这种情况下,可调参数N可设为5,从而满足上述条件:在以前未发送的数据段(即,初次发送的数据段)数量超过接收窗口大小前,收到重传数据段的确认。如果该条件未满足,则由于在已发送但未确认的数据段数量未超过接收方通知的接收窗口大小时发送方只可传送序列中的其他数据段,因此,这将导致在发送方传输停止。
使用以上公式,如果未确认内容大小相对于接收窗口较大,则可能得到负重复确认阈值。为避免此类负重复确认阈值,可使用最大值算子,这可防止重复确认阈值得出此类负值。相应地,在图7所示时间,即在接收第一个重复确认消息前计算重复确认阈值的优选方式为
重复确认消息阈值=max(接收窗口大小-2×未确认内容大小+N,1)。
在下述内容中,描述了可如何确定可调参数N的示例。如上所述,在N=3,并在接收第一个重复确认消息前一个操作确定重复确认消息阈值时,第一个数据分组01重新传输的确认正好在接收窗口“填满”后收到。然而,仅在只有一个分组丢失并且未发生分组重新排序的条件下,这是有效的。在两个条件有效的情况下,N超过3的任一增大将最终导致窗口停止,即,发送方将不被允许传送任何其他数据分组。因此,N=3被认为是N的上限。然而,要注意的是,在不止一个段已丢失的情况下,可进一步增大N并仍可避免窗口停止。然而,这将不是典型的情况,因此,N=3可优选选择为上限。
对于N的下限,一个合理的要求是计算重复确认阈值的任一算法将计算大于或等于1的值。这是在以下条件获得的值
N=(2×未确认内容大小-接收窗口-1)。
一般而言,在N降低时,系统变得较不平稳,即,误差恢复会较早地触发,换而言之,较早地断定数据分组丢失。然而,使用降低的N及因此降低的重复确认阈值,发送方对于引起网络重新排序的分组将较不健壮。
作为上限与下限之间引起良性结果的一个合理值,重复确认消息阈值可设为
max(接收窗口大小-2×未确认内容大小,1)即,N=0。
图6的通信装置可配置为执行上述计算和操作。
更精确地说,在另一实施例中,通信装置包括用于如下的组件:设置重复确认阈值,使得确定丢失的数据段在数据段序列中在某个时间点之前被重传,选择所述时间点,使得指示该确定丢失的数据段(即重传的数据段)的正确接收的确认消息预期在传送序号超出该确定丢失的数据段的序号接收窗口大小的数据段之前在发送方被接收。
此外,在另一实施例中,通信装置包括基于由接收窗口大小与未确认内容大小之间的差构成的可使用窗口大小,确定重复确认阈值的组件,未确认内容大小表示尚未确认的已传送数据段数量。
此外,在另一实施例中,通信装置包括基于可使用窗口大小与未确认内容大小之间的差确定重复确认阈值的组件。
确定重复确认的组件可适用于在接收第一个重复消息前一个时刻将阈值确定为值1和通过如下计算得到的值中的较大值:
(接收窗口大小-(k×未确认内容大小))其中,k是浮动量。
用于确定重复确认的组件可适用于使用k=2。
此外,在另一实施例中,通信装置包括确定重复确认阈值为以下值的组件:
接收窗口大小-(2×未确认内容大小)+N,N构成满足以下条件的可调参数
(2×未确定内容大小)-接收窗口大小+1<N<3。
此外,在另一实施例中,通信装置包括在确定接收窗口大小变化时更新重复确认阈值的组件。
此外,在另一实施例中,通信装置包括至少在每第一次收到数据段之一的重复确认消息时更新重复确认阈值的组件。
此外,在另一实施例中,通信装置包括每次收到确认消息时更新重复确认阈值的组件。
除以上概述的基于接收窗口大小设置重复确认消息阈值外,通过表示在接收方缓冲区空间中可存储的数据段数量的接收窗口大小,也可将发送方的情况考虑在内。更精确地说,根据另一实施例,在发送方受阻而无法传送以前未发送的数据段时,重传确定丢失的数据段。这种情况下,如果满足以下条件之一,则可视为发送方受阻:以前未发送的数据段数量超过接收窗口大小;以前未发送的数据段数量超过发送窗口大小;或者构成数据段源的应用未提供用于传输的数据段。
本发明的方法可用于按任一适合或适当的方式实现,且尤其可以计算机程序的形式存在,及因此也可按承载此类计算机程序的存储媒体形式存在。同样地,本发明可以设置为根据本发明方法操作的通信装置形式存在。
虽然通过详细实施例描述了本发明,但决不可将本发明限于这些实施例;本发明范围由随附权利要求书定义。此外,权利要求书的标号不可视为限制,它们只是为了使权利要求书更易于阅读。
Claims (16)
1. 一种控制数据段序列从发送方流到接收方的方法,包括:
按所述序列的顺序将数据段从所述发送方传送到所述接收方;
从所述接收方接收确认消息,其中,确认消息指示按所述序列的正确顺序正确接收数据段;
如果数据段已被接收但不是按所述序列的正确顺序接收,在所述发送方接收来自所述接收方的重复确认消息,被接收的所述重复确认消息与按所述数据段序列的顺序最后正确接收的数据段相关联;
如果重复确认消息数量达到基于接收窗口大小确定的重复确认阈值,判定已被发送但未被确认的数据段已丢失,所述接收窗口大小对应于能够在所述接收方被存储在缓冲区空间中的数据段数量;以及
重传确定丢失的所述数据段。
2. 如权利要求1所述的方法,其中,设置所述重复确认阈值,使得确定丢失的数据段在所述数据段序列中在某个时间之前重传,其中选择所述时间点,使得指示所述确定丢失的数据段的正确接收的确认消息预期在传送序号超出所述确定丢失的数据段的序号所述接收窗口大小的数据段之前在所述发送方被接收。
3. 如权利要求1和2至少之一所述的方法,其中,基于由所述接收窗口大小与未确认内容大小之间的差构成的可使用窗口大小,确定所述重复确认阈值,所述未确认内容大小表示尚未确认的已传送数据段数量。
4. 如权利要求1到3至少之一所述的方法,其中,基于所述可使用窗口大小与所述未确认内容大小之间的差确定所述重复确认阈值。
5. 如权利要求1到4至少之一所述的方法,其中,在接收第一个重复消息前一个时刻,将所述重复确认阈值确定为以下值中的较大值:
值1与通过计算(接收窗口大小 - (k × 未确认内容大小) ) 而得到的值,
其中,k是浮动量。
6. 如权利要求5所述的方法,其中,k = 2。
7. 如权利要求1到4至少之一所述的方法,其中,所述重复确认阈值确定为
接收窗口大小 - (2 × 未确认内容大小) + N,
N构成满足以下条件的可调参数
(2 × 未确定内容大小) - 接收窗口大小 + 1 < N < 3。
8. 如权利要求1到7至少之一所述的方法,其中,在确定所述接收窗口大小变化时更新所述重复确认阈值。
9. 如权利要求1到7至少之一所述的方法,其中,至少在每第一次收到所述数据段之一的重复确认消息时更新所述重复确认阈值。
10. 如权利要求7和9所述的方法,其中,N = 5。
11. 如权利要求1到7至少之一所述的方法,其中,每次收到确认消息时更新所述重复确认阈值。
12. 如权利要求1到11至少之一所述的方法,其中,在所述发送方受阻而无法传送以前未发送的数据段时,重传确定丢失的所述数据段。
13. 如权利要求12所述的方法,其中,如果满足以下条件之一,则所述发送方可视为受阻:
以前未发送的数据段数量超过所述接收窗口所述大小;
以前未发送的数据段数量超过所述发送窗口所述大小;
构成所述数据段源的应用未提供用于传输的数据段。
14. 一种计算机程序,在计算机上执行时设置来执行如权利要求1到13至少之一所述的方法。
15. 一种存储如权利要求14所述的计算机程序的计算机可读存储器装置。
16. 一种控制数据段序列从发送方流到接收方的通信装置,包括:
用于按所述序列的顺序将数据段从所述发送方传送到所述接收方的组件;
用于从所述接收方接收确认消息的组件,其中,确认消息指示按所述序列的正确顺序正确接收数据段;
用于如果数据段已被接收但不是按所述序列的正确顺序接收则在所述发送方接收来自所述接收方的重复确认消息的组件,被接收的所述重复确认消息与按所述数据段序列的顺序最后正确接收的分组相关联;
用于如果重复确认消息数量达到基于所述接收窗口大小确定的重复确认阈值则判定已被发送但未被确认的数据段已丢失的组件,所述接收窗口大小对应于能够在所述接收方被存储在缓冲区空间中的数据段数量;以及
用于重传确定丢失的所述数据段的组件。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410552877.1A CN104301079A (zh) | 2004-12-22 | 2004-12-22 | 使用重复确认的数据流控制 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410552877.1A CN104301079A (zh) | 2004-12-22 | 2004-12-22 | 使用重复确认的数据流控制 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2004800446731A Division CN101088243A (zh) | 2004-12-22 | 2004-12-22 | 使用重复确认的数据流控制 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN104301079A true CN104301079A (zh) | 2015-01-21 |
Family
ID=52320662
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410552877.1A Pending CN104301079A (zh) | 2004-12-22 | 2004-12-22 | 使用重复确认的数据流控制 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104301079A (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107683598A (zh) * | 2015-06-03 | 2018-02-09 | 桥联有限公司 | 传输数据 |
CN108476097A (zh) * | 2016-09-18 | 2018-08-31 | 深圳市大疆创新科技有限公司 | 数据重传方法和装置 |
CN111163013A (zh) * | 2020-03-02 | 2020-05-15 | 西南交通大学 | 一种基于udp的半可靠数据传输拥塞控制方法 |
WO2024114361A1 (zh) * | 2022-12-01 | 2024-06-06 | 华为技术有限公司 | 一种数据传输方法和节点 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1214828A (zh) * | 1996-04-01 | 1999-04-21 | 艾利森公司 | 在自动重复请求系统中恢复数据的方法和设备 |
CN1283344A (zh) * | 1997-10-22 | 2001-02-07 | 艾利森电话股份有限公司 | 智能分组重发方案 |
US20030095537A1 (en) * | 2001-11-21 | 2003-05-22 | Homare Murakami | Packet communication method and proposal node |
CN1511396A (zh) * | 2001-04-04 | 2004-07-07 | ����ɭ�绰�ɷ�����˾ | 数据流控制方法 |
-
2004
- 2004-12-22 CN CN201410552877.1A patent/CN104301079A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1214828A (zh) * | 1996-04-01 | 1999-04-21 | 艾利森公司 | 在自动重复请求系统中恢复数据的方法和设备 |
CN1283344A (zh) * | 1997-10-22 | 2001-02-07 | 艾利森电话股份有限公司 | 智能分组重发方案 |
CN1511396A (zh) * | 2001-04-04 | 2004-07-07 | ����ɭ�绰�ɷ�����˾ | 数据流控制方法 |
US20030095537A1 (en) * | 2001-11-21 | 2003-05-22 | Homare Murakami | Packet communication method and proposal node |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107683598A (zh) * | 2015-06-03 | 2018-02-09 | 桥联有限公司 | 传输数据 |
CN107683598B (zh) * | 2015-06-03 | 2020-09-08 | 桥联有限公司 | 一种传输数据的方法及设备 |
CN108476097A (zh) * | 2016-09-18 | 2018-08-31 | 深圳市大疆创新科技有限公司 | 数据重传方法和装置 |
CN108476097B (zh) * | 2016-09-18 | 2021-08-03 | 深圳市大疆创新科技有限公司 | 数据重传方法和装置 |
CN111163013A (zh) * | 2020-03-02 | 2020-05-15 | 西南交通大学 | 一种基于udp的半可靠数据传输拥塞控制方法 |
CN111163013B (zh) * | 2020-03-02 | 2022-04-29 | 西南交通大学 | 一种基于udp的半可靠数据传输拥塞控制方法 |
WO2024114361A1 (zh) * | 2022-12-01 | 2024-06-06 | 华为技术有限公司 | 一种数据传输方法和节点 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101088243A (zh) | 使用重复确认的数据流控制 | |
US7032153B1 (en) | Dynamic automatic retransmission request in wireless access networks | |
EP1871031B1 (en) | Retransmission control method and device | |
US7283814B2 (en) | Method and apparatus for scheduling transmissions in wireless data networks | |
EP2109954B1 (en) | Ack prioritization in wireless networks | |
KR100976425B1 (ko) | 무선 링크 제어 재전송을 지원하기 위해 프로토콜 데이터단위의 재전송의 순위 지정을 하는 노드 b | |
KR100785293B1 (ko) | 다중 tcp확인응답을 이용한 tcp 혼잡 제어 시스템및 그 방법 | |
US7352700B2 (en) | Methods and devices for maximizing the throughput of TCP/IP data along wireless links | |
US7707303B2 (en) | Method and devices for controlling retransmissions in data streaming | |
US20080101290A1 (en) | Apparatus for Arq Controlling in Wireless Portable Internet System and Method Thereof | |
US7382732B2 (en) | Method and system for flow control for route switching | |
US20070086367A1 (en) | Down-link data transmission and receiving system and method of ARQ in wireless communication system | |
JP2007089177A (ja) | 無線通信システムにおける状態報告信号の伝送速度を改善する方法及び装置 | |
US20070058534A1 (en) | Session relay apparatus and relaying method | |
CN102694631B (zh) | 一种用于控制数据传输的方法和装置 | |
US20120106344A1 (en) | Data communication acknowledgement in a network | |
KR20190105061A (ko) | 데이터를 송신하는 방법과 데이터 송신 장치, 및 고객 댁내 장치 | |
CN104301079A (zh) | 使用重复确认的数据流控制 | |
US20060072577A1 (en) | Method for communication over a lossy interface | |
CN115348336A (zh) | 异构数据流的通用传输架构 | |
Tykhomyrov et al. | Analysis and performance evaluation of the IEEE 802.16 ARQ mechanism | |
RU2366095C2 (ru) | Управление потоком данных с дублированным подтверждением | |
GB2576204A (en) | Operation of automatic repeat request (ARQ) | |
KR20080071002A (ko) | 이동통신 시스템에서 알엘피 버퍼링 타이머 변경을 이용한전송 장치 및 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
WD01 | Invention patent application deemed withdrawn after publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20150121 |