JP5767706B2 - データの送信方法、送信機、受信機、並びにプログラム - Google Patents

Description

本発明は、一般に、ネットワークを介した送信機から受信機へのデータ転送に関し、特に、並列データプロトコルを使用するネットワークを介した送信機から受信機への大量のデータ転送に関する。

送信機及び受信機が１つ以上のネットワークを介して通信する送信機／受信機システムにおいてデータを転送する場合、並列データプロトコルは、送信機／受信機システムにおいて大量のデータ転送のために使用可能である。送信機／受信機システムの例には、クライアント／サーバシステム及びピアツーピアシステムが含まれる。そのような送信機／受信機システムにおいて、複数のＴＣＰ接続等の送信機と受信機との間の複数の並列接続を開くことが以前から考えられてきた。複数の接続を開く目的は、使用可能なネットワークの帯域幅を集約することである。より厳密には、送信機と受信機との間の単一の接続は、所定のネットワークにおいて使用可能な全ての帯域幅を使用しなくてもよい。複数の並列接続を開くことにより、あらゆる１つの特定のネットワークにおいて帯域幅を最大限利用することが可能になる。

帯域幅の集約に関する１つの問題は、使用可能にされた帯域幅の量が非常に多いためにデータを格納する受信機の能力又は送信のためにデータを検索する送信機の能力を上回ることである。そのようなデータ転送において、送信機から受信機へのデータ転送のボトルネック（障害）は、使用可能なネットワーク帯域幅の不足によりもたらされるものではないだろう。特に、余剰の使用可能な帯域幅がある状況において、データ転送のボトルネックは、実際にはデータをディスクに読み込み且つ書き込む物理的Ｉ／Ｏである。

Ｉ／Ｏストレージシステムの帯域幅がボトルネックである場合、多数の並列接続を使用して帯域幅を集約するシステムは、自身が使用できるより多くの使用可能なネットワークソケットを独占する。そのような構成は、同一の通信ネットワークを介して動作する他の送信機／受信機システムに対して不公平である。

本発明において、Ｉ／Ｏストレージシステムの性能に基づいて、ネットワークを介した送信機と送信機に接続された受信機との間の接続の数をオートチューニングすることで上述の問題に対処する。接続の数は、２つのシステム間の最適な数の接続を確立するように接続を開き且つ／あるいは閉じることでオートチューニングされる。オートチューニングは、特に、大量のデータ転送に対するボトルネックが受信機のＩ／Ｏストレージシステムに存在することを受信機が検出した時に既存の接続を閉じ、且つネットワークからデータを受信するよりも速く受信機のＩ／Ｏストレージシステムがデータを書き込んでいる時に新しい接続を開くことで実行可能となる。また、送信機と受信機との間の接続の数は、データがネットワークを介して送出されているよりも速く送信機のＩ／Ｏストレージシステムがデータを読み出している時に新しい接続を開き、且つデータがネットワークを介して送出されているよりも遅く送信機のＩ／Ｏストレージシステムがデータを読み出しており且つ２つ以上の送信機がデータを受信機に送出している時に既存の接続を閉じることでオートチューニングされる。

従って、本明細書で説明する一実施形態の例において、複数の接続は、ネットワークを介して送信機と受信機との間で確立される。複数の接続は、複数のＴＣＰ接続等であってもよい。データは、ネットワークの帯域幅の利用を集約するように複数の接続を介してデータを分割して送出することで送信機から受信機に送出される。送信機と受信機との間の最適な数の接続は、大量のデータ転送に対するボトルネックが受信機のＩ／Ｏストレージシステムに存在することを受信機が検出した時に既存の接続を閉じることでオートチューニングされる。この点に関して、既存の接続を閉じることは、一次接続ではなく二次接続を閉じることである。接続の数は、ネットワークからデータを受信するよりも速く受信機のＩ／Ｏストレージシステムがデータを書き込んでいる時に新しい接続を開くことで更にオートチューニングされる。また、送信機と受信機との間の接続の数は、データがネットワークを介して送出されているよりも速く送信機のＩ／Ｏストレージシステムがデータを読み出している時に新しい接続を開くことでオートチューニングされる。接続の数は、データがネットワークを介して送出されているよりも遅く送信機のＩ／Ｏストレージシステムがデータを読み出しており且つ２つ以上の送信機がデータを受信機に送出している時に既存の接続を閉じることで更にオートチューニングされる。

上述の構成により、通常、送信機及び受信機が理想的なスループットを提供することで大量のデータ転送に対する性能を向上するように接続の数を動的に増減する自己校正を提供することが可能である。また、多数の送信機／受信機構成にわたり公平性が保たれる。例えば、現在の並列接続の数が余剰のネットワーク帯域幅を集約しているために現在のボトルネックが受信機のシステムＩ／Ｏである場合、接続のうちのいくつかは、他の送信機／受信機システムが使用するための帯域幅をリリースするように閉じられる。

本明細書で更に説明する一実施形態の例において、受信機のＩ／Ｏストレージシステムはディスクを含む。本実施形態の例において、接続の数をオートチューニングする場合、ディスクのシーク動作が受信機のＩ／Ｏストレージシステムに対して実行される時に受信機のＩ／Ｏストレージシステムにおける大量のデータ転送に対するボトルネックありと検出する。より具体的には、複数の接続が使用されているため、データは、受信機において順番に到着しなくてもよい。受信機が次の連続データチャンクを待って時間切れになる場合、受信機のＩ／Ｏストレージシステムは、更なるシーク動作を必要とする可能性のある故障データに対するディスク書き込みを実行してもよい。一般にこれは、受信機のＩ／Ｏストレージシステムがデータをディスクに書き込んでいるよりも速くデータが送信機から受信機に転送されていることを意味する。従って、ボトルネックは、受信機のＩ／Ｏストレージシステムに存在するだろう。

本明細書で説明する更なる一実施形態の例において、受信機のＩ／Ｏストレージシステムはディスクを含む。更なる本実施形態の例において、接続の数をオートチューニングする場合、受信機のＩ／Ｏストレージシステムが前のＩ／Ｏ書き込み速度よりも遅くデータをディスクに書き込んでいる時に受信機のＩ／Ｏストレージシステムにおける大量のデータ転送に対するボトルネックありと検出する。前のＩ／Ｏ書き込み速度は、２回以上の書き込み動作に対して前に測定されたＩ／Ｏ書き込み速度又は書き込み動作の期間中に前に測定されたＩ／Ｏ書き込み速度、あるいは書き込み動作の前に測定されたＩ／Ｏ書き込み速度の加重平均に基づいてよい。例えば、受信機のＩ／Ｏストレージシステムの前のＩ／Ｏ書き込み速度が１０Ｍｂ／ｓであり、且つ受信機のＩ／Ｏストレージシステムが現在５Ｍｂ／ｓでデータを書き込んでいる場合、ボトルネックは、受信機のＩ／Ｏストレージシステムに存在するだろう。例えば受信機のＩ／Ｏストレージシステムが他の非ＭＤＴアプリケーションを処理している場合、Ｉ／Ｏストレージシステムの書き込み速度は低下するだろう。

本明細書で説明する別の実施形態の例において、接続の数をオートチューニングすることは、大量のデータ転送に対するボトルネックがネットワークに存在することを送信機が検出する場合に送信機と受信機との間の既存の接続を送信機により閉じることを更に含む。その結果、ネットワークの更なる輻輳を減少できる。本実施形態の例において、現在のラウンドトリップ時間（ＲＴＴ）が前のＲＴＴよりも長い場合、ネットワークにおける大量のデータ転送に対するボトルネックありと検出する。現在のＲＴＴ及び前のＲＴＴは、２つ以上のメッセージパッケージに対するＲＴＴ又はＲＴＴの加重平均に基づいてよい。現在のＲＴＴが実質的に前のＲＴＴよりも長い場合、ネットワークは、使用中であり且つ他の送信機／受信機システムからのより多くのトラフィックを有するだろう。ネットワークが使用中である場合に既存の接続を閉じることにより、使用中のネットワークを介して更に多くのデータを送出することで発生するこれ以上の輻輳を減少してもよい。

本明細書で説明する更なる一実施形態の例において、接続の数をオートチューニングすることは、大量のデータ転送に対するボトルネックが送信機のＩ／Ｏストレージシステムに存在することを送信機が検出する場合に送信機と受信機との間の既存の接続を閉じることを更に含む。送信機におけるバッファがほぼ空である場合、送信機のＩ／Ｏストレージシステムにおける大量のデータ転送に対するボトルネックありと検出する。

本明細書で説明する更なる一実施形態の例において、送信機は、送信機におけるバッファがほぼ満杯であることを検出する場合、新しい接続を開くための要求を受信機に送出するか、あるいは既に作成されているが現在データを送出するために使用されていない接続を利用する。送信機におけるバッファがほぼ満杯である場合に新しい接続を開くことは、送信機からデータを送出する際の遅延又は間隔を減少できるために全体的に平滑なデータ転送を提供するという有利な影響を及ぼす。いくつかの状況において、送信機及び受信機におけるバッファサイズは、ネットワークにおけるボトルネックの検出又は受信機のＩ／Ｏストレージシステムにおけるボトルネックの検出に従って調整されうる。特に、本実施形態の例において、送信機におけるバッファのサイズは、バッファにデータが溢れるのを回避できるように拡大されてよい。

本明細書で説明する別の実施形態の例によれば、各々が複数の大量のデータ転送のうちのそれぞれ１つを受信機に送出している複数の送信機が存在する。本実施形態の例において、ネットワークを介して送信機と受信機との間に複数の接続を確立する場合、受信機は、他の送信機から要求された接続の数に基づいて送信機と受信機との間に確立されうる最大数の接続を設定する。例えば、全ての送信機が共有できる最大２０個の接続を受信機が有し、且つ他の送信機が現在２０個の接続のうちの１５個を利用している場合、受信機は、送信機が他の送信機により使用されている１５個の接続に基づいてデータを転送するために使用してもよい最大５個の接続を設定してもよい。更に本実施形態の例において、受信機は、他の送信機から要求された接続の数に基づいて最大数の接続が確立されうる期間を設定する。更に受信機は、他の送信機から要求された接続の数に基づいて確立されうる最大数の接続のうちの各接続を確立するための開始時間を設定する。例えば、最大３個の接続が受信機により設定される場合、第１の二次接続は、一次接続が確立された１分後に確立され且つ４分間続いてもよく、第２の二次接続は、一次接続が確立された２分後に確立され且つ２分間続いてもよい。

本明細書で説明する更なる一実施形態の例において、ジョブキューは、要求された接続の入力数と比較して、全ての複数の送信機間に存在する現在の接続の数を管理するスケジュールマネージャにより維持される。更にスケジュールマネージャは、複数の送信機の各々に優先度を割り当てる。この点に関して、スケジュールマネージャは、より少ない数の接続をより優先度の低い送信機に割り当てることと比較して、より多くの数の接続をより優先度の高い送信機に割り当てる。

本明細書で説明する別の実施形態の例によれば、送信機は、データがネットワークを介して送出されているよりも速く送信機のＩ／Ｏストレージシステムがデータを読み出している時に１つ以上の接続を開くための要求を受信機に送出する。接続の数をオートチューニングする場合、受信機は、１つ以上の接続がスケジュールマネージャにより使用可能であると判定される場合に要求された１つ以上の接続を開く。

本明細書で説明する更なる一実施形態の例によれば、送信機は、現在のラウンドトリップ時間（ＲＴＴ）が前のＲＴＴから実質的に短縮されている時に１つ以上の接続を開くための要求を受信機に送出する。現在のＲＴＴ及び前のＲＴＴは、２つ以上のメッセージパッケージに対するＲＴＴ又はＲＴＴの加重平均に基づいてよい。接続の数をオートチューニングする場合、受信機は、１つ以上の接続がスケジュールマネージャにより使用可能であると判定される場合に要求された１つ以上の接続を開く。

この簡単な発明の概要は、本発明の特性を迅速に理解できるように提供されている。以下の詳細な説明及び添付の図面を参照することにより、より完全に理解される。

一実施形態の例のアーキテクチャが実現されてもよいネットワークを介して接続された複数の送信機及び受信機を示す図である。 図１の送信機の内部アーキテクチャを説明する詳細なブロック図である。 図１の受信機の内部アーキテクチャを説明する詳細なブロック図である。 一実施形態の例に従って、送信機と受信機との間の一次接続の確立を説明する送信機及び受信機を示す図である。 一実施形態の例に従って、送信機と受信機との間の二次接続の確立を説明する送信機及び受信機を示す図である。 一実施形態の例に従って、セッションにおける接続の数を増加又は減少するように送信機に通知する受信機を説明するシーケンス図である。 一実施形態の例に従って、送信機から受信機へのデータの送出を一般的に説明する送信機及び受信機を示す別の図である。 一実施形態の例に係る転送送信機を示すクラス図である。 一実施形態の例に係る転送受信機を示すクラス図である。 一実施形態の例に係るサーバディスパッチャを示すクラス図である。 一実施形態の例に係るデータソースを示すクラス図である。 一実施形態の例に係るクライアント対話を示すクラス図である。 一実施形態の例に係るサーバ対話を示すクラス図である。 、 、 、 、 、 、 、 「ｐｕｔ」の例におけるクライアント側を示すシーケンス図である。 、 、 、 、 、 「ｐｕｔ」の例におけるプロバイダ側を示すシーケンス図である。 、 、 「ｇｅｔ」の例におけるクライアント側を示すシーケンス図である。 、 、 「ｇｅｔ」の例におけるプロバイダ側を示すシーケンス図である。 、 、 「ｇｅｔ」動作を取り消すクライアント側を示すシーケンス図である。 、 、 「ｇｅｔ」動作を取り消すプロバイダ側を示すシーケンス図である。 、 、 「ｐｕｔ」動作を取り消すクライアント側を示すシーケンス図である。 、 、 「ｐｕｔ」動作を取り消すプロバイダ側を示すシーケンス図である。 図１の受信機のＩ／Ｏストレージシステムにおける書き込み動作を示す図である。 図２１に示されたようなＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１を示す図である。 図１の受信機のＩ／Ｏストレージシステムにおける書き込み動作を示す別の図である。 図１の送信機１０１のＩ／Ｏストレージシステムにおけるデータ転送のボトルネックを検出するシーケンス図である。 図１の送信機１０１のＩ／Ｏストレージシステムにおける読み出し動作を示す図である。 一実施形態の例に係るサーバを示すクラス図である。 一実施形態の例に係るクライアントを示すクラス図である。 一実施形態の例に係るデータシリアライザを示すクラス図である。 一実施形態の例に係るデータデシリアライザを示すクラス図である。 、 、 クライアントにおいてセッションを確立するシーケンス図である。 一実施形態の例に従って、送信機における開始セッションの確立を説明するフローチャートである。 一実施形態の例に従って、送信機における参加セッションの確立を説明するフローチャートである。 、 、 、 サーバにおいてセッションを確立するシーケンス図である。 一実施形態の例に従って、受信機におけるセッションの確立を説明するフローチャートである。 、 、 、 、 クライアントにおけるデータ交換を示すシーケンス図である。 、 送信機におけるデータ交換を説明するフローチャートである。 、 、 、 、 サーバにおけるデータ交換を示すシーケンス図である。 、 受信機におけるデータ交換を説明するフローチャートである。 別の実施形態の例を詳細に説明するフローチャートである。

図１は、一実施形態の例のアーキテクチャが実現されてもよいネットワークを介して接続された複数の送信機及び受信機を示す図である。図１に示されるように、送信機１０１、１３１及び１３２は、ネットワーク１２０を介して受信機１０２に接続される。より具体的には、送信機１０１は、ネットワークインタフェース１１１を介してネットワーク１２０に接続され、送信機１３１は、ネットワークインタフェース１１２を介してネットワーク１２０に接続され、送信機１３２は、ネットワークインタフェース１１３を介してネットワーク１２０に接続され、受信機１０２は、ネットワークインタフェース１１４を介してネットワーク１２０に接続される。図１において、送信機１０１、１３１及び１３２は、１つのネットワークを介して接続するように示されるが、他の実施形態の例において、送信機１０１、１３１及び１３２、並びに受信機１０２は、２つ以上のネットワークを介して接続されてよい。また、ネットワーク１２０又は多数のネットワークに接続された３つを上回るかあるいは下回る送信機及び２つ以上の受信機が存在してもよい。

ネットワーク１２０は、イントラネットであるが、他の実施形態の例において、インターネット又はデータを転送する他のあらゆる適切な種類のネットワークであってよい。

送信機１０１、１３１及び１３２は、ネットワークを介して大量のデータ転送を実行できるデバイスである。しかし、送信機１０１、１３１及び１３２は、データを送出することに限定されず、転送されたデータを受信できるデバイスであってもよい。例えば送信機１０１、１３１及び１３２は、コンピュータ又はネットワークを介して大量のデータ転送を実行できる他のあらゆるデバイスであってよい。更に送信機１０１、１３１及び１３２は、クライアント／サーバシステムにおけるクライアントデバイス又はピアツーピアシステムにおけるピアデバイスであってもよい。

受信機１０２は、ネットワークを介して大量のデータ転送を送受信できるデバイスである。例えば受信機１０２は、コンピュータ又はネットワークを介して大量のデータ転送を実行できる他のあらゆるデバイスであってよい。更に受信機１０２は、クライアント／サーバシステムにおけるサーバデバイス又はピアツーピアシステムにおけるピアデバイスであってもよい。

ネットワークインタフェース１１１〜１１４は、有線又は無線の物理インタフェースであってよい。ネットワークインタフェース１１１〜１１４の各々は、ネットワーク１２０との１つ以上のソケット接続を確立するように１つ以上のポートを含む。

図２は、図１の送信機１０１、１３１及び１３２の各々の内部アーキテクチャを説明する詳細なブロック図である。図２に示されるように、送信機１０１、１３１及び１３２の各々は、コンピュータバス２００とインタフェースする中央処理装置（ＣＰＵ）２０２を備えてもよい。また、コンピュータバス２００とインタフェースするものには、ハード（又は固定）ディスク２２０、ネットワークインタフェース１１１、１１２又は１１３、メインランタイム一時メモリとして使用するためのランダムアクセスメモリ（ＲＡＭ）２０８及び読み出し専用メモリ（ＲＯＭ）２１０がある。

ＲＡＭ２０８は、オペレーティングシステム、アプリケーションプログラム及びインタフェースドライバ等のソフトウェアプログラムにおける命令の実行中にＲＡＭ２０８に格納された情報をＣＰＵ２０２に提供するようにコンピュータバス２００とインタフェースする。より具体的には、最初にＣＰＵ２０２は、固定ディスク２２０からコンピュータが実行可能な処理ステップをロードするか、あるいは別の記憶装置をＲＡＭ２０８の領域にロードする。次にＣＰＵ２０２は、ロードされたコンピュータが実行可能な処理ステップを実行するためにＲＡＭ２０８から格納された処理ステップを実行してよい。また、収集されたネットワーク性能の統計又は他の情報等のデータは、コンピュータが実行可能なソフトウェアプログラムがデータにアクセスし且つ／あるいはデータを修正する必要がある程度まで、そのようなソフトウェアプログラムの実行中にＣＰＵ２０２がアクセスできるようにＲＡＭ２０８に格納されてよい。

図２に更に示されるように、ハードディスク２２０は、オペレーティングシステム２２８、送信機１０１、１３１又は１３２を起動及び停止するプログラム、あるいは他のプログラム等のアプリケーションプログラム２３０を含む。ハードディスク２２０は、ネットワーク１２０等のネットワークに対するソフトウェアインタフェース用のネットワークドライバ２３２を更に含む。ハードディスク２２０は、送信機からのデータの送出を制御するストリーミングソフトウェア２３４を更に含む。最後にハードディスク２２０は、送信機１０１と受信機１０２との間の接続の数を制御するオートチューニングソフトウェア２３６を含む。図４０に関連して、オートチューニングソフトウェア２３６を以下に更に詳細に説明する。

一実施形態の例において、ストリーミングソフトウェア２３４及びオートチューニングソフトウェア２３６は、ＣＰＵ２０２によりＲＡＭ２０８の領域にロードされる。次にＣＰＵ２０２は、ロードされたコンピュータが実行可能なステップを実行するためにＲＡＭ２０８から格納されたストリーミングソフトウェア２３４及びオートチューニングソフトウェア２３６を実行する。更にアプリケーションプログラム２３０は、ＣＰＵ２０２によりＲＡＭ２０８の領域にロードされる。次にＣＰＵ２０２は、ロードされたコンピュータが実行可能なステップを実行するために、図４０に関連して以下に詳細に説明されるような格納された処理ステップを実行する。

図３は、図１の受信機１０２の内部アーキテクチャを説明する詳細なブロック図である。図３に示されるように、受信機１０２は、コンピュータバス３００とインタフェースする中央処理装置（ＣＰＵ）３０２を備える。また、コンピュータバス３００とインタフェースするものには、ハード（又は固定）ディスク３２０、ネットワークインタフェース１１４、メインランタイム一時メモリとして使用するためのランダムアクセスメモリ（ＲＡＭ）３０８及び読み出し専用メモリ（ＲＯＭ）３１０がある。

ＲＡＭ３０８は、オペレーティングシステム、アプリケーションプログラム及びインタフェースドライバ等のソフトウェアプログラムにおける命令の実行中にＲＡＭ３０８に格納された情報をＣＰＵ３０２に提供するようにコンピュータバス３００とインタフェースする。より具体的には、最初にＣＰＵ３０２は、固定ディスク３２０からコンピュータが実行可能な処理ステップをロードするか、あるいは別の記憶装置をＲＡＭ３０８の領域にロードする。次にＣＰＵ３０２は、ロードされたコンピュータが実行可能な処理ステップを実行するためにＲＡＭ３０８から格納された処理ステップを実行してよい。また、収集されたネットワーク性能の統計又は他の情報等のデータは、コンピュータが実行可能なソフトウェアプログラムがデータにアクセスし且つ／あるいはデータを修正する必要がある程度まで、そのようなソフトウェアプログラムの実行中にＣＰＵ３０２がアクセスできるようにＲＡＭ３０８に格納されてよい。

図３に更に示されるように、ハードディスク３２０は、オペレーティングシステム３２８、受信機１０２を起動及び停止するプログラム、あるいは他のプログラム等のアプリケーションプログラム３３０を含む。ハードディスク３２０は、ネットワーク１２０等のネットワークに対するソフトウェアインタフェース用のネットワークドライバ３３２を更に含む。ハードディスク３２０は、受信機１０２によるデータの受信を制御するストリーミングソフトウェア３３４を更に含む。更にハードディスク３２０は、送信機１０１と受信機１０２との間の接続に対する種々のパラメータをスケジュールするスケジュールマネージャ３３８を含む。図４０に関連して、スケジュールマネージャ３３８を以下に更に詳細に説明する。最後にハードディスク３２０は、送信機１０１と受信機１０２との間の接続の数を制御するオートチューニングソフトウェア３３６を含む。図４０に関連して、オートチューニングソフトウェア３３６を以下に更に詳細に説明する。

スケジュールマネージャ３３８は多くの役割を担える。例えばスケジュールマネージャ３３８は、種々のデータ転送ジョブ／セッションに割り当てられた優先度を追跡する役割を担える。更にスケジュールマネージャ３３８は、データ転送セッションが開くことができる接続の数を管理する役割を担える。特にスケジュールマネージャ３３８は、所定のデータ転送に対して送信機と受信機との間の現在の接続の数を追跡するようにジョブキューを維持する。また、スケジュールマネージャ３３８は、所定の数の接続が送信機と受信機との間で開かれてよい開始時間を規定する役割を担える。最後にスケジュールマネージャ３３８は、所定の数の接続が開始され且つ開き続けられる期間又は持続期間を規定し、且つその期間が経過した後で接続を終了する役割を担える。図４０に関連して、これらの役割を以下に更に詳細に説明する。

上述の役割を担う場合、スケジュールマネージャ３３８は、各役割内である特定の判断を行うためにユーザ定義優先度及びシステムロード定義優先度等のある特定の基準を使用する。ユーザ定義優先度の一例は、支払いの少ない顧客よりも支払いの多い顧客のデータ転送に優先権を与えることである。システムロード定義優先度のいくつかの例は、データ転送、利用が不十分にならないような帯域幅及びシステムリソースの十分な利用、公平な負荷分散方式（ユーザがデータ転送のためにこの方式を使用したい場合）の全てを中断しないようにシステムを十分にロードしたままにすること、並びにそれらより長期のデータ転送を好むこと、あるいは短期のデータ転送が最初に転送を実行して長期のデータ転送が完了するのを待つことなく終了するようにより多くの接続を短期のデータ転送に与えることを含む。

スケジュールマネージャ３３８が上述の役割を担うのを容易にするために、以下の情報、すなわち所定の送信機と受信機との間の使用可能な帯域幅、所定のデータ転送ジョブに対するデータサイズ、種々の送信機に割り当てられた優先度、並びに現在のＣＰＵ負荷、現在のメモリ負荷、データの転送に対するディスク又はあらゆるディスクに関連した障害(bottleneck:ボトルネック）への現在の負荷及びデータの転送に対するネットワーク又はあらゆるネットワークに関連した障害への現在の負荷の性能に基づいて許容接続の数を考えるオートチューニングソフトウェア３３６からの推奨がスケジュールマネージャ３３８に対して使用可能になる。

一実施形態の例において、ストリーミングソフトウェア３３４、オートチューニングソフトウェア３３６及びスケジュールマネージャ３３８は、ＣＰＵ３０２によりＲＡＭ３０８の領域にロードされる。次にＣＰＵ３０２は、ロードされたコンピュータが実行可能なステップを実行するために、ＲＡＭ３０８から格納されたストリーミングソフトウェア３３４、オートチューニングソフトウェア３３６及びスケジュールマネージャ３３８の処理ステップを実行する。また、アプリケーションプログラム３３０の処理ステップは、ＣＰＵ３０２によりＲＡＭ３０８の領域にロードされる。次にＣＰＵ３０２は、ロードされたコンピュータが実行可能なステップを実行するために、図４０に関連して以下に詳細に説明するような格納された処理ステップを実行する。

図４Ａは、一実施形態の例に従って、送信機と受信機との間の一次接続の確立を説明する送信機及び受信機を示す図である。一般に、送信機１０１と受信機１０２との間でデータを送受信するために多数のソケットを介する多数の転送制御プロトコル（ＴＣＰ）接続を利用する並列データプロトコル（ＰＤＰ）が提供される。しかし、データがストレージシステムに書き込まれる前に受信機がデータをメモリバッファに収集する限り、マルチストリームデータ転送のための他の多数の接続システム（すなわち、あらゆるコネクション指向プロトコルを介したあらゆる論理接続エンドポイント）が利用されてもよい。図６に関連して、他の多数の接続システムを以下に更に詳細に説明する。図４Ａにおいて、送信機１０１のみが示されるが、他の実施形態の例において、送信機１３１及び１３２等の２つ以上の送信機が受信機１０２との接続を形成していてもよい。

図４Ａにおいて、実現されたＰＤＰの例は、多数のストリーム（例えば、ＴＣＰ接続）を介してデータを送受信できるようにする固有の軽い２値要求／応答ベースのプロトコルである。実際のデータ転送が実行可能となる前に、送信機１０１は、最初に要求メッセージを受信機１０２に送出する（４０１）。要求メッセージは、受信機１０２に登録される要求されたＵＲＩ（経路）を含む。受信機１０２は、有効な要求メッセージを受信すると、データ転送接続を開始するために送信機１０１により使用される受信機１０２により割り当てられた一意のセッションｉｄを含む応答メッセージで応答する（４０２）。上述のステップ４０１及び４０２は、受信機１０２において最初のソケットを開始し、データを転送するためのセッションを開始する。

受信機１０２により送出された応答メッセージにおいて、受信機１０２は、送信機１０１が確立されたセッションに参加することを許可される多くの接続を含む。送信機１０１が提供された数を上回る接続に参加しようとする場合、受信機１０２は更なる参加要求を拒否できる。更に応答メッセージは、確立されたセッションに対して１つの寿命を含むことができる。含まれた寿命が経過した後、送信機１０１はセッションを停止及び終了する。

受信機１０２は、使用中である場合に再度セッションを作成しようとする前に待つ期間に送信機１０１に戻る。次に送信機１０１は、受信機１０２により与えられた時間に基づいて後続のセッション作成要求を送出する。特定の期間が経過する前に送信機１０１が後続のセッション作成要求を送出する場合、受信機１０２はセッションを作成するための要求を拒否する。

セッションが作成されると、データは、送信機１０１から受信機１０２に送出されてよく（４０３）、且つ受信機１０２から送信機１０１に送出されてよい（４０４）。送信機１０１と受信機１０２との間で送出されたデータは、送出されるデータヘッダｉｄ及び多くのデータ部分を含む。

図４Ｂは、一実施形態の例に従って、送信機と受信機との間の二次接続の確立を説明する送信機及び受信機を示す図である。図４Ｂにおいて、確立された所定のセッションの間、図４Ａにおいて上述したように、送信機１０１は、受信機１０２との新しい接続を開くための参加要求を送出し、且つ有効なセッションｉｄを提供することで既存のデータ転送セッションに参加できる（４０５）。送信機１０１が有効なセッションｉｄを提供する場合、受信機１０２は、参加セッションｉｄを含む応答メッセージを返送する（４０６）。更に応答メッセージは、現在のセッションの活動中の時間及び更新された参加セッションのリストを含む状態変更を含むことができる。

参加セッションが作成されると、データは、送信機１０１から受信機１０２に送出されてよく（４０７）、且つ受信機１０２から送信機１０１に送出されてよい（４０８）。送信機１０１と受信機１０２との間で送出されたデータは、送出されるデータヘッダｉｄ及び多くのデータ部分を含む。

場合によっては、図４Ｂのステップ４０６において、受信機１０２は、送信機１０１からの参加要求を拒否する応答メッセージを送出してもよい。例えば、要求が図４Ａで受信機により提供された許可された接続の数を超えるため、受信機１０２は参加要求を拒否してもよい。これらの場合、応答メッセージは、現在のセッションに対して許可された接続の数を含む。更に応答メッセージは、送信機１０１が再度セッションに参加しようとする前に待つべき期間（例えば、数秒）を含むことができる。この点に関して、送信機１０１は、受信機１０２により提供された数秒が過ぎた後で新しい参加要求を開始してもよい。

図５は、一実施形態の例に従って、セッションにおける接続の数を増加又は減少するように送信機に通知する受信機を説明するシーケンス図である。図５において、送信機１０１は、オフセット１、長さ１のデータ部分を受信機１０２に送出する（５０１）。次に送信機１０１は、オフセット２、長さ２のデータ部分を受信機１０２に送出し（５０２）、後続のオフセット及び長さを含むデータ部分を送出し続ける（５０３）。次に受信機１０２は、送信機１０１がより多くの参加セッションを開始できるかを判定し、多くの新しい参加セッション及びセッションｉｄと共に、オフセット及び長さを含む受信したデータ部分の肯定応答を送信機１０１に送出する（５０４）。肯定応答は、新しい参加セッションを開始する前に待つ期間を更に含むことができる。その後、送信機１０１は、セッションｉｄを含む参加要求を送出し（５０５）、セッションが作成されると、新たに作成された参加セッションを介してオフセット及び長さを含む別のデータ部分を送出する（５０６）。

場合によっては、受信機１０２は、１つ以上の既存の接続を閉じることを決定してもよい。これらの場合、受信機は、受信機１０２が１つ以上の接続を閉じたという肯定応答を送出する。送信機１０１は、受信機１０２が１つ以上の接続を閉じたという肯定応答を受信すると、残りの開いている接続を介して送出されたデータを再度割り当てることでその肯定応答に反応する。

図６は、一実施形態の例に従って、送信機から受信機へのデータの送出を一般的に説明する送信機及び受信機を示す別の図である。図６において、送信機１０１は、データを格納するディスク等の記憶媒体６０１と、データバッファ６２１を含むデータバッファリーダ６０２と、データを送信するためのデータブロブシリアライザ６０３とを備える。送信機１０１は、接続６０４ａ及び６０５ａ、接続６０４ｂ及び６０５ｂ、並びに接続６０４ｃ及び６０５ｃを介して受信機１０２に接続される。受信機１０２は、ディスク等の記憶媒体６０９を含むＩ／Ｏストレージシステムと、データバッファ６２２を含むデータブロブデシリアライザ６０８と、送信されたデータを受信するためのデータブロブデシリアライザファイル６０７とを備える。

図６において、ソースデータの実際の読み出しは、送信機１０１により送信されるデータで記憶媒体６０１を満たす別個のスレッドを使用して非同期的に実行される。データは、データバッファリーダ６０２により記憶媒体６０１から読み出され、データバッファ６２１に格納される。送信機接続６０４ａ、６０４ｂ及び６０４ｃの各々は、データバッファ６２１から次に使用可能なデータチャンクをデキューする。データバッファリーダ６０２は、データバッファ６２１からデータを読み出し、データブロブシリアライザ６０３は、次に使用可能なデータチャンクをデキューした特定の接続を介して次に使用可能なデータチャンクを送信する。送信されたデータチャンクは、受信機接続６０５ａ、６０５ｂ及び６０５ｃのうちの対応する１つを介して受信される。データブロブシリアライザ６０７は、受信機接続６０５ａ、６０５ｂ及び６０５ｃから送信されたデータチャンクを受信する。データブロブデシリアライザ６０８は、データをデータバッファ６２２に格納し、データチャンクを適切な順序にすることで元のファイルを再度作成する。次にデータブロブデシリアライザ６０８は、データを記憶媒体６０９に書き込むためにバックグラウンドスレッドを使用する。

性能上の理由から、データブロブデシリアライザ６０８は、いくつかのデータをデータバッファ６２２にキャッシュし、データが元の順序にされる場合にはデータを記憶媒体６０９に書き込むことを好む。場合によっては、種々の接続を介して送出されたデータの順序がかなり狂う場合、データブロブデシリアライザ６０８は、出力ファイルにおいて異なる位置をシークしてデータを記憶媒体６０９に書き込み、キャッシュされたデータで処理メモリを消耗するのを回避する。

［大量のデータ転送−並列データプロトコル（ＭＤＴ−ＰＤＰ）］
本明細書で説明するアーキテクチャの例において、ＭＤＴ−ＰＤＰ転送コンポーネントは、アプリケーション内でＳＣＬ（Ｓｏａｐ Ｃｏｎｎｅｃｔｉｏｎ Ｌｉｂｒａｒｙ）サブシステムに対する転送ハンドラとして動作する。これは、ＳＯＡＰ要求及びＳＯＡＰ応答を転送することを含む。ＭＤＴ−ＰＤＰ転送は、ＳＣＬクライアント及びＳＣＬサービスの観点からＳＣＬのデフォルトＨＴＴＰベースの転送と機能的に等しい。しかし、本明細書において提供された開示内容は上述のアーキテクチャの例に限定されず、特許請求の範囲の特徴が実現される限り、あらゆる転送プロトコルが実現されてもよい。

ＳＯＡＰ Ｃｏｎｎｅｃｔｉｏｎ ｌｉｂｒａｒｙの目的は、ＳＯＡＰメッセージを用いたＷｅｂサービスのプロバイダ（すなわち、受信機）機能及びクライアント機能を与えることである。プロバイダ機能は、特定の処理を実行し且つアクセスするための情報を提供するようにＷｅｂサービスを提供する機能である。一方、クライアント機能はＷｅｂサービスにアクセスする機能である。ＳＯＡＰ Ｃｏｎｎｅｃｔｉｏｎ Ｌｉｂｒａｒｙを使用するＷｅｂサービスは、ＳＯＡＰ Ｃｏｎｎｅｃｔｉｏｎ Ｌｉｂｒａｒｙを使用するクライアントだけではなく、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ Ｆｒａｍｅｗｏｒｋ及び他のＷｅｂサービスフレームワークを使用するクライアントからの要求も処理できるようにする。同様に、クライアント機能は、ＳＯＡＰ Ｃｏｎｎｅｃｔｉｏｎ Ｌｉｂｒａｒｙを使用するＷｅｂサービスだけではなく、．ＮＥＴ Ｆｒａｍｅｗｏｒｋ及び他のＷｅｂサービスフレームワークを使用するＷｅｂサービスに関連した要求も実行できるようにする。

本明細書で説明するアーキテクチャの例において、ＭＤＴ−ＰＤＰは、ＳＣＬ内部で規定された転送ハンドラインタフェースを実現する。それらは、送信機及び受信機のそれぞれの側のＰｄｐ ＴｒａｎｓｐｏｒｔＲｅｃｅｉｖｅｒ及びＰｄｐ ＴｒａｎｓｐｏｒｔＳｅｎｄｅｒである。送信機側のＰｄｐ ＴｒａｎｓｐｏｒｔＳｅｎｄｅｒは、ＰＤＰ送信機とＰＤＰ受信機との間の並列接続とのＰＤＰ送信機セッションを確立することを担う。ハンドラチェーン内部のこれらのハンドラの呼び出しは、データ及びイニシエータの流れの方向に依存する。ハンドラチェーン内部のこれらのハンドラの呼び出しは、下に形成されたＰＤＰ層におけるデータ転送の開始及び終了と更にリンクされる。

図７〜図１２は、一実施形態の例のアーキテクチャを形成する主なクラスの各々を示すクラス図である。図１３〜図２０に関連して、主なクラスの各々の間の特定の関係及び対話に関して以下に詳細に説明する。

図７は、一実施形態の例に係る転送送信機を示すクラス図である。図７に示されるように、ｐｄｐ：：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクト７０３及びｐｄｐ：：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＳｅｎｄｅｒオブジェクト７０４の各々は、ｐｄｐ：：ＰｄｐＴｒａｎｓｐｏｒｔＳｅｎｄｅｒオブジェクト７０２を継承する。また、ｐｄｐ：：ＰｄｐＴｒａｎｓｐｏｒｔＳｅｎｄｅｒオブジェクト７０２は、ＳＣＬライブラリのｔｒａｎｓｐｏｒｔ：：ＴｒａｎｓｐｏｒｔＳｅｎｄｅｒオブジェクト７０１を実現する。図７のクラス図におけるｓｅｎｄ（）メソッドは、ＭｅｓｓａｇｅＣｏｎｔｅｘｔオブジェクトを含むトランスポート層を介してメッセージを送出する。このメソッドは、メッセージの送信を処理する場合に呼び出される。

図８は、一実施形態の例に係る転送受信機を示すクラス図である。図８に示されるように、ｐｄｐ：：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＲｅｃｅｉｖｅｒオブジェクト及びｐｄｐ：：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＲｅｃｅｉｖｅｒオブジェクト８０４の各々は、ｐｄｐ：：ＰｄｐＴｒａｎｓｐｏｒｔＲｅｃｅｉｖｅｒオブジェクト８０２を継承する。また、ｐｄｐ：：ＰｄｐＴｒａｎｓｐｏｒｔＲｅｃｅｉｖｅｒオブジェクト８０２は、ｔｒａｎｓｐｏｒｔ：：ＴｒａｎｓｐｏｒｔＲｅｃｅｉｖｅｒオブジェクト８０１を実現する。このｒｅｃｅｉｖｅ（）メソッドは、トランスポート層からメッセージを受信し、受信のために受信したメッセージの種々の情報をＭｅｓｓａｇｅクラスに格納するように管理を実行する。

図９は、一実施形態の例に係るサーバディスパッチャを示すクラス図である。図９に示されるように、ｐｄｐ：：ＳｏａｐＤｉｓｐａｔｃｈｅｒオブジェクト９０３は、ｓｅｒｖｅｒ：：ＤｉｓｐａｔｃｈｅｒＢａｓｅオブジェクト９０２を継承し、ｐｄｐ：：ＤａｔａＢｌｏｂＰｒｏｖｉｄｅｒＳｏａｐオブジェクト９０４及びａｐｐｌｉｃａｔｉｏｎ：：ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏオブジェクト９０５に従属する。また、ｓｅｒｖｅｒ：：ＤｉｓｐａｔｃｈｅｒＢａｓｅオブジェクト９０２は、ｓｅｒｖｅｒ：：Ｄｉｓｐａｔｃｈｅｒオブジェクト９０１に従属する。ユーザがＳｏａｐ Ｃｏｎｎｅｃｔｉｏｎ Ｌｉｂｒａｒｙを用いてサービス又はクライアントを作成する場合、ＳｏａｐＤｉｓｐａｔｃｈｅｒクラスは、動作情報及びクライアント情報等の情報を維持するＡｐｐｌｉｃａｔｉｏｎＩｎｆｏオブジェクトを含む。従って、ＳｏａｐＤｉｓｐａｔｃｈｅｒは、ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏオブジェクトを含むＳＣＬと通信でき、ＳＣＬは、ＤｉｓｐａｔｃｈＨａｎｄｌｅｒＣｈａｉｎオブジェクト（不図示）において異なる種類のディスパッチハンドラに対するＤｉｓｐａｔｃｈｅｒＨａｎｄｌｅｒ（不図示）を含む。

図１０は、一実施形態の例に係るデータソースを示すクラス図である。図１０に示されるように、ｐｄｐ：：ＭｄｔＤａｔａＳｏｕｒｃｅオブジェクト１００２は、ｄａｔａｈｏｌｄｅｒ：：ＤａｔａＳｏｕｒｃｅオブジェクト１００３を継承し、ｔｒａｎｓｐｏｒｔ：：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＦｉｌｅオブジェクト１００１と関連する。ＤａｔａＳｏｕｒｃｅオブジェクトは、データが保持されるｉｎｐｕｔＳｔｒｅａｍオブジェクトを呼び出し側が検索できるようにする機能性を含む。

図１１は、一実施形態の例に係るクライアント対話を示すクラス図である。図１１に示されるように、ｐｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＲｅｃｅｉｖｅｒオブジェクト１１０１及びＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクト１１０３の各々は、ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクト１１０２に従属する。ＤａｔａＳｏｕｒｃｅオブジェクトは、ＭＤＴクライアントに対するクライアント情報を含む。

図１２は、一実施形態の例に係るサーバ対話を示すクラス図である。図１２に示されるように、Ｐｄｐ ＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＲｅｃｅｉｖｅｒオブジェクト１２０２及びＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＳｅｎｄｅｒオブジェクト１２０３の各々は、ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクト１２０１に従属する。ＳｅｒｖｅｒＳｅｓｓｉｏｎは、ＰＤＰサーバのサーバセッションを規定する。

図１３Ａ及び図１３Ｂは、「ｐｕｔ」の例におけるクライアント側を示すシーケンス図である。図１３Ａに示されるように、１３０１において、ＳＣＬＣｌｉｅｎｔオブジェクトは、ユーザからＰＵＴ（＜ｆｉｌｅｎａｍｅ＞）を継承する。１３０２において、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトは、ＳＣＬＣｌｉｅｎｔオブジェクトからｉｎｖｏｋｅ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１３０３において、：Ｐｄｐ ＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｉｎｉｔ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１３０４及び１３０５において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトは、：ＤａｔａＢｌｏｂＰｒｏｖｉｄｅｒＳｏａｐオブジェクト及び：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトと関連する。１３０６、１３０７及び１３０８において、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｓｅｔＤａｔａＢｌｏｂＰｒｏｖｉｄｅｒ（ＤａｔａＢｌｏｂＰｒｏｖｉｄｅｒ）、ｓｅｔＬｏｃａｌＩｎｅｔＡｄｄｒｅｓｓｅｓ（ｉｎｅｔＡｄｒｅｓｓ［］）及びｓｅｔＣｏｎｎｅｃｔｉｏｎＯｐｔｉｏｎｓ（ＰｄｐＣｏｎｎｅｃｔｉｏｎＯｐｔｉｏｎｓ）を継承する。１３０９において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｓｅｎｄ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。ＳＣＬＣｌｉｅｎｔは、このカスタムトランスポートを介してＳＯＡＰメッセージを送受信するためにＭＤＴプロトコル及びＰＤＰプロトコルを利用するＳＯＡＰクライアントとして動作する。ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトは、送信機が多数の接続を介してデータを送出するためにＰＤＰプロトコルを利用できるようにする「単純な」構成要素である。また、「ＰＵＴ」動作の場合、送信機はデータを受信機（すなわち、プロバイダ）に送出する。「ＧＥＴ」動作の場合、送信機はプロバイダ（すなわち、受信機）からデータを検索する。

１３１０において、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｇｅｔＳｅｓｓｉｏｎ（）：ＣｌｉｅｎｔＳｅｓｓｉｏｎを継承する。１３１１において、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトは：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトと関連し、１３１２及び１３１３において、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅＱｕｅｕｅオブジェクト及び：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅＱｕｅｕｅオブジェクトと関連する。１３１４において、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトからｓｔａｒｔＳｅｓｓｉｏｎ（ＭｅｓｓａｇｅＲｅｑｕｅｓｔ）：ＭｅｓｓａｇｅＲｅｓｐｏｎｓｅを継承する。１３１５において、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトと関連する。１３１６及び１３１７において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｃｒｅａｔｅＳｅｓｓｉｏｎ（ＭｅｓｓａｇｅＲｅｑｕｅｓｔ）及びｄｏＲｅｑｕｅｓｔ（）を継承する。１３１８において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトと関連する。１３１９において、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトと関連する。１３２０において、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトは：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトと関連する。１３２１において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトは：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＳｏａｐオブジェクトと関連する。１３２２において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからａｄｄＤａｔａＢｌｏｂ（ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒ）を継承する。１３２３において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｄｅｓｔｒｏｙ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１３２４において、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｗａｉｔｆｏｒＲｅｑｕｅｓｔＣｏｍｐｌｅｔｉｏｎ（）を継承する。１３２５において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｔＲｅｃｅｉｖｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｒｅｃｅｉｖｅ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。尚、ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＳｏａｐクラスは、ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒ（例えば、以下に説明する図２７を参照）を拡張し、ＭｅｓｓａｇｅＣｏｎｔｅｘｔオブジェクトのメッセージを直列化するためにＳＣＬ ＭｅｓｓａｇｅＳｅｒｉａｌｉｚｅｒオブジェクトを利用する。ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒは、以下に更に詳細に説明するＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＮｏＤａｔａ及びＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＰａｒｔＳｔｒｅａｍにより更に拡張される抽象クラスとしてデータブロブシリアライザを規定する。

１３２６において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＳｏａｐオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｓｅｒｉａｌｉｚｅ（ＯｕｔｐｕｔＳｔｒｅａｍ）を継承する。１３２７において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｄｏＲｅｓｐｏｎｓｅ（）を継承する。１３２８において、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、：ＣｌｉｅｔＳｅｓｓｉｏｎオブジェクト）からｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｕｓ（ＳＥＳＳＩＯＮ＿ＲＥＳＰＯＳＥを継承する。１３３０において、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＲｅｃｅｉｖｅｒオブジェクトからｒｅａｄ（）：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒを継承する。１３２９において、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトからｗａｉｔＦｏｒＣｏｍｐｌｅｔｉｏｎ（）を継承する。１３３１において、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトからｇｅｔＩｎｃｏｍｉｎＤａｔａＢｌｏｂｓ：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅを継承する。１３３２において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクトは、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトからｇｅｔＤａｔａＢｌｏｂｓ（）：ＤａｔａＢｌｏｂＤｅｓｅｒａｌｉｚｅｒを継承する。１３３３において、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトは：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＲｅｃｅｉｖｅｒと関連する。１３３４において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＲｅｃｅｉｖｅｒは、自身からｄｅｓｅｒｉｌｉａｚｅ（ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒ［］ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。

図１４Ａ及び図１４Ｂは、「ｐｕｔ」の例におけるプロバイダ側を示すシーケンス図である。図１４Ａに示されるように、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｄｏＲｅｑｕｅｓｔを継承する。１４０２において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｇｅｔＩｎｃｏｍｉｎＤａｔａＢｌｏｂｓ（）：ＤａｔａｂｌｏｂＤｅｓｅｒｉａｌｉｚｅＱｕｅｕｅを継承する。１４０３及び１４０４において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクト及び：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｇｅｔＤａｔａＢｌｏｂ（ＭｅｓｓａｇｅｓＨｅａｄｅｒ）：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒ及びｄｅｓｅｒｉａｌｉｚｅ（ＩｎｐｕｔＳｔｒｅａｍ）を継承する。１４０５において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＳＥＳＳＩＯＮ＿ＲＥＱＵＥＳＴ）を継承する。１４０６において、：ＳｏａｐＤｉｓｐａｔｃｈｅｒオブジェクトは、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトからｄｏＷｏｒｋ（ＳｅｒｖｅｒＳｅｓｓｉｏｎ）を継承する。１４１４において、：ＨａｎｄｌｅｒＣｈａｉｎは、：ＳｏａｐＤｉｓｐａｔｃｈｅｒオブジェクトからｉｎｖｏｋｅ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１４１５において、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＲｅｃｅｉｖｅｒは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｒｅｃｅｉｖｅ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１４０７及び１４０８において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクト及び：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅは、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＲｅｃｅｉｖｅｒオブジェクトからｇｅｔＩｎｃｏｍｉｎＤａｔａＢｌｏｂｓ（）：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅ及びｇｅｔＤａｔａＢｌｏｂｓ（）：ＤｄａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒを継承する。尚、ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＦｉｌｅクラスは、ファイルベースのデータブロブデシリアライザを実現する。ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅクラスは、データブロブデシリアライザキューを実現する。ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＲＡＦクラスの実現例は、データ部分を単一のファイルに非直列化する実現例である。このＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＲＡＦの実現例は、データ部分を書き出すためにＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅ（「ＲＡＦ」）を使用する。また、ディスクへの書き込み及び入力ストリームからの読み出しは、メモリ内のデータ部分バッファ及びバックグラウンドライタスレッドを使用することで分離される。ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎクラスは、ＰＤＰサーバ及びＰＤＰサーバのセッション情報を含む。その呼び出し側は、ＰＤＰ接続を作成及び開始して、このクラスを介してメッセージを送受信できる。

１４０９において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｄｏＲｅｓｐｏｎｓｅを継承する。１４１６及び１４１７において、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＲｅｃｅｉｖｅｒは、ｄｅｓｅｒｉａｌｉｚｅＳＯＡＰ（ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｅｒＦｉｌｅ，ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）及びｄｅｓｅｒｉａｌｉｚｅＡｔｔａｃｈｍｅｎｔ（ＤａｔａＢｌｏｂＤｅｓｅｅｒｉａｌｉｚｅｒＲＡＦ，ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１４１８において、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＲｅｃｅｉｖｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｄｅｓｔｒｏｙ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１４１９及び１４２０において、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＳｅｎｄｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｉｎｉｔ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）及びｓｅｎｄ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１４２１において、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＳｅｎｄｅｒは、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＳｏａｐオブジェクトと関連する。１４１０において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅＱｕｅｕｅは、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＳｅｎｄｅｒオブジェクトからａｄｄＤａｔａＢｌｏｂ（ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒ）を継承する。１４１１において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅＱｕｅｕｅは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｇｅｔＮｅｘｔＤａｔａＢｌｏｂ（ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒ）：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒを継承する。１４１２において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＳｏａｐオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｓｅｒｉａｌｉｚｅ（ＯｕｔｐｕｔＳｔｒｅａｍ）を継承する。１４１３において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＳＥＳＳＩＯＮ＿ＤＯＮＥ）を継承する。

図１５は、「ｇｅｔ」の例におけるクライアント側を示すシーケンス図である。図１５に示されるように、１５０１において、ＳＣＬＣｌｉｅｎｔオブジェクトは、ユーザからＧＥＴ（＜ｆｉｌｅｎａｍｅ＞）を継承する。１５０２において、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトは、ＳＣＬＣｌｉｅｎｔオブジェクトからＩｎｖｏｋｅ（ｍｅｓｓａｇｅｃｏｎｔｅｘｔ）を継承する。１５０３において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｉｎｉｔ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１５０４、１５０５及び１５０６において、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｓｅｔＤａｔａＢｌｏｂＰｒｏｖｉｄｅｒ（ＤａｔａＢｌｏｂＰｒｏｖｉｅｒ）、ｓｅｔＬｏｃａｌＩｎｅｔＡｄｄｒｅｓｓ（ＩｎｅｔＡｄｄｒｅｓｓ［］）及びｓｅｔＣｏｎｎｅｃｔｉｏｎＯｐｔｉｏｎｓ（ＰｄｐＣｏｎｎｅｃｔｉｏｎＯｐｔｉｏｎｓ）を継承する。１５０７において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｓｅｎｄ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１５０８において、：ＳｉｍｐｌｅＣｌｉｅｎｔオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｇｅｔＳｅｓｓｉｏｎ（）：ＣｌｉｅｎｔＳｅｓｓｉｏｎを継承する。１５０９において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトは、自身からｓｅｎｄＳｏｐａＭｅｓｓａｇｅ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ，ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅＱｕｅｕｅ）を継承する。１５１０において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｄｅｓｔｒｏｙ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１５１１及び１５１２において、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＲｅｃｅｉｖｅｒオブジェクトは、：ＨａｎｄｅｒＣｈａｉｎオブジェクトからｒｅｃｅｉｖｅ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）及びｄｅｓｔｒｏｙ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。

図１６は、「ｇｅｔ」の例におけるプロバイダ側を示すシーケンス図である。図１６に示されるように、１６０１において、：ＳｏａｐＤｉｓｐａｔｃｈｅｒオブジェクトは、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトからｄｏＷｏｒｋ（ＳｅｒｖｅｒＳｅｓｓｉｏｎ）を継承する。１６０２において、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトは、：ＳｏａｐＤｉｓｐａｔｃｈｅｒオブジェクトからｉｎｖｏｋｅ（ｍｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１６０３及び１６０４において、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＲｅｃｅｉｖｅｒは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｒｅｃｅｉｖｅ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）及びｄｅｓｔｒｏｙ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１６０５及び１６０６において、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＳｅｎｄｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｉｎｉｔ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）及びｓｅｎｄ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。１６０７において、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＳｅｎｄｅｒは、自身からｓｅｎｄＳｏａｐＭｅｓｓａｇｅ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ，ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅＱｕｅｕｅ）を継承する。１６０８において、：ＰｄｐＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒＳｅｎｄｅｒオブジェクトは、：ＨａｎｄｌｅｒＣｈａｉｎオブジェクトからｄｅｓｔｒｏｙ（ＭｅｓｓａｇｅＣｏｎｔｅｘｔ）を継承する。

図１７は、「ｇｅｔ」動作を取り消すクライアント側を示すシーケンス図である。図１７に示されるように、１７０１において、：ＣｌｉｅｔｎＳｅｓｓｉｏｎオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｓｔａｒｔ ａ ｎｅｗ ｓｅｓｓｉｏｎ（）を継承する。１７０２において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、：ＣｌｉｅｔＳｅｓｓｉｏｎオブジェクトからｓｔａｒｔ ｔｈｅ ｃｏｎｎｅｃｔｉｏｎ （ｓｏｃｋｅｔ ｔｈｒｅａｄ）を継承する。１７０３において、：ＭｅｔｅｒＩｎｐｕｔＳｔｒｅａｍオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトから*ｒｅａｄ（ｂｙｔｅ［］，ｉｎｔ，ｉｎｔ）：ｉｎｔを継承する。１７０４において、：ＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒオブジェクトは、ＭｅｔｅｒＩｎｐｕｔＳｔｒｅａｍオブジェクトにおいて関数*ｏｎＢｙｔｅｓＲｅａｄ（ｌｏｎｇ）によりインスタンス化される。１７０５において、：ＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒオブジェクトは、ＳｅｓｓｉｏｎＥｖｅｎｔ（）を：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒと関連付ける。１７０６において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＩｎＴｒａｎｓｐｏｒｔＥｖｅｎｔＬｉｓｔｅｎｅｒオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｈａｎｄｌｅｌｎＴｒａｎｓｐｏｒｔＥｖｅｎｔ（ＩｎＴｒａｎｓｐｏｒｔＥｖｅｎｔ）を継承する。１７０７において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＩｎＴｒａｎｓｐｏｒｔＥｖｅｎｔＬｉｓｔｅｎｅｒオブジェクトは、ｔｈｒｏｗ ＩＯＥｘｃｅｐｔｉｏｎ（）を：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトと関連付ける。１７０８において、：ＣｌｉｎｅｔＳｅｓｓｉｏｎオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｔｅｒｍｉｎａｔｅ（Ｅｘｃｅｐｔｉｏｎ）を継承する。１７０９において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、：ＣｌｉｎｅｔＳｅｓｓｉｏｎオブジェクトからｃｌｏｓｅ（）を継承する。ＭｅｔｅｒｉｎｐｕｔＳｔｒｅａｍオブジェクトは、ＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒオブジェクトを利用し且つＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒオブジェクトにおいて関数ｏｎＢｙｔｅｓＲｅａｄ（ｌｏｎｇ）を呼び出すことで受信したデータバイトを更新する。

図１８は、「ｇｅｔ」動作を取り消すプロバイダ側を示すシーケンス図である。図１８に示されるように、１８０１において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトは、ＳｏａｐＤｉｓｐａｔｃｈｅｒ：ｅｖｅｎｔＰｒｏｃｅｓｓｏｒＴｈｒｅａｄからＳｔａｒｔ ａ ｎｅｗ ｓｅｒｖｅｒ ｓｅｓｓｉｏｎ（）を継承する。１８０２において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトからｓｔａｒｔ ａ ｃｏｎｎｅｃｔｉｏｎ ｓｏｃｋｅｔ（）を継承する。１８０３において、：ＭｅｔｅｒＯｕｔｐｕｔＳｔｒｅａｍは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトから*ｗｒｉｔｅ（ｂｙｔｅ［］，ｉｎｔ，ｉｎｔ）を継承する。１８０４において、：ＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒオブジェクトは、：ＭｅｔｅｒＯｕｔｐｕｔＳｔｒｅａｍオブジェクトから*ｏｎＢｙｔｅＷｒｉｔｅ（ｌｏｎｇ）を継承する。１８０５において、：ＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒは、ｗａｉｔＦｏｒＥｖｅｎｔ（）：ＳｅｓｓｉｏｎＥｖｅｎｔをＳｏａｐＤｉｓｐａｔｃｈｅｒ：ｅｖｅｎｔＰｒｏｃｅｓｓｏｒＴｈｒｅａｄオブジェクトと関連付ける。１８０６において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＯｕｔＴｒａｎｓｐｏｒｔＥｖｅｎｔＬＩｓｔｅｎｅｒオブジェクトは、ＳｏａｐＤｉｓｐａｔｃｈｅｒ：ｅｖｅｎｔＰｒｏｃｅｓｓｏｒＴｈｒｅａｄオブジェクトからｈａｎｄｌｅＯｕｔＴｒａｎｓｐｏｒｔＥｃｅｎｔ（ＯｕｔＴｒａｎｓｐｏｒｔＥｖｅｎｔ）を継承する。１８０７において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＯｕｔＴｒａｎｓｐｏｒｔＥｖｅｎｔＬｉｓｔｅｎｅｒオブジェクトは、ＳｏａｐＤｉｓｐａｔｃｈｅｒ：ｅｖｅｎｔＰｒｏｃｅｓｓｏｒＴｈｒｅａｄオブジェクトと関連する。１８０８において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトは、ＳｏａｐＤｉｓｐａｔｃｈｅｒ：ｅｖｅｎｔＰｒｏｃｅｓｓｏｒＴｈｒｅａｄからｔｅｒｍｉｎａｔｅ（Ｅｘｃｅｐｔｉｏｎ）を継承する。１８０９において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトからｃｌｏｓｅ（）を継承する。

図１９は、「ｐｕｔ」動作を取り消すクライアント側を示すシーケンス図である。図１９に示されるように、：ＭｅｔｅｒＯｕｔｐｕｔＳｔｒｅａｍオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｗｒｉｔｅ（ｂｙｔｅ［］，ｉｎｔ，ｉｎｔ）を継承する。１９０２において、：ＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒオブジェクトは、ｏｎＢｙｔｅｓＷｒｉｔｅ（ｌｏｎｇ）を継承する。１９０３において、：ＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｗａｉｔＦｏｒＥｖｅｎｔ（）：ＳｅｓｓｉｏｎＥｖｅｎｔを継承する。１９０４において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＯｕｔＴｒａｎｓｐｏｒｔＥｖｅｎｔＬｉｓｔｅｎｅｒオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｈａｎｄｌｅＯｕｔＴｒａｎｓｐｏｒｔＥｖｅｎｔ（ＯｕｔＴｒａｎｓｐｏｒｔＥｖｅｎｔ）を継承する。１９０５において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＯｕｔＴｒａｎｓｐｏｒｔＥｖｅｎｔＬｉｓｔｅｎｅｒオブジェクトは、ｔｈｒｏｗ ＩＯＥｘｃｅｐｔｉｏｎ（）を：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトと関連付ける。１９０６において、：ＣｌｉｅｔｎＳｅｓｓｉｏｎオブジェクトは、：ＰｄｐＴｒａｎｓｐｏｒｔＣｌｉｅｎｔＳｅｎｄｅｒオブジェクトからｔｅｒｍｉｎａｔｅ（Ｅｘｃｅｐｔｉｏｎ）を継承する。１９０７において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトからｃｌｏｓｅ（）を継承する。

図２０は、「ｐｕｔ」動作を取り消すプロバイダ側を示すシーケンス図である。図２０に示されるように、：ＭｅｔｅｒＩｎｐｕｔＳｔｒｅａｍオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｒｅａｄ（ｂｙｔｅ［］，ｉｎｔ，ｉｎｔ）を継承する。２００２において、：ＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒオブジェクトは、ｏｎＢｙｔｅｓＲｅａｄ（ｌｏｎｇ）を継承する。２００３において、：ＳｅｓｓｉｏｎＤａｔａＭｅｔｅｒオブジェクトは、ＳｏａｐＤｉｓｐａｔｃｈｅｒ：ｅｖｅｎｔＰｒｏｃｅｓｓｏｒＴｈｒｅａｄオブジェクトからｗａｉｔＦｏｒＥｖｅｎｔ（）：ＳｅｓｓｉｏｎＥｖｅｎｔを継承する。２００４において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＩｎＴｒａｎｓｐｏｒｔＥｖｅｎｔＬｉｓｔｅｎｅｒオブジェクトは、ＳｏａｐＤｉｓｐａｔｃｈｅｒ：ｅｖｅｎｔＰｒｏｃｅｓｓｏｒＴｈｒｅａｄオブジェクトからｈａｎｄｌｅＩｎＴｒａｎｓｐｏｒｔＥｖｅｎｔ（ＩｎＴｒａｎｓｐｏｒｔＥｖｅｎｔ）を継承する。２００５において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＩｎＴｒａｎｓｐｏｒｔＥｖｅｎｔＬｉｓｔｅｎｅｒオブジェクトは、ｔｈｒｏｗ ＩＯＥｘｃｅｐｔｉｏｎ（）をＳｏａｐＤｉｓｐａｔｃｈｅｒ：ｅｖｅｎｔＰｒｏｃｅｓｓｏｒＴｈｒｅａｄオブジェクトと関連付ける。２００６において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトは、ＳｏａｐＤｉｓｐａｔｃｈｅｒ：ｅｖｅｎｔＰｒｏｃｅｓｓｏｒＴｈｒｅａｄオブジェクトからｔｅｒｍｉｎａｔｅ（Ｅｘｃｅｐｔｉｏｎ）を継承する。２００７において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトからｃｌｏｓｅ（）を継承する。

図２１は、図１の受信機１０２のＩ／Ｏストレージシステムにおける書き込み動作を示す図である。一般に、並列接続データ転送システムにおいて、受信機のＩ／Ｏストレージシステムは、大量のデータ転送に対する障害（ボトルネック）となりうる。特に、Ｉ／Ｏストレージシステムに含まれたディスクは、大量のデータ転送に対する障害となりうる。この点に関して、ファイルが小さな部力に分解されて別個の接続を介して配信される場合、データは、特に接続の数が増加するにつれ受信機において順番に到着しないだろう。受信機が次の連続データチャンクが到着するのを待って時間切れになる場合、データをディスクに書き込む前に受信機のデータバッファは満杯になるだろう。受信機のデータバッファが満杯になると、受信機のＩ／Ｏストレージシステムは、更なるシーク動作を必要とする可能性のある故障データに対するディスク書き込みを実行することを強制されてもよい。更なるシーク動作を実行することにより、受信機のＩ／Ｏストレージシステムがデータの転送に対する障害である場合にデータを転送するのにかかる時間は更に長くなる。また、肯定応答がない（すなわち、受信機のバッファが満杯であることによるデータ消失の場合の）ことでデータの転送が更に遅延するために、更なるシーク動作を実行することにより、送信機からのデータ再送事象を更にトリガしてもよい。この例において、受信機は、新しい接続要求の受け入れを中止でき、バッファが満杯な状態を回避できるように既存の接続の数を更に減少できる。その結果、更なる高価なシーク動作が回避されるだろう。

複数の接続を介してデータを送出する場合、送信機１０１と受信機１０２との間の接続と出力ファイルとの間に多対一の関係が存在する。すなわち、多数の同時接続において転送されたデータは、単一のファイルに集約される。データを受信する受信機の各接続内において、スレッドは、単一のファイルと関連付けられたインバウンド接続から全てのデータチャンクを読み出すように開始される。同一のファイルに対してチャンクを転送する全てのＮ個の並列接続は、図６に示されたような同一のデータブロブデシリアライザファイル６０７で非直列化方法を呼び出す。データブロブデシリアライザの（図６の）タスクは、全てのＮ個の接続からのファイルと関連付けられた全てのデータチャンクを読み出すためのものであり、効率的にデータを図６の記憶媒体６０９に転送する。

図２１に示されるように、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は、楕円形で示されるＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓの形態のデータを格納する。図２１において、ライタスレッド２１０２は、ＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓをファイルに書き込む。図中符号２１０３はファイルの先頭を示す。また、ファイルに既に書き込まれたデータは、図中符号２１０５として示される。領域２１０６は、データが既に受信されているがまだファイルに書き込まれていない領域を示す。領域２１０７は、データがまだ受信されていない領域を示す。ＤａｔａＷｒｉｔｅＱｕｅｕｅは、スレッドセーフブロッキングキューの実現例である。インスタンスモニタは、ｒｅｍｏｖｅ（）メソッド及びｉｎｓｅｒｔ（）メソッドに対する同期ロックとして使用される。ｒｅｍｏｖｅ（）メソッド及びｉｎｓｅｒｔ（）メソッドは、キューから項目を除去する。ｒｅｍｏｖｅＤａｔａＷｒｉｔｅＯｂｊｅｃｔＷｉｔｈＯｆｆｓｅｔ（）メソッドは、特定のオフセットにおける変更開始を除去するために使用可能である。このメソッドは、必要なデータブロックが使用可能になるまでブロックする。ＤａｔａＷｒｉｔｅＯｂｊｅｃｔオブジェクトは、ＬｉｎｋＬｉｓｔオブジェクトのメモリバッファにデータを格納してデータを連結し、データのオフセット及び長さの情報を更に記録する。

図２１において、現在のファイル位置は、ライタスレッド２１０２がデータをファイルに書き込むのに使用可能である。しかし、現在のファイル位置２１０５に対してそのようなＤａｔａＷｒｉｔｅＯｂｊｅｃｔがＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１に存在しないことがありうる。ファイルの種々の領域からデータを転送するために種々の接続が使用されるため、ライタスレッド２１０２がファイルの特定の領域をディスクに書き込む準備ができるまでにファイルのその特定の領域がまだ受信されていないことがありうる。これは、メモリバッファが記憶装置に書き込む前に一時的なチャンクデータを収容するのに十分なほど大きくないことを示すだろう。その結果、シーク動作が実行されてもよいことを意味する。通常、これは、送信機１０１から受信機１０２へのデータ転送速度がＩ／Ｏストレージシステムを処理するよりも高速であることを意味する。従って、参加接続の数は、ファイルシーク動作を回避するように減少されてもよい。図４０に関連して、これを以下に更に詳細に説明する。

より具体的には、ライタスレッド２１０２は、この例においてファイルの異なる領域をディスクに書き込むことが許可される場合、回避されるべきシーク動作を実行する。一方、ライタスレッド２１０２が接続のうちの１つによりＤａｔａＷｒｉｔｅＯｂｊｅｃｔがキューに提示される無限の時間の長さを待ちながら無制限にブロックする場合、非効率的になる可能性もある。これは、より高速なネットワークが採用され且つＩ／Ｏストレージシステムのディスクがデータの転送において障害である場合に特に当てはまる。この場合、ライタスレッド２１０２が待たされるほど、転送はより非効率的になる。

データの効率的なＰＤＰ転送を提供するために、以下の２つのことを平衡させる。すなわち、（１）データをディスクに頻繁に書き込むことであり、ライタスレッド２１０２が頻繁に非ブロック化されたままであるのを許可することを意味する。（２）ファイルシーク動作を回避することであり、現在のファイル位置に対するデータが接続のうちの１つから読み出されるまで待つようにライタスレッド２１０２をブロックする場合もあることを意味する。

上述の平衡は、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１において実行される。現在のファイル位置２１０４に対するＤａｔａＷｒｉｔｅＯｂｊｅｃｔが使用不可である場合、例えばＤａｔａＷｒｉｔｅＱｕｅｕｅは、不要なシーク動作及びライタスレッド２１０２の不要なブロックを実質的に回避する傾向がある以下のヒューリスティックを採用する。すなわち、ＤａｔａＷｒｉｔｅＯｂｊｅｃｔが現在のファイル位置に対して使用不可である場合、（１）要求されたＤａｔａＷｒｉｔｅＯｂｊｅｃｔがリーダスレッドによりＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１に追加される間最大２秒待ち、（２）要求されたＤａｔａＷｒｉｔｅＯｂｊｅｃｔが２秒のタイムアウト期間内に使用可能になる場合にそれを返送し、（３）要求されたＤａｔａＷｒｉｔｅＯｂｊｅｃｔが２秒のタイムアウト期間内に使用可能にならない場合に使用可能である最も低い絶対オフセットを含むＤａｔａＷｒｉｔｅＯｂｊｅｃｔをライタスレッド２１０２に返送する。このヒューリスティックは、ライタスレッドがディスクへの書き込みを継続することとファイルシーク動作を回避することとを平衡しようとする。しかし、シーク動作は全て回避されなくてもよく、データ転送をより適切に実行するために、受信機１０２は、送信機１０１からの参加要求をブロックし、且つ送信機１０１が１つ以上の二次接続を閉じることを要求してもよい。図４０に関連して、これを以下に更に詳細に説明する。

メモリにより少ないＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓがある（すなわち、データがライタスレッド２１０２によりまだファイルに書き込まれていないことを示す）場合、現在のファイル位置２１０４を示すＤａｔａＷｒｉｔｅＯｂｊｅｃｔが使用可能である可能性はあまり高くない。この例においてライタスレッド２１０２が使用可能なＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓのうちの１つをファイルに書き込むことが許可される場合、ファイルに対するシーク動作が必要である可能性はより高い。従って、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１がほぼ空になると、接続リーダスレッドによりＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１を最小レベルまで満たせるように、ライタスレッド２１０２は、ＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓを除去しようとする場合にブロックされる。

異なる例において、リーダスレッドは、ＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓをＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１に追加しようとする場合にブロックされてもよい。この例において、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１が非常に多数のＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓで満たされる場合、別のＤａｔａＷｒｉｔｅＯｂｊｅｃｔをＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１に追加しようとする接続リーダスレッド（不図示）はブロックされる。これにより、ライタスレッド２１０２はＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓのうちのいくつかをディスクに書き込める。

内部的に、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は、上述のブロックの例が発生した時を判断するためにＣｏｎｓｕｍｅｒＰｒｏｄｕｃｅｒＴｈｒｏｔｔｌｅオブジェクト（不図示）を利用する。ＣｏｎｓｕｍｅｒＰｒｏｄｕｃｅｒＴｈｒｏｕｔｔｌｅオブジェクトは、ＤａｔａＷｒｉｔｅＯｂｊｅｃｔＴｈｒｏｔｔｌｅ（不図示）が実現するための契約を規定するインタフェースオブジェクトである。ＤａｔａＷｒｉｔｅＯｂｊｅｃｔＴｈｒｏｔｔｌｅは、アプリケーションがディスク記憶装置に書き込む前に未実現データをメモリにキャッシュするようにメモリバッファのサイズを構成できるようにし、現在の消費されたリカバリバッファ情報を更に含む。

ライタスレッド２１０２がＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１からＤａｔａＷｒｉｔｅＯｂｊｅｃｔを除去するように要求する場合、ＤａｔａＷｒｉｔｅＱｕｅｕｅは、その要求をＣｏｎｓｕｍｅｒＰｒｏｄｕｃｅｒＴｈｒｏｔｔｌｅオブジェクトに通知する。ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１が最小数のＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓを有さない場合、ＣｏｎｓｕｍｅｒＰｒｏｄｕｃｅｒＴｈｒｏｔｔｌｅオブジェクトはライタスレッド２１０２をブロックする。ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１が十分なＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓで満たされると、ＣｏｎｓｕｍｅｒＰｒｏｄｕｃｅｒＴｈｒｏｔｔｌｅはライタスレッド２１０２をリリースする。

あるいは、リーダスレッドが新しいＤａｔａＷｒｉｔｅＯｂｊｅｃｔをＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１に追加するように要求する場合、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は最大数のＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓに到達したかもしれない。この例において、ライタスレッド２１０２がＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１からＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓを除去する機会を有するまで、リーダスレッドはブロックされる。ここでも、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は、上述の例が発生した時を判断するためにそのＣｏｎｓｕｍｅｒＰｒｏｄｕｃｅｒＴｈｒｏｔｔｌｅオブジェクトを利用する。リーダスレッドがＤａｔａＷｒｉｔｅＯｂｊｅｃｔをＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１に追加する場合、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は、ＤａｔａＷｒｉｔｅＯｂｊｅｃｔが追加されていることをＣｏｎｓｕｍｅｒＰｒｏｄｕｃｅｒＴｈｒｏｔｔｌｅに通知する。ＣｏｎｓｕｍｅｒＰｒｏｄｕｃｔＴｈｒｏｔｔｌｅは、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１がその最大数のＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓに到達したと判断する場合、リーダスレッドをブロックする。キューにおけるＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓの数が減少するまで、リーダスレッドはブロックされたままである。

図２２は、図２１に示されたようなＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１を示す図である。図２２において、ＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓ２２０１ａ〜２２０１ｄ等のいくつかのＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓを受信した後のＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１が示される。この例において、ＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓは、ファイルの５つの隣接領域を示す５つのチェーンに編成される。ＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓ２２０１ａ〜２２０１ｄは、５つのチェーンのうちの１つを示す。一般にＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は、Ｎ個のリーダスレッドに対する同期及び編成の点として動作する。シーク動作を回避するために、ＤａｔａＷｒｉｔｅＱｕｅｕｅは、自動的にファイルの隣接領域を示すＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓの集合を検出する。ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は、ファイルの隣接領域を示す多数のＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓを受信する場合、各ＤａｔａＷｒｉｔｅＯｂｊｅｃｔがどの接続からのものかに関係なく、ＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓを単一のチェーンの内部に集める。従って、ＤａｔａＷｒｉｔｅＱｕｅｕｅは、順序付けされていないＤａｔａＷｒｉｔｅＯｂｊｅｃｔチェーンの集合としてＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓを格納する。

図２１のライタスレッド２１０２は、ＤａｔａＷｒｉｔｅＱｕｅｕｅからＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓを除去する場合、現在のファイル位置を示す。ファイルシーク動作を回避できるようにするために、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は、そのオフセットが現在のファイル位置２１０４であるＤａｔａＷｒｉｔｅＯｂｊｅｃｔを提供する。次にライタスレッド２１０２は、シーク動作を実行せずに現在のファイル位置２１０４に書き込んでもよい。内部的に、ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は、ファイルの隣接領域を示すＭ個のＤａｔａＷｒｉｔｅＯｂｊｅｃｔチェーンの集合を維持する。ＤａｔａＷｒｉｔｅＱｕｅｕｅ２１０１は、Ｍ個のＤａｔａＷｒｉｔｅＯｂｊｅｃｔチェーンのオフセットの開始を確認し、最初のオフセットが現在のファイル位置に一致するチェーンがある場合、チェーン全体が返送される。

図２３は、図１の受信機１０２のＩ／Ｏストレージシステムにおける書き込み動作を示す別の図である。一般に、データが順番に来なくてもよいため、多数の接続は、データを再度集めるようにデータをメモリ内のバッファに書き込んでもよい。データをディスクに書き込む間のＩ／Ｏストレージシステム書き込み速度を測定することにより、ディスクが他のアプリケーション及びタスクからの要求を処理するのに使用中であるかを判断できる。それに応じて、接続の数を適切に減少又は増加できる。図４０に関連して、これを更に詳細に説明する。

図２３に示されるように、ライタスレッド２１０２は、記憶媒体６０９（図６に示されたような）のファイルにデータを書き込む。ライタスレッド２１０２を使用することにより、Ｎ個のリーダスレッドをファイル書き込み動作から分離する。ＤａｔａＷｒｉｔｅＯｂｊｅｃｔｓは、接続６０５ａ〜６０５ｃにより追加され、ライタスレッド２１０２により除去される。ライタスレッド２１０２がデータを記憶媒体６０９に書き込む速度は、Ｉ／Ｏストレージシステムに対して測定された書き込み速度である。

図２４Ａは、図１の送信機１０１のＩ／Ｏストレージシステムにおけるデータ転送の障害（ボトルネック）を検出するシーケンス図である。一般に送信機１０１は、ネットワーク性能を見つけるためにラウンドトリップ時間（ＲＴＴ）を利用してもよい。利用されたＲＴＴは、ＴＣＰのＲＴＴ又はＲＴＴを算出するための他のあらゆる固有の手法であってもよい。近年のＴＣＰの実現例は、一般的なデータパケットの交換を監視し且つどれくらいの長さが「長すぎる」かの推定を発展させることでネットワーク性能の問題に対応しようとする。この処理をラウンドトリップ時間（ＲＴＴ）推定と呼ぶ。ＲＴＴ推定は、ＴＣＰ交換、特に殆どのＴＣＰの実現例が良質なリンクかどうかに関係なく最終的にパケットをドロップしてそれらを再送信する無限に大きな転送において重要な性能パラメータである。ＲＴＴ推定が低すぎる場合、パケットは不必要に再送信されず、ＲＴＴ推定が高すぎる場合、接続は、ホストが時間切れを待つ間アイドル状態であってもよい。受信機１０２に送出されたメッセージパケットのＲＴＴ時間が前のメッセージパケットより長くかかっていることに送信機１０１が気付く場合、それは、ネットワークが使用中であり且つより多くのトラフィックを有することを示すだろう。この場合、送信機１０１は、接続の数を減少して受信機１０２に報知できる。あるいは、ＲＴＴがより短い期間かかっている場合、送信機は、接続の数を増加するように要求してもよい。図４０に関連して、上述の接続の数の増減を更に詳細に説明する。

図２４Ａにおいて、送信機１０１は、肯定応答を送信機１０１に送出するように受信機１０２に要求できる。送信機１０１は、キャッシュされた情報をこれ以上保持しない状況を検出する場合、受信機１０２にそれを通知し、両者がキャッシュされた情報を適切に除去して新しいデータ部分に進めるように肯定応答（ＡＣＫ）を送出することを受信機に強制する。このような状況において、受信機は、送信機１０１がより多くの帯域幅を利用するために接続の数を増加できるかを判断できる。肯定応答（ＡＣＫ）は、トランスポート層のＡＣＫ信号（例えば、ＴＣＰプロトコル）ではなく、アプリケーション層に対する肯定応答を参照している。このため、ＭＤＴは、データが肯定応答（すなわち、ここではＡＣＫ）として到着したことを受信機がクライアントに報知するために通信チャネルを実現する。あるいは、受信機否定応答（ＲＮＡ）は、上述のキャッシュの除去を実現するために利用可能である。

特に、図２４Ａにおいて、送信機１０１は、メッセージを送出する（ステップ２４０１）前にデータをメモリバッファに読み込む。ステップ２４０２〜２４０６において、送信機１０１は、オフセットａ１、長さｂ１を含むデータ部分、オフセットａ２、長さｂ２を含むデータ部分、オフセットａ３、長さｂ３を含むデータ部分を送出し、データ部分がａ（ｎ−１）のオフセット、長さｂ（ｎ−１）及び最終的にａｎのオフセット、長さｂｎに到達するまでデータ部分を送出し続ける。ここで、「ｎ」は、一連のデータ部分の数を示す。ステップ２４０７において、送信機１０１は、受信機が認識されたデータ部分のリストを含むＡＣＫを送出することを要求する。受信機１０２は、追跡してきたデータパケットの値のオフセット及び長さを進め、データパッケージを記憶装置に書き込む。ステップ２４０８において、受信機１０２は要求されたＡＣＫを送出し、送信機１０１はメモリバッファにキャッシュされたデータを除去する。

図２４Ｂは、図１の送信機１０１のＩ／Ｏストレージシステムにおける読み出し動作を示す図である。図２４Ｂにおいて、データバッファリーダ２４１１は、別個のスレッドに記憶媒体（すなわち、ディスク）６０１からデータブロックを読み出す。データバッファリーダ２４１１は、「空き」セクション及び「満杯」セクションを含むダブルキュー機構を使用する。データバッファリーダ２４１１は、データバッファ部分をメモリバッファ２４１２の「満杯」側にロードする。データバッファリーダ２４１１は、ロードされ且つ再利用されたデータバッファ部分を管理し、同期的にロードされたデータバッファ部分へのアクセスを一覧表示し且つ提供する。更にデータバッファ部分は、ネットワークに対してそれらのコンテンツを読み書きする機能を提供する。

ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＰａｒｔＳｔｒｅａｍ２４２１ａ、２４２１ｂ及び２４２１ｃは、データバッファリーダ２４１１からロードされたデータ部分を検索し、ネットワークを介して連続的にデータ部分を送出する。ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＰａｒｔＳｔｒｅａｍは、ＰＤＰプロトコル接続に基づくデータを用いてデータを直列化するように、所定の入力ストリーム又はデータバッファリーダに対してＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒを拡張する。 ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＰａｒｔＳｔｒｅａｍ２４２１ａ、２４２１ｂ及び２４２１ｃは、利用されたデータ部分を更に再利用する。接続６０４ａ、６０４ｂ及び６０４ｃは、リモートホストとのエンドツーエンド接続ソケットを提供し、データをリモートホストに送出するためにＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＰａｒｔＳｔｒｅａｍオブジェクト２４２１ａ、２４２１ｂ及び２４２１ｃを使用する。接続６０４ａ、６０４ｂ及び６０４ｃは、ローカルホスト上で他の接続インスタンスと同時に動作する。

図２４Ｂに示された高度なダブルキュー機構は、以下の効率的な概念、すなわち（１）ディスクからデータを非同期に読み出すことでデータの読み出し及び送出におけるタイミングの重複を実現すること、（２）同期アクセスをロードされたデータバッファ部分のリストに提供する機能により、同時に実行している接続スレッドが多数のソケットを介してデータを同時に送出できること、並びに（３）データバッファ部分を再利用する機能により、実質的に不要なヒープメモリの割り当て及びガーベッジコレクションを回避することを提供する。

ネットワークがデータを送出できるよりも速くデータバッファリーダ２４１１が記憶媒体（すなわち、ディスク）６０１からデータを読み出し、且つメモリバッファがその限界（多くのクライアント／サーバアプリケーションシステムに適用する）に到達する場合、クライアントは、メモリが使用可能になるまでデータをメモリバッファに読み込むのを中止する。この結果、ネットワーク上でのディスクからのデータの読み出し及びデータの送出が重複しない時間帯が得られる。それにより、システムにわたり非正規化されたデータの流れができる。これにより、少なくともより大きなデータセットに対するデータのネットスループットが減少する。しかし、ネットワークがデータの転送に対する障害であると識別することである送信機のメモリバッファが頻繁に満杯になっているのが検出されると、帯域幅が低い場合にネットワークがデータで詰まるのを軽減するように接続の数を減少することで補修動作を実行できる。ほぼ同時に、遅延の発生は、公平に正規化されたデータ送出の流れを実現するように、接続の数が減少するのとほぼ同時に記憶媒体（すなわち、ディスク）からデータを読み出す際に更に発生される。図４０に関連して、上述の検出及び補修動作を以下に更に詳細に説明する。

図２５〜図２８は、一実施形態の例のアーキテクチャの中核を形成する主なクラスの各々を示すクラス図である。図２９〜図３９を参照して、主なクラスの各々の間の特定の関係及び対話に関して以下に詳細に説明する。

図２５は、一実施形態の例に係るサーバを示すクラス図である。図２５に示されるように、ｓｅｒｖｅｒ：：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクト２５０１は、ｓｅｒｖｅｒ：：Ｄｉｓｐａｔｃｈｅｒオブジェクト２５０２、ｓｅｒｖｅｒ：：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクト２５０３及びｓｅｒｖｅｒ：：Ｓｅｒｖｅｒオブジェクト２５０４と関連する。また、ｓｅｒｖｅｒ：：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクト２５０３は、ｓｅｒｖｅｒ：：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクト２５０１及びｓｅｒｖｅｒ：：Ｓｅｒｖｅｒオブジェクト２５０４と関連する。更にｓｅｒｖｅｒ：：Ｓｅｒｖｅｒオブジェクト２５０４は、ｓｅｒｖｅｒ：：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクト２５０１及びｓｅｒｖｅｒ：：Ｄｉｓｐａｔｃｈｅｒオブジェクト２０５２と関連する。尚、この図において規定されたクラスは、ＰＤＰプロトコルクライアント接続要求を受け入れ且つＳＯＡＰ Ｃｏｎｎｅｃｔｉｏｎ Ｌｉｂｒａｒｙ（すなわち、ＳＣＬ）を介してサーバセッションを維持するＰＤＰプロトコルサーバを作成するためにＭＤＴアプリケーションにより使用される。Ｓｅｒｖｅｒオブジェクトは、ＰＤＰサーバを実現し、特定のアドレス及びポートをリスンするＰＤＰサーバの例を作成且つ開始し、サーバ接続セクション及び参加セッションを樹立且つ維持する。呼び出し側は、このクラスからもセッションｉｄを検索できる。

図２６は、一実施形態の例に係るクライアントを示すクラス図である。図２６に示されるように、ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクト２６０３及びＳｉｍｐｌｅＣｌｉｅｎｔオブジェクト２６０２の各々は、ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクト２６０１と関連する。これらのクラスは、ＰＤＰプロトコルサーバ接続に接続し且つＳｏａｐ Ｃｏｎｎｅｃｔｉｏｎ ｌｉｂｒａｒｙを介してクライアントセッションを維持するＰＤＰプロトコルを作成するためにＭＤＴアプリケーションにより使用される。

図２７は、一実施形態の例に係るデータシリアライザを示すクラス図である。図２７に示されるように、ＤａｔａＢｌｏｂＩｔｅｍオブジェクト２７０３は、ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒオブジェクト２７０１と関連する。また、ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＰａｒｔＳｔｒｅａｍオブジェクト２７０２及びＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＮｏＤａｔａオブジェクト２７０４の各々は、ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒオブジェクト２７０１と関連する。ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＮｏＤａｔａ及びＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＰａｒｔＳｔｒｅａｍの双方は、ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒオブジェクトを拡張する。また、ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＮｏＤａｔａは、データを全く含まない直列化されたデータブロブを提供する。

図２８は、一実施形態の例に係るデータデシリアライザを示すクラス図である。図２８に示されるように、ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＦｉｌｅオブジェクト２８０３及びＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＲＡＦオブジェクト２８０２の各々は、ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒオブジェクト２８０１を継承する。また、ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＲＡＦオブジェクト２８０２は、ＤａｔａＷｒｉｔｅＱｕｅｕｅオブジェクト２８０４と関連する。ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒは、データブロブデシリアライザを規定し、ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＦｉｌｅ、ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＲＡＦ、ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＱｕｅｕｅは、このオブジェクトを拡張し、ＭｅｓｓａｇｅＣｏｎｔｅｘｔオブジェクトのメッセージを非直列化するためにＳＣＬ ＭｅｓｓａｇｅＳｅｒｉａｌｉｚｅｒオブジェクトを利用する。

図２９は、クライアントにおいてセッションを確立するシーケンス図である。図２９に示されるように、２９０１において、ｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、開発者からｓｔａｒｔＳｅｓｓｉｏｎ（）を継承する。２９０２において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＰｄｐＣｌｉｅｎｔＳｏｃｋｅｔＦａｃｔｏｒｙオブジェクトは、ｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトからｃｒｅａｔｅ（ＵｒｌＥｘ）：Ｓｏｃｋｅｔを継承する。２９０３において、＜＜ｓｔａｔｉｃ＞＞：Ｒｅｑｕｅｓｔオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｗｒｉｔｅ（ＯｕｔｐｕｔＳｔｒｅａｍ）を継承する。２９０４において、＜＜ｓｔａｔｉｃ＞＞：Ｒｅｓｐｏｎｓｅオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｒｅａｄ（ＩｎｐｕｔＳｔｒｅａｍ）を継承する。２９０５において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトからｇｅｔＲｅｓｐｏｎｓｅ（）：Ｍｅｓｓａｇｅ．Ｒｅｓｐｏｎｓｅを継承する。Ｍｅｓｓａｇｅ．Ｒｅｓｐｏｎｓｅは、Ｍｅｓｓａｇｅクラス（不図示）の内部クラスであり、ＰＤＰ応答メッセージを規定する。Ｍｅｓｓａｇｅクラスは、ＰＤＰ通信に対して使用された全ての転送メッセージを含む。このクラスにより、呼び出し側は、入力ストリームから次のＰＤＰメッセージを取得でき、ベースＰＤＰメッセージを規定する。

２９０６において、ｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、開発者からｊｏｉｎＳｅｓｓｉｏｎ（）を継承する。２９０７において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＰｄｐＣｌｉｅｎｔＳｏｃｋｅｔＦａｃｔｏｒｙオブジェクトは、ｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトからｃｒｅａｔｅ（ＵｒｌＥｘ）：Ｓｏｃｋｅｔを継承する。２９０８において、＜＜ｓｔａｔｉｃ＞＞：Ｊｏｉｎオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｗｒｉｔｅ（ＯｕｔｐｕｔＳｔｒｅａｍ）を受信する。２９０９において、＜＜ｓｔａｔｉｃ＞＞：Ｒｅｓｐｏｎｓｅオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｒｅａｄ（ＩｎｐｕｔＳｔｒｅａｍ）を継承する。２９１０において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトからｇｅｔＲｅｓｐｏｎｓｅ（）：Ｍｅｓｓａｇｅ．Ｒｅｓｐｏｎｓｅを継承する。２９１１において、ｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、開発者からｗａｉｔＦｏｒＣｏｍｐｌｅｔｉｏｎ（）を継承する。２９１２において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎは、自身からｄｏＲｅｑｕｅｓｔ（）を継承する。２９１３において、：ＣｌｉｎｅｔＣｏｎｎｅｃｔｉｏｎは、ｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＱＵＥＳＴ）をｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎと関連付ける。

２９１４において、：ＣｌｉｅｎｔＣｏｎｎｅｔｉｏｎオブジェクトは、自身からｄｏＲｅｑｕｅｓｔを継承する。２９１５において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎは、ｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＱＵＥＳＴ）をｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎと関連付ける。２９１６において、：ＣｌｉｅｎｔＣｏｎｎｅｔｉｏｎは、自身からｄｏＲｅｓｐｏｎｓｅ（）を継承する。２９１７において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＳＰＯＮＳＥ）をｃｌｉｅｎｔ：：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトと関連付ける。２９１８において、：ＣｌｉｅｎｔＣｏｎｎｅｔｉｏｎオブジェクトは、自身からｄｏＲｅｓｐｏｎｓｅを継承する。２９１９において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＳＰＯＮＳＥ）を関連付ける。２９２０において、：ＣｌｉｅｎｔＣｏｎｎｅｔｉｏｎオブジェクトは、自身からｃｌｏｓｅ（）を継承する。２９２１において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｃｌｏｓｅ（）を継承する。

図３０は、一実施形態の例に従って、図１の送信機１０１等の送信機における開始セッションの確立を説明するフローチャートである。ステップ３００１において、開始セッションの確立を開始する。ステップ３００２において、ソケットは、開始セッションを確立する送信機において作成される。ステップ３００３において、要求メッセージは、開始セッションを確立するために、送信機により図１の受信機１０２等の受信機に送出される。次に送信機は、受信機から送信機に送出された応答メッセージを読み出す（ステップ３００４）。ステップ３００５において、開始セッションを確立するために送出された応答メッセージが成功したことを応答メッセージが示すかを判定する。要求が成功しなかった場合、ステップ３００２で作成されたソケットは閉じられる（ステップ３００６）。要求が成功した場合、セッションが作成され（ステップ３００７）、更なる要求が実行される（ステップ３００８）。

図３１は、一実施形態の例に従って、図１の送信機１０１等の送信機における参加セッションの確立を説明するフローチャートである。ステップ３１０１において、参加セッションの確立を開始する。ステップ３１０２において、ソケットは、参加セッションを確立する送信機において作成される。ステップ３１０３において、参加メッセージは、参加セッションを確立するために、送信機により図１の受信機１０２等の受信機に送出される。次に送信機は、受信機から送信機に送出された応答メッセージを読み出す（ステップ３１０４）。ステップ３１０５において、参加セッションを確立するために送出された参加メッセージが成功したことを応答メッセージが示すかを判定する。参加メッセージが成功しなかった場合、ステップ３１０２で作成されたソケットは閉じられる。参加メッセージが成功した場合、参加セッションが作成される（ステップ３００７）。ステップ３１０８において、セッション状態を確認する。セッションが実行される場合、ソケットは閉じられる（ステップ３１１１）。更なる要求が認可される場合、ステップ３１０９に進む。図３５に関連して、これを詳細に説明する。更なる応答が認可される場合、ステップ３１１０に進む。図３６に関連して、これを詳細に説明する。

図３２は、サーバにおいてセッションを確立するシーケンス図である。図３２に示されるように、３２０１において、：Ｓｅｒｖｅｒオブジェクトは、開発者からａｄｄＤｉｓｐａｔｃｈｅｒ（Ｓｔｒｉｎｇ，Ｄｉｓｐａｔｃｈｅｒ）を継承する。３２０２において、：Ｓｅｒｖｅｒオブジェクトは、開発者からｓｔａｒｔ（）を継承する。３２０３において、＜＜ｓｔａｔｉｃ＞＞：Ｒｅｑｕｅｓｔオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｒｅａｄ（ＩｎｐｕｔＳｔｒｅａｍ）を継承する。３２０４において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｃｒｅａｔｅＳｅｓｓｉｏｎ（Ｍｅｓｓａｇｅｓ．Ｒｅｑｕｅｓｔ）：ＳｅｒｖｅｒＳｅｓｓｉｏｎを：Ｓｅｒｖｅｒオブジェクトと関連付ける。尚、ここでパラメータとして渡されたＭｅｓｓａｇｅ．Ｒｅｑｕｅｓｔは、Ｍｅｓｓａｇｅｓクラス（不図示）の内部クラスであり、ＰＤＰ要求メッセージを規定する。

３２０５において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：Ｄｉｓｐａｔｃｈｅｒは、：ＳｅｒｖｅｒオブジェクトからｏｎＳｅｓｓｉｏｎＣｒｅａｔｅ（ＳｅｒｖｅｒＳｅｓｓｉｏｎ）を継承する。３２０６において、＜＜ｓｔａｔｉｃ＞＞：Ｒｅｓｐｏｎｓｅは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｗｒｉｔｅ（ＯｕｔｐｕｔＳｔｒｅａｍ）を継承する。３２０７において、＜＜ｓｔａｔｉｃ＞＞：Ｊｏｉｎオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｒｅａｄ（ＩｎｐｕｔＳｔｒｅａｍ）を継承する。３２０８において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｊｏｉｎＳｅｓｓｉｏｎ（Ｍｅｓｓａｆｅｅｓ．Ｊｏｉｎ）：ＳｅｒｖｅｒＳｅｓｓｉｏｎを：Ｓｅｒｖｅｒオブジェクトと関連付ける。３２０９において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：Ｄｉｓｐａｔｃｈｅｒオブジェクトは、：ＳｅｒｖｅｒオブジェクトからｏｎＳｅｓｓｉｏｎＪｏｉｎ（ＳｅｒｖｅｒＳｅｓｓｉｏｎ）を継承する。３２１０において、＜＜ｓｔａｔｉｃ＞＞：Ｒｅｓｐｏｎｓｅオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｗｒｉｔｅ（ＯｕｔｐｕｔＳｔｒｅａｍ）を継承する。

３２１１において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｄｏＲｅｑｕｅｓｔ（）を継承する。３２１２において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎは、ｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＱＵＥＳＴ）を：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトと関連付ける。３２１３において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎは、自身からｄｏＲｅｑｕｅｓｔ（）を継承する。３２１４において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＱＵＥＳＴ）を：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトと関連付ける。３２１５において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：Ｄｉｓｐａｔｃｈｅｒオブジェクトは、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトからｄｏＷｏｒｋ（ＳｅｒｖｅｒＳｅｓｓｉｏｎ）を継承する。３２１６において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｄｏＲｅｓｐｏｎｓｅ（）を継承する。３２１７において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｄｏＲｅｓｐｏｎｓｅ（）を継承する。３２１８において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＳＰＯＮＳＥ）を継承する。３２１９において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＳＰＯＮＳＥ）を継承する。３２２０において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：Ｄｉｓｐａｔｃｈｅｒオブジェクトは、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトからｏｎＳｅｓｓｉｏｎＥｎｄ（ＳｅｒｖｅｒＳｅｓｓｉｏｎ）を継承する。３２２１において、：Ｓｅｒｖｅｒオブジェクトは、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトからｒｅｍｏｖｅＳｅｓｓｉｏｎ（ＳｅｒｖｅｒＳｅｓｓｉｏｎ）を除去する。３２２２及び３２２３において、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｃｌｏｓｅ（）を継承する。

図３３は、一実施形態の例に従って、受信機におけるセッションの確立を説明するフローチャートである。図３３のステップ３３０１において、接続の受け入れを開始する。ステップ３３０２において、受信機は、送信機により送出されたメッセージを受信し、そのメッセージを読み出す。ステップ３３０３において、メッセージのＩＤを取得する。メッセージが要求メッセージ又は参加メッセージ以外であることをメッセージのＩＤが示す場合、受信機は、エラーメッセージと共に応答を送信機に送出し（ステップ３３１６）、利用されたソケットを閉じる（ステップ３３１７）。メッセージが要求メッセージである場合、要求された接続経路が登録されるかを判定する（３３０７）。経路が登録されない場合、受信機は、エラーメッセージと共に応答を送信機に送出し（ステップ３３１８）、利用されたソケットを閉じる（ステップ３３１９）。経路が登録される場合、セッションが作成され（ステップ３３０８）、応答は、セッションＩＤメッセージと共に受信機から送信機に送出される（ステップ３３０９）。

３３０３において、メッセージが参加メッセージである場合、受信機は、要求された参加セッションが使用可能であるかを判定する（ステップ３３０４）。セッションが使用不可である場合、受信機は、エラーメッセージと共に応答を送信機に送出し（ステップ３３０５）、利用されたソケットを閉じる（ステップ３３０６）。セッションが使用可能である場合、セッションに参加し（ステップ３３１０）、応答は、セッション状態メッセージと共に受信機から送信機に送出される（ステップ３３１１）。ステップ３３１２において、セッション状態を確認する。セッションが実行される場合、ソケットは閉じられる（ステップ３３１５）。更なる要求が認可される場合、ステップ３３１３に進む。図３８に関連して、これを詳細に説明する。更なる応答が認可される場合、ステップ３３１４に進む。図３９に関連して、これを詳細に説明する。

図３４は、クライアントにおけるデータ交換を示すシーケンス図である。図３４に示されるように、３４０１において、ｔｒａｎｓｐｏｒｔ：：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅＱｕｅｕｅオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｇｅｔＮｅｘｔＤａｔａＢｌｏｂ（ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒ）：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒを継承する。３４０２において、ｔｒａｎｓｐｏｒｔ：：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅＱｕｅｕｅオブジェクトは、開発者からａｄｄＤａｔａＢｌｏｂ（ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒ）を継承する。３４０３において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｓｅｒｉａｌｉｚｅ（ＯｕｔｐｕｔＳｔｒｅａｍ）を：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒオブジェクトと関連付ける。３４０４において、ｔｒａｎｓｐｏｒｔ：：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅＱｕｅｕｅオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｇｅｔＮｅｘｔＤａｔａＢｌｏｂ（ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒ）：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒを継承する。３４０５において、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトは、開発者からｗａｉｔＦｏｒＣｏｍｐｌｅｔｉｏｎ（）を継承する。３４０６において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎは、ｓｅｒｉａｌｉｚｅ（ＯｕｔｐｕｔＳｔｒｅａｍ）を：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒオブジェクトと関連付ける。３４０７において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＱＵＥＳＴ）を：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトと関連付ける。３４０８において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＱＵＥＳＴ）を：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトと関連付ける。

３４０９において、ｔｒａｎｓｐｏｒｔ：：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＱｕｅｕｅは、：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトからｃｌｏｓｅ（）を継承する。３４１０において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒオブジェクトは、ｔｒａｎｓｐｏｒｔ：：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクトからｃｌｏｓｅ（）を継承する。３４１１において、ｔｒａｎｓｐｏｒｔ：：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｇｅｔＤａｔａＢｌｏｂ（Ｍｅｓｓａｇｅｓ．Ｈｅａｄｅｒ）：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒを継承する。３４１２において、ｔｒａｎｓｐｏｒｔ：：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｇｅｔＤａｔａＢｌｏｂ（Ｍｅｓｓａｇｅｓ．Ｈｅａｄｅｒ）：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒを継承する。尚、Ｍｅｓｓａｇｅ．Ｈｅａｄｅｒは、Ｍｅｓｓａｇｅｓクラス（不図示）の内部クラスであり、ＤＡＴＡ−ＨＥＡＤＥＲメッセージを規定する。３４１３及び３４１５において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒオブジェクトは、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトからｄｅｓｅｒｉａｌｉｚｅｒ（ＩｎｐｕｔＳｔｒｅａｍ）及びｄｅｓｅｒｉａｌｉｚｅｒ（ＩｎｐｕｔＳｔｒｅａｍ）を継承する。３４１４及び３４１６において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、ｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＳＰＯＮＳＥ）を：ＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクトと関連付ける。３４１７及び３４１８において、：ＣｌｉｅｎｔＣｏｎｎｅｃｔｉｏｎオブジェクトは、自身からｃｌｏｓｅ（）を継承する。３４１９及び３４２１において、ｔｒａｎｓｐｏｒｔ：：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクトは、開発者からｇｅｔＤａｔａＢｌｏｂｓ（）：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒ及びｄｉｓｐｏｓｅ（）を継承する。３４２０及び３４２２において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒオブジェクトは、ｇｅｔＤａｔａ（）：ＩｎｐｕｔＳｔｒｅａｍ及びｄｉｓｐｏｓｅ（）を継承する。

図３５及び図３６は、送信機におけるデータ交換を一般的に説明するフローチャートである。図３５のステップ３５０１において、データを送出するための要求を開始する。ステップ３５０２において、送信機は、取得するための次に使用可能な直列化データブロブがあるかを判定する。次に使用可能なデータブロブがある場合、送信機は、データブロブに対してデータヘッダを書き込み（ステップ３５０３）、データのソースからデータブロブのデータ部分を読み出し（ステップ３５０４）、読み出されたデータ部分を作成されたソケットに書き込む（ステップ３５０５）。ステップ３５０６において、送信機は、データ部分がデータブロブの最後のデータ部分であるかを判定する。データ部分が最後のデータ部分ではない場合、送信機は、データブロブの次のデータ部分を作成されたソケットに書き込む（ステップ３５０５）。ステップ３５０６でデータ部分が最後のデータ部分である場合、ステップ３５０２に戻る。次に使用可能な直列化データブロブがないとステップ３５０２で判定される場合、要求が完了し（ステップ３５０７）、受信したデータへの応答が実行される（ステップ３５０８）。

図３６において、ステップ３６０１で受信したデータへの応答が実行される。ステップ３６０２において、着信データに対するデータヘッダが読み出される。ステップ３６０３において、送信機は、読み出されたデータヘッダと関連付けられた非直列化データブロブを取得する。ステップ３６０４において、送信機は、作成されたソケットからデータブロブのデータ部分を読み出す。ステップ３６０５において、送信機は、読み出されたデータ部分をデータ記憶装置に書き込む。３６０６において、送信機は、データ部分がデータブロブの最後のデータ部分であるかを判定する。データ部分が最後のデータ部分ではないと判定される場合、送信機が次のデータ部分をデータ記憶装置に書き込むステップ３６０５に戻る。データ部分が最後のデータ部分であると判定される場合、ステップ３６０７に進む。ステップ３６０７において、送信機は、データヘッダが受信されるデータに対する最後のデータヘッダであるかを判定する。データヘッダが最後のデータヘッダである場合、応答が完了する（ステップ３６０８）。

図３７は、サーバにおけるデータ交換を示すシーケンス図である。図３７に示されるように、３７０１及び３７０２において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクトは、ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｇｅｔＤａｔａＢｌｏｂ（Ｍｅｓｓａｇｅｓ．Ｈｅａｄｅｒ）：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒを継承する。３７０３及び３７０４において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｄｅｓｅｒｉａｌｉｚｅｒ（ＩｎｐｕｔＳｔｒｅａｍ）を継承する。３７０５及び３７０６において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＱＵＥＳＴ）を継承する。３７０７において、＜＜ｉｎｔｅｒｆａｃｅ＞＞：Ｄｉｓｐａｔｃｈｅｒオブジェクトは、：ＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクトからｄｏＷｏｒｋ（ＳｅｒｖｅｒＳｅｓｓｉｏｎ）を継承する。３７０８において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅは、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＤｉｓｐａｔｃｈｅｒオブジェクトからｇｅｔＤａｔａＢｌｏｂｓ（）：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒを継承する。３７０８において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅは、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＤｉｓｐａｔｃｈｅｒオブジェクトからｇｅｔＤａｔａＢｌｏｂｓ（）：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒを継承する。３７０９において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒオブジェクトは、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＤｉｓｐａｔｃｈｅｒオブジェクトからｇｅｔＤａｔａ（）：ＩｎｐｕｔＳｔｒｅａｍを継承する。

３７１０及び３７１１において、：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクト及び：ＤａｔａＢｌｏｂＤｅｓｅｒｉａｌｉｚｅｒオブジェクトはｄｉｓｐｏｓｅ（）を継承する。３７１２において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクトは、＜＜ｉｎｔｅｒｆａｃｅ＞＞：ＤｉｓｐａｔｃｈｅｒオブジェクトからａｄｄＤａｔａＢｌｏｂ（ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒ）を継承する。３７１３及び３７１４において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｇｅｔＮｅｘｔＤａｔａＢｌｏｂ（ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒ）：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒを継承する。３７１５及び３７１６において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒオブジェクトは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｓｅｒｉａｌｉｚｅ（ＯｕｔｐｕｔＳｔｒｅａｍ）を継承する。３７１７及び３７１８において、：ＳｅｒｖｅｒＳｅｓｓｉｏｎは、：ＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトからｓｅｔＣｏｍｐｌｅｔｉｏｎＳｔａｔｅ（ＲＥＳＰＯＮＳＥ）を継承する。３７１９及び３７２０において、：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒＱｕｅｕｅオブジェクト及び：ＤａｔａＢｌｏｂＳｅｒｉａｌｉｚｅｒオブジェクトは、ｃｌｏｓｅ（）を継承する。

図３８及び図３９は、受信機におけるデータ交換を一般的に説明するフローチャートである。図３８において、ステップ３８０１で受信したデータへの応答が実行される。ステップ３８０２において、着信データに対するデータヘッダが読み出される。ステップ３８０３において、受信機は、読み出されたデータヘッダと関連付けられた非直列化データブロブを取得する。ステップ３８０４において、受信機は、作成されたソケットからデータブロブのデータ部分を読み出す。ステップ３８０５において、受信機は、読み出されたデータ部分をデータ記憶装置に書き込む。３８０６において、受信機は、データ部分がデータブロブの最後のデータ部分であるかを判定する。データ部分が最後のデータ部分ではないと判定される場合、受信機が次のデータ部分をデータ記憶装置に書き込むステップ３８０５に戻る。データ部分が最後のデータ部分であると判定される場合、ステップ３８０７に進む。ステップ３８０７において、受信機は、データヘッダが受信されるデータに対する最後のデータヘッダであるかを判定する。データヘッダが最後のデータヘッダである場合、応答が完了する（ステップ３８０８）。

図３９のステップ３９０１において、データを送出するための要求を開始する。ステップ３９０２において、受信機は、取得するための次に使用可能な直列化データブロブがあるかを判定する。次に使用可能なデータブロブがある場合、受信機は、データブロブに対してデータヘッダを書き込み（ステップ３９０３）、データのソースからデータブロブのデータ部分を読み出し（ステップ３９０４）、読み出されたデータ部分を作成されたソケットに書き込む（ステップ３９０５）。ステップ３９０６において、受信機は、データ部分がデータブロブの最後のデータ部分であるかを判定する。データ部分が最後のデータ部分ではない場合、受信機は、データブロブの次のデータ部分を作成されたソケットに書き込む（ステップ３９０５）。ステップ３９０６でデータ部分が最後のデータ部分である場合、ステップ３９０２に戻る。次に使用可能な直列化データブロブがないとステップ３９０２で判定される場合、要求が完了し（ステップ３９０７）、受信したデータへの応答が実行される（ステップ３９０８）。

［送信機と受信機との間の接続の数のオートチューニング］
図４０は、別の実施形態の例を詳細に説明するフローチャートである。より具体的には、図４０は、図１に示されたようなネットワーク１２０を介した送信機１０１から送信機１０１に接続された受信機１０２への大量のデータ転送に対する一実施形態の例を詳細に説明するフローチャートを示す。

図４０に示されるように、ステップ４００１及び４００２において、ネットワーク１２０を介して送信機１０１と受信機１０２との間に複数の接続が確立される。これらの接続は、並列ＴＣＰ接続等であってよいが、複数の接続はＴＣＰ接続に限定されず、並列接続を使用する他のプロトコルが使用されてもよい。ステップ４００３において、データは、ネットワーク１２０の帯域幅の利用を集約するように複数の接続を介してデータを分割して送出することで送信機１０１から受信機１０２に送出される。ステップ４００４において、受信機１０２は、複数の接続を介して分割データを受信し、分割データを元の形式に再結合する。

ステップ４００５〜４０１０において、送信機１０１と受信機１０２との間の接続の数、並びに送信機１０１におけるＩ／Ｏストレージシステムの少なくとも１つの性能、受信機１０２におけるＩ／Ｏストレージシステムの性能及びネットワーク１２０の性能に基づいてオートチューニングが実行される。オートチューニングが実行され、データの理想的で効率的なスループットを提供するように送信機と受信機との間の最適な数の接続を提供する。特に、ステップ４００５において、データが図２に示されたようなオートチューニングソフトウェア２３６を介するネットワーク１２０を介して送出されているよりも速く送信機１０１のＩ／Ｏストレージシステムがデータを読み出しているかを判定する。例えば、送信機１０１のＩ／Ｏストレージシステムが送信機のメモリバッファにデータを入力している速度の計算と、データがネットワーク１２０からの送信機のメモリバッファから取り出されている速度の計算とを比較することにより、このような判定を行う。データがネットワーク１２０を介して送出されているよりも速く送信機１０１のＩ／Ｏストレージシステムがデータを読み出していることがステップ４００５で判定される場合、送信機１０１が新しい接続を開くための要求を受信機１０２に送出する送信機１０１と受信機１０２との間の接続の数に対してオートチューニングを実行する。新しい接続を開くための要求が成功であったという応答を受信機１０２が返送する場合、送信機１０１は、システムにおいてデータの平滑な流れを提供するように新しい接続を介してデータを送出できる。

新しい接続を開くための要求を送出する場合、送信機１０１は、１つ以上の新しい接続が開かれることを要求してもよい。しかし、多くの新しい接続が開かれることを送信機１０１が要求する場合、受信機１０２は、以下に更に詳細に説明する多くの種々の理由のために、全ての新しい接続を開くための要求を拒否してもよい。

データがネットワーク１２０を介して送出されているよりも速く送信機１０１のＩ／Ｏストレージシステムがデータを読み出していないことがステップ４００５で判定される場合、ステップ４００６に進む。ステップ４００６において、データがネットワーク１２０を介して送出されているよりも遅く送信機１０１のＩ／Ｏシステムがデータを読み出しているかを判定する。データがネットワーク１２０を介して送出されているよりも遅く送信機１０１のＩ／Ｏシステムがデータを読み出しており、且つ図１の送信機１３１及び１３２のうちのいずれか等の２つ以上の送信機が受信機１０２にデータを送出していると判定される場合、送信機１０１は、複数の接続の既存の接続を閉じ、送信機１０１と受信機１０２との間の接続の数をオートチューニングする。この点に関して、既存の接続を閉じることは、一次接続ではなく二次接続を閉じることである。上記の結果、送信機１０１は、データを送出するために送信機１０１により最大限に利用されていない受信機１０２におけるソケットの占有を実質的に回避してもよい。

低い利用度を有する送信機のメモリバッファを確認することにより、例えば、メモリバッファの利用度がある特定の期間（例えば、３０秒）低いままであり、メモリバッファサイズの合計の所定の閾値（例えば、３０％）を下回ったままである場合、送信機は、データが送出されているよりも遅く自身がデータを読み出していると結論付けてよい。同様に、メモリの利用度がある期間の間高く且つその時間フレーム中に閾値（例えば、メモリバッファの８０％が使用されている）に到達する場合、送信機は、データがネットワーク１２０を介して送出されているよりも速く送信機１０１のＩ／Ｏシステムがデータを読み出していると結論付けてよい。

ステップ４００９において、大量のデータ転送に対する障害が受信機１０２のＩ／Ｏストレージシステムに存在するかがオートチューニングソフトウェア３３６により検出される。大量のデータ転送に対する障害が受信機１０２のＩ／Ｏストレージシステムに存在することが検出される場合、受信機１０２が既存の接続（すなわち、二次接続）を閉じる送信機１０１と受信機１０２との間の接続の数に対してオートチューニングを実行する。受信機１０２は、１つ以上の既存の二次接続を閉じてよい。

送信機１０１は、送信機１０１におけるバッファがほぼ満杯であることを検出する場合、新しい接続を開くための要求を受信機に送出してもよいか、あるいは既に作成されているが現在データを送出するために使用されていない接続を利用する。送信機におけるバッファがほぼ満杯である場合に新しい接続を開くことは、送信機からデータを送出する際の遅延又は間隔を減少できるために全体的に平滑なデータ転送を提供するという有利な影響を及ぼす。あるいは、送信機１０１は、大量のデータ転送に対する障害が送信機のＩ／Ｏストレージシステムに存在することを検出する場合、既存の二次接続を閉じてもよい。送信機１０１におけるバッファがほぼ空である場合、送信機１０１のＩ／Ｏストレージシステムにおける大量のデータ転送に対する障害ありと検出する。

場合によっては、受信機１０２のＩ／Ｏストレージシステムは、図６のディスク６０９等のディスクを含む。これらの例において、ディスクのシーク動作が受信機１０２のＩ／Ｏストレージシステムに対して実行される時に受信機１０２のＩ／Ｏストレージシステムにおける大量のデータ転送に対する障害ありと検出する。より具体的には、複数の接続が使用されているため、データは、受信機１０２において順番に到着しなくてもよい。受信機１０２が次の連続データチャンクを待って時間切れになるかあるいはそのメモリバッファを満たす場合、受信機１０２のＩ／Ｏストレージシステムは、更なるシーク動作を後で必要とする可能性のある故障データに対するディスク書き込みを実行してもよい。これは、受信機１０１のＩ／Ｏストレージシステムがデータをディスクに書き込んでいるよりも速く送信機１０１から受信機１０２にデータが転送されていることを意味するだろう。従って、障害は、受信機１０２のＩ／Ｏストレージシステムに存在するだろう。

あるいは、受信機１０２のＩ／Ｏシステムがディスクを含むこれらの例において、受信機１０２のＩ／Ｏストレージシステムが前のＩ／Ｏ書き込み速度よりも遅くデータをディスクに書き込んでいる時に受信機１０２のＩ／Ｏストレージシステムにおける大量のデータ転送に対する障害ありと検出する。前のＩ／Ｏ書き込み速度は、２回以上の書き込み動作に対して前に測定されたＩ／Ｏ書き込み速度又は書き込み動作の期間中に前に測定されたＩ／Ｏ書き込み速度、あるいは書き込み動作の前に測定されたＩ／Ｏ書き込み速度の加重平均に基づいてよい。例えば、受信機のＩ／Ｏストレージシステムの前のＩ／Ｏ書き込み速度が１０Ｍｂ／ｓであり、且つ受信機のＩ／Ｏストレージシステムが現在５Ｍｂ／ｓでデータを書き込んでいる場合、障害は、受信機のＩ／Ｏストレージシステムに存在するだろう。例えば受信機のＩ／Ｏストレージシステムが他の非ＭＤＴアプリケーションを処理している場合、Ｉ／Ｏストレージシステムの書き込み速度は低下する可能性がある。

ステップ４０１０において、データがネットワーク１２０から受信されるよりも速く受信機１０２のＩ／Ｏストレージシステムがデータを書き込んでいるかを判定する。例えば、受信機１０２のＩ／Ｏストレージシステムが受信機１０２のメモリバッファからデータを書き出している速度の計算と、データがネットワーク１２０により受信機１０２のメモリバッファに入力されている速度の計算とを比較することにより、このような判定を行ってよい。データがネットワーク１２０から受信されるよりも速く受信機１０２のＩ／Ｏストレージシステムがデータを書き込んでいると判定される場合、受信機１０２は、新しい接続（図５に示されたようなＡＣＫ機構を介して）を開くように送信機に命令又は提案する。

図４０のステップ４０１０において、データがネットワーク１０２から受信されるよりも速く受信機１０２のＩ／Ｏストレージシステムがデータを書き込んでいないと判定される場合、ステップ４０１３に進む。ステップ４０１３において、受信機１０２は、送信機１０１により送出される全てのデータを自身が受信しているかを判定する。全てのデータが受信機１０２により受信されている場合、処理は終了する（ステップ４０１４）。全てのデータが受信機１０２により受信されていない場合、ステップ４００４に進む。

ステップ４００７において、送信機１０１は、大量のデータ転送に対する障害がネットワーク１２０に存在するかを検出する。ステップ４００７で大量のデータ転送に対する障害がネットワーク１２０に存在することが検出される場合、送信機１０１は、送信機１０１と受信機１０２との間の既存の接続を閉じる。ネットワークにおける大量のデータ転送の障害が輻輳により発生する場合、既存の二次接続を閉じることでネットワークにおける更なる輻輳を減少できる。

ステップ４００７において、現在のラウンドトリップ時間（ＲＴＴ）が前のＲＴＴよりも長い場合、ネットワークにおける大量のデータ転送に対する障害ありと検出する。現在のＲＴＴ及び前のＲＴＴは、２つ以上のメッセージパッケージに対するＲＴＴ又はＲＴＴの加重平均に基づいてよい。現在のＲＴＴが実質的に前のＲＴＴよりも長い（例えば、＋２０％）場合、ネットワークは、使用中であり且つ他の送信機／受信機システムからのより多くのトラフィックを有するだろう。ネットワークが使用中である場合に既存の接続を閉じることにより、使用中のネットワークを介して更に多くのデータを送出することで発生するこれ以上の輻輳を減少してもよい。

一例において、荷重測定のサンプルは以下のように見えてもよい。すなわち、ｎ０〜ｎ９等の１０個のＲＴＴシーケンスサンプルがある場合、荷重ＲＴＴ測定は、１番目：ｎ０、２番目：（ｎ０*０．８＋ｎ１*０．２）、３番目（２番目：*０．８＋ｎ２*０．２）、４番目：（３番目*０．８＋ｎ３*０．２）、．．．、１０番目：（ｎ９*０．８＋ｎ９*０．２）である。

ステップ４００７で大量のデータ転送に対する障害がネットワーク１２０において検出されない場合、ステップ４００８に進む。ステップ４００８において、現在のラウンドトリップ時間（ＲＴＴ）が前のＲＴＴから実質的に短縮されているかを判定する。現在のＲＴＴ及び前のＲＴＴは、２つ以上のメッセージパッケージに対するＲＴＴ又はＲＴＴの加重平均に基づいてよい。現在のＲＴＴが前のＲＴＴから実質的に短縮されているとステップ４００８で判定される場合、送信機１０１は、新しい接続を開くための要求を受信機１０２に送出する。ＲＴＴを短縮することは、ネットワークの性能が向上していることを示す。従って、送信機１０１は、データのスループットを向上するために１つ以上の新しい接続を開きたい。

いくつかの状況において、送信機１０１及び受信機１０２におけるバッファサイズは、ネットワークにおける障害の検出又は受信機のＩ／Ｏストレージシステムにおける障害の検出に従って調整されてよい。特に本実施形態の例において、送信機におけるバッファのサイズは、バッファにデータが溢れるのを回避できるように拡大されてよい。

上述の実施形態の例により、通常、送信機及び受信機が理想的なスループットを提供することで大量のデータ転送に対する性能を向上するように接続の数を動的に増減する自己校正を提供することが可能である。また、多数の送信機／受信機構成にわたり公平性が保たれる。例えば、現在の並列接続の数が余剰のネットワーク帯域幅を集約しているために現在の障害が受信機のシステムＩ／Ｏである場合、接続のうちのいくつかは、他の送信機／受信機システムが使用するための帯域幅をリリースするように閉じられてよい。

他の実施形態の例において、各々が複数の大量のデータ転送のうちのそれぞれ１つを受信機１０２に送出する複数の送信機が存在する。例えば、図１に示されたように、送信機１３１及び１３２の各々は、送信機１０１が大量のデータ転送を受信機１０２に送出しているのとほぼ同時に大量のデータ転送を受信機１０２に更に送出していてもよい。これらの実施形態の例において、ネットワーク１２０を介して送信機１０１と受信機１０２との間に複数の接続を確立する場合、受信機１０２は、送信機１３１及び１３２等の他の送信機から要求された接続の数に基づいて送信機１０１と受信機１０２との間に確立されうる最大数の接続を設定する。例えば、全ての送信機が共有できる最大２０個の接続を受信機１０２が有し、且つ他の送信機が現在２０個の接続のうちの１５個を利用している場合、受信機１０２は、送信機１０１が他の送信機により使用されている１５個の接続に基づいてデータを転送するために使用してもよい最大５個の接続を設定してもよい。

いくつかの例において、ネットワーク１２０を介して送信機１０１と受信機１０２との間の複数の接続を確立する場合、受信機１０２は、他の送信機から要求された接続の数に基づいて最大数の接続が確立されうる期間を設定する。更に受信機１０２は、他の送信機から要求された接続の数に基づいて確立されうる最大数の接続のうちの各接続を確立するための開始時間を設定してもよい。例えば、最大３個の接続が受信機１０２により設定される場合、第１の二次接続は、一次接続が確立された１分後に確立され且つ４分間続いてもよく、第２の二次接続は、一次接続が確立された２分後に確立され且つ２分間続いてもよい。

いくつかの状況において、ジョブキューは、要求された接続の入力数と比較して、全ての複数の送信機間に存在する現在の接続の数を管理する受信機１０２に含まれたスケジュールマネージャ（すなわち、図３のスケジュールマネージャ３３８）により維持される。更にスケジュールマネージャは、複数の送信機の各々に優先度を割り当てる。この点に関して、スケジュールマネージャは、より少ない数の接続をより優先度の低い送信機に割り当てることと比較して、より多くの数の接続をより優先度の高い送信機に割り当てる。例えば、より優先度の高い送信機は、より小さなデータセットを有するより優先度の低い送信機と比較して大きなデータセットを有する送信機であってもよい。この例において、より大きなデータセットを有するより優先度の高い送信機は、より小さなデータセットを有するより優先度の低い送信機よりも多くの数の接続を割り当てられるだろう。

更に送信機は、データがネットワークを介して送出されているよりも速く送信機のＩ／Ｏストレージシステムがデータを読み出している時に１つ以上の接続を開くための要求を受信機に送出してもよい。接続の数をオートチューニングする場合、受信機は、１つ以上の接続がスケジュールマネージャにより使用可能であると判定される場合に要求された１つ以上の接続を開く。

更に送信機は、現在のラウンドトリップ時間（ＲＴＴ）が前のＲＴＴから実質的に短縮されている時に１つ以上の接続を開くための要求を受信機に送出してもよい。現在のＲＴＴ及び前のＲＴＴは、２つ以上のメッセージパッケージに対するＲＴＴ又はＲＴＴの加重平均に基づいてよい。接続の数をオートチューニングする場合、受信機は、１つ以上の接続がスケジュールマネージャにより使用可能であると判定される場合に要求された１つ以上の接続を開く。

この点に関して、接続は、スケジュールマネージャにより設定された期間の間開かれ且つ閉じられる。スケジュールマネージャにより設定された期間は、種々の接続毎に異なる期間であってもよい。最後に、各接続は異なる開始時間において開かれてもよい。

多数の要求が種々の送信機から受信機１０２により受信される場合、各送信機は、その処理能力により制限された種々の転送速度でデータを送出してよい。スケジュールマネージャ３３８は、ファイルデータサイズと共に受信する送信機の数及びデータ速度（この値は事前に使用可能であってもよい）に基づいて、公平性を保ち且つ全体的なシステムスループットを向上できる。

既存のデータ転送要求の処理中に新しい要求が受信される場合、受信機１０２は、後の要求を受け入れ、且つ第２の要求に対するセッションに参加できる（セッションｉｄと共に）通知された接続の数を返送できる。受信機は、データの処理及びＩ／Ｏストレージシステムへの書き込みの途中である場合、参加セッション要求の履行が終わり次第値を待つ時間と共に通知された接続の数を返送してもよい。一方、受信機は、第１の要求に残されたデータの量が第２の要求において転送するデータの量より大幅に少ないことを認識する場合、第１の要求に対する接続の数を減少し且つ第２の要求に対して許可された接続の数を増加できる。更に受信機１０２は、第２の要求に残されたデータの量が第１の要求において転送するデータの量より大幅に少ないことを認識する場合、第２の要求に対する接続の数を減少し且つ第１の要求に対して許可された接続の数を増加できる。

スケジュールマネージャ３３８は、要求を更に優先できる（すなわち、より優先度の高い新しい要求は、別の要求の処理中に到着する）。これは、メッセージレベルでアプリケーションポリシーと結び付けて実行されてよく、あるいは転送データレベルで送出されるデータと結び付けて実行されてよい。

本明細書は、例示した特定の実施形態を詳細に説明した。添付の特許請求の範囲の範囲は上述の実施形態に限定されず、且つ種々の変更及び変形が特許請求の範囲の範囲から逸脱せずに当業者により行われてもよいことが理解される。

また、本願は、ここに編入される、２０１０年８月３１日に出願された米国特許出願第１２／８７３３０５号からの優先権を請求するものである。

Claims (6)

1. ネットワークを介した送信機から前記送信機に接続された受信機へのデータ送信の方法であって、
   確立手段が、前記ネットワークを介して前記送信機と前記受信機との間に複数の接続を確立し、
   送出手段が、前記複数の接続を介してデータを分割して前記送信機から前記受信機に送出し、
   チューニング手段が、データが前記ネットワークを介して送出されているよりも遅く前記送信機のＩ／Ｏストレージシステムがデータを読み出している場合に既存の接続を閉じることにより、前記送信機と前記受信機との間の接続の数をチューニングすることを特徴とする方法。
2. 前記チューニング手段が、データが前記ネットワークを介して送出されているよりも速く前記送信機のＩ／Ｏストレージシステムがデータを読み出している場合に新しい接続を開くことにより、前記送信機と前記受信機との間の接続の数をチューニングすることを特徴とする請求項１に記載の方法。
3. 送信機であって、
   ネットワークを介して前記送信機と受信機との間に複数の接続を確立する確立手段と、
   前記複数の接続を介してデータを分割して前記送信機から前記受信機に送出する送出手段と、
   データが前記ネットワークを介して送出されているよりも遅く前記送信機のＩ／Ｏストレージシステムがデータを読み出している場合に既存の接続を閉じることにより、前記送信機と前記受信機との間の接続をチューニングするチューニング手段とを含むことを特徴とする送信機。
4. 前記チューニング手段が、データが前記ネットワークを介して送出されているよりも速く前記送信機のＩ／Ｏストレージシステムがデータを読み出している場合に新しい接続を開くことにより、前記送信機と前記受信機との間の接続をチューニングすることを特徴とする請求項３に記載の送信機。
5. コンピュータを送信機として機能させるためのプログラムであって、
   ネットワークを介して前記送信機と受信機との間に複数の接続を確立する確立手段と、
   前記複数の接続を介してデータを分割して前記送信機から前記受信機に送出する送出手段と、
   データが前記ネットワークを介して送出されているよりも遅く前記送信機のＩ／Ｏストレージシステムがデータを読み出している場合に既存の接続を閉じることにより、前記送信機と前記受信機との間の接続をチューニングするチューニング手段としてコンピュータを機能させるためのプログラム。
6. 前記チューニング手段が、データが前記ネットワークを介して送出されているよりも遅く前記送信機のＩ／Ｏストレージシステムがデータを読み出している場合に新しい接続を開くことにより、前記送信機と前記受信機との間の接続をチューニングする請求項５に記載のプログラム。

Images