JP2002208981A

JP2002208981A - 通信方法

Info

Publication number: JP2002208981A
Application number: JP2001004399A
Authority: JP
Inventors: Furederiko Mashieru; フレデリコマシエル
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2001-01-12
Filing date: 2001-01-12
Publication date: 2002-07-26
Also published as: US20050050162A1; US6826622B2; US20020095471A1

Abstract

(57)【要約】【課題】ソケットＡＰＩやＭＰＩＡＰＩを使用した
通信の高速化【解決手段】５つの新機能を使用する。（１）受信側
が、アプリケーション・データ２０２での受信と事前割
り振りバッファ２４２での受信のどれが最適かを決定す
るデータ長を送信側知らせる。（２）アプリケーション
・データ２０２の受信アドレスを知らせる効果を計算
し、効果が低い場合に知らせを抑える。（３）８つの通
信方法を可能にする通信プロトコルを使用する。（４）
送受信動作に期待される転送データ長を通信相手にあら
かじめ知らせる。（５）通信パターンにより事前割り振
りバッファ１４２，２４２を変更する（拡大・縮小・追
加・削除等）。【効果】通信を高速化し、処理オーバーヘッドとメモ
リ使用量を減らす。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数の種類の通信
網により接続された複数の計算機を有する計算機システ
ムにおける、計算機間のデータ送受信方法に係り、特に
計算機間メモリ間データ転送の機能を持つネットワーク
とハードウェアの上での計算機間データ送受信方法に関
する。

【０００２】

【従来の技術】計算機間通信、特にインターネットやイ
ントラネットでの通信には、ＴＣＰ／ＩＰプロトコルが
極めて一般的に使用されている。ＴＣＰ／ＩＰ処理をア
プリケーションでなくオペレーティングシステムが行う
ため、アプリケーションがＴＣＰ／ＩＰで通信するため
に「ソケット」と呼ばれるＡＰＩ（Application Progra
mming Interface、アプリケーションがコンピュータや
オペレーティングシステムのある機能を用いるために呼
び出す関数の集合）を用いる（W. Richard Stevens, "U
NIX Network Programming," Prentice Hall, U.S.A., 1
990, ISBN 0-13-949876-1参照）。

【０００３】図１にＴＣＰ／ＩＰプロトコルを使用し通
信するホストのソフトウェア構成例を示す。ホスト１０
はネットワーク１８を使用して通信する。ホスト１０の
オペレーティングシステムのカーネル１２０がＴＣＰ／
ＩＰのプロトコル処理１２１をし、通信ハードウェア１
１を制御して通信する。アプリケーション１００のプロ
グラム１０１がソケットＡＰＩ９０を用い、ライブラリ
１１０を呼び出す。ライブラリがシステムコール１１１
を実行してカーネル１２０を呼び出す。カーネル１２０
がソケット用バッファ１２２を介して、アプリケーショ
ン１００のデータ１０２を送受信する。

【０００４】ＴＣＰ／ＩＰ通信はプロトコル処理１２１
の処理量が多く、そしてシステムコール１１１と、デー
タ１０２とソケットバッファ１２２の間のコピーはオー
バーヘッドとなるため、これらの処理は通信性能を制限
することがある。このため、スーパーコンピュータやワ
ークステーションクラスタのような、高速な通信を必要
とする計算機システムでは、プロトコル処理、システム
コールとデータコピーをせず、カーネルを介さずにアプ
リケーション間データ転送ができるネットワークが用い
られる。本明細書では今後、この通信方法を「高速通
信」と呼ぶ。高速通信の例としてＶＩＡ（Compaq Compu
ter Corp., Intel Corp., Microsoft Corp., "Virtual
Interface Architecture Specification, Draft Revisi
on 1.0," December 4, 1997, http://www.viarch.org参
照）がある。高速通信とＴＣＰ／ＩＰは機能が異なるた
め、これらＡＰＩも異なる。

【０００５】図２に高速通信を使うホストのソフトウェ
ア構成例を示す。アプリケーション１０３のプログラム
１０４が高速通信ＡＰＩ９１を用いて、高速通信ライブ
ラリ１３０を呼び出し、データ１０５を送受信する。高
速通信ライブラリ１３０の通信処理１３１はカーネル１
２０を介さずに高速通信ハードウェア１２を起動しデー
タ１０５を高速通信ネットワーク１９で通信する。高速
通信におけるデータ送受信では、アプリケーション１０
３が送受信したいデータ１０５のアクセス権限があるか
という検査、そしてアプリケーション１０３が指定した
仮想アドレスを高速通信ハードウェア１２が使う物理ア
ドレスへの変換という二つの処理が必要である。このた
めアプリケーション１０３が送受信する前に、高速通信
ライブラリ１３０を呼び出し、送受信するデータ１０５
を登録する（登録されたデータを８０７のような角丸四
角形で示す）。登録処理を高速通信ライブラリの呼び出
し（１３２）でカーネルが行う（１２３）ため、アクセ
ス権限を調査し、権限があった場合にアドレス変換を行
い、登録したデータをメモリ登録テーブル１３に登録す
ることができる。高速通信ハードウェア１２がこのメモ
リ登録テーブル１３を用い、アクセス権限調査とアドレ
ス変換を行う。高速通信ＡＰＩ９１はソケットＡＰＩ９
０と異なるため、ソケットＡＰＩ９０を使うアプリケー
ション１００が高速通信を使用するためには、アプリケ
ーション１００を高速通信ＡＰＩ９１に向けて書き換え
なければならない。この書き換えは難しいため、多くの
アプリケーションが変更されず従来のソケットＡＰＩを
使いつづけ、高速通信の高速性を活用できない。この問
題を解決するために、図３に示す「高速ソケット」とい
う方式を用いる。高速ソケットライブラリ１４０はアプ
リケーション１００のソケットＡＰＩ９０の呼び出しを
受け、エミュレーション処理１４１をし、高速通信を用
い通信する。このため、アプリケーションの互換性を保
ちながら、高速通信の高速性を用いることができる。高
速ソケットの例として、公開特許公報特開平１１−３２
８１３４、Berkeley大学の方式（S. H. Rodrigues, T.
E. Anderson, D. E. Culler, "High-Performance Local
AreaCommunication With Fast Sockets," Proceedings
of the USENIX '97, 1997, pp. 257-274参照）、Shah
らによる方式（H. V. Shah, C. Pu, R. S. Madukkarumu
kumana, "High Performance Sockets and RPC over Vir
tual Interface (VI) Architecture", Proceedings of
CANPC'99, 1999参照）、Microsoft社のWinsock Direct
（"Winsock Direct Specification", Microsoft Window
s Driver Development Kit (DDK) 参照）が挙げられ
る。

【０００６】アプリケーション１００のデータ１０２を
登録（８００）して通信した場合、バッファ登録８００
の処理オーバーヘッド（１３２，１２３）が生じる。デ
ータ長が長い場合にこのオーバーヘッド（１３２，１２
３）は通信時間に比べて短いため、高速性を得られる。
一方、データ長が短いとき、通信時間に比較してこのオ
ーバーヘッドは大きく、通信性能が低下する。この問題
を解決するため高速通信ライブラリ１４０は起動時に、
事前割り振りバッファ１４２をアロケートし登録（８０
１）する。短いデータ１０２を通信するとき、このデー
タ１０２を登録せず事前割り振りバッファ１４２にコピ
ーし通信する。この場合にはコピーのオーバーヘッドが
生じるが、データ長が短くこのオーバーヘッドが登録処
理に比較して少ないため、高速性を得られる。事前割り
振りバッファ１４２は普段送信用バッファと受信用バッ
ファに分かれているが、図３と今後のソフトウェア構成
の図ではこれらをまとめて一つのバッファ１４２として
示す。

【０００７】以上はＴＣＰ／ＩＰ通信と高速ソケットの
説明であった。一般アプリケーションがＴＣＰ／ＩＰ通
信（と、その結果、ソケットＡＰＩ）を用いる一方、科
学技術計算アプリケーションはＭＰＩ（Message Passin
g Interface Forum, "MPI: AMessage-Passing Interfac
e Standard," 1995参照）のようなＡＰＩを用いる。Ｍ
ＰＩは計算機アーキテクチャ非依存のため、高速通信の
上でＭＰＩをインプリメントする場合、ＭＰＩのＡＰＩ
の呼び出しを高速通信のＡＰＩの呼び出しにマッピング
する。この機能を実現する製品としてMPI Software Tec
hnology社のＭＰＩ−Ｐｒｏが挙げられる（R. Dimitrov
and A. Skjellum., "Efficient MPI for Virtual Inte
rface (VI) Architecture," Proceedings of the 1999
International Conference on Parallel and Distribut
ed Processing Techniques andApplications, Las Vega
s, Nevada, U.S.A., June 1999, Vol.6, pp. 3094-3100
参照）。図４にＭＰＩの実現方法を示す。図４では、Ｍ
ＰＩを使用するアプリケーション１０６のプログラム１
０７がＭＰＩＡＰＩ９２を利用してデータ１０８を通
信する。ＭＰＩライブラリ１５０がエミュレーション１
５１を行い、上記のマッピングを行う。ＭＰＩ（図４）
の構成は高速ソケット（図３）の構成と同様のため、両
者の通信における課題も同様である。本明細書では記載
がなければ、高速ソケットに説明する方法はＭＰＩにも
当てはまり、またＭＰＩに説明する方法は高速ソケット
にも当てはまる。

【０００８】

【発明が解決しようとする課題】本発明は従来の高速ソ
ケットライブラリ１４０やＭＰＩライブラリ１５０のよ
うな通信ライブラリの５つの問題を解決する（下記にこ
れらのライブラリを「エミュレーションライブラリ」と
呼ぶ）。ここではこれらの問題を概説して、必要な場合
に発明の実施の形態の説明ではこれらの問題の詳細な説
明をしてから本発明の解決手段を説明する。第一の問題
は次のとおりである。従来方式では送信ホストがデータ
長により、送信ホストにデータ１０２，１０８を登録
（８００，８０８）した通信と事前割り振りバッファ１
４２，１５２にコピーした通信のどちらが最適かを選択
するが、受信ホストにどちらが最適かを考慮しない。こ
のため、受信ホストの受信処理性能を低下する。

【０００９】第二の問題は次のとおりである。受信ホス
トで受信呼び出しが受信データよりを先行した場合、受
信ホストが受信データ１０２，１０８領域を登録（８０
０）してこのアドレスとデータ長を通信相手に知らせる
ことができる。しかし、送信ホストが送信開始後にこの
知らせを受信した場合、この知らせは無駄となり、送信
ホストと受信ホストの処理オーバーヘッドとなり、ネッ
トワークバンド幅を占めるため、システム全体の処理性
能を低下する。

【００１０】第三の問題は次のとおりである。従来方式
は送信ホストからのデータ書き込みと受信ホストからの
データ読み出しという二つのデータ転送方法と、受信ホ
ストと送信ホストそれぞれのデータ１０２，１０８を登
録（８００，８０８）した通信と事前割り振りバッファ
１４２，１５２にコピーした通信の４つの組み合わせ、
全体で８つの組み合わせを全て利用することができな
い。このため、高速通信を可能にするネットワークの性
能を最大限に向上できない。

【００１１】第四の問題は次のとおりである。従来方式
は通信相手にもかかわらず同じ通信方法を使用する。し
かし、今後は通信相手がサーバ等のコンピュータでな
く、ｉＳＣＳＩ（ＴＣＰ／ＩＰ上ＳＣＳＩプロトコル、
J. Satran et alli., "iSCSI (Internet SCSI)," Inter
net Engineering Task Force Internet-Draft draft-sa
tran-iscsi-01.txt, July 10, 2000参照）を使用してい
るストレージ装置であることが考えられる（本発明で
は、通信する装置を種類にかかわらず「ホスト」と呼
ぶ）。ストレージ装置はコンピュータに比較して事前割
り振りバッファ１４２に使用できるメモリ量が制限され
ており処理性能が低いことがあるため、上記第三の問題
に述べた８つの組み合わせの一部のみが効率的である。
通信相手の特性により通信方法を制限しないことは、例
えばこの通信相手がストレージ装置の場合には装置の必
要となるメモリなどを増加し、送受信処理を複雑にし装
置の必要な処理能力を高め、コストを高くする。

【００１２】第五の問題は次のとおりである。従来方式
はＴＣＰ／ＩＰ接続確立時に事前割り振りバッファ１４
２，１５２をアロケートし、この後の通信にはバッファ
の大きさ等を変更しない。このため、このＴＣＰ／ＩＰ
接続の特性に必要となるバッファ量を適応することがで
きない。例えば必要な時にバッファの大きさを増加しな
いことは性能を低下する要因になる。そして、事前割り
振りバッファ１４２，１５２のような登録（８０１，８
０９）したデータ領域は、データ送受信対象のためスワ
ップアウトできなく、主記憶を占める。このため、バッ
ファの大きさを削減しないことは他のアプリケーション
が使えるメモリを少なくするため性能低下の要因にもな
る。

【００１３】

【課題を解決するための手段】第一の問題の解決方法
は、通信するホストが通信相手にデータ１０２，１０８
を登録（８００，８０８）した通信と事前割り振りバッ
ファ１４２，１５２にコピーした通信のどれが最適かを
決定するデータ長を知らせることである。

【００１４】第二の問題の解決方法は、受信ホストが知
らせの効果を計算し、効果が低い場合に知らせを抑える
ことである。

【００１５】第三の問題の解決方法は、８つの組み合わ
せを可能にする通信プロトコルである。

【００１６】第四の問題の解決方法は、送受信動作に期
待される転送データ長を通信相手に知らせることであ
る。

【００１７】第五の問題の解決方法は通信パターンによ
るバッファの変更である。

【００１８】

【発明の実施の形態】＜＜第一の問題の解決方法＞＞こ
の問題の解決方法の説明としてまず、従来方式を説明す
る。図５にＭＰＩ−Ｐｒｏの通信方法を示す。（今後、
通信方法の図を理解しやすくするために、図３と図４の
アプリケーション１００，１０６とエミュレーションラ
イブラリ１４０，１５０のみを示す。両ホスト１０，２
０は同様なソフトウェア構成を持つ。そして、片方向の
データ転送のみを示し、左のホストを送信ホスト１０、
右のホストを受信ホスト２０とする。）ＭＰＩ−Ｐｒｏ
は送信側では事前割り振りバッファを利用しなく、アプ
リケーション１０６のデータ１０８から直接送信する。
全ての通信は送信ホスト１０からの書き込みである。デ
ータ長が長い場合にデータ１０８を直接アプリケーショ
ン２０６データ２０８に送信（９００）し、データ長が
短い場合データを受信ホスト２０の事前割り振りバッフ
ァ２５２に送信（９０２）する。ここでは、どちらに送
信するか決定するホストは送信ホスト１０である。

【００１９】スーパーコンピュータの場合、ホスト１
０、２０は普段全て同じ物であるため、送信ホスト１０
は受信ホスト２０のアプリケーションデータ２０８と事
前割り振りバッファ２５２とのどちらに送信すれば最適
かを判断できる。しかし、高速ソケット通信やＭＰＩを
実行するワークステーションクラスタのようにホスト１
０，２０が異なるシステムの場合、ホストによりメモリ
登録動作（１３２，１２３）の時間とメモリコピーの性
能が異なるため、送信ホスト１０だけの判断は不可能で
ある。判断を間違えば受信処理（と、その結果、送信ホ
スト１０と受信ホスト２０を含むシステム全体）の性能
が低下する。

【００２０】以上は従来の技術である。本発明ではこの
問題を解決するために、受信ホストが登録（８０５）し
た通信と事前割り振りバッファ２５２を介した通信のど
れが最適かを決定するデータ長を送信ホストに知らせ
る。知らせるタイミングはまず、高速ソケットでは通信
するホスト１０，２０がソケットＡＰＩ９０でソケット
の接続を確立したとき、ＭＰＩではＭＰＩライブラリ１
５０，２５０の初期化時である（今後、このタイミング
を「通信開始」と呼ぶ）。従来（図６ａ）このタイミン
グで送信するデータ９１０（事前割り振りバッファアド
レスとデータ長等）と一緒に、本発明のデータ長の知ら
せ９１１（図６ｂ）を転送することが考えられる。そし
てもう一つの可能なタイミングとして、ホスト２０が始
めてホスト１０に通信したとき、この情報を追加するこ
とも考えられる。

【００２１】どちらの通信方法が最適かを決定するデー
タ長の設定として、（１）アプリケーション２０６から
の設定、（２）ホスト１０，２０の管理者やユーザやア
プリケーションからの設定、（３）エミュレーションラ
イブラリ１４０，１５０をホスト１０，２０にインスト
ールしたプログラムの設定、などの方法が考えられる
（しかし、これらの方法に限られていない）。

【００２２】以上の発明のため、受信ホスト２０の受信
処理（と、その結果、システム全体）の性能が向上す
る、という効果を得る。

【００２３】＜＜第ニの問題の解決方法＞＞この問題の
解決方法の説明としてまず、従来方式を説明する。図７
に従来方式を示す。受信ホスト２０のアプリケーション
２０６が受信呼び出しを実行し、エミュレーションライ
ブラリ２５０が、アプリケーションデータ２０８に直接
受信することが効率的であることを判断したとき、デー
タ２０８を登録（８０５）して、送信側に受信アドレス
とデータ長を知らせること（９５０）ができる（データ
転送以外、エミュレーションライブラリ１４０，１５
０，２５０は制御メッセージを交換し、このアドレスと
データ長の知らせを制御メッセージとして転送する）。
この場合、送信ホスト１０が送信呼び出しを実行したと
きにデータをこのアドレスに送信して（９５１）、そし
て送信完了の確認メッセージ９５２を送信する。このた
め、送信呼び出しの直後に送信の開始ができる。しか
し、以前述べたとおり、送信ホスト１０が送信開始後に
アドレスの知らせ９５０を受信した場合、この知らせ９
５０は無駄となり、処理オーバーヘッドとなり、ネット
ワークバンド幅を占めるため、システム全体の処理性能
を低下する。

【００２４】以上は従来の技術である。本発明はこの問
題を解決するために、受信ホスト２０がアドレスの知ら
せ９５０の効果を計算し、効果が低い場合に知らせを抑
える。送信したアドレスの知らせ９５０の送信回数に対
して、このアドレスに受信した回数の割合で効果を計算
できる。そして、この効果があるしきい値より低い場
合、アドレスの知らせ９５０の送信を抑える。

【００２５】上記の解決方法にはまず、ユーザや管理
者、エミュレーションライブラリ１４０，１５０，２５
０作者かインストールプログラム、あるいはアプリケー
ション２００がしきい値を設定することが考えられる。
そして、全てのアドレスの知らせ９５０をまとめて効果
を計算すること、そして受信アドレス毎に計算するこ
と、の２つの方式が考えられる（後者の場合、効率の悪
い受信アドレスだけに、アドレスの知らせ９５０を抑え
ることができる）。そして、抑える動作として中止（止
めて続けない）と中断（止めた後に続く）が考えられ
る。

【００２６】以上の発明のため、送信ホスト１０と受信
ホスト２０の処理効率を向上し、ネットワークバンド幅
を無駄に占めないため、これらのホスト（と、その結
果、システム全体）の性能が向上する、という効果を得
る。

【００２７】＜＜第三の問題の解決方法＞＞ここではま
ず、従来方式の通信方法を説明する。今後送信個所と受
信個所の組み合わせを示す番号（９００，９０４等）
に、送信ホスト１０からの書き込み（ｗｒｉｔｅ）か受
信ホスト２０からの読み出し（ｒｅａｄ）を加えて各組
み合わせを示す。例えば、以前説明した図５のＭＰＩ−
Ｐｒｏは９００−ｗｒｉｔｅと９０４−ｗｒｉｔｅの２
つの組み合わせのみを使用する。

【００２８】図８にWinsock Directの通信方法を示し、
図９にプロトコルの詳細を示す。Winsock Directではま
ず、送信ホスト１０がデータを事前割振りバッファ１４
２，２４２の間でデータ送信する（９４０，９３０）
（９０３−ｗｒｉｔｅ）。受信ホスト２０が受信したデ
ータをアプリケーション２００のデータ２０２にコピー
する（９０５，９３１、９４２）。データ長が長い場
合、上記で先頭データのみを送信し、残りのデータ１０
２を登録し（８００）、その先頭アドレスを上記の送信
９４０，９３０に加える。受信ホストがデータ２０２を
登録（８０２）する。高速通信ハードウェア１２が受信
ホスト２０からの読み出し通信の機能がある場合、受信
ホスト２０が通信データを読み出す（９３２，９００−
ｒｅａｄ）。一方、受信側からの読み出し通信機能がな
い場合受信ホストが受信領域の先頭アドレスを知らせ
（９４１）、送信ホスト１０がデータを書き込む（９４
３，９００−ｗｒｉｔｅ）。この後、最後に通信をした
ホストが通信完了の確認を送信する（９３３，９４
４）。そして、両ホスト１０，２０がメモリ登録（８０
０，８０２）を解除する。

【００２９】図１０にShahらによる方式の通信方法を示
す。送信ホスト１０はデータ長が短い場合、事前割振り
バッファ１４２，２４２間でデータを送信する（９０３
−ｗｒｉｔｅ）。一方データ長が長い場合データ１０２
を登録（８００）して、受信ホストの事前割り振りバッ
ファ２４２に送信する（９０４−ｗｒｉｔｅ）。

【００３０】以上は従来方式である。本発明は、図１１
に示すとおり、８つの組み合わせを全て利用可能にする
プロトコルを使用する。特にこのプロトコルは従来方式
が利用しなかった９０２−ｒｅａｄ、９０２−ｗｒｉｔ
ｅ、９０３−ｒｅａｄ、９０４ｒｅａｄを可能にする。

【００３１】以下に、本発明の通信方法を説明する。図
１２に送信ホスト１０側のアルゴリズムを示す。まず、
受信したアドレス知らせメッセージがあれば、これらの
メッセージを処理する（７０１）。そして送信データ１
０２，１０８のデータ長を調べ（７０２）、データが長
い場合にメモリを登録（８００，８０８）し（７０
４）、短い場合に事前割り振りバッファ１４２，１５２
にコピーする（７０３）。

【００３２】次に、アドレス知らせメッセージで知らせ
た、受信ホスト２０での宛先アドレスがあれば（７０
５）、送信データを受信ホスト２０のアプリケーション
データ２０２、２０８に書き込み送信する（７０６）
（長いデータ長の場合９００−ｗｒｉｔｅ、短いデータ
長の場合９０２−ｗｒｉｔｅになる）。宛先アドレスが
なければ、受信ホスト２０の事前割り振りバッファ２４
２，２５２への送信が可能か（すなわち、事前割り振り
バッファに空きがあるか）、そして適切か（第一の問題
で説明したとおり、受信ホスト２０がこのデータ長を事
前割り振りバッファ４２，２５２で受信したいか）を調
べる（７０７）。この二つの条件が真であれば、送信ホ
スト１０が事前割り振りバッファ２４２、２５２に書き
込み送信する（７０８）（長いデータ長の場合９０４−
ｗｒｉｔｅ、短いデータ長の場合９０３−ｗｒｉｔｅに
なる）。一方、この二つの条件のどれかが真でなけれ
ば、送信データのアドレス知らせを送信して（７０
９）、受信完了メッセージを待つ（７１０）（長いデー
タ長の場合９００−ｒｅａｄか９０４−ｒｅａｄのどれ
か、短いデータ長の場合９０２−ｒｅａｄか９０３−ｒ
ｅａｄのどれかになる）。最後に、送信データを解放
（７１１）する（長いデータ長の場合登録８００，８０
８を、短いデータ長の場合事前割り振りバッファ１４
２，１５２を解放する）。

【００３３】図１３に受信側のアルゴリズムを示す。ま
ず、事前割り振りバッファ２４２，２５２で受信したデ
ータをコピー（９０５）して、アドレス知らせメッセー
ジがあるかを調べる（７２１）。アドレス知らせメッセ
ージがあった場合（７２２）、データ長を調べる（７２
３）。データ長が長い場合、アプリケーションデータ２
０２，２０８を登録（８０２，８０５）し（７２４）、
送信ホスト１０からデータを読み出す（７２５）（９０
０−ｒｅａｄか９０２−ｒｅａｄのどれかになる）。一
方、データ長が短い場合、受信ホスト２０が事前割り振
りバッファ２４２，２５２にデータを読み出す（７２
６）（９０３−ｒｅａｄか９０４−ｒｅａｄのどれかに
なる）。データ長にもかかわらず、最後に受信完了メッ
セージを送信する（７２７）。

【００３４】アドレス知らせメッセージがなかった場合
（７２２）、データ長を調べる（７２８）。データ長が
短い場合、事前割り振りバッファ２４２，２５２でのデ
ータ受信（９０３−ｗｒｉｔｅか９０４−ｗｒｉｔｅ）
か、アドレス知らせメッセージを待つ（後者の場合、図
１３の処理をスタート７２０から繰り返す）。一方、デ
ータ長が長い場合にはアプリケーションのデータを登録
して（７２９）、この先頭アドレスをアドレス知らせメ
ッセージで送信する（７３０）。送信ホスト１０では送
信処理開始の前にこのアドレス知らせメッセージが受信
されたら、９００−ｗｒｉｔｅと９０２−ｗｒｉｔｅの
どれかの通信になる。一方、受信ホスト２０がこのステ
ップでアドレス知らせメッセージを受信すれば、これは
送信ホスト１０と受信ホスト２０が同時にお互いにアド
レス知らせメッセージを送信したことが分かる。この場
合、送信ホスト１０に送信してもらうために、受信ホス
ト２０がこのデータ転送におけるアドレス知らせメッセ
ージを無視する。

【００３５】以上の発明のため、送信ホスト１０と受信
ホスト２０の間の通信性能が向上し、これらのホスト
（と、その結果、システム全体）の性能が向上する、と
いう効果を得る。

【００３６】＜＜第四の問題の解決方法＞＞ストレージ
装置などのホスト１０，２０はアプリケーションデータ
１０２，２０２，１０８，２０８か通信割り振りバッフ
ァ１４２，１５２，２４２，２５２のどれかしか装備し
ないことが考えられる。第三の問題の解決方法で説明し
た通信アルゴリズムはこの場合にでも使用できる。ある
ホスト１０，２０にアプリケーションデータ１０２，１
０８，２０２，２０８がない場合、このホスト１０，２
０の処理の判断７０２，７２３，７２８をいつも「短
い」とする。逆にあるホスト１０，２０に事前割り振り
バッファ１４２，２４２，１５２，２５２がなければ、
このホストでこれらの判断をいつも「長い」とし、そし
て通信開始にこのホストから図６ａの事前割り振りバッ
ファアドレスを送信しなく、そして通信相手に判断７０
７の「可能かつ適切か」の条件に「存在するか」という
条件を加える。このため、必要でない機能のインプリメ
ントが不要となり、そして事前割り振りバッファ１４
２，２４２，１５２，２５２がない場合このメモリ領域
のアロケーションが不要となり、このアルゴリズムは容
易なインプリメントと資源の節約を可能にする。しか
し、下記に説明する問題が生じる。

【００３７】上記のアルゴリズムを使用しホストとスト
レージ装置が通信している場合、ストレージ装置は必要
でない資源（事前割り振りバッファ１４２，２４２，１
５２，２５２等）をアロケートしない。一方、ホスト側
は通信の特性を理解しないため、例えばデータ転送単位
がいつも長い時にでも事前割り振りバッファ１４２，２
４２，１５２，２５２をアロケートし、メモリを無駄に
する。

【００３８】本発明では上記の問題を解決するために通
信初期化時に期待される転送データ長を使用してライブ
ラリの初期化を行う。この転送データ長を通信相手に知
らせ、およびまたはアプリケーション１００，２００，
１０６，２０６が指定する。この転送データ長が「長
い」か「短い」により、アプリケーションのデータ送受
信が必要か、または事前割り振りバッファ１４２，２４
２，１５２，２５２が必要かを判断できる。

【００３９】以上の発明のため、ホスト１０，２０の間
の通信性能が向上し、メモリを節約するため、これらの
ホスト（と、その結果、システム全体）の性能が向上す
る、という効果を得る。そしてホスト１０，２０に必要
な処理性能とメモリ量だけを装備すればよいため、シス
テムのコストを低下できる、という効果もある。

【００４０】＜＜第五の問題の解決方法＞＞次に本発明
の解決方法を説明する。まず、事前割り振りバッファの
変更は（１）拡大か縮小のサイズ変更、（２）追加か削
除、（３）受信用バッファを送信用にすることか、送信
用バッファを受信用にすること、の３種類がある。

【００４１】ホスト１０，２０は次の動作で変更を決定
することが考えられる。まず、エミュレーションライブ
ラリ１４０，１５０，２４０，２５０の起動時に、サイ
ズの最大値と最小値、そして使用率の上限と下限の値を
設定する。これらの値の設定方法は（１）ライブラリ１
４０，１５０作成時の定数（２）ホスト１０，２０のユ
ーザや管理者やユーザやアプリケーションからの設定、
（３）ライブラリ１４０、１５０，２４０，２５０をホ
スト１０，２０にインストールしたプログラムの設定、
などの方法が考えられる（しかし、これらの方法に限ら
れていない）。そして、通信開始後、送受信動作毎およ
びまたは定期的に送信用事前割り振りバッファ１４２，
１５２と受信用事前割り振りバッファ２４２，２５２の
使用率を調べ、平均使用率を計算する。この平均使用率
が上限を超え、そしてこの事前割り振りバッファ１４
２，２４２，１５２，２５２のサイズが最大限を超えて
いない場合，バッファの拡大や追加を行う。逆に、この
平均使用率が下限を超え、そしてこの事前割り振りバッ
ファ１４２，２４２，１５２，２５２のサイズが最小限
を超えていない場合、バッファの縮小や削除を行う。そ
して送信用バッファにある変更、そして受信用バッファ
にその逆の変更を決定したら、バッファの用途を変更す
る（逆もまた同様である）。例えば、送信用事前割り振
りバッファ１４２，１５２を拡大して受信用事前割り振
りバッファ２４２，２５２を縮小する場合、受信用バッ
ファの一部を送信用にすることが考えられる。

【００４２】受信ホスト２０での事前割り振りバッファ
２４２，２５２を変更した場合、受信ホスト２０が送信
ホスト１０に変更内容を制御メッセージで知らせる必要
がある（逆に、送信ホスト１０の送信用事前割り振りバ
ッファ１４２，１５２の変更を受信ホスト２０に知らせ
る必要はない）。サイズ縮小、バッファ削除と用途変更
の変更知らせメッセージの場合、送信ホストが変更され
る領域にデータを送信しないために、受信ホスト２０が
変更知らせメッセージを送信して、送信ホストが応答し
た後に変更を行う。これら以外の変更を、知らせメッセ
ージを行う前にでも変更が行えられ、そして送信ホスト
の応答が不要である。

【００４３】以上の発明のため、ホスト１０，２０の間
の通信性能が向上し、メモリを節約するため、これらの
ホスト（と、その結果、システム全体）の性能が向上す
る、という効果を得る。そしてホスト１０，２０に必要
なメモリ量だけを装備すればよいため、システムのコス
トを低下できる、という効果もある。

【００４４】＜＜変形例＞＞本発明はすでに記載した実
施の形態あるいはその変形例に限定されるのではなく、
以下に例示する変形例あるいは他の変形例によっても実
現可能であることは言うまでもない。また、上記複数の
実施の形態あるいはその変形例として記載の技術あるい
は以下の変形例の組み合わせによっても実現できる。（１）以上の説明ではデータ１０２，２０２，１０８，
２０８を登録（８００，８０２，８０５，８０６）して
通信した場合、通信完了後に登録を解除すると述べてい
る。しかし、ＭＰＩ−Ｐｒｏと同様に、後で同じアドレ
スのデータが通信された場合に登録を不要にするために
登録を解除しなくキャッシングすることが考えられる。（２）以上のアルゴリズムやプロトコルの説明では通信
完了確認メッセージの送信を示したが、高速通信ハード
ウェア１２や通信プロトコルの機能によりこれらのメッ
セージ、あるいはその一部が不要となる。（３）上記の５つの問題の解決方法を別々に使用するこ
と、あるいは複数同時に組み合わせて使用することがで
きる。

【００４５】なお、本発明を実施するためのプログラム
は、それ単独であるいは他のプログラムと組み合わせ
て、ディスク記憶装置等のプログラム記憶媒体に記憶さ
れた販売することができる。また、本発明を実施するた
めのプログラムは、すでに使用されている通信を行うプ
ログラムに追加される形式のプログラムでもよく、ある
いはその通信用のプログラムの一部を置換する形式のプ
ログラムでもよい。

【００４６】

【発明の効果】以上から明らかなように、通信を高速化
し、処理オーバーヘッドとメモリ使用量を減らすことが
できる。

【図面の簡単な説明】

【図１】ＴＣＰ／ＩＰプロトコルを使用し通信するホス
トのソフトウェア構成を示す図。

【図２】高速通信を使用し通信するホストのソフトウェ
ア構成を示す図。

【図３】高速ソケットを使用し通信するホストのソフト
ウェア構成を示す図。

【図４】ＭＰＩを使用し通信するホストのソフトウェア
構成を示す図。

【図５】ＭＰＩ−Ｐｒｏの通信方法を示す図。

【図６】第一の問題を解決するための、通信方法切り替
えしきい値のデータ長の転送を示す図。

【図７】送信宛先を知らせるためのアドレス知らせメッ
セージとその応答を示す図。

【図８】Winsock Directの通信方法を示す図。

【図９】Winsock Directのプロトコルの詳細を示す図。

【図１０】Shahらによる方式の通信方法を示す図。

【図１１】本発明の通信方法を示す図。

【図１２】本発明の送信側の通信アルゴリズムを示す
図。

【図１３】本発明の受信側の通信アルゴリズムを示す
図。

【符号の説明】

１０：送信ホスト２０：受信ホスト１００，１０３，１０６，２００：アプリケーション１２０：オペレーティング・システム・カーネル１１：通信ハードウェア１２：高速通信ハードウェア。

Claims

【特許請求の範囲】

【請求項１】通信手段を介して情報処理装置間でデータ
を転送する通信方法であり、受信側となるべき第一の情
報処理装置は送信側となるべき第二の情報処理装置に対
し、前記データの受信対象のメモリ領域を連絡するよう
にされた通信方法において、前記第一の情報処理装置は
前記第二の情報処理装置に対し、前記受信対象のメモリ
領域を第二の情報処理装置から指示して該受信対象のメ
モリ領域に前記データを転送する第一の転送動作と、前
記第一の情報処理装置に予め割り振ったバッファ領域を
介して該データを転送する第二の転送動作との何れを選
択すべきかを判定するための転送データ長に関する閾値
を通知することを特徴とする通信方法。
【請求項２】前記閾値は転送のスループットを向上する
ために定められることを特徴とする請求項１の通信方
法。
【請求項３】前記閾値は転送のレイテンシーを削減する
ために定められることを特徴とする請求項１の通信方
法。
【請求項４】前記閾値は転送の処理量を削減するために
定められることを特徴とする請求項１の通信方法。
【請求項５】通信手段を介して情報処理装置間でデータ
を転送する通信方法であり、受信側となるべき第一の情
報処理装置は送信側となるべき第二の情報処理装置に対
し、前記データの受信対象のメモリ領域を連絡するよう
にされた通信方法において、前記第一の情報処理装置は
前記第二の情報処理装置に対し、前記受信対象のメモリ
領域を第二の情報処理装置から指示して該受信対象のメ
モリ領域に前記データを転送する第一の転送動作と、前
記第一の情報処理装置に予め割り振ったバッファ領域を
介して該データを転送する第二の転送動作との何れを選
択すべきかを判定するための転送データ長に関する閾値
を通知し、前記第二の情報処理装置は転送すべきデータ
長が前記閾値を越えるか否かにより前記第一の転送動作
か、第二の転送動作かを決定して前記データを転送する
ことを特徴とする通信方法。
【請求項６】通信手段に接続し、上記の通信手段を介し
て第二情報処理装置からデータを受信し、上記の通信手
段でデータを受信する前に対象のメモリ領域を受信可能
な領域として指示する第一の情報処理装置において、上
記受信可能な領域として指示する動作の処理時間によ
り、あらかじめ割り振って指示したメモリ領域の大きさ
を決定し、上記のメモリ領域の大きさを上記第二情報処
理装置に知らせ、第二情報処理装置に上記メモリ領域の
大きさを超えないデータ長の送信を上記あらかじめ割り
振って指示したメモリ領域に送信してもらい、超えるデ
ータ長の送信に対象のメモリ領域を指示して上記対象の
メモリ領域に送信してもらうことにより、最速の通信方
法を使用することを特徴とする通信方法。
【請求項７】通信手段を介して情報処理装置間でデータ
を転送する通信方法であり、受信側となるべき第一の情
報処理装置は前記データの受信対象のメモリ領域を登録
し、前記受信対象のメモリ領域のアドレスを送信側とな
るべき第二の情報処理装置に対して通知することを特徴
とする通信方法。
【請求項８】前記第一の情報処理装置は、前記受信対象
のメモリ領域の登録が必要か否かを判定し、必要があっ
た時にのみ前記メモリ領域の登録と前記アドレスの第二
の情報処理装置に対する通知とを実行することを特徴と
する請求項７の通信方法。
【請求項９】前記判定は前記アドレスの通知の効率を測
定することにより実行することを特徴とする請求項８の
通信方法。
【請求項１０】通信手段に接続し、上記の通信手段を介
して第二情報処理装置にデータを送信し、上記の通信手
段でデータを送信する前に対象のメモリ領域を送信可能
な領域として指示する第一の情報処理装置において、あ
らかじめ割り振って指示したメモリ領域に送信データを
コピーし、上記コピーしたデータのアドレスとデータ量
を上記第二情報処理装置に知らせ、上記第二情報処理装
置にデータを読み出すことを特徴とする通信方法。
【請求項１１】通信手段に接続し、上記の通信手段を介
して第二情報処理装置にデータを送信し、上記の通信手
段でデータを送信する前に対象のメモリ領域を送信可能
な領域として指示する第一の情報処理装置において、あ
らかじめ割り振って指示したメモリ領域に送信データを
コピーし、上記コピーしたデータを、上記第二情報処理
装置がこの通信に指示したメモリ領域に送信することを
特徴とする通信方法。
【請求項１２】通信相手のメモリアドレスを指定しデー
タを送信できる通信手段に接続し、上記の通信手段を介
して第二情報処理装置からデータを受信する第一の情報
処理装置において、第二情報処理装置がこのデータ転送
に指示しアドレスとデータ量を知らせたメモリ領域か
ら、第一情報処理装置があらかじめ割り振って指示した
メモリ領域に読み出すことを特徴とする通信方法。
【請求項１３】通信手段に接続し、上記の通信手段を介
して複数のデータ転送方法を持つ通信プロトコルで送受
信する第一と第二の情報処理装において、送受信開始
時、第一およびまたは第二の情報処理装が通信相手に平
均転送データ長を知らせ、上記平均転送データ長により
転送方法を選択することを特徴とする通信方法。
【請求項１４】上記転送方法の選択は、対象のメモリ領
域を指示して送受信するか否か、およびまたはあらかじ
め割り振って指示したメモリ領域を介してデータを送受
信するか否かを特徴とする請求項１３の通信方法。
【請求項１５】通信相手のメモリアドレスを指定しデー
タを送受信できる通信相手のメモリアドレスを指定しデ
ータを送信できる通信手段に接続し、上記の通信手段を
介して第二情報処理装置とデータを送受信し、上記の通
信手段でデータを受信する前に対象のメモリ領域を受信
可能な領域として指示し、あらかじめ割り振って指示し
たメモリ領域を介してデータを送受信する第一の情報処
理装置において、上記あらかじめ割り振って指示したメ
モリ領域を変更することを特徴とする通信方法。
【請求項１６】上記変更が上記メモリ領域の拡大および
または縮小であることを特徴とする請求項１５の通信方
法。
【請求項１７】上記あらかじめ割り振って指示したメモ
リ領域は受信用途と受信用途に分かれおり、上記変更が
受信用途のメモリ領域を送信用途にすること、およびま
たは送信用途のメモリ領域を受信用途にすることを特徴
とする請求項１５の通信方法。