用于网络传输丢失容限的客户端应用控制的方法和系统的制作方法

文档序号:7594436阅读:153来源:国知局
专利名称:用于网络传输丢失容限的客户端应用控制的方法和系统的制作方法
技术领域
本发明一般涉及数据处理系统网络中的数据传输,特别涉及互联网或类似网络上的数据块传输。更具体地说,本发明涉及实现由应用控制的、动态的、准可靠(quasi-reliable)的数据传输功能性,以改善诸如互联网的网络上的数据传输性能。
背景技术
互联网已成为一种用于传输和发布数据(文本、代码、图像、视频、音频或混合数据)与软件的重要渠道。用户以范围从14.4Kb/s到大于45Mb/s的广泛不同性能级别连接到骨干网。此外,传输控制协议/互联网协议(TCP/IP)已成为互联网/内部网技术中的一种广泛实现的标准通信协议,它允许客户端、服务器和耦合它们的通信系统之间的广泛异构性。互联网协议(IP)是网络层协议,而传输控制协议(TCP)是传输层协议。在网络层,IP提供“数据报”传送服务。相反,TCP在数据报服务之上构建传输层服务,用于在两个IP主机之间提供有保证的、顺序的字节流传送。
TCP流控制机制只在终端站上运行,以限制TCP端点发送数据的速率。但是,TCP缺乏显式的数据速率控制。基本流控制机制是施加于最后显式确认的字节以外的一定范围字节上的“滑动窗”。该滑动窗限制最近从服务器发送的字节到尚未从客户端接收到接收确认的最早字节之间的连续字节的最大数目。该滑动操作限制TCP端点可以发送的未确认可传输数据的数目。多种算法自动重新发送分组,并在超过滑动窗限制时缓慢地重新启动数据传输。由此,如果服务器和客户端之间的链路在传输数据集合的中间被关断,则服务器将在客户端所确认的最后分组的一个滑动窗内停止发送分组。滑动窗的使用内在地限制了通过网络的数据传输带宽。
TCP/IP是一种面向连接的可靠通信协议,它严格地强制执行可靠的数据传输,使得一个TCP帧的丢失可能阻塞该TCP流中所有后继数据的传送,直到该丢失的TCP帧被传送为止。然而,不是所有的客户端应用都需要TCP所提供的严格顺序和可靠传送,这尤其是因为该服务以一定的成本得到带宽。例如,基于视频或图像的应用不需要非常可靠的数据传送。在这些应用中,如果数据流的某些部分丢失,则视频/图像仍然可以有效地表现出来。因此,如果性能可以被总体改善,则该应用在某些情况下愿意容忍一定的数据丢失。但是,TCP由于强制执行其严格可靠性而将自动减小可用于该应用的带宽。
一种避免TCP严格可靠性要求的方法是采用不可靠的传输,例如用户数据报协议(UDP)。UDP是一种定义无连接数据报服务的协议。实现UDP的传输层过程或系统可能产生自包含的数据分组,其包括目的地路由信息。为了使用该方法,客户端应用必须在UDP传输层上面的层中实现它们自己的部分可靠性。但是,应用在UDP传输层上面的层中使用自己的部分可靠性往往使该应用非常复杂,因为它必须将自己的报头插入分组中以有序化(order)和顺序化(sequence)这些分组。
另一种方法采用诸如流控制传输协议(SCTP)的协议,该协议在同一连接内既提供可靠的数据流又提供部分可靠的数据流。但是,采用SCTP涉及更改服务器和客户端应用以适应该独特协议。这种对服务器和客户端应用的更改涉及重写整个应用,这不太经济或者不总是切实可行。
可以看到需要一种通信协议来提供准可靠的数据传输,但同时减少上述解决方案中的成本和复杂度。最好,让该协议能容易地加入到现有网络中,并根据客户端应用对数据传输的可靠性要求来动态地控制该协议。

发明内容
根据本发明,公开了用于为数据处理系统的应用管理通信链路上的数据流传输的改进型方法、系统和产品。在本发明的一种优选方法中,为多个在通信链路上接收的数据分组中的数据分组指定丢失容限,其中丢失容限是对应用来说允许未在通信链路上接收到的该多个数据分组的最大百分比;当接收到一条指示,表明数据分组未在通信链路上接收到时,判定该多个数据分组中未在通信链路上接收到的数据分组数是否已超过为该数据分组指定的丢失容限。如果该多个数据分组中未在通信链路上接收到的数据分组数没有超过为该数据分组指定的丢失容限,则发送表示该数据分组已被数据处理系统接收到的确认。如果该多个数据分组中未在通信链路上接收到的数据分组数超过为该数据分组指定的丢失容限,则发送表示该数据分组未被数据处理系统接收到的确认。
本发明的所有目的、特性和优点在以下详细描述中将会变得清楚。


图1示出了其中可以实现本发明优选实施例的数据处理系统网络。
图2是可以用于本发明的优选实施例中的万维网服务器-客户端系统的典型软件架构的图示。
图3示出采用TCP/IP的4层通信架构的例子。
图4示出包括通过路由器连接到令牌环网络的以太网网络的互联网的例子。
图5示出数据穿过TCP/IP协议栈时的数据结构。
图6示出TCP发送或重试帧和TCP确认帧的数据结构。
图7示出根据本发明一个优选实施例的用于为客户端应用设置数据传输丢失容限的过程的流程图。
图8示出根据本发明一个优选实施例的用于实现由应用控制的、动态的、准可靠的TCP功能性的过程的流程图。
图9示出客户端的存储器中的寄存器,其中存储过程变量LOSS_T和强行确认F_ACK。
图10示出将图7和图8所示的过程应用于数据流的例子。
具体实施例方式
在下面的描述中,参考其中相似的附图标记代表相同或相似单元的附图,以优选实施例描述本发明。虽然本发明以实现本发明目的的最佳模式描述,但是本领域的技术人员应当理解,在本文的启迪下,可以在不脱离本发明的精神或范围的情况下作出各种修改。
现在参考附图,并且特别参考图1,示出了一种其中可以实现本发明优选实施例的数据处理系统网络。数据处理系统网络102包括至少一个服务器系统104,其通过至少一个诸如互联网108的网络连接到至少一个客户端系统106。服务器系统104和客户端系统106之间的数据传输遵循TCP/IP规范,以及文件传输协议(FTP)、超文本传输协议(HTTP)或某类似通信协议。大型数据传输采用并行帧执行,下面将对此作进一步详细描述。应当理解,尽管只示出了单个服务器系统104和单个客户端系统106,但数据处理系统网络102可以包括任意数目的服务器和客户端系统(未示出),它们通过包括互联网108在内的一个或多个连接和网络互连。
图2示出可以用于本发明优选实施例中的万维网服务器-客户端系统的典型软件架构。服务器104和客户端106均采用软件架构200构造。在最低层,操作系统205用于向用户和其它软件提供高层功能性。该操作系统通常包括BIOS(基本输入输出系统)。通信软件210通过外部端口提供经由物理通信链路与诸如互联网的网络的通信,其方式是直接调用操作系统功能性,或间接地绕过操作系统来访问用于在网络上通信的硬件。应用编程接口215允许系统用户,不管是个人还是软件例程,利用标准相容接口调用系统功能,而无需关心特定功能性是如何实现的。万维网软件220代表若干可用于向计算机配备万维网功能性的标准商业包中的任何一个。应用软件225代表任意数目的、设计为对通过通信端口的数据作出反应以提供用户寻求的期望功能性的软件应用。这一层的应用可以包括处理可以由万维网的用户访问的数据、视频、图形、照片或文本所需的应用。在优选实施例中,(在此所定义的)数据传输“丢失容限”由运行在客户端系统中的应用软件225控制。但是,本领域的技术人员应当理解,本发明可以在客户端106中实施为固件、软件或任何硬件电路。
为了在网络上传输数据,需要具有一组规则以便正确执行传输序列的每一个部分。这些规则中的每一个称作协议,并且一组规则称作协议集。在互联网和诸如LAN(局域网)和WAN(广域网)的各种其他网络上传输数据时所用的最常用协议集由TCP/IP(传输控制协议/互联网协议)协议集提供。TCP/IP协议集允许各种不同类型的、运行不同操作系统的计算机相互通信。TCP/IP形成全球互联网即真正跨越全球的超过一百万台计算机的广域网的基础。除了TCP/IP协议集之外,还存在很多其他网络协议集,包括IPX/SPX(互联网分组交换/顺序分组交换)和NetBios。虽然最初是由独立研究组开发的,但是大部分网络协议是公开(非私有)标准,其中许多是作为一系列按照数字顺序的RFC(请求注解)论文来公布的。例如,IP协议是RFC791。RFC论文可在互联网上或者各图书馆内容易地获得。
尽管存在区别,但这些网络协议集的每一个在结构上是类似的,它们都包括一组层,其中每层负责通信任务的不同方面。为简单起见,下面讨论将主要关于采用TCP/IP协议时的本发明使用。然而,本领域的技术人员应当认识到,虽然本发明的原理是参照TCP/IP协议描述的,但是本发明也可以应用于各种其他网络。
如图3所示,TCP/IP和类似协议由4层通信架构300采用,该通信架构覆盖服务器104和客户端106内的软件架构200,并且包括应用层310、传输层312、网络层314和链路层316。每层如下负责处理不同通信任务。链路层316(也称作数据链路层或网络接口层)通常包括操作系统中的设备驱动程序和计算机中的相应网络接口卡。它们一起处理在物理上与正在使用的网络介质例如以太网电缆等进行接口交互的所有硬件细节。网络层314(也称作互联网层)处理数据分组在网络内的移动。例如,网络层处理在网络上传输的各个数据分组的路由选择。TCP/IP协议集中的网络层由若干协议构成,包括IP(互联网协议)、ICMP(互联网控制消息协议)和IGMP(互联网组管理协议)。
传输层312提供网络层314和应用层310之间的接口,其帮助两个主机之间的数据传输。在TCP/IP协议集中存在两个明显不同的传输协议TCP(传输控制协议)和UDP(用户数据报协议)。它与如下事情有关将从应用传给它的数据划分为合适大小的用于下面网络层的块、确认所接收的分组、设置超时以确定另一端确认被发送的分组等等。根据本发明,当采用TCP时,客户端中的应用层设置由传输层来满足可靠性要求。相反,UDP向应用层提供简单得多的服务。UDP仅仅从一个主机向另一个主机发送称为数据报的分组,而不提供任何用于保证数据被正确传输的机制。当采用UDP时,可靠性功能性必须由应用层执行。
应用层310处理特定应用的细节。几乎每一个实现都提供有很多常用TCP/IP应用,包括(1)用于远程登录的Telnet;(2)FTP,文件传输协议;(3)SMTP,用于电子邮件的简单邮件传输协议;以及(4)SNMP,简单网络管理协议。
计算机网络已经从包括少量计算机的简单LAN发展到包括联网计算机网络的WAN。最初的计算机网络是由在独立计算机之间提供通信链路是有利的这一认识来促成的。在这些原始网络中使用的概念推动了今天互联网的发展,该互联网包括采用同一协议集的多个网络的网络。该互联网允许一个网络上的计算机与其它网络上的任意一个或多个计算机通信,从而允许跨越组成所有网络的所有计算机来共享数据构建互联网的最简单方法是用路由器连接两个或更多网络。典型的路由器包括具有输入和输出连接以及专用硬件的专用硬件盒,和/或允许连接很多不同类型的物理网络的嵌入式软件,这些网络例如是以太网、令牌环、点对点链路等等。图4示出包括通过路由器36连接到令牌环网络34的以太网网络32的互联网。尽管图4只示出两个通信中的主机,但在以太网网络上的任何主机都可以与令牌环网络上的任何主机通信。路由器36包括网络层模块38(在本例中为IP模块),和用于连接到主机网络的适当网络驱动器,即以太网驱动器40和令牌环驱动器42。
如图4所示,在应用层,该网络包括FTP客户端420和FTP服务器422。大多数网络应用设计为一端是客户端,而另一端是服务器。该服务器向各客户端提供某种类型的服务,在本例中为访问服务器主机上的文件。每一层都具有一个或多个用于与其同一层的对等体进行通信的协议。这些通信协议包括应用层的FTP协议444、传输层的TCP协议446、网络层的IP协议448以及链路层的以太网协议450和令牌环协议454。常见的是,应用层处理用户进程,而较低三层(传输层、网络层和链路层)则在诸如UNIX或Windows的操作系统的内核中实现。例如,网络接口层的目的是处理通信介质(以太网、令牌环等等)的细节,而应用层的目的是处理一个特定的用户应用(FTP、Telnet等等)。
应用层和传输层采用端到端协议(FTP协议444、TCP协议446)。网络层提供在两端系统和其间的每一个中间系统上使用的中继段到中继段(hop-to-hop)协议(为简洁起见这里只示出了一个中间系统)。例如,路由器436的IP模块438采用IP协议448连接到两个主机。还存在特定于连接到路由器的不同类型主机网络的链路层协议,以在链路层处理网络和路由器之间的通信。因此,以太网协议450用于处理路由器436中的以太网驱动器440和以太网网络432上的主机的以太网驱动器452之间的通信,而令牌环协议454用于处理路由器436的令牌环驱动器442和令牌环网络434上的主机的令牌环驱动器456之间的通信。
在TCP/IP协议集中,网络层即IP提供不可靠的服务。网络层将数据分组从源处移动到目的地,但是它没有提供用于保证传送的机制,或者甚至没有提供用于能够判定是否已发生正确传输的机制。TCP提供可靠性服务,以确保数据在两个主机之间被正确传输,该服务包括丢失检测和重新传输服务。
路由器具有两个或更多个网络接口层(因为它连接两个或更多个网络)。任何具有多接口的系统都称为是连接多个网络的(multi-homed)。主机也可以是连接多个网络的,但除非它特定地将分组从一个接口转发到另一个接口,否则就不称为路由器。同样,路由器无需是只在互联网内移动分组的专用硬件盒。大多数TCP/IP实现都允许连接多个网络的主机充当路由器的角色,但该主机需要特定地配置为支持该用途。在这样的情况下,系统是主机(当正在使用诸如FTP或Telnet的应用时)或者路由器(当它正在将分组从一个网络转发到另一个网络时)。另一种连接网络的方式是利用桥接器。桥接器在链路层连接网络,而路由器在网络层连接网络。桥接器使得多个LAN对高层来说显得好像是单个LAN一样。
互联网的最强大特性之一是能够向应用隐藏互联网物理布局的所有细节。这允许应用层不在意网络的底层结构;事实上,应用层不能也不会关心一对网络是由单个路由器连接的,还是由连接多个物理上不同网络的多个路由器和桥接器连接的。
当应用利用TCP/IP发送数据时,该数据沿着协议栈逐层向下发送,直到它作为比特流跨越网络发送为止。如图5所示,每层都通过将报头前置于其接收的数据中(有时也添加报尾信息)将信息添加到该数据中。例如,在应用层,将应用报头580前置于用户数据582中以形成应用数据584。在传输层,将传输协议报头前置于应用数据中。在图5的情况下,传输层是TCP,因此将TCP报头586前置于应用数据584中,由此形成发送到网络层IP的TCP帧588。TCP报头586包括20个字节。类似地,在网络层,将网络层报头前置于传输层数据中。在TCP/IP的情况下,将IP报头590前置于TCP帧588中以形成IP数据报592。IP报头590也包括20个字节。最后,在链路层,将诸如以太网报头594的介质报头添加到从网络层接收的数据中以形成数据帧。在某些情况下,例如当介质是以太网时,还将介质报尾附加于数据的末尾。例如,在图5中,将以太网报尾96附加于以太网报头594和IP数据报592中以形成以太网帧598。该以太网帧包括对应于原始应用消息数据的跨越网络流动的比特流。报头底部的数字(14、20、20、4)是以字节为单位的报头典型大小,例如,以太网报头94包括14个字节等。帧的大小将由用来传输数据分组的网络类型的最大传输单元(MTU)限定。例如,以太网网络的MTU是1500个字节。网络层自动执行片段化(将数据报分裂为更小的片段),使得每个片段都小于网络的MTU。
当客户端检测到某些数据帧从数据传输流中丢失时,客户端将通过在确认帧中发送丢失帧的第一字节的顺序号来请求服务器重新传输丢失帧。如图6所示,TCP发送或重试消息610一般包括介质报头612、协议报头614、接收顺序号字段616、发送顺序号字段618和消息主体620。介质报头612将特定于网络类型,例如,以太网报头用于以太网网络等。协议报头614将取决于所采用的传输和网络层协议,例如TCP/IP、IPX/SPX、Netbios等。接收顺序号字段616提供由计算机可靠接收的最后一个顺序号的标识符。发送顺序号618对应于该消息的相对顺序号。消息主体620包含正在源计算机和目的计算机之间发送的应用数据。TCP确认帧622包括介质报头624、协议报头626、接收顺序号字段628和发送顺序号字段630。这些字段与上述共享相同名称的字段类似。确认帧622由接收计算机发送,以确认发送或重试消息的接收。根据TCP,一接收到表示丢失帧的3个连续确认帧时,服务器通常就将“快速重新传输”从丢失的顺序号开始的丢失帧。这种重新传输负面影响了性能,因为服务器缩小其滑动窗,并减少了其发送的数据量。
根据本发明,一种可动态实施的、由应用控制的、准可靠的TCP扩展允许客户端应用动态设置TCP内的数据传输可靠性级别,从而将传输层编程为乐观地确认不重要的丢失帧。该可靠性要求可以动态设置为数据传输期间数据流内的特定数据帧所需的可靠性级别。该过程避免了不必要的重新传输,并允许TCP数据流和滑动窗不中断地前进,从而相当大地提高了网络吞吐量。
参考图7,示出了根据本发明优选实施例为客户端应用设置数据传输丢失容限的过程700的流程图。过程700从步骤705开始,其中客户端106中的应用310通过调用协议栈300发起与互联网108的网络连接。在步骤710,客户端应用310为待装载到接收缓冲区中的特定数据确定数据传输可靠性要求(即由接收缓冲区长度(“len”)度量的接收者字节范围(RBR))。过程转到步骤715,其中能够利用本发明的TCP扩展的客户端应用310通过对TCP层312的网络输入/输出系统调用进行系统调用,从而为当前连接或待接收的数据帧设置百分比丢失容限。这在客户端106中实现,其中应用310通过应用程序员接口(API)215内的“接收”(“recv”)命令进行系统调用。根据本优选实施例,UNIX套接字API系统调用的BSD(Berkeley)版本中使用的“接收”系统调用的新选项(“loss_t”)被设置为当前应用310可接受的百分比丢失容限。在此所用的“丢失容限”定义为给定数据集中允许丢失但对将使用该给定数据集的应用来说仍然满足数据需要的最大数据百分比或最大数据量。百分比丢失容限的取值范围在0-100内。丢失容限值“0”相当于使用丢失数据容限为0的标准、可靠TCP,而百分比丢失容限100由于从不需要重新传输丢失分组而给予TCP类似于UDP的性能。该应用想要以给定丢失容限接收的接收缓冲区长度(“len”)或字节总长度也在“recv”调用中指定。“len”等于接收者字节范围(RBR),其是当前应用愿意以指定丢失容限(系统调用中的“loss_t”)接收的字节数。
在本优选实施例中提供的“recv”系统调用的代表性格式如下所示int recv(s,buf,len,flags,loss_t)int s;void *buf;int len,flags,loss_t;其中,s是套接字描述符buf是指向用户(应用)接收缓冲区的指针len是该接收缓冲区的长度flags是特殊标志,如MSG-00B(发送或接收带外(out-of-band)数据)MSG-PEEK等loss_t是将要用于指定应用在接收缓冲区范围内的百分比丢失容限的新参数丢失容限也以当前应用310可以容许在RBR内丢失的数据的绝对数量(LOSS_T)表示。在本优选实施例中,LOSS_T以千字节表示,并存储在可由传输层312访问的客户端106的存储器中。LOSS_T直接由应用310设置,或者由TCP层312按照下式计算LOSS_T=loss_t100*(len)]]>[字节]
在一个优选实施例中,该过程将LOSS_T计算为在15千字节RBR内等于loss_t百分比的数据字节数。
回到图7,过程700从步骤715进入确定块720,其中将LOSS_T设置为存储在如图9所示的寄存器905中的值,并在如图9所示的寄存器910中将强行确认(F_ACK)(下面描述)设置为0。然后,该过程转到判定块725,以判定自从进行“recv”系统调用以来是否已接收RBR内的所有字节。如果判定结果是肯定的,则该过程转到步骤730,其中传输层将其操作切换为常规TCP,并请求重新传输所有丢失分组,直到该应用发出新的接收系统调用为止。如果判定结果是否定的,则该过程转到步骤735,其中客户端继续以本优选实施例的丢失容限功能性运行其传输层。此后,该过程返回到步骤725,以判定自从进行“recv”系统调用以来是否已接收RBR内的所有字节。
现在参考图8,示出了根据本发明优选实施例的用于实现由应用控制的丢失容限TCP功能性的过程的流程图。根据过程700中指定的丢失容限,TCP层312在过程800中,根据在接收字节范围内是否已超过为应用310指定的丢失容限来判定是否触发重新传输或继续向应用310传送失序帧。当在服务器和客户端之间发起网络连接时,过程800从步骤805开始。
图9表示客户端106的存储器中的寄存器900,其可由传输层312访问,并存储过程变量LOSS_T和强行确认(F_ACK)(下面描述)。在步骤805,过程变量LOSS_T和F_ACK在寄存器900中设为0。此后,该过程转到步骤810,其中客户端106在网络连接上接收数据分组。然后,该过程转到判定块815,其中判定所接收的数据分组是否失序。如果该数据分组的顺序号为期望的次序,则该过程转到步骤820,其中如果需要,将确认帧622往回发送到服务器104以确认该数据分组的接收。此后,过程返回到步骤810,以等待在网络连接上接收下一个数据分组。
回到判定块815,如果判定所接收的数据分组失序,则数据流中的一个或多个进行中数据帧丢失。在这种情况下,该过程转到判定块825,其中判定在接收字节范围内导致强行确认(F_ACK)的丢失分组的数目是否已超过由客户端应用310为RBR设置的LOSS_T。这通过判定存储在寄存器910中的F_ACK是否大于或等于存储在寄存器905中的当前RBR的LOSS_T来实现。如前所述,LOSS_T是为了保持当前应用310的可靠性要求而可以接受的数据丢失量。如果该过程具有RBR中数千字节的强行确认而超过当前LOSS_T数,或者如果接收的分组超过RBR,则该过程转到步骤830,其中客户端106发送确认请求610,以重新传输丢失的数据分组,确认请求610包括客户端期望重新传输的丢失帧的第一字节的顺序号。通过阻塞TCP流中所有随后数据的传送,直到丢失的TCP帧被传输了为止,客户端106以常规TCP方式继续运行。此后,该过程返回到步骤810,以等待在网络连接上接收下一个期待数据分组。
回到判定块825,如果判定在RBR内导致强行确认的丢失分组的数目没有超过LOSS_T,则该过程转到步骤835,其中将寄存器910中的F_ACK增加丢失分组中的丢失字节数,然后该过程转到步骤840,其中客户端106强行将表示丢失分组已被客户端106接收的确认帧622(“强行确认”)发送到服务器。由此,即使客户端应用310没有接收到丢失的数据帧,数据流也可以继续不中断地流动,因为应用310已接收了RBR中的足够数据来满足当前应用的可靠性要求。从步骤835出发,该过程返回到步骤810,其中客户端106等待在网络连接上接收其顺序号在导致强行确认的丢失分组之后的数据分组。
现在可以理解,对于可以容许一定数量丢失数据的应用,网络客户端可以指定在当前应用中可以接受的数据丢失容限,以提供准可靠的TCP功能性。例如,如果应用310将loss_t设置为百分之十,则TCP层312将确认(即强行确认)给定15千字节(Kbyte)RBR中最大可达1500字节,即使没有接收到这些字节。超过该RBR内的指定loss_t百分比的任何丢失字节将不被乐观地确认为已接收,并且将需要服务器重新传输这些丢失帧。百分之百的loss_t将从不触发从服务器重新传输,由此使TCP容许在网络上丢失任意数量的分组。百分之零的loss_t将要求TCP以其严格可靠的操作模式运行,从而提供严格可靠的数据传输,其中每个连续TCP帧都必须被连续传送。
图10是将过程700和800应用于数据流的例子。图10示出11个分组的数据流,这些分组具有识别它们的顺序号1到13。如点1005所示,应用发出系统调用“recv(6,buf,15000,flag,10)”。由此,loss_t设置为10%,并且len设置为15千字节。如图所示,滑动窗1010等于6个分组。分组1、2和3已经被TCP层确认。由于RBR是15千字节,而每个数据分组是1500字节,因此该系统调用所设置的10%丢失容限将在数据分组1-10的字节范围内保持有效。对于数据分组11及后面的分组,系统将以正常、可靠的TCP运行,直到该应用通过新的接收系统调用来指定新的丢失容限为止。可以理解,如果RBR内10个分组中的一个分组(即10%丢失容限)在发送者和接收者之间的传输中丢失,则接收者将强行确认对该数据分组的接收。在图10的例子中,如果接收窗1010(即分组4-9)内的分组之一没有按顺序到达,则客户端还是将强行确认对该分组的接收。然后,寄存器910增加1500,这将等于设置在寄存器905中的1500字节的丢失容限(根据系统调用的10%丢失容限)。此后,如果在第一次强行确认之后段4-10中的另一个没有到达客户端,则TCP层将不强行确认丢失分组,而是将发送请求重新传输该丢失分组的确认。
本领域的技术人员应当理解,本发明提供了改善数据发送的显著优点。该过程成功地防止了由于为给定应用强制执行的不必要可靠性要求而导致的通信延迟。此外,该过程防止了网络中的拥塞并避免重新传输,从而当应用可以容忍给定百分比的不可靠数据或丢失已发送数据时,允许数据流继续。此外,可以看到该过程是在客户端实现的,从而防止了对服务器端系统进行重大和高成本的更改。相反,对客户端端应用的最小修改都可以程序化,以动态确定给定客户端应用何时将简单地通过在接收系统调用中设置选项来利用丢失容限特性。利用标准TCP,不知道本发明的丢失容限特性的服务器端系统和客户端应用可以无缝地与应用本发明的客户端系统一起运行。此外,优选实施例的丢失容限特性可以由应用动态控制,从而特定应用、或特定数据传输的选择部分可以利用本发明的丢失容限特性。
尽管本发明是参照其优选实施例来具体描述的,但本领域的技术人员应当理解,在不脱离本发明的精神和范围的情况下,可以对其进行形式和细节的各种修改。例如,本发明可以利用计算机程序软件、固件或硬件的任意组合来实现。作为实施本发明或构造根据本发明的设备的预备步骤,根据本发明的计算机程序代码(无论是软件或固件)一般将存储在一个或多个机器可读存储介质例如固定(硬盘)驱动器、软盘、光盘、磁带、诸如ROM、PROM的半导体存储器等等中,从而产生根据本发明的产品。该包含计算机程序代码的产品通过直接从存储装置执行代码,通过将代码从存储装置复制到诸如硬盘、RAM等的另一个存储装置中,或者通过传输该代码以进行远程执行来使用。本发明的方法形式可以通过组合一个或多个包含本发明代码的机器可读存储装置与用来执行包含在其中的代码的适当标准计算机硬件来实施。用于实施本发明的设备可以是一个或多个包含或具有对根据本发明编码的计算机程序的网络访问的计算机和存储系统。
权利要求
1.一种数据处理系统中用于为该数据处理系统的应用管理通信链路上的数据流传输的方法,所述方法包括以下步骤为多个在该通信链路上接收的数据分组中的数据分组指定丢失容限,其中丢失容限是对应用来说允许未在通信链路上接收到的所述多个数据分组的最大百分比;接收表示未在通信链路上接收到数据分组的指示;判定所述多个数据分组中未在通信链路上接收到的数据分组数是否已超过为该数据分组指定的丢失容限;以及如果所述多个数据分组中未在通信链路上接收到的数据分组数没有超过为该数据分组指定的丢失容限,则发送表示该数据分组已被数据处理系统接收到的确认。
2.如权利要求1所述的方法,还包括以下步骤,如果所述多个数据分组中未在通信链路上接收到的数据分组数超过为该数据分组指定的丢失容限,则发送表示该数据分组未被数据处理系统接收到的确认。
3.如权利要求1所述的方法,其中,所述多个数据分组包括接收缓冲区的长度。
4.如权利要求1所述的方法,其中,所述指示是所接收的数据分组没有在顺序上接着前面已接收的数据分组。
5.如权利要求1所述的方法,其中,所述指定步骤包括向数据处理系统的传输层进行系统调用。
6.如权利要求1所述的方法,其中,接收数据分组和发送确认都遵循TCP。
7.如权利要求1所述的方法,其中,所述数据流由服务器发送,并且所述确认从客户端发送到该服务器。
8.一种为其应用管理通信链路上的数据流传输的数据处理系统,所述系统包括用于为多个在该通信链路上接收的数据分组中的数据分组指定丢失容限的装置,其中丢失容限是对应用来说允许未在通信链路上接收到的所述多个数据分组的最大百分比;用于接收表示未在通信链路上接收到数据分组的指示的装置;用于判定所述多个数据分组中未在通信链路上接收到的数据分组数是否已超过为该数据分组指定的丢失容限的装置;以及用于如果所述多个数据分组中未在通信链路上接收到的数据分组数没有超过为该数据分组指定的丢失容限,则发送表示该数据分组已被数据处理系统接收到的确认的装置。
9.如权利要求8所述的数据处理系统,还包括用于如果所述多个数据分组中未在通信链路上接收到的数据分组数超过为该数据分组指定的丢失容限,则发送表示该数据分组未被数据处理系统接收到的确认的装置。
10.如权利要求8所述的数据处理系统,其中,所述多个数据分组包括数据流接收缓冲区的长度。
11.如权利要求8所述的数据处理系统,其中,所述指示是所接收的数据分组没有在顺序上接着前面已接收的数据分组。
12.如权利要求8所述的数据处理系统,其中,所述指定步骤包括向数据处理系统的传输层进行系统调用。
13.如权利要求8所述的数据处理系统,其中,接收数据分组和发送确认都遵循TCP。
14.如权利要求8所述的数据处理系统,其中,所述数据流由服务器发送,并且所述确认从容户端发送到该服务器。
15.一种包括机器可读介质的产品,该介质包含嵌入在其中的程序逻辑,该程序逻辑使得用于为其应用管理通信链路上的数据流传输的数据处理系统中的控制电路执行以下步骤为多个在该通信链路上接收的数据分组中的数据分组指定丢失容限,其中丢失容限是对应用来说允许未在通信链路上接收到的所述多个数据分组的最大百分比;接收表示未在通信链路上接收到数据分组的指示;判定所述多个数据分组中未在通信链路上接收到的数据分组数是否已超过为该数据分组指定的丢失容限;以及如果所述多个数据分组中未在通信链路上接收到的数据分组数没有超过为该数据分组指定的丢失容限,则发送表示该数据分组已被数据处理系统接收到的确认。
16.如权利要求15所述的产品,还包括以下步骤,如果所述多个数据分组中未在通信链路上接收到的数据分组数超过为该数据分组指定的丢失容限,则发送表示该数据分组未被数据处理系统接收到的确认。
17.如权利要求15所述的产品,其中,所述多个数据分组包括接收缓冲区的长度。
18.如权利要求15所述的产品,其中,所述指示是所接收的数据分组没有在顺序上接着前面已接收的数据分组。
19.如权利要求15所述的产品,其中,所述指定步骤包括向数据处理系统的传输层进行系统调用。
20.如权利要求15所述的产品,其中,接收数据分组和发送确认都遵循TCP。
21.如权利要求15所述的产品,其中,所述数据流由服务器发送,并且所述确认从容户端发送到该服务器。
22.一种为其应用管理从服务器在通信链路上的数据流传输的客户端数据处理系统,所述系统包括传输层,允许该应用为在该通信链路上接收的数据流的数据分组指定丢失容限,其中丢失容限是对应用来说允许未在通信链路上接收到的接收缓冲区长度的最大百分比,其中如果未在通信链路上接收到该数据分组,并且如果该接收缓冲区长度内未在通信链路上接收到的数据分组数没有超过为该数据分组指定的丢失容限,则该传输层向服务器发送表示该数据分组已被客户端数据处理系统接收到的确认。
23.如权利要求22所述的数据处理系统,其中,如果该接收缓冲区长度内未在通信链路上接收到的数据分组数超过为该数据分组指定的丢失容限,则该传输层向服务器发送请求向所述客户端数据处理系统重新传输该数据分组的确认。
24.如权利要求22所述的数据处理系统,其中,所述应用通过向传输层进行系统调用来向传输层指定所述丢失容限。
25.如权利要求22所述的数据处理系统,其中,所述传输层遵循TCP。
全文摘要
一种可动态实施的、由应用控制的、准可靠的TCP扩展允许客户端应用通过对TCP的网络输入/输出系统调用来为数据传输可靠性动态设置百分比丢失容限,从而将传输层编程为乐观地确认不重要的丢失帧。该可靠性要求可以在TCP内动态设置为数据传输期间数据流内的特定数据帧所需的可靠性级别。根据该指定的丢失容限,TCP层判定是触发重新传输还是继续传送失序帧到应用。为每个丢失分组发送强行确认帧,直到在当前接收缓冲帧内导致强行确认的丢失分组的数目超过该丢失容限为止。该过程避免了不必要的重新传输,并允许TCP数据流和滑动窗不中断地前进,从而相当大地提高了网络吞吐量。
文档编号H04L29/06GK1581761SQ20041005663
公开日2005年2月16日 申请日期2004年8月13日 优先权日2003年8月14日
发明者德威普·N·巴纳尔吉, 卡维萨·V·M·巴拉塔克, 凯坦·P·潘乔利, 文卡特·文卡特萨布拉 申请人:国际商业机器公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1