用于自动调节从发送器通过并行连接到接收器的大量数据传送的机制的制作方法

专利名称：用于自动调节从发送器通过并行连接到接收器的大量数据传送的机制的制作方法
技术领域：
本公开内容大体上涉及从发送器通过网络到接收器的数据传送，更具体地，涉及使用并行数据协议从发送器通过网络到接收器的大量数据传送。
背景技术：
当在发送器-接收器系统中传送数据时，并行数据协议可被用于发送器-接收器系统中的大量数据传送，在所述发送器-接收器系统中，发送器和接收器通过一个或多个网络进行通信。发送器-接收器系统的例子包括客户端-服务器系统和对等系统。在这样的发送器-接收器系统中，以前考虑在发送器与接收器之间打开多个并行连接(诸如多个TCP连接)。打开多个连接的目的是聚合网络的可用带宽。更准确地讲，发送器与接收器之间的单个连接可能不能使用给定网络中的所有可用带宽。通过打开多个并行连接，可实现任何一个特定网络中的带宽的最大利用。

发明内容
带宽聚合的一个问题是，使得可供使用的带宽的量可以如此大以至于它超出接收器存储数据的能力或者发送器检索用于发送的数据的能力。在这样的数据传送中，从发送器到接收器的数据传送的瓶颈可能不是由可用网络带宽的缺乏而引起的。具体地讲，在存在多余的可用带宽的情况下，数据传送的瓶颈实际上是读取数据和将数据写入到盘时所涉及的物理I/o。如果I/O存储系统的带宽是瓶颈，则通过使用多个并行连接来聚合带宽的系统将独占比它们能够使用的网络套接字多的可用网络套接字。这样的布置对于通过相同的通信网络操作的其他发送器-接收器系统是不公平的。在本公开内容中，通过下述方式来解决前述问题，即，基于I/O存储系统的性能来自动调节(autotune)发送器和通过网络与该发送器连接的接收器之间的连接的数量。通过打开和/或关闭连接自动调节连接的数量以便建立两个系统之间的最佳数量的连接。自动调节可具体地通过下述方式发生:当接收器检测到大量数据传送的瓶颈存在于接收器的I/O存储系统中时，关闭现存连接，并且当接收器的I/O存储系统写数据比从网络接收数据快时，打开新连接。而且，通过下述方式来自动调节发送器与接收器之间的连接的数量:当发送器的I/O存储系统读数据比通过网络送出数据快时，打开新连接，并且当发送器的I/O存储系统读数据比通过网络送出数据慢并且多于一个的发送器正将数据发送到接收器时，关闭现存连接。因此，在这里描述的示例性实施例中，通过网络在发送器与接收器之间建立多个连接。所述多个连接可以是，例如，多个TCP连接。然后通过在所述多个连接上划分地发送数据来将数据从发送器发送到接收器，以便聚合网络的带宽的利用。通过下述方式来自动调节发送器与接收器之间的连接的最佳数量:当接收器检测到大量数据传送的瓶颈存在于接收器的I/O存储系统中时，关闭现存连接。就这一点而言，现存连接的关闭是次要连接而非主要连接的关闭。通过下述方式来进一步自动调节连接的数量:当接收器的I/o存储系统写数据比从网络接收数据快时，打开新连接。另外，通过下述方式来自动调节发送器与接收器之间的连接的数量:当发送器的I/o存储系统读数据比通过网络送出数据快时，打开新连接。通过下述方式来进一步自动调节连接的数量:当发送器的I/o存储系统读数据比通过网络送出数据慢并且多于一个的发送器正将数据发送到接收器时，关闭现存连接。借助于前述布置，通常可提供自校准，在所述自校准中，发送器和接收器动态地增加和减少连接的数量，以便通过提供理想的吞吐量来改进大量数据传送的性能。另外，在大量的发送器-接收器布置之间保持公平性。例如，如果当前瓶颈是接收器的系统1/0，使得当前数量的并行连接聚合了多余的网络带宽，则可关闭这些连接中的一些，以便释放带宽以供其他发送器-接收器系统使用。在这里还描述的示例性实施例中，接收器的I/O存储系统包括盘。在这个示例性实施例中，当自动调节连接的数量时，当在接收器的I/o存储系统上执行盘的查找操作时，肯定地检测到大量数据传送的瓶颈在接收器的I/o存储系统中。更具体地讲，因为多个连接正被使用，所以数据可能不能按顺序到达接收器。如果接收器超时等待下一连续数据块，则接收器的I/o存储系统可对乱序数据进行盘写入，这可能要求附加的查找操作。这通常意味着，将数据从发送器传送到接收器比接收器的I/o存储系统将数据写到盘快。因此，瓶颈可能存在于接收器的i/o存储系统中。在这里描述的另一示例性实施例中，接收器的I/O存储系统包括盘。在这个另一示例性实施例中，当自动调节连接的数量时，当接收器的I/o存储系统将数据写到盘比先前的I/o写速率慢时，肯定地检测到大量数据传送的瓶颈在接收器的I/O存储系统中。所述先前的I/o写速率可以基于先前对多于一次写操作测量的I/O写速率，或者可以基于先前对一时间段的写操作测量的I/o写速率，或者可以基于先前对写操作测量的I/O写速率的加权平均值。例如，如果接收器的I/o存储系统的先前的I/O写速率为lOMb/s，并且接收器的I/o存储系统当前正以5Mb/s写数据，则瓶颈可能存在于接收器的I/O存储系统中。当例如I/O存储系统正在处理其他非MDT应用时，可能发生接收器的I/O存储系统写速率变慢。在这里描述的另一示例性实施例中，连接数量的自动调节还包括:在发送器检测到大量数据传送的瓶颈存在于网络中的情况下，发送器关闭发送器与接收器之间的现存连接。结果，可减少网络的进一步拥塞。在这个示例性实施例中，在当前的往返时间(RTT)比先前的RTT长时，肯定地检测到大量数据传送的瓶颈在网络中。当前的RTT和先前的RTT可以基于多于一个消息包的RTT，或者可以基于RTT的加权平均值。如果当前的RTT大大地长于先前的RTT，则网络可能忙并且具有来自其他发送器-接收器系统的更多流量。通过在网络忙时关闭现存连接，可减少由通过繁忙网络发送更多数据而引起的任何进一步拥塞。在这里描述的再一示例性实施例中，连接数量的自动调节还包括:在发送器检测到大量数据传送的瓶颈存在于发送器的I/o存储系统中的情况下，关闭发送器与接收器之间的现存连接。当发送器处的缓冲区基本上空时，肯定地检测到大量数据传送的瓶颈在发送器的I/o存储系统中。在这里描述的又一示例性实施例中，在发送器检测到发送器处的缓冲区基本上满的情况下，发送器将用于打开新连接的请求发送到接收器，或者利用已经被创建的但是当前未被用于发送数据的连接。因为可减少从发送器发送数据时的延迟或间隙，所以当发送器处的缓冲区基本上满时打开新连接具有提供平稳的总数据传送的有益效果。在一些情况下，可根据网络中的瓶颈的检测或者根据接收器的I/o存储系统中的瓶颈的检测来调整发送器和接收器处的缓冲区大小。具体地讲，在这个示例性实施例中，可增大发送器处的缓冲区的大小，以可能防止缓冲区溢出数据。根据这里描述的另一示例性实施例，存在多个发送器，每个发送器将多个大量数据传送中的相应一个大量数据传送发送到接收器。在这个示例性实施例中，当通过网络建立发送器与接收器之间的多个连接时，接收器基于其他发送器请求的连接的数量来设置发送器与接收器之间可建立的连接的最多数量。例如，如果接收器具有所有发送器可共享的最多20个连接，并且其他发送器当前正利用这20个连接中的15个连接，则接收器可基于其他发送器正使用的15个连接来设置在其上发送器可用于传送数据的最多5个连接。并且，在这个示例性实施例中，接收器基于其他发送器请求的连接的数量来设置在其内可建立最多数量连接的时间段。另外，接收器基于其他发送器请求的连接的数量来设置用于建立可被建立的最多数量的连接中的每个连接的起始时间。例如，如果接收器设置最多3个连接，则在主要连接被建立之后的I分钟可建立第一次要连接，并且第一次要连接可持续4分钟，并且在主要连接被建立之后的2分钟可建立第二次要连接，并且第二次要连接可持续2分钟。在这里描述的另一示例性实施例中，作业队列由调度管理器维护，与传入的被请求连接的数量相对比，所述调度管理器管理所有的多个发送器之间存在的当前连接的数量。另外，调度管理器将优先级分配给所述多个发送器中的每一个。就这一点而言，与将较少数量的连接分配给较低优先级的发送器相对比，调度管理器将较多数量的连接分配给较高优先级的发送器。根据这里描述的另一示例性实施例，当发送器的I/O存储系统读数据比通过网络送出数据快时，发送器将用于打开一个或多个连接的请求发送到接收器。当自动调节连接的数量时，如果被请求的一个或多个连接被调度管理器确定为可用，则接收器打开所述一个或多个连接。根据这里描述的再一示例性实施例，在当前的往返时间(RTT)从先前的RTT大大地缩短时，发送器将用于打开一个或多个连接的请求发送到接收器。当前的RTT和先前的RTT可以基于多于一个消息包的RTT，或者可以基于RTT的加权平均值。当自动调节连接的数量时，如果被请求的一个或多个连接被调度管理器确定为可用，则接收器打开所述一个或多个连接。提供这个简要的发明内容，以使得本公开内容的本质可被快速地理解。可通过参照以下具体实施方式
和附图来获得更完整的理解。


图1是通过在其上可实现示例性实施例的架构的网络连接的多个发送器和接收器的代表性示图。图2是用于解释图1的发送器的内部架构的详细框图。
图3是用于解释图1的接收器的内部架构的详细框图。图4A是用于解释根据示例性实施例的发送器与接收器之间的主要连接的建立的发送器和接收器的示图。图4B是用于解释根据示例性实施例的发送器与接收器之间的次要连接的建立的发送器和接收器的示图。图5是用于提供根据示例性实施例的接收器向发送器通知增加或减少会话中的连接数量的解释的顺序图。图6是用于提供根据示例性实施例的将数据从发送器发送到接收器的大体解释的发送器和接收器的另一视图。图7是根据示例性实施例的针对传输发送器的类图。图8是根据示例性实施例的针对传输接收器的类图。图9是根据示例性实施例的针对服务器分配器的类图。图10是根据示例性实施例的针对数据源的类图。图11是根据示例性实施例的针对客户端交互的类图。图12是根据示例性实施例的针对服务器交互的类图。图13A和图13B是“put”情况下的客户端一方的顺序图。图14A和图14B是“put”情况下的提供者一方的顺序图。图15是“get”情况下的客户端一方的顺序图。图16是“get”情况下的提供者一方的顺序图。图17是客户端一方用于取消“get”操作的顺序图。图18是提供者一方用于取消“get”操作的顺序图。图19是客户端一方用于取消“put”操作的顺序图。图20是提供者一方用于取消“put”操作的顺序图。图21是图1的接收器的I/O存储系统中的写操作的代表性示图。图22是如图21所示的DataWriteQueue2101的代表性示图。图23是图1的接收器的I/O存储系统中的写操作的另一代表性示图。图24A是用于在图1中的发送器101的I/O存储系统中检测数据传送中的瓶颈的顺序图。图24B是图1中的发送器101的I/O存储系统中的读操作的代表性示图。图25是根据示例性实施例的针对服务器的类图。图26是根据示例性实施例的针对客户端的类图。图27是根据示例性实施例的针对数据串化器的类图。图28是根据示例性实施例的针对数据解串器的类图。图29是用于在客户端建立会话的顺序图。图30是用于提供根据示例性实施例的用于在发送器建立开始会话的描述的流程图。图31是用于提供根据示例性实施例的用于在发送器建立加入会话的描述的流程图。图32是用于在服务器建立会话的顺序图。
图33是用于提供根据示例性实施例的用于在接收器建立会话的描述的流程图。图34是用于客户端处的数据交换的顺序图。图35和图36是用于提供发送器处的数据交换的描述的流程图。图37是用于服务器处的数据交换的顺序图。图38和图39是用于提供接收器处的数据交换的描述的流程图。图40是用于提供另一示例性实施例的详细解释的流程图。
具体实施例方式图1是通过在其上可实现示例性实施例的架构的网络连接的多个发送器与接收器的代表性示图。如图1所示，发送器101、131和132通过网络120与接收器102连接。更具体地讲，发送器101通过网络接口 111与网络120连接，发送器131通过网络接口 112与网络120连接，发送器132通过网络接口 113与网络120连接，接收器102通过网络接口114与网络120连接。在图1中，发送器101、131和132被示出为通过一个网络连接；然而，在其他示例性实施例中，发送器101、131和132以及接收器102可通过多于一个的网络连接。另外，可存在与网络120连接或者与多个网络连接的多于或少于三个的发送器以及多于一个的接收器。网络120是内联网，但是在其他7]^例性实施例中，网络120可以是互联网或者任何其他合适类型的用于传送数据的网络。发送器101、131和132是能够通过网络发送大量数据传送的装置。然而，发送器101、131和132不限于发送数据，还可以是能够接收被传送数据的装置。发送器101、131和132可以是例如计算机或者能够通过网络`发送大量数据传送的任何其他装置。另外，发送器101、131和132可以是客户端-服务器系统中的客户端装置，或者可以是对等系统中的
对等装置。接收器102是能够通过网络接收和发送大量数据传送的装置。接收器102可以是例如计算机或者能够通过网络接收和发送大量数据传送的任何其他装置。另外，接收器102可以是客户端-服务器系统中的服务器装置，或者可以是对等系统中的对等装置。网络接口 111至114可以是有线或无线物理接口。网络接口 111至114中的每一个包括一个或多个端口，以便与网络120建立一个或多个套接字连接。图2是用于解释图1的发送器101、131和132中的每一个的内部架构的详细框图。如图2所示，发送器101、131和132中的每一个可包括与计算机总线200接口连接的中央处理单元(CPU) 202。还与计算机总线200接口连接的是硬盘(或固定盘)220、网络接口 111、112或113、用作主要的运行时暂存器的随机存取存储器(RAM)208、以及只读存储器(ROM)210。RAM208与计算机总线200接口连接，以便在执行软件程序(诸如操作系统、应用程序和接口驱动程序)中的指令期间将存储在RAM208中的信息提供给CPU202。更具体地讲，CPU202首先将计算机可执行处理步骤从固定盘220或另一存储装置加载到RAM208的区域中。CPU202然后可从RAM208执行被存储的处理步骤，以便执行加载的计算机可执行处理步骤。另外，诸如收集的网络性能统计数据或其他信息之类的数据可被存储在RAM208中，以使得该数据可在计算机可执行软件程序的执行期间被CPU202访问，达到这样的软件程序需要访问和/或修改该数据的程度。如图2中还示出的，硬盘220包含操作系统228、应用程序230 (诸如用于启动和关闭发送器101、131或132的程序)或其他程序。硬盘220还包含用于与网络(诸如网络120)的软件接口的网络驱动程序232。硬盘220还包含用于控制从发送器发送数据的流传输(streaming)软件234。最后，硬盘220包含用于控制发送器101与接收器102之间的连接的数量的自动调节软件236，其将结合图40被更详细地描述。在示例性实施例中，流传输软件234和自动调节软件236被CPU202加载到RAM208的区域中。CPU202然后从RAM208执行被存储的流传输软件234和自动调节软件236，以便执行加载的计算机可执行步骤。另外，应用程序230被CPU202加载到RAM208的区域中。CPU202然后执行以下结合图40详细描述的被存储的处理步骤，以便执行加载的计算机可执行步骤。图3是用于解释图1的接收器102的内部架构的详细框图。如图3所示，接收器102包括与计算机总线300接口连接的中央处理单元(CPU)302。还与计算机总线300接口连接的是硬盘(或固定盘)320、网络接口 114、用作主要的运行时暂存器的随机存取存储器(RAM) 308、以及只读存储器(ROM) 310。RAM308与计算机总线300接口连接，以便在执行软件程序(诸如操作系统、应用程序和接口驱动程序)中的指令期间将存储在RAM308中的信息提供给CPU302。更具体地讲，CPU302首先将计算机可执行处理步骤从固定盘320或另一存储装置加载到RAM308的区域中。CPU302然后可从RAM308执行被存储的处理步骤，以便执行加载的计算机可执行处理步骤。另外，诸如收集的网络性能统计数据或其他信息之类的数据可被存储在RAM308中，以使得该数据可在计算机可执行软件程序的执行期间被CPU302访问，达到这样的软件程序需要访问和/或修改该数据的程度。如图3中还示出的，硬盘320包含操作系统328、应用程序330(诸如用于启动和关闭接收器102的程序)或其他程序。硬盘320还包含用于与网络(诸如网络120)的软件接口的网络驱动程序332。硬盘320还包含用于控制接收器102接收数据的流传输软件334。另外，硬盘320包含用于对于发送器101与接收器102之间的连接调度不同参数的调度管理器338，其将结合图40被更详细地描述。最后，硬盘320包含用于控制发送器101与接收器102之间的连接的数量的自动调节软件336，其也将结合图40被更详细地描述。调度管理器338可起到很多作用。例如，调度管理器338可起到保持跟踪被分配给各个数据传送作业/会话的优先级的作用。另外，调度管理器338可起到管理数据传送会话可打开的连接的数量的作用。具体地讲，调度管理器338维护作业队列，以针对给定的数据传送保持跟踪发送器与接收器之间的连接的当前数量。此外，调度管理器338可起到限定给定数量的连接可在发送器与接收器之间被打开的起始时间的作用。最后，调度管理器338可起到下述作用:限定在其内给定数量的连接可被启动和保持打开的时间段或持续时间，并且在该时间段过去之后终止连接。这些作用将在下面结合图40被更详细地描述。当起到前述作用时，调度管理器338使用某些准则(例如，用户定义的优先级和系统负载定义的优先级)来在每个作用内作出某些决定。用户定义的优先级的一个例子是向高支付客户的数据传送给予高于低支付客户的优先次序。系统负载定义的优先级的一些例子包括:保持系统具有足够的负载而不打断所有的数据传送、带宽和系统资源的有效利用以使得不存在利用不足、公平负载平衡方案(如果用户想使用该方案来进行数据传送)；以及与短期数据传送相比优先执行长期数据传送，或者将更多连接给予短期数据传送，以使得它们首先执行它们的传送并退出而无需等待长期数据传送完成。为了便利于调度管理器338起到前述作用，使得以下信息可供调度管理器338使用:给定发送器与接收器之间的可用带宽，给定数据传送作业的数据大小，被分配给不同发送器的优先级，以及来自自动调节软件336的与基于以下方面的性能的可允许连接数量有关的推荐:当前CPU负荷、当前内存负荷、盘上的当前负荷或者数据传送的任何盘相关瓶颈、以及网络上的当前负荷或者数据传送的任何网络相关瓶颈。在示例性实施例中，流传输软件334、自动调节软件336和调度管理器338被CPU302加载到RAM308的区域中。CPU302然后从RAM308执行流传输软件334、自动调节软件336和调度管理器338的被存储的处理步骤，以便执行加载的计算机可执行步骤。另外，应用程序330的处理步骤被CPU302加载到RAM308的区域中。CPU302然后执行如以下结合图40详细描述的被存储的处理步骤，以便执行加载的计算机可执行步骤。图4A是用于解释根据示例性实施例的发送器与接收器之间的主要连接的建立的发送器和接收器的示图。通常，提供并行数据协议(PDP)，所述PDP通过多个套接字利用多个传输控制协议(TCP)连接来在发送器101与接收器102之间发送和接收数据。然而，可利用用于多流数据传输的其他多连接系统(即，通过任何面向连接的协议的任何逻辑连接端点)，只要接收器在数据被写到存储系统中之前将数据收集到内存缓冲区中即可，其将在下面结合图6被更详细地描述。在图4A中，仅示出了发送器101 ;然而，在其他示例性实施例中，多于一个的发送器(诸如发送器131和132)可与接收器102形成连接。在图4A中，所实现的示例性PDP是专有的、轻量级的基于二值请求/响应的协议，该协议使得可通过多个流(比如，TCP连接)来发送和接收数据。在实际的数据传送可发生之前，发送器101首先将请求消息发送到接收器102(401)。请求消息包括向接收器102注册的被请求URI (路径)。当接收器102接收到有效的请求消息时，接收器102用响应消息进行回复，所述响应消息包括接收器102分配的、可供发送器101用于打开数据传送连接的唯一会话id(402)。前述步骤401和402在接收器102启动第一套接字以建立用于传送数据的会话。在接收器102发送的响应消息中，接收器102包括发送器101被允许加入被建立会话的多个连接。如果发送器101尝试加入多于所提供的多个连接，则接收器102可拒绝额外的加入请求。另外，响应消息可包括被建立会话的生命周期的长度。在所包括的生命周期到期之后，发送器101停止并终止所述会话。如果接收器102忙，则接收器102将尝试再次创建会话之前的等待时间段返回给发送器101。发送器101然后基于接收器102给予的时间来发送随后的创建会话请求。如果发送器101在规定的时间段到期之前发送随后的创建会话请求，则接收器102将拒绝用于创建会话的请求。—旦会话被创建，接着数据就可从发送器101被发送到接收器102 (403)，并且数据就可从接收器102被发送到发送器101 (404)。在发送器101与接收器102之间发送的数据包括数据头id和将被发送的若干个数据部分。图4B是用于解释根据示例性实施例的发送器与接收器之间的次要连接的建立的发送器和接收器的示图。在图4B中，在给定的被建立的会话期间，如以上在图4A中所描述的，发送器101可通过下述方式加入现存的数据传送会话:发送用于打开与接收器102的新连接的加入请求，并提供有效的会话id (405)。如果发送器101提供有效的会话id，则接收器102返回包括加入会话id的响应消息(406)。另外，响应消息可包括状态变化，所述状态变化包括当前会话的维持时间(time-alive)和加入会话的更新列表。一旦加入会话被创建，数据就可从发送器101被发送到接收器102 (407)，并且数据就可从接收器102被发送到发送器101 (408)。在发送器101与接收器102之间发送的数据包括数据头id和将被发送的若干个数据部分。在一些情况下，在图4B的步骤406中，接收器102可发送拒绝来自发送器101的加入请求的响应消息。接收器102可拒绝加入请求，例如因为该请求超过了图4A中接收器所提供的允许的连接数量。在这些情况下，响应消息包括当前会话所允许的连接数量。另夕卜，响应消息可包括发送器101在再次试图加入会话之前应该等待的时间段(比如，秒数)。就这一点而言，发送器101可在接收器102提供的该秒数过去之后启动新的加入请求。图5是用于提供根据示例性实施例的接收器向发送器通知增加或减少会话中的连接数量的解释的顺序图。在图5中，发送器101将偏移为1、长度为I的数据部分发送到接收器102 (501)。发送器101然后将偏移为2、长度为2的数据部分发送到接收器102(502)，并继续发送具有后续的偏移和长度的数据部分(503)。接收器102然后确定发送器101是否可启动更多的加入会话，并将与偏移和长度一起接收的数据部分的应答与新加入会话的数量和会话id—起发送到发送器101(504)。所述应答还可包括启动新的加入会话之前要等待的时间段。发送器101然后发送具有会话id的加入请求(505)，并且一旦会话被创建，发送器101就通过新创建的加入会话来发送包括偏移和长度的另一数据部分(506)。在一些情况下，接收器102可确定关闭一个或多个现存连接。在这些情况下，接收器发送接收器102已关闭一个或多个连接的应答。当发送器101接收到一个或多个连接已被接收器102关闭的应答时，发送器101通过重新分配在剩余的打开连接上发送的数据来对所述应答作出反应。图6是用于提供根据示例性实施例的将数据从发送器发送到接收器的大体解释的发送器和接收器的另一示图。在图6中，发送器101包括I/O存储系统，所述I/O存储系统包括存储介质601 (诸如存储数据的盘)、数据缓冲区读取器602 (包括数据缓冲区621)、以及用于发送数据的数据blob串化器603。发送器101通过连接604a和605a、通过连接604b和605b、以及通过连接604c和605c与接收器102连接。接收器102包括I/O存储系统，所述I/O存储系统包括存储介质609 (诸如盘)、数据blob解串器608 (包括数据缓冲区622)、以及用于接收发送的数据的数据blob解串器文件607。在图6中，通过使用单独的线程来异步地完成源数据的实际读取，所述单独的线程与将由发送器101发送的数据一起填充在存储介质601中。数据被数据缓冲区读取器602从存储介质601读取，并被存储在数据缓冲区621中。每个发送器连接604a、604b和604c使下一可用数据块从数据缓冲区621出列。数据缓冲区读取器602从数据缓冲区621读取数据，并且数据blob串化器603通过使下一可用数据块出列的特定连接发送下一可用数据块。发送的数据块通过接收器连接605a、605b和605c中的对应一个被接收。数据blob解串器文件607从接收器连接605a、605b和605c接收发送的数据块。数据blob解串器608将数据存储在数据缓冲区622中，并通过将数据块放入正确顺序中来重新创建原始文件。数据blob解串器608然后使用后台线程来将数据写到存储介质609。
由于性能原因，数据blob解串器608将一些数据高速缓存在数据缓冲区622中，以在数据按原始排序被放置时优选地将数据写到存储介质609。在一些情况下，当在不同的连接上发送的数据的排序变得太过无序时，数据blob解串器608将查找输出文件中的不同位置，并将数据写到存储介质609，以防止处理内存被高速缓存的数据耗尽。大量数据传送-并行数据协议(MDT-PDP)在这里描述的示例性架构中，MDT-PDP传输组件充当针对应用内的Soap连接库(SCL)子系统的传输句柄(handler)。这包括传送SOAP请求和响应。从SCL客户端和SCL服务的观点来讲，MDT-PDP传输在功能上等同于SCL的缺省的基于HTTP的传输。然而，这里提供的公开内容不限于前述示例性架构，并且可实现任何传输协议，只要实现权利要求的特征即可。SOAP连接库的目的是提供基于SOAP消息的Web服务的提供者卿，接收器)功能和客户端功能。提供者功能是提供Web服务以执行特定处理并提供用于访问的信息的功能。反之，客户端功能是访问Web服务的功能。使用SOAP连接库的Web服务不仅是客户端使用SOAP连接库，而且它还使得能够对来自使用Microsoft.NET框架和其他Web服务框架的客户端的请求进行处理。类似地，客户端功能不仅是Web服务使用SOAP连接库，而且它还使得能够执行与使用.NET框架和其他Web服务框架的Web服务相关的请求。在这里描述的示例性架构中，MDT-PDP实现了 SCL内定义的传输句柄接口。它们是发送器和接收器中的每一方的PdpTransportReceiver和PdpTransportSender。发送器一方的PdpTransportSender负责通过PDP发送器与PDP接收器之间的并行连接来建立F1DP发送器会话句柄链内的这些句柄的调用取决于数据的流动方向和发起者。句柄链内的这些句柄的调用还与底层PDP层处的数据传送的开始和结束相关。图7至图12是形成示例性实施例的架构的每个主要类的类图。以下结合图13至图20来详细地提供关于每个主要类之间的具体关系和交互的描述。图7是根据示例性实施例的针对传输发送器的类图。如图7所示，pdp::PdpTransportClientSender 对象 703 和 pdp::PdpTransportProviderSender 对象704 均继承 pdp::PdpTransportSender 对象 702。另外，pdp::PdpTransportSender 对象 702实现SCL库的transport:: TransportSender对象701。图7的类图中的send O方法使用MessageContext对象通过传输层发送消息。当该方法对消息的发送进行处理时,该方法被调用。图8是根据示例性实施例的针对传输接收器的类图。如图8所示，pdp::PdpTransportClientReceiver 对象和 pdp::PdpTransportProviderReceiver 对象804 均继承 pdp::PdpTransportReceiver 对象 802。另外，pdp::PdpTransportReceiver 对象802实现transport:: TransportReceiver对象801。这个receive O方法从传输层接收消息，并执行管理以将接收的消息的各种信息存储在Message类中以供接收。图9是根据示例性实施例的针对服务器分配器的类图。如图9所示，pdp::SoapDispatcher 对象 903 继承 server::DispatcherBase 对象 902,并依赖于pdp::DataBlobProviderSoap 对象 904 和 application::ApplicationInfo 对象 905。另外,server::DispatcherBase 对象 902 依赖于 server::Dispatcher 对象 901。SoapDispatcher类包含维护信息的AppicationInfo对象，所述信息诸如当用户用Soap连接库创建服务或客户端时的操作信息和客户端信息。因此，SoapDispatcher可通过ApplicationInfo对象与SCL通信，并且SCL将对于不同类型的分配句柄的DispatcherHandler (未示出)包含在DispatchHandlerChain 对象(未不出)中。图10是根据示例性实施例的针对数据源的类图。如图10所示，pdp::MdtDataSource 对象 1002 继承 dataholder::DataSource 对象 1003，并与 transport::DataBlobDeserializerFiIe对象1001相关联。DataSource对象包含允许调用者检索其中保存有数据的inputStream对象的功能。图11是根据示例性实施例的针对客户端交互的类图。如图11所示，PdpTransportClientReceiver 对象 1101 和 PdpTransportClientSender 对象 1103 中的每一个依赖于SimpleClient对象1102。DataSource对象包含针对MDT客户端的客户端信息。图12是根据示例性实施例的针对服务器交互的类图。如图12所示，PdpTransportProviderReceiver 对象 1202 和 PdpTransportProviderSender 对象 1203 中的每一个依赖于ServerSession对象1201。ServerSession定义PDP服务器的服务器会话。图13A和图13B是“put”情况下的客户端一方的顺序图。如图13A所示，在1301中，SCLClient 对象从用户继承 PUT (〈filename〉)。在 1302 中，:HandlerChain 对象从SCLClient 对象继承 invoke (MessageContext)。在 1303 中，:PdpTransportClientSender从:HandlerChain 对象继承 ini t (MessageContext)。 在 1304 和 1305中，:PdpTransportClientSender 对象与:DataBlobProviderSoap 对象和:SimpleClient 对象相关联。在 1306、1307 和 1308 中，:SimpleClient 对象从:PdpTransportClientSender对象继承 setDataBlobPr ovider (DataBlobProvider)、setLocallnetAddresses(inetAdress [])和 setConnectionOptions(PdpConnectionOptions)。 在 1309中，:PdpTransportClientSender 对象从:HandlerChain 对象继承 send (MessageContext)。SCLClient对象充当SOAP客户端，所述SOAP客户端利用MDT和PDP协议通过该定制的传输来发送和接收SOAP消息。SimpleClient对象是允许发送器利用PDP协议通过多个连接来发送数据的“简单”组件。此外，对于“PUT”操作，发送器将数据发送到接收器(S卩，提供者)。对于“GET”操作，发送器从提供者(S卩，接收器)取回数据。在1310 中，:SimpleClient 对象从:PdpTransportClientSender 对象继承getSessionO:ClientSession。在 1311 中，:SimpleClient 对象与:ClientSession 对象相关联，并且在 1312 和 1313 中，:ClientSession 对象与:DataBlobSerializeQueue对象和=DataBlobDeserializeQueue 对象相关联。在 1314 中，:ClientSession 对象从:SimpleClient 对象继 7承 startSession(MessageRequest):MessagesResponse。在 1315 中，:ClientSession 对象与:ClientConnection 对象相关联。在 1316 和1317 中，:ClientConnection 对象从它自己继承 createSession(MessageRequest)和 doRequestO。在 1318 中，:ClientConnection 对象与:ClientSession 对象相关联。在1319中，:ClientSession对象与:SimpleClient对象相关联。在1320中，:SimpleClient 对象与=PdpTransportClientSender 对象相关联。在 1321中，:PdpTransportClientSender 对象与:DataBlobSerializerSoap 对象相关联。在1322 中，:DataBlobSerializeQueue 对象从:PdpTransportClientSender 对象继承addDataBlob(DataBlobSerializer)。在 1323 中，:PdpTransportClientSender 对象从:HandlerChain 对象继承 destroy (MessageContext)，并且在 1324 中，:ClientSession对象从:PdpTransportClientSender 对象继承 WaitForRequestCompletion O。在 1325 中，:PdpTransportClientReceiver 对象从:HandlerChain 对象继承receive (MessageContext)。应该注意的是，DataBlobSerializerSoap 类扩展DataBlobSerializer (参见比如下述图 27)，并利用 SCL MessageSerializer 对象来使MessageContext对象中的消息串行化。DataBlobSerializer将数据blob串化器定义为抽象类，该抽象类也被以下更详细描述的DataBlobSerializerNoData和DataBlobSerializerPartStream 扩展。在1326 中，=DataBlobSerializerSoap 对象从:ClientConnection 对象继承 serialize (OutputStream)。在 1327 中，:ClientConnection 对象从它自己继承 doReponseO。在 1328 中，:ClientSession 对象从:ClientSession 对象继承 setCompletionStatus(SESSION—RESPONSE)。 在 1330 中，:SimpleClient 对象从=PdpTransportClientReceiver 对象继承 read():DataBlobDeserializerD 在 1329中，:ClientSession 对象从:SimpleClient 对象继承 waitForCompletionO。在 1331中，:ClientSession 对象从:SimpleClient 对象继承 getlncominDataBlobs:DataBlobDeserializerQueue0 在 1332 中，=DataBlobDeserializerQueue 对象从:SimpleClient对象继承 getDataBlobs O:DataBlobDeseralizer。在 1333 中，:SimpleClient 对象与:PdpTransportClientReceiver 相关联。在 1334 中，:PdpTransportClientReceiver 从它自己继承 deseriliaze (DataBlobDeserializer []MessageContext)。图14A和图14B是“put”情况下的提供者一方的顺序图。如图14A所7j\,:ServerConnection 对象从它自己继承 doRequest。在 1402 中，:ServerSession从:ServerConnection 对象继 7承 getlncominDataBlobsO =DataBlobDeserializeQueue。在 1403 和 1404 中，:DataBlobDeserializerQueue 对象和:DataBlobDeserializer对象从:ServerConnection 对象继承 getDataBlob(MessagesHeader):DataBlobDeserializer 和 deserialize(InputStream)。 在 1405 中，:ServerSession 对 象从:ServerConnection 对象继承 setCompletionState(SESSION—REQUEST)。在 1406中，:SoapDispatcher 对象从:ServerSession 对象继承 doWork(ServerSession)。在1414 中，:HandlerChain 从:SoapDispatcher 对象继承 invoke (MessageContext)。在 1415 中，:PdpTransportProviderReceiver 从:HandlerChain 对象继承 receive (MessageContext)。 在 1407 和 1408 中，:ServerSession 对象和=DataBlobDeserializerQueue 从:PdpTransportProviderReceiver 对象继 7承 getlncominDataBlobs():DataBlobDeserializerQueue 和 getDataBlobsO:DataB1bDeserializer。应该注意的是，DataBlobDeserializerFile类实现基于文件的数据blob解串器。DataBlobDeserializerQueue 类实现数据 blob 解串器队列。DataBlobDeserializerRAF类的实现是将数据部分解串到单个文件的一种实现。这个DataBlobDeserializerRAF实现使用RandomAccessFile (“RAF”)来写出数据部分。此外，尽管使用内存中数据部分缓冲区和后台写线程，但是将输入流写到盘和从输入流进行读取是去耦合的(decoupled)。ServerConnection类包括PDP服务器和PDP服务器的会话信息。调用者可通过该类创建并启动PDP连接并且接收和发送消息。在1409 中，:ServerConnection 对象从它自己继承 doResponse。在 1416 和1417 中，:PdpTransportProviderReceiver 继 7承 deserializeSOAP(DataBlobDeserializeerFile，MessageContext)和 deserializeAttachment(DataBlobDeserializerRAFj MessageContext) o 在 1418 中，:PdpTransportProviderReceiver 对象从:HandlerChain 对象继承 destroy(MessageContext)。在 1419 和 1420 中，:PdpTransportProviderSender对象从:HandlerChain 对象继承 init(MessageContext)和 send(MessageContext)。在 1421 中，:PdpTransportProviderSender 与:DataBlobSerializerSoap 对象相关联。在 1410 中，=DataBlobSerializeQueue 从:PdpTransportProviderSender 对象继承 addDataBlob (DataBlobSerializer)。 在 1411 中，=DataBlobSerializeQueue从:ServerConnection 对象继承 getNextDataBlob(DataBlobSerializer):DataBlobSerializerD 在 1412 中，=DataBlobSerializerSoap 对象从:ServerConnection 对象继承serialize (OutputStream) ο 在 1413 中，:ServerSession 对象从:ServerConnection 对象继承 setCompletionState (SESSION—DONE)。图15是“get”情况下的客户端一方的顺序图。如图15所示，在1501中，SCLClient 对象从用户继承 GET (〈filename〉)。在 1502 中，:HandlerChain 对象从SCLClient 对象继承 Invoke (messagecontext)。在 1503 中，:PdpTransportClientSender对象从:HandlerChain 对象继承 init (MessageContext)。在 1504、1505 和 1506中，:SimpleClient 对象从:PdpTransportClientSender 对象继承 SetDataBlobProvider (DataBlobProvider)、setLocalInetAddress (InetAddress [])和 setConnectionOptions (PdpConnectionOptions)ο 在 1507 中，:PdpTransportClientSender 对象从:HandlerChain 对象继承 send(MessageContext)。在 1508 中，:SimpleClient 对象从:PdpTransportClientSender 对象继承 getSessionO:ClientSession。在 1509中，:PdpTransportClientSender 对象从它自己继承 sendSoapMessage (MessageContext，DataBlobSerializeQueue)。在 1510 中，:PdpTransportClientSender 对象从:HandlerChain对象继承 destroy (MessageContext)。在 1511 和 1512 中，:PdpTransportClientReceiver对象从:HandlerChain 对象继承 receive (MessageContext)和 destroy (MessageContext)。图16是“get”情况下的提供者一方的顺序图。如图16所示，在1601中，:SoapDispatcher 对象从:ServerSession 对象继承 doWork(ServerSession)。在1602 中，:HandlerChain 对象从:SoapDispatcher 对象继承 invoke (messageContext) 0在 1603 和 1604 中，:PdpTransportProviderReceiver 从:HandlerChain 对象继承 receive (MessageContext)和 destroy (MessageContext)。 在 1605和 1606 中，:PdpTransportProviderSender 对象从:HandlerChain 对象继承 init(MessageContext)和 send (MessageContext)。 在 1607中，:PdpTransportProviderSender 从它自己继承 sendSoapMessage (MessageContextj DataBlobSerializeQueue)。在 1608 中，:PdpTransportProviderSender 对象从:HandlerChain对象继承 destroy (MessageContext)。图17是用于取消“get”操作的客户端一方的顺序图。如图17所示，在1701中，:ClientSession 对象从:PdpTransportClientSender 对象继承 start a newsession() 0 在 1702 中，:ClientConnection 对象从:ClientSession 对象继承 start theconnection (socket thread)。在 1703 中，:MeterInputStream 对象从:ClientConnection对象继承打ead(byte口，int，int):1nt。在 1704 中，:SessionDataMeter 对象被:MeterInputStream 对象中的函数 5^onBytesRead(1ng)实例化。在 1705中，:SessionDataMeter 对象将 SessionEvent O 与=PdpTransportClientSender 相关联。在1706 中，《interface》: InTransportEventListener 对象从:PdpTransportClientSender对象继承 handlelnTransportEvent (InTransportEvent) ο 在 1707 中，《interface》:InTransportEventListener 对象将 throw IOException()与:PdpTransportClientSender对象相关联。在 1708 中，:ClientSession 对象从:PdpTransportClientSender 对象继7承 terminate (Exception) ο 在 1709 中，:ClientConnection 对象从:ClientSession 对象继承close O ο MeterinputStream对象通过调用SessionDataMeter对象中的函数onBytesRead(long)来更新通过利用SessionDataMeter对象接收的数据字节。图18是用于取消“get”操作的提供者一方的顺序图。如图18所示，在1801中，:ServerSession 对象从 SoapDispatcher:eventProcessorThread 继承 Start a newserversession O。在 1802 中，:ServerConnection 对象从:ServerSession 对象继承start a connection socket()。在 1803 中，:MeterOutputStream 从:ServerConnection对象继承 *write (byte []，int，int)。 在 1804 中，:SessionDataMeter 对象从:MeterOutputStream对象继承 ^onByteWrite (long)。在 1805 中，:SessionDataMeter 将waitForEvent ():SessionEvent 与 SoapDispatcher:eventProcessorThread 对象相关联。在 1806 中，<<interace>>: OutTransportEventListener 对象从 SoapDispatcher: eventProcessorThread 对象继承 handleOutTransportEcent (OutTransportEvent)。在 1807 中，<〈interface>>:OutTransportEventListener 对象与 SoapDispatcher: eventProcessorThread 对象相关联。在 1808 中，:ServerSession 对象从 SoapDispatcher: eventProcessorThread 继承 terminate (Exception)。在 1809 中，:ServerConnection 对象从:ServerSession对象继承close O ο图19是用于取消“put”操作的客户端一方的顺序图。如图19所不，:MeterOutputStream 对象从:ClientConnection 对象继承 write (byte 口，int, int)。在 1902 中，:SessionDataMeter 对象继承 onBytesWrite (long)。 在 1903中，=SessionDataMeter 对象从=PdpTransportClientSender 对象继承waitForEventO:SessionEventο 在 1904 中，《interface》:OutTransportEventListener 对象从:PdpTransportClientSender 对象继 7承 handleOutTransportEvent(OutTransportEvent) ο 在 1905 中，《interface》:OutTransportEventListener 对象将 throwIOExceptionO 与:PdpTransportClientSender 对象相关联。在 1906 中，:ClientSession 对象从=PdpTransportClientSender 对象继承terminate (Exception) ο 在 1907 中，:ClientConnection 对象从:ClientSession 对象继承 close O ο图20是用于取消“put”操作的提供者一方的顺序图。如图20所不，:MeterInputStream 对象从:ServerConnection 对象继 7承 read (byte 口，int, int)。在 2002 中，:SessionDataMeter 对象继承 onBytesRead (long)。 在 2003中，:SessionDataMeter 对象从 SoapDispatcher:eventProcessorThread 对象继承waitForEventO:SessionEvent0 在 2004 中，〈〈interface》:InTransportEventListener 对象从 SoapDispatcher:eventProcessorThread 对象继 7承 handleInTransportEvent (InTransportEvent) ο 在 2005 中，〈〈interface》:InTransportEventListener 对象将 throw IOException ()与 SoapDispatcher: eventProcessorThread 对象相关联。在2006 中，:ServerSession 对象从 SoapDispatcher:eventProcessorThread 对象继承terminate (Exception) ο 在 2007 中，:ServerConnection 对象从:ServerSession 对象继承 close O。图21是图1的接收器102的I/O存储系统中的写操作的代表性示图。通常，在并行连接数据传送系统中，接收器的I/o存储系统可以是大量数据传送的瓶颈，更具体地讲，I/o存储系统中所包括的盘可以是大量数据传送的瓶颈。就这一点而言，当文件被划分为小片段或小块并通过分离的连接被传递时，数据可能不能按顺序到达接收器，尤其是当连接的数量增加时。如果接收器超时等待下一连续数据块到达，则在将数据写到盘之前，接收器的数据缓冲区可能变满。如果接收器的数据缓冲区变满，则接收器的I/o存储系统可能被迫对乱序数据进行盘写入，这可能需要额外的查找操作。如果接收器的I/o存储系统是对于数据传送的瓶颈，则执行额外的查找操作将进一步增加传送数据花费的时间。另外，由于缺少应答(即，对于由于接收器缓冲区满而丢失的数据的应答)，前述可能还触发从发送器重发数据的事件，从而为数据传送增加进一步的延迟。在这种情况下，接收器可停止接受新的连接请求，并且还可减少现存的连接数量，以可能避免满缓冲区状况，这继而可进一步避免高成本的查找操作。当通过多个连接发送数据时，多对一关系存在于发送器101和接收器102之间的连接与输出文件之间。也就是说，在多个并发连接中传送的数据被汇集到单个文件中。在接收器接收数据的每个连接内，启动从与所述单个文件相关联的入站(inbound)连接读取所有数据块的线程。传送同一文件的块的N个并行连接全都对如图6所示的同一数据blob解串器文件607调用解串方法。(图6的)数据blob解串器的任务于是是，从所有N个连接读取与所述文件相关联的所有数据块，并以有效的方式将所述数据传送到图6的存储介质609。如图21所示，DataffriteQueue2101将数据存储为椭圆形所表示的DataffriteObject的形式。在图21中，写线程2102将DataffriteObject写到文件。标号2103表示文件的开头。而且，已经被写到文件的数据被表示为标号2105。区域2106表示在其中数据已被接收、但是还未被写到文件的区域。区域2107表示在其中数据还未被接收的区域。DataWriteQueue是线程安全的阻止队列实现。实例监视器用作remove O方法和insert ()方法的同步锁。它们从队列移除项目。removeDataWriteOb jectWithOffsetO方法可被用于移除从特定偏移开始的变化。该方法将阻止，直到所需的数据区块可得。DataffriteObject对象将内存缓冲区中的数据存储在LinkList对象中以链接该数据，并且它还记录数据偏移和长度信息。在图21中，当前文件位置可供写线程2102用于将数据写到文件。然而，可能的是，对于当前文件位置2105，没有这样的DataWriteObject存在于DataWriteQueue2101中。因为不同的连接被用于从文件的不同区域传输数据，所以到写线程2102准备将文件的特定区域写到盘的时候，文件的该特定区域可能还未被接收。这可能表明内存缓冲区没有大到足以在写到存储器之前容纳临时块数据，这继而意味着查找操作可能被执行。这通常意味着，与处理I/O存储系统相比，从发送器101到接收器102的数据传送速率更快。因此，可减少加入连接的数量以避免文件查找操作，以下将结合图40来更详细地描述这种情况。更具体地讲，如果写线程2102在这种情况下被允许将文件的不同区域写到盘，则写线程2102将执行要被避免的查找操作。另一方面，如果写线程2102无限期地阻止，从而等待无限量的时间以使DataWriteObject通过连接之一被提交到队列，则也存在低效率的可能性。当利用更快的网络并且I/O存储系统的盘是数据传送中的瓶颈时，尤其如此。在这种情况下，使写线程2102等待地越长，传送变得效率越低。为了提供高效率的PDP数据传送，使两件事平衡:(I)频繁地将数据写到盘，这意味着允许写线程2102频繁地保持未被阻止；和(2)避免文件查找操作，这意味着有时阻止写线程2102以等待直到从连接之一读取针对当前文件位置的数据。上述平衡在DataWriteQueue2101中执行。在针对当前文件位置2104的DataffriteObject不可得时，DataffriteQueue利用例如以下启发法(heuristic)(该启发法趋向于基本上避免不必要的查找操作，并且还趋向于基本上避免写线程2102的不必要的阻止):如果DataWriteObject对于当前文件位置不可得:(I)对于将通过读线程被添加到DataWriteQueue2101的被请求的DataWriteObject等待直到2秒；(2)如果被请求的DataWriteObject在2秒超时时间段内变为可得，贝U返回它；以及(3)如果被请求的DataffriteObject没有在2秒超时时间段内变为可得，则将可得的具有最低绝对偏移的DataWriteObject返回给写线程2102。这种启发法尝试使保持写线程写到盘与避免文件查找操作相平衡。然而，可能不能完全避免查找操作，并且为了更好的数据传送性能，接收器102可阻止来自发送器101的加入请求，并请求发送器101关闭一个或多个次要连接，以下将结合图40来更详细地描述这种情况。当内存中存在较少的DataWriteObject (即，表示还未被写线程2102写到文件的数据)时，代表当前文件位置2104的DataWriteObject可得是不太可能的。如果写线程2102在这种情况下被允许将可得的DataWriteObject之一写到文件，则更可能的是需要在文件上的查找操作。因此，当DataWriteQueue2101几乎为空时，写线程2102在它试图移除DataffriteObject时被阻止，以允许DataWriteQueue2101被连接读线程填充到最小水平。在不同的情况下，当读线程试图将DataWriteObject添加到DataWriteQueue2101时，这些读线程可被阻止。在这种情况下，当DataWriteQueue2101填充有非常大量的DataffriteObject 时，接着，试图将另一 DataWriteObject 添加到 DataWriteQueue2101 的连接读线程(未示出)将被阻止。这允许写线程2102将DataWriteObject中的一些写到盘。在内部，DataffriteQueue2101利用 ConsumerProducerThrottle 对象(未示出)来决定何时发生了前述的阻止情况。ConsumerProducerThrottle对象是定义关于实现DataWriteObjectThrottle (未示出)的契约(contract)的接口对象。DataffriteObjectThrottle允许应用配置在将未实现的数据写到盘存储器之前将该数据高速缓存在内存中的内存缓冲区大小，并且它还包含当前的和消耗的恢复缓冲区信息。当写线程2102 请求从 DataWriteQueue2101 移除 DataWriteObject时，DataWriteQueue 向 ConsumerProducerThrottle 对象通知该请求。如果DataWriteQueue2101在其中不具有最少数量的DataWriteObject，则ConsumerProducerThrottle 对象阻止写线程 2102。一旦 DataWriteQueue2101 被足够的DataWriteObject 填充，ConsumerProducerThrottle 就释放写线程 2102。可替换地，当读线程请求将新的DataWriteObject添加到DataWriteQueue2101时，DataWriteQueue2101可能已达到最多数量的DataWriteObject。在这种情况下，读线程被阻止，直到写线程2102具有从DataWriteQueue2101移除DataWriteObject的机会。再次，DataWriteQueue2101 利用其 ConsumerProducerThrottle 对象来决定何时发生了前述情况。当读线程将DataWriteObject添加到DataWriteQueue2101时，DataWriteQueue210I 向 ConsumerProducerThrottle 通知 DataWriteObject 正被添力口。如果 ConsumerProductThrottle 决定 DataWriteQueue2101 已达到其最多数量的DataWriteObject，则ConsumerProductThrottle阻止读线程。读线程保持被阻止，直到队列中的DataWriteObject的数量减少。图22是如图21所示的DataWriteQueue2101的代表性示图。在图22中，DataWr iteQueue2101 被不为在接收多个 DataWr iteOb ject (例如，DataWriteOb ject220 Ia 至2201d)之后。在这个例子中，DataWriteOb ject被组织成5个链，这5个链表示文件的5个邻接区域。0&丨3 1'；^6013」^(^22013至2201(1表不所述5个链之一。通常，03丨3 1'；^6013」^(^2101充当N个读线程的同步和组织点。为了避免查找操作，DataWriteQueue自动地检测表示文件的邻接区域的DataWriteObject的集合。当DataWriteQueue2101接收到表示文件的邻接区域的多个DataWriteObject时，无论每个DataWriteObject来自哪个连接，DataWriteQueue2101 都在内部将这些 DataWriteObject 收集成单个链。DataWriteQueue由此将DataWriteObject存储为DataWriteObject链的无序集合。当图21 的写线程 2102 从 DataWriteQueue 移除 DataWriteObject 时，写线程 2102指示当前文件位置。为了可能避免文件查找操作，DataWriteQueue2101提供其偏移是当前文件位置2104的DataWriteObject。写线程2102然后可在不执行查找操作的情况下写到当前文件位置2104。在内部，D`ataWriteQueue2101维护表示文件的邻接区域的M个DataWriteObject 链的收集。DataWriteQueue2101 检查所述 M 个 DataWriteObject 链的起始偏移，并且如果存在其初始偏移与当前文件位置匹配的链，则返回该整个链。图23是图1的接收器102的I/O存储系统中的写操作的另一代表性示图。通常，因为数据可能不能依次到达，所以多个连接可将数据写到内存缓冲区以重新组装数据。通过在将数据写到盘的同时测量I/O存储系统写速率，可确定盘是否忙于对来自其他应用和任务的请求进行处理。因此，可适当地减少或增加连接的数量，将结合图40来更详细地描述这种情况。如图23所示，写线程2102将数据写到存储介质609中的文件(如图6所示)。写线程2102的使用将N个读线程从文件写操作去賴合。DataWriteObject通过连接605a至605c被添加，并且被写线程2102移除。写线程2102将数据写到存储介质609的速率是I/O存储系统的被测写速率。图24A是用于检测在图1中的发送器101的1/0存储系统中的数据传送中的瓶颈的顺序图。通常，发送器101可利用往返时间(RTT)来找到网络性能。所利用的RTT可以是TCP的RTT或者计算RTT的任何其他专有方法。现代的TCP实现通过下述方式来设法回答网络性能的问题:监视数据包的正常交换，并逐渐产生对多久为“太久”的估计。这个处理被称为往返时间(RTT)估计。RTT估计是TCP交换中的重要性能参数，尤其是在无限大的传送中，在所述无限大的传送中，无论链路的质量是否良好，大多数TCP实现最终都丢弃包并重传它们。如果RTT估计太低，则不必要地重传包；如果RTT估计太高，则在主机等待超时的同时连接可处于空闲状态。当发送器101发现发送到接收器102的消息包的RTT时间花费比先前的消息包长时，这可表明网络忙并且具有更多的流量。在这种情况下，发送器101可减少连接的数量并通知接收器102。可替换地，当RTT花费较短的时间段时，发送器可要求增加连接的数量。将结合图40来更详细地描述前述连接数量的减少和增加。在图24A中，发送器101可要求接收器102向发送器101发送应答。当发送器101检测到它将不再保存高速缓存的信息的情况时，发送器101将通知接收器102，并迫使接收器发送应答(ACK)以允许双方适当地清除高速缓存的信息并前进到新的数据部分。在这种情况下，接收器可决定它是否可针对发送器101增加连接数量以利用更多的带宽。所述应答(ACK)是指应用层上的应答，而非传输层(诸如TCP协议)中的ACK信号。为此，MDT实现供接收器作为应答(即，这里的ACK)向客户端通知数据已达到的通信信道。可替换地，接收器否定应答(RNA)可被用于实现前述的高速缓存的清除。特别地，在图24A中，发送器101在送出消息之前将数据读取到内存缓冲区中(步骤2401)。在步骤2402至2406中，发送器101发送偏移为al、长度为bl的数据部分，发送偏移为a2、长度为b2的数据部分，发送偏移为a3、长度为b3的数据部分，并继续发送数据部分，直到这些数据部分达到偏移a (n-1)、长度b (n-1)，并最终达到偏移an、长度bn，其中，“η”表示序列中的数据部分的数量。在步骤2407中，发送器101请求接收器发送包括所识别的数据部分的列表的ACK。接收器102使它跟踪的数据包的值的偏移和长度向前移动，并将这些数据包写到存储器。在步骤2408中，接收器102发送被请求的ACK，发送器101清除高速缓存在内存缓冲区中的数据。图24Β是图1中的发送器101的I/O存储系统中的读操作的代表性示图。在图24Β中，数据缓冲区读取器2411在独立的线程中从存储介质(即，盘)601读取数据区块。数据缓冲区读取器2411使用包括“Free”部分和“Full”部分的双队列机制。数据缓冲区读取器2411将数据缓冲区部分加载到内存缓冲区2412的“Full”侧中。数据缓冲区读取器2411管理加载且循环的数据缓冲区部分列表，并以同步的方式提供对加载的数据缓冲区部分的访问。另外，数据缓冲区部分提供从网络读取它们的内容和将它们的内容写到网络的能力。DataBlobSerializerPartStream2421a>242Ib 和 2421c 从数据缓冲区读取器2411检索加载的数据部分，并通过网络依次发送这些数据部分。DataBlobSerializerPartStream针对给定的输入流或数据缓冲区读取器扩展DataBlobSerializer,以使数据与基于PDP协议连接的数据串行化。DataBlobSerializerPartStream2421a、2421b和2421c也循环利用的数据部分。连接604a、604b和604c将端对端连接套接字提供给远程主机，并使用DataBlobSerializerPartStream对象2421a、2421b和2421c来将数据发送到远程主机。连接604a、604b和604c与本地主机上的其他连接实例并行地工作。
图24B中所示的复杂的双队列机制提供以下高效率构思:(I)从盘异步地读取数据，从而在数据读取和数据发送中实现时序重叠；(2)提供对加载的数据缓冲区部分的列表的同步访问的能力，该能力使得可同时运行连接线程以通过多个套接字并行地发送数据；以及(3)重复使用数据缓冲区部分的能力，从而基本上避免不必要的堆内存分配和垃圾收集。
当数据缓冲区读取器2411从存储介质(B卩，盘)601读取数据比网络可发送数据快、并且内存缓冲区达到其极限(所述极限适用于许多客户端-服务器应用系统)时，客户端将停止将数据读取到内存缓冲区中，直到内存可用。这导致在其中从盘读取数据和网络上发送数据不重叠的时间跨度，从而导致数据在系统上的非规范化的流动。这至少对于较大数据集合降低了数据的净吞吐量。然而，一旦检测到发送器的内存缓冲区频繁地变满(这识别网络是数据传送的瓶颈)，就可通过下述方式来采取校正动作:当带宽低时，减少连接的数量以减轻数据对网络的堵塞，并且基本上同时地，引入延时。基本上与减少连接的数量同时地，也在从存储介质(即，盘)读取数据中引入延迟，以实现发送数据的适当规范化的流动。以下将结合图40来更详细地描述前述的检测和校正动作。图25至图28是针对形成示例性实施例的架构的核心的每个主要类的类图。以下结合图29至图39来详细地提供关于每个主要类之间的具体关系和交互的描述。图25是根据示例性实施例的针对服务器的类图。如图25所不，server:: ServerSession 对象 2501 与 server: !Dispatcher 对象 2502、server::ServerConnection 对象 2503 和 server::Server 对象 2504 相关联。另夕卜，server::ServerConnection 对象 2503 与 server::ServerSession 对象 2501和 server::Server 对象 2504 相关联。而且，server::Server 对象 2504 与server:: ServerSession 对象 2501 和 server::Dispatcher 对象 2502 相关联。应该注意的是，该图中所指定的类被MDT应用使用来通过SOAP连接库(即，SCL)创建PDP协议服务器以接受PDP协议客户端连接请求并维护服务器会话。Server对象实现PDP服务器，创建并启动PDP服务器的实例以监听特定地址和端口，并且构建并维护服务器连接部分和加入会话。调用者也可从这个类检索会话id。图26是根据示例性实施例的针对客户端的类图。如图26所示,ClientConnection对象2603和SimpleClient对象2602中的每一个与ClientSession对象2601相关联。这些类被MDT应用使用来通过Soap连接库创建PDP协议以连接到PDP协议服务器连接并维护客户端会话。图27是根据示例性实施例的针对数据串化器的类图。如图27所示,DataBlobItem对象 2703 与 DataBlobSerializer 对象 2701 相关联。另外，DataBlobSerializerPartStream对象 2702 和 DataBlobSerializerNoData 对象 2704 中的每一个与 DataBlobSerializer 对象 2701 相关联。DataBlobSerializerNoData 和 DataBlobSerializerPartStream 都扩展DataBlobSerializer对象。并且,DataBlobSerializerNoData提供不包含任何数据的串行化的数据blob。图28是根据示例性实施例的针对数据解串器的类图。如图28所示，DataBlobDeserializerFile 对象 2803 和 DataBlobDeserializerRAF 对象 2802 中的每一个继承 DataBlobDeserializer 对象 2801。另外，DataBlobDeserializerRAF 对象 2802与 DataWriteQueue 对象 2804 相关联。DataBlobDeserializer 定义数据 blob 解串器和DataBlobDeserializerFiIeλ DataBlobDeserializerRAF, DataBlobSerializerQueue 扩展这个对象，并利用SCL MessageSerializer对象来对MessageContext对象中的消息进行解串O图29是用于在客户端建立会话的顺序图。如图29所示，在2901中，client::ClientSession 对象从开发工具(Developer)继承 startSession O。在 2902中，<<interface>>:PdpClientSocketFactory 对象从 client::ClientSession 对象继承create (UrlEx): Socket。在 2903 中，〈〈static〉〉: Request 对象从:ClientConnection对象继承 write (OutputStream)。 在 2904 中，〈〈static〉〉: Response 对象从:ClientConnection 对象继承 read (InputStream)。在 2905 中，:ClientConnection 对象从 client::ClientSession 对象继 7承 getResponse O:Messages.Response。Message.Response是Message类(未示出)的内部类，并定义PDP响应消息。Message类包含用于F1DP通信的所有传输消息。通过该类，调用者可从输入流得到下一 PDP消息，并定义基本PDP消肩、O在2906 中，client::ClientSession对象从开发工具继承 joinSession ()。在 2907中，<<interface>>:PdpClientSocketFactory 对象从 client::ClientSession 对象继承create (UrlEx): Socket。在 2908 中，〈〈static〉〉: Join对象从:ClientConnection对象接收write (OutputStream)。在 2909 中，〈〈static〉〉: Response 对象从:ClientConnection 对象继承read(InputStream)。在 2910 中，:ClientConnection对象从 client::ClientSession对象继承 getResponse O:Message.Response。在 2911 中，client::ClientSession 对象从开发工具继承waitForCompletionO。在2912中，:ClientConnection从它自己继承 doRequestO。在 2913 中，:ClientConnection 将 setCompletionState (REQUEST)与client::ClientSession 相关联。在2914 中，:ClientConnection 对象从它自己继承 doRequest。在 2915中，:ClientConnection 将 setCom`pletionState (REQUEST)与 client::ClientSession相关联。在2916中，:ClientConnection从它自己继承doResponseO。在2917 中，:ClientConnection 对象将 setCompletionState (RESPONSE)与client::ClientSession对象相关联。在2918中，:ClientConnection对象从它自己继承doResponse O。在 2919 中，:ClientConnection 对象关联 setCompletionState (RESPONSE)。在 2920 中，:ClientConnection对象从它自己继承 close O。在 2921 中，:ClientConnection对象从它自己继承close O。图30是用于提供根据示例性实施例的在发送器(例如，图1的发送器101)建立开始会话的描述的流程图。在步骤3001中，开始会话的建立开始。在步骤3002中，在发送器创建用于建立开始会话的套接字。在步骤3003中，发送器将用于建立开始会话的请求消息发送到接收器(例如，图1的接收器102)。发送器然后读取从接收器发送到发送器的响应消息(步骤3004)。在步骤3005中，确定响应消息是否指示发送的用于建立开始会话的请求消息成功。如果该请求不成功，则关闭在步骤3002中创建的套接字(步骤3006)。如果该请求成功，则创建会话(步骤3007 )，并执行进一步的请求(步骤3008 )。图31是用于提供根据示例性实施例的在发送器(例如，图1的发送器101)建立加入会话的描述的流程图。在步骤3101中，加入会话的建立开始。在步骤3102中，在发送器创建用于建立加入会话的套接字。在步骤3103中，发送器将用于建立加入会话的加入消息发送到接收器(例如，图1的接收器102)。发送器然后读取从接收器发送到发送器的响应消息(步骤3104)。在步骤3105中，确定响应消息是否指示发送的用于建立加入会话的加入消息成功。如果该加入消息不成功，则关闭在步骤3102中创建的套接字。如果该加入消息成功，则创建加入会话(步骤3107)。在步骤3108中，对会话状态进行检查。如果会话完成，则关闭套接字(步骤3111)。如果进一步的请求被保证，则所述处理前进到步骤3109，结合图35来详细描述这种情况。如果进一步的响应被保证，则所述处理前进到步骤3110，结合图36来详细描述这种情况。图32是用于在服务器建立会话的顺序图。如图32所示，在3201中，:Server对象从开发工具继承addDispatcher (String，Dispatcher)。在3202中，:Server对象从开发工具继承 start O ο 在 3203 中，〈〈static〉〉: Request 对象从:ServerConnection 对象继承read(InputStream)。在 3204 中，:ServerConnection 对象将 createSession(Messages.Request):ServerSession与:Server对象相关联。应该注意的是，这里作为参数传递的Message.Request是Messages类(未示出)的内部类，并且它定义PDP请求消息。在3205 中，<〈interface>>:Dispatcher 从:Server 对象继7承 onSessionCreate (ServerSession) ο 在 3206 中，<<static>>:Response从:ServerConnection 对象继承 write (OutputStream)。在 3207 中，〈〈static〉〉: Join 对象从:ServerConnection 对象继承 read (InputStream)。在 3208 中，:ServerConnection 对象将 joinSessoin (Messafees.Join): ServerSession 与:Server 对象相关联。在 3209 中，<<interface>>:Dispatcher 对象从:Server 对象继承 onSessionJoin(ServerSession)。在 3210 中，〈〈static〉〉:Response 对象从:ServerConnection 对象继承write (OutputStream)。在3211 中，:ServerConnection 对象从它自己继承 doRequestO。在 3212中，:ServerConnection 将 setCompletionState (REQUEST)与:ServerSession 对象相关联。在3213中，:ServerConnection从它自己继承doRequestO。在3214中，:ServerConnection 对 象 将 setCompletionState(REQUEST)与:ServerSession对象相关联。在 3215 中，<〈interface>>:Dispatcher 对象从:ServerSession对象继承 doWork(ServerSession)。在 3216 中，:ServerConnection 对象从它自己继承doResponseO。在3217中，:ServerConnection对象从它自己继承doResponseO。在 3218 中，:ServerSession 对象从:ServerConnection 对象继承setCompletionState (RESPONSE)。在 3219 中，:ServerSession 对象从:ServerConnection对象继承 setCompletionState (RESPONSE)。在 3220 中，〈〈interface〉〉:Dispatcher 对象从:ServerSession 对象继承 onSessionEnd (ServerSession)。在 3221 中，:Server对象从:ServerSession 对象继承 removeSession (ServerSession)。在 3222 和 3223中，:ServerConnection对象从它们自己继承close O。图33是用于提供根据示例性实施例的在接收器建立会话的描述的流程图。在图33的步骤3301中，连接的接受开始。在步骤3302中，发送器发送的消息被接收器接收，并且接收器读取消息。在步骤3303中，获得所述消息的ID。如果所述消息的ID指示该消息是除了请求消息或加入消息之外的其它消息，则接收器将响应与错误消息一起发送到发送器(步骤3316)，并关闭利用的套接字(步骤3317)。如果所述消息是请求消息，则确定被请求的连接路径是否被注册(3307)。如果所述路径未被注册，则接收器将响应与错误消息一起发送到发送器(步骤3318)，并关闭利用的套接字(步骤3319)。如果所述路径被注册，则创建会话(步骤3308)，并将响应与会话ID消息一起从接收器发送给到发送器(步骤3309)。在步骤3303中，如果所述消息是加入消息，则接收器确定被请求的加入会话是否可用(步骤3304)。如果所述会话不可用，则接收器将响应与错误消息一起发送到发送器(步骤3305)，并关闭利用的套接字(步骤3306)。如果所述会话可用，则加入所述会话(步骤3310)，并将响应与会话状态消息一起从接收器发送到发送器(步骤3311)。在步骤3312中，对会话状态进行检查。如果会话完成，则关闭套接字(步骤3315)。如果进一步的请求被保证，则所述处理前进到步骤3313，结合图38来详细描述这种情况。如果进一步的响应被保证，则所述处理前进到步骤3314，结合图39来详细描述这种情况。图34是针对客户端处的数据交换的顺序图。如图34所示，在3401中，transport::DataBlobSerializeQueue 对象从:ClientConnection 对象继承 getNextDataBlob (DataB1bSerializer)=DataBlobSerializer0 在 3402 中，transport::DataBlobSerializeQueue对象从开发工具继承 addDataBlob (DataBlobSerializer)。在 3403 中，:ClientConnection对象将 serialize (OutputStream)与=DataBlobSerializer 对象相关联。在 3404 中，transport:: DataBlobSerializeQueue 对象从:ClientConnection 对象继承 getNextDataBlob (DataBlobSerializer):DataBlobSerializerD 在 3405 中，:ClientSession对象从开发工具继承 waitForCompletion O。在 3406 中，:ClientConnection 将 serialize (OutputStream)与=DataBlobSerializer 对象相关联。在 3407 中，:ClientConnection 对象将 setCompletionState(REQUEST)与:ClientSession 对象相关联。在 3408中，:ClientConnection 对象将 setCompletionState (REQUEST)与:ClientSession 对象相关联。

在3409 中，transport:=DataBlobSerializerQueue 从:ClientSession 对象继承 close O ο 在 3410 中，=DataBlobSerializer 对象从 transport::DataBlobSeriaIizerQueue 对象继承 close O。在 3411 中，transport::DataBlobDeserializerQueue从:ClientConnecion 对象继承 getDataBlob (Messages.Header):DataBlobDeserializer。在 3412 中，transport::DataBlobDeserializerQueue 对象从:ClientConnection对象继承 getDataBlob(Messages.Header):DataBlobDeserializer。应该注意的是，Message.Header是Messages类(未示出)的内部类，并且它定义DATA-HEADER消息。在 3413 和 3415 中，=DataBlobDeserializer 对象从:ClientConnection 对象继7承 deserializer (InputStream)和 deserializer (InputStream)0 在 3414 和 3416中，:ClientConnection 对象将 setCompletionState (RESPONSE)与:ClientSession 对象相关联。在3417和3418中，:ClientConnection对象从它们自己继承close O。在3419和 3421 中，transport::DataBlobDeserializerQueue 对象从开发工具继承 getDataBlobsO:DataBlobDeserializer 和 dispose O。在 3420 和 3422 中，:DataBlobDeserializer 对象继承 getDataO:1nputStream 和 dispose ()。图35和图36是用于提供针对发送器处的数据交换的大致描述的流程图。在图35的步骤3501中，发送数据的请求开始。在步骤3502中，发送器确定是否存在要得到的下一可得串行化数据blob。如果存在下一可得的数据blob，则发送器针对该数据blob写数据头(步骤3503)，从数据的源读取该数据blob的数据部分(步骤3504)，并将读取的数据部分写到创建的套接字(步骤3505)。在步骤3506中，发送器确定该数据部分是否是数据blob的最后数据部分。如果该数据部分不是最后数据部分，则发送器将该数据blob的下一数据部分写到创建的套接字(步骤3505)。如果在步骤3506中该数据部分是最后数据部分，则所述处理返回到步骤3502。如果在步骤3502中确定不存在下一可得的串行化数据blob，则所述请求完成(步骤3507 )，并执行对接收数据的响应(步骤3508 )。在图36中，在步骤3601中，执行对接收数据的响应。在步骤3602中，读取传入数据的数据头。在步骤3603中，发送器获得与读取的数据头相关联的解串的数据blob。在步骤3604中，发送器从创建的套接字读取数据blob的数据部分。在步骤3605中，发送器将读取的数据部分写到数据存储器。在步骤3606中，发送器确定该数据部分是否是该数据blob的最后数据部分。如果该数据部分被确定为不是最后数据部分，则所述处理返回到步骤3605，在步骤3605中，发送器将下一数据部分写到数据存储器。如果该数据部分被确定为最后数据部分，则所述处理前进到步骤3607。在步骤3607中，发送器确定该数据头是否是将被接收的数据的最后数据头。如果该数据头是最后数据头，则所述响应完成(步骤3608X图37是针对服务器处的数据交换的顺序图。如图37所示，在3701和 3702 中，=DataBlobDeserializerQueue 对象从 ServerConnection 对象继承 getDataBlob (Messages.Header):DataB1bDeserializer 在 3703和 3704 中，=DataBlobDeserializer 对象从:ServerConnection 对象继承 deserializer (InputStream) 在 3705 和 3706 中，:ServerSession 对象从:ServerConnection 对象继承 setCompletionState(REQUEST)。在 3707 中，<<interface>>:Dispatcher 对象从:ServerSession 对象继承 doWork(ServerSession)。在 3708 中，=DataBlobDeserializerQueue 从 <〈interface>>:Dispatcher 对象继承getDataBlobsO =DataBlobDeserializer0 在 3708 中，:DataBlobDeserializerQueue从 <<interface>>:Dispatcher 对象继承 getDataBlobsO:DataBlobDeserializer。在 3709 中，:DataBlobDeserializer 对象从 <<interface>>:Dispatcher 对象继承getDataO:1nputStream0在3710和3711 中，=DataBlobDeserializerQueue对象和=DataBlobDeserializer对象继承 dispose O。 在 3712 中，=DataBlobSerializerQueue 对象从<<interface>>:Dispatcher 对象继承 addDataBlob(DataBlobSerializer)。在 3713 和3714 中，:DataBlobSerializerQueue 对象从:ServerConnection 对象继承 getNextDataBlob (DataBlobSerializer): DataBlobSerializer0 在 3715 和 3716 中，:DataBlobSerializer对象从:ServerConnection 对象继承 serialize (OutputStream) 0 在 3717 和 3718中，:ServerSession 从:ServerConnection 对象继承 setCompletionState (RESPONSE)。在 3719 和 3720 中，:DataBlobSerializerQueue 对象和:DataBlobSerializer 对象继承close () ο图38和图39是用于提供针对接收器处的数据交换的大致描述的流程图。在图38中，在步骤3801中，执行对接收数据的响应。在步骤3802中，读取传入数据的数据头。在步骤3803中，接收器获得与读取的数据头相关联的解串的数据blob。在步骤3804中，接收器从创建的套接字读取数据blob的数据部分。在步骤3805中，接收器将读取的数据部分写到数据存储器。在步骤3806中，接收器确定该数据部分是否是该数据blob的最后数据部分。如果该数据部分被确定为不是最后数据部分，则所述处理返回到步骤3805，在步骤3805中，接收器将下一数据部分写到数据存储器。如果该数据部分被确定为最后数据部分，则所述处理前进到步骤3807。在步骤3807中，接收器确定该数据头是否是将被接收的数据的最后数据头。如果该数据头是最后数据头，则所述响应完成(步骤3808)。在图39的步骤3901中，发送数据的请求开始。在步骤3902中，接收器确定是否存在要获得的下一可得的串行化数据blob。如果存在下一可得的数据blob，则接收器针对该数据blob写数据头(步骤3903)，从数据的源读取该数据blob的数据部分(步骤3904)，并将读取的数据部分写到创建的套接字(步骤3905)。在步骤3906中，接收器确定该数据部分是否是该数据blob的最后数据部分。如果该数据部分不是最后数据部分，则接收器将该数据blob的下一数据部分写到创建的套接字(步骤3905)。如果在步骤3906中该数据部分是最后数据部分，则所述处理返回到步骤3902。如果在步骤3902中确定不存在下一可得的串行化数据blob，则所述请求完成(步骤3907)，并执行对接收数据的响应(步骤3908)。自动调节发送器与接收器之间的连接的数量图40是用于提供另一示例性实施例的详细解释的流程图。更具体地讲，图40描绘了用于提供关于如图1所示的从发送器101到通过网络120与发送器101连接的接收器102的大量数据传送的示例性实施例的详细解释的流程图。如图40所示，在步骤4001和4002中，通过网络120在发送器101与接收器102之间建立多个连接。这些连接可以是，例如，并行TCP连接；然而，所述多个连接不限于TCP连接，并且可利用使用并行连接的其他协议。在步骤4003中，通过在所述多个连接上划分地发送数据来将数据从发送器101发送到接收器102，以便聚合网络120的带宽的利用。在步骤4004中，接收器102通过所述多个连接接收划分的数据，并且接收器102将划分的数据重组为其原始形式。在步骤4005至4010中，至少基于发送器101处的1/0存储系统的性能、接收器102处的I/o存储系统的性能和网络120的性能，基于发送器101与接收器102之间的连接的数量来执行自动调节。自动调节被执行以提供发送器与接收器之间的连接的最佳数量，从而提供理想且高效率的数据吞吐量。更特别地，在步骤4005中，通过图2所示的自动调节软件236来确定发送器101的1/0存储系统读数据是否比通过网络120送出数据快。例如通过下述方式进行该确定:将发送器101的1/0存储系统把数据输入到发送器的内存缓冲区中的速率的计算与从网络120从发送器的内存缓冲区获取数据的速率的计算相比较。如果在步骤4005中确定发送器101的1/0存储系统读数据比通过网络120送出数据快，则对发送器101与接收器102之间的连接的数量执行自动调节，在所述自动调节中，发送器101将用于打开新连接的请求发送到接收器102。如果接收器102返回用于打开新连接的请求成功的响应，则发送器101可通过该新连接发送数据，以提供系统中的平稳数据流动。当发送用于打开新连接的请求时,发送器101可请求打开一个或多个新连接。然而，如果发送器101请求打开许多个新连接，则接收器102可由于若干个不同原因而拒绝用于打开所有这些新连接的请求，其将在下面被更详细地描述。如果在步骤4005中确定发送器101的I/O存储系统读数据不比通过网络120送出数据快，则所述处理前进到步骤4006。在步骤4006中，确定发送器101的I/O系统读数据是否比通过网络120送出数据慢。如果确定发送器101的I/O系统读数据比通过网络120送出数据慢，并且多于一个的发送器(例如，图1的发送器131和132之一)正将数据发送到接收器102，则发送器101关闭所述多个连接中的现存连接，以对发送器101与接收器102之间的连接的数量进行自动调节。就这一点而言，现存连接的关闭是次要连接而非主要连接的关闭。作为前面描述的结果，发送器101可基本上防止在接收器102处占用未被发送器101充分用于发送数据的套接字。通过检查发送器的具有低利用率的内存缓冲区，例如，当内存缓冲区利用率在某一时间段(比如，30秒)内保持低并保持低于总内存缓冲区大小的预定义阈值(比如，30%)时，则发送器可推断发送器读数据比发送数据慢。同样地，如果内存利用率在一时间段内高并且阈值(诸如内存缓冲区的80%正被使用)在该时间帧期间被达到，则发送器可推断发送器101的I/O系统读数据比通过网络120送出数据快。在步骤4009中，通过自动调节软件336来检测大量数据传送的瓶颈是否存在于接收器102的I/O存储系统中。如果肯定地检测到大量数据传送的瓶颈存在于接收器102的I/O存储系统中，则对发送器101与接收器102之间的连接的数量执行自动调节，在所述自动调节中，接收器102关闭现存连接(S卩，次要连接)。接收器102可关闭一个或多个现存的次要连接。在发送器101检测到发送器101处的缓冲区基本上满的情况下，发送器101可将用于打开新连接的请求发送到接收器，或者利用已经被创建但是当前还未被用于发送数据的连接。当发送器处的缓冲区基本上满时打开新连接具有提供平稳的总数据传送的有益效果，这是因为可减小从发送器发送数据时的延迟或间隙。可替换地，在发送器检测到大量数据传送的瓶颈存在于发送器的I/o存储系统中的情况下，发送器101可关闭现存的次要连接。当发送器101处的缓冲区基本上空时，肯定地检测到大量数据传送的瓶颈在发送器101的I/o存储系统中。在一些情况下，接收器102的I/O存储系统包括盘(例如，图6的盘609)。在这些情况下，当对接收器102的I/O存储系统执行盘的查找操作时，肯定地检测到大量数据传送的瓶颈在接收器102的I/O存储系统中。更具体地讲，因为多个连接正被使用，所以数据可能不能按顺序到达接收器102。如果接收器102在等待下一连续数据块时超时或者填充其内存缓冲区，则接收器102的I/O存储系统可能对乱序数据进行盘写入，对乱序数据进行盘写入稍后可能需要额外的查找操作。这可意味着，数据从发送器101被传送到接收器102比接收器101的I/O存储系统将数据写到盘快。因此，瓶颈可能存在于接收器102的I/O存储系统中。可替换地，在接收器102的I/O系统包括盘的那些情况下，当接收器102的I/O存储系统将数据写到盘比先前的I/o写速率慢时，肯定地检测到大量数据传送的瓶颈在接收器102的I/O存储系统中。先前的I/O写速率可以基于先前对多于一个的写操作测量的I/O写速率，或者可以基于先前对一时间段的写操作测量的I/O写速率，或者可以基于先前测量的写操作的I/o写速率的加权平均值。例如，如果接收器的I/o存储系统的先前的I/O写速率为lOMb/s，并且接收器的I/O存储系统当前正以5Mb/s写数据，则瓶颈可能存在于接收器的I/O存储系统中。当例如I/O存储系统正对其他非MDT应用进行处理时，接收器的变慢的I/O存储系统写速率可能发生。在步骤4010中，确定接收器102的I/O存储系统写数据是否比从网络120接收数据快。可例如通过下述方式进行该确定:将接收器102的I/O存储系统从接收器102的内存缓冲区写数据的速率的计算与通过网络120将数据放入接收器102的内存缓冲区中的速率的计算相比较。如果确定接收器102的I/O存储系统写数据比从网络120接收数据快，则接收器102指示或建议发送器打开新连接(通过如图5所示的ACK机制)。在图40的步骤4010中，如果确定接收器102的I/O存储系统写数据不比从网络102接收数据快，则所述处理前进到步骤4013。在步骤4013中，接收器102确定将由发送器101发送的所有数据是否已被接收器102接收。如果所有数据已被接收器102接收，则所述处理结束(步骤4014)。如果并非所有数据已被接收器102接收，则所述处理前进到步骤 4004。在步骤4007中，发送器101检测大量数据传送的瓶颈是否存在于网络120中。如果在步骤4007中肯定地检测到大量数据传送的瓶颈存在于网络120中，则发送器101关闭发送器101与接收器102之间的现存连接。在网络中的大量数据传送的瓶颈由拥塞引起的情况下，可通过关闭现存的次要连接来减少网络的进一步拥塞。在步骤4007中，在当前的往返时间(RTT)比先前的RTT长时，肯定地检测到大量数据传送的瓶颈在网络中。当前的RTT和先前的RTT可以基于多于一个消息包的RTT，或者可以基于RTT的加权平均值。如果当前的RTT大大地长于先前的RTT (比如，+20%)，则网络可能忙并且具有来自其他发送器-接收器系统的更多流量。通过在网络忙时关闭现存连接，可减少由通过繁忙网络发送更多数据而引起的任何进一步拥塞。在例子中，加权测量的样本可能看起来如下:如果存在10个RTT顺序样本(诸如n0 至n9)，则加权RTT测量如下:第 1:n0、第 2: (η0*0.8+η1*0.2)、第 3:(第 2*0.8+η2*0.2)、第 4 (第 3*0.8+η3*0.2)、...、第 10: (η9*0.8+η9*0.2)。如果在步骤4007中，大量数据传送的瓶颈未被检测在网络120中，则所述处理前进到步骤4008。在步骤4008中，确定当前的往返时间(RTT)是否从先前的RTT大幅缩短。当前的RTT和先前的RTT可以基于多于一个消息包的RTT，或者可以基于RTT的加权平均值。如果在步骤4008中确定当前的RTT已从先前的RTT大幅缩短，则发送器101将用于打开新连接的请求发送到接收器102。缩短RTT表明网络的性能正在改进。因此，发送器101将想要打开一个或多个新连接来提高数据的吞吐量。在一些情况下，发送器101和接收器102处的缓冲区大小可根据网络中的瓶颈的检测或者根据接收器的I/o存储系统中的瓶颈的检测被调整。具体地讲，在这个示例性实施例中，发送器处的缓冲区的大小可增大以可防止缓冲区溢出数据。借助于前述示例性实施例，通常可提供自校准，在所述自校准中，发送器和接收器动态地增加和减少连接的数量，以便通过提供理想的吞吐量来改进大数据传送的性能。另夕卜，在大量的发送器-接收器布置上保持公平性。例如，如果当前瓶颈是接收器的系统1/0，使得当前数量的并行连接聚合了多余的网络带宽，则可关闭这些连接中的一些，以便释放带宽来供其他发送器-接收器系统使用。
在其他示例性实施例中，存在多个发送器，每个发送器将多个大量数据传送中的相应一个大量数据传送发送到接收器102。例如，如图1所示，发送器131和132中的每一个也可基本上与发送器101将大量数据传送发送到接收器102同时地将大量数据传送发送到接收器102。在这些示例性实施例中，当通过网络120建立发送器101与接收器102之间的多个连接时，接收器102基于其他发送器(例如，发送器131和132)请求的连接的数量来设置发送器101与接收器102之间可建立的连接的最多数量。例如，如果接收器102具有所有发送器可共享的最多20个连接，并且其他发送器当前正利用这20个连接中的15个连接，则接收器102可基于正被所述其他发送器使用的15个连接来设置在其上发送器101可用于传送数据的最多5个连接。在一些情况下，当通过网络120建立发送器101与接收器102之间的多个连接时，接收器102基于其他发送器请求的连接的数量来设置在其内可建立最多数量连接的时间段。另外，接收器102可基于其他发送器请求的连接的数量来设置用于建立可建立的最多数量连接中的每个连接的起始时间。例如，如果接收器102设置最多3个连接，则可在主要连接被建立之后的一分钟建立第一次要连接，并且第一次要连接可持续4分钟，以及可在主要连接被建立之后的两分钟建立第二次要连接，并且第二次要连接可持续2分钟。在一些情况下，作业队列由接收器102中所包括的调度管理器(即，图3中的调度管理器338)维护，与传入的被请求连接的数量相比，所述调度管理器管理所有多个发送器之间现存的当前连接的数量。另外，调度管理器将优先级分配给所述多个发送器中的每一个。就这一点而言，与将较少数量的连接分配给较低优先级的发送器相比，调度管理器将较多数量的连接分配给较高优先级的发送器。例如，与具有较小数据集合的较低优先级的发送器相比，较高优先级的发送器可以是具有较大数据集合的发送器。在这个例子中，具有较大数据集合的较高优先级的发送器将被分配比具有较小数据集合的较低优先级的发送器多的连接。另外，当发送器的I/O存储系统读数据比通过网络送出数据快时，发送器可将用于打开一个或多个连接的请求发送到接收器。当自动调节连接的数量时，如果被请求的一个或多个连接被调度管理器确定为可用，则接收器打开所述一个或多个连接。而且，在当前的往返时间(RTT)从先前的RTT大幅缩短时，发送器可将用于打开一个或多个连接的请求发送到接收器。当前的RTT和先前的RTT可以基于多于一个消息包的RTT，或者可以基于RTT的加权平均值。当自动调节连接的数量时，如果被请求的一个或多个连接被调度管理器确定为可用，则接收器打开所述一个或多个连接。就这一点而言，在调度管理器设置的时间段内打开和关闭连接。调度管理器设置的时间段可以是对于不同连接中的每一个不同的时间段。最后，连接中的每一个可在不同的起始时间被打开。当多个请求被接收器102从不同发送器接收时，每个发送器可以用受其处理能力约束的不同传送速率来发送数据。调度管理器338可基于发送器的数量和它接收的数据速率连同文件数据大小(该值可提前获得)来保持公平性和改进总系统吞吐量。如果新请求在现存数据传送请求的处理期间被接收，则接收器102可接受后来的请求，并返回对于第2请求建议的可加入会话的连接的数量(连同会话id —起)。如果接收器在对数据进行处理和将数据写到I/O存储系统的当中，则接收器可将建议的连接数量与等待时间值一起返回，当所述等待时间值到期时，加入会话请求将被兑现(honored)。同时，如果接收器知道第一请求中剩下的数据量远小于第二请求中要传送的数据量，则接收器可减少用于第一请求的连接数量并增加用于第二请求的允许的连接数量。并且，如果接收器知道第二请求中剩下的数据量远小于第一请求中要传送的数据量，则接收器102可减少用于第二请求的连接数量并增加用于第一请求的允许的连接数量。调度管理器338还可对请求施加优先级(B卩，具有较高优先级的新请求在另一请求的处理期间到达)。这可在消息级别上进行并与应用策略相联系，或者在传输数据级别上进行并与将被发送的数据相联系。本公开内容提供了关于具体的说明性实施例的详细描述。要理解的是，所附权利要求的范围不限于上述实施例，在不脱离权利要求的范围的情况下，相关领域的技术人员可进行各种改变和修改。本申请要求于2010年8月31日提交的美国申请N0.12/873，305的优先权，该申请特此通过引用并入本文。
权利要求
1.一种用于从发送器到通过网络与所述发送器连接的接收器的大量数据传送的方法，所述方法包括: 通过所述网络建立所述发送器与所述接收器之间的多个连接； 通过在所述多个连接上划分地发送数据来将数据从所述发送器发送到所述接收器，以便聚合所述网络的带宽的利用；和 通过下述方式来自动调节所述发送器与所述接收器之间的连接的最佳数量:当检测到大量数据传送的瓶颈存在于所述接收器的I/o存储系统中时，关闭现存连接，并且当所述接收器的I/o存储系统写数据比从所述网络接收数据快时，打开新连接。
2.根据权利要求1所述的方法，其中，所述I/O存储系统包括盘，并且其中，当自动调节连接的数量时，当在所述接收器的I/o存储系统上执行所述盘的查找操作时，肯定地检测到大量数据传送的瓶颈在所述接收器的I/o存储系统中。
3.根据权利要求1所述的方法，其中，所述I/O存储系统包括盘，并且其中，当自动调节连接的数量时，当所述接收器的I/o存储系统将数据写到盘比先前的I/O写速率慢时，肯定地检测到大量数据传送的瓶颈在所述接收器的I/o存储系统中。
4.根据权利要求1所述的方法，其中，自动调节还包括:在所述发送器检测到大量数据传送的瓶颈存在于所述网络中的情况下，所述发送器关闭所述发送器与所述接收器之间的现存连接，以便减少所述网络的进一步拥塞。
5.根据权利要求4所述的方法，其中，在当前的往返时间(RTT)比先前的RTT长时，肯定地检测到大量数据传送的瓶颈在所述网络中。
6.根据权利要求4所述的方法，还包括根据瓶颈在所述网络中的检测或者根据瓶颈在所述接收器的I/O存储系 统中的检测来调整所述发送器和所述接收器处的缓冲区大小。
7.根据权利要求1所述的方法，其中，在所述发送器检测到所述发送器处的缓冲区基本上满的情况下，所述发送器将用于打开新连接的请求发送到所述接收器，或者利用已经被创建但是当前未被用于发送数据的连接。
8.根据权利要求1所述的方法，其中，存在多个发送器，每个发送器将多个大量数据传送中的相应一个大量数据传送发送到所述接收器。
9.根据权利要求8所述的方法，其中，当通过所述网络建立所述发送器与所述接收器之间的多个连接时，所述接收器基于其他发送器请求的连接的数量来设置能够在所述发送器与所述接收器之间建立的连接的最多数量。
10.根据权利要求9所述的方法，其中，所述接收器基于其他发送器请求的连接的数量来设置在其内能够建立最多数量连接的时间段。
11.根据权利要求9所述的方法，其中，所述接收器基于其他发送器请求的连接的数量来设置用于建立能够被建立的最多数量的连接中的每个连接的起始时间。
12.根据权利要求8所述的方法，还包括维护作业队列，其中，所述作业队列由调度管理器维护，并且与传入的被请求连接的数量相比，管理所有的所述多个发送器之间存在的当前连接的数量。
13.根据权利要求12所述的方法，还包括将优先级分配给所述多个发送器中的每一个，其中，优先级由所述调度管理器分配，以便与将较少数量的连接分配给较低优先级的发送器相比，将较多数量的连接分配给较高优先级的发送器。
14.根据权利要求12所述的方法，其中，当所述发送器的I/O存储系统读数据比通过所述网络送出数据快时，所述发送器将用于打开一个或多个连接的请求发送到所述接收器，并且其中，当自动调节连接的数量时，如果被请求的一个或多个连接被所述调度管理器确定为可用，则所述接收器打开所述一个或多个连接。
15.根据权利要求1所述的方法，其中，当往返时间(RTT)已从先前的RTT缩短时，所述发送器将用于打开一个或多个连接的请求发送到所述接收器，并且其中，当自动调节连接的数量时，如果一个或多个连接被调度管理器确定为可用，则所述接收器打开被请求的一个或多个连接。
16.根据权利要求12所述的方法，其中，当自动调节连接的数量时，在所述调度管理器设置的时间段内打开和关闭所述连接。
17.根据权利要求16所述的方法，其中，所述调度管理器设置的时间段对于不同连接中的每一个是不同的时间段。
18.根据权利要求16所述的方法，其中，所述连接中的每一个在不同的起始时间被打 开。
19.一种用于从发送器到通过网络与所述发送器连接的接收器的大量数据传送的方法，所述方法包括: 通过所述网络建立所述发送器与所述接收器之间的多个连接； 通过在所述多个连接上划分地发送数据来将数据从所述发送器发送到所述接收器，以便聚合所述网络的带宽的利用；和 通过下述方式来自动调节所述发送器与所述接收器之间的连接的数量:当所述发送器的I/o存储系统读数据比通过所述网络送出数据快时，打开新连接，并且当所述发送器的I/o存储系统读数据比通过所述网络送出数据慢并且多于一个的发送器正将数据发送到所述接收器时，关闭现存连接。
20.根据权利要求19所述的方法，其中，自动调节还包括:在所述发送器检测到大量数据传送的瓶颈存在于所述网络中的情况下，关闭所述发送器与所述接收器之间的现存连接，以便减少所述网络中的进一步拥塞。
21.根据权利要求20所述的方法，其中，在当前的往返时间(RTT)比先前的RTT长时，肯定地检测到大量数据传送的瓶颈在所述网络中。
22.根据权利要求19所述的方法，其中，自动调节还包括:在所述发送器检测到大量数据传送的瓶颈存在于所述发送器的I/O存储系统中的情况下，关闭所述发送器与所述接收器之间的现存连接，并且其中，当所述发送器处的缓冲区基本上空时，肯定地检测到大量数据传送的瓶颈在所述发送器的I/O存储系统中。
23.根据权利要求19所述的方法，其中，自动调节还包括:当确定往返时间(RTT)已从先前的RTT缩短时，将用于打开新连接的请求发送到所述接收器。
24.一种接收器，包括: 计算机可读存储器，其被构造为存储计算机可执行处理步骤；和 处理器，其被构造为执行存储在所述存储器中的计算机可执行处理步骤， 其中，所述存储器中的处理步骤使所述处理器执行从发送器到通过网络与所述发送器连接的接收器的大量数据传送，并且其中，存储在所述存储器中的处理步骤包括执行如下的计算机可执行步骤: 通过所述网络建立所述发送器与所述接收器之间的多个连接； 通过在所述多个连接上划分地发送数据来将数据从所述发送器发送到所述接收器，以便聚合所述网络的带宽的利用；和 通过下述方式来自动调节所述发送器与所述接收器之间的连接的最佳数量:当检测到大量数据传送的瓶颈存在于所述接收器的I/o存储系统中时，关闭现存连接，并且当所述接收器的I/o存储系统写数据比从所述网络接收数据快时，打开新连接。
25.根据权利要求24所述的接收器，其中，所述I/O存储系统包括盘，并且其中，当自动调节连接的数量时，当在所述接收器的I/o存储系统上执行所述盘的查找操作时，肯定地检测到大量数据传送的瓶颈在所述接收器的I/o存储系统中。
26.根据权利要求24所述的接收器，其中，所述I/O存储系统包括盘，并且其中，当自动调节连接的数量时，当所述接收器的I/O存储系统将数据写到所述盘比先前的I/O写速率慢时，肯定地检测到大量数据传送的瓶颈在所述接收器的I/O存储系统中。
27.根据权利要求24所述的接收器，其中，自动调节还包括:在所述发送器检测到大量数据传送的瓶颈存在于所述网络中的情况下，所述发送器关闭所述发送器与所述接收器之间的现存连接，以便减少所述网络的进一步拥塞。
28.根据权利要求27所述的接收器，其中，在当前的往返时间(RTT)比先前的RTT长时，肯定地检测到大量数据传送的瓶颈在所述网络中。
29.根据权利要求27所述的接收器，其中，存储在所述存储器中的所述处理步骤还包括执行如下的计算机可执行步骤: 根据瓶颈在所述网 络中的检测或者根据瓶颈在所述接收器的I/O存储系统中的检测来调整所述发送器和所述接收器处的缓冲区大小。
30.根据权利要求24所述的接收器，其中，在所述发送器检测到所述发送器处的缓冲区基本上满的情况下，所述发送器将用于打开新连接的请求发送到所述接收器，或者利用已经被创建的但是当前未被用于发送数据的连接。
31.根据权利要求24所述的接收器，其中，存在多个发送器，每个发送器将多个大量数据传送中的相应一个大量数据传送发送到所述接收器。
32.根据权利要求31所述的接收器，其中，当通过所述网络建立所述发送器与所述接收器之间的多个连接时，所述接收器基于其他发送器请求的连接的数量来设置能够在所述发送器与所述接收器之间建立的连接的最多数量。
33.根据权利要求32所述的接收器，其中，所述接收器基于其他发送器请求的连接的数量来设置在其内能够建立最多数量连接的时间段。
34.根据权利要求32所述的接收器，其中，所述接收器基于其他发送器请求的连接的数量来设置用于建立能够被建立的最多数量的连接中的每个连接的起始时间。
35.根据权利要求31所述的接收器，其中，存储在所述存储器中的处理步骤还包括执行如下的计算机可执行步骤: 维护作业队列，其中，所述作业队列由调度管理器维护，并且与传入的被请求连接的数量相比，管理所有的所述多个发送器之间存在的当前连接的数量。
36.根据权利要求35所述的接收器，其中，存储在所述存储器中的处理步骤还包括执行如下的计算机可执行步骤: 将优先级分配给所述多个发送器中的每一个，其中，优先级由所述调度管理器分配，以便与将较少数量的连接分配给较低优先级的发送器相比，将较多数量的连接分配给较高优先级的发送器。
37.根据权利要求35所述的接收器，其中，当所述发送器的I/O存储系统读数据比通过所述网络送出数据快时，所述发送器将用于打开一个或多个连接的请求发送到所述接收器，并且其中，当自动调节连接的数量时，如果被请求的一个或多个连接被所述调度管理器确定为可用，则所述接收器打开所述一个或多个连接。
38.根据权利要求35所述的接收器，其中，当往返时间(RTT)已从先前的RTT缩短时，所述发送器将用于打开一个或多个连接的请求发送到所述接收器，并且其中，当自动调节连接的数量时，如果被请求的一个或多个连接被所述调度管理器确定为可用，则所述接收器打开所述一个或多个连接。
39.根据权利要求35所述的接收器，其中，当自动调节连接的数量时，在所述调度管理器设置的时间段内打开和关闭所述连接。
40.根据权利要求39所述的接收器，其中，所述调度管理器设置的时间段对于不同连接中的每一个是不同的时间段。
41.根据权利要求39所述的接收器，其中，所述连接中的每一个在不同的起始时间被打开。
42.一种发送器,包括: 计算机可读存储器，其被构造为存储计算机可执行处理步骤；和 处理器，其被构造为执行存储在所述存储器中的计算机可执行处理步骤， 其中，所述存储器中的处理步骤使所述处理器执行从发送器到通过网络与所述发送器连接的接收器的大量数据传送，并且其中，存储在所述存储器中的处理步骤包括执行如下的计算机可执行步骤: 通过所述网络建立所述发送器与所述接收器之间的多个连接； 通过在所述多个连接上划分地发送数据来将数据从所述发送器发送到所述接收器，以便聚合所述网络的带宽的利用；和 通过下述方式来自动调节所述发送器与所述接收器之间的连接的最佳数量:当所述发送器的I/O存储系统读数据比通过所述网络送出数据快时，打开新连接，并且当所述发送器的I/O存储系统读数据比通过所述网络送出数据慢并且多于一个的发送器正将数据发送到所述接收器时，关闭现存连接。
43.根据权利要求42所述的发送器，其中，自动调节还包括:在所述发送器检测到大量数据传送的瓶颈存在于所述网络中的情况下，关闭所述发送器与所述接收器之间的现存连接，以便减少所述网络中的进一步拥塞。
44.根据权利要求43所述的发送器，其中，在当前的往返时间(RTT)比先前的RTT长时，肯定地检测到大量数据传送的瓶颈在所述网络中。
45.根据权利要求42所述的发送器，其中，自动调节还包括:在所述发送器检测到大量数据传送的瓶颈存在于所述发送器的I/O存储系统中的情况下，关闭所述发送器与所述接收器之间的现存连接，并且其中，当所述发送器处的缓冲区基本上空时，肯定地检测到大量数据传送的瓶颈在所述发送器的I/o存储系统中。
46.根据权利要求42所述的发送器，其中，自动调节还包括:当确定往返时间(RTT)已从先前的RTT缩短时，将用于打开新连接的请求发送到所述接收器。
47.一种计算机可读存储介质，在所述计算机可读存储介质上，存储有用于使处理器执行从发送器到通过网络与所述发送器连接的接收器的大量数据传送的计算机可执行处理步骤，所述处理步骤包括: 通过所述网络建立所述发送器与所述接收器之间的多个连接； 通过在所述多个连接上划分地发送数据来将数据从所述发送器发送到所述接收器，以便聚合所述网络的带宽的利用；和 通过下述方式来自动调节所述发送器与所述接收器之间的连接的最佳数量:当检测到大量数据传送的瓶颈存在于所述接收器的I/O存储系统中时，关闭现存连接，并且当所述接收器的I/O存储系统写数据比从所述网络接收数据快时，打开新连接。
48.一种计算机可读存储介质，在所述计算机可读存储介质上，存储有用于使处理器执行从发送器到通过网络与所述发送器连接的接收器的大量数据传送的计算机可执行处理步骤，所述处理步骤包括: 通过所述网络建立所述发送器与所述接收器之间的多个连接； 通过在所述多个连接上划分地发送数据来将数据从所述发送器发送到所述接收器，以便聚合所述网络的带宽的利用；和 通过下述方式来自动调节所述发送器与所述接收器之间的连接的最佳数量:当所述发送器的I/O存储系统读数据比通过所述网络送出数据快时，打开新连接，并且当所述发送器的I/O存储系统读数据比通过所述`网络送出数据慢并且多于一个的发送器正将数据发送到所述接收器时，关闭现存连接。
全文摘要
本发明涉及在发送器和通过网络与发送器连接的接收器之间建立的多个连接上执行大量数据传送。通过在所述多个连接上划分地发送数据来将数据从发送器发送到接收器。通过下述方式来自动调节发送器与接收器之间的连接的最佳数量当大量数据传送的瓶颈存在于接收器的存储系统中时，关闭现存连接，并且当接收器写数据比从网络接收数据快时，打开新连接。通过下述方式来进一步自动调节连接的数量取决于发送器读数据比通过网络送出数据快还是慢，打开或关闭连接。
文档编号G06F15/16GK103109285SQ201180040917
公开日2013年5月15日 申请日期2011年8月17日 优先权日2010年8月31日
发明者Y·L·曹, C·M·玛查伽特, P·杰恩 申请人:佳能株式会社