JP5331897B2 - 通信方法、情報処理装置及びプログラム - Google Patents

Description

本発明は、通信方法、情報処理装置及びプログラムに関する。

ホストコンピュータシステムと、イーサネットやＩｎｆｉｎｉＢａｎｄなどの通信方式におけるネットワークアダプタとの間で、データを転送する方法が知られている。この方法では、ネットワークアダプタはホストシステムのデバイスドライバからの送信要求メッセージで指定されたホストメモリの特定のアドレスからデータを読み取る。

又、プロセッサ間のデータ転送方法として、プロセッサからメッセージを同報通信する場合に、物理的なサブネットワークに属する全てのプロセッサに対して無条件に同報通信を行うブロードキャストと呼ばれる方法が知られている。更により一般にネットワーク内のノードの一部に対し選択的に同報通信を行う場合を含めたマルチキャストと呼ばれる方法が知られている。ネットワーク・ハードウェア関連技術の分野では、ブロードキャストとマルチキャストの両者を厳密に区別する場合が多い。しかし、並列計算関連技術の分野では、ブロードキャストとマルチキャストの両者を明確に区別しない場合、あるいは、ある一時点で論理的に通信に関与しているプロセッサ乃至それらのプロセッサ上で動作しているプログラム全てへの同報通信をブロードキャストと呼ぶ場合がある。

又、互いに複数の独立したネットワークが相互に接続された複数の処理ノードにおいて、各ノードが並列アルゴリズム動作を実行する並列計算を実行する並列スーパーコンピュータが知られている。当該並列スーパーコンピュータでは、当該互いに独立したネットワークの一つであるグローバルバリアネットワークによって、複数の処理ノード間の同期処理の一種であるバリア同期が可能である。ここでグローバルバリアネットワークとは、非特許文献１３、第２０２頁、右欄第５行目乃至２３行目に記載されたBarrier Networkを意味する。

特表２００４−５３１００１号公報 特開平８−７７１２７号公報 特表２００４−５３８５４８号公報

Rajeev Thakur, Rolf Rabenseifner, William Gropp, "Optimization of Collective Communication Operations in MPICH", International Journal of High Performance Computing Applications Juan Fernandez, Eitan Frachtenberg, Fabrizio Petrini, "BCS-MPI: A New Approach in the System Software Design for Large-Scale Parallel Computers", Proceedings of the ACM/IEEE SC2003 Conference (SC 03) Katia Obraczka, "Multicast transport protocols: A survey and taxonomy," IEEE Commun. Mag., vol. 36, no. 1, pp. 94-102, Jan. 1998. Kees Verstoep, Koen Langendoen, Henri Bal,"Efficient reliable multicast on Myrinet", Parallel Processing, 1996, Proceedings of the 1996 International Conference Jiuxing Liu, Amith R Mamidala, Dhabaleswar K Panda, "Fast and Scalable MPI-Level Broadcast using InfiniBand's Hardware Multicast Support", Technical Report, OSU-CISRC-10/03-TR57, October 2003 「ＲＤＭＡプロトコル：ネットワークパフォーマンスの向上」（ＵＲＬ：http://h50146.www5.hp.com/products/servers/proliant/whitepaper/wp049_060331/pdfs/wp049_060330.pdf、２００９年５月１４日現在） Torsten Hoefler, Christian Siebelt, and Wolfgang Rehm, "A Practically constant-time MPI Broadcast Algorithm for large-scale InfiniBand Clusters with Multicast" "Concurrency: Mutual exclusion and synchronization" (URL: http://www.cs.helsinki.fi/u/alanko/rio/S02/kalvokopiot/ch3_p2.pdf、２００９年５月１４日現在） "Barrier Synchronization", Maurice Herlihy & Nir Shavit (URL: http://www.cs.brown.edu/courses/cs176/ch17.ppt、２００９年５月１４日現在) 「高機能・高性能システムインターコネクト技術の開発」九州大学／富士通株式会社 石畑宏明(URL: http://www.psi-project.jp/images/event/hiroaki_ishihata_20061220.pdf、２００９年５月１４日現在) 「コレクティブ通信をサポートする高機能スイッチの開発」富士通株式会社 清水俊幸(URL: http://www.psi-project.jp/images/event/toshiyuki_shimizu_20080218.pdf、２００９年５月１４日現在) 富士通フォーラム２００８「ペタスケールコンピューティングを担う先進技術」(URL: http://forum.fujitsu.com/2008/tokyo/exhibition/downloads/pdf/technology02_panf_jp.pdf、２００９年５月１４日現在) A. Gara et al. "Overview of the BlueGene/L system architecture", IBM J. RES & DEV. VOL. 49 NO. 2/3 MARCH/MAY 2005

送信側のノードから複数の受信側のノードに対して同報通信を行う場合、複数の受信側ノードにおいて確実に同期した上で、同期通信を実行し得る構成を提供することが目的である。

送信元ノードが複数の送信先ノードの各々へ送信する送信データを、送信元ノードが有する通信用のバッファに格納し、送信元ノードが、通信用のバッファから複数の送信先ノードが送信データを受信するために必要なバッファ情報を作成する。そして送信元ノードが複数の送信先ノードの各々に対し、複数の送信先ノードの各々からの同期信号全てを受信することにより同期を行うバリア同期により同報通信を行うことによって前記バッファ情報を送信する。そして複数の送信先ノードの各々が、１対１通信によって、バッファ情報を使用して通信用のバッファから前記送信データを受信する。

バリア同期による同報通信によって送信データより短いデータを確実に同報することができる。このため、バリア同期による同報通信により、複数の送信先ノードの各々に対しバッファ情報を確実に送信することができる。そして複数の送信先ノードの各々は当該バッファ情報を使用して１対１通信を行って通信用のバッファから送信データを受信するため、確実に送信データを受信することができる。

第１実施例に係る通信方法の動作の流れを示すフローチャート（その１）である。 第１実施例に係る通信方法の動作の流れを示すフローチャート（その２）である。 第２実施例による通信方法の動作の流れを示すフローチャート（その１）である。 第２実施例による通信方法の動作の流れを示すフローチャート（その２）である。 第１実施例に係る通信方法の動作の流れを示すフローチャート（その３）である。 第１実施例に係る通信方法の動作の流れを示すフローチャート（その４）である。 第１実施例に係る通信方法の具体例１を説明する図（その１）である。 第１実施例に係る通信方法の具体例１を説明する図（その２）である。 第１実施例に係る通信方法の具体例１を説明する図（その３）である。 第１実施例に係る通信方法の具体例２を説明する図（その１）である。 第１実施例に係る通信方法の具体例２を説明する図（その２）である。 第１実施例に係る通信方法の具体例２を説明する図（その３）である。 第１実施例に係る通信方法の具体例３を説明する図（その１）である。 第１実施例に係る通信方法の具体例３を説明する図（その２）である。 第１実施例に係る通信方法の具体例３を説明する図（その３）である。 第１実施例に係る通信方法の具体例４を説明する図（その１）である。 第１実施例に係る通信方法の具体例４を説明する図（その２）である。 第１実施例に係る通信方法の具体例４を説明する図（その３）である。 第２実施例による通信方法の動作の流れを示すフローチャート（その３）である。 第２実施例による通信方法の動作の流れを示すフローチャート（その４）である。 第２実施例による通信方法の動作の流れを示すフローチャート（その５）である。 第２実施例による通信方法の動作の流れを示すフローチャート（その６）である。 第２実施例による通信方法の具体例１を説明する図（その１）である。 第２実施例による通信方法の具体例１を説明する図（その２）である。 第２実施例による通信方法の具体例１を説明する図（その３）である。 第２実施例による通信方法の具体例２を説明する図（その１）である。 第２実施例による通信方法の具体例２を説明する図（その２）である。 第２実施例による通信方法の具体例２を説明する図（その３）である。 第２実施例による通信方法の具体例３を説明する図（その１）である。 第２実施例による通信方法の具体例３を説明する図（その２）である。 第２実施例による通信方法の具体例３を説明する図（その３）である。 第１実施例および第２実施例の各々の各具体例における各ノード（送信側のノード、受信側のノードあるいは中継ノード）のハードウェア構成例について説明するブロック図である。 第１実施例および第２実施例の各々における同報通信（バリア同期を使用する方法）の動作の流れを示すフローチャートである。 図１４におけるバリア同期の動作の流れを示すフローチャートである。 第１実施例および第２実施例の各々における同報通信（リダクション装置を使用する方法）の動作の流れを示すフローチャートである。 図１６におけるリダクション装置を使用する方法の動作の流れを示すフローチャートである。 図１６，図１７に記載されたリダクション装置を使用する方法について説明するブロック図である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突（ｃｏｌｌｉｓｉｏｎ）の回避を図る方法を説明する図（その１）である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突の回避を図る方法を説明する図（その２）である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突の回避を図る方法を説明する図（その３）である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突の回避を図る方法を説明する図（その４）である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突の回避を図る方法を説明する図（その５）である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突の回避を図る方法を説明する図（その６）である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突の回避を図る方法を説明する図（その７）である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突の回避を図る方法を説明する図（その８）である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突の回避を図る方法を説明する図（その９）である。 複数のノードが基点となるＲＲＤＭＡ機能の実施における衝突の回避を図る方法を説明する図（その１０）である。 「通信用のバッファ」の設定例について説明するための図である。 「リカバリ制御情報」のデータフォーマット例について説明するための図である。

第１実施例に係る通信方法は、データが短い場合の信頼性のある同報通信方法と信頼性のある１対１通信方法とを使用する通信方法である。第１実施例に係る通信方法では特に、データが短い場合の信頼性のある同報通信方法によりノード間でバッファ情報（後述）の共有制御を行うことに特徴を有する。

第２実施例に係る通信方法は、データが短い場合の信頼性のある同報通信方法とデータが長い場合の必ずしも信頼性のない同報通信方法とを使用する通信方法である。第２実施例に係る通信方法では特に、データが短い場合の信頼性のある同報通信方法を、データが長い場合の同報通信方法を実行する際のタイミング制御と伝送エラー回復処理の高速化とに使用することに特徴を有する。

なお第１実施例に係る通信方法と第２実施例に係る通信方法とを適宜組み合わせてデータの通信を行う通信方法の実施例も可能である。

上記各実施例は並列計算を行うノード間の同報通信方法である。ここで並列計算における同報通信の技術として、以下の３種類の方式１）、２）、３）がある。

１）第１の方式はもっとも一般的な方式であり、各ノードが信頼性のある１対１通信方法により、所定のアルゴリズムに従ってデータをノード間で転送することによって、同報通信を実現する方式である(非特許文献１，４参照)。この方式は実現に際して一般的な用途に使用される通信方法のみを使用するため、実現に要される費用が少なく済む。この方式に関連する技術として、中継アルゴリズムの選択に関する技術、システムの通信方式の特性を利用して各段での１対１通信に際して同報通信を高速化する技術等がある。それぞれの技術に一定の効果はあるが、本方式を取る限り通信遅延が少なくとも全ノード数の対数とノード間での遅延との積になる。又、長いデータの同報通信に際して、１対１通信のバンド幅による制約を重視するアルゴリズムを使用した場合には通信遅延は全ノード数に比例する。当該場合とは、中継先を１つだけに絞り、各段の中継の際に１対１通信での全バンド幅を中継に使用する場合である。

２）第２の方式は、第１の方式に比べると実現例が少ないが、必ずしも信頼性のない同報通信をデータの転送に利用する方式である。当該方式では、場合により、信頼性のある１対１通信方法による再送を通信プロトコル上のタイミングの制御や伝送エラーの回復に使用する(非特許文献３，５を参照)。この方式はデータ本体（送信データ）の転送についてノード間の中継が不要であり、通信方式での伝送エラー率が十分小さい限り効率が高い。しかしながら伝送エラー時の回復処理の際に用いられるデータの送達確認手段を１対１通信で実現することによる負荷の面で、ノード数が大きい場合への対応が難しいと考えられる。

３）第３の方式は、やはり実現例は少ないが、同報通信機能を持つ通信記憶専用ノード内に、次の中継点への転送が完了するまでの間データを保持するバッファを設ける方式である。当該方式では、通信中継装置間での通信で送達を確認することで信頼性のある同報通信方法を実現する（非特許文献２のQuadrics の項参照）。ここで通信中継装置とは、例えばスイッチ（交換機）あるいはルータを示す（以下同様）。同方式によればノード間の直接のデータ転送が不要であり、送信ノードの送達確認負荷も小さいので、通信効率が高い。しかしながら複数の方向への中継処理の際、各方向の通信路の輻輳状況が異なる場合のバッファ使用状況を制御することが難しいため、この方式での同報通信機構は使用の条件を限定しないと実現が難しいと考えられる。この方式は、同じネットワーク内での特定の一組のノード群だけによって使用され、かつノード群がネットワーク上で全て互いに隣接している場合に限定して使用される例が多い。

第１実施例に係る通信方法および第２実施例に係る通信方法の各々によれば、並列計算を行うノード間の同報通信を高速に行うことが可能である。並列計算での同報通信は、データの一部についてでも伝送エラーがあれば計算全体が無意味になるため、信頼性のある同報通信でなければならない。又、並列計算における同報通信において扱われるデータの長さは計算の内容に応じて様々な長さとなる。ここで一般的な用途において同報通信を高速に行う通信装置は、以下の２種類の同報通信方法を使用する場合が多いと考えられる。通信装置とは、例えば通信カードであり、通信カードは、例えばＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）である（以下同様）。すなわち、第１の同報通信方法は、データが短い場合に信頼性がある同報通信方法であり、第２の同報通信方法は、データが長い場合の必ずしも信頼性のない（伝送エラーの可能性を残す）同報通信方法である。上記第１および第２の同報通信方法のいずれによっても、並列計算において使用される同報通信にとって必要な条件は満たされないと考えられる。

そこで第１実施例に係る通信方法は、データが短い場合の信頼性のある同報通信方法と、信頼性のある１対１通信方法とを使用する通信方法である。第１実施例に係る通信方法では特に、データが短い場合の信頼性のある同報通信方法により、並列計算を行う複数のノード間でバッファ情報（後述）の共有制御を行う。

又、第２実施例に係る通信方法は、データが短い場合の信頼性のある同報通信方法および、データが長い場合の必ずしも信頼性のない同報通信方法を使用する通信方法である。第２実施例に係る通信方法では特に、データが短い場合の信頼性のある同報通信方法を、データが長い場合の同報通信方法の実施におけるタイミング制御と伝送エラー回復処理の高速化とに使用する。

又、上記第１実施例に係る通信方法と第２実施例に係る通信方法とを適宜組み合わせて併用しながら、並列計算を行う複数のノード間の同報通信を行う実施例も可能である。

なお上記「データが短い場合の信頼性のある同報通信方法」における「データが短い」点の意義について以下に説明する。「データが短い」とは、単に「並列計算で同報通信したいデータの長さに比べて、使用される通信方式においてサポートされる同報通信の１回の動作で送ることができるデータが短い」ことを意味する。ここで一般に通信方式の機能が限定的になるほど、当該機能をハードウェアとして実装することが容易になると考えられる。すなわち、同報通信の対象を「１回の物理パケット長より短いメッセージに限る」という限定、「固定長のヘッダ部分だけで、可変長のメッセージ本文がない情報に限る」という限定等により、同報通信の実現がより容易になると考えられる。すなわち、より一般的な「複数の物理パケットからなるメッセージ本文つき」の情報を対象とした同報通信に比べ、上記の如くの限定による「短いデータ」を対象とする同報通信の方が、実現が容易と考えられる。したがって「データが短い場合の信頼性のある同報通信方法」は、「データが長い場合の信頼性のある同報通信方法」に比して実現が容易と考えられる点に意義がある。

図１Ａ、図１Ｂは、第１実施例に係る通信方法の概略の動作の流れを示す。図１ＡのステップＳ１で送信側のノードが、通信用のバッファ（後述する）に送信データを格納する。ステップＳ２で送信側のノードが、通信用のバッファに関するバッファ情報を有するパケットを作成する。ステップＳ３で送信側のノードは、上記バッファ情報を有するパケットを、データが短い場合の信頼性のある同報通信方法により、複数の受信側のノードの各々に対し送信する。

図１ＢのステップＳ４にて複数の受信側のノードの各々は、ステップＳ３にて送信されたバッファ情報を有するパケットを、上記データが短い場合の信頼性のある同報通信方法により受信する。ステップＳ５にて複数の受信側のノードの各々は、ステップＳ４にて受信したパケットが有するバッファ情報を使用して上記通信用のバッファにアクセスし、当該通信用のバッファに格納された送信データを受信する。

ここで上記「データが短い場合の信頼性のある同報通信方法」とは、例えば後述する「バリア同期」あるいは「リダクション装置」を使用した通信方法である（以下同様）。又、ステップＳ５において、通信用のバッファにアクセスし、当該通信用のバッファに格納された送信データを受信する方法（すなわち信頼性のある１対１通信方法）は、例えば後述するＲＲＤＭＡ（Ｒｅａｄ Ｒｅｍｏｔｅ Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）機能を使用する方法である（以下同様）。 図２Ａ、図２Ｂは、第２実施例に係る通信方法の概略の動作の流れを示す。図２ＡのステップＳ１１にて送信側のノードは、複数の受信側のノードの各々に対して送信する送信データの完全性のチェックとリカバリに必要な情報としてのリカバリ制御情報を作成する。ステップＳ１２にて送信側のノードは、リカバリ制御情報を、データが短い場合の信頼性のある同報通信方法により、複数の受信側のノードの各々に対し送信する。ステップＳ１３にて送信側のノードは、送信データを、データが長い場合の必ずしも信頼性のない同報通信方法により、複数の受信側のノードの各々に対し送信する。ステップＳ１４にて送信側のノードは、送信データの再送等の送信データのリカバリが必要か否か判断する。例えば、後述するステップＳ１９にて受信側のノードから再送要求が送信された場合に、送信データのリカバリが必要と判断する。次にステップＳ１５にて送信側のノードは、ステップＳ１４にてリカバリが必要と判断した場合に該当する送信データのリカバリを実行する。ステップＳ１４にて送信データのリカバリが必要でないと判断した場合、動作を終了する。

図２ＢのステップＳ１６にて複数の受信側のノードの各々は、上記ステップＳ１２で送信されたリカバリ制御情報を、上記データが短い場合の信頼性のある同報通信方法にて受信する。ステップＳ１７にて複数の受信側のノードの各々は、ステップＳ１３で送信された送信データを、上記データが長い場合の必ずしも信頼性のない同報通信方法にて受信する。ステップＳ１８にて複数の受信側のノードの各々は、ステップＳ１６で受信したリカバリ制御情報に含まれる送信データの完全性のチェックに必要な情報を使用し、受信した送信データの完全性をチェックする。そして当該チェックの結果に基づき、送信データのリカバリが必要か否かを判断する。送信データのリカバリが必要な場合（ステップＳ１８のＹＥＳ），複数の受信側のノードの内の該当するノードはステップＳ１９にて、上記リカバリ制御情報に基づき、送信データのリカバリを実行する。送信データのリカバリが必要ではない場合（ステップＳ１８のＮＯ），動作を終了する。

上記「データが短い場合の信頼性のある同報通信方法」とは上記同様、例えば後述する「バリア同期」あるいは「リダクション装置」を使用する通信方法である（以下同様）。又、上記「データが長い場合の必ずしも信頼性のない同報通信方法」とは、例えばマルチキャストによる通信方法である（以下同様）。

上記「短いデータに対する信頼性のある同報通信方法」によって送信できるデータ長の上限値は比較的小さい。他方、一般に多数のノードが接続されたネットワーク内では、各ノードを示すアドレスのビット数が大きくなる。又、大容量の記憶装置内での位置を示すアドレスのビット数は大きい。ここで上記「送信できるデータ長の上限値」が上記バッファ情報の大きさより小さい場合は、以下の(a),(b),(c)の方法の内の一の方法、あるいは(a),(b),(c)の方法のうちの複数を組み合わせた方法で対処することができる。
(a)「短いデータに対する信頼性のある同報通信方法」を複数回使用して、バッファ情報を分割して送信する。
(ｂ)バッファ情報として、通信用のバッファにアクセスして送信データを受信する際に使用されるバッファのアドレスそのものを送信する代わりに、バッファのアドレス自体より短い情報に変換して送信する。当該変換は以下の(1)乃至(3)に示す如くの、「バッファアドレスの再符号化」により実現する。
(1)通信用のバッファを設けるノードのネットワークアドレスを比較的少数に限定し、それらに番号を振る。番号はネットワーク全体を通して一意に振る必要はなく、送信側のノードと受信側のノードとの組み合わせ、あるいは、送信側のノードのグループと受信側のノードのグループとの組み合わせに対して一意であればよい。
(2) 通信用のバッファを設ける記憶装置内のアドレスを比較的少数に限定し、番号を振る。この番号の振り方も、上記(1)の場合同様、送信側のノード（のグループ）と受信側のノード（のグループ）との組み合わせに対して一意であればよい。
(3)予め上記(1)あるいは(2)の方法で決めた、アドレスと番号との対応を示す対応情報を送信側のノード（のグループ）と受信側のノード（のグループ）とで共有しておく。送信側のノードが通信用のバッファに送信データを格納する際および、受信側のノードからＲＲＤＭＡ機能による受信を開始する際に、上記対応情報を参照すればよい。
(c）比較的大きなバッファ情報を送る必要がある場合には、バッファ情報自体を、送信データを送信する方法と同様の方法で送信する。

上記(b)の方法における「バッファアドレスの再符号化」（に用いられる対応情報、すなわち対応表の準備）は、同報通信の初期設定時、ないし、一連の同報通信を開始する前に実施しておく。ここで一般にメモリの対応表を引く時間は、ノード間の通信を複数回実行する時間より桁違いに短くなる場合が多い。又、ノード間の通信時間は、比較的短いデータに対してさえもデータ長に依存して長くなる場合が多い。このため、「「バッファアドレスの再符号化」用の対応表を作る際に行われる通信で第１実施例に係る通信方法を使用する」場合などの例外的な場合を除くと、(b)の方法の利用が有効と考えられる。

他方、多数のノードに対する同報通信を1対１通信の組み合わせのみで実施する場合、必要な通信回数が、少なくともノード数の対数の程度で増加する。更に、送信データが大きい場合には、データ長に比例する遅延が生ずる。したがって多数のノードに対する同報通信を1対１通信の組み合わせのみで実施する場合当該同報通信において、上記(a)の方法による通信回数の増加による遅延より桁違いに大きな遅延が発生する場合が多い。よって当該(a)の方法も有効な場合がある。

又、大規模なネットワークで、しかも大きなデータを同報通信で転送する場合であて、ネットワーク内の経路のバンド幅を有効に利用するために比較的大きなバッファ情報を送る場合、上記（ｃ）の方法が有効と言える場合がある。当該場合は、送信データの同報通信と同様な方法でバッファ情報を送信する場合の遅延の増加よりも、バンド幅の有効利用による通信時間短縮効果の方が大きい場合である。

以下に上記第１実施例に係る通信方法について詳細に説明する。

図３Ａ，図３Ｂは、第１実施例に係る通信方法の詳細な動作の流れを説明するフローチャートである。図３Ａ中、ステップＳ３１で送信側のノードは、送信データを通信用のバッファに格納する。ステップＳ３２で送信側のノードは上記送信データを格納した通信用のバッファの場所を示す情報（バッファ情報）を含むパケットを作成する。ステップＳ３３で送信側のノードは上記通信用のバッファの場所を示す情報（バッファ情報）を含むパケットを、データが短い場合の信頼性のある同報通信方法にて、複数の受信側のノードの各々に送信する。

図３Ｂ中、ステップＳ３４で複数の受信側のノードの各々は、上記ステップＳ３３で送信された、通信用のバッファの場所を示す情報（バッファ情報）を有するパケットを、上記データが短い場合の信頼性のある同報通信方法にて受信する。ステップＳ３５で複数の受信側のノードの各々は、上記通信用のバッファの場所を示す情報（バッファ情報）に基づき、上記送信データを上記通信用のバッファから、ＲＲＤＭＡ機能により取得する。

第１実施例に係る通信方法は、データが短い場合の信頼性のある同報通信方法および信頼性のある１対１通信方法を使用する。上記信頼性のある１対１通信方法は例えばＲＲＤＭＡ機能を使用する方法である。ＲＲＤＭＡ機能により、通信用のバッファから複数の受信側のノードの各々が自ノードに対し、送信データを直接転送する(図３ＢのステップＳ３５)ことができる。ここで、特に受信側のノードから通信を開始するＲＤＭＡ機能をＲＲＤＭＡ機能と称する。ＲＲＤＭＡ機能はＲＤＭＡ Ｒｅａｄ機能、あるいはＧｅｔ機能と称される場合もある。ＲＲＤＭＡ機能の利用により、並列計算に必要なさまざまの長さのデータの信頼性のある同報通信が実現できる。

ここでＲＤＭＡ機能とはリモートホストのメモリにＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を介さず直接値を書き込むアクセス機能である。ＲＤＭＡによればＣＰＵへの負荷が非常に小さく、かつ極めて小さい遅延で通信できることが期待できる。ＩｎｆｉｎｉＢａｎｄ、Ｖｉｒｔｕａｌ Ｉｎｔｅｒｆａｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＶＩＡ）、ｉＷａｒｐなどの通信規格においては、ＲＤＭＡ機能は標準的な機能として定義されている。なおｉＷａｒｐはＥｔｈｅｒｎｅｔ上のＴＣＰ／ＩＰコネクションを通してＲＤＭＡを行う機能（ＲＤＭＡ ｏｖｅｒ ＴＣＰ／ＩＰ）を含む。いずれの規格上でのＲＤＭＡの実現も（実装手段の細部は異なるが）基本機能の面では、特に違いはない。非特許文献６には上記ＲＤＭＡ ｏｖｅｒ ＴＣＰ／ＩＰとＲＤＭＡ ｏｖｅｒ ＩｎｆｉｎｉＢａｎｄの技術解説がなされている。非特許文献６の４ページの図２、９ページの図５においてＲＤＭＡにおけるデータの流れが示されている。

上記図３ＡのステップＳ３１で送信側のノードは、自ノードの通信装置内のバッファ（通信用のバッファ）に送信データを格納する。ここで送信データはＲＲＤＭＡ機能で転送可能でバッファ内に格納可能な長さの情報とされる。又、送信データを格納する通信用のバッファは自ノードの通信装置内のバッファに限らず、最初の段の通信中継装置内のバッファであってもよい。

その後送信側のノードは上記ステップＳ３２、Ｓ３４にて、データが短い場合の信頼性のある同報通信方法により、複数の受信側のノードの各々に対し、送信データを格納した通信用のバッファの場所を示す情報（バッファ情報）を通知する。あるいは送信データを格納した通信用のバッファの場所を示す情報を予め全ノードが共有しておき、送信データの通信用のバッファへの格納完了の旨を通知するようにしてもよい。又は送信データの通信用のバッファへの格納状況を通知するようにしてもよい。第１実施例において、上記複数の受信側のノードとは、送信側のノードが含まれるネットワークに含まれる他の全てのノードを意味する。又、上記他の全てのノードに代えて、最初の段の通信中継装置に対し、通信用のバッファに送信データを格納完了した旨、又は通信用のバッファに送信データを格納した状況を通知するようにしてもよい。次にステップＳ３５にて、他の全てのノードあるいは最初の段の通信中継装置は、ＲＲＤＭＡ機能により、通信用のバッファから送信データを取得する。通信用のバッファは静的に予め定められた位置のバッファ、あるいは動的に送信側のノードないし通信中継装置から通知される位置のバッファとすることができる。

上記ステップＳ３１の「送信データを通信用のバッファに格納する」動作は大別して次の２種類の方法で実現され得る。
(1)第１の方法は、送信データが格納されたメモリ上の領域を通信装置からアクセス可能な状態にする方法である。ここで、例えば送信側のノードのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が「ページング（メモリ領域の単位（ページ）を一時的に上記メモリ以外の記憶領域に退避する機能）」を有する場合がある。この場合、通信用のバッファとしてのメモリ内の記憶領域が通信中にメモリ上に存在し続けるようにする。すなわち通信用のバッファ用の記憶領域がページングの対象に選ばれないようにする。
(2)通信装置がアクセス可能な記憶領域（例えば、上記メモリ上で予めページング機能の対象外とされた記憶領域、送信側のノードが有する通信カード内のメモリ内の記憶領域等）に送信データをコピーする。

ここで通信用のバッファとして「ネットワーク上の記憶装置のアドレスと当該記憶装置上のアドレスとの対を指定することによって他の全てのノードから送信データをＲＲＤＭＡ機構により取得可能なネットワーク上の記憶装置」を使用する。例えば、以下の(1)乃至(3)のような場所の記憶装置を通信用のバッファとして使用する。又、当該(1)乃至(3)のような場所を複数併用してもよい。
(1)送信側のノード自体が持つメモリ、あるいは送信側のノードが有する通信カード上のメモリ。
(2)通信中継装置自体が持つメモリ、あるいは通信中継装置が有する通信カード上のメモリ。
(3)ネットワーク上の記憶装置（通信中継装置内のメモリ、あるいは通信中継装置に連動するメモリ）。

ここで通信用のバッファとしてのメモリの実装位置の違いによる影響は、下記の(a)乃至(d)の範囲に限定される。

(a)通信手順上で使用するＲＲＤＭＡ機能の実施に際しての「ネットワーク上の送信データの場所（ネットワーク上の記憶装置のアドレスと、当該記憶装置上のアドレスとの対）」の差
(b)ＲＲＤＭＡ機能を起動するために使用されるコマンド（ないしコマンド列）の差
(c)通信用のバッファの実装位置による通信遅延の差（例えば、ＮＩＣや通信中継装置等の通信装置上のメモリを使用する場合、送信側のノードのメモリ（主記憶）を使用する場合に比べ、送信データがネットワークに送出される際の遅延時間が、一般的には小さい）
(d)通信用のバッファの実装位置による容量の差（通信装置上のメモリの容量は、送信側のノードの主記憶の容量に比べ、一般的には小さい）
説明の便宜上、上記(1)乃至(3)のメモリを区別せずに単に通信用のバッファと称する。又、大規模なネットワークでは何段もの階層的な中継処理が必要であるが、以下の説明では便宜上、中継処理がある場合は「中継処理の１段分」のみを表記する。

図４Ａ，４Ｂ，４Ｃとともに、第１実施例の具体例１について説明する。

第１実施例の具体例１は、通信用のバッファが送信側のノードにある場合に、短いデータに対する信頼性のある同報通信方法とＲＲＤＭＡ機能との組み合わせにより、一般の長さの送信データに対して信頼性のある同報通信を提供する例である。

まず第１に、図４Ａに示す如く、送信側のノード１１が、送信データを通信用のバッファ１１ａに格納する。通信用のバッファ１１ａとして、送信側のノード１１の主記憶を使用する、送信側のノード１１が有する通信装置内部のメモリを使用する、あるいは送信側のノード１１の主記憶の一部に通信装置を接続して主記憶の一部を使用することができる。

第２に、図４Ｂに示す如く、通信用のバッファ１１ａに送信データがあることを、他のノード２１，２２，２３又は第一段の中継ノード２１，２２，２３に対し、データが短い場合の信頼性のある同報通信方法で通知する。

第３に、図４Ｃに示す如く、通信用のバッファ１１ａに格納された送信データを、受信側のノード（送信側のノード以外の全ノード又は最初の段の中継ノード）２１，２２，２３が自ノードに対し、ＲＲＤＭＡ機能によって転送する。ここでＲＲＤＭＡ機能を使用する方法は、受信側のノード２１，２２，２３の各々が起動する信頼性のある１対１通信方法である。

ここで送信側のノード１１と受信側のノード２１，２２，２３との間の中継段数が１より大きい場合、前段の中継ノードが送信の基点となって上記の図４Ｂ，図４Ｃの動作を中継段数分繰り返せばよい。

ここで上記第１実施例の具体例１において、送信側のノードの通信用のバッファのアドレスを、受信側のノードに予め送信しておくことができる。そして、図４Ｂの動作において、複数ノード間のバリア同期を、上記データが短い場合の信頼性のある同報通信方法として使用（あるいは流用）することができる。あるいはバッファ情報又は送信データの受信完了確認をバリア同期で実現することもできる。

ここでバリア同期とは、バリア同期に参加する各ノードが同期信号の基点となると共に、他のノードが基点となった同期信号全てを受信することによって同期が完了するという、ノード間の同期方法である。他のノードが基点となった信号の受信に際しては、基点となったノード以外のノードによる中継があっても良い。バリア同期では、同期信号という１種類の短いデータの同報通信を、同期に参加する各ノードが行う。バリア同期は並列計算システムではよく使用されるので、バリア同期の機能を備えた通信システムは、特に大規模な並列計算システムでは実現例が多い。このため、バリア同期をデータが短い場合の信頼性のある同報通信方法に適用するに当たっての追加費用は小さく済む場合が多いと考えられる。バリア同期については更に図１４，図１５とともに後述する。又、バリア同期の代わりに、図１６，１７，１８とともに後述するリダクション装置を使用する方法を使用しても良い。

次に図５Ａ，５Ｂ，５Ｃとともに、第１実施例の具体例２について説明する。

第１実施例の具体例２は通信中継装置上のメモリを通信用のバッファに使用する例である。大規模なネットワークで送信側のノードが有するメモリが通信用のバッファとして使用されると、ＲＲＤＭＡ機能の実施の際に、送信側のノードのメモリに対するアクセスが集中することが想定される。その場合、同報通信性能上の問題（ボトルネック）となる場合がある。上記の如く通信中継装置上のメモリを利用することにより、この問題が解決できる。なお送信側のノードに対し、多数のノードから同時にＲＲＤＭＡ機能実施の要求がなされた場合に起こりえる「衝突」を回避する方法について後述する。

第１実施例の具体例２では第１に、図５Ａに示す如く、送信側のノード１１が、送信データを通信中継装置Ｓ１，Ｓ２のメモリＳ１ａ、Ｓ２ａにそれぞれ格納する。最初の中継の際に通信中継装置を１つしか使用しない場合は１対１通信でよい。最初の中継の時点でも通信中継装置を複数使用する場合、１対１通信を反復するか、あるいは上記第１実施例の具体例１の方法で同報通信を行えばよい。なお、通信中継装置内（あるいは通信中継装置と連動して動作する）メモリを通信用のバッファとして使用することの利点は以下の通りである。すなわち後述する図５Ｃの動作において、各受信側のノードへの通信経路の途中にある通信中継装置内のバッファに送信データを格納することで、送信側のノードよりもネットワーク上で近い場所から送信データを取得し得る。

第２に図５Ｂに示す如く、通信中継装置Ｓ１，Ｓ２内のバッファＳ１ａ，Ｓ２ａに送信データがあることを、受信側のノード（他のノード又は中継ノード）２１，２２，２３，２４に対して、データが短い場合の信頼性のある同報通信方法で通知する。

第３に図５Ｃに示す如く、バッファＳ１ａ，Ｓ２ａに格納された送信データを受信側のノード（送信側のノード１１以外のノード又は最初の段の中継ノード）２１，２２，２３，２４が夫々、ＲＲＤＭＡ機能を使用して取得する。ＲＲＤＭＡ機能を使用する方法は、受信側のノード２１，２２，２３，２４の各々が起動する信頼性のある１対１通信方法である。

次に図６Ａ，６Ｂ，６Ｃとともに、第１実施例の具体例３について説明する。

具体例３は、通信用のバッファ用の中継ノードが存在する場合の例である。大規模なネットワークで送信側のノードが有するメモリが通信用のバッファとして使用されると、ＲＲＤＭＡ機能の実施の際に、送信側のノードのメモリに対するアクセスが集中することが想定される。その場合、同報通信性能上の問題（ボトルネック）となる場合がある。上記の如く中継ノードのメモリを利用することにより、この問題が解決できる。なお送信側のノードに対し、多数のノードから同時にＲＲＤＭＡ機能実施の要求がなされた場合に起こりえる「衝突」を回避する方法について後述する。

第１実施例の具体例３では第１に、図６Ａに示される如く、送信側のノード１１が、送信データを通信用のバッファ用の中継ノードＮ１，Ｎ２上の夫々のメモリＮ１ａ、Ｎ２ａに格納する。最初の中継の際に通信用のバッファ用の中継ノードを１つしか使用しない場合は１対１通信でよい。最初の中継の時点でも通信用のバッファ用の中継ノードを複数使用する場合、１対１通信を反復するか、あるいは上記実施例１の具体例１の方法で同報通信を行えばよい。

通信用のバッファ用の中継ノードＮ１，Ｎ２は、ネットワーク内の位置および中継ノードのメモリ量やネットワークとのインターフェース数などを考慮し、送信データの転送効率や負荷分散が最適となるように選択する。なお、上記第１実施例の具体例２の如くに通信中継装置内部のメモリを使用する場合とは異なり、送信側のノード１１から受信側のノード２１への１対１通信の経路上に通信用のバッファ用の中継ノードＮ１，Ｎ２がある必要はない。

第２に図６Ｂに示される如く、通信用のバッファ用の中継ノードＮ１，Ｎ２内のメモリＮ１ａ，Ｎ２ａに送信データがあることを、受信側のノード（他のノード又は中継ノード）２１，２２，２３、２４に対し、データが短い場合の信頼性のある同報通信方法で通知する。

第３に図６Ｃに示される如く、通信用のバッファ用の中継ノードＮ１，Ｎ２内のメモリＮ１ａ，Ｎ２ａに格納された送信データを、受信側のノード（送信側のノード以外のノード又は最初の段の中継ノード）２１，２２，２３、２４がそれぞれＲＲＤＭＡ機能によって自ノードに転送する。ＲＲＤＭＡ機能を使用する方法は受信側の通信ノードが起動する信頼性のある１対１通信方法である。

ここで送信データについて中継処理の段数が１より大きい場合、前段の中継ノードが送信の基点となり、図６Ａ，６Ｂ，６Ｃの動作を中継段数分繰り返せばよい。

次に図７Ａ，７Ｂ，７Ｃとともに第１実施例の具体例４について説明する。

第１実施例の具体例４は図７Ａに示す如く、送信側のノード１１が複数の通信用のバッファ１１ａ，１１ｂを使う例である。第１実施例の具体例４は、例えば以下の（ａ）、（ｂ）の場合に適用される。

(a)ひとまとまりの送信データが複数の通信用のバッファにまたがって存在する場合
この場合、一つのバッファにまとめるコピー操作を省略することができる。

(b)通信効率の向上のため、ひとまとまりのデータを分割して送信する場合
この場合、(1)各中継ノードが扱うデータを小さくして中継時の遅延時間を短縮することができる。あるいは(2)通信帯域に余裕がある伝送路を使用し、又は通信帯域が独立した複数の通信路を並行に使用し、複数の通信を並行して行うことができる。

上記（ａ）のひとまとまりのデータが複数の通信用のバッファに存在する場合、バッファ情報は、一般には、各通信用のバッファのアドレスと長さである（図２４とともに後述）。ただし、連続データを分割して送信する場合、又は複数のバッファ間のオフセットが固定の場合、バッファ情報は先頭のバッファのアドレス、データ長、バッファ数でよい。

第１実施例の具体例４では、第１に図７Ａに示される如く、関与するノード全てに、バッファ情報をデータが短い場合の信頼性のある同報通信方法で送る。

第２に図７Ｂに示される如く、通信中継装置又は中継ノードＮ１，Ｎ２の各々は、通信用のバッファ１１ａ，１１ｂから、夫々送信データの一部をＲＲＤＭＡ機能によって自ノードに転送する。

第３に図７Ｃに示される如く、受信側の通信ノード２１が、通信中継装置又は中継ノードＮ１，Ｎ２のそれぞれのメモリＮ１ａ，Ｎ２ａから、送信データのそれぞれの部分をＲＲＤＭＡ機能により自ノードのメモリ２１ａ，２１ｂに夫々転送する。その後受信側の通信ノード２１は、転送した送信データのそれぞれの部分をまとめてひとまとまりの送信データを得る。

次に第２実施例の詳細について説明する。

第２実施例に係る通信方法は、データが短い場合の信頼性のある同報通信方法および、データが長い場合の必ずしも信頼性のない同報通信方法を使用する通信方法である。第２実施例に係る通信方法は、上述の第１実施例に係る通信方法同様、当該通信方法を使用し、並列計算で必要なさまざまの長さのデータに対して、信頼性のある同報通信を実現する。

第２実施例に係る通信方法では図８Ａに示される如く、ステップＳ４１で、送信側のノードは、送信データの伝送エラー検出およびリカバリ用の情報としてリカバリ制御情報を作成する。リカバリ制御情報は、送信データの大きさ、エラー検出コード、そして場合によってはタイムアウト時間その他の情報を含む（図２５とともに後述）。送信側のノードはステップＳ４２で、リカバリ制御情報を、データが短い場合の信頼性のある同報通信方法により、複数の受信側のノードの各々に送信する。ステップＳ４３で送信側のノードは送信データを、データが長い場合の必ずしも信頼性のない同報通信方法によって送信する。ステップＳ４４で送信側のノードは、送信データのリカバリが必要か否かを判定する。例えば受信側のノードから送信データに対する再送依頼があった場合には送信データのリカバリが必要と判断し、送信データに対する再送依頼がなかった場合には送信データのリカバリが必要でないと判断する。送信側のノードは、送信データのリカバリが必要と判断した場合にはステップＳ４５にて送信データのリカバリを行う。送信データのリカバリが必要でないと判断した場合には、動作を終了する。

又、図８Ｂに示される如く、ステップＳ４６で、複数の受信側のノードの各々は、ステップＳ４２で送信されたリカバリ制御情報を、上記データが短い場合の信頼性のある同報通信方法で受信する。ステップＳ４７で、複数の受信側のノードの各々は、ステップＳ４３で送信された送信データを、上記データが長い場合の必ずしも信頼性のない同報通信方法で受信する。ステップＳ４８で複数の受信側のノードの各々は、受信されたリカバリ制御情報に含まれる送信データの完全性のチェックに必要な情報を使用し、受信された送信データの完全性のチェックを行う。受信された送信データの完全性のチェックの結果、受信された送信データが完全でなく、送信データのリカバリが必要であると判断した場合（ステップＳ４８のＹＥＳ），該当する受信側のノードはステップＳ４９にて、受信されたリカバリ制御情報に含まれるリカバリに必要な情報を使用し、送信データのリカバリを行う。受信された送信データの完全性のチェックの結果、受信された送信データが完全であり、送信データのリカバリが必要でないと判断した場合（ステップＳ４８のＮＯ），動作を終了する。

すなわち上記ステップＳ４８にて各受信側のノードは、データが長い場合の必ずしも信頼性のない同報通信方法で受信した送信データの伝送エラーを検出し、必要な回復処理（リカバリ）を行う。データが長い場合の必ずしも信頼性のない同報通信方法で受信した送信データの伝送エラーの検出は、データが短い場合の信頼性のある同報通信方法によって受信したリカバリ制御情報に含まれる送信データの完全性のチェックに必要な情報を利用して行う。

送信データのリカバリの方法を大別すると、下記に挙げる３種の方法（ａ），（ｂ），（ｃ）がある。このうち方法（ｃ）は、上記第１実施例に係る通信方法を利用する方法である。

(a)再送による方法
(1)受信側のノードが送信データのパケット異常を検出して送信側のノードに送信データの再送を要求する。

(2)送信側のノードが、受信側のノードからの受信確認応答のタイムアウトを検出した場合、送信データを再送する。

(b)送信データに冗長性を持たせる方法
ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ：前方誤り訂正)として知られる技術を利用することができる。すなわち送信データを複数のパケットに分けて送信する場合、誤り訂正符号化処理により例えばＮ＋１パケットを送信し、そのうちNパケットを正しく受信できれば元のデータが復元できるように送信データを変換して送信する。

(c)ＲＲＤＭＡ機能を併用する方法（使用する通信方式に既にＲＲＤＭＡ機能が含まれる場合）
送信側のノードのバッファ情報（上記第１実施例に係る通信方法参照）を、送信データの伝送エラー検出および回復用の情報（送信データの完全性のチェックおよびリカバリに必要な情報）としてのリカバリ制御情報の一部に含めておく。そして送信データのリカバリが必要な場合、バッファ情報を使用し、受信側ノードは第１実施例に係る通信方法を使用してＲＲＤＭＡ機能によって送信データを取得しなおす。

図９Ａ，９Ｂは、第２実施例に係る通信方法を説明する動作フローチャートである。但し図９Ａ，９Ｂの方法は上述した図８Ａ，８Ｂの方法に対し、送信データのリカバリに上記（ｃ）の方法を使用する例である。

図９ＡのステップＳ６１で、送信側のノードは送信データを通信用のバッファに格納する。通信用のバッファについては第１実施例に係る通信方法における通信用のバッファと同様の方法にて設けることができる。図８ＡのステップＳ４１同様、ステップＳ６２にて送信側のノードは、送信データの伝送エラー検出およびリカバリ用の情報としてリカバリ制御情報を作成する。但しリカバリ制御情報には、第１実施例に係る通信方法で使用する如くのバッファ情報が含まれる。図８ＡのステップＳ４２同様、送信側のノードはステップＳ６３で、リカバリ制御情報を、データが短い場合の信頼性のある同報通信方法により、複数の受信側のノードの各々に送信する。図８ＡのステップＳ４３同様、送信側のノードはステップＳ６４で、送信データを、データが長い場合の必ずしも信頼性のない同報通信方法によって送信する。ステップＳ６５で送信側のノードは、後述するステップＳ７０で複数の受信側のノードの各々から前記通信用のバッファが不要との通知を受けたとき、当該通信用のバッファを解放し、動作を終了する。

又、図９Ｂに示される如く、図８ＢのステップＳ４６同様、複数の受信側のノードの各々はステップＳ６６で、ステップＳ６３で送信されたリカバリ制御情報を、上記データが短い場合の信頼性のある同報通信方法で受信する。図８ＢのステップＳ４７同様、複数の受信側のノードの各々はステップＳ６７で、ステップＳ６４で送信された送信データを、上記データが長い場合の必ずしも信頼性のない同報通信方法で受信する。図８ＢのステップＳ４８同様、複数の受信側のノードの各々はステップＳ６８で、受信されたリカバリ制御情報に含まれる送信データの完全性のチェックに必要な情報を使用し、受信された送信データの完全性のチェックを行う。受信された送信データの完全性のチェックの結果、受信された送信データが完全でなく、送信データのリカバリが必要であると判断した場合（ステップ６８のＹＥＳ），該当する受信側のノードはステップＳ６９にて、第１実施例に係る通信方法を利用し、ＲＲＤＭＡ機能により送信側のノードの通信用のバッファから送信データを取得する。ＲＲＤＭＡ機能の実施には、受信されたリカバリ制御情報に含まれるバッファ情報を使用する。ステップＳ７０にて当該受信側のノードは、送信データのリカバリ完了後、送信側のノードに対し、通信用のバッファが不要になった旨を通知し、動作を終了する。又、送信データのリカバリが必要でないと判断した場合（ステップ６８のＹＥＳ）も動作を終了する。

第２実施例に係る通信方法ではエラーの検出や回復処理（送信データのリカバリ）における負荷を分散するため、大規模なネットワークでは、本来送信側のノードが行う下記の(1),(2)の処理に関する役割を、複数のノード間で分担するようにすることができる。さらに、非常に大規模なネットワークにおいては、これらの処理の分担においても、送信側のノードを基点とし受信側のノードを終点とする階層関係によって、順次段階的に処理するようにすることができる。

(1) 再送要求の受付
(2) ＲＲＤＭＡ機能によるエラー回復処理（送信データのリカバリ）のため通信用のバッファの保持
これらの回復処理（送信データのリカバリ）で「どのノードがどの範囲のノードのエラーにつき送信データのリカバリを担当するか」についての役割分担や階層関係は、ノード間の（ネットワーク上の）位置関係や通信効率を考慮して定める。例えば１対１通信の反復のみで同報通信を実現する場合の階層関係を使用することもできる。ただし、１対１通信の反復で同報通信を行う場合と異なり、「アルゴリズム上決まっている受信順序において、前のノードが後のノードに関する送信データのリカバリをサポートするしかない」という制約は特にない。ここで、ほぼ同じ頃に、どのノードもハードウェアレベルの同報通信により送信データを受信する。したがって上記制約がないことで、送信データを正常に受け取れなかったノードが（送信データのリカバリのために）あらためて送信データを受け取る際の、送信データ提供元ノードの選び方の自由度は高い。

データが長い場合の必ずしも信頼性のない同報通信でエラーが検出された場合の送信データのリカバリにおける送信データの再送方法は次の２種類（１）、（２）に大別される。大規模なネットワークでの実現の際は、それぞれ課題がある。

(1)１対１通信による再送
エラーを検出したノードに対して送信データを再送する方法である。送信データの再送に要される通信帯域は小さい。しかしながら、送信データを再送するノードに対しての再送依頼、あるいは送信データの再送が不要である旨の通知に要される負荷が、再送元に集中する問題への対応が必要となる。送信側のノードの負荷の解消は一般に再送元に階層関係を作ることで行うが、その場合、再送時の遅延が大きくなりやすい。なお、使用している通信方式が信頼性のある１対１通信方法を有する場合には、信頼性のある１対１通信方法で再送する方が効率的である。ここで、再送時にエラーが再現する確率は（必要なら何回か再送を反復することで）実用上問題ない程度まで小さくできる。このため、通信方式自体が信頼性を保障していない場合も、送信データの再送を含む通信プロトコルにより、当該通信方式によって信頼性を確保することは可能である。通信方式自体による信頼性の保障も、実際は通信方式の内部処理としてエラー検出と再送が制御されているために、「その通信方式を利用する際に信頼性の確保について特別な考慮をする必要がない」場合も多い。

(2)同報通信による再送
あるノードでエラーが検出された場合、同報通信を再度行う方法である。タイムアウト制御を併用することで再送元での処理負荷の上昇を抑えることはできるが、送信データの再送がネットワーク全体の通信帯域を大きく使ってしまうことへの対応が必要である。

データが長い場合の必ずしも信頼性がない通信方法で起こりえる通信エラーには、次の２種類（ａ），（ｂ）がある。

(a)パケット全体が届かない
(b)届いたパケットの内容が正しくない
第２実施例に係る通信方法では、データが短い場合の信頼性のある同報通信方法によってリカバリ制御情報を送信する。その結果、(a)の場合に対し、該当する受信側のノードが通信エラーを検出することができ、さらに、(b)の場合も含めて送信データのリカバリの効率を高めることができる。

以下の説明では、上述の第１実施例に係る通信方法の説明と同様、「通信用のバッファ」の実装位置の違いによる差異には、特に言及しない。又、大規模なネットワークでの送信データのリカバリにおいては、何段もの階層的な中継処理が必要となる場合があるが、以下の説明では、図を見やすくするため、中継処理がある場合は「中継処理の１段分」のみを表記する。

以下に第２実施例に係る通信方法の具体例について図とともに説明する。

図１０Ａ，１０Ｂ，１０Ｃとともに、第２実施例の具体例１について説明する。

第２実施例の具体例１は、１対１通信による送信データのリカバリで信頼性を確保する場合の基本的な例である。

第１に、図１０Ａに示される如く、送信側のノード１１はリカバリ制御情報を、データが短い場合の信頼性のある同報通信方法により、受信側のノード２１，２２，２３に送信する。リカバリ制御情報は、送信データの伝送エラー検出（完全性のチェック）および回復（リカバリ）用の情報であり、送信データの大きさ、エラー検出コード、そして場合によってはタイムアウト時間その他の情報を含む（以下同様）。

第２に図１０Ｂに示される如く、送信側のノード１１は本来の同報通信データ（送信データ）を、データが長い場合の必ずしも信頼性のない同報通信方法によって受信側のノード２１，２２，２３に送信する。受信側のノード２１，２２，２３は、上記リカバリ制御情報に基づき、まず送信データのエラー検出を行う。エラー検出の結果特にエラーが発生していなければ、動作を終了する。

他方、エラー検出の結果エラーが発生していた場合、図１０Ｃに示される如く、該当する受信側のノード２３は、データが短い場合の信頼性のある同報通信方法によって得られた上記リカバリ制御情報を利用して送信データのリカバリを行う。

図１１Ａ，１１Ｂ，１１Ｃとともに、第２実施例の具体例２について説明する。第２実施例の具体例２は、１対１通信でのリカバリの際に送信側のノードの負荷を分散する例である。

第１に図１１Ａに示される如く、送信側のノード１１は、上記同様のリカバリ制御情報を、データが短い場合の信頼性のある同報通信方法で受信側のノード２１，２２，２３，２４に送信する。

第２に図１１Ｂに示される如く、送信側のノード１１は本来の同報通信データ（送信データ）を、データが長い場合の必ずしも信頼性のない同報通信方法によって送信する。受信側のノード２１，２２，２３，２４の各々は、上記リカバリ制御情報に含まれる伝送エラー検出用の情報を使用し、まず受信された送信データのエラー検出を行う。エラー検出の結果特にエラーが発生していなければ、動作を終了する。

ここで例えば受信側のノード２２でエラーが検出された場合、当該ノード２２は受信したリカバリ制御情報に含まれる回復用の情報に基づき、送信データのリカバリを行う。但し当該第２実施例の具体例２では上記第２実施例の具体例１と異なり、図１１Ｃに示される如く、当該ノード２２は、他の受信側のノード２１との間で受信された送信データのリカバリを行う。この場合、ノード２１は「リカバリ分散ノード」として機能する。すなわち上記第２実施例の具体例１ではノード２２は送信側のノード１１との間で送信データのリカバリを行うが、当該実施例２の具体例２では、受信側のノード２１との間で受信された送信データのリカバリを行う。その結果送信データのリカバリの際の送信側のノード１１の負荷がノード２１に分散される。尚この場合、更に上記送信データのリカバリの負荷の分散に係るノード２１においても受信された送信データにエラーが検出された場合、まず当該ノード２１が送信側のノード１１との間で送信データのリカバリを行い、その後、ノード２２がノード２１との間で送信データのリカバリを行えばよい。

次に図１２Ａ，１２Ｂ，１２Ｃとともに、第２実施例の具体例３について説明する。第２実施例の具体例３は、送信データのリカバリの際に送信側のノードの負荷を分散し、必要に応じて同報通信による再送を行う例である。

第１に図１２Ａに示される如く、送信側のノード１１は、送信データの伝送エラー検出および回復用情報（リカバリ制御情報）を、データが短い場合の信頼性のある同報通信方法で受信側のノード２１，２２，２３，２４に送信する。リカバリ制御情報は上記同様、送信データの大きさ、エラー検出コード、そして場合によってはタイムアウト時間その他の情報を含む。

第２に図１２Ｂに示される如く、送信側のノード１１は本来の同報通信データ（送信データ）を、データが長い場合の必ずしも信頼性のない同報通信方法によって受信側のノード２１，２２，２３、２４に送信する。受信側のノード２１，２２，２３，２４の各々は、リカバリ制御情報に含まれるエラー検出用の情報を使用し、まず受信された送信データのエラー検出を行う。送信データに特にエラーが発生していなければ、動作を終了する。

送信データにエラーが発生していた場合、該当する受信側のノードは、受信されたリカバリ制御情報に含まれる回復用の情報を利用し、送信データのリカバリを行う。なお第２実施例の具体例３の場合も第２実施例の具体例２同様、送信データのリカバリは図１１Ｃの如くに階層関係に従って順次行われる。しかしながら第２実施例の具体例３の場合、上記階層関係の下位の方から（所定の閾値を超える）複数の再送依頼（図１２Ｃ中、破線矢印）がなされた場合には、（当該下位の階層以下に対しての）同報通信による再送を行う（実線矢印）。その結果、図１１Ｃの場合に生じ得る、中継による通信遅延を短縮することができる。なお、通信経路が多重化されている場合には、ある階層から先の（下位の）通信経路に異常がある可能性を考慮して、別の通信経路を使用するようにしてもよい。例えば図１２Ｃの例の場合、ノード２３は本来の階層関係によればノード１１に対して再送依頼するが、ノート１１への通信経路が多重化されている場合には、ノード２４を介してノード１１へ再送依頼するという別の通信経路を使用する。

図１３は、上記第１実施例および第２実施例の各々において使用される送信側のノード、受信側のノード、中継ノードの各々のノードのハードウェア構成例について説明する図である。各ノード１１０は、バス１１３を介して相互に接続されるＣＰＵ１１１とメモリ１１２とを含む。ＣＰＵ１１１は各種演算を行う。メモリ１１２には、ＣＰＵ１１１が実行するプログラムの他、各種データが格納される。上記第１実施例あるいは第２実施例に係る通信方法で使用される通信用のバッファとしても使用され得る。又、メモリ１１２には、上記第１および第２実施例の各々に係る通信方法を実現するプログラムも格納される。ＣＰＵ１１１は同プログラムを実行することにより、図１Ａ乃至１２Ｃとともに述べた動作、あるいは後述する図１４乃至図２５Ａとともに述べる動作を実行することができる。又、ノード１１０は、ネットワーク上の他のノードと通信する際に使用する通信カード（通信装置）１２０を有する。通信カード１２０は例えばＮＩＣとすることができる。

図１４は、上記データが短い場合の信頼性のある同報通信方法（特にバリア同期を使用する場合）の動作の流れを説明するフローチャートである。図１４中、ステップＳ１０１で、送信側のノードが、所定の格納場所にバッファ情報を格納する。次にステップＳ１０２で、送信側のノードと複数の受信側のノードとを含む全ノードがバリア同期（図１５とともに後述する）を行う。次にステップＳ１０３にて、複数の受信側の通信ノードの各々が、上記所定の格納場所から、上記バッファ情報をＲＲＤＭＡ機能により自ノードに転送する。その結果、複数の受信側の通信ノードの各々はバッファ情報を得ることができる。

上述の図１４の方法では、ステップＳ１０２のバリア同期において、上記全ノードが相互に同期をとる。そしてこのように同期がとれた後、ステップＳ１０３にて、各受信側のノードは所定の格納場所からバッファ情報を得る。すなわちデータが短い場合の信頼性のある同報通信方法が実現される。尚予めステップＳ１０１にて、送信側のノードは上記所定の格納場所にバッファ情報を格納する。又、上記所定の格納場所の情報は、上記全ノードで予め共有されており、送信側のノードはバッファ情報を、一定の格納タイミングで上記所定の格納場所に格納し、その後、一定の解放タイミングで上記所定の格納場所を解放する。バリア同期は、上記一定の格納タイミングから一定の解放タイミングまでの間の期間、すなわち上記所定の格納場所にバッファ情報が存在する期間を受信側のノードに通知する手段として使用される。なお、ステップＳ１０３の後に再度バリア同期を行うことにより、送信側のノードが上記一定の解放タイミングを得るようにしても良い。

図１５は、図１４のステップＳ１０２のバリア同期の動作の流れを示すフローチャートである。図１５中、ステップＳ１１１で上記全ノードの各々は、他の全ノードに対し、「バリア同期」信号を送信する。「バリア同期」信号は、単にタイミングを通知するためのみに必要な最短の信号であればよい。ステップＳ１１２で各ノードは他の全ノードから「バリア同期」信号を受信すると（ＹＥＳ）、動作を終了する。

なおバリア同期に関し、非特許文献８の第１３頁に「プログラムの書き方」という観点による図が示されている。更に非特許文献９の第９乃至１５頁にバリア同期の概念が説明されている。特に非特許文献８には以下の点が記載されている。全てのスレッド（ｔｈｒｅａｄ：並列処理での個々の処理の流れ）が、ある処理ブロックを抜ける（言い換えれば、次の処理へと進む直前の点まで到達する）まで、どのスレッドも次の処理ブロックへ進まない。

図１６は、上記データが短い場合の信頼性のある同報通信方法（特にリダクション装置を使用する場合）の動作の流れを説明するフローチャートである。図１６中、ステップＳ１２０で、送信側のノードおよび複数の受信側のノードを含む全ノードが、リダクション装置を使用して、ステップＳ１２１，Ｓ１２２，Ｓ１２３，Ｓ１２４の動作を行う。リダクション装置については図１８とともに後述する。

ステップＳ１２１で送信側のノードはバッファ情報をリダクション装置に送信する。ステップＳ１２２で複数の受信側の通信ノードの各々は、"０"の情報をリダクション装置に送信する。ステップＳ１２３でリダクション装置は、ステップＳ１２１で送信されたバッファ情報と、ステップＳ１２２で送信された"０"情報との和演算を行う。すなわち、バッファ情報と、各受信側のノードからの"０"情報との総和をとる。総和の結果、「バッファ情報」＋"０"＋"０"＋"０"＋...＝「バッファ情報」となり、演算結果「バッファ情報」が得られる。リダクション装置は演算結果「バッファ情報」を、全ノードに送信する。その結果ステップＳ１２４で、複数の受信側の通信ノードの各々は、「バッファ情報」を得ることができる。すなわちデータが短い場合の信頼性のある同報通信方法が実現される。

図１７は、図１６のステップＳ１２０の、リダクション装置を使用した、データが短い場合の信頼性のある同報通信方法の動作の流れを、図１６とは別の観点から説明するフローチャートである。図１７中、ステップＳ１３１（図１６中、ステップＳ１２１，Ｓ１２２に対応）で、各ノードがリダクション装置に情報を送信する。ステップＳ１３２（ステップＳ１２３に対応）で、リダクション装置が、各ノードが送信した上記情報を受信する。ステップＳ１３３（ステップＳ１２３）に対応）で、リダクション装置が上記受信した情報に基づいて演算（例えば上記総和演算）を行う。ステップＳ１３４（ステップＳ１２３に対応）で、リダクション装置が、上記演算の結果を各ノードに送信する。ステップＳ１３５（ステップＳ１２４に対応）で、各ノードが演算の結果を受信する。

図１８は上記リダクション装置について説明するブロック図である。リダクション装置Ｃ１はネットワーク上で、各通信ノード１１，２１，２２，２３と、通信中継装置Ｓ１を介し、相互に接続されている。リダクション装置Ｃ１は、例えば図１３とともに上述した各ノードと同様のハードウェア構成を有する。リダクション装置Ｃ１は上記の如く、全ノード１１，２１，２２，２３から情報を受信し、受信した情報に対し所定の演算（例えば上記の如く、総和演算）を行い、演算結果を全ノードに送信する。

リダクション装置につき、非特許文献１０，１１，１２に説明がなされている。尚非特許文献１０，１１において、「コレクティブ通信」という用語が使われている場合、実際には「リダクション」のことだけを指している場合が多い。ただし、「リダクション」用の関数である「ＭＰＩ＿Ａｌｌｒｅｄｕｃｅ」の動作は計算過程において「バリア同期」の動作を含む（値を計算するため結果的に同期処理をしている）ため、「リダクション」および「バリア同期」」を指している場合もある。非特許文献１２では、リダクション装置が並列計算の高速化に果たす役割の説明がなされている。尚用語「高機能スイッチ」は、ＭＰＩの集団通信用の函数である「ＭＰＩ＿Ａｌｌｒｅｄｕｃｅ」の動作をハードウェアで実現している。「ＭＰＩ＿Ａｌｌｒｅｄｕｃｅ」では、全てのノードが持っている入力データから計算した値、例えば総和を関数の出力として得ることができる。このため、例えば「数値と見なせる大きさのデータ」に対して、データを発信するノード以外が全て"0"を指定してＭＰＩ＿Ａｌｌｒｅｄｕｃｅを呼び出すことにより、そのデータの同報通信が実現される。

次に、上記ＲＲＤＭＡ機能の実施時に、多数のノードから同時にＲＲＤＭＡ機能実施の要求がなされた場合に起こりえる「衝突」を回避する方法についての説明を行う。

この「衝突」を回避する方法について、まず概略的な説明を行う。

(1)問題点を明確にするため、以下で考察する「衝突」とは「複数のノードから「同時」に１ノードのデータにＲＲＤＭＡ機能でアクセスすることが、結果的には、同報通信性能の向上につながらない事態」と定義する。

あるノードのデータを複数のノードからＲＲＤＭＡ機能でアクセスすること自体は、使用している通信方式が３個以上のノードを含むネットワークをサポートしている限り当然可能である。一般に、あるハードウェアへの「同時」アクセスは、ハードウェア内のａｒｂｉｔｒａｔｉｏｎ（調停）と呼ばれる機能や 関連するソフトウェアによる排他制御によって「時分割」的に処理される。

従って、問題点として「期待した性能向上効果が得られない」場合が考えられる。そのような性能上の問題点は、一般に「通信方式の構成要素に対する負荷が、当初想定した数あるいは量を越える」ことが原因と解される。

(2)上記(1)の最後に述べた「通信方式の構成要素に対する負荷が当初想定した数あるいは量を越える」ことが原因である問題点への対応方法は、大別して次の２通り（通信方式の構成要素に対する負荷を、想定した範囲に押さえる、という原則は共通）考えられる。

第１の対応方法は、想定される負荷に見合う資源を用意しておく方法である。例えば、ＮＩＣへの負荷 が大きいと想定される場合、能力の高いＮＩＣを用意するか、あるいはＮＩＣを複数用意する方法である。

第２の対応方法は、用意できる通信資源の量に合わせて負荷を調整する方法である。例えば、ＮＩＣへの負荷が大きいと想定される場合、一度にＮＩＣに課される転送要求の数や大きさを制限する。例えば、「ある特定の大きさのデータの転送要求について、用意されたＮＩＣの能力が、同時に処理して大幅な性能低下を招かない要求数は６以下」である場合を想定する。この場合、転送を階層化することにより、１階層では６以下しか同時に転送しないようにすればよい。この場合は、例えば、１階層あたりでデータが短い場合の信頼性のある同報通信方法での通知先を６以下に制限すればよい。

以上述べてきたように、「衝突」回避の方法は、次の（ａ），（ｂ）の方法に帰着する。

(a)各ノード上の通信資源への負荷を適正に見積もり、負荷に見合った資源を用意しておく方法
(b)用意できた資源を有効に使えるように、各資源への負荷の分配を適切に調整する方法
上記第１実施例、第２実施例の各々における、データが短い場合の信頼性のある同報通信方法とＲＲＤＭＡ機能を使用した１対１の通信方法との組み合わせによる通信方法において、例えば以下の方法を実行する。すなわち、データが短い場合の信頼性のある同報通信方法によってバッファ情報あるいはリカバリ制御情報を送信する際に、「負荷の分散に関する情報」を併せて送信する。その結果、上記（ｂ）の方法を効果的に行うことができる。又、上記(a)の方法については、上記第１実施例、第２実施例の各々の適用を前提にシステム資源を格納しておけば、各実施例による性能向上効果がより大きくなると期待される。

以下に上記ＲＲＤＭＡ機能の実施時に、多数のノードから同時にＲＲＤＭＡ機能実施の要求がなされた場合に起こりえる「衝突」を回避する方法につき、より具体的に説明する。

受信側のノードからＲＲＤＭＡ機能を利用することにより、「送信側のノードの ＣＰＵ負荷が送信先の数に比例する」という問題は、回避することができる。しかし、送信側のノードのＣＰＵ以外の資源（メモリ、ＮＩＣ、ＩＯバスなど）の負荷も送信先の数に比例して増大する。したがって送信先の数が大きい場合、多数の送信先からのＲＲＤＭＡ機能に係る同時アクセス、ないしアクセスタイミングの重なり（衝突）により、ＣＰＵ以外の資源への負荷がシステムのボトルネックになる問題を避ける必要もある。これらの資源アクセスの衝突を回避する方法として、大略、以下の(a),(b)の方法が考えられる。

(a)負荷が大きいシステム資源については、ノードあたりの数を増やした上で平行動作させる。具体的には以下の（１）、（２）、（３）の方法が考えられる。

(1)ＮＩＣの負荷がボトルネックになる場合、ＮＩＣを１システムに複数装備し、これらを平行動作させる（図１９，図２０とともに後述）。

(2)メモリバスあるいはＩＯバスへのアクセスがボトルネックになる場合、これらのバスの数、あるいは１つのバスが同時に処理できる数を増やす（図１９，図２０とともに後述）。

(3)ネットワーク全体の転送能力がボトルネックになる場合には、複数のネットワークを使用する。この方法は、別の種類のネットワークの併用を含む（図２１とともに後述）。

具体的には例えば図１９に示す如く、ノード当たりのＮＩＣ等の通信カードの数を増加させる。図１９は、ノード１１，２１，２２，２３の各々が、２個の通信カード１１ｃ１，１１ｃ２，２１ｃ１，２１ｃ２，２２ｃ１，２２ｃ２，２３ｃ１，２３ｃ２を有する。その結果、ＩＯバスを分けることが可能になり、負荷分散が果たせる。

ここで複数の通信カードを有するノードがシステムに充分な割合で含まれる場合、階層化された通信の各段での中継に際し、複数の通信カードを有するノードを中継サーバとして利用することが考えられる。この場合、複数の受信側のノードが複数の通信カードを有することでネットワーク能力が高い中継サーバから間接的に送信データを受信することで負荷分散（衝突の回避）が図れる。図２０は、通信カードＮ１ｃ１，Ｎ１ｃ２，Ｎ１ｃ３を複数（この例では３個）有するノードＮ１が中継サーバとして動作する例を示す。図２０中、受信側のノード２４は自ノードの通信カード２４ｃを介し、通信カード１１ｃを有する送信側のノード１１から直接送信データを受信する。他方、夫々が通信カード２１ｃ、２２ｃ、２３ｃを有する受信側のノード２１，２２，２３の各々は、通信カードＮ１ｃ１，Ｎ１ｃ２，Ｎ１ｃ３を有する中継サーバとしてのノードＮ１を介し、間接的に送信側のノード１１から送信データを受信する。その結果、複数の受信側のノード２１，２２，２３，２４が送信データを受信する際の転送元の負荷が、計４個の通信カード、すなわち送信側のノードの通信カード１１ｃ、中継サーバとしてのノードＮ１の通信カードＮ１ｃ１，Ｎ１ｃ２，Ｎ１ｃ３、に分散される。又、中継サーバとしてのノードＮ１は、３個の通信カードＮ１ｃ１，Ｎ１ｃ２，Ｎ１ｃ３を使用することにより、送信元のノード２１から、送信データを３分割して受信することができる。その結果通信カードの負荷が分散される。

図２１は複数のネットワークを使用することで負荷分散（衝突の回避）を図る例を示す。図２１の場合、第１のネットワークは通信中継装置Ｓ１を有し、データが短い場合の信頼性のある同報通信方法をサポートすることで、第１実施例に係る通信方法におけるバッファ情報の同報に使用される。すなわち送信側のノード１１は通信カード１１ｃ１を使用し、第１のネットワークの通信中継装置Ｓ１を介してバッファ情報を送信する。受信側のノード２１は通信カード２１ｃ１を使用し、第１のネットワークの通信中継装置Ｓ１を介してバッファ情報を受信する。他方、第２のネットワークは通信中継装置Ｓ２を有し、信頼性のある１対１通信方法（ＲＲＤＭＡ機能による方法等）をサポートすることで、第１実施例に係る通信方法における送信データの転送に使用される。すなわち受信側のノード２１は通信カード２１ｃ２を使用し、第２のネットワークの通信中継装置Ｓ２を介し、送信側のノード１１の通信カード１１ｃ２から、送信データを受信する。

(b)複数ノードにより、ボトルネックとなる資源、およびその資源を使う処理について分担する。この場合複数ノード間の処理についてスケジューリングを行って、１ノードが同時に処理するデータ転送要求量を減らす。具体的には以下の（１）、（２）の方法が考えられる。

(1)ノード数が非常に大きい場合には、以下に示す如くの方法により、階層化した処理を行う。
- 同報通信の場合、送信開始時点では送信側のノードだけが持つデータを持つノードが、通信段数の増加に従って増加するようにする。つまり、階層関係において後の段階になるほど「次の段階では送信側のノードになりうるノード」が増加していく。このことを利用して、各種の資源への負荷をノード間に分散し「衝突」を回避することができる。
- 階層関係の各段階での配布数が多いほど通信段数は少なくて済むが１段階あたりの時間が増加する。又、２ノード間の通信による通信資源への負荷や通信所用時間は、その２ノードの選び方や通信データ量に依存する。

(2)同報通信全体の性能を最適化するために、階層化された通信の各段階で、どのように転送するのが適切かを、次のような資源上の制約と転送要求量の比や、ネットワークの接続形態（トポロジー）を考慮して定める。
- 各ＮＩＣがサポートする通信帯域やＩＯバスあるいはメモリバスの帯域による制約
- ノードあたりの資源量（ＮＩＣ数、独立動作可能なバス数）による制約
- ネットワークに適用される通信方式の側の資源量による制約（例えばネットワークの「スイッチ」や「ハブ」が一度に取り扱える通信データ量に上限があるので、「単位時間内にネットワークを移動中のデータの総量」にも上限がある）
上記の(a),(b)の方法はＣＰＵ以外の資源についての負荷分散（衝突回避）方法として（ＲＲＤＭＡ機能の使用の有無に必ずしも依存しない）一般的な考え方と言える。特に、データ本体（送信データ）の移動にＲＲＤＭＡ機能による１対１通信のみを使用する場合でも、１対１通信だけの組み合わせによる同報通信の実現で使用される手法は、全てそのまま使用できる。又、データが短い場合の信頼性のある同報通信方法におけるバッファ情報を利用して、更に拡張して上記の(a),(b)の方法を用いることができる。まず実施例１に係る通信方法においてＲＲＤＭＡ機能使用時に起こりえる衝突を回避する方法について説明する。

一般に、階層的な転送によって同報通信を実現する場合、「前の段でデータを受け取ったノード全てが、次の段でなるべく多くの別のノードに転送する」ことが「転送の並列度」の観点からは最も効率がよい。さらに以下の(1),(2)の条件も（十分に精度が高い近似として）成り立つ場合は、実際の同報通信性能も高くなる。

(1)どのノード間の転送時間も全て同じ。

(2)複数の組のノードが同時に通信することが、各組の間の通信性能に影響を与えない。

現実のネットワークでの同報通信では、ネットワークのトポロジーや各ノードの通信性能の特性、転送データ量などの条件により、上記の条件(1),(2)は成立しない場合も多い。ここで以下に「前の段でデータを受け取ったノードは全て次の段でできるだけ多く別のノードに転送する」という指針が、階層的な転送によって同報通信を実現する場合の効率を改善する際に、一定の範囲で意味を持つ場合を考察する。

まず、一般に１対１通信だけの階層的な転送によって同報通信を実現する場合において、「前の段で１つのノードからデータを受け取ったノードが全て次の段で別のノード１つに転送する」という、もっとも単純な場合を、比較の基準として選ぶ。この場合の転送パターンは２項木（ｂｉｎｏｍｉａｌ ｔｒｅｅ）と呼ばれる「グラフ」で表される。

「転送元ノードから同時に２つのノードがＲＲＤＭＡ機能でデータを受信する際に１つのノードからのＲＲＤＭＡ機能によるデータの受信が完了した後で別ノードから転送を開始する場合の２倍以上の時間がかかる」という場合を想定する。当該場合以外では、同時に２つのノードに転送を行うことにより、上記の２項木による転送パターンに比べ、高い性能が実現できる。

上記「転送元ノードから同時に２つのノードがＲＲＤＭＡ機能でデータを受信する際に１つのノードからのＲＤＭＡ機能によるデータの受信が完了した後で別ノードから転送を開始する場合の２倍以上の時間がかかる」場合は以下に述べるように比較的稀である。そこで当該場合が仮に発生した場合についても、ボトルネックになる箇所の負荷を下げることで解消可能と考えられる。

(1)転送元ノードから同時に２つのノードがＲＲＤＭＡ機能でデータを受信する際は、転送の開始と終了に要する時間（ソフトウェアによる処理時間を含む）は、受信側の２ノードの間で並列化されるため、「長くかかった方の時間」である。しかしながら、１つのノードからの転送が完了した後で別ノードから転送を開始する場合には、転送の開始と終了に要する時間は、２つの転送での時間の和になる。比較的小さなデータの転送の場合、転送の開始と終了に要する時間が データの転送時間と同程度の（無視はできない）長さになる場合がある。従って、２つの転送での時間の和は一方だけの（長くかかった方の）時間より長くなる可能性が高い。

(2)転送元ノードから同時に２つのノードがＲＲＤＭＡ機能でデータを受信する場合の転送時間が１つのノードだけからのアクセスよりも長くなる要因として以下の点が考えられる。すなわちデータの各部分の転送時間が、ハードウェアによる調停 (ａｒｂｉｔｒａｔｉｏｎ） に必要な時間の分だけ増加する点である。すなわち２以上の転送先ノードが同時に転送元ノードにアクセスすることで、ＮＩＣ，ＩＯバス、メモリなどのバンド幅が低下することによる影響が支配的な場合と言い換えることができる。上記(1)の理由と考え合わせると、上記「転送元ノードから同時に２つのノードがＲＲＤＭＡ機能でデータを受信する際に１つのノードからのＲＲＤＭＡ機能によるデータの受信が完了した後で別ノードから転送を開始する場合の２倍以上の時間がかかる」という問題は、以下にようにして解消できる。すなわち、比較的長いデータを一度に転送する場合に対して、バンド幅による制限に対処すればよい。

このような並列アクセスの問題に対しては、前述の「負荷が大きいシステム資源についてはノードあたりの数を増やした上で平行動作させる」という対策は有効と考えられる。又、並列動作可能な資源の数以下に転送先の数を制限すれば、問題は起きないとも言える。

(3)上記(2)の理由で考察したことから、問題が起こるとすれば「転送データ（送信データ）が長いため、転送時間が転送元での通信バンド幅によって決ってしまう」場合と言える。この場合には、データを複数のセグメントに分割して、各段階で転送元になるノードを複数にすることで、問題を解消できる。

図２２Ａ，２２Ｂ，２２Ｃ，２２Ｄ，２２Ｅは、送信データを２つのセグメント（第１セグメントおよび第２セグメント）に分けて、各セグメントについて 転送元になるサーバを作る例を示す。この例では、１ノードに複数ノードからの ＲＲＤＭＡ機能によるアクセスが同時に実行されることを回避することができる。なお図２２Ｅに示す第５段階では、受信側のノード２１，２２，２３，２４の各々が有する通信カードの転送機能が、「送信」、「受信」の各々について独立のバンド幅を持っていることを想定している。このような機能を有するＮＩＣは多い。

図２２Ａに示される第１段階では、送信データの第１のセグメントが送信側のノード１１の通信用のバッファ１１ａから、受信側のノード２１の通信用のバッファ２１ａにＲＲＤＭＡ機能により転送される。

図２２Ｂに示される第２段階では、送信データの第２のセグメントが送信側のノード１１の通信用のバッファ１１ｂから、受信側のノード２２の通信用のバッファ２１ｂにＲＲＤＭＡ機能により転送される。

図２２Ｃに示される第３段階では、送信側のノード１１は受信側のノード２１，２２，２３，２４，２５の各々に対し、以下に述べる第４段階、第５段階の実行のために必要なバッファ情報を、データが短い場合の信頼性のある同報通信方法で、送信する。

図２２Ｄに示される第４段階では、送信側のノード１１の通信用のバッファ１１ａから受信側のノード２５の通信用のバッファ２５ａに対し、送信データの第１セグメントがＲＲＤＭＡ機能により転送される。又、受信側のノードであって中継ノードとしても機能するノード２１の通信用のバッファ２１ａから受信側のノード２３の通信用のバッファ２３ａに対し、送信データの第１セグメントがＲＲＤＭＡ機能により転送される。同様に受信側のノードであって中継ノードとしても機能するノード２２の通信用のバッファ２２ｂから受信側のノード２４の通信用のバッファ２４ｂに対し、送信データの第２セグメントがＲＲＤＭＡ機能により転送される。

図２２Ｅに示される第５段階では、送信側のノード１１の通信用のバッファ１１ｂから受信側のノード２５の通信用のバッファ２５ｂに対し、送信データの第２セグメントがＲＲＤＭＡ機能により転送される。又、受信側のノードであって中継ノードとしても機能するノード２１の通信用のバッファ２１ａから受信側のノード２４の通信用のバッファ２４ａに対し、送信データの第１セグメントがＲＲＤＭＡ機能により転送される。同様に受信側のノードであって中継ノードとしても機能するノード２２の通信用のバッファ２２ｂから受信側のノード２３の通信用のバッファ２３ｂに対し、送信データの第２セグメントがＲＲＤＭＡ機能により転送される。同様に受信側のノードであって中継ノードとしても機能するノード２３の通信用のバッファ２３ａから受信側のノード２２の通信用のバッファ２２ａに対し、送信データの第１セグメントがＲＲＤＭＡ機能により転送される。同様に受信側のノードであって中継ノードとしても機能するノード２４の通信用のバッファ２４ｂから受信側のノード２１の通信用のバッファ２１ｂに対し、送信データの第２セグメントがＲＲＤＭＡ機能により転送される。

上述した図２２Ａ，２２Ｂ，２２Ｃ，２２Ｄ，２２Ｅの第１乃至第５段階により、送信側のノード１１の通信用のバッファ１１ａ，１１ｂに格納されていた送信データの第１および第２セグメントは、受信用のノードの各々に転送される。すなわち、送信データの第１および第２セグメントは受信側のノード２１の通信用のバッファ２１ａ、２１ｂに転送される。同様に送信データの第１および第２セグメントは受信側のノード２２の通信用のバッファ２２ａ、２２ｂに転送される。同様に送信データの第１および第２セグメントは受信側のノード２３の通信用のバッファ２３ａ、２３ｂに転送される。同様に送信データの第１および第２セグメントは受信側のノード２４の通信用のバッファ２４ａ、２４ｂに転送される。同様に送信データの第１および第２セグメントは受信側のノード２５の通信用のバッファ２５ａ、２５ｂに転送される。

ここで図２２Ｂの第２段階においては、送信データの第１セグメントを受信済みのノード２１は転送元とはなっていない。以下に説明する図２３Ａ，２３Ｂに示される例は、上記第２段階において、送信データの第１セグメントを受信済みのノード２１からの転送が開始される例である。データが短い場合の信頼性のある同報通信方法によるバッファ情報の通知はデータが短いために所要時間が短いと考えると、図２３Ａ，２３Ｂの例の方法によれば、複数のノードにおける通信カードの並列使用度は高くなる。

図２３Ａ，２３Ｂの例の場合、第２段階では図２３Ａに示される如く、送信側のノード１１は、受信側のノード２１，２３，２５に対し、第１実施例に係る通信方法におけるバッファ情報を、データが短い場合の信頼性のある同報通信方法にて、同報する。

次に図２３Ｂに示される如く、上記バッファ情報に基づき、受信側のノード２２は、送信データの第２セグメントを送信側のノード１１からＲＲＤＭＡ機能を使用して受信する。又、上記バッファ情報に基づき、受信側のノード２５は、送信データの第１セグメントを、受信側のノードであり中継ノードとしても機能するノード２１からＲＲＤＭＡ機能を使用して受信する。その後は上記図２２Ｃ，２２Ｄ，２２Ｅとともに上述した第３乃至第５段落が実行される。但し図２３Ａ，２３Ｂの例の場合、既に第２段階で送信データの第１セグメントが受信ノード２５に転送されている。したがってこの場合第４段階であらためて送信データの第１セグメントを受信ノード２５に転送する必要はない。

次に第２実施例に係る通信方法の場合のＲＲＤＭＡ機能使用時に起こりえる「衝突」を回避する方法について説明する。

データ本体（送信データ）の転送にはデータが長い場合の必ずしも信頼性のない同報通信を使用し、送信データのリカバリのためにＲＲＤＭＡ機能を使用する場合、そもそも同時に複数のノードからアクセスされる量が少なくなると考えられる。このため「衝突」の問題は発生しにくいと考えられる。さらに上述の第１実施例に係る通信方法の場合のＲＲＤＭＡ機能使用時の衝突を回避する方法の説明中の(3)にて述べた方法を使用することができる。すなわち再送に係る送信データを転送する際、再送に係る送信データを複数のセグメントに分け、受信側のノードは各セグメントの送信データを異なるノードを介して取得すればよい。

なお、データが長い場合の必ずしも信頼性のない同報通信を利用する場合に、再送に係る送信データを取得する際には（特にノード数が大きい場合に）ツリー（ｔｒｅｅ）状の階層化ではなく、「前の段でデータのセグメントを正しく取得できたノードからリング（ｒｉｎｇ）状に送信データを取得していく」という手法も知られている。転送パターンがリング状なら、１度に１つのノードからしかアクセスされないので「衝突」は起こらない。この手法については、例えば非特許文献７のFigure １等に記載されている。

図２４は上記「通信用のバッファ」の設定例を説明する図である。

図２４の設定例の場合、ノードが有する主記憶５００中、先頭アドレス５２１の領域５２０がバッファ領域として設定される。更にバッファ領域５２０中、先頭アドレス５２１からオフセット５２２離れたアドレスから開始され長さ５２３を有する領域５２５が「通信用のバッファ」として設定される。すなわち「通信用のバッファ」５２５は、主記憶５００中、「先頭アドレス５２１」＋「オフセット５２２」で得られるアドレスから「先頭アドレス５２１」＋「オフセット５２２」＋「長さ５２３」で得られるアドレスまでの範囲を有する。ここで上記の如く「バッファ情報」は、「通信用のバッファの場所を示す情報」であり、したがって図２４の設定例の場合、「バッファ情報」は、上記先頭アドレス５２１，オフセット５２２及び長さ５２３の情報を含む。

図２５は上記リカバリ制御情報のデータフォーマット例について説明するための図である。図２５のデータフォーマット例では図示の如く、リカバリ制御情報３００のデータフォーマットは、エラー検出コードを格納する領域３１０，データの大きさを示す情報を格納する領域３２０及びその他の情報を格納する領域３３０を有する。その他の情報を格納する領域３３０には、必要に応じ、上記の如く、タイムアウト時間、バッファ情報等が格納される。

Claims (8)

1. 送信元ノードが複数の送信先ノードの各々へ送信する送信データを、前記送信元ノードが有する通信用のバッファに格納するステップと、
   前記送信元ノードが、前記通信用のバッファから前記複数の送信先ノードが前記送信データを受信するために必要なバッファ情報を作成するステップと、
   前記送信元ノードが前記複数の送信先ノードの各々に対し、前記複数の送信先ノードの各々からの同期信号全てを受信することにより同期を行うバリア同期により同報通信を行う方法である第１の通信方法によって前記バッファ情報を送信するステップと、
   前記複数の送信先ノードの各々が、１対１通信を行う方法である第２の通信方法によって、前記バッファ情報を使用して前記通信用のバッファから前記送信データを受信するステップと、
   を有することを特徴とする通信方法。
2. 前記第１の通信方法は、前記送信データより短いデータの送信に対する信頼性を有する通信方法としての、バリア同期あるいはリダクション装置を使用する方法であることを特徴とする、請求項１に記載の通信方法。
3. 送信元ノードが送信データの完全性のチェックおよびリカバリに必要なリカバリ制御情報を作成するステップと、
   前記送信元ノードが複数の送信先ノードの各々に対し、前記複数の送信先ノードの各々からの同期信号全てを受信することにより同期を行うバリア同期により同報通信を行う方法である第１の通信方法によって、前記リカバリ制御情報を送信するステップと、
   前記送信元ノードが前記送信データを前記複数の送信先ノードの各々に対し、同報通信を行う方法である第２の通信方法により送信するステップと、
   前記複数の送信先ノードの各々が前記送信データを受信するステップと、
   前記複数の送信先ノードの各々が前記リカバリ制御情報を使用して当該受信された送信データの完全性のチェックを行うステップと、
   前記複数の送信先ノードの各々が前記受信された送信データの完全性のチェックの結果、前記受信された送信データが完全でない場合、前記リカバリ制御情報を使用して前記送信データのリカバリを行うステップと、
   を有することを特徴とする通信方法。
4. 前記第１の通信方法は、前記送信データより短いデータの送信に対し、前記第２の通信方法に比して高い信頼性を有する通信方法であることを特徴とする、請求項３に記載の通信方法。
5. 送信元ノードとしてのコンピュータを、
   複数の送信先ノードの各々へ送信する送信データを通信用のバッファに格納する手段と、
   前記複数の送信先ノードが前記通信用のバッファから前記送信データを受信するために必要なバッファ情報を作成する手段と、
   前記複数の送信先ノードの各々に対し、同報通信を行う方法である第１の通信方法によって前記バッファ情報を送信する手段として機能させることを特徴とするプログラム。
6. 前記第１の通信方法は、前記送信データより短いデータの送信に対する信頼性を有する通信方法としての、バリア同期あるいはリダクション装置を使用する方法であることを特徴とする、請求項５に記載のプログラム。
7. 送信先ノードとしてのコンピュータを、
   同報通信を行う方法である第１の通信方法によって、送信元ノードにより送信データが格納されたバッファから前記送信データを受信するために必要なバッファ情報を前記送信元ノードから受信する手段と、
   １対１通信を行う方法である第２の通信方法によって、前記バッファ情報を使用して前記通信用のバッファから前記送信データを受信する手段として機能させることを特徴とするプログラム。
8. 前記第１の通信方法は、前記送信データより短いデータの送信に対する信頼性を有する通信方法としての、バリア同期あるいはリダクション装置を使用する方法であることを特徴とする、請求項７に記載のプログラム。

Images