"ネットワークを介して、送信機から当該送信機に接続された受信機への大量のデータ転送の方法であって、前記ネットワークを介して前記送信機と前記受信機との間に複数の接続を確立し、前記ネットワークの帯域幅の利用を集約するように前記複数の接続を介してデータを分割して送出することで前記送信機から前記受信機に前記データを送出し、大量のデータ転送に対するボトルネックが前記受信機のI/Oストレージシステムに存在することを検出した時に既存の接続を閉じ、且つ前記ネットワークからデータを受信するよりも速く前記受信機の前記I/Oストレージシステムがデータを書き込んでいる時に新しい接続を開くことにより、前記送信機と前記受信機との間の最適な数の接続をオートチューニングすることを特徴とする方法。前記I/Oストレージシステムはディスクを含み、接続の数をオートチューニングする場合、前記ディスクのシーク動作が前記受信機の前記I/Oストレージシステムに対して実行される時に前記受信機の前記I/Oストレージシステムにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項1に記載の方法。前記I/Oストレージシステムはディスクを含み、接続の数をオートチューニングする場合、前記受信機のI/Oストレージシステムが前のI/O書き込み速度よりも遅くデータを前記ディスクに書き込んでいる時に前記受信機の前記I/Oストレージシステムにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項1に記載の方法。オートチューニングすることは、前記ネットワークの更なる輻輳を減少するように、大量のデータ転送に対するボトルネックが前記ネットワークに存在することを前記送信機が検出する場合に前記送信機と前記受信機との間の既存の接続を前記送信機により閉じることを更に含むことを特徴とする請求項1に記載の方法。現在のラウンドトリップ時間RTTが前のRTTよりも長い場合、前記ネットワークにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項4に記載の方法。前記ネットワークにおけるボトルネックの検出又は前記受信機の前記I/Oストレージシステムにおけるボトルネックの検出に従って、前記送信機及び前記受信機におけるバッファサイズ調整することを更に備えることを特徴とする請求項4に記載の方法。前記送信機は、前記送信機におけるバッファがほぼ満杯であることを検出する場合、新しい接続を開くための要求を前記受信機に送出するか、あるいは既に作成されているが現在データを送出するために使用されていない接続を利用することを特徴とする請求項1に記載の方法。各々が複数の大量のデータ転送のうちのそれぞれ1つを前記受信機に送出する複数の送信機が存在することを特徴とする請求項1に記載の方法。前記ネットワークを介して前記送信機と前記受信機との間に複数の接続を確立する場合、前記受信機は、前記他の送信機から要求された接続の数に基づいて前記送信機と前記受信機との間に確立されうる最大数の接続を設定することを特徴とする請求項8に記載の方法。前記受信機は、前記他の送信機から要求された接続の数に基づいて前記最大数の接続が確立されうる期間を設定することを特徴とする請求項9に記載の方法。前記受信機は、前記他の送信機から要求された接続の数に基づいて確立されうる前記最大数の接続のうちの各接続を確立するための開始時間を設定することを特徴とする請求項9に記載の方法。要求された接続の入力数と比較して、スケジュールマネージャにより維持され且つ全ての前記複数の送信機間に存在する現在の接続の数を管理するジョブキューを維持することを更に備えることを特徴とする請求項8に記載の方法。前記複数の送信機の各々に優先度を割り当てることを更に備え、優先度は、より少ない数の接続をより優先度の低い送信機に割り当てることと比較して、より多くの数の接続をより優先度の高い送信機に割り当てるように前記スケジュールマネージャにより割り当てられることを特徴とする請求項12に記載の方法。前記送信機は、データが前記ネットワークを介して送出されているよりも速く前記送信機のI/Oストレージシステムがデータを読み出している時に1つ以上の接続を開くための要求を前記受信機に送出し、接続の数をオートチューニングする場合、前記受信機は、前記1つ以上の接続が前記スケジュールマネージャにより使用可能であると判定される場合に前記要求された1つ以上の接続を開くことを特徴とする請求項12に記載の方法。前記送信機は、ラウンドトリップ時間RTTが前のRTTから実質的に短縮されている時に1つ以上の接続を開くための要求を前記受信機に送出し、接続の数をオートチューニングする場合、前記受信機は、1つ以上の接続がスケジュールマネージャにより使用可能であると判定される場合に前記要求された1つ以上の接続を開くことを特徴とする請求項1に記載の方法。接続の数をオートチューニングする場合、前記接続は、前記スケジュールマネージャにより設定された期間の間開かれ且つ閉じられることを特徴とする請求項12に記載の方法。前記スケジュールマネージャにより設定された前記期間は、前記種々の接続毎に異なる期間であることを特徴とする請求項16に記載の方法。前記各接続は異なる開始時間において開かれることを特徴とする請求項16に記載の方法。ネットワークを介した送信機から前記送信機に接続された受信機への大量のデータ転送の方法であって、前記ネットワークを介して前記送信機と前記受信機との間に複数の接続を確立することと、前記ネットワークの帯域幅の利用を集約するように前記複数の接続を介してデータを分割して送出することで前記送信機から前記受信機に前記データを送出することと、データが前記ネットワークを介して送出されているよりも速く前記送信機のI/Oストレージシステムがデータを読み出している時に新しい接続を開き、且つデータが前記ネットワークを介して送出されているよりも遅く前記送信機の前記I/Oストレージシステムがデータを読み出しており且つ2つ以上の送信機がデータを前記受信機に送出している時に既存の接続を閉じることにより、前記送信機と前記受信機との間の接続の数をオートチューニングすることと、を備えることを特徴とする方法。オートチューニングすることは、前記ネットワークにおける更なる輻輳を減少するように、大量のデータ転送に対するボトルネックが前記ネットワークに存在することを前記送信機が検出する場合に前記送信機と前記受信機との間の既存の接続を閉じることを更に含むことを特徴とする請求項19に記載の方法。現在のラウンドトリップ時間RTTが前のRTTよりも長い場合、前記ネットワークにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項20に記載の方法。オートチューニングすることは、大量のデータ転送に対するボトルネックが前記送信機の前記I/Oストレージシステムに存在することを前記送信機が検出する場合に前記送信機と前記受信機との間の既存の二次接続を閉じることを更に含み、前記送信機におけるバッファがほぼ空である場合、前記送信機の前記I/Oストレージシステムにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項19に記載の方法。オートチューニングすることは、ラウンドトリップ時間RTTが前のRTTから短縮されていると判定される場合に新しい接続を開くための要求を前記受信機に送出することを更に含むことを特徴とする請求項19に記載の方法。コンピュータが実行可能な処理ステップを格納するように構成されたコンピュータ可読メモリと、前記メモリに格納された前記コンピュータが実行可能な処理ステップを実行するように構成されたプロセッサとを備える受信機であって、前記メモリの前記処理ステップは、ネットワークを介した送信機から前記送信機に接続された受信機への大量のデータ転送を前記プロセッサに実行させ、前記ネットワークを介して前記送信機と前記受信機との間に複数の接続を確立するコンピュータが実行可能なステップと、前記ネットワークの帯域幅の利用を集約するように前記複数の接続を介してデータを分割して送出することで前記送信機から前記受信機に前記データを送出するコンピュータが実行可能なステップと、大量のデータ転送に対するボトルネックが前記受信機のI/Oストレージシステムに存在することを検出した時に既存の接続を閉じ、且つ前記ネットワークからデータを受信するよりも速く前記受信機の前記I/Oストレージシステムがデータを書き込んでいる時に新しい接続を開くことにより、前記送信機と前記受信機との間の最適な数の接続をオートチューニングするコンピュータが実行可能なステップとを含むことを特徴とする受信機。前記I/Oストレージシステムはディスクを含み、接続の数をオートチューニングする場合、前記ディスクのシーク動作が前記受信機の前記I/Oストレージシステムに対して実行される時に前記受信機の前記I/Oストレージシステムにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項24に記載の受信機。前記I/Oストレージシステムはディスクを含み、接続の数をオートチューニングする場合、前記受信機のI/Oストレージシステムが前のI/O書き込み速度よりも遅くデータを前記ディスクに書き込んでいる時に前記受信機の前記I/Oストレージシステムにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項24に記載の受信機。オートチューニングすることは、前記ネットワークの更なる輻輳を減少するように、大量のデータ転送に対するボトルネックが前記ネットワークに存在することを前記送信機が検出する場合に前記送信機と前記受信機との間の既存の接続を前記送信機により閉じることを更に含むことを特徴とする請求項24に記載の受信機。現在のラウンドトリップ時間RTTが前のRTTよりも長い場合、前記ネットワークにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項27に記載の受信機。前記メモリに格納された前記処理ステップは、前記ネットワークにおけるボトルネックの検出又は前記受信機の前記I/Oストレージシステムにおけるボトルネックの検出に従って、前記送信機及び前記受信機におけるバッファサイズ調整するコンピュータが実行可能なステップを更に含むことを特徴とする請求項27に記載の受信機。前記送信機は、前記送信機におけるバッファがほぼ満杯であることを検出する場合、新しい接続を開くための要求を前記受信機に送出するか、あるいは既に作成されているが現在データを送出するために使用されていない接続を利用することを特徴とする請求項24に記載の受信機。各々が複数の大量のデータ転送のうちのそれぞれ1つを前記受信機に送出する複数の送信機が存在することを特徴とする請求項24に記載の受信機。前記ネットワークを介して前記送信機と前記受信機との間に複数の接続を確立する場合、前記受信機は、前記他の送信機から要求された接続の数に基づいて前記送信機と前記受信機との間に確立されうる最大数の接続を設定することを特徴とする請求項31に記載の受信機。前記受信機は、前記他の送信機から要求された接続の数に基づいて前記最大数の接続が確立されうる期間を設定することを特徴とする請求項32に記載の受信機。前記受信機は、前記他の送信機から要求された接続の数に基づいて確立されうる前記最大数の接続のうちの各接続を確立するための開始時間を設定することを特徴とする請求項32に記載の受信機。前記メモリに格納された前記処理ステップは、要求された接続の入力数と比較して、スケジュールマネージャにより維持され且つ全ての前記複数の送信機間に存在する現在の接続の数を管理するジョブキューを維持するコンピュータが実行可能なステップを更に含むことを特徴とする請求項31に記載の受信機。前記メモリに格納された前記処理ステップは、前記複数の送信機の各々に優先度を割り当てるコンピュータが実行可能なステップを更に含み、優先度は、より少ない数の接続をより優先度の低い送信機に割り当てることと比較して、より多くの数の接続をより優先度の高い送信機に割り当てるように前記スケジュールマネージャにより割り当てられることを特徴とする請求項35に記載の受信機。前記送信機は、データが前記ネットワークを介して送出されているよりも速く前記送信機のI/Oストレージシステムがデータを読み出している時に1つ以上の接続を開くための要求を前記受信機に送出し、接続の数をオートチューニングする場合、前記受信機は、前記1つ以上の接続が前記スケジュールマネージャにより使用可能であると判定される場合に前記要求された1つ以上の接続を開くことを特徴とする請求項35に記載の受信機。前記送信機は、ラウンドトリップ時間RTTが前のRTTから実質的に短縮されている時に1つ以上の接続を開くための要求を前記受信機に送出し、接続の数をオートチューニングする場合、前記受信機は、1つ以上の接続が前記スケジュールマネージャにより使用可能であると判定される場合に前記要求された1つ以上の接続を開くことを特徴とする請求項35に記載の受信機。接続の数をオートチューニングする場合、前記接続は、前記スケジュールマネージャにより設定された期間の間開かれ且つ閉じられることを特徴とする請求項35に記載の受信機。前記スケジュールマネージャにより設定された前記期間は、前記種々の接続毎に異なる期間であることを特徴とする請求項39に記載の受信機。前記各接続は異なる開始時間において開かれることを特徴とする請求項39に記載の受信機。コンピュータが実行可能な処理ステップを格納するように構成されたコンピュータ可読メモリと、前記メモリに格納された前記コンピュータが実行可能な処理ステップを実行するように構成されたプロセッサとを備える送信機であって、前記メモリの前記処理ステップは、ネットワークを介した送信機から前記送信機に接続された受信機への大量のデータ転送を前記プロセッサに実行させ、前記ネットワークを介して前記送信機と前記受信機との間に複数の接続を確立するコンピュータが実行可能なステップと、前記ネットワークの帯域幅の利用を集約するように前記複数の接続を介してデータを分割して送出することで前記送信機から前記受信機に前記データを送出するコンピュータが実行可能なステップと、データが前記ネットワークを介して送出されているよりも速く前記送信機のI/Oストレージシステムがデータを読み出している時に新しい接続を開き、且つデータが前記ネットワークを介して送出されているよりも遅く前記送信機の前記I/Oストレージシステムがデータを読み出しており且つ2つ以上の送信機がデータを前記受信機に送出している時に既存の接続を閉じることにより、前記送信機と前記受信機との間の最適な数の接続をオートチューニングするコンピュータが実行可能なステップとを含むことを特徴とする送信機。オートチューニングすることは、前記ネットワークの更なる輻輳を減少するように、大量のデータ転送に対するボトルネックが前記ネットワークに存在することを前記送信機が検出する場合に前記送信機と前記受信機との間の既存の接続を閉じることを更に含むことを特徴とする請求項42記載の送信機。現在のラウンドトリップ時間RTTが前のRTTよりも長い場合、前記ネットワークにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項43記載の送信機。オートチューニングすることは、大量のデータ転送に対するボトルネックが前記送信機の前記I/Oストレージシステムに存在することを前記送信機が検出する場合に前記送信機と前記受信機との間の既存の接続を閉じることを更に含み、前記送信機におけるバッファがほぼ空である場合、前記送信機の前記I/Oストレージシステムにおける大量のデータ転送に対するボトルネックありと検出することを特徴とする請求項42記載の送信機。オートチューニングすることは、ラウンドトリップ時間RTTが前のRTTから短縮されていると判定される場合に新しい接続を開くための要求を前記受信機に送出することを更に含むことを特徴とする請求項42記載の送信機。ネットワークを介した送信機から前記送信機に接続された受信機への大量のデータ転送をプロセッサに実行させるコンピュータが実行可能な処理ステップを格納するコンピュータ可読記憶媒体であって、前記処理ステップは、前記ネットワークを介して前記送信機と前記受信機との間に複数の接続を確立することと、前記ネットワークの帯域幅の利用を集約するように前記複数の接続を介してデータを分割して送出することで前記送信機から前記受信機に前記データを送出することと、大量のデータ転送に対するボトルネックが前記受信機のI/Oストレージシステムに存在することを検出した時に既存の接続を閉じ、且つ前記ネットワークからデータを受信するよりも速く前記受信機の前記I/Oストレージシステムがデータを書き込んでいる時に新しい接続を開くことにより、前記送信機と前記受信機との間の最適な数の接続をオートチューニングすることとを含むことを特徴とするコンピュータ可読記憶媒体。ネットワークを介した送信機から前記送信機に接続された受信機への大量のデータ転送をプロセッサに実行させるコンピュータが実行可能な処理ステップを格納するコンピュータ可読記憶媒体であって、前記処理ステップは、前記ネットワークを介して前記送信機と前記受信機との間に複数の接続を確立することと、前記ネットワークの帯域幅の利用を集約するように前記複数の接続を介してデータを分割して送出することで前記送信機から前記受信機に前記データを送出することと、データが前記ネットワークを介して送出されているよりも速く前記送信機のI/Oストレージシステムがデータを読み出している時に新しい接続を開き、且つデータが前記ネットワークを介して送出されているよりも遅く前記送信機の前記I/Oストレージシステムがデータを読み出しており且つ2つ以上の送信機がデータを前記受信機に送出している時に既存の接続を閉じることにより、前記送信機と前記受信機との間の最適な数の接続をオートチューニングすることとを含むことを特徴とするコンピュータ可読記憶媒体。帯域幅の集約に関する1つの問題は、使用可能にされた帯域幅の量が非常に多いためにデータを格納する受信機の能力又は送信のためにデータを検索する送信機の能力を上回ることである。そのようなデータ転送において、送信機から受信機へのデータ転送のボトルネック障害は、使用可能なネットワーク帯域幅の不足によりもたらされるものではないだろう。特に、余剰の使用可能な帯域幅がある状況において、データ転送のボトルネックは、実際にはデータをディスクに読み込み且つ書き込む物理的I/Oである。I/Oストレージシステムの帯域幅がボトルネックである場合、多数の並列接続を使用して帯域幅を集約するシステムは、自身が使用できるより多くの使用可能なネットワークソケットを独占する。そのような構成は、同一の通信ネットワークを介して動作する他の送信機/受信機システムに対して不公平である。本発明において、I/Oストレージシステムの性能に基づいて、ネットワークを介した送信機と送信機に接続された受信機との間の接続の数をオートチューニングすることで上述の問題に対処する。接続の数は、2つのシステム間の最適な数の接続を確立するように接続を開き且つ/あるいは閉じることでオートチューニングされる。オートチューニングは、特に、大量のデータ転送に対するボトルネックが受信機のI/Oストレージシステムに存在することを受信機が検出した時に既存の接続を閉じ、且つネットワークからデータを受信するよりも速く受信機のI/Oストレージシステムがデータを書き込んでいる時に新しい接続を開くことで実行可能となる。また、送信機と受信機との間の接続の数は、データがネットワークを介して送出されているよりも速く送信機のI/Oストレージシステムがデータを読み出している時に新しい接続を開き、且つデータがネットワークを介して送出されているよりも遅く送信機のI/Oストレージシステムがデータを読み出しており且つ2つ以上の送信機がデータを受信機に送出している時に既存の接続を閉じることでオートチューニングされる。従って、本明細書で説明する一実施形態の例において、複数の接続は、ネットワークを介して送信機と受信機との間で確立される。複数の接続は、複数のTCP接続等であってもよい。データは、ネットワークの帯域幅の利用を集約するように複数の接続を介してデータを分割して送出することで送信機から受信機に送出される。送信機と受信機との間の最適な数の接続は、大量のデータ転送に対するボトルネックが受信機のI/Oストレージシステムに存在することを受信機が検出した時に既存の接続を閉じることでオートチューニングされる。この点に関して、既存の接続を閉じることは、一次接続ではなく二次接続を閉じることである。接続の数は、ネットワークからデータを受信するよりも速く受信機のI/Oストレージシステムがデータを書き込んでいる時に新しい接続を開くことで更にオートチューニングされる。また、送信機と受信機との間の接続の数は、データがネットワークを介して送出されているよりも速く送信機のI/Oストレージシステムがデータを読み出している時に新しい接続を開くことでオートチューニングされる。接続の数は、データがネットワークを介して送出されているよりも遅く送信機のI/Oストレージシステムがデータを読み出しており且つ2つ以上の送信機がデータを受信機に送出している時に既存の接続を閉じることで更にオートチューニングされる。上述の構成により、通常、送信機及び受信機が理想的なスループットを提供することで大量のデータ転送に対する性能を向上するように接続の数を動的に増減する自己校正を提供することが可能である。また、多数の送信機/受信機構成にわたり公平性が保たれる。例えば、現在の並列接続の数が余剰のネットワーク帯域幅を集約しているために現在のボトルネックが受信機のシステムI/Oである場合、接続のうちのいくつかは、他の送信機/受信機システムが使用するための帯域幅をリリースするように閉じられる。本明細書で更に説明する一実施形態の例において、受信機のI/Oストレージシステムはディスクを含む。本実施形態の例において、接続の数をオートチューニングする場合、ディスクのシーク動作が受信機のI/Oストレージシステムに対して実行される時に受信機のI/Oストレージシステムにおける大量のデータ転送に対するボトルネックありと検出する。より具体的には、複数の接続が使用されているため、データは、受信機において順番に到着しなくてもよい。受信機が次の連続データチャンクを待って時間切れになる場合、受信機のI/Oストレージシステムは、更なるシーク動作を必要とする可能性のある故障データに対するディスク書き込みを実行してもよい。一般にこれは、受信機のI/Oストレージシステムがデータをディスクに書き込んでいるよりも速くデータが送信機から受信機に転送されていることを意味する。従って、ボトルネックは、受信機のI/Oストレージシステムに存在するだろう。本明細書で説明する更なる一実施形態の例において、受信機のI/Oストレージシステムはディスクを含む。更なる本実施形態の例において、接続の数をオートチューニングする場合、受信機のI/Oストレージシステムが前のI/O書き込み速度よりも遅くデータをディスクに書き込んでいる時に受信機のI/Oストレージシステムにおける大量のデータ転送に対するボトルネックありと検出する。前のI/O書き込み速度は、2回以上の書き込み動作に対して前に測定されたI/O書き込み速度又は書き込み動作の期間中に前に測定されたI/O書き込み速度、あるいは書き込み動作の前に測定されたI/O書き込み速度の加重平均に基づいてよい。例えば、受信機のI/Oストレージシステムの前のI/O書き込み速度が10Mb/sであり、且つ受信機のI/Oストレージシステムが現在5Mb/sでデータを書き込んでいる場合、ボトルネックは、受信機のI/Oストレージシステムに存在するだろう。例えば受信機のI/Oストレージシステムが他の非MDTアプリケーションを処理している場合、I/Oストレージシステムの書き込み速度は低下するだろう。本明細書で説明する別の実施形態の例において、接続の数をオートチューニングすることは、大量のデータ転送に対するボトルネックがネットワークに存在することを送信機が検出する場合に送信機と受信機との間の既存の接続を送信機により閉じることを更に含む。その結果、ネットワークの更なる輻輳を減少できる。本実施形態の例において、現在のラウンドトリップ時間RTTが前のRTTよりも長い場合、ネットワークにおける大量のデータ転送に対するボトルネックありと検出する。現在のRTT及び前のRTTは、2つ以上のメッセージパッケージに対するRTT又はRTTの加重平均に基づいてよい。現在のRTTが実質的に前のRTTよりも長い場合、ネットワークは、使用中であり且つ他の送信機/受信機システムからのより多くのトラフィックを有するだろう。ネットワークが使用中である場合に既存の接続を閉じることにより、使用中のネットワークを介して更に多くのデータを送出することで発生するこれ以上の輻輳を減少してもよい。本明細書で説明する更なる一実施形態の例において、接続の数をオートチューニングすることは、大量のデータ転送に対するボトルネックが送信機のI/Oストレージシステムに存在することを送信機が検出する場合に送信機と受信機との間の既存の接続を閉じることを更に含む。送信機におけるバッファがほぼ空である場合、送信機のI/Oストレージシステムにおける大量のデータ転送に対するボトルネックありと検出する。本明細書で説明する更なる一実施形態の例において、送信機は、送信機におけるバッファがほぼ満杯であることを検出する場合、新しい接続を開くための要求を受信機に送出するか、あるいは既に作成されているが現在データを送出するために使用されていない接続を利用する。送信機におけるバッファがほぼ満杯である場合に新しい接続を開くことは、送信機からデータを送出する際の遅延又は間隔を減少できるために全体的に平滑なデータ転送を提供するという有利な影響を及ぼす。いくつかの状況において、送信機及び受信機におけるバッファサイズは、ネットワークにおけるボトルネックの検出又は受信機のI/Oストレージシステムにおけるボトルネックの検出に従って調整されうる。特に、本実施形態の例において、送信機におけるバッファのサイズは、バッファにデータが溢れるのを回避できるように拡大されてよい。本明細書で説明する別の実施形態の例によれば、各々が複数の大量のデータ転送のうちのそれぞれ1つを受信機に送出している複数の送信機が存在する。本実施形態の例において、ネットワークを介して送信機と受信機との間に複数の接続を確立する場合、受信機は、他の送信機から要求された接続の数に基づいて送信機と受信機との間に確立されうる最大数の接続を設定する。例えば、全ての送信機が共有できる最大20個の接続を受信機が有し、且つ他の送信機が現在20個の接続のうちの15個を利用している場合、受信機は、送信機が他の送信機により使用されている15個の接続に基づいてデータを転送するために使用してもよい最大5個の接続を設定してもよい。更に本実施形態の例において、受信機は、他の送信機から要求された接続の数に基づいて最大数の接続が確立されうる期間を設定する。更に受信機は、他の送信機から要求された接続の数に基づいて確立されうる最大数の接続のうちの各接続を確立するための開始時間を設定する。例えば、最大3個の接続が受信機により設定される場合、第1の二次接続は、一次接続が確立された1分後に確立され且つ4分間続いてもよく、第2の二次接続は、一次接続が確立された2分後に確立され且つ2分間続いてもよい。本明細書で説明する更なる一実施形態の例において、ジョブキューは、要求された接続の入力数と比較して、全ての複数の送信機間に存在する現在の接続の数を管理するスケジュールマネージャにより維持される。更にスケジュールマネージャは、複数の送信機の各々に優先度を割り当てる。この点に関して、スケジュールマネージャは、より少ない数の接続をより優先度の低い送信機に割り当てることと比較して、より多くの数の接続をより優先度の高い送信機に割り当てる。本明細書で説明する別の実施形態の例によれば、送信機は、データがネットワークを介して送出されているよりも速く送信機のI/Oストレージシステムがデータを読み出している時に1つ以上の接続を開くための要求を受信機に送出する。接続の数をオートチューニングする場合、受信機は、1つ以上の接続がスケジュールマネージャにより使用可能であると判定される場合に要求された1つ以上の接続を開く。本明細書で説明する更なる一実施形態の例によれば、送信機は、現在のラウンドトリップ時間RTTが前のRTTから実質的に短縮されている時に1つ以上の接続を開くための要求を受信機に送出する。現在のRTT及び前のRTTは、2つ以上のメッセージパッケージに対するRTT又はRTTの加重平均に基づいてよい。接続の数をオートチューニングする場合、受信機は、1つ以上の接続がスケジュールマネージャにより使用可能であると判定される場合に要求された1つ以上の接続を開く。この簡単な発明の概要は、本発明の特性を迅速に理解できるように提供されている。以下の詳細な説明及び添付の図面を参照することにより、より完全に理解される。図1は、一実施形態の例のアーキテクチャが実現されてもよいネットワークを介して接続された複数の送信機及び受信機を示す図である。図1に示されるように、送信機101、131及び132は、ネットワーク120を介して受信機102に接続される。より具体的には、送信機101は、ネットワークインタフェース111を介してネットワーク120に接続され、送信機131は、ネットワークインタフェース112を介してネットワーク120に接続され、送信機132は、ネットワークインタフェース113を介してネットワーク120に接続され、受信機102は、ネットワークインタフェース114を介してネットワーク120に接続される。図1において、送信機101、131及び132は、1つのネットワークを介して接続するように示されるが、他の実施形態の例において、送信機101、131及び132、並びに受信機102は、2つ以上のネットワークを介して接続されてよい。また、ネットワーク120又は多数のネットワークに接続された3つを上回るかあるいは下回る送信機及び2つ以上の受信機が存在してもよい。ネットワーク120は、イントラネットであるが、他の実施形態の例において、インターネット又はデータを転送する他のあらゆる適切な種類のネットワークであってよい。送信機101、131及び132は、ネットワークを介して大量のデータ転送を実行できるデバイスである。しかし、送信機101、131及び132は、データを送出することに限定されず、転送されたデータを受信できるデバイスであってもよい。例えば送信機101、131及び132は、コンピュータ又はネットワークを介して大量のデータ転送を実行できる他のあらゆるデバイスであってよい。更に送信機101、131及び132は、クライアント/サーバシステムにおけるクライアントデバイス又はピアツーピアシステムにおけるピアデバイスであってもよい。受信機102は、ネットワークを介して大量のデータ転送を送受信できるデバイスである。例えば受信機102は、コンピュータ又はネットワークを介して大量のデータ転送を実行できる他のあらゆるデバイスであってよい。更に受信機102は、クライアント/サーバシステムにおけるサーバデバイス又はピアツーピアシステムにおけるピアデバイスであってもよい。ネットワークインタフェース111~114は、有線又は無線の物理インタフェースであってよい。ネットワークインタフェース111~114の各々は、ネットワーク120との1つ以上のソケット接続を確立するように1つ以上のポートを含む。図2は、図1の送信機101、131及び132の各々の内部アーキテクチャを説明する詳細なブロック図である。図2に示されるように、送信機101、131及び132の各々は、コンピュータバス200とインタフェースする中央処理装置CPU202を備えてもよい。また、コンピュータバス200とインタフェースするものには、ハード又は固定ディスク220、ネットワークインタフェース111、112又は113、メインランタイム一時メモリとして使用するためのランダムアクセスメモリRAM208及び読み出し専用メモリROM210がある。RAM208は、オペレーティングシステム、アプリケーションプログラム及びインタフェースドライバ等のソフトウェアプログラムにおける命令の実行中にRAM208に格納された情報をCPU202に提供するようにコンピュータバス200とインタフェースする。より具体的には、最初にCPU202は、固定ディスク220からコンピュータが実行可能な処理ステップをロードするか、あるいは別の記憶装置をRAM208の領域にロードする。次にCPU202は、ロードされたコンピュータが実行可能な処理ステップを実行するためにRAM208から格納された処理ステップを実行してよい。また、収集されたネットワーク性能の統計又は他の情報等のデータは、コンピュータが実行可能なソフトウェアプログラムがデータにアクセスし且つ/あるいはデータを修正する必要がある程度まで、そのようなソフトウェアプログラムの実行中にCPU202がアクセスできるようにRAM208に格納されてよい。図2に更に示されるように、ハードディスク220は、オペレーティングシステム228、送信機101、131又は132を起動及び停止するプログラム、あるいは他のプログラム等のアプリケーションプログラム230を含む。ハードディスク220は、ネットワーク120等のネットワークに対するソフトウェアインタフェース用のネットワークドライバ232を更に含む。ハードディスク220は、送信機からのデータの送出を制御するストリーミングソフトウェア234を更に含む。最後にハードディスク220は、送信機101と受信機102との間の接続の数を制御するオートチューニングソフトウェア236を含む。図40に関連して、オートチューニングソフトウェア236を以下に更に詳細に説明する。一実施形態の例において、ストリーミングソフトウェア234及びオートチューニングソフトウェア236は、CPU202によりRAM208の領域にロードされる。次にCPU202は、ロードされたコンピュータが実行可能なステップを実行するためにRAM208から格納されたストリーミングソフトウェア234及びオートチューニングソフトウェア236を実行する。更にアプリケーションプログラム230は、CPU202によりRAM208の領域にロードされる。次にCPU202は、ロードされたコンピュータが実行可能なステップを実行するために、図40に関連して以下に詳細に説明されるような格納された処理ステップを実行する。図3は、図1の受信機102の内部アーキテクチャを説明する詳細なブロック図である。図3に示されるように、受信機102は、コンピュータバス300とインタフェースする中央処理装置CPU302を備える。また、コンピュータバス300とインタフェースするものには、ハード又は固定ディスク320、ネットワークインタフェース114、メインランタイム一時メモリとして使用するためのランダムアクセスメモリRAM308及び読み出し専用メモリROM310がある。RAM308は、オペレーティングシステム、アプリケーションプログラム及びインタフェースドライバ等のソフトウェアプログラムにおける命令の実行中にRAM308に格納された情報をCPU302に提供するようにコンピュータバス300とインタフェースする。より具体的には、最初にCPU302は、固定ディスク320からコンピュータが実行可能な処理ステップをロードするか、あるいは別の記憶装置をRAM308の領域にロードする。次にCPU302は、ロードされたコンピュータが実行可能な処理ステップを実行するためにRAM308から格納された処理ステップを実行してよい。また、収集されたネットワーク性能の統計又は他の情報等のデータは、コンピュータが実行可能なソフトウェアプログラムがデータにアクセスし且つ/あるいはデータを修正する必要がある程度まで、そのようなソフトウェアプログラムの実行中にCPU302がアクセスできるようにRAM308に格納されてよい。図3に更に示されるように、ハードディスク320は、オペレーティングシステム328、受信機102を起動及び停止するプログラム、あるいは他のプログラム等のアプリケーションプログラム330を含む。ハードディスク320は、ネットワーク120等のネットワークに対するソフトウェアインタフェース用のネットワークドライバ332を更に含む。ハードディスク320は、受信機102によるデータの受信を制御するストリーミングソフトウェア334を更に含む。更にハードディスク320は、送信機101と受信機102との間の接続に対する種々のパラメータをスケジュールするスケジュールマネージャ338を含む。図40に関連して、スケジュールマネージャ338を以下に更に詳細に説明する。最後にハードディスク320は、送信機101と受信機102との間の接続の数を制御するオートチューニングソフトウェア336を含む。図40に関連して、オートチューニングソフトウェア336を以下に更に詳細に説明する。スケジュールマネージャ338は多くの役割を担える。例えばスケジュールマネージャ338は、種々のデータ転送ジョブ/セッションに割り当てられた優先度を追跡する役割を担える。更にスケジュールマネージャ338は、データ転送セッションが開くことができる接続の数を管理する役割を担える。特にスケジュールマネージャ338は、所定のデータ転送に対して送信機と受信機との間の現在の接続の数を追跡するようにジョブキューを維持する。また、スケジュールマネージャ338は、所定の数の接続が送信機と受信機との間で開かれてよい開始時間を規定する役割を担える。最後にスケジュールマネージャ338は、所定の数の接続が開始され且つ開き続けられる期間又は持続期間を規定し、且つその期間が経過した後で接続を終了する役割を担える。図40に関連して、これらの役割を以下に更に詳細に説明する。上述の役割を担う場合、スケジュールマネージャ338は、各役割内である特定の判断を行うためにユーザ定義優先度及びシステムロード定義優先度等のある特定の基準を使用する。ユーザ定義優先度の一例は、支払いの少ない顧客よりも支払いの多い顧客のデータ転送に優先権を与えることである。システムロード定義優先度のいくつかの例は、データ転送、利用が不十分にならないような帯域幅及びシステムリソースの十分な利用、公平な負荷分散方式ユーザがデータ転送のためにこの方式を使用したい場合の全てを中断しないようにシステムを十分にロードしたままにすること、並びにそれらより長期のデータ転送を好むこと、あるいは短期のデータ転送が最初に転送を実行して長期のデータ転送が完了するのを待つことなく終了するようにより多くの接続を短期のデータ転送に与えることを含む。スケジュールマネージャ338が上述の役割を担うのを容易にするために、以下の情報、すなわち所定の送信機と受信機との間の使用可能な帯域幅、所定のデータ転送ジョブに対するデータサイズ、種々の送信機に割り当てられた優先度、並びに現在のCPU負荷、現在のメモリ負荷、データの転送に対するディスク又はあらゆるディスクに関連した障害bottleneckボトルネックへの現在の負荷及びデータの転送に対するネットワーク又はあらゆるネットワークに関連した障害への現在の負荷の性能に基づいて許容接続の数を考えるオートチューニングソフトウェア336からの推奨がスケジュールマネージャ338に対して使用可能になる。一実施形態の例において、ストリーミングソフトウェア334、オートチューニングソフトウェア336及びスケジュールマネージャ338は、CPU302によりRAM308の領域にロードされる。次にCPU302は、ロードされたコンピュータが実行可能なステップを実行するために、RAM308から格納されたストリーミングソフトウェア334、オートチューニングソフトウェア336及びスケジュールマネージャ338の処理ステップを実行する。また、アプリケーションプログラム330の処理ステップは、CPU302によりRAM308の領域にロードされる。次にCPU302は、ロードされたコンピュータが実行可能なステップを実行するために、図40に関連して以下に詳細に説明するような格納された処理ステップを実行する。図4Aは、一実施形態の例に従って、送信機と受信機との間の一次接続の確立を説明する送信機及び受信機を示す図である。一般に、送信機101と受信機102との間でデータを送受信するために多数のソケットを介する多数の転送制御プロトコルTCP接続を利用する並列データプロトコルPDPが提供される。しかし、データがストレージシステムに書き込まれる前に受信機がデータをメモリバッファに収集する限り、マルチストリームデータ転送のための他の多数の接続システムすなわち、あらゆるコネクション指向プロトコルを介したあらゆる論理接続エンドポイントが利用されてもよい。図6に関連して、他の多数の接続システムを以下に更に詳細に説明する。図4Aにおいて、送信機101のみが示されるが、他の実施形態の例において、送信機131及び132等の2つ以上の送信機が受信機102との接続を形成していてもよい。図4Aにおいて、実現されたPDPの例は、多数のストリーム例えば、TCP接続を介してデータを送受信できるようにする固有の軽い2値要求/応答ベースのプロトコルである。実際のデータ転送が実行可能となる前に、送信機101は、最初に要求メッセージを受信機102に送出する401。要求メッセージは、受信機102に登録される要求されたURI経路を含む。受信機102は、有効な要求メッセージを受信すると、データ転送接続を開始するために送信機101により使用される受信機102により割り当てられた一意のセッションidを含む応答メッセージで応答する402。上述のステップ401及び402は、受信機102において最初のソケットを開始し、データを転送するためのセッションを開始する。受信機102により送出された応答メッセージにおいて、受信機102は、送信機101が確立されたセッションに参加することを許可される多くの接続を含む。送信機101が提供された数を上回る接続に参加しようとする場合、受信機102は更なる参加要求を拒否できる。更に応答メッセージは、確立されたセッションに対して1つの寿命を含むことができる。含まれた寿命が経過した後、送信機101はセッションを停止及び終了する。受信機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。更に応答メッセージは、現在のセッションの活動中の時間及び更新された参加セッションのリストを含む状態変更を含むことができる。参加セッションが作成されると、データは、送信機101から受信機102に送出されてよく407、且つ受信機102から送信機101に送出されてよい408。送信機101と受信機102との間で送出されたデータは、送出されるデータヘッダid及び多くのデータ部分を含む。場合によっては、図4Bのステップ406において、受信機102は、送信機101からの参加要求を拒否する応答メッセージを送出してもよい。例えば、要求が図4Aで受信機により提供された許可された接続の数を超えるため、受信機102は参加要求を拒否してもよい。これらの場合、応答メッセージは、現在のセッションに対して許可された接続の数を含む。更に応答メッセージは、送信機101が再度セッションに参加しようとする前に待つべき期間例えば、数秒を含むことができる。この点に関して、送信機101は、受信機102により提供された数秒が過ぎた後で新しい参加要求を開始してもよい。図5は、一実施形態の例に従って、セッションにおける接続の数を増加又は減少するように送信機に通知する受信機を説明するシーケンス図である。図5において、送信機101は、オフセット1、長さ1のデータ部分を受信機102に送出する501。次に送信機101は、オフセット2、長さ2のデータ部分を受信機102に送出し502、後続のオフセット及び長さを含むデータ部分を送出し続ける503。次に受信機102は、送信機101がより多くの参加セッションを開始できるかを判定し、多くの新しい参加セッション及びセッションidと共に、オフセット及び長さを含む受信したデータ部分の肯定応答を送信機101に送出する504。肯定応答は、新しい参加セッションを開始する前に待つ期間を更に含むことができる。その後、送信機101は、セッションidを含む参加要求を送出し505、セッションが作成されると、新たに作成された参加セッションを介してオフセット及び長さを含む別のデータ部分を送出する506。場合によっては、受信機102は、1つ以上の既存の接続を閉じることを決定してもよい。これらの場合、受信機は、受信機102が1つ以上の接続を閉じたという肯定応答を送出する。送信機101は、受信機102が1つ以上の接続を閉じたという肯定応答を受信すると、残りの開いている接続を介して送出されたデータを再度割り当てることでその肯定応答に反応する。図6は、一実施形態の例に従って、送信機から受信機へのデータの送出を一般的に説明する送信機及び受信機を示す別の図である。図6において、送信機101は、データを格納するディスク等の記憶媒体601と、データバッファ621を含むデータバッファリーダ602と、データを送信するためのデータブロブシリアライザ603とを備える。送信機101は、接続604a及び605a、接続604b及び605b、並びに接続604c及び605cを介して受信機102に接続される。受信機102は、ディスク等の記憶媒体609を含むI/Oストレージシステムと、データバッファ622を含むデータブロブデシリアライザ608と、送信されたデータを受信するためのデータブロブデシリアライザファイル607とを備える。図6において、ソースデータの実際の読み出しは、送信機101により送信されるデータで記憶媒体601を満たす別個のスレッドを使用して非同期的に実行される。データは、データバッファリーダ602により記憶媒体601から読み出され、データバッファ621に格納される。送信機接続604a、604b及び604cの各々は、データバッファ621から次に使用可能なデータチャンクをデキューする。データバッファリーダ602は、データバッファ621からデータを読み出し、データブロブシリアライザ603は、次に使用可能なデータチャンクをデキューした特定の接続を介して次に使用可能なデータチャンクを送信する。送信されたデータチャンクは、受信機接続605a、605b及び605cのうちの対応する1つを介して受信される。データブロブシリアライザ607は、受信機接続605a、605b及び605cから送信されたデータチャンクを受信する。データブロブデシリアライザ608は、データをデータバッファ622に格納し、データチャンクを適切な順序にすることで元のファイルを再度作成する。次にデータブロブデシリアライザ608は、データを記憶媒体609に書き込むためにバックグラウンドスレッドを使用する。性能上の理由から、データブロブデシリアライザ608は、いくつかのデータをデータバッファ622にキャッシュし、データが元の順序にされる場合にはデータを記憶媒体609に書き込むことを好む。場合によっては、種々の接続を介して送出されたデータの順序がかなり狂う場合、データブロブデシリアライザ608は、出力ファイルにおいて異なる位置をシークしてデータを記憶媒体609に書き込み、キャッシュされたデータで処理メモリを消耗するのを回避する。[大量のデータ転送-並列データプロトコルMDT-PDP]本明細書で説明するアーキテクチャの例において、MDT-PDP転送コンポーネントは、アプリケーション内でSCLSoapConnectionLibraryサブシステムに対する転送ハンドラとして動作する。これは、SOAP要求及びSOAP応答を転送することを含む。MDT-PDP転送は、SCLクライアント及びSCLサービスの観点からSCLのデフォルトHTTPベースの転送と機能的に等しい。しかし、本明細書において提供された開示内容は上述のアーキテクチャの例に限定されず、特許請求の範囲の特徴が実現される限り、あらゆる転送プロトコルが実現されてもよい。SOAPConnectionlibraryの目的は、SOAPメッセージを用いたWebサービスのプロバイダすなわち、受信機機能及びクライアント機能を与えることである。プロバイダ機能は、特定の処理を実行し且つアクセスするための情報を提供するようにWebサービスを提供する機能である。一方、クライアント機能はWebサービスにアクセスする機能である。SOAPConnectionLibraryを使用するWebサービスは、SOAPConnectionLibraryを使用するクライアントだけではなく、Microsoft.NETFramework及び他のWebサービスフレームワークを使用するクライアントからの要求も処理できるようにする。同様に、クライアント機能は、SOAPConnectionLibraryを使用するWebサービスだけではなく、.NETFramework及び他のWebサービスフレームワークを使用するWebサービスに関連した要求も実行できるようにする。本明細書で説明するアーキテクチャの例において、MDT-PDPは、SCL内部で規定された転送ハンドラインタフェースを実現する。それらは、送信機及び受信機のそれぞれの側のPdpTransportReceiver及びPdpTransportSenderである。送信機側のPdpTransportSenderは、PDP送信機とPDP受信機との間の並列接続とのPDP送信機セッションを確立することを担う。ハンドラチェーン内部のこれらのハンドラの呼び出しは、データ及びイニシエータの流れの方向に依存する。ハンドラチェーン内部のこれらのハンドラの呼び出しは、下に形成された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メソッドは、MessageContextオブジェクトを含むトランスポート層を介してメッセージを送出する。このメソッドは、メッセージの送信を処理する場合に呼び出される。図8は、一実施形態の例に係る転送受信機を示すクラス図である。図8に示されるように、pdp::PdpTransportClientReceiverオブジェクト及びpdp::PdpTransportProviderReceiverオブジェクト804の各々は、pdp::PdpTransportReceiverオブジェクト802を継承する。また、pdp::PdpTransportReceiverオブジェクト802は、transport::TransportReceiverオブジェクト801を実現する。このreceiveメソッドは、トランスポート層からメッセージを受信し、受信のために受信したメッセージの種々の情報をMessageクラスに格納するように管理を実行する。図9は、一実施形態の例に係るサーバディスパッチャを示すクラス図である。図9に示されるように、pdp::SoapDispatcherオブジェクト903は、server::DispatcherBaseオブジェクト902を継承し、pdp::DataBlobProviderSoapオブジェクト904及びapplication::ApplicationInfoオブジェクト905に従属する。また、server::DispatcherBaseオブジェクト902は、server::Dispatcherオブジェクト901に従属する。ユーザがSoapConnectionLibraryを用いてサービス又はクライアントを作成する場合、SoapDispatcherクラスは、動作情報及びクライアント情報等の情報を維持するApplicationInfoオブジェクトを含む。従って、SoapDispatcherは、ApplicationInfoオブジェクトを含むSCLと通信でき、SCLは、DispatchHandlerChainオブジェクト不図示において異なる種類のディスパッチハンドラに対するDispatcherHandler不図示を含む。図10は、一実施形態の例に係るデータソースを示すクラス図である。図10に示されるように、pdp::MdtDataSourceオブジェクト1002は、dataholder::DataSourceオブジェクト1003を継承し、transport::DataBlobDeserializerFileオブジェクト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オブジェクトからinvokeMessageContextを継承する。1303において、:PdpTransportClientSenderは、:HandlerChainオブジェクトからinitMessageContextを継承する。1304及び1305において、:PdpTransportClientSenderオブジェクトは、:DataBlobProviderSoapオブジェクト及び:SimpleClientオブジェクトと関連する。1306、1307及び1308において、:SimpleClientオブジェクトは、:PdpTransportClientSenderオブジェクトからsetDataBlobProviderDataBlobProvider、setLocalInetAddressesinetAdress[]及びsetConnectionOptionsPdpConnectionOptionsを継承する。1309において、:PdpTransportClientSenderオブジェクトは、:HandlerChainオブジェクトからsendMessageContextを継承する。SCLClientは、このカスタムトランスポートを介してSOAPメッセージを送受信するためにMDTプロトコル及びPDPプロトコルを利用するSOAPクライアントとして動作する。SimpleClientオブジェクトは、送信機が多数の接続を介してデータを送出するためにPDPプロトコルを利用できるようにする単純な構成要素である。また、PUT動作の場合、送信機はデータを受信機すなわち、プロバイダに送出する。GET動作の場合、送信機はプロバイダすなわち、受信機からデータを検索する。1310において、:SimpleClientオブジェクトは、:PdpTransportClientSenderオブジェクトからgetSession:ClientSessionを継承する。1311において、:SimpleClientオブジェクトは:ClientSessionオブジェクトと関連し、1312及び1313において、:ClientSessionオブジェクトは、:DataBlobSerializeQueueオブジェクト及び:DataBlobDeserializeQueueオブジェクトと関連する。1314において、:ClientSessionオブジェクトは、:SimpleClientオブジェクトからstartSessionMessageRequest:MessageResponseを継承する。1315において、:ClientSessionオブジェクトは、:ClientConnectionオブジェクトと関連する。1316及び1317において、:ClientConnectionオブジェクトは、自身からcreateSessionMessageRequest及びdoRequestを継承する。1318において、:ClientConnectionオブジェクトは:ClientSessionオブジェクトと関連する。1319において、:ClientSessionオブジェクトは:SimpleClientオブジェクトと関連する。1320において、:SimpleClientオブジェクトは:PdpTransportClientSenderオブジェクトと関連する。1321において、:PdpTransportClientSenderオブジェクトは:DataBlobSerializerSoapオブジェクトと関連する。1322において、:DataBlobSerializerQueueオブジェクトは、:PdpTransportClientSenderオブジェクトからaddDataBlobDataBlobSerializerを継承する。1323において、:PdpTransportClientSenderオブジェクトは、:HandlerChainオブジェクトからdestroyMessageContextを継承する。1324において、:ClientSessionオブジェクトは、:PdpTransportClientSenderオブジェクトからwaitforRequestCompletionを継承する。1325において、:PdpTransportClietReceiverオブジェクトは、:HandlerChainオブジェクトからreceiveMessageContextを継承する。尚、DataBlobSerializerSoapクラスは、DataBlobSerializer例えば、以下に説明する図27を参照を拡張し、MessageContextオブジェクトのメッセージを直列化するためにSCLMessageSerializerオブジェクトを利用する。DataBlobSerializerは、以下に更に詳細に説明するDataBlobSerializerNoData及びDataBlobSerializerPartStreamにより更に拡張される抽象クラスとしてデータブロブシリアライザを規定する。1326において、:DataBlobSerializerSoapオブジェクトは、:ClientConnectionオブジェクトからserializeOutputStreamを継承する。1327において、:ClientConnectionオブジェクトは、自身からdoResponseを継承する。1328において、:ClientSessionオブジェクトは、:ClietSessionオブジェクトからsetCompletionStatusSESSION_RESPOSEを継承する。1330において、:SimpleClientオブジェクトは、:PdpTransportClientReceiverオブジェクトからread:DataBlobDeserializerを継承する。1329において、:ClientSessionオブジェクトは、:SimpleClientオブジェクトからwaitForCompletionを継承する。1331において、:ClientSessionオブジェクトは、:SimpleClientオブジェクトからgetIncominDataBlobs:DataBlobDeserializerQueueを継承する。1332において、:DataBlobDeserializerQueueオブジェクトは、:SimpleClientオブジェクトからgetDataBlobs:DataBlobDeseralizerを継承する。1333において、:SimpleClientオブジェクトは:PdpTransportClientReceiverと関連する。1334において、:PdpTransportClientReceiverは、自身からdeseriliazeDataBlobDeserializer[]MessageContextを継承する。図14A及び図14Bは、putの例におけるプロバイダ側を示すシーケンス図である。図14Aに示されるように、:ServerConnectionオブジェクトは、自身からdoRequestを継承する。1402において、:ServerSessionは、:ServerConnectionオブジェクトからgetIncominDataBlobs:DatablobDeserializeQueueを継承する。1403及び1404において、:DataBlobDeserializerQueueオブジェクト及び:DataBlobDeserializerオブジェクトは、:ServerConnectionオブジェクトからgetDataBlobMessagesHeader:DataBlobDeserializer及びdeserializeInputStreamを継承する。1405において、:ServerSessionオブジェクトは、:ServerConnectionオブジェクトからsetCompletionStateSESSION_REQUESTを継承する。1406において、:SoapDispatcherオブジェクトは、:ServerSessionオブジェクトからdoWorkServerSessionを継承する。1414において、:HandlerChainは、:SoapDispatcherオブジェクトからinvokeMessageContextを継承する。1415において、:PdpTransportProviderReceiverは、:HandlerChainオブジェクトからreceiveMessageContextを継承する。1407及び1408において、:ServerSessionオブジェクト及び:DataBlobDeserializerQueueは、:PdpTransportProviderReceiverオブジェクトからgetIncominDataBlobs:DataBlobDeserializerQueue及びgetDataBlobs:DdataBlobDeserializerを継承する。尚、DataBlobDeserializerFileクラスは、ファイルベースのデータブロブデシリアライザを実現する。DataBlobDeserializerQueueクラスは、データブロブデシリアライザキューを実現する。DataBlobDeserializerRAFクラスの実現例は、データ部分を単一のファイルに非直列化する実現例である。このDataBlobDeserializerRAFの実現例は、データ部分を書き出すためにRandomAccessFileRAFを使用する。また、ディスクへの書き込み及び入力ストリームからの読み出しは、メモリ内のデータ部分バッファ及びバックグラウンドライタスレッドを使用することで分離される。ServerConnectionクラスは、PDPサーバ及びPDPサーバのセッション情報を含む。その呼び出し側は、PDP接続を作成及び開始して、このクラスを介してメッセージを送受信できる。1409において、:ServerConnectionオブジェクトは、自身からdoResponseを継承する。1416及び1417において、:PdpTransportProviderReceiverは、deserializeSOAPDataBlobDeserializeerFile,MessageContext及びdeserializeAttachmentDataBlobDeseerializerRAF,MessageContextを継承する。1418において、:PdpTransportProviderReceiverオブジェクトは、:HandlerChainオブジェクトからdestroyMessageContextを継承する。1419及び1420において、:PdpTransportProviderSenderオブジェクトは、:HandlerChainオブジェクトからinitMessageContext及びsendMessageContextを継承する。1421において、:PdpTransportProviderSenderは、:DataBlobSerializerSoapオブジェクトと関連する。1410において、:DataBlobSerializeQueueは、:PdpTransportProviderSenderオブジェクトからaddDataBlobDataBlobSerializerを継承する。1411において、:DataBlobSerializeQueueは、:ServerConnectionオブジェクトからgetNextDataBlobDataBlobSerializer:DataBlobSerializerを継承する。1412において、:DataBlobSerializerSoapオブジェクトは、:ServerConnectionオブジェクトからserializeOutputStreamを継承する。1413において、:ServerSessionオブジェクトは、:ServerConnectionオブジェクトからsetCompletionStateSESSION_DONEを継承する。図15は、getの例におけるクライアント側を示すシーケンス図である。図15に示されるように、1501において、SCLClientオブジェクトは、ユーザからGET<filename>を継承する。1502において、:HandlerChainオブジェクトは、SCLClientオブジェクトからInvokemessagecontextを継承する。1503において、:PdpTransportClientSenderオブジェクトは、:HandlerChainオブジェクトからinitMessageContextを継承する。1504、1505及び1506において、:SimpleClientオブジェクトは、:PdpTransportClientSenderオブジェクトからsetDataBlobProviderDataBlobProvier、setLocalInetAddressInetAddress[]及びsetConnectionOptionsPdpConnectionOptionsを継承する。1507において、:PdpTransportClientSenderオブジェクトは、:HandlerChainオブジェクトからsendMessageContextを継承する。1508において、:SimpleClientオブジェクトは、:PdpTransportClientSenderオブジェクトからgetSession:ClientSessionを継承する。1509において、:PdpTransportClientSenderオブジェクトは、自身からsendSopaMessageMessageContext,DataBlobSerializeQueueを継承する。1510において、:PdpTransportClientSenderオブジェクトは、:HandlerChainオブジェクトからdestroyMessageContextを継承する。1511及び1512において、:PdpTransportClientReceiverオブジェクトは、:HanderChainオブジェクトからreceiveMessageContext及びdestroyMessageContextを継承する。図16は、getの例におけるプロバイダ側を示すシーケンス図である。図16に示されるように、1601において、:SoapDispatcherオブジェクトは、:ServerSessionオブジェクトからdoWorkServerSessionを継承する。1602において、:HandlerChainオブジェクトは、:SoapDispatcherオブジェクトからinvokemessageContextを継承する。1603及び1604において、:PdpTransportProviderReceiverは、:HandlerChainオブジェクトからreceiveMessageContext及びdestroyMessageContextを継承する。1605及び1606において、:PdpTransportProviderSenderオブジェクトは、:HandlerChainオブジェクトからinitMessageContext及びsendMessageContextを継承する。1607において、:PdpTransportProviderSenderは、自身からsendSoapMessageMessageContext,DataBlobSerializeQueueを継承する。1608において、:PdpTransportProviderSenderオブジェクトは、:HandlerChainオブジェクトからdestroyMessageContextを継承する。図17は、get動作を取り消すクライアント側を示すシーケンス図である。図17に示されるように、1701において、:ClietnSessionオブジェクトは、:PdpTransportClientSenderオブジェクトからstartanewsessionを継承する。1702において、:ClientConnectionオブジェクトは、:ClietSessionオブジェクトからstarttheconnectionsocketthreadを継承する。1703において、:MeterInputStreamオブジェクトは、:ClientConnectionオブジェクトからreadbyte[],int,int:intを継承する。1704において、:SessionDataMeterオブジェクトは、MeterInputStreamオブジェクトにおいて関数onBytesReadlongによりインスタンス化される。1705において、:SessionDataMeterオブジェクトは、SessionEventを:PdpTransportClientSenderと関連付ける。1706において、<<interface>>:InTransportEventListenerオブジェクトは、:PdpTransportClientSenderオブジェクトからhandlelnTransportEventInTransportEventを継承する。1707において、<<interface>>:InTransportEventListenerオブジェクトは、throwIOExceptionを:PdpTransportClientSenderオブジェクトと関連付ける。1708において、:ClinetSessionオブジェクトは、:PdpTransportClientSenderオブジェクトからterminateExceptionを継承する。1709において、:ClientConnectionオブジェクトは、:ClinetSessionオブジェクトからcloseを継承する。MeterinputStreamオブジェクトは、SessionDataMeterオブジェクトを利用し且つSessionDataMeterオブジェクトにおいて関数onBytesReadlongを呼び出すことで受信したデータバイトを更新する。図18は、get動作を取り消すプロバイダ側を示すシーケンス図である。図18に示されるように、1801において、:ServerSessionオブジェクトは、SoapDispatcher:eventProcessorThreadからStartanewserversessionを継承する。1802において、:ServerConnectionオブジェクトは、:ServerSessionオブジェクトからstartaconnectionsocketを継承する。1803において、:MeterOutputStreamは、:ServerConnectionオブジェクトからwritebyte[],int,intを継承する。1804において、:SessionDataMeterオブジェクトは、:MeterOutputStreamオブジェクトからonByteWritelongを継承する。1805において、:SessionDataMeterは、waitForEvent:SessionEventをSoapDispatcher:eventProcessorThreadオブジェクトと関連付ける。1806において、<<interface>>:OutTransportEventLIstenerオブジェクトは、SoapDispatcher:eventProcessorThreadオブジェクトからhandleOutTransportEcentOutTransportEventを継承する。1807において、<<interface>>:OutTransportEventListenerオブジェクトは、SoapDispatcher:eventProcessorThreadオブジェクトと関連する。1808において、:ServerSessionオブジェクトは、SoapDispatcher:eventProcessorThreadからterminateExceptionを継承する。1809において、:ServerConnectionオブジェクトは、:ServerSessionオブジェクトからcloseを継承する。図19は、put動作を取り消すクライアント側を示すシーケンス図である。図19に示されるように、:MeterOutputStreamオブジェクトは、:ClientConnectionオブジェクトからwritebyte[],int,intを継承する。1902において、:SessionDataMeterオブジェクトは、onBytesWritelongを継承する。1903において、:SessionDataMeterオブジェクトは、:PdpTransportClientSenderオブジェクトからwaitForEvent:SessionEventを継承する。1904において、<<interface>>:OutTransportEventListenerオブジェクトは、:PdpTransportClientSenderオブジェクトからhandleOutTransportEventOutTransportEventを継承する。1905において、<<interface>>:OutTransportEventListenerオブジェクトは、throwIOExceptionを:PdpTransportClientSenderオブジェクトと関連付ける。1906において、:ClietnSessionオブジェクトは、:PdpTransportClientSenderオブジェクトからterminateExceptionを継承する。1907において、:ClientConnectionオブジェクトは、:ClientSessionオブジェクトからcloseを継承する。図20は、put動作を取り消すプロバイダ側を示すシーケンス図である。図20に示されるように、:MeterInputStreamオブジェクトは、:ServerConnectionオブジェクトからreadbyte[],int,intを継承する。2002において、:SessionDataMeterオブジェクトは、onBytesReadlongを継承する。2003において、:SessionDataMeterオブジェクトは、SoapDispatcher:eventProcessorThreadオブジェクトからwaitForEvent:SessionEventを継承する。2004において、<<interface>>:InTransportEventListenerオブジェクトは、SoapDispatcher:eventProcessorThreadオブジェクトからhandleInTransportEventInTransportEventを継承する。2005において、<<interface>>:InTransportEventListenerオブジェクトは、throwIOExceptionをSoapDispatcher:eventProcessorThreadオブジェクトと関連付ける。2006において、:ServerSessionオブジェクトは、SoapDispatcher:eventProcessorThreadオブジェクトからterminateExceptionを継承する。2007において、:ServerConnectionオブジェクトは、:ServerSessionオブジェクトからcloseを継承する。図21は、図1の受信機102のI/Oストレージシステムにおける書き込み動作を示す図である。一般に、並列接続データ転送システムにおいて、受信機のI/Oストレージシステムは、大量のデータ転送に対する障害ボトルネックとなりうる。特に、I/Oストレージシステムに含まれたディスクは、大量のデータ転送に対する障害となりうる。この点に関して、ファイルが小さな部力に分解されて別個の接続を介して配信される場合、データは、特に接続の数が増加するにつれ受信機において順番に到着しないだろう。受信機が次の連続データチャンクが到着するのを待って時間切れになる場合、データをディスクに書き込む前に受信機のデータバッファは満杯になるだろう。受信機のデータバッファが満杯になると、受信機のI/Oストレージシステムは、更なるシーク動作を必要とする可能性のある故障データに対するディスク書き込みを実行することを強制されてもよい。更なるシーク動作を実行することにより、受信機のI/Oストレージシステムがデータの転送に対する障害である場合にデータを転送するのにかかる時間は更に長くなる。また、肯定応答がないすなわち、受信機のバッファが満杯であることによるデータ消失の場合のことでデータの転送が更に遅延するために、更なるシーク動作を実行することにより、送信機からのデータ再送事象を更にトリガしてもよい。この例において、受信機は、新しい接続要求の受け入れを中止でき、バッファが満杯な状態を回避できるように既存の接続の数を更に減少できる。その結果、更なる高価なシーク動作が回避されるだろう。複数の接続を介してデータを送出する場合、送信機101と受信機102との間の接続と出力ファイルとの間に多対一の関係が存在する。すなわち、多数の同時接続において転送されたデータは、単一のファイルに集約される。データを受信する受信機の各接続内において、スレッドは、単一のファイルと関連付けられたインバウンド接続から全てのデータチャンクを読み出すように開始される。同一のファイルに対してチャンクを転送する全てのN個の並列接続は、図6に示されたような同一のデータブロブデシリアライザファイル607で非直列化方法を呼び出す。データブロブデシリアライザの図6のタスクは、全てのN個の接続からのファイルと関連付けられた全てのデータチャンクを読み出すためのものであり、効率的にデータを図6の記憶媒体609に転送する。図21に示されるように、DataWriteQueue2101は、楕円形で示されるDataWriteObjectsの形態のデータを格納する。図21において、ライタスレッド2102は、DataWriteObjectsをファイルに書き込む。図中符号2103はファイルの先頭を示す。また、ファイルに既に書き込まれたデータは、図中符号2105として示される。領域2106は、データが既に受信されているがまだファイルに書き込まれていない領域を示す。領域2107は、データがまだ受信されていない領域を示す。DataWriteQueueは、スレッドセーフブロッキングキューの実現例である。インスタンスモニタは、removeメソッド及びinsertメソッドに対する同期ロックとして使用される。removeメソッド及びinsertメソッドは、キューから項目を除去する。removeDataWriteObjectWithOffsetメソッドは、特定のオフセットにおける変更開始を除去するために使用可能である。このメソッドは、必要なデータブロックが使用可能になるまでブロックする。DataWriteObjectオブジェクトは、LinkListオブジェクトのメモリバッファにデータを格納してデータを連結し、データのオフセット及び長さの情報を更に記録する。図21において、現在のファイル位置は、ライタスレッド2102がデータをファイルに書き込むのに使用可能である。しかし、現在のファイル位置2105に対してそのようなDataWriteObjectがDataWriteQueue2101に存在しないことがありうる。ファイルの種々の領域からデータを転送するために種々の接続が使用されるため、ライタスレッド2102がファイルの特定の領域をディスクに書き込む準備ができるまでにファイルのその特定の領域がまだ受信されていないことがありうる。これは、メモリバッファが記憶装置に書き込む前に一時的なチャンクデータを収容するのに十分なほど大きくないことを示すだろう。その結果、シーク動作が実行されてもよいことを意味する。通常、これは、送信機101から受信機102へのデータ転送速度がI/Oストレージシステムを処理するよりも高速であることを意味する。従って、参加接続の数は、ファイルシーク動作を回避するように減少されてもよい。図40に関連して、これを以下に更に詳細に説明する。より具体的には、ライタスレッド2102は、この例においてファイルの異なる領域をディスクに書き込むことが許可される場合、回避されるべきシーク動作を実行する。一方、ライタスレッド2102が接続のうちの1つによりDataWriteObjectがキューに提示される無限の時間の長さを待ちながら無制限にブロックする場合、非効率的になる可能性もある。これは、より高速なネットワークが採用され且つI/Oストレージシステムのディスクがデータの転送において障害である場合に特に当てはまる。この場合、ライタスレッド2102が待たされるほど、転送はより非効率的になる。データの効率的なPDP転送を提供するために、以下の2つのことを平衡させる。すなわち、1データをディスクに頻繁に書き込むことであり、ライタスレッド2102が頻繁に非ブロック化されたままであるのを許可することを意味する。2ファイルシーク動作を回避することであり、現在のファイル位置に対するデータが接続のうちの1つから読み出されるまで待つようにライタスレッド2102をブロックする場合もあることを意味する。上述の平衡は、DataWriteQueue2101において実行される。現在のファイル位置2104に対するDataWriteObjectが使用不可である場合、例えばDataWriteQueueは、不要なシーク動作及びライタスレッド2102の不要なブロックを実質的に回避する傾向がある以下のヒューリスティックを採用する。すなわち、DataWriteObjectが現在のファイル位置に対して使用不可である場合、1要求されたDataWriteObjectがリーダスレッドによりDataWriteQueue2101に追加される間最大2秒待ち、2要求されたDataWriteObjectが2秒のタイムアウト期間内に使用可能になる場合にそれを返送し、3要求されたDataWriteObjectが2秒のタイムアウト期間内に使用可能にならない場合に使用可能である最も低い絶対オフセットを含むDataWriteObjectをライタスレッド2102に返送する。このヒューリスティックは、ライタスレッドがディスクへの書き込みを継続することとファイルシーク動作を回避することとを平衡しようとする。しかし、シーク動作は全て回避されなくてもよく、データ転送をより適切に実行するために、受信機102は、送信機101からの参加要求をブロックし、且つ送信機101が1つ以上の二次接続を閉じることを要求してもよい。図40に関連して、これを以下に更に詳細に説明する。メモリにより少ないDataWriteObjectsがあるすなわち、データがライタスレッド2102によりまだファイルに書き込まれていないことを示す場合、現在のファイル位置2104を示すDataWriteObjectが使用可能である可能性はあまり高くない。この例においてライタスレッド2102が使用可能なDataWriteObjectsのうちの1つをファイルに書き込むことが許可される場合、ファイルに対するシーク動作が必要である可能性はより高い。従って、DataWriteQueue2101がほぼ空になると、接続リーダスレッドによりDataWriteQueue2101を最小レベルまで満たせるように、ライタスレッド2102は、DataWriteObjectsを除去しようとする場合にブロックされる。異なる例において、リーダスレッドは、DataWriteObjectsをDataWriteQueue2101に追加しようとする場合にブロックされてもよい。この例において、DataWriteQueue2101が非常に多数のDataWriteObjectsで満たされる場合、別のDataWriteObjectをDataWriteQueue2101に追加しようとする接続リーダスレッド不図示はブロックされる。これにより、ライタスレッド2102はDataWriteObjectsのうちのいくつかをディスクに書き込める。内部的に、DataWriteQueue2101は、上述のブロックの例が発生した時を判断するためにConsumerProducerThrottleオブジェクト不図示を利用する。ConsumerProducerThrouttleオブジェクトは、DataWriteObjectThrottle不図示が実現するための契約を規定するインタフェースオブジェクトである。DataWriteObjectThrottleは、アプリケーションがディスク記憶装置に書き込む前に未実現データをメモリにキャッシュするようにメモリバッファのサイズを構成できるようにし、現在の消費されたリカバリバッファ情報を更に含む。ライタスレッド2102がDataWriteQueue2101からDataWriteObjectを除去するように要求する場合、DataWriteQueueは、その要求をConsumerProducerThrottleオブジェクトに通知する。DataWriteQueue2101が最小数のDataWriteObjectsを有さない場合、ConsumerProducerThrottleオブジェクトはライタスレッド2102をブロックする。DataWriteQueue2101が十分なDataWriteObjectsで満たされると、ConsumerProducerThrottleはライタスレッド2102をリリースする。あるいは、リーダスレッドが新しいDataWriteObjectをDataWriteQueue2101に追加するように要求する場合、DataWriteQueue2101は最大数のDataWriteObjectsに到達したかもしれない。この例において、ライタスレッド2102がDataWriteQueue2101からDataWriteObjectsを除去する機会を有するまで、リーダスレッドはブロックされる。ここでも、DataWriteQueue2101は、上述の例が発生した時を判断するためにそのConsumerProducerThrottleオブジェクトを利用する。リーダスレッドがDataWriteObjectをDataWriteQueue2101に追加する場合、DataWriteQueue2101は、DataWriteObjectが追加されていることをConsumerProducerThrottleに通知する。ConsumerProductThrottleは、DataWriteQueue2101がその最大数のDataWriteObjectsに到達したと判断する場合、リーダスレッドをブロックする。キューにおけるDataWriteObjectsの数が減少するまで、リーダスレッドはブロックされたままである。図22は、図21に示されたようなDataWriteQueue2101を示す図である。図22において、DataWriteObjects2201a~2201d等のいくつかのDataWriteObjectsを受信した後のDataWriteQueue2101が示される。この例において、DataWriteObjectsは、ファイルの5つの隣接領域を示す5つのチェーンに編成される。DataWriteObjects2201a~2201dは、5つのチェーンのうちの1つを示す。一般にDataWriteQueue2101は、N個のリーダスレッドに対する同期及び編成の点として動作する。シーク動作を回避するために、DataWriteQueueは、自動的にファイルの隣接領域を示すDataWriteObjectsの集合を検出する。DataWriteQueue2101は、ファイルの隣接領域を示す多数のDataWriteObjectsを受信する場合、各DataWriteObjectがどの接続からのものかに関係なく、DataWriteObjectsを単一のチェーンの内部に集める。従って、DataWriteQueueは、順序付けされていないDataWriteObjectチェーンの集合としてDataWriteObjectsを格納する。図21のライタスレッド2102は、DataWriteQueueからDataWriteObjectsを除去する場合、現在のファイル位置を示す。ファイルシーク動作を回避できるようにするために、DataWriteQueue2101は、そのオフセットが現在のファイル位置2104であるDataWriteObjectを提供する。次にライタスレッド2102は、シーク動作を実行せずに現在のファイル位置2104に書き込んでもよい。内部的に、DataWriteQueue2101は、ファイルの隣接領域を示すM個のDataWriteObjectチェーンの集合を維持する。DataWriteQueue2101は、M個のDataWriteObjectチェーンのオフセットの開始を確認し、最初のオフセットが現在のファイル位置に一致するチェーンがある場合、チェーン全体が返送される。図23は、図1の受信機102のI/Oストレージシステムにおける書き込み動作を示す別の図である。一般に、データが順番に来なくてもよいため、多数の接続は、データを再度集めるようにデータをメモリ内のバッファに書き込んでもよい。データをディスクに書き込む間のI/Oストレージシステム書き込み速度を測定することにより、ディスクが他のアプリケーション及びタスクからの要求を処理するのに使用中であるかを判断できる。それに応じて、接続の数を適切に減少又は増加できる。図40に関連して、これを更に詳細に説明する。図23に示されるように、ライタスレッド2102は、記憶媒体609図6に示されたようなのファイルにデータを書き込む。ライタスレッド2102を使用することにより、N個のリーダスレッドをファイル書き込み動作から分離する。DataWriteObjectsは、接続605a~605cにより追加され、ライタスレッド2102により除去される。ライタスレッド2102がデータを記憶媒体609に書き込む速度は、I/Oストレージシステムに対して測定された書き込み速度である。図24Aは、図1の送信機101のI/Oストレージシステムにおけるデータ転送の障害ボトルネックを検出するシーケンス図である。一般に送信機101は、ネットワーク性能を見つけるためにラウンドトリップ時間RTTを利用してもよい。利用されたRTTは、TCPのRTT又はRTTを算出するための他のあらゆる固有の手法であってもよい。近年のTCPの実現例は、一般的なデータパケットの交換を監視し且つどれくらいの長さが長すぎるかの推定を発展させることでネットワーク性能の問題に対応しようとする。この処理をラウンドトリップ時間RTT推定と呼ぶ。RTT推定は、TCP交換、特に殆どのTCPの実現例が良質なリンクかどうかに関係なく最終的にパケットをドロップしてそれらを再送信する無限に大きな転送において重要な性能パラメータである。RTT推定が低すぎる場合、パケットは不必要に再送信されず、RTT推定が高すぎる場合、接続は、ホストが時間切れを待つ間アイドル状態であってもよい。受信機102に送出されたメッセージパケットのRTT時間が前のメッセージパケットより長くかかっていることに送信機101が気付く場合、それは、ネットワークが使用中であり且つより多くのトラフィックを有することを示すだろう。この場合、送信機101は、接続の数を減少して受信機102に報知できる。あるいは、RTTがより短い期間かかっている場合、送信機は、接続の数を増加するように要求してもよい。図40に関連して、上述の接続の数の増減を更に詳細に説明する。図24Aにおいて、送信機101は、肯定応答を送信機101に送出するように受信機102に要求できる。送信機101は、キャッシュされた情報をこれ以上保持しない状況を検出する場合、受信機102にそれを通知し、両者がキャッシュされた情報を適切に除去して新しいデータ部分に進めるように肯定応答ACKを送出することを受信機に強制する。このような状況において、受信機は、送信機101がより多くの帯域幅を利用するために接続の数を増加できるかを判断できる。肯定応答ACKは、トランスポート層のACK信号例えば、TCPプロトコルではなく、アプリケーション層に対する肯定応答を参照している。このため、MDTは、データが肯定応答すなわち、ここではACKとして到着したことを受信機がクライアントに報知するために通信チャネルを実現する。あるいは、受信機否定応答RNAは、上述のキャッシュの除去を実現するために利用可能である。特に、図24Aにおいて、送信機101は、メッセージを送出するステップ2401前にデータをメモリバッファに読み込む。ステップ2402~2406において、送信機101は、オフセットa1、長さb1を含むデータ部分、オフセットa2、長さb2を含むデータ部分、オフセットa3、長さb3を含むデータ部分を送出し、データ部分がan-1のオフセット、長さbn-1及び最終的にanのオフセット、長さbnに到達するまでデータ部分を送出し続ける。ここで、nは、一連のデータ部分の数を示す。ステップ2407において、送信機101は、受信機が認識されたデータ部分のリストを含むACKを送出することを要求する。受信機102は、追跡してきたデータパケットの値のオフセット及び長さを進め、データパッケージを記憶装置に書き込む。ステップ2408において、受信機102は要求されたACKを送出し、送信機101はメモリバッファにキャッシュされたデータを除去する。図24Bは、図1の送信機101のI/Oストレージシステムにおける読み出し動作を示す図である。図24Bにおいて、データバッファリーダ2411は、別個のスレッドに記憶媒体すなわち、ディスク601からデータブロックを読み出す。データバッファリーダ2411は、空きセクション及び満杯セクションを含むダブルキュー機構を使用する。データバッファリーダ2411は、データバッファ部分をメモリバッファ2412の満杯側にロードする。データバッファリーダ2411は、ロードされ且つ再利用されたデータバッファ部分を管理し、同期的にロードされたデータバッファ部分へのアクセスを一覧表示し且つ提供する。更にデータバッファ部分は、ネットワークに対してそれらのコンテンツを読み書きする機能を提供する。DataBlobSerializerPartStream2421a、2421b及び2421cは、データバッファリーダ2411からロードされたデータ部分を検索し、ネットワークを介して連続的にデータ部分を送出する。DataBlobSerializerPartStreamは、PDPプロトコル接続に基づくデータを用いてデータを直列化するように、所定の入力ストリーム又はデータバッファリーダに対してDataBlobSerializerを拡張する。DataBlobSerializerPartStream2421a、2421b及び2421cは、利用されたデータ部分を更に再利用する。接続604a、604b及び604cは、リモートホストとのエンドツーエンド接続ソケットを提供し、データをリモートホストに送出するためにDataBlobSerializerPartStreamオブジェクト2421a、2421b及び2421cを使用する。接続604a、604b及び604cは、ローカルホスト上で他の接続インスタンスと同時に動作する。図24Bに示された高度なダブルキュー機構は、以下の効率的な概念、すなわち1ディスクからデータを非同期に読み出すことでデータの読み出し及び送出におけるタイミングの重複を実現すること、2同期アクセスをロードされたデータバッファ部分のリストに提供する機能により、同時に実行している接続スレッドが多数のソケットを介してデータを同時に送出できること、並びに3データバッファ部分を再利用する機能により、実質的に不要なヒープメモリの割り当て及びガーベッジコレクションを回避することを提供する。ネットワークがデータを送出できるよりも速くデータバッファリーダ2411が記憶媒体すなわち、ディスク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オブジェクト2052と関連する。尚、この図において規定されたクラスは、PDPプロトコルクライアント接続要求を受け入れ且つSOAPConnectionLibraryすなわち、SCLを介してサーバセッションを維持するPDPプロトコルサーバを作成するためにMDTアプリケーションにより使用される。Serverオブジェクトは、PDPサーバを実現し、特定のアドレス及びポートをリスンするPDPサーバの例を作成且つ開始し、サーバ接続セクション及び参加セッションを樹立且つ維持する。呼び出し側は、このクラスからもセッションidを検索できる。図26は、一実施形態の例に係るクライアントを示すクラス図である。図26に示されるように、ClientConnectionオブジェクト2603及びSimpleClientオブジェクト2602の各々は、ClientSessionオブジェクト2601と関連する。これらのクラスは、PDPプロトコルサーバ接続に接続し且つSoapConnectionlibraryを介してクライアントセッションを維持するPDPプロトコルを作成するためにMDTアプリケーションにより使用される。図27は、一実施形態の例に係るデータシリアライザを示すクラス図である。図27に示されるように、DataBlobItemオブジェクト2703は、DataBlobSerializerオブジェクト2701と関連する。また、DataBlobSerializerPartStreamオブジェクト2702及びDataBlobSerializerNoDataオブジェクト2704の各々は、DataBlobSerializerオブジェクト2701と関連する。DataBlobSerializerNoData及びDataBlobSerializerPartStreamの双方は、DataBlobSerializerオブジェクトを拡張する。また、DataBlobSerializerNoDataは、データを全く含まない直列化されたデータブロブを提供する。図28は、一実施形態の例に係るデータデシリアライザを示すクラス図である。図28に示されるように、DataBlobDeserializerFileオブジェクト2803及びDataBlobDeserializerRAFオブジェクト2802の各々は、DataBlobDeserializerオブジェクト2801を継承する。また、DataBlobDeserializerRAFオブジェクト2802は、DataWriteQueueオブジェクト2804と関連する。DataBlobDeserializerは、データブロブデシリアライザを規定し、DataBlobDeserializerFile、DataBlobDeserializerRAF、DataBlobSerializerQueueは、このオブジェクトを拡張し、MessageContextオブジェクトのメッセージを非直列化するためにSCLMessageSerializerオブジェクトを利用する。図29は、クライアントにおいてセッションを確立するシーケンス図である。図29に示されるように、2901において、client::ClientSessionオブジェクトは、開発者からstartSessionを継承する。2902において、<<interface>>:PdpClientSocketFactoryオブジェクトは、client::ClientSessionオブジェクトからcreateUrlEx:Socketを継承する。2903において、<<static>>:Requestオブジェクトは、:ClientConnectionオブジェクトからwriteOutputStreamを継承する。2904において、<<static>>:Responseオブジェクトは、:ClientConnectionオブジェクトからreadInputStreamを継承する。2905において、:ClientConnectionオブジェクトは、client::ClientSessionオブジェクトからgetResponse:Message.Responseを継承する。Message.Responseは、Messageクラス不図示の内部クラスであり、PDP応答メッセージを規定する。Messageクラスは、PDP通信に対して使用された全ての転送メッセージを含む。このクラスにより、呼び出し側は、入力ストリームから次のPDPメッセージを取得でき、ベースPDPメッセージを規定する。2906において、client::ClientSessionオブジェクトは、開発者からjoinSessionを継承する。2907において、<<interface>>:PdpClientSocketFactoryオブジェクトは、client::ClientSessionオブジェクトからcreateUrlEx:Socketを継承する。2908において、<<static>>:Joinオブジェクトは、:ClientConnectionオブジェクトからwriteOutputStreamを受信する。2909において、<<static>>:Responseオブジェクトは、:ClientConnectionオブジェクトからreadInputStreamを継承する。2910において、:ClientConnectionオブジェクトは、client::ClientSessionオブジェクトからgetResponse:Message.Responseを継承する。2911において、client::ClientSessionオブジェクトは、開発者からwaitForCompletionを継承する。2912において、:ClientConnectionは、自身からdoRequestを継承する。2913において、:ClinetConnectionは、setCompletionStateREQUESTをclient::ClientSessionと関連付ける。2914において、:ClientConnetionオブジェクトは、自身からdoRequestを継承する。2915において、:ClientConnectionは、setCompletionStateREQUESTをclient::ClientSessionと関連付ける。2916において、:ClientConnetionは、自身からdoResponseを継承する。2917において、:ClientConnectionオブジェクトは、setCompletionStateRESPONSEをclient::ClientSessionオブジェクトと関連付ける。2918において、:ClientConnetionオブジェクトは、自身からdoResponseを継承する。2919において、:ClientConnectionオブジェクトは、setCompletionStateRESPONSEを関連付ける。2920において、:ClientConnetionオブジェクトは、自身からcloseを継承する。2921において、:ClientConnectionオブジェクトは、自身からcloseを継承する。図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で作成されたソケットは閉じられる。参加メッセージが成功した場合、参加セッションが作成されるステップ3007。ステップ3108において、セッション状態を確認する。セッションが実行される場合、ソケットは閉じられるステップ3111。更なる要求が認可される場合、ステップ3109に進む。図35に関連して、これを詳細に説明する。更なる応答が認可される場合、ステップ3110に進む。図36に関連して、これを詳細に説明する。図32は、サーバにおいてセッションを確立するシーケンス図である。図32に示されるように、3201において、:Serverオブジェクトは、開発者からaddDispatcherString,Dispatcherを継承する。3202において、:Serverオブジェクトは、開発者からstartを継承する。3203において、<<static>>:Requestオブジェクトは、:ServerConnectionオブジェクトからreadInputStreamを継承する。3204において、:ServerConnectionオブジェクトは、createSessionMessages.Request:ServerSessionを:Serverオブジェクトと関連付ける。尚、ここでパラメータとして渡されたMessage.Requestは、Messagesクラス不図示の内部クラスであり、PDP要求メッセージを規定する。3205において、<<interface>>:Dispatcherは、:ServerオブジェクトからonSessionCreateServerSessionを継承する。3206において、<<static>>:Responseは、:ServerConnectionオブジェクトからwriteOutputStreamを継承する。3207において、<<static>>:Joinオブジェクトは、:ServerConnectionオブジェクトからreadInputStreamを継承する。3208において、:ServerConnectionオブジェクトは、joinSessionMessafees.Join:ServerSessionを:Serverオブジェクトと関連付ける。3209において、<<interface>>:Dispatcherオブジェクトは、:ServerオブジェクトからonSessionJoinServerSessionを継承する。3210において、<<static>>:Responseオブジェクトは、:ServerConnectionオブジェクトからwriteOutputStreamを継承する。3211において、:ServerConnectionオブジェクトは、自身からdoRequestを継承する。3212において、:ServerConnectionは、setCompletionStateREQUESTを:ServerSessionオブジェクトと関連付ける。3213において、:ServerConnectionは、自身からdoRequestを継承する。3214において、:ServerConnectionオブジェクトは、setCompletionStateREQUESTを:ServerSessionオブジェクトと関連付ける。3215において、<<interface>>:Dispatcherオブジェクトは、:ServerSessionオブジェクトからdoWorkServerSessionを継承する。3216において、:ServerConnectionオブジェクトは、自身からdoResponseを継承する。3217において、:ServerConnectionオブジェクトは、自身からdoResponseを継承する。3218において、:ServerSessionオブジェクトは、:ServerConnectionオブジェクトからsetCompletionStateRESPONSEを継承する。3219において、:ServerSessionオブジェクトは、:ServerConnectionオブジェクトからsetCompletionStateRESPONSEを継承する。3220において、<<interface>>:Dispatcherオブジェクトは、:ServerSessionオブジェクトからonSessionEndServerSessionを継承する。3221において、:Serverオブジェクトは、:ServerSessionオブジェクトからremoveSessionServerSessionを除去する。3222及び3223において、:ServerConnectionオブジェクトは、自身からcloseを継承する。図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オブジェクトからgetNextDataBlobDataBlobSerializer:DataBlobSerializerを継承する。3402において、transport::DataBlobSerializeQueueオブジェクトは、開発者からaddDataBlobDataBlobSerializerを継承する。3403において、:ClientConnectionオブジェクトは、serializeOutputStreamを:DataBlobSerializerオブジェクトと関連付ける。3404において、transport::DataBlobSerializeQueueオブジェクトは、:ClientConnectionオブジェクトからgetNextDataBlobDataBlobSerializer:DataBlobSerializerを継承する。3405において、:ClientSessionオブジェクトは、開発者からwaitForCompletionを継承する。3406において、:ClientConnectionは、serializeOutputStreamを:DataBlobSerializerオブジェクトと関連付ける。3407において、:ClientConnectionオブジェクトは、setCompletionStateREQUESTを:ClientSessionオブジェクトと関連付ける。3408において、:ClientConnectionオブジェクトは、setCompletionStateREQUESTを:ClientSessionオブジェクトと関連付ける。3409において、transport::DataBlobSerializerQueueは、:ClientSessionオブジェクトからcloseを継承する。3410において、:DataBlobSerializerオブジェクトは、transport::DataBlobSerializerQueueオブジェクトからcloseを継承する。3411において、transport::DataBlobDeserializerQueueは、:ClientConnectionオブジェクトからgetDataBlobMessages.Header:DataBlobDeserializerを継承する。3412において、transport::DataBlobDeserializerQueueオブジェクトは、:ClientConnectionオブジェクトからgetDataBlobMessages.Header:DataBlobDeserializerを継承する。尚、Message.Headerは、Messagesクラス不図示の内部クラスであり、DATA-HEADERメッセージを規定する。3413及び3415において、:DataBlobDeserializerオブジェクトは、:ClientConnectionオブジェクトからdeserializerInputStream及びdeserializerInputStreamを継承する。3414及び3416において、:ClientConnectionオブジェクトは、setCompletionStateRESPONSEを:ClientSessionオブジェクトと関連付ける。3417及び3418において、:ClientConnectionオブジェクトは、自身からcloseを継承する。3419及び3421において、transport::DataBlobDeserializerQueueオブジェクトは、開発者からgetDataBlobs:DataBlobDeserializer及びdisposeを継承する。3420及び3422において、:DataBlobDeserializerオブジェクトは、getData:InputStream及びdisposeを継承する。図35及び図36は、送信機におけるデータ交換を一般的に説明するフローチャートである。図35のステップ3501において、データを送出するための要求を開始する。ステップ3502において、送信機は、取得するための次に使用可能な直列化データブロブがあるかを判定する。次に使用可能なデータブロブがある場合、送信機は、データブロブに対してデータヘッダを書き込みステップ3503、データのソースからデータブロブのデータ部分を読み出しステップ3504、読み出されたデータ部分を作成されたソケットに書き込むステップ3505。ステップ3506において、送信機は、データ部分がデータブロブの最後のデータ部分であるかを判定する。データ部分が最後のデータ部分ではない場合、送信機は、データブロブの次のデータ部分を作成されたソケットに書き込むステップ3505。ステップ3506でデータ部分が最後のデータ部分である場合、ステップ3502に戻る。次に使用可能な直列化データブロブがないとステップ3502で判定される場合、要求が完了しステップ3507、受信したデータへの応答が実行されるステップ3508。図36において、ステップ3601で受信したデータへの応答が実行される。ステップ3602において、着信データに対するデータヘッダが読み出される。ステップ3603において、送信機は、読み出されたデータヘッダと関連付けられた非直列化データブロブを取得する。ステップ3604において、送信機は、作成されたソケットからデータブロブのデータ部分を読み出す。ステップ3605において、送信機は、読み出されたデータ部分をデータ記憶装置に書き込む。3606において、送信機は、データ部分がデータブロブの最後のデータ部分であるかを判定する。データ部分が最後のデータ部分ではないと判定される場合、送信機が次のデータ部分をデータ記憶装置に書き込むステップ3605に戻る。データ部分が最後のデータ部分であると判定される場合、ステップ3607に進む。ステップ3607において、送信機は、データヘッダが受信されるデータに対する最後のデータヘッダであるかを判定する。データヘッダが最後のデータヘッダである場合、応答が完了するステップ3608。図37は、サーバにおけるデータ交換を示すシーケンス図である。図37に示されるように、3701及び3702において、:DataBlobDeserializerQueueオブジェクトは、ServerConnectionオブジェクトからgetDataBlobMessages.Header:DataBlobDeserializerを継承する。3703及び3704において、:DataBlobDeserializerオブジェクトは、:ServerConnectionオブジェクトからdeserializerInputStreamを継承する。3705及び3706において、:ServerSessionオブジェクトは、:ServerConnectionオブジェクトからsetCompletionStateREQUESTを継承する。3707において、<<interface>>:Dispatcherオブジェクトは、:ServerSessionオブジェクトからdoWorkServerSessionを継承する。3708において、:DataBlobDeserializerQueueは、<<interface>>:DispatcherオブジェクトからgetDataBlobs:DataBlobDeserializerを継承する。3708において、:DataBlobDeserializerQueueは、<<interface>>:DispatcherオブジェクトからgetDataBlobs:DataBlobDeserializerを継承する。3709において、:DataBlobDeserializerオブジェクトは、<<interface>>:DispatcherオブジェクトからgetData:InputStreamを継承する。3710及び3711において、:DataBlobDeserializerQueueオブジェクト及び:DataBlobDeserializerオブジェクトはdisposeを継承する。3712において、:DataBlobSerializerQueueオブジェクトは、<<interface>>:DispatcherオブジェクトからaddDataBlobDataBlobSerializerを継承する。3713及び3714において、:DataBlobSerializerQueueオブジェクトは、:ServerConnectionオブジェクトからgetNextDataBlobDataBlobSerializer:DataBlobSerializerを継承する。3715及び3716において、:DataBlobSerializerオブジェクトは、:ServerConnectionオブジェクトからserializeOutputStreamを継承する。3717及び3718において、:ServerSessionは、:ServerConnectionオブジェクトからsetCompletionStateRESPONSEを継承する。3719及び3720において、:DataBlobSerializerQueueオブジェクト及び:DataBlobSerializerオブジェクトは、closeを継承する。図38及び図39は、受信機におけるデータ交換を一般的に説明するフローチャートである。図38において、ステップ3801で受信したデータへの応答が実行される。ステップ3802において、着信データに対するデータヘッダが読み出される。ステップ3803において、受信機は、読み出されたデータヘッダと関連付けられた非直列化データブロブを取得する。ステップ3804において、受信機は、作成されたソケットからデータブロブのデータ部分を読み出す。ステップ3805において、受信機は、読み出されたデータ部分をデータ記憶装置に書き込む。3806において、受信機は、データ部分がデータブロブの最後のデータ部分であるかを判定する。データ部分が最後のデータ部分ではないと判定される場合、受信機が次のデータ部分をデータ記憶装置に書き込むステップ3805に戻る。データ部分が最後のデータ部分であると判定される場合、ステップ3807に進む。ステップ3807において、受信機は、データヘッダが受信されるデータに対する最後のデータヘッダであるかを判定する。データヘッダが最後のデータヘッダである場合、応答が完了するステップ3808。図39のステップ3901において、データを送出するための要求を開始する。ステップ3902において、受信機は、取得するための次に使用可能な直列化データブロブがあるかを判定する。次に使用可能なデータブロブがある場合、受信機は、データブロブに対してデータヘッダを書き込みステップ3903、データのソースからデータブロブのデータ部分を読み出しステップ3904、読み出されたデータ部分を作成されたソケットに書き込むステップ3905。ステップ3906において、受信機は、データ部分がデータブロブの最後のデータ部分であるかを判定する。データ部分が最後のデータ部分ではない場合、受信機は、データブロブの次のデータ部分を作成されたソケットに書き込むステップ3905。ステップ3906でデータ部分が最後のデータ部分である場合、ステップ3902に戻る。次に使用可能な直列化データブロブがないとステップ3902で判定される場合、要求が完了しステップ3907、受信したデータへの応答が実行されるステップ3908。[送信機と受信機との間の接続の数のオートチューニング]図40は、別の実施形態の例を詳細に説明するフローチャートである。より具体的には、図40は、図1に示されたようなネットワーク120を介した送信機101から送信機101に接続された受信機102への大量のデータ転送に対する一実施形態の例を詳細に説明するフローチャートを示す。図40に示されるように、ステップ4001及び4002において、ネットワーク120を介して送信機101と受信機102との間に複数の接続が確立される。これらの接続は、並列TCP接続等であってよいが、複数の接続はTCP接続に限定されず、並列接続を使用する他のプロトコルが使用されてもよい。ステップ4003において、データは、ネットワーク120の帯域幅の利用を集約するように複数の接続を介してデータを分割して送出することで送信機101から受信機102に送出される。ステップ4004において、受信機102は、複数の接続を介して分割データを受信し、分割データを元の形式に再結合する。ステップ4005~4010において、送信機101と受信機102との間の接続の数、並びに送信機101におけるI/Oストレージシステムの少なくとも1つの性能、受信機102におけるI/Oストレージシステムの性能及びネットワーク120の性能に基づいてオートチューニングが実行される。オートチューニングが実行され、データの理想的で効率的なスループットを提供するように送信機と受信機との間の最適な数の接続を提供する。特に、ステップ4005において、データが図2に示されたようなオートチューニングソフトウェア236を介するネットワーク120を介して送出されているよりも速く送信機101のI/Oストレージシステムがデータを読み出しているかを判定する。例えば、送信機101のI/Oストレージシステムが送信機のメモリバッファにデータを入力している速度の計算と、データがネットワーク120からの送信機のメモリバッファから取り出されている速度の計算とを比較することにより、このような判定を行う。データがネットワーク120を介して送出されているよりも速く送信機101のI/Oストレージシステムがデータを読み出していることがステップ4005で判定される場合、送信機101が新しい接続を開くための要求を受信機102に送出する送信機101と受信機102との間の接続の数に対してオートチューニングを実行する。新しい接続を開くための要求が成功であったという応答を受信機102が返送する場合、送信機101は、システムにおいてデータの平滑な流れを提供するように新しい接続を介してデータを送出できる。新しい接続を開くための要求を送出する場合、送信機101は、1つ以上の新しい接続が開かれることを要求してもよい。しかし、多くの新しい接続が開かれることを送信機101が要求する場合、受信機102は、以下に更に詳細に説明する多くの種々の理由のために、全ての新しい接続を開くための要求を拒否してもよい。データがネットワーク120を介して送出されているよりも速く送信機101のI/Oストレージシステムがデータを読み出していないことがステップ4005で判定される場合、ステップ4006に進む。ステップ4006において、データがネットワーク120を介して送出されているよりも遅く送信機101のI/Oシステムがデータを読み出しているかを判定する。データがネットワーク120を介して送出されているよりも遅く送信機101のI/Oシステムがデータを読み出しており、且つ図1の送信機131及び132のうちのいずれか等の2つ以上の送信機が受信機102にデータを送出していると判定される場合、送信機101は、複数の接続の既存の接続を閉じ、送信機101と受信機102との間の接続の数をオートチューニングする。この点に関して、既存の接続を閉じることは、一次接続ではなく二次接続を閉じることである。上記の結果、送信機101は、データを送出するために送信機101により最大限に利用されていない受信機102におけるソケットの占有を実質的に回避してもよい。低い利用度を有する送信機のメモリバッファを確認することにより、例えば、メモリバッファの利用度がある特定の期間例えば、30秒低いままであり、メモリバッファサイズの合計の所定の閾値例えば、30を下回ったままである場合、送信機は、データが送出されているよりも遅く自身がデータを読み出していると結論付けてよい。同様に、メモリの利用度がある期間の間高く且つその時間フレーム中に閾値例えば、メモリバッファの80が使用されているに到達する場合、送信機は、データがネットワーク120を介して送出されているよりも速く送信機101のI/Oシステムがデータを読み出していると結論付けてよい。ステップ4009において、大量のデータ転送に対する障害が受信機102のI/Oストレージシステムに存在するかがオートチューニングソフトウェア336により検出される。大量のデータ転送に対する障害が受信機102のI/Oストレージシステムに存在することが検出される場合、受信機102が既存の接続すなわち、二次接続を閉じる送信機101と受信機102との間の接続の数に対してオートチューニングを実行する。受信機102は、1つ以上の既存の二次接続を閉じてよい。送信機101は、送信機101におけるバッファがほぼ満杯であることを検出する場合、新しい接続を開くための要求を受信機に送出してもよいか、あるいは既に作成されているが現在データを送出するために使用されていない接続を利用する。送信機におけるバッファがほぼ満杯である場合に新しい接続を開くことは、送信機からデータを送出する際の遅延又は間隔を減少できるために全体的に平滑なデータ転送を提供するという有利な影響を及ぼす。あるいは、送信機101は、大量のデータ転送に対する障害が送信機のI/Oストレージシステムに存在することを検出する場合、既存の二次接続を閉じてもよい。送信機101におけるバッファがほぼ空である場合、送信機101のI/Oストレージシステムにおける大量のデータ転送に対する障害ありと検出する。場合によっては、受信機102のI/Oストレージシステムは、図6のディスク609等のディスクを含む。これらの例において、ディスクのシーク動作が受信機102のI/Oストレージシステムに対して実行される時に受信機102のI/Oストレージシステムにおける大量のデータ転送に対する障害ありと検出する。より具体的には、複数の接続が使用されているため、データは、受信機102において順番に到着しなくてもよい。受信機102が次の連続データチャンクを待って時間切れになるかあるいはそのメモリバッファを満たす場合、受信機102のI/Oストレージシステムは、更なるシーク動作を後で必要とする可能性のある故障データに対するディスク書き込みを実行してもよい。これは、受信機101のI/Oストレージシステムがデータをディスクに書き込んでいるよりも速く送信機101から受信機102にデータが転送されていることを意味するだろう。従って、障害は、受信機102のI/Oストレージシステムに存在するだろう。あるいは、受信機102のI/Oシステムがディスクを含むこれらの例において、受信機102のI/Oストレージシステムが前のI/O書き込み速度よりも遅くデータをディスクに書き込んでいる時に受信機102のI/Oストレージシステムにおける大量のデータ転送に対する障害ありと検出する。前のI/O書き込み速度は、2回以上の書き込み動作に対して前に測定されたI/O書き込み速度又は書き込み動作の期間中に前に測定されたI/O書き込み速度、あるいは書き込み動作の前に測定されたI/O書き込み速度の加重平均に基づいてよい。例えば、受信機のI/Oストレージシステムの前のI/O書き込み速度が10Mb/sであり、且つ受信機のI/Oストレージシステムが現在5Mb/sでデータを書き込んでいる場合、障害は、受信機のI/Oストレージシステムに存在するだろう。例えば受信機のI/Oストレージシステムが他の非MDTアプリケーションを処理している場合、I/Oストレージシステムの書き込み速度は低下する可能性がある。ステップ4010において、データがネットワーク120から受信されるよりも速く受信機102のI/Oストレージシステムがデータを書き込んでいるかを判定する。例えば、受信機102のI/Oストレージシステムが受信機102のメモリバッファからデータを書き出している速度の計算と、データがネットワーク120により受信機102のメモリバッファに入力されている速度の計算とを比較することにより、このような判定を行ってよい。データがネットワーク120から受信されるよりも速く受信機102のI/Oストレージシステムがデータを書き込んでいると判定される場合、受信機102は、新しい接続図5に示されたようなACK機構を介してを開くように送信機に命令又は提案する。図40のステップ4010において、データがネットワーク102から受信されるよりも速く受信機102のI/Oストレージシステムがデータを書き込んでいないと判定される場合、ステップ4013に進む。ステップ4013において、受信機102は、送信機101により送出される全てのデータを自身が受信しているかを判定する。全てのデータが受信機102により受信されている場合、処理は終了するステップ4014。全てのデータが受信機102により受信されていない場合、ステップ4004に進む。ステップ4007において、送信機101は、大量のデータ転送に対する障害がネットワーク120に存在するかを検出する。ステップ4007で大量のデータ転送に対する障害がネットワーク120に存在することが検出される場合、送信機101は、送信機101と受信機102との間の既存の接続を閉じる。ネットワークにおける大量のデータ転送の障害が輻輳により発生する場合、既存の二次接続を閉じることでネットワークにおける更なる輻輳を減少できる。ステップ4007において、現在のラウンドトリップ時間RTTが前のRTTよりも長い場合、ネットワークにおける大量のデータ転送に対する障害ありと検出する。現在のRTT及び前のRTTは、2つ以上のメッセージパッケージに対するRTT又はRTTの加重平均に基づいてよい。現在のRTTが実質的に前のRTTよりも長い例えば、20場合、ネットワークは、使用中であり且つ他の送信機/受信機システムからのより多くのトラフィックを有するだろう。ネットワークが使用中である場合に既存の接続を閉じることにより、使用中のネットワークを介して更に多くのデータを送出することで発生するこれ以上の輻輳を減少してもよい。一例において、荷重測定のサンプルは以下のように見えてもよい。すなわち、n0~n9等の10個のRTTシーケンスサンプルがある場合、荷重RTT測定は、1番目:n0、2番目:n00.8n10.2、3番目2番目:0.8n20.2、4番目:3番目0.8n30.2、...、10番目:n90.8n90.2である。ステップ4007で大量のデータ転送に対する障害がネットワーク120において検出されない場合、ステップ4008に進む。ステップ4008において、現在のラウンドトリップ時間RTTが前のRTTから実質的に短縮されているかを判定する。現在のRTT及び前のRTTは、2つ以上のメッセージパッケージに対するRTT又はRTTの加重平均に基づいてよい。現在のRTTが前のRTTから実質的に短縮されているとステップ4008で判定される場合、送信機101は、新しい接続を開くための要求を受信機102に送出する。RTTを短縮することは、ネットワークの性能が向上していることを示す。従って、送信機101は、データのスループットを向上するために1つ以上の新しい接続を開きたい。いくつかの状況において、送信機101及び受信機102におけるバッファサイズは、ネットワークにおける障害の検出又は受信機のI/Oストレージシステムにおける障害の検出に従って調整されてよい。特に本実施形態の例において、送信機におけるバッファのサイズは、バッファにデータが溢れるのを回避できるように拡大されてよい。上述の実施形態の例により、通常、送信機及び受信機が理想的なスループットを提供することで大量のデータ転送に対する性能を向上するように接続の数を動的に増減する自己校正を提供することが可能である。また、多数の送信機/受信機構成にわたり公平性が保たれる。例えば、現在の並列接続の数が余剰のネットワーク帯域幅を集約しているために現在の障害が受信機のシステムI/Oである場合、接続のうちのいくつかは、他の送信機/受信機システムが使用するための帯域幅をリリースするように閉じられてよい。他の実施形態の例において、各々が複数の大量のデータ転送のうちのそれぞれ1つを受信機102に送出する複数の送信機が存在する。例えば、図1に示されたように、送信機131及び132の各々は、送信機101が大量のデータ転送を受信機102に送出しているのとほぼ同時に大量のデータ転送を受信機102に更に送出していてもよい。これらの実施形態の例において、ネットワーク120を介して送信機101と受信機102との間に複数の接続を確立する場合、受信機102は、送信機131及び132等の他の送信機から要求された接続の数に基づいて送信機101と受信機102との間に確立されうる最大数の接続を設定する。例えば、全ての送信機が共有できる最大20個の接続を受信機102が有し、且つ他の送信機が現在20個の接続のうちの15個を利用している場合、受信機102は、送信機101が他の送信機により使用されている15個の接続に基づいてデータを転送するために使用してもよい最大5個の接続を設定してもよい。いくつかの例において、ネットワーク120を介して送信機101と受信機102との間の複数の接続を確立する場合、受信機102は、他の送信機から要求された接続の数に基づいて最大数の接続が確立されうる期間を設定する。更に受信機102は、他の送信機から要求された接続の数に基づいて確立されうる最大数の接続のうちの各接続を確立するための開始時間を設定してもよい。例えば、最大3個の接続が受信機102により設定される場合、第1の二次接続は、一次接続が確立された1分後に確立され且つ4分間続いてもよく、第2の二次接続は、一次接続が確立された2分後に確立され且つ2分間続いてもよい。いくつかの状況において、ジョブキューは、要求された接続の入力数と比較して、全ての複数の送信機間に存在する現在の接続の数を管理する受信機102に含まれたスケジュールマネージャすなわち、図3のスケジュールマネージャ338により維持される。更にスケジュールマネージャは、複数の送信機の各々に優先度を割り当てる。この点に関して、スケジュールマネージャは、より少ない数の接続をより優先度の低い送信機に割り当てることと比較して、より多くの数の接続をより優先度の高い送信機に割り当てる。例えば、より優先度の高い送信機は、より小さなデータセットを有するより優先度の低い送信機と比較して大きなデータセットを有する送信機であってもよい。この例において、より大きなデータセットを有するより優先度の高い送信機は、より小さなデータセットを有するより優先度の低い送信機よりも多くの数の接続を割り当てられるだろう。更に送信機は、データがネットワークを介して送出されているよりも速く送信機のI/Oストレージシステムがデータを読み出している時に1つ以上の接続を開くための要求を受信機に送出してもよい。接続の数をオートチューニングする場合、受信機は、1つ以上の接続がスケジュールマネージャにより使用可能であると判定される場合に要求された1つ以上の接続を開く。更に送信機は、現在のラウンドトリップ時間RTTが前のRTTから実質的に短縮されている時に1つ以上の接続を開くための要求を受信機に送出してもよい。現在のRTT及び前のRTTは、2つ以上のメッセージパッケージに対するRTT又はRTTの加重平均に基づいてよい。接続の数をオートチューニングする場合、受信機は、1つ以上の接続がスケジュールマネージャにより使用可能であると判定される場合に要求された1つ以上の接続を開く。この点に関して、接続は、スケジュールマネージャにより設定された期間の間開かれ且つ閉じられる。スケジュールマネージャにより設定された期間は、種々の接続毎に異なる期間であってもよい。最後に、各接続は異なる開始時間において開かれてもよい。多数の要求が種々の送信機から受信機102により受信される場合、各送信機は、その処理能力により制限された種々の転送速度でデータを送出してよい。スケジュールマネージャ338は、ファイルデータサイズと共に受信する送信機の数及びデータ速度この値は事前に使用可能であってもよいに基づいて、公平性を保ち且つ全体的なシステムスループットを向上できる。既存のデータ転送要求の処理中に新しい要求が受信される場合、受信機102は、後の要求を受け入れ、且つ第2の要求に対するセッションに参加できるセッションidと共に通知された接続の数を返送できる。受信機は、データの処理及びI/Oストレージシステムへの書き込みの途中である場合、参加セッション要求の履行が終わり次第値を待つ時間と共に通知された接続の数を返送してもよい。一方、受信機は、第1の要求に残されたデータの量が第2の要求において転送するデータの量より大幅に少ないことを認識する場合、第1の要求に対する接続の数を減少し且つ第2の要求に対して許可された接続の数を増加できる。更に受信機102は、第2の要求に残されたデータの量が第1の要求において転送するデータの量より大幅に少ないことを認識する場合、第2の要求に対する接続の数を減少し且つ第1の要求に対して許可された接続の数を増加できる。スケジュールマネージャ338は、要求を更に優先できるすなわち、より優先度の高い新しい要求は、別の要求の処理中に到着する。これは、メッセージレベルでアプリケーションポリシーと結び付けて実行されてよく、あるいは転送データレベルで送出されるデータと結び付けて実行されてよい。本明細書は、例示した特定の実施形態を詳細に説明した。添付の特許請求の範囲の範囲は上述の実施形態に限定されず、且つ種々の変更及び変形が特許請求の範囲の範囲から逸脱せずに当業者により行われてもよいことが理解される。また、本願は、ここに編入される、2010年8月31日に出願された米国特許出願第12/873305号からの優先権を請求するものである。"