JP2016045510A - 情報処理システム、情報処理装置、情報処理システムの制御方法及び情報処理装置の制御プログラム - Google Patents

Abstract

【課題】プロセス間でのデータ通信において、バッファに保持される受信データの上書きに関係して発生する余分な制御通信を抑制する。【解決手段】送信側情報処理装置は、送信側プロセスを実行する送信側演算処理装置と、送信対象である対象データを保持する送信側記憶領域を有する送信側記憶装置と、送信側プロセスにより、対象データと対象データの宛先を示す宛先情報とを有する制御情報を含んで生成される送信データを、通信経路を介して送信する送信側通信装置を有する。送信側情報処理装置に通信経路を介して接続される受信側情報処理装置は、送信データを、通信経路を介して受信する受信側通信装置と、受信側プロセスを実行する受信側演算処理装置と、受信側プロセスにより、送信データから抽出される対象データを、記憶する受信側記憶領域を有する受信側記憶装置を有する。【選択図】図１１

Description

本発明は、情報処理システム、情報処理装置、情報処理システムの制御方法及び情報処理装置の制御プログラムに関する。

いわゆるスーパーコンピュータでは、例えば大規模な科学技術計算（ＨＰＣ：High Performance Computing）が主要目的とされる場合が多い。そのため、スーパーコンピュータでは、システム全体の処理性能が最重要項目の１つである。

スーパーコンピュータは、複数のProcessor Element（ＰＥ）と通信モジュールを含む情報処理装置としての計算ノード、複数の計算ノード間を接続するネットワーク等をそのシステム内に含む。ＰＥはそれぞれ、演算処理装置としてのCentral Processing Unit（ＣＰＵ）と主記憶装置としてのメモリを有する。

ユーザは、システムの多数のＰＥ上に、それぞれプロセスを起動して、１つのプログラムを実行する。このようなプログラムの実行においては、プロセス間でのデータ通信が発生する場合がある。プロセス間のデータ通信では、例えばMessage Passing Interface（ＭＰＩ）というApplication Programming Interface（ＡＰＩ）が使用される。

近年のスーパーコンピュータにおいては、含まれるＰＥの数は増加傾向にある。また、ＰＥ内のＣＰＵの多コア化が進んでおり、１つのＰＥ上に複数のプロセスを立ち上げて処理をする傾向に移行してきている。このため、スーパーコンピュータにおいてプログラムの実行により使用されるプロセス数や、プログラムの実行により発生するプロセス間通信の数も増加してきている。

多数のプロセス間でデータの通信が発生するプログラムでは、プログラム全体の処理において、計算ノード間の通信処理がより重要になる。ＭＰＩには例えば、特定プロセス（グループ）に他のプロセス（グループ）がデータを転送するＡＰＩや、全プロセス間のデータを転置交換するＡＰＩが存在する。このようなＡＰＩの処理が実行される場合には、プロセスの数の増加に応じて通信が増加し、プログラム全体の処理性能に対するプロセス間通信の影響が大きくなる。

一方、データの通信に関する技術として、送信部は、データ転送要求を受けた際に、転送先に受信許可の有無かを問合せることなく、送信対象データからRemote Direct Memory Access（ＲＤＭＡ）パケットを作成して投機的に送信する技術がある。送信部は、受信領域が受信不許可であれば、転送先から再送要求を受信した際に、ＲＤＭＡパケットを再送する。受信部は、パケット受信時に転送領域管理情報を参照して転送不許可を判別した場合に、受信パケットを破棄し、その後に転送許可を判別した場合に、再送要求を送信して転送させる。

特開２００７−２５７４７９号公報 特開２０１１−２３４１４５号公報

Yuichiro Ajima, Yuzo Takagi, Tomohiro Inoue, Shinya Hiramoto, Toshiyuki Shimizu: "The Tofu Interconnect", The 19th Annual Symposium on High-Performance Interconnects, p87-94(2011). Yuichiro Ajima, Tomohiro Inoue, Shinya Hiramoto, Toshiyuki Shimizu, Yuzo Takagi: "The Tofu Interconnect", IEEE Micro, Vol.32, No.1, p21-31(2012).

上記技術では、同時に複数のプロセス間通信が発生した場合に、受信側のバッファに格納された受信データが、受信プロセスにより使用される前に、別のプロセス間通信における受信データに上書きされてしまうことがある。この場合、上書きされたデータは受信側から消失してしまうため、上書きされたデータを再取得するための制御通信が発生する。通信するプロセス数が大量である場合や、各プロセスにおける処理数が大量である場合は、制御通信の発生による遅延の影響が大きくなる。

１つの側面では、本発明は、プロセス間でのデータ通信において、バッファに保持される受信データの上書きに関係して発生する余分な制御通信を抑制する。

一態様の情報処理システムは、送信側情報処理装置と、送信側情報処理装置に通信経路を介して接続される受信側情報処理装置とを有する。送信側情報処理装置は、送信側プロセスを実行する送信側演算処理装置と、送信対象である対象データを保持する送信側記憶領域を有する送信側記憶装置と、送信側プロセスにより、対象データと対象データの宛先を示す宛先情報とを有する制御情報を含んで生成される送信データを、通信経路を介して送信する送信側通信装置を有する。受信側情報処理装置は、送信データを、通信経路を介して受信する受信側通信装置と、受信側プロセスを実行する受信側演算処理装置と、受信側プロセスにより、送信データから抽出される対象データを、記憶する受信側記憶領域を有する受信側記憶装置を有する。

一態様によれば、プロセス間でのデータ通信において、バッファに保持される受信データの上書きに関係して発生する余分な制御通信を抑制することができる。

ＭＰＩ通信関数とＲＤＭＡ通信関数の違いを説明するための図である。 Eagerプロトコルについて説明するための図である。 Rendezvous-RDMA readプロトコルについて説明するための図である。 Rendezvous-RDMA writeプロトコルについて説明するための図である。 送信ノードのＭＰＩ領域のデータが受信ノードのＭＰＩ領域に送信される手順を説明するための図である。 第１の方法を説明するための図である。 第２−１の方法において、データの上書きが発生した場合の再転送の様子を説明するための図である。 第２−２の方法において、データの上書きを防止するための制御を説明するための図である。 第２−３の方法において、データの上書きを防止するための制御を説明するための図である。 実施形態の通信方法の流れを説明するための図である。 実施形態に係る情報処理システムの構成の一例を示す。 通信ノードの構成の一例を示す。 設定部によるディスクリプタへの送信対象データの埋め込みについて説明するための図である。 送信対象データが複数のディスクリプタに分割して埋め込まれて、転送される様子を説明するための図である。 ディスクリプタのデータ構造の一例を示す。 ディスクリプタの埋め込み領域の一例を示す。 ダミー通信において、２つの送信プロセスが同時に、１つの受信プロセスに対してデータを送信する様子を説明するための図である。 基本通信における第１の方法と、ダミー通信とのバッファの確保のされ方について比較する図である。 実施形態に係る送信ノードのダミー通信における処理の詳細を図解したフローチャートの一例である。 送信処理Ａの処理の詳細を図解したフローチャートの一例である。 送信処理Ｂの処理の詳細を図解したフローチャートの一例である。 実施形態に係る受信ノードのダミー通信における処理の詳細を図解したフローチャートの一例である。 受信処理Ａの処理の詳細を図解したフローチャートの一例である。 受信処理Ｂの処理の詳細を図解したフローチャートの一例である。 受信処理Ｃの処理の詳細を図解したフローチャートの一例である。 実施形態に係る通信モジュールのデータの受信処理の詳細を図解したフローチャートの一例である。 実施形態に係る情報処理システムのハードウェア構成の一例を示す。

情報処理システムとしてのスーパーコンピュータにおけるプロセス間のデータ通信では、例えばＭＰＩが使用される。ＭＰＩライブラリの実装において例えば３つのプロトコルのうちのいずれかが選択されて通信が行われる。３つのプロトコルとは、すなわち、Eagerプロトコル、Rendezvous-RDMA readプロトコル、Rendezvous-RDMA writeプロトコルである。

以下の説明では、プロセス間通信において、送信プロセスが受信プロセスに転送する対象データを送信対象データと記す場合がある。

先ず、ＭＰＩ通信関数と、ＲＤＭＡ通信関数の違いについて説明する。図１は、ＭＰＩ通信関数とＲＤＭＡ通信関数の違いを説明するための図である。図１（Ａ）は、ＭＰＩ通信関数を用いた通信について説明するための図である。図１（Ｂ）は、ＲＤＭＡ通信関数を用いた通信について説明するための図である。

図１（Ａ）に示すように、ＭＰＩ通信関数を用いた通信の場合、データを送信するプロセスＡは、プロセスＡ自身の情報と、通信相手のプロセスＢのプロセスＩＤの情報を用いてデータを送信することが可能である。具体的にはプロセスＡは、通信相手先であるプロセスＢのプロセスＩＤを指定してプロセスＢに対してデータを送信する。このようにＭＰＩ通信関数を用いた通信の場合、プロセスＡはプロセスＢに関してプロセスＩＤ以外の情報を持たなくても、データの通信を行うことができる。尚、通信相手のプロセスＩＤは、別のＭＰＩ関数を用いて入手可能である。

一方、ＲＤＭＡ通信関数を用いた通信の場合、図１（Ｂ）に示すように、プロセスＡは、プロセスＢのプロセスＩＤに加えて、プロセスＢについての通信制御に関する情報を用いて、データを送信する。すなわちプロセスＡは、プロセスＢについての通信制御に関する情報を持っていなければ、データをプロセスＢに送信することはできない。通信制御に関する情報とは、例えば、受信側情報処理装置としての受信ノードにおいて送信対象データが格納されるメモリのアドレスなどの情報である。プロセスＡは、データの通信に先立ってプロセスＢについての通信制御に関する情報をプロセスＢから取得する。そして取得した情報に基づいて、プロセスＡは、受信ノードのメモリのアドレス等を指定してデータをプロセスＢへ送信する。このようにＲＤＭＡ通信関数を用いた通信では、通信相手の通信制御に関する情報をやり取りするための制御通信が発生する。

次に、図２〜図４を参照して、実施形態で使用される３つのプロトコルについて説明する。先ずEagerプロトコルについて説明する。

Eagerプロトコルを用いた通信では、送信対象データの通信前の制御通信は行われない。制御通信がない代わりに、受信ノードにおいてＭＰＩライブラリにより受信バッファが確保される。送信対象データは受信ノードで受信されると、受信バッファに格納される。受信バッファに格納された送信対象データは、その後、アプリケーションの使用するメモリ領域（ユーザ領域）へコピーされる。以下の説明では、ＭＰＩライブラリにより使用されるメモリ領域をＭＰＩ領域と記し、アプリケーションが使用するメモリ領域をアプリケーション領域と記す場合がある。受信バッファは、ＭＰＩ領域に確保される。尚、アプリケーション領域は、所定の記憶領域でもよい。

図２は、Eagerプロトコルについて説明するための図である。図２に示すように、先ず送信プロセスは、アプリケーション領域から送信対象データをＭＰＩ領域にコピーする。次に送信プロセスは、コピーした送信対象データに、タグ情報等を格納したヘッダ及びフッタを付加して、受信プロセスへ送信する。受信プロセスはデータを受信すると、受信バッファに、受信したデータを格納する。次に受信プロセスは、ヘッダ及びフッタを送信対象データから外して、アプリケーションが使用するメモリ領域にコピーする。そして受信プロセスは、送信プロセスに対して送信対象データの受信が完了したことを通知する。

Eagerプロトコルを用いた通信は、比較的小さなデータの転送に適している。具体的にはEagerプロトコルを用いた通信に適するデータとは、送信プロセスに対応する受信バッファに入りきるサイズのデータ等であり、例えば、１メガバイトまでのデータである。尚、Eagerプロトコルを用いた通信において送信プロセスは、事前に受信ノードのアドレスを知っているものとする。

次にRendezvous-RDMA readプロトコルについて説明する。Rendezvous-RDMA readプロトコルを用いた通信では、送信対象データの通信前に、通信相手の通信制御に関する情報をやり取りするための制御通信が行われる。具体的には受信プロセスは、制御通信により送信プロセスの通信制御に関する情報を取得する。そして受信プロセスは、取得した情報を用いて、送信側のアプリケーション領域から送信対象データを取得し、直接受信ノードのアプリケーション領域に格納する。

図３は、Rendezvous-RDMA readプロトコルについて説明するための図である。図３に示すように、先ず送信プロセスは制御通信により、通信制御に関する情報を受信プロセスに送信する。通信制御に関する情報を受信すると、受信プロセスは、通信制御に関する情報を受信バッファに格納する。次に受信プロセスは、通信制御に関する情報に基づいて、例えば、取得対象のデータが格納される送信側情報処理装置としての送信ノードのアドレスや、取得したデータを格納する受信ノードのアドレス等を指定して、送信対象データの取得要求（RDMA Read）を発行する。送信対象データの取得要求を受信すると、送信プロセスは、送信対象データを受信ノードのアプリケーション領域に送信する。送信対象データを受信すると、受信プロセスは通信の完了通知を送信プロセスに対して送信する。

Rendezvous-RDMA readプロトコルを用いた通信は、Eagerプロトコルを用いた通信よりも、大きなデータの転送に適している。具体的にはRendezvous-RDMA readプロトコルを用いた通信に適するデータとは、送信プロセスに対応する受信バッファのサイズより大きいサイズのデータ等であり、例えば１メガバイトより大きなデータである。

次にRendezvous-RDMA writeプロトコルについて説明する。Rendezvous-RDMA writeプロトコルを用いた通信では、Rendezvous-RDMA writeプロトコルを用いた通信と同様に、送信対象データの通信前に、通信相手の通信制御に関する情報をやり取りするための制御通信が行われる。具体的には送信プロセスは、制御通信により、送信プロセスの通信制御に関する情報を受信プロセスに送信し、その応答として、受信プロセスの通信制御に関する情報を取得する。そして送信プロセスは、送信側のアプリケーション領域から送信対象データを送信し、直接受信ノードのアプリケーション領域に格納する（RDMA Write）。

図４に示すように、先ず送信プロセスは制御通信により、送信ノードの通信制御に関する情報を受信プロセスに送信する。通信制御に関する情報を受信すると、受信プロセスは、通信制御に関する情報を受信バッファに格納する。次に受信プロセスは、受信ノードの通信制御に関する情報を送信プロセスに送信する。次に送信プロセスは、受信プロセスの通信制御に関する情報に基づいて、送信対象データの格納先となる受信ノードのアプリケーション領域のアドレスを指定して、送信対象データ送信する。それにより送信プロセスは、指定したアプリケーション領域に送信対象データを書き込む。そして送信プロセスは、通信の完了通知を受信プロセスに対して送信する。

Rendezvous-RDMA writeプロトコルを用いた通信は、Rendezvous-RDMA readプロトコルを用いた通信と同様に、Eagerプロトコルを用いた通信よりも、大きなデータの転送に適している。

上記３つのプロトコルを用いた通信において、異なる送信プロセスから同時にデータが送られてくる場合があるので、受信バッファは送信プロセスごとに確保されることがある。この場合、大量の通信が発生すると、受信側のメモリ使用量が多くなる。

尚、送信側のＭＰＩ領域は、他の送信プロセスが他のデータを送信する際にも使い回すことができる領域である。このため、複数の送信プロセスによる通信が発生しても送信側のＭＰＩ領域が不足するケースが発生することは、受信側のＭＰＩ領域に比較すると少ない。

次に、送信ノードのＭＰＩ領域のデータが受信ノードのＭＰＩ領域に送信される手順について説明する。以下の説明では、送信ノードのＭＰＩ領域から受信ノードのＭＰＩ領域に転送されるデータを通信データと記す場合がある。通信データは、Eagerプロトコルの通信の場合は、送信対象データであり、Rendezvous-RDMA read、及びRendezvous-RDMA writeプロトコルの通信の場合は、通信制御に関する情報である。

図５は、送信ノードのＭＰＩ領域のデータが受信ノードのＭＰＩ領域に送信される手順を説明するための図である。

図５において送信ノードのＭＰＩライブラリ（以下、送信ＭＰＩライブラリと記す場合がある）は、先ず、通信データをアプリケーション領域からＭＰＩ領域にコピーする。そして送信ＭＰＩライブラリは、ＭＰＩ領域の通信データの送信処理を開始する。データの送信前に送信ＭＰＩライブラリは、通信データの通信を制御するための制御情報（以下、ディスクリプタと記す場合がある）を生成する。このディスクリプタとともに、送信ＭＰＩライブラリは通信経路としてのネットワークまたはインターコネクトを介して、通信データを受信ノードに送信する。

送信ノードから通信データとディスクリプタを受信すると、受信ノードは通信データをＭＰＩ領域に確保したバッファに格納する。通信データのバッファへの格納が完了すると、受信ノードの通信モジュールは、ディスクリプタの一部の情報を含む受信完了通知を生成して、生成した受信完了通知をキューに格納する。キューは、通信モジュールにより受信ノードのメモリを用いて実現される。ここで、通信モジュールは、受信ノードのハードウェアにより制御されるものであってもよいし、ＭＰＩライブラリの機能によって実現されてもよい。

次に、受信ノードのＭＰＩライブラリ（以下、受信ＭＰＩライブラリと記す場合がある）は、キューに格納された受信完了通知を参照し、参照した受信完了通知に基づいて、バッファの通信データにアクセスする。ここで、受信ＭＰＩライブラリは、キューに対してポーリングを行うことにより受信完了通知がキューに格納されたか否かを確認する。

そしてＭＰＩライブラリは、バッファから通信データを、通信プロトコルに応じて、アプリケーション領域またはＭＰＩ領域にコピーする。すなわち、通信プロトコルがEagerプロトコルの場合は、ＭＰＩライブラリは、通信データをアプリケーション領域にコピーする。そしてコピーされたデータに対してアプリケーション等はアクセスを行う。通信プロトコルがRendezvous-RDMA read、またはRendezvous-RDMA writeの場合には、ＭＰＩライブラリは、通信データをＭＰＩ領域の別の領域にコピーする。通信プロトコルがRendezvous-RDMA read、またはRendezvous-RDMA writeの場合には、ＭＰＩ領域にコピーした通信データは、送信ノードの通信制御に関する情報であり、この情報に基づいてRDMA-ReadまたはRDMA-Writeが行われることとなる。以下の説明では、通信データは、受信ノードにおいて、バッファに格納されてから別の領域にコピーされるまでの間は、通信で使用中であると記す場合がある。

ディスクリプタは、対応する通信データのプロセス間の通信を制御するために使用される通信制御情報である。ディスクリプタは通信処理を行う通信モジュールにより使用される。詳しくは後ほど説明するが、ディスクリプタは、例えば、通信の方法、通信相手のデータのメモリ上の位置、通信データのサイズ、及び通信相手の位置情報を含む。例えばプロセスＸがプロセスＹに通信データを送信する際に生成されるディスクリプタには、以下の情報が含まれてもよい。すなわちディスクリプタに含まれる情報は、RDMA-Writeを行う旨を示す情報、プロセスＹのメモリの「AAAA」番地からサイズ「L」バイト分のデータを書き込む旨を示す情報、プロセスＸの通信データは「BBBB」番地にある旨を示す情報である。

尚、送信ＭＰＩライブラリは送信プロセスによって実行されてもよいし、受信ＭＰＩライブラリは受信プロセスによって実行されてもよい。また、ディスクリプタを生成するのは、送信プロセスからデータを送信する旨の通知を受けた通信モジュールのプロセスまたは所定のソフトウェア（プログラム）であってもよい。

上述したようにＭＰＩを用いた通信においては、受信ノードにおいて通信データを一時的に記憶するための領域が利用される。例えば、通信を行うプロセスは各ノードのＭＰＩ領域にバッファを確保して、このバッファを通信に利用する。尚、これに比べて例えば、Transmission Control Protocol/Internet Protocol（ＴＣＰ／ＩＰ）等を用いた通信では、バッファを使わずに通信することが処理上は可能である。

プロセス間通信におけるバッファの確保の方法は、プロセス間通信毎にバッファを確保する方法と、全プロセスが共有して使用する固定長の受信バッファを確保する方法との２つの方法がある。

プロセス間通信毎にバッファを確保する方法（第１の方法）では、受信プロセスは、プロセス間通信毎に、ＭＰＩ領域の互いに異なる領域にバッファを確保する。すなわち受信プロセスは、各プロセス間通信で確保するバッファの領域が、互いに重ならないように確保する。

図６は、第１の方法を説明するための図である。図６において、プロセスＡはプロセスＸに対して、通信データＮを送信している。プロセスＡが送信する通信データＮに対応するディスクリプタＮには、通信データＮが、送信ノードＡのメモリにおいて、先頭アドレスが「AAA」からサイズが「N」バイトの領域に格納されていることを示す情報が含まれる。また、ディスクリプタＮには、通信データＮの送信先のプロセスがプロセスＸであることを示す情報が含まれる。また、ディスクリプタＮには、通信データＮの転送先の領域が、受信ノードＸのアドレス「XXX」を先頭アドレスとする領域であることを示す情報が含まれる。

また、プロセスＢはプロセスＸに対して、通信データＭを送信している。プロセスＢが送信する通信データＭに対応するディスクリプタＭには、通信データＭが、送信ノードＢのメモリにおいて、先頭アドレスが「BBB」からサイズが「M」バイトの領域に格納されていることを示す情報が含まれる。また、ディスクリプタＭには、通信データＭの送信先のプロセスがプロセスＸであることを示す情報が含まれる。また、ディスクリプタＭには、通信データＭの転送先の領域が、受信ノードＸのアドレス「YYY」を先頭アドレスとする領域であることを示す情報が含まれる。

受信ノードＸには、プロセスＸの通信相手のプロセスである、プロセスＡ、プロセスＢ毎にバッファが割り当てられている。プロセスＡ、プロセスＢから受信した通信データはプロセス毎に割り当てられたバッファに格納される。バッファに通信データが格納されると、受信用のキューに受信完了通知が書き込まれる。プロセスＸはキューにある受信完了通知を確認し、受信完了通知に記載されたメモリのアドレス上の通信データにアクセスする。そしてプロセスＸは、通信プロトコルに応じて、通信データを別の領域にコピーする。

例えばプロセスＸは、通信データＮの受信完了通知を参照して、通信データＮが格納されている先頭アドレス「XXX」とデータのサイズ「N」を特定する。そしてプロセスＸは、アドレス「XXX」からサイズ「N」の領域に格納されているデータにアクセスして、そのデータを別の領域にコピーする。

尚、受信バッファは、プロセス間通信ごとに割り当てられてもよい。
後ほど説明するが、バッファを全プロセスで共有して使用する場合には、複数のプロセス間通信が同時に発生すると、通信で使用中のデータが上書きされることがある。これに対して第１の方法では、１つのノードにおいて複数のプロセス間通信が同時に発生しても、通信で使用中のデータが上書きされることを防ぐことができる。これは、各プロセス間通信で確保されるバッファの領域が異なるためである。このため、データの上書きを防ぐための制御を実現するための、別途のプロセス間通信は発生しない。よって、複数のプロセス間通信が同時に発生しても、データの上書きを防ぐための制御に起因する処理性能の劣化を抑制することができる。

しかしながら、第１の方法では、プロセス間通信毎にバッファが確保されるため、大量のプロセス間通信が発生すると、ＭＰＩライブラリが使用するメモリ量が膨大になる。ＭＰＩ領域が増大すると、それだけ各ノードのメモリで使用可能なアプリケーション領域を圧迫することとなる。各ノードに搭載される物理メモリは有限であり、特にＨＰＣの分野におけるように、大量のプロセス間通信が発生する場合には、メモリの枯渇や、メモリ不足に起因するアプリケーションの処理性能の低下が問題となる。

送信ノードと受信ノードが、通信において使用可能な一時領域が存在しないインターコネクトで接続される場合には、受信ノードのメモリ使用量の問題の影響は大きくなる。このようなインターコネクトには、例えば、Ｔｏｆｕ（Torus fusion）インターコネクト等がある。

全プロセス共通の受信バッファを確保する方法（第２の方法）は、すべてのプロセス間通信において、受信ノードにおいて使用されるバッファが共通のバッファとなる方法である。共通のバッファは、各ノードにおいてＭＰＩ領域として確保可能なメモリの容量を超えないように確保される。このため、大量のプロセス間通信が発生した場合にも、ＭＰＩライブラリが使用するメモリ量を所定の範囲内に抑えることができる。しかしながら第２の方法では、使用中のデータの上書きを防ぐためには、通信データを送信するための通信とは別途のプロセス間通信が発生することとなる。第２の方法は、バッファの制御方法に基づいてさらに３つの方法（第２−１の方法〜第２−３の方法）に分類される。

第２−１の方法は、各プロセスのバッファの使用に関する制御を何も行わない方法である。第２−１の方法では、バッファの使用に関する制御が行われないために、１つのノードで複数のプロセス間通信が発生した場合に、通信で使用中のデータが上書きされる可能性がある。これは例えば、２つの異なるプロセスが同時に、同じプロセスに対して、同じ受信バッファのアドレスにデータを格納するように指定して、データを送信する場合等である。通信で使用中のデータが上書きされた場合、受信したデータが受信ノードから消失してしまうため、アプリケーション等は受信したデータにアクセスすることができなくなる。そのため、データの上書きが発生した場合には、受信プロセスは上書きされたデータの再転送を行うように制御する。

図７は、第２−１の方法において、データの上書きが発生した場合の再転送の様子を説明するための図である。図７において、プロセスＡとプロセスＢは同時に、プロセスＸに対して、それぞれ通信データＮ、通信データＭを送信している。このとき、プロセスＡとプロセスＢは、互いに相手のプロセスが、プロセスＸにデータを送信することを知らないし、データをプロセスＸのバッファのどこの領域に送るのかも知らない。受信ノードＸにおいて、通信データＮと通信データＭが格納されるバッファの領域が重複した場合には、どちらかのデータが他方のデータによって上書きされてしまう。このような上書きが発生した場合、プロセスＸは、上書きされたデータの送信プロセス（図７ではプロセスＡ）に対して、通信データの再送要求を送信する。再送要求を受信すると、プロセスＡは再度、プロセスＸに対して通信データＮを送信する。

このように第２−１の方法では、データの上書きが発生した場合に再転送のための通信が発生する。また、再転送の制御のために、チェックポイント/リスタートのような、実行時の通信順を記録する処理等が発生する。そのためバックアップやリカバリの時間も発生することとなる。

第２−２の方法は、全プロセス共通の受信バッファをプロセス数で分割する制御を行う方法である。第２−２の方法では、プロセス毎に送信可能なデータサイズが制限される。このデータサイズはプロセス数に反比例する。このため送信可能なデータサイズよりも大きいデータを送信する場合には、送信プロセスは通信データを複数に分割して送信する。複数の分割されたデータは連続して送信されることが考えられ、この場合、受信ノードでは、分割されたデータの１つを受信した後、そのデータを処理しきる前に、次の分割されたデータを受信してしまうというケースが発生する確率が高くなる。受信したデータを処理しきる前に新たにデータを受信すると、第２−２の方法では、受信プロセスは、バッファ上の処理前のデータを、後から受信したデータで上書きしてしまう。

このようなデータの上書きを防ぐために、受信プロセスは、データの送信が可能である旨の通知（送信許可通知）を送信プロセスに送信し、送信プロセスは送信許可通知を受信してから、データを送信するように制御が行われる。

図８は、第２−２の方法において、データの上書きを防止するための制御を説明するための図である。図８において、プロセスＡは、プロセスＸに対して、所定のデータを分割した複数の通信データＮ１、Ｎ２を連続して送信している。このときプロセスＸは、通信データＮ１をメモリに格納してから、通信データＮ１を別の領域にコピーする前に、通信データＮ２のデータを受信している。この場合、受信プロセスは、使用中の通信データＮ１を通信データＮ２のデータに上書きしてしまう。

そこで、プロセスＸは、通信データＮ１を受信すると、通信データＮ１が別の領域にコピーされたことを確認してから、送信許可通知をプロセスＡに送信する。プロセスＡは、送信許可通知を受信したことを確認したのちに、通信データＮ２をプロセスＸに対して送信する。これにより、通信で使用中のデータの上書きを防ぐことができる。

しかしながら第２−２の方法では、上書きを防止するために、送信許可通知を送信する通信が発生し、送信プロセスは、送信許可通知の受信を待ってから次の通信データの送信を行うため、レイテンシが悪化する。

第２−３の方法は、全プロセス共通の受信バッファにおいて、受信プロセスが動的にバッファを確保する制御を行う方法である。図９は、第２−３の方法におけるデータの上書きを防止するための制御を説明するための図である。

第２−３の方法では、先ず送信プロセスＡは、受信プロセスＸに対して、バッファの領域確保を依頼する。依頼に応じてプロセスＸは、バッファの領域を確保する。このときプロセスＸは、確保するバッファの領域に対して排他制御を行う。尚、メモリが不足している等の理由でバッファの領域を確保できない場合は待ちが発生する。そしてプロセスＸは、確保したバッファのアドレスを、プロセスＡに通知する。プロセスＡは、バッファのアドレスが通知されるまで待ち、通知を受信すると、その通知で示されるバッファのアドレスを指定して、データを送信する。

このように、第２−３の方法では、バッファ領域の確保のための通信が発生する。通信の回数が増えるためレイテンシが悪化し、また、受信バッファの排他制御のための時間もかかる。

次に、実施形態において、送信対象データが送信プロセスから受信プロセスに転送される様子を説明する。

実施形態において、送信プロセスは、ペイロード情報としての通信データを例えば空データのダミーデータとし、ダミーデータに対応するディスクリプタに送信対象データを埋め込む。そして送信プロセスは、通信データとしてのダミーデータと、ディスクリプタとを受信ノードに送信する。受信プロセスは、ディスクリプタに埋め込まれた送信対象データを抽出することにより、送信対象データを取得する。
ここで、ダミーデータは空データであってもよいし、何かのデータを含む実データであってもよい。

図１０は、実施形態の通信方法の流れを説明するための図である。図１０において、送信プロセスは先ず、ダミーデータと、そのダミーデータに対応するディスクリプタを生成する。次に送信プロセスは、送信対象データを分割して分割データを生成し、分割データをディスクリプタの特定の領域に埋め込む。そして送信プロセスは、ダミーデータと、そのダミーデータに対応するディスクリプタとを、ネットワークまたはインターコネクトを介して受信ノードに送信する。

受信ノードは、ダミーデータと、ダミーデータに対応するディスクリプタとを受信すると、先ず、ダミーデータを受信バッファに格納する。ダミーデータの受信バッファへの格納が完了すると、受信プロセスはディスクリプタに基づいて、受信完了通知を生成し、キューに格納する。次に受信プロセスは、キューに格納された受信完了通知から分割データを抽出する。そして受信プロセスは、分割データを結合して通信データを再構成する。その後、受信プロセスは、再構成した通信データを、通信プロトコルに応じてアプリケーション領域またはＭＰＩ領域にコピーする。

以下の説明では、図１０を参照して説明した、通信データをダミー情報として、ディスクリプタに送信対象データを埋め込む通信をダミー通信と記し、図５を参照して説明した通信を基本通信と記す。

図１１は、実施形態に係る情報処理システムの構成の一例を示す。図１１において情報処理システム１は、送信側情報処理装置２と、送信側情報処理装置２に通信経路を介して接続される受信側情報処理装置３とを有する。

送信側情報処理装置２は、送信側演算処理装置４と、送信側記憶装置５と、送信側通信装置６とを有する。送信側演算処理装置４は、送信側プロセス（送信プロセス）を実行する。送信側記憶装置５は、送信対象である対象データ（送信対象データ）を保持する送信側記憶領域を有する。送信側通信装置６は、送信側プロセスにより、対象データと対象データの宛先を示す宛先情報とを有する制御情報（ディスクリプタ）を含んで生成される送信データを、通信経路を介して送信する。

受信側情報処理装置３は、受信側通信装置７と、受信側演算処理装置８と、受信側記憶装置９とを有する。受信側通信装置７は、送信データを、通信経路を介して受信する。受信側演算処理装置８は、受信側プロセス（受信プロセス）を実行する。受信側記憶装置９は、受信側プロセスにより、送信データから抽出される対象データを、記憶する受信側記憶領域を有する。

送信データはさらに、制御情報の他に、ペイロード情報（通信データ）を有する。ペイロード情報は空データである。もしくは、ペイロード情報は実データである。

制御情報はさらに、宛先情報の他に、送信側情報処理装置２と受信側情報処理装置３との間の通信方式を示す通信方式情報（通信種別情報）を有する。また、送信側通信装置６と受信側通信装置７は、通信方式情報に応じた通信方式により、通信を行う。

送信側プロセスは、対象データを分割して制御情報に埋め込むことにより、送信データを生成する。

以下、送信側情報処理装置２と受信側情報処理装置３の処理について具体的に説明する。送信側プロセス（送信プロセス）と受信側プロセス（受信プロセス）は、プロセス間データ通信手順を用いて通信を行う。プロセス間データ通信手順は、送信側プロセスと受信側プロセスとの間で、ペイロード情報（通信データ）と、ペイロード情報の通信を制御するための制御情報（ディスクリプタ）の通信を行うプロセス間通信の手順である。プロセス間データ通信手順において、受信側情報処理装置３では、送信側プロセスから受信したペイロード情報は格納領域（バッファ）に格納され、受信した制御情報は受信順に管理される。

送信側プロセスは、プロセス間データ通信手順を用いて受信側プロセスと通信を行う。送信側プロセスは、プロセス間データ通信手順を用いて、ペイロード情報と、制御情報とを受信側プロセスに送信する。ここでペイロード情報は、ダミー情報である。制御情報は、ダミー情報に対応付けられる。また制御情報は、データの書換えが可能な第１領域（埋め込み領域）と、受信側プロセスの情報が格納される第２領域とを含む。この第１領域は、第２領域とは異なる領域である。制御情報は第１領域に対象データ（送信対象データ）の少なくとも一部を含む。

受信側プロセスは、ダミー情報と制御情報を送信側プロセスから受信し、受信順に管理される制御情報から対象データの少なくとも一部を取り出す。

これにより、複数のプロセス間通信が同時に発生した場合に、受信側情報処理装置３において、対象データが他のプロセス間通信における通信データにより上書きされることを防ぐことができる。このため、例えば第２−２の方法及び第２−３の方法で説明したような、対象データの上書きを防ぐために発生するプロセス間通信を抑制することができる。また、例えば第２−１の方法で説明したような、データの上書きが発生した場合に行われる再転送のための通信を抑制することができる。また、再転送の制御のための処理等を抑制することができ、再転送の制御のためのバックアップやリカバリの発生を防ぐことができる。

また、実施形態において対象データは、プロセス間データ通信手順においてデータを送信する場合におけるデータのサイズ及び格納位置を示す情報を格納する第１領域に書き込まれる。

これにより、効率的に制御情報に対象データを含ませて、対象データを送信側プロセスから受信側プロセスへ送信することができる。

または、実施形態において対象データは、プロセス間データ通信手順において組み込みデータが格納される第１領域に書き込まれる。

これにより、効率的に制御情報に対象データを含ませて、対象データを送信側プロセスから受信側プロセスへ送信することができる。

また制御情報は、第１領域に、対象データの少なくとも一部と、通信方式を示す通信方式情報（通信種別情報）とを含む。受信側プロセスは、受信した制御情報に含まれる通信方式情報が示す通信の方式に応じて、制御情報から対象データの少なくとも一部を取り出す。

これにより、受信側プロセスは受信した制御情報に、対象データが含まれているか否かを識別することができる。

また制御情報は、第２領域に、送信側プロセスの識別情報を含む。送信側プロセスは、対象データを複数の分割データに分割して、１以上の分割データ、及び、通信種別情報を、複数の制御情報の第１領域に格納する。そして送信側プロセスは、複数の制御情報を受信側プロセスに送信する。受信側プロセスは、制御情報を受信した場合、第１領域に含まれる通信種別情報に応じて、第１領域から分割データを取り出し、第２領域に含まれる識別情報に応じて、複数の制御情報から取り出した分割データを結合して対象データを再構成する。

これにより、送信側プロセスは対象データを複数の制御情報に分割して送信することができる。また受信側プロセスは、受信側情報処理装置３において複数の送信側プロセスとのプロセス間通信が同時に発生した場合にも、複数の制御情報から、各送信側プロセスとの通信毎に、対象データを再構築することができる。

また受信側情報処理装置３においてダミー情報が格納される領域は、複数のプロセス間通信によって共有される固定長のバッファである。

これにより、複数のプロセス間通信が発生した場合に、受信側情報処理装置３のバッファの使用量を削減することができる。

図１２は、実施形態に係る通信ノードの構成の一例を示す。図１２において、通信ノード１８は、記憶部１０、送信制御部１１、設定部１２、送信部１３、受信制御部１４、受信部１５、及び、抽出部１６を含む。記憶部１０、送信制御部１１、設定部１２、及び送信部１３は、データの送信に関する。記憶部１０、受信制御部１４、受信部１５、及び抽出部１６は、データの受信に関する。

通信ノード１８は、送信側情報処理装置２、及び受信側情報処理装置３の一例である。送信制御部１１、設定部１２、及び送信部１３の機能の一部は、送信側演算処理装置４が実行する送信側プロセスの一例である。また送信部１３の機能の一部は、送信側通信装置６の一例である。受信制御部１４、及び抽出部１６は、受信側演算処理装置８が実行する受信側プロセスの一例である。記憶部１０は、送信側情報処理装置２においては、送信側記憶装置５の一例である。また記憶部１０は、受信側情報処理装置３においては、受信側記憶装置９の一例である。受信部１５は、受信側通信装置７の一例である。

記憶部１０には、ＭＰＩ領域、アプリケーション領域、キューが確保される。キューは、例えば、通信ノード１８のOperating System（ＯＳ）が確保するカーネル等の領域に確保される。ＭＰＩ領域には、受信した通信データが格納されるバッファの領域が確保される。

先ず、データの送信処理に関するものについて説明する。
送信制御部１１は、送信対象データのサイズに応じて、プロセス間通信において使用する通信プロトコルを選択する。具体的には例えば、送信制御部１１は先ず、送信対象データのサイズが所定の閾値よりも大きいか否かを判定する。送信対象データのサイズが所定の閾値よりも小さい場合には、送信制御部１１は、送信対象データを通信する際に使用するプロトコルとして、Eagerプロトコルを選択する。一方、送信対象データのサイズが所定の閾値以上の場合には、送信制御部１１は、送信対象データを通信する際に使用するプロトコルとして、Rendezvous-RDMA readプロトコル、または、Rendezvous-RDMA writeプロトコルを選択する。所定の閾値は予め記憶部１０に記憶される。尚、送信対象データの通信で使用される通信プロトコルは、ユーザ端末により指定されてもよい。また送信制御部１１は、選択した通信プロトコルに応じて種々の処理を行う。

また送信制御部１１は、通信データと、通信データに対応するディスクリプタを生成する。ただし実施形態においては、通信データはダミーデータとする。送信制御部１１は、ディスクリプタに通信データ（ダミーデータ）の通信を制御するための通信制御情報を設定する。ダミーデータは、中身に意味がないデータである。ダミーデータのサイズは所定のサイズであってもよく、ダミーデータのサイズを小さくすることで、通信量や通信で使用するバッファの量を小さくすることができる。

設定部１２は、ディスクリプタの領域（フィールド）のうち、値の変更が可能な領域であって、通信データをダミーデータとすることで値の書換えが可能となる領域（以下、埋め込み領域と記す場合がある）に、プロセス間で本来通信したい送信対象データを埋め込む。埋め込み領域は、データの書換えが可能な領域であって、受信プロセスの情報が格納される領域とは異なる領域である。このとき設定部１２は、送信対象データのサイズに応じて、送信対象データを複数の分割データに分割して埋め込み領域に埋め込む。送信対象データの分割において設定部１２は、各分割データのサイズが、埋め込み領域に格納可能なサイズとなるように分割する。尚、１つのディスクリプタに複数の埋め込み領域が含まれ、各ディスクリプタのサイズはそれぞれ異なる場合もあるが、この場合、設定部１２は、各埋め込み領域に分割データが格納されるように、各分割データのサイズを調整して分割する。また設定部１２は、ディスクリプタに送信対象データが含まれているか否かを示す情報である通信種別情報を埋め込み領域に格納してもよい。ディスクリプタに通信データを格納する処理の詳細については、後ほど説明する。

送信部１３は、通信データ（ダミーデータ）と、送信対象データ（分割データ）が埋め込まれたディスクリプタとを、受信ノードに対して送信する。

次に、データの受信処理に関するものについて説明する。
受信制御部１４は、データの受信に先立って、予め固定長のバッファをＭＰＩ領域に確保する。

受信部１５は、通信データ（ダミーデータ）とディスクリプタとを送信ノードから受信する。すると受信部１５は、通信データを固定長のバッファに格納する。ここで通信データを格納する固定長のバッファは、全てのダミー通信で共通して使用されるバッファである。通信データのバッファへの格納が完了すると、受信部１５は、通信データに対応するディスクリプタに基づいて受信完了通知を生成し、キューに格納する。

抽出部１６は、定期的にポーリングを行い、受信完了通知がキューに格納されているか否かを判定する。ポーリングによる監視において、キューに受信完了通知が格納さていることを確認すると抽出部１６は、その受信完了通知がダミー通信において生成されたものであるか否かを判定する。具体的には例えば、抽出部１６は、受信完了通知の埋め込み領域に通信種別情報が含まれているか否かを判定する。受信完了通知に通信種別情報が含まれていることを確認することで抽出部１６は、受信完了通知はダミー通信に関するものであると認識することができる。受信完了通知がダミー通信において生成されたものであると判定した場合、抽出部１６は、受信完了通知から、その受信完了通知に対応するディスクリプタの埋め込み領域に埋め込まれた分割データを抽出する。そして抽出部１６は、抽出した複数の分割データを結合する。

受信完了通知に対応する通信が基本通信かダミー通信かについて、抽出部１６は、ディスクリプタに含まれる、通信データが格納されるバッファの位置を示す情報に基づいて判定してもよい。通信データが格納されるバッファの位置を示す情報が、ダミー通信用の固定長のバッファを示している場合には、抽出部１６は、受信完了通知に対応する通信はダミー通信であると判定してもよい。

分割データの結合は、予め定められた結合規則に基づいて行われる。この結合規則は、記憶部１０の所定の記憶領域に記憶される。尚、結合規則は、送信ノードで送信対象データを分割した分割データをディスクリプタに埋め込む際の規則と対応するものとする。１つの送信対象データに対応する複数の分割データが複数のディスクリプタに跨って送信される場合には、抽出部１６は、受信完了通知の受信順に基づいて、複数の分割データを結合してもよい。尚、例えば、送信ノードは送信対象データの最後に、送信対象データの末尾を示す所定の情報を格納し、抽出部１６は末尾を示す情報が分割データに含まれているか否かを確認することにより、送信対象データの末尾を認識してもよい。

そして抽出部１６は、再構成した通信データを、通信プロトコルに応じて、ＭＰＩ領域、または、アプリケーション領域にコピーする。すなわち、通信プロトコルがEagerプロトコルの場合には、抽出部１６は、送信対象データをアプリケーション領域にコピーする。通信プロトコルがRendezvous-RDMA readまたはRendezvous-RDMA writeの場合には、抽出部１６は、送信対象データ（通信制御に関する情報）をＭＰＩ領域にコピーする。

また、受信制御部１４及び受信部１５は、送信対象データのサイズに応じた通信プロトコルの選択や、選択した通信プロトコルに応じて種々の処理を行う。

次に、設定部１２によるディスクリプタへの送信対象データの埋め込みについて説明する。図１３は、設定部１２によるディスクリプタへの送信対象データの埋め込みについて説明するための図である。

図１３（Ａ）は、基本通信における、ディスクリプタ及び受信完了通知のデータ構成の一例を示す。図１３（Ｂ）は、ダミー通信における、ディスクリプタ及び受信完了通知のデータ構成の一例を示す。

図１３（Ａ）に示すように、ディスクリプタは、複数の領域（フィールド）を有する。ディスクリプタが有する領域は、データの書換えが不可能な領域（以下、書換え不能領域と記す場合がある）と、データの書換えが可能な領域（以下、書換え可能領域と記す場合がある）に分けられる。また、ディスクリプタが有するいくつかの領域は、通信相手に関する情報が格納される。

ダミー通信では、図１３（Ｂ）に示すように、ディスクリプタの領域のうち、次の３つの条件を満たす埋め込み領域の一部に送信対象データが格納される。
（１）データの書換えが可能な領域である
（２）受信完了通知に含まれる情報が格納される領域である
（３）通信相手に関する情報が格納される領域とは異なる領域である
埋め込み領域は、ディスクリプタの仕様に応じて、予め定められる領域である。尚、埋め込み領域の一部に送信対象データが格納されるとしたが、通信に影響が生じないのであれば、埋め込み領域の全部の領域に送信対象データが格納されてもよい。

ダミー通信において、ディスクリプタの埋め込み領域に送信対象データの埋め込みが可能な理由は、通信データがダミーデータであるために、埋め込み領域に本来格納される情報が使用されない情報となるからである。それらの情報は、例えば、通信データのサイズを示す情報や通信データのバッファの位置を示す情報等である。これらの情報は、通信データがダミーデータである場合には、変更されても通信への影響が生じない。

図１３（Ｂ）に示すように、埋め込み領域は、ディスクリプタに複数含まれる場合がある。送信対象データは、各埋め込み領域に格納可能なサイズに分割されて、各埋め込み領域に埋め込まれる。

送信対象データが埋め込まれる領域は、受信完了通知に含まれる情報が格納される領域のうちの何れかの領域である。そのためディスクリプタに埋め込まれた送信対象データは、受信完了通知にも含まれることとなる。受信完了通知に含まれる送信対象データは、抽出部１６によって抽出されて結合される。

図１３（Ｂ）においては、送信対象データは「F1」、「F2」、「F3」に分割されて、ディスクリプタの埋め込み領域に埋め込まれて転送される。そして、受信ノードにおいて、分割されて埋め込まれた「F1」、「F2」、「F3」は、受信完了通知から抽出されて結合される。

送信対象データのサイズは、１つのディスクリプタの埋め込み領域のサイズの合計よりも大きい場合がある。その場合、送信プロセスは、送信対象データを複数のディスクリプタに分割して格納し、受信ノードに送信する。

図１４は、送信対象データが複数のディスクリプタに分割して埋め込まれて、転送される様子を説明するための図である。図１４において、送信対象データのサイズは、１つのディスクリプタの埋め込み領域のサイズの合計よりも大きい。図１４の場合、送信プロセスは、送信対象データを分割して、「F11」〜「F13」のデータを１つのディスクリプタに埋め込んで、受信ノードに送信している。同様に、送信プロセスは「Fx1」〜「Fx3」（2≦x≦n）(nは整数)のデータをそれぞれ１つのディスクリプタに埋め込んで、受信ノードに送信している。

また図１４において抽出部１６は、受信した複数のディスクリプタに対応する各受信完了通知の埋め込み領域から、送信対象データを抽出して結合している。そして抽出部１６は、各受信完了通知の埋め込み領域から抽出して結合した送信対象データを、さらに結合して、元の送信対象データを再構成している。

ここで、抽出部１６は、受信完了通知に含まれる通信相手に関する情報を参照して、受信完了通知に対応する通信相手を識別することができる。よって、複数のプロセス間通信が同時に発生している場合でも、送信プロセス毎に受信完了通知からデータを抽出して結合することができる。

次に、ディスクリプタの構成の詳細について説明する。ディスクリプタは、対応する通信データのプロセス間の通信を制御するために使用される情報である。ディスクリプタは、通信の方法、通信データが格納される通信相手のメモリ上の位置、通信データのサイズ、及び通信相手の位置情報などを含む。

図１５は、ディスクリプタのデータ構造の一例を示す。図１５において、領域５１は、通信の手法に関する情報が格納される。具体的には、領域５１には、パケットの送出間隔やパケットのサイズ等の情報が格納される。「ABC1」、「Remote node address」、「RI」の領域には、通信データの転送先のノード座標情報が格納される。「Embedded data」の領域には、組み込みデータが格納される。組み込みデータはユーザにより自由に書換えが可能なデータである。「Message length」領域には、通信データのサイズが格納される。「Remote steering tag」、「local steering tag」、「Remote steering offset」、「Local steering offset」領域には、通信データの送受信を行うアドレス空間の座標を示す情報が格納される。具体的には、「Remote steering tag」領域には通信相手のノードにおいて、通信データが格納されるバッファの先頭アドレスを示す情報が格納される。また「local steering tag」には、自ノードにおいて、通信データが格納されるバッファの先頭アドレスを示す情報が格納される。「Remote offset」には、通信相手のノードにおいて、通信データが格納されるアドレスを示す情報であって、「Remote steering tag」のアドレスからのオフセット位置により示される情報が格納される。「Local offset」領域には、通信データが格納されるアドレスを示す情報であって、「Local steering tag」のアドレスからのオフセット位置により示される情報が格納される。

受信完了通知は、受信ノードにおいて、受信部１５（通信モジュール）によりディスクリプタに基づいて生成される情報である。受信完了通知は、対応する通信データのバッファへの格納が完了した場合に、受信部１５によりキューに格納される。抽出部１６は、定期的にキューに受信完了通知が格納されているか否かを確認し（ポーリングを行い）、キューに受信完了通知が格納されていることを確認する。その結果、抽出部１６は、通信データがバッファに格納されたことを認識し、バッファにおける通信データの格納位置を把握することができる。

具体的には受信完了通知は、通信相手のノードの座標情報を含む。これは、図１５の「ABC1」、「Remote node address」、「RI」の領域に格納される情報に相当する情報である。また受信完了通知は、組み込みデータの情報を含む。これは、図１５の「Embedded data」領域に格納される情報に相当する情報である。また受信完了通知は、通信データのサイズを示す情報を含む。これは、図１５の「Message length」領域に格納される情報に相当する情報である。さらに受信完了通知は、自プロセス上のデータが到着したアドレス情報を含む。これは、図１５の「Remote steering tag」又は「Remote offset」の領域に格納される情報に相当する情報である。

図１６は、ディスクリプタの埋め込み領域の一例を示す。図１６のディスクリプタの各フィールドは、書換え不能領域、通信相手の情報が格納される領域、埋め込み領域に分けられる。

埋め込み領域は、「Embedded data」、「Message length」、及び「Remote Offset」の領域である。埋め込み領域は、上述した３つの埋め込み領域としての条件を満たしている。尚、各埋め込み領域に埋め込み可能な送信対象データのサイズは、ダミー通信で使用する固定長の受信バッファのサイズ等を調整することにより変化させることもできる。尚、通信相手の情報が格納される領域は、「ABC1」、「Remote node address」、及び「RI」であり、通信相手のノードの座標情報を含む。尚、受信完了通知が格納されるキューが複数使用可能な場合は、どのキューから受信完了通知を受け取ったかということと、送信対象データのビットを関連付けることにより、送信対象データの情報をディスクリプタに含めることもできる。

抽出部１６がキューに格納された受信完了通知を確認した際に、その受信完了通知が基本通信において生成されたものか、ダミー通信において生成されたものかを識別するための通信種別情報は、埋め込み領域に格納されてもよい。具体的には通信種別情報は、例えば、「Embedded data」領域に格納されてもよい。通信種別情報は、基本通信かダミー通信かを示す１ビットの情報であってもよい。また通信種別情報は、さらに、受信完了通知に対応する通信で使用されるプロトコルの種別を示すプロトコル種別情報を含んでもよい。プロトコル種別情報は、Eagerプロトコル、Rendezvous-RDMA readプロトコル、Rendezvous-RDMA writeプロトコルのいずれかの通信であることを示す２ビットの情報であってもよい。

受信完了通知に対応する通信が基本通信かダミー通信かについて、抽出部１６は、「steering tag」の値に基づいて識別してもよい。すなわち抽出部１６は、「steering tag」が示す位置が、ダミー通信用の固定長のバッファを示している場合には、受信完了通知に対応する通信はダミー通信であると判定してもよい。この手法は、通信種別情報を埋め込み領域に埋め込む手法に比べて、埋め込み領域に格納可能な送信対象データのサイズを増やすことができる。これは、ダミー通信においては、予め通信で使用するバッファを所定のアドレスに固定することができるために実現可能な手法である。

ダミー通信においては、１つのノードで複数のプロセス間通信が発生した場合でも、送信対象データが、他のデータに上書きされることにより消失する可能性はない。図７において説明したように、上書きが発生するのは同時に２つ以上のプロセス間通信において、重複する受信バッファに送信対象データが格納される場合である。ダミー通信においては、受信バッファに格納されるのはダミーデータであり、送信対象データは受信バッファではなく、ディスクリプタに埋め込まれた状態でキューに格納される。そのため図７のような通信データの上書きは発生しない。

図１７は、ダミー通信において、２つの送信プロセスが同時に、１つの受信プロセスに対してデータを送信する様子を説明するための図である。図１７において、プロセスＡとプロセスＢは同時に、プロセスＸに対して、それぞれ送信対象データＮ、送信対象データＭを送信するためにダミー通信を行っている。

プロセスＡ（設定部１２）は送信対象データＮを分割して、複数のディスクリプタ（ＤＮ１、ＤＮ２）に埋め込んでいる。そしてプロセスＡ（送信部１３）は、ダミー通信を実行している。プロセスＡ（送信部１３）からダミーデータＡとディスクリプタＤＮ１が送信され、ダミーデータＡは受信ノードＸの受信バッファに格納される。そして、ディスクリプタＤＮ１に基づいて生成された受信完了通知ＤＮ'１がキューに格納される。

同様にプロセスＢ（設定部１２）は送信対象データＭを分割して、複数のディスクリプタ（ＤＭ１、ＤＭ２）に埋め込んでいる。そしてプロセスＢ（送信部１３）は、ダミー通信を実行している。プロセスＢ（送信部１３）からダミーデータＢとディスクリプタＤＭ１が送信され、ダミーデータＢは受信ノードＸの受信バッファに格納される。ディスクリプタＤＭ１に基づいて生成された受信完了通知ＤＭ'１がキューに格納される。ここで、プロセスＢから送信されたダミーデータＢが格納される受信バッファは、ダミーデータＡが格納された受信バッファと同じである。ダミーデータＡは、ダミーデータＢに上書きされることとなるかもしれないが、ダミーデータは参照されないので、通信に影響はない。

プロセスＸ（抽出部１６）は、キューに格納された受信完了通知ＤＮ'１、ＤＭ'１のそれぞれから、送信対象データＮ、Ｍの分割されたデータを抽出する。さらにプロセスＸ（抽出部１６）は、ＤＮ'１、ＤＭ'１の後にキューに格納される受信完了通知ＤＮ'２、ＤＭ'２から送信対象データＮ、Ｍの分割されたデータを抽出する。そしてプロセスＸ（抽出部１６）は抽出したデータを、プロセス（プロセスＡ、プロセスＢ）毎に結合することで、送信対象データＮ、Ｍを取得する。ここで、プロセスＸ（抽出部１６）は、受信完了通知に含まれる通信相手に関する情報を参照して、受信完了通知に対応する通信相手を識別することができる。

受信完了通知は、その受信完了通知に対応するダミーデータがバッファに格納された順に、キューに格納される。このことを利用して抽出部１６は、受信完了通知の格納順に基づいて、複数の受信完了通知に含まれる複数の分割データの結合を制御することもできる。具体的には例えば、先ず、設定部１２は、送信対象データにおける分割データの位置と、分割データを埋め込むディスクリプタの送信順とが対応するように制御する。そして抽出部１６は、受信完了通知の格納順から、受信完了通知に含まれる分割データの、送信対象データにおける位置を特定する。そして抽出部１６は、元の送信対象データが得られるように分割データを結合することで、複数の分割データを正しく結合することができる。

例えば図１７において、ＤＮ１とＤＮ２は、送信対象データＮにおいて、ＤＮ１が先頭側であり、ＤＮ２が末尾側に位置するデータである。このときプロセスＡ（設定部１２）は、ＤＮ１とＤＮ２が含まれるディスクリプタの送信順を、送信対象データにおける位置の順（例えば各分割データの先頭のアドレス順）となるように制御する。プロセスＸ（抽出部１６）は、受信完了通知の格納順に対応するように、各受信完了通知に含まれる分割データを結合する。この場合、ＤＮ１、ＤＮ２の順で受信完了通知がキューに登録されるため、プロセスＸ（抽出部１６）はＤＮ１を先等とし、ＤＮ２をＤＮ１の末尾に結合する。このようにしてプロセスＸ（抽出部１６）は、送信対象データＮを正しく再構成することができる。

ダミー通信において、ダミー通信が格納されるバッファは、複数のプロセス間通信で共有して使用される固定長のバッファである。図１８は、基本通信における第１の方法と、ダミー通信とのバッファの確保のされ方について比較する図である。図１８（Ａ）は、第１の方法においてバッファが確保される様子を示している。図１８（Ｂ）は、ダミー通信においてバッファが確保される様子を示している。

図１８（Ａ）では、通信相手のプロセス（図１８（Ａ）のプロセスＡ〜Ｎ）毎に対応したバッファが確保される。すなわち、プロセス毎に確保されるバッファのサイズであるＮバイト×プロセス数のバッファが確保される。一方、図１８（Ｂ）では、通信相手のすべてのプロセスが共有するバッファが一つ確保される。すなわち、５４４バイトのバッファが確保される。

ダミー通信では、バッファに格納されるデータはダミーデータとなる。そのため複数のプロセスにより格納されたダミーデータは上書きされても通信に支障はない。従って、通信相手のプロセス数が増加しても、バッファ使用量を増加させることなく、通信が可能となる。実施形態では、送信対象データの上書きが発生しないので、送信対象データの上書きに関して発生する制御通信を抑制することができる。実施形態では、通信相手のプロセス数に関わらず、一つの固定長のバッファを共有して使用することができるので、第１の方法に比べてバッファの使用量を削減することができる。尚、図１８（Ｂ）では、固定長のバッファのサイズを５４４バイトとしているがこれは一例であり、固定長のバッファのサイズは５４４バイトに限定されず、プロセス数に依存しない固定の値としてもよい。

次に、実施形態に係る送信ノードの処理のフローについて説明する。図１９は、実施形態に係る送信ノードのダミー通信における処理の詳細を図解したフローチャートの一例である。

図１９において先ず、送信ノードの送信制御部１１は、通信プロトコルの選択を行う（Ｓ１０１）。すなわち送信制御部１１は、送信対象データのサイズに応じて、通信プロトコルを選択する。通信プロトコルを選択すると送信制御部１１は、選択したプロトコルについて受信ノードに通知を行ってもよい。

次に送信制御部１１は、選択された通信プロトコルを確認する（Ｓ１０２）。選択された通信プロトコルがEagerプロトコルであると判定された場合（Ｓ１０２でEagerプロトコル）、処理は送信処理Ａに遷移する（Ｓ１０３）。送信処理Ａの詳細については、後ほど図２０を参照して説明する。送信処理Ａが完了すると、処理は終了する。

Ｓ１０２において、選択された通信プロトコルがRendezvous-RDMA writeプロトコルであると判定された場合（Ｓ１０２でRendezvous-RDMA writeプロトコル）、処理は送信処理Ｂに遷移する（Ｓ１０４）。送信処理Ｂの詳細については、後ほど図２１を参照して説明する。送信処理Ｂが完了すると、処理は終了する。

Ｓ１０２において、選択された通信プロトコルがRendezvous-RDMA readプロトコルであると判定された場合（Ｓ１０２でRendezvous-RDMA readプロトコル）、処理は送信処理Ａに遷移する（Ｓ１０５）。送信処理Ａの詳細については、後ほど図２０を参照して説明する。尚、Ｓ１０５で実行される送信処理Ａの送信対象データは通信制御に関する情報となる。送信処理Ａが完了すると、処理は終了する。

次に、Ｓ１０３、Ｓ１０５、及び後ほど説明するＳ３０１で実行される送信処理Ａについて説明する。図２０は、送信処理Ａの処理の詳細を図解したフローチャートの一例である。

図２０において先ず設定部１２は、送信対象データのサイズに応じて、送信対象データを複数の分割データに分割する（Ｓ２０１）。尚、送信対象データのサイズが１つの埋め込み領域に収まるサイズである場合には、Ｓ２０１は省略できる。

次に送信制御部１１は、通信データとしてのダミーデータと、その通信データに対応するディスクリプタを生成する（Ｓ２０２）。送信制御部１１は、Ｓ２０２においては、生成したディスクリプタの各領域に、通信データを受信ノードに送信するときの設定値を設定しておく。

次に設定部１２は、Ｓ２０２で生成したディスクリプタの埋め込み領域に分割データを埋め込む（Ｓ２０３）。また設定部１２は、ディスクリプタが基本通信におけるものかダミー通信におけるものかを受信ノードにおいて判定することが可能なように、埋め込み領域に通信種別情報を格納してもよい。

そして送信部１３は、ダミー通信を発行する（Ｓ２０４）。すなわち送信部１３は、Ｓ２０２で生成した通信データ（ダミーデータ）と、Ｓ２０３で分割データ（送信対象データ）を埋め込んだディスクリプタとを、受信ノードに送信する。

次に送信制御部１１は、送信対象データの転送が完了したか否かを判定する（Ｓ２０５）。すなわち送信制御部１１は、Ｓ２０１で送信対象データを分割して生成した全ての分割データを、ディスクリプタに埋め込んで送信したか否かを判定する。送信対象データの転送が完了していないと判定すると（Ｓ２０５でＮｏ）、送信制御部１１は、処理をＳ２０２に遷移させ、新たにダミーデータと、ディスクリプタとを生成する。一方、送信対象データの転送が完了したと判定すると（Ｓ２０５でＹｅｓ）、処理は終了する。

次に、Ｓ１０３で実行される送信処理Ｂについて説明する。図２１は、送信処理Ｂの処理の詳細を図解したフローチャートの一例である。

図２１において先ず設定部１２は、送信処理Ａを実行する（Ｓ３０１）。Ｓ３０１で実行される送信処理Ａの通信データは通信制御に関する情報となる。

Ｓ３０１で通信制御に関する情報の転送が完了すると、送信制御部１１は、受信ノードから、ＲＤＭＡ転送のための受信ノードの通信制御に関する情報を受信したか否かを判定する（Ｓ３０２）。受信ノードの通信制御に関する情報を受信していないと判定した場合（Ｓ３０２でＮｏ）、送信制御部１１は、Ｓ３０２の処理を繰り返す。

Ｓ３０２において受信ノードの通信制御に関する情報を受信したと判定すると（Ｓ３０２でＹｅｓ）、送信制御部１１は、RDMA-Writeにより送信対象データを転送する（Ｓ３０３）。すなわち送信制御部１１は、Ｓ３０２で受信した、受信ノードの通信制御に関する情報に基づいて、送信対象データの格納先となる受信ノードのアプリケーション領域のアドレスを指定して、送信対象データを送信する。その結果、送信制御部１１は指定したアプリケーション領域に送信対象データを書き込む。

そして送信制御部１１は、RDMA-Writeの通信の完了通知を受信制御部１４に対して送信する（Ｓ３０４）。そして処理は終了する。

次に、実施形態に係る受信ノードの処理のフローについて説明する。図２２は、実施形態に係る受信ノードのダミー通信における処理の詳細を図解したフローチャートの一例である。

図２２において先ず、受信ノードの受信制御部１４は、通信プロトコルの選択を行う（Ｓ１１１）。すなわち受信制御部１４は、送信対象データのサイズに応じて、通信プロトコルを選択する。通信プロトコルを選択すると受信制御部１４は、選択したプロトコルについて送信ノードに通知を行ってもよい。

次に受信制御部１４は、選択された通信プロトコルを確認する（Ｓ１１２）。選択された通信プロトコルがEagerプロトコルであると判定された場合（Ｓ１１２でEagerプロトコル）、処理は受信処理Ａに遷移する（Ｓ１１３）。受信処理Ａの詳細については、後ほど図２３を参照して説明する。受信処理Ａが完了すると、処理は終了する。

Ｓ１１２において、選択された通信プロトコルがRendezvous-RDMA writeプロトコルであると判定された場合（Ｓ１１２でRendezvous-RDMA writeプロトコル）、処理は受信処理Ｂに遷移する（Ｓ１１４）。受信処理Ｂの詳細については、後ほど図２４を参照して説明する。受信処理Ｂが完了すると、処理は終了する。

Ｓ１１２において、選択された通信プロトコルがRendezvous-RDMA readプロトコルであると判定された場合（Ｓ１１２でRendezvous-RDMA readプロトコル）、処理は受信処理Ｃに遷移する（Ｓ１１５）。受信処理Ｃの詳細については、後ほど図２５を参照して説明する。受信処理Ｃが完了すると、処理は終了する。

次に、Ｓ１１３で実行される受信処理Ａについて説明する。図２３は、受信処理Ａの処理の詳細を図解したフローチャートの一例である。

図２３において先ず、受信制御部１４は、固定長のバッファをＭＰＩ領域に確保する（Ｓ４０１）。ここで確保する固定長のバッファは、すべてのダミー通信において共有して使用されるものである。

次に抽出部１６は、キューに受信完了通知が格納されているか否かを判定する（Ｓ４０２）。キューに受信完了通知が格納されていないと判定した場合（Ｓ４０２でＮｏ）、抽出部１６は再度Ｓ４０２を実行する。

一方、キューに受信完了通知が格納されていると判定した場合（Ｓ４０２でＹｅｓ）、抽出部１６は、キューの先頭から受信完了通知を取り出し、受信完了通知がダミー通信において生成されたものであるか否かを判定する（Ｓ４０３）。具体的には抽出部１６は、受信完了通知に通信種別情報が含まれているか否かを判定する。または抽出部１６は、受信完了通知に含まれる情報であって、通信データが格納されるバッファの先頭アドレスを示す情報が、ダミー通信用の固定長のバッファを示しているか否かを判定する。

受信完了通知がダミー通信において生成されたものであると判定した場合（Ｓ４０３でＹｅｓ）、抽出部１６は、受信完了通知から分割データ（送信対象データ）を抽出する（Ｓ４０４）。

そして抽出部１６は、Ｓ４０４で抽出した分割データを結合する（Ｓ４０５）。すなわち抽出部１６は、Ｓ４０４で抽出した複数の送信対象データを予め定められた結合規則、及び受信完了通知の受信順に基づいて結合する。尚、抽出部１６は、受信完了通知に含まれる通信相手に関する情報を参照して、受信完了通知に対応する送信元プロセスを識別し、通信元プロセス毎に、受信完了通知からデータを抽出して結合する。

次に受信制御部１４は、通信データの転送が完了したか否かを判定する（Ｓ４０６）。すなわち受信制御部１４は、Ｓ４０４で抽出した分割データに、送信対象データの末尾を示す情報が格納されているか否かを判定する。通信データの転送が完了していないと判定した場合（Ｓ４０６でＮｏ）、受信制御部１４は、処理をＳ４０１に遷移させる。通信データの転送が完了したと判定した場合（Ｓ４０６でＹｅｓ）、受信制御部１４は、処理をＳ４０８に遷移する。

Ｓ４０３において、受信完了通知がダミー通信において生成されたものでないと判定した場合（Ｓ４０３でＮｏ）、受信制御部１４は、受信完了通知から通信データが格納されたバッファの位置（アドレス）を特定し、特定した位置にアクセスする（Ｓ４０７）。そして処理は、Ｓ４０８に遷移する。

Ｓ４０８において、受信制御部１４は、通信プロトコルに応じて、ＭＰＩ領域、または、アプリケーション領域に、再構成した送信対象データをコピーする。そして処理は終了する。

次に、Ｓ１１４で実行される受信処理Ｂについて説明する。図２４は、受信処理Ｂの処理の詳細を図解したフローチャートの一例である。

図２４において先ず、受信処理Ａが実行される（Ｓ５０１）。Ｓ５０１で実行される受信処理Ａにおいては、Ｓ４０８で送信対象データはＭＰＩ領域にコピーされる。

次に、受信制御部１４は、送信ノードに対して、受信ノードの通信制御に関する情報を送信する（Ｓ５０２）。この後、通信制御に関する情報に基づいて、送信ノードよりRDMA-Writeにより送信対象データが転送される。そして処理は終了する。

次に、Ｓ１１５で実行される受信処理Ｃについて説明する。図２５は、受信処理Ｃの処理の詳細を図解したフローチャートの一例である。

図２５において先ず、受信処理Ａが実行される（Ｓ６０１）。Ｓ６０１で実行される受信処理Ａにおいては、Ｓ４０８で送信対象データはＭＰＩ領域にコピーされる。

次に、受信制御部１４は、Ｓ４０８でＭＰＩ領域にコピーされた、送信ノードの通信制御に関する情報に基づいて、RDMA-Readにより送信対象データを取得する（Ｓ６０２）。

そして受信制御部１４は、RDMA-Readの通信の完了通知を送信制御部１１に対して送信する（Ｓ６０３）。そして処理は終了する。

次に、実施形態に係る受信部１５のデータの受信処理のフローを説明する。図２６は、実施形態に係る受信部１５のデータの受信処理の詳細を図解したフローチャートの一例である。

図２６において先ず、受信部１５は、送信ノードから通信データと、その通信データに対応するディスクリプタを受信する（Ｓ７０１）。次に受信部１５は、ディスクリプタに基づいて、対応する通信データをバッファに格納する（Ｓ７０２）。そして受信部１５は、ディスクリプタに基づいて受信完了通知を生成し、生成した受信完了通知をキューに格納する（Ｓ７０３）。そして処理は終了する。

次に、実施形態に係る情報処理システムの構成について説明する。図２７は、実施形態に係る情報処理システムのハードウェア構成の一例を示す。

図２７において、情報処理システム３０は、１以上の情報処理装置２０（２０ａ、２０ｂ、２０ｃ）を含む。各情報処理装置２０は、１以上とＰＥ２１（２１ａ、２１ｂ、２１ｃ）と、各ＰＥ２１に接続された通信モジュール２２（２２ａ、２２ｂ、２２ｃ）を含む。ＰＥ２１は、ＣＰＵ２３（２３ａ、２３ｂ、２３ｃ）とメモリ２４（２４ａ、２４ｂ、２４ｃ）を含む。ＣＰＵ２３、メモリ２４、及び通信モジュール２２はそれぞれバス等を介して接続される。各通信モジュール２２は、インターコネクトを介して接続される。また通信モジュール２２の各々は、情報を記憶するストレージ装置（図示せず）と、インターコネクトまたは通信ネットワーク等を介して接続されてもよい。情報処理システム３０は、例えばＬＡＮ等のネットワークを介してユーザ端末２５に接続される。情報処理システム３０は、情報処理システム１の一例である。情報処理装置２０は、通信ノード１８の一例である。

ＣＰＵ２３は、メモリ２４を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、送信制御部１１、設定部１２、送信部１３、受信制御部１４、抽出部１６の機能の一部または全部を提供する。すなわち、ＣＰＵ２３は、メモリ２４を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、送信側情報処理装置２においては、送信側演算処理装置４の機能の一部または全部を提供する。ＣＰＵ２３は、メモリ２４を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、受信側情報処理装置３においては、受信側演算処理装置８の機能の一部または全部を提供する。

メモリ２４は、例えば半導体メモリであり、Random Access Memory（ＲＡＭ）領域およびRead Only Memory（ＲＯＭ）領域を含んで構成される。メモリ２４は記憶部１０の機能の一部または全部を提供する。すなわち、メモリ２４は、送信側情報処理装置２においては、送信側記憶装置５の機能の一部または全部を提供する。またメモリ２４は、受信側情報処理装置３においては、受信側記憶装置９の機能の一部または全部を提供する。

通信モジュール２２は、ＣＰＵ２３の指示に従って、ネットワークまたはインターコネクトを介して通信をおこなうモジュールである。通信モジュール２２は、送信部１３、受信部１５の機能の一部または全部を提供する。すなわち、通信モジュール２２は、送信側情報処理装置２においては、送信側通信装置６の機能の一部または全部を提供する。またメモリ２４は、受信側情報処理装置３においては、受信側通信装置７の機能の一部または全部を提供する。

情報処理装置２０は、読取装置を含んでもよい。読取装置は、ＣＰＵ２３の指示に従って着脱可能記憶媒体にアクセスする。着脱可能記憶媒体は、たとえば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。

実施形態のプログラムは、例えば、下記の形態でＣＰＵ２３に提供される。
（１）メモリ２４に予めインストールされている。
（２）着脱可能記憶媒体（図示せず）により提供される。
（３）プログラムサーバ（図示せず）から通信モジュール２２を介して提供される。

さらに、情報処理装置２０の一部は、ハードウェアで実現してもよい。或いは、情報処理装置２０は、ソフトウェアおよびハードウェアの組み合わせで実現してもよい。

ユーザ端末２５は、情報処理システム３０に対してプログラムの実行指示を送信し、その応答としてプログラムの実行の結果を受信する。プログラムの実行指示は、情報処理システム３０に含まれる１以上のＰＥ２１に対して送信される。１つのプログラムの実行においては、複数のプロセスが実行され、プロセス間でデータ通信が行われる。各プロセスは、１以上のＰＥ２１において実行される。プロセス間通信ではＭＰＩが使用される。プロセス間通信を行う各プロセスは、例えば、通信データの転送量に応じて、プロセス間通信で使用するプロトコル（Eager、Rendezvous-RDMA）を切り替えてもよい。

尚、実施形態においては、受信完了通知が格納される領域をキューとしたが、受信ノードが通信データを受信した順に、通信データに対応する受信完了通知が順次格納され、受信順番が保証されるように制御される領域であれば、キューに限定されない。また、ダミー通信は、同じ通信ノード１８で実行される２つのプロセス間で行われてもよい。

尚、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 情報処理システム
２ 送信側情報処理装置
３ 受信側情報処理装置
４ 送信側演算処理装置
５ 送信側記憶装置
６ 送信側通信装置
７ 受信側通信装置
８ 受信側演算処理装置
９ 受信側記憶装置
１０ 記憶部
１１ 送信制御部
１２ 設定部
１３ 送信部
１４ 受信制御部
１５ 受信部
１６ 抽出部
１８ 通信ノード
２０ 情報処理装置
２１ ＰＥ
２２ 通信モジュール
２３ ＣＰＵ
２４ メモリ
２５ ユーザ端末
３０ 情報処理システム

Claims (8)

1. 送信側情報処理装置と、前記送信側情報処理装置に通信経路を介して接続される受信側情報処理装置とを有する情報処理システムにおいて、
   前記送信側情報処理装置は、
   送信側プロセスを実行する送信側演算処理装置と、
   送信対象である対象データを保持する送信側記憶領域を有する送信側記憶装置と、
   前記送信側プロセスにより、前記対象データと前記対象データの宛先を示す宛先情報とを有する制御情報を含んで生成される送信データを、前記通信経路を介して送信する送信側通信装置を有し、
   前記受信側情報処理装置は、
   前記送信データを、前記通信経路を介して受信する受信側通信装置と、
   受信側プロセスを実行する受信側演算処理装置と、
   前記受信側プロセスにより、前記送信データから抽出される対象データを、記憶する受信側記憶領域を有する受信側記憶装置を有することを特徴とする情報処理システム。
2. 前記送信データはさらに、
   前記制御情報の他に、ペイロード情報を有し、
   前記ペイロード情報は空データであることを特徴とする請求項１記載の情報処理システム。
3. 前記送信データはさらに、
   前記制御情報の他に、ペイロード情報を有し、
   前記ペイロード情報は実データであることを特徴とする請求項１記載の情報処理システム。
4. 前記制御情報はさらに、
   前記宛先情報の他に、前記送信側情報処理装置と前記受信側情報処理装置との間の通信方式を示す通信方式情報を有し、
   前記送信側通信装置と前記受信側通信装置は、前記通信方式情報に応じた通信方式により、通信を行うことを特徴とする請求項１〜３のいずれか一項に記載の情報処理システム。
5. 前記送信側プロセスは、
   前記対象データを分割して前記制御情報に埋め込むことにより、前記送信データを生成することを特徴とする請求項１〜４のいずれか一項に記載の情報処理システム。
6. 他の情報処理装置に通信経路を介して接続される情報処理装置において、
   前記情報処理装置は、
   プロセスを実行する演算処理装置と、
   送信対象である対象データを保持する記憶領域を有する記憶装置と、
   前記プロセスにより、前記対象データと前記対象データの宛先を示す宛先情報とを有する制御情報を含んで生成される送信データを、前記通信経路を介して送信する通信装置を有することを特徴とする情報処理装置。
7. 送信側情報処理装置と、前記送信側情報処理装置に通信経路を介して接続される受信側情報処理装置とを有する情報処理システムの制御方法において、
   前記送信側情報処理装置が有する送信側演算処理装置が、送信側プロセスを実行し、
   前記送信側プロセスにより、前記送信側情報処理装置が有する送信側記憶装置の送信側記憶領域に保持された送信対象である対象データと、前記対象データの宛先を示す宛先情報とを含む制御情報を有する送信データを生成し、
   前記送信側情報処理装置が有する送信側通信装置が、前記送信データを、前記通信経路を介して送信し、
   前記受信側情報処理装置が有する受信側通信装置が、前記送信データを、前記通信経路を介して受信し、
   前記受信側情報処理装置が有する受信側演算処理装置が、受信側プロセスを実行し、
   前記受信側プロセスにより、前記送信データから抽出される対象データを、前記受信側情報処理装置が有する受信側記憶装置の受信側記憶領域に記憶することを特徴とする情報処理システムの制御方法。
8. 他の情報処理装置に通信経路を介して接続される情報処理装置の制御プログラムにおいて、
   前記情報処理装置が有する演算処理装置に、プロセスを実行させ、
   前記プロセスに、前記情報処理装置が有する記憶装置の記憶領域に保持された送信対象である対象データと、前記対象データの宛先を示す宛先情報とを含む制御情報を有する送信データを生成させ、
   前記情報処理装置が有する通信装置に、前記送信データを、前記通信経路を介して送信させることを特徴とする情報処理装置の制御プログラム。