JP2000020490A

JP2000020490A - 遠隔手続き呼出し機構またはオブジェクトリクエストブローカ機構を有する計算機、データ転送方法、および転送方法記憶媒体

Info

Publication number: JP2000020490A
Application number: JP10186082A
Authority: JP
Inventors: Yuji Imai; 祐二今井
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1998-07-01
Filing date: 1998-07-01
Publication date: 2000-01-21
Also published as: US6697878B1

Abstract

(57)【要約】【課題】分散コンピューティング環境における遠隔手
続き呼出し機構、またはオブジェクトリクエストブロー
カ機構を有する計算機相互間でのデータ転送遅延を短縮
する。【解決手段】前記計算機において、自計算機の物理メ
モリ領域上のデータを、ネットワークを介して、通信相
手側計算機の物理メモリ上の領域に向けて直接に転送す
る遠隔直接データ転送手段を備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、分散コンピューテ
ィング環境において、遠隔手続き呼出し（ＲＰＣ）機
構、またはオブジェクトリクエストブローカ（ＯＲＢ）
機構を持つ計算機に関し、更に詳しくはシステムエリア
ネットワーク（ＳＡＮ）が有する遠隔直接データ転送
（ＲＤＭＡ）機構を利用して、送信側計算機の物理メモ
リ上の記憶領域のデータを受信側計算機の物理メモリの
記憶領域に直接に転送することが可能な計算機に関す
る。

【０００２】

【従来の技術】本発明は遠隔直接メモリ操作（ＲＤＭ
Ａ、リモートダイレクトメモリアクセス）が可能なシス
テムエリアネットワーク（ＳＡＮ）を相互間の物理通信
路として有し、遠隔手続き呼出し（ＲＰＣ、リモートプ
ロセデュアコール）機構、またはオブジェクトリクエス
トブローカ（ＯＲＢ）機構を有する計算機を対象とする
ものである。

【０００３】ＯＲＢやＲＰＣは、分散コンピューティン
グ環境において計算機、すなわちノードの間にまたがっ
てメソッドの呼出しや、関数の呼出しを行うための機構
である。ＯＲＢは、例えばコルバ（ＣＯＲＢＡ、コモン
オブジェクトリクエストブローカアーキテクチャ）と呼
ばれる分散オブジェクト間通信路の規格の１つにおいて
用いられている。この規格はオブジェクトマネージメン
トグループ（ＯＭＧ）によって制定された業界標準であ
り、ＳｕｎマイクロシステムやＩＢＭ，ＤＥＣ、ネット
スケープなどの様々なベンダによって広く採用されてい
る。

【０００４】ＯＲＢは、クライアントとオブジェクトの
間においてクライアントのリクエストをオブジェクトに
伝えてオペレーションを行わせ、オブジェクトが結果を
返す場合にはその結果をクライアントに返却するもので
ある。

【０００５】図３４はＯＲＢやＲＰＣの仕組の従来例の
説明図である。従来において、ＯＲＢやＲＰＣを使用す
るノードはパケット型通信ネットワークに接続されてい
て、遠隔呼出しのリクエストは例えばインターネット標
準プロトコルとしてのＵＤＰやＴＣＰ／ＩＰのパケット
に分割して配信される。このため、オペレーションシス
テム内のＴＣＰ／ＩＰ処理部により、パケットの分割や
再構成の処理、ハードウェア割込み処理が行われる。Ｒ
ＰＣがＵＤＰを使用する場合には、同様の処理がＲＰＣ
ライブラリによって行われる。このようにパケットに分
割することにより、ネットワークインタフェースカード
（ＮＩＣ）や中継機構を単純化することができ、ＬＡＮ
からＷＡＮまで広範囲なネットワークが利用可能とな
る。

【０００６】ＯＲＢやＲＰＣは、内部データ表現形式が
異なるノードの間や、言語の間でも関数呼出しができる
ように、ネットワークに送り出すデータに対しては標準
的なデータ表現形式、例えばＳｕｎＲＰＣのＸＤＲ（エ
クスターナルデータリプレゼンテーション）、ＣＯＲＢ
ＡのＣＤＲ（コモンデータリプレゼンテーション）のよ
うな表現形式に変換を行っている。

【０００７】近年パケットを用いるネットワークに代わ
って、システムエリアネットワーク（ＳＡＮ）と呼ばれ
るハードウェアが用いられるようになっている。ＳＡＮ
は、送信側が宛先ノードの物理メモリに対してデータを
直接書き込むことが可能であるという特徴と、データの
送受信が確実に行われることがハードウェアで保証され
ているという特徴がある。ＳＡＮプログラムは、送信す
べきデータを物理主記憶上に格納して、ネットワークカ
ードに対して送信データの位置と、受手側のノードの物
理主記憶上にある受信バッファの位置を指定して送信開
始命令を伝えることによって、データの送信が行われ、
高速な処理が可能となる。

【０００８】ＳＡＮでは、システムエリアとして地理的
な制約、例えば“ワンフロア”を設けて、ネットワーク
メディアとしてのファイバやワイヤを高信頼化し、ＮＩ
Ｃをインテリジェント化することによって、高速なデー
タ転送を可能としている。このデータ転送においては、
ネットワークインタフェースカード（ＮＩＣ）がＤＭＡ
コントローラとして動作する。すなわちＣＰＵが送り元
と宛先のアドレスを指定してデータ転送命令をＮＩＣに
出すことにより、リモートダイレクトメモリアクセス
（ＲＤＭＡ）動作が実行される。このＲＤＭＡが一般の
ＤＭＡと異なる点は、アドレスとしてノードの識別子を
含むことである。ノードの識別子が自ノードであれば、
自ノードから出て自ノードに戻るＤＭＡの作用が行われ
ることになり、ＮＩＣは単なるＤＭＡコントローラとし
て動作する。

【０００９】従来、ＳＡＮはメッセージパッシングイン
タフェース（ＭＰＩ）や、パラレルバーチャルマシン
（ＰＶＭ）などのデータストリーム（データが流れる１
本の管）モデル、もしくは共有メモリとして使用されて
いる。これらはおもに科学技術計算の分野で用いられて
いる。

【００１０】ここでＣＯＲＢＡにおける遠隔呼出し処理
の従来例などについて説明する。図３５、図３６は遠隔
呼出し処理のフローチャートである。図３５で送信側に
おいては、プログラムによってプロキシ関数が呼び出さ
れ、送信側プロキシによってリクエストヘッダとボディ
ーの作成、ＣＤＲ形式への変換が行われ、ソケットから
リクエストがＴＣＰ／ＩＰ処理部に送られ、パケットに
分割されてメッセージがネットワークに送出される。

【００１１】受信側においては、ＴＣＰ／ＩＰ処理によ
ってパケットがメッセージに再構成され、受信側スケル
トンによって呼び出すべきオブジェクトが特定され、引
数への逆変換が行われ、呼び出すべき関数が検索され、
関数を実行するスレッドが呼び出されて関数実行に必要
となる引数の値が渡される。

【００１２】図３６で受信側プログラムによって関数
（演算）が実行され、その結果など、リクエスト送信側
への返信メッセージがある場合には、受信側スケルトン
によってリプライヘッダ、ボディーの作成が行われ、ソ
ケットから受信側ＴＣＰ／ＩＰ処理部に送られるメッセ
ージが、パケットに分割されてネットワークに送出され
る。

【００１３】送信側ＴＣＰ／ＩＰ処理部では、パケット
をメッセージに再構成し、送信側リプライ振り分けスレ
ッドによって待機しているスレッドが特定され待機して
いたスレッドが起こされ、送信側プロキシにより引数へ
の逆変換が行われ、送信側プログラムによってその引数
を用いて結果が呼び出される。

【００１４】図３７はＣＤＲ領域の獲得方法の従来例の
説明図である。同図において、ＣＤＲ管理領域の構造
と、ＣＤＲの擬似コードが示されている。図３８はリク
エストメッセージの構造の説明図である。同図において
オフセットの値が６に対するビックエンディアン、リト
ルエンディアンについては後述する。

【００１５】図３９はオブジェクトキーの構造の説明図
である。オブジェクトの存在するホスト名や、サービス
を受け付けるＴＣＰのポート番号などが示される。

【００１６】

【発明が解決しようとする課題】以上説明したように従
来においては、ＯＲＢ機構やＲＰＣ機構を持つ計算機に
おいても、ノード間の通信においてパケット方式を用い
ているために、データのパケットへの分割や再構成の処
理に時間がかかるという問題点があった。また受信側で
パケットの到着毎にハードウェア割込みが必要となるた
め、ネットワークの速度が向上するにつれて、パケット
分割／再構成処理、割込処理、および標準データ形式へ
の変換処理などが全体の遅延に占める割合が大きくな
り、ネットワークメディアだけを高速化してもメディア
の速度向上を生かしきれず、例えばギガビットのイーサ
ネットにおいて３００Mbps程度の速度しか実現できない
という問題点があった。

【００１７】パケットによるネットワークに代わって登
場したＳＡＮを用いても、従来のＯＲＢやＲＰＣはＴＣ
ＰやＵＤＰを下位に使用することを前提とする構造とな
っており、ＳＡＮを用いるとしてもそれはパケット転送
ネットワークとして使用されるか、データストリームモ
デルとして使用されるしかなく、ＳＡＮの特徴を利用す
ることができないという問題点があった。

【００１８】本発明はＳＡＮによる遠隔直接メモリアク
セス（ＲＤＭＡ）を利用することによって、ＯＲＢやＲ
ＰＣ機構を有する計算機の間におけるデータ転送の遅延
の短縮を実現することを目的とする。

【００１９】

【課題を解決するための手段】図１は本発明の原理構成
ブロック図である。同図は分散コンピューティング環境
における遠隔手続き呼出し（ＲＰＣ）機構１、またはオ
ブジェクトリクエストブローカ（ＯＲＢ）機構２を有す
る計算機３の原理構成ブロック図である。

【００２０】図１において遠隔直接データ転送手段４
は、自計算機の物理メモリ領域上のデータを、ネットワ
ークを介して通信相手側計算機上の物理メモリ領域に向
けて直接に転送する、リモートダイレクトメモリアクセ
ス（ＲＤＭＡ）の動作を行うものである。

【００２１】本発明の実施の形態においては、計算機相
互間が例えばシステムエリアネットワーク（ＳＡＮ）５
によって結合され、このネットワークを物理通信路とし
て遠隔直接データ転送手段４によるデータ転送が行われ
る。

【００２２】前述のように、従来は例えばＣＯＲＢＡに
おいてはＣＤＲが共通データ形式として用いられ、デー
タ送信前に必ず共通データ形式への変換が行われたが、
本発明の実施形態においては、送信側と受信側の計算機
内のデータ表現形式が同一の場合には、共通データ形式
への変換を省略することも可能である。

【００２３】この場合、例えば各計算機に、ネットワー
クに接続されている各計算機のデータ表現形式を管理す
るデータ表現形式管理手段を更に備えることによって、
その管理内容に対応してデータ表現形式変換の省略を行
うこともできる。

【００２４】また本発明の実施形態においては、自計算
機と相手側計算機とのデータ表現形式が異なる場合、送
信側で転送データを相手側のデータ表現形式に変換した
後にデータ転送を行うこともできる。この場合にも前述
のデータ表現形式管理手段を更に備えることによって、
その管理内容に対応して表現形式変換後のデータ転送を
行うことも可能である。

【００２５】次に本発明の実施形態においては、自計算
機と相手側計算機とのデータ表現形式が異なる時、相手
側計算機から転送されたデータを自計算機のデータ表現
形式に変換した後に自計算機の物理メモリ領域上に格納
するデータ形式変換手段を更に備えることもできる。こ
の場合に、送信側の遠隔直接データ転送手段４が転送デ
ータを含むメッセージに自計算機側でのデータ表現形式
を添付して転送し、受信側のデータ形式変換手段が添付
されたデータ表現形式への変換を行うことも可能であ
る。

【００２６】さらに、本発明の実施形態においては、計
算機の間での通信コネクションの開始にあたり、自計算
機のデータ表現形式を相手側計算機に通知するデータ表
現形式通知手段を更に備えることも可能である。

【００２７】また本発明の実施形態においては、物理メ
モリ領域上のデータがデータ転送中に仮想記憶のための
２次記憶領域に退避されることを防止するために、例え
ば関数に対する引数によって指定される領域を物理メモ
リ上に固定した状態で、相手側の計算機に向けたデータ
転送が行われる。

【００２８】本発明の異なる実施形態においては、相手
側計算機の遠隔直接データ転送手段４から転送され、あ
らかじめ固定された物理メモリ領域に格納されたデータ
の格納領域を、そのまま自計算機の受信関数／メソッド
に引き渡すデータ引渡し手段を更に備えることも可能で
ある。この場合、相手側計算機からの転送が完了したデ
ータの格納領域の物理メモリ領域への固定を、データ引
渡し手段による受信関数／メソッドへの引渡しに先立っ
て解除するメモリ領域固定解除手段を更に備えることも
可能である。

【００２９】更に本発明の異なる実施形態においては、
相手側計算機から送られた転送データを含むメッセージ
の到着時点でハードウェア割込みを行うと共に、その転
送データを用いて行われる関数／メソッドの処理が軽い
時には、その関数／メソッドの処理を自分自身で実行す
る割込処理手段を更に備えることも可能である。

【００３０】以上のように本発明によれば、例えばシス
テムエリアネットワークを用いて、自計算機の物理メモ
リ領域上のデータをネットワークを介して通信相手側計
算機の物理メモリ領域に向けて直接に転送することが可
能となる。

【００３１】

【発明の実施の形態】図２は、本発明の計算機において
用いられるネットワークインタフェースとしてのメッセ
ージコントローラ（ＭＳＣ）による、リモートダイレク
トメモリアクセス（ＲＤＭＡ）を用いたデータ転送の説
明図である。同図においてＭＳＣ１０によるＲＤＭＡ
は、ＣＰＵによって次のような命令がＭＳＣ１０に発行
されることによって実行される。

【００３２】ＳＥＮＤ（送り元メモリ領域、送り先ノー
ド、送り先メモリ領域）この命令の中での送り元および
送り先のメモリ領域は、オペレーティングシステムカー
ネル１１のダイレクトバーチャルメモリアクセス（ＤＶ
ＭＡ）空間１２内の先頭アドレスと領域の長さで指定さ
れる。ＤＶＭＡ空間１２とは計算機のＩ／Ｏデバイスか
ら見た時の仮想記憶空間であり、物理メモリ１３はこの
空間上にマップすることができる。ＣＰＵは必要に応じ
てこのマップを自由に変更することができる。

【００３３】従って上述のＳＥＮＤ命令が発行される前
に、送信側のＣＰＵはＤＶＭＡ空間１２に送信すべきデ
ータが格納される物理メモリを、また受信側のＣＰＵは
受信データを受け取るこめの物理メモリをマップし、Ｍ
ＳＣ１０からその物理メモリにデータを読み書き可能に
しておく必要がある。

【００３４】一方同じ物理メモリ１３は、ユーザプロセ
ス１４の仮想記憶空間、すなわちユーザＶＭ空間１５に
マップすることが可能である。ユーザ仮想記憶空間１５
は、オペレーティングシステムカーネル側のＤＶＭＡ空
間１２と物理メモリ１３との間とは独立に、物理メモリ
１３との間でマップを行うことが可能である。同一物理
メモリ領域１３をユーザ仮想記憶空間１５とＤＶＭＡ空
間１２とにそれぞれマップすることで、ＣＰＵの間の通
信が可能になる。

【００３５】まず送信側のＣＰＵは物理メモリ１３への
データ書込みを行い、その後ＳＥＮＤ命令を発行する。
送信側と受信側とのノードの間で、ＲＤＭＡによってネ
ットワーク１６を介して、受信側の物理メモリ１３への
データ転送が行われ、受信側ＣＰＵは物理メモリからの
データ読込みを行う。

【００３６】図３、図４は本発明の第１の実施形態とし
てのＣＯＲＢＡにおける遠隔手続き呼出し処理のフロー
チャートである。図３を図３５の従来例と比較すると、
まず送信側ではソケットとＴＣＰ／ＩＰ処理部によるデ
ータ送信の代わりに、ＲＤＭＡによる送信処理が行われ
る点が異なる。

【００３７】まず送信側プロキシにおいて、転送データ
のＣＤＲ形式への変換を含んでリクエストのヘッダとボ
ディーが作成され、図３５と異なって、ＣＤＲバッファ
が物理メモリ領域上のＲＤＭＡ領域として固定された後
に、バッファの内容がＲＤＭＡ送信される。

【００３８】受信側では図３５と異なり、ＲＤＭＡドラ
イバがメッセージ到着割込みを行うことによって処理が
開始される。ＲＤＭＡされたデータが用いられる点以外
は、受信側スケルトンによる処理は図３６におけると基
本的に同じである。

【００３９】図４で受信側プログラムによって関数（演
算）が実行され、受信側から返信メッセージを送る場合
の処理は、受信側スケルトンにおいてリプライのヘッダ
とボディーが作成され、ＣＤＲバッファが物理メモリ領
域上にＲＤＭＡ領域として固定された後に、メッセージ
のＲＤＭＡ転送が行われてＣＤＲ領域が解放される点
と、送信側ＲＤＭＡドライバがＴＣＰ／ＩＰ処理部の代
わりにメッセージの到着割込みを行う点が図３６と異な
っている。

【００４０】前述のように従来のＯＲＢやＲＰＣにおい
ては、送信ノードと受信ノードとにおけるデータ表現形
式の違い、エンディアン、すなわち多バイトの数値のメ
モリ上での表現形式の違いなどを吸収するために、送信
に先立ってデータの共通データ形式への変換が行われて
いた。すなわちＣＯＲＢＡにおいてはＣＤＲ，ＳｕｎＲ
ＰＣにおいてはＸＤＲへのデータ形式の変換が行われて
いた。

【００４１】図５はエンディアンとアラインメントの相
違による数値データのメモリ上での表現形式の相違の説
明図である。同図(a) のオブジェクトに対するメモリ上
での表現形式の相違が、(b) 〜(d) に示されている。

【００４２】本発明の第１の実施形態においては、デー
タの表現形式やエンディアンなどが送信側と受信側のノ
ード（プロセス）において同一であることが判明してい
る場合には、共通データ形式への変換を行うことなく、
データのＲＤＭＡが行われる。

【００４３】また本発明の第１の実施形態においては、
データの表現形式などが送信側のプロセスと受信側のプ
ロセスとで異なる場合には、送信側において受信側プロ
セスのデータ表現形式に変換した後にそのデータを転送
する、すなわちＲＤＭＡを行うこともでき、また逆に送
信側ではデータ表現形式の変換を行うことなくＲＤＭＡ
を行い、受信側において自プロセスの表現形式に変換す
ることもできる。この場合、送信側において転送データ
を含むメッセージに自ノード側でのデータ表現形式を添
付して送ることによって、受信側でのデータ表現形式変
換動作を行うこともできる。

【００４４】また本発明の第１の実施形態においては、
ネットワークに接続された各計算機のデータ表現形式な
どのデータをテーブルとして保持し、メッセージの送り
元、または宛先のノードによってデータ形式変換動作を
変更することも可能である。図６はそのような各ノード
におけるデータ表現形式などを示すテーブルの例であ
る。同図には、ノードアドレスに対応して、エンディア
ンとアラインメントタイプとの相違が示されている。こ
のようなテーブルはあらかじめシステムエリアネットワ
ーク（ＳＡＮ）の管理者によって作成され、全てのノー
ドに保持されるものとする。

【００４５】更に本発明の第１の実施形態においては、
このようなデータ表現形式の相違を調整するために、ノ
ードの間でのコネクションの開始時に各々のデータ表現
形式を交換することにより、その内容に応じてデータ表
現形式の変換動作を行うこともできる。このコネクショ
ン開始時の処理について図７〜図９を用いて説明する。

【００４６】図７は通常時のコネクション開設手順のフ
ローチャートである。送信側プログラムにおいて宛先オ
ブジェクトキーが渡されて、送信側プロキシにおいてそ
のキーから宛先のホスト名、ポート名が抽出され、その
ポートへのコネクションがない場合には、コネクション
開設要求が行われる。このコネクション開設要求は、Ｔ
ＣＰ／ＩＰ処理部によって受信側に送られ、受信側から
のコネクション受託返信を受信することにより、コネク
ションの開設が完了する。なおここではコネクション開
設処理はＴＣＰ／ＩＰ処理部によって、パケットネット
ワークを介して行われる例を説明したが、ＳＡＮによる
ＲＤＭＡを用いて同様の処理を実行することも当然可能
である。

【００４７】図８は図７の開設手順の直後に行われるデ
ータ表現形式交換動作の処理フローチャートである。送
信側プロキシにおいて、自ノードのエンディアン情報、
アラインメント情報の送信が行われ、また相手側からの
エンディアン情報、アラインメント情報を受信すること
により、エンディアン情報とアラインメント情報の交換
が行われる。

【００４８】図９は図８の処理において交換されるメッ
セージの構造である。エンディアン情報、アラインメン
ト情報の長さ、アラインメント情報を含むメッセージが
交換される。

【００４９】前述のように、送信側のノードにおいてデ
ータの表現形式を共通データ形式、例えばＣＯＲＢＡに
おけるＣＤＲの形式に変換したり、受信側のノードで用
いられているデータ表現形式に変換したりすることがあ
る。この場合、変換後のデータを格納すべき固定領域を
物理メモリ上にあらかじめ確保ししおくこともできる。
これによってリクエストヘッダとボディーを作成し、Ｃ
ＤＲ形式に変換した後にＣＤＲバッファを物理メモリ領
域上に固定する場合に比べて、ＲＤＭＡを行うたびに物
理メモリ領域の固定を行うための処理を省略することが
可能となる。またこの領域は１回のリクエストが終われ
ば再利用可能であり、ＯＲＢやＲＰＣの初期化時に一括
して固定したものを何度も利用することが可能である。

【００５０】図１０はそのように送信用ＲＤＭＡ領域を
あらかじめ物理メモリに固定する場合の動作フローの説
明図である。同図において、例えばＯＲＢの初期化時に
送信用ＲＤＭＡ領域が確保され、物理メモリ領域上に固
定された後、図３と同様の処理が行われるが、送信側プ
ロキシの処理が図３とやや異なる、すなわちＣＤＲ管理
領域の獲得として、初期化時に確保された領域から、Ｃ
ＤＲ領域への割付けが行われる。そしてリクエストヘッ
ダ、ボディーが作成され、バッファの内容がＲＤＭＡに
よって転送された後に、ＣＤＲバッファとして獲得され
た領域が次にＲＤＭＡの対象として利用される可能性の
ある領域として解放されて、送信側プロキシの処理を終
了する。

【００５１】次に本発明においては、受信側のノードで
送信側からＲＤＭＡによって転送されたデータを用いて
行われる関数／メソッドの処理が短時間で終ることが確
実な処理については、受信側スケルトンが関数／メソッ
ドを実行する新たなスレッドを呼び出す代わりに、メッ
セージが到着した時点でハードウェア割込みを行う割込
み処理スレッドや、メッセージ受信スレッド自身が処理
を行うことも可能である。これによってメッセージの処
理を行うための新しいスレッドを起動して、処理を受け
渡す必要がなくなる。この場合の処理を本発明の第２の
実施形態として説明する。

【００５２】すなわち、図３の受信側ＲＤＭＡドライバ
によるメッセージ到着割込みの後の受信側スケルトンの
処理の最後で行われる「関数を実行するスレッドを呼出
して引数を渡す」という処理が変更されることになる。
図１１は関数を実行する新しいスレッドを呼び出して、
そのスレッドに処理を行わせるための最終行の「関数を
実行するスレッドを呼出して引数を渡す」という処理の
詳細フローチャートである。

【００５３】同図においてプログラムの初期化時にスレ
ッドがある一定の個数だけ作成され、セマフォで待機さ
せられた後に処理が実行されるが、受信側スケルトンの
処理において、待機しているスレッド１つが選択され、
メッセージが渡された後にロックがはずされる。そして
待機スレッドが関数を実行するスレッドとしてメッセー
ジの処理を継続し、ロックをはずしたスレッドは次のリ
クエストの受信処理に入ることになる。

【００５４】図１２は、受信側で行われる関数／メソッ
ドの処理が軽量である時に、割込み処理スレッド、また
は受信スレッド自身がその処理を行う場合の受信側スケ
ルトンと待機スケルトンとの処理フローチャートであ
る。受信側スケルトンにおいて、リクエストが呼び出そ
うとしているメソッドの処理が軽量であると判定された
場合には、メッセージの処理を行うためにメソッドを呼
び出す処理において、呼び出すスレッド自分自身によっ
てメソッドが実行される。リクエストが呼び出そうとし
ているメソッドの処理が軽量でない場合には、待機して
いるスレッド１つが選択され、メッセージが渡された後
にロックがはずされる。そして受信側スケルトンは次の
リクエスト受信処理に入る。待機スレッドにメッセージ
が渡されてロックがはずされた場合には、メッセージの
処理を行うスレッドと受信スレッドとが独立に継続する
ことになる。

【００５５】図１３はメソッドの処理が軽量が否かを記
録するテーブルの例の説明図である。同図においてテー
ブルにはメソッドのクラス名、メソッド名もしくはメソ
ッドＩＤ、および関数へのポインタに加えて、メソッド
毎にそのメソッドの処理が軽いか重いかを示すライトま
たはヘビーが記録されている。

【００５６】図１３のライト／ヘビー欄の指定は、例え
ばユーザによって行われることができる。ユーザはＯＲ
Ｂを利用したプログラムとしてのコマンドによって、ラ
イト／ヘビー欄にライトまたはヘビーを設定したいメソ
ッドを、モジュール名、インタフェース名、およびメソ
ッド名をコマンド引数とすることによって指定すること
ができる。

【００５７】図１４はこのようなユーザがライトまたは
ヘビーを設定したいメソッド、すなわちコマンドによっ
て指定されるメソッドの例を示す。同図においてライト
またはヘビーが設定されるべきメソッドがモジュール
名、インタフェース名、メソッド名を用いて指定されて
いる。

【００５８】図１５、図１６は図３のメッセージ受信時
の受信側スケルトンの処理において図１４で呼び出され
るメソッドだけが特別扱いされる、第２の実施形態にお
ける遠隔手続き呼出し処理フローチャートである。この
フローチャート内の受信側スケルトンの処理において、
ヘッダ中のメソッド名から呼び出すべき関数が検索され
た後に、その関数が例えばライトを設定すべき対象であ
ると判定された場合には、モジュール名、インタフェー
ス名、メソッド名の逆変換によって、図１３に示したテ
ーブル内の該当メソッドのライト／ヘビー欄がライトに
設定された後に、受信側プログラムによる処理をスキッ
プして、次の受信側スケルトンの処理に移行する。その
ような設定対象でないと判定された場合には指定された
関数を実行するスレッドが呼び出され、引数が渡され
る。

【００５９】図１３のライト／ヘビー欄の設定について
は、上述のようにユーザがコマンドによって指定する方
法以外に、サーバ側のメソッド関数を作成する言語コン
パイラ、リンカー、ＣＯＲＢＡのＩＤＬ（インタフェー
スデフィニションランゲージ）コンパイラがメソッ
ド関数の作成時にそのメソッド関数の処理が軽いか否か
を示すライト／ヘビー情報を作成し、この情報を基にし
て、図１３のテーブルを作成するためのＯＲＢ初期化処
理においてライト／ヘビー情報の内容を設定する方法も
考えられる。

【００６０】この場合には、言語コンパイラ、リンカー
は次のような判定基準を用いて、コンパイル対象のメソ
ッド関数がライトであるかヘビーであるかの判定を行
う。第１の基準として、システムコールを呼び出す可能
性があるライブラリ関数はその処理がヘビーであると判
定する。

【００６１】第２の基準として、メソッド関数の中で外
部関数の呼出しを行っていない場合には処理がライトで
あると判定する。第３の基準として、メソッド関数の中
で外部関数呼出しが行われるときには、全ての呼び出さ
れる関数がライトである場合に限って、そのメソッド関
数自身もライトであると判定する。呼び出される関数の
中に１つでもヘビーのものがある場合には、そのメソッ
ド関数はヘビーと判定する。但し、そのメソッド関数が
自分自身を再帰的に呼び出す場合には、そのメソッド関
数はヘビーと判定する。

【００６２】コンパイラ、リンカーは、プログラム内の
全ての関数についてこれらの判定基準に従ってヘビー／
ライトを判定し、図１３と同じ情報を持つファイルを作
成する。ＩＤＬコンパイラは、スケルトンのルーチンを
作成する時に、これらのヘビー／ライト情報をＯＲＢに
登録するルーチンを生成し、ＯＲＢの初期化時にこのル
ーチンが呼び出され、図１３のライト／ヘビー欄の内容
設定が行われる。

【００６３】本発明においては、送信側から送られるデ
ータが受信側ノードにおいて格納される物理メモリの領
域の大きさを送信側であらかじめ指定し、データ送信に
先立ってその領域を確保しておくような実施形態も可能
である。そのような実施形態を本発明の第３の実施形態
として説明する。

【００６４】図１７は、第３の実施形態において例えば
第２の実施形態におけるコネクション開設手順、すなわ
ち図７、図８の処理の後に実行サレルＲＤＭＡ用バッフ
ァ要求処理のフローチャートである。同図において送信
側プロキシからプリアロケート、すなわち要求する領域
量が送信され、受信側スケルトンにおいて送信側によっ
て希望されたＲＤＭＡ用バッファの獲得とワイヤダウ
ン、すなわちＳＡＮネットワークハードウェアへの接続
が行われ、送信側のバッファ使用権を示すバッファトー
クンが返信され、そのバッファトークンが送信側プロキ
シにおいてバッファトークンのリストに格納される。

【００６５】図１８は、図１７において送信側プロキシ
からバッファ割当て要求のために受信側に送信されるバ
ッファ要求メッセージの構造の例である。また図１９
は、図１８のバッファ要求メッセージに対する受信側か
らのリプライとしての返信メッセージ、すなわちバッフ
ァトークンが含まれる返信メッセージの例である。これ
らのメッセージについて図２０を用いて説明する。

【００６６】図２０は、例えば送信側ノードにおいてコ
ネクション毎に管理される獲得バッファ管理テーブルの
例である。同図においてコネクションの開設時、すなわ
ち初期に、４Ｋバイトのバッファが３２個、８Ｋバイト
が４個、１６Ｋバイトが４個獲得されたことが示されて
いる。この初期における獲得バッファ量については、例
えば製品の出荷時にその推奨値が設定されると共に、ユ
ーザやプログラマがその値をチューニング可能なものと
する。図内の不足と判断する数、および追加単位数につ
いては後述する。なお、リプライメッセージが格納され
るべき送信ノード側のＲＤＭＡ用バッファについても、
同様に受信側からバッファの獲得要求が成され、送信側
からバッファトークンが返信されるので図２０の表は受
信側ノードにも備えられる。

【００６７】図２０内の初期獲得数に対応して、図１８
のメッセージにおけるトークンの数は合計４０、要求す
るバッファのサイズは次のようになる。

【００６８】

【表１】

【００６９】また図１９において返信されるトークンの
数、および獲得バッファの大きさは図１８におけると同
じである。獲得バッファのＲＤＭＡアドレスは、例えば
獲得バッファが先頭アドレスＡからその領域が確保され
るものとして、次のように表現される。

【００７０】〔Ａ，Ａ＋4096，Ａ＋4096×２，・・・，
Ａ＋4096×ｎ，・・・，Ａ＋4096×32，Ａ＋4096×34，
Ａ＋4096×36，・・・〕図２１、図２２は第３の実施形態における遠隔手続き呼
出し処理のフローチャートである。図３、図４の第１の
実施形態におけるフローチャートと比較すると、送信側
プロキシおよび受信側スケルトンによる処理が異なる。
まず送信側プロキシにおいては引数が物理メモリに固定
された後に、リクエストヘッダのみが作成される。そし
てバッファトークンが残っているか否かが判定され、残
っている場合にはリクエストヘッダにトークンが埋め込
まれる。バッファトークンが残っていない場合には追加
バッファトークンのリクエスト処理が行われる。この処
理については図２３で説明する。

【００７１】送信側プロキシではその後バッファトーク
ンの選択、すなわち送信データが受信側のメモリにおい
てどの領域に格納されるべきかを示すバッファトークン
の指定を行った後に、引数をそのトークンが示すスケル
トン側のメモリ領域に書き込むと共に、リクエストヘッ
ダをＲＤＭＡ送信する。

【００７２】受信側スケルトンの処理は、図３と比較す
ると、ＲＤＭＡ送信されたデータのＣＤＲ形式からの逆
変換によって引数を求める処理が行われない点を除い
て、図３におけると同じである。この逆変換の処理が行
われない理由については後述する。

【００７３】受信側からのリプライが必要な場合、図２
２の処理が実行されるが、図４と比較すると受信側スケ
ルトンによる処理が異なる。まず図２２では受信側スケ
ルトンによって返信領域が物理メモリに固定された後
に、リプライヘッダのみが作成される。そしてバッファ
トークンが残っていないか否かが判定され、残っている
場合にはリプライヘッダにトークンが埋め込まれ、ヘッ
ダにメッセージ長が代入された後、返信メッセージがト
ークンによって示されるプロキシ側メモリ領域に書き込
まれ、リプライヘッダのＲＤＭＡ送信が行われる。また
バッファトークンが残っていなかった場合に、図２３に
示す追加バッファトークンリクエスト処理が実行される
ことは前述と同様である。

【００７４】図２３はバッファトークン追加要求処理の
フローチャートである。同図においては、リクエストの
送信側プロキシが追加トークンをリクエストするものと
して処理を説明する。その処理は図１７におけるとほぼ
同様であるが、送信側プロキシは、図２０に示したよう
にその時点で不足と判断する各サイズのバッファ領域の
数に基づいて、追加を要求する各サイズのバッファ領域
の数（単位数）を指定し、プリアロケート、すなわち希
望領域量として受信側に送信する。受信側スケルトンに
おいてその要求量に応じてバッファの獲得が行われ、バ
ッファトークンを含んだリプライが送信側プロキシに送
信され、送信側プロキシではそのバッファトークンをリ
ストに追加して、処理を終了する。

【００７５】前述のように、図２１、図２２に示した第
３の実施形態における処理フローチャートでは、図３、
図４に示した処理フローチャートと送信側プロキシおよ
び受信側スケルトンによる処理が一部異なる。その相違
について図２４、図２５を用いてさらに説明する。

【００７６】図２１において送信側プロキシによって実
行される処理のうちで、バッファトークンによって指定
される受信側のメモリ領域にデータが直接に転送される
点以外に、まず引数が物理メモリに固定された後にリク
エストヘッダのみが作成され、そのＣＤＲ形式への変換
が行われる。

【００７７】そして受信側スケルトンにおいてヘッダの
逆変換が行われるが、ＲＤＭＡされたデータ、すなわち
メッセージのＣＤＲ形式からの逆変換による引数作成処
理は行われず、トークンによって示される領域に書き込
まれた内容と送信側プロキシによって物理メモリに固定
された引数領域の内容は同じものであり、受信側スケル
トンによって行われる最後の処理、すなわち「関数を実
行するスレッドを呼出して引数を渡す」という処理にお
ける引数の領域は、トークンによって示される領域その
ままのものである。

【００７８】これに対して図３では、リクエストボディ
ーもＣＤＲ変換されてＣＤＲバッファの内容がＲＤＭＡ
送信され、そのデータはＣＤＲ形式から逆変換されて引
数領域が作成される。

【００７９】図２４はこの相違を示すものである。(a)
は図３における処理を説明するものであり、ＲＤＭＡ送
信されたデータはＣＤＲ逆変換されながら受信側の関数
に渡すための引数領域にコピーされる形式で、引数領域
が作成され、その領域が受信側の関数によって参照され
ることになる。

【００８０】これに対して(b) の図２１に対応する処理
では、ＲＤＭＡされた内容、すなわちＲＤＭＡ受信バッ
ファの内容がそのまま引数領域として使用されることに
なり、この内容が受信側の関数によって参照されること
になる。このため受信側において、ＲＤＭＡ送信された
引数領域をそのまま受信側の関数、またはメソッドに渡
すことが可能となり、ＲＤＭＡ受信バッファから引数領
域へのコピー操作を省略することが可能となる。

【００８１】送信側においても、同様のコピー操作の削
減が可能である。図２５は送信側におけるコピー処理削
減の説明図である。同図(a) は図３における処理の説明
図である。同図では、例えば２つの引数領域がまとめら
れて、(1) においてＣＤＲ変換された後にＣＤＲバッフ
ァに格納され、(2) において物理メモリにページ固定さ
れ、(3) においてＲＤＭＡ送信され、受信バッファの内
容が(4) においてＣＤＲ形式から逆変換されて引数領域
にコピーされ、(5) において関数から参照されることに
なる。

【００８２】これに対して(b) は図２１における処理を
示し、送信側で２つの引数領域は図のように１つにまと
められるか、あるいはそのままそれぞれ、(1) で物理メ
モリにページ固定され、(2) でＲＤＭＡ送信されて受信
バッファに格納され、(3) において受信側の関数によっ
てその内容が参照される。これによって(a) と比較する
と、ＣＤＲ形式への変換を行いながらその内容をＣＤＲ
バッファに格納するコピー操作を削減することが可能と
なり、また複数の引数領域をまとめることなく１つずつ
ＲＤＭＡ送信することも可能であり、複数の引数領域を
１つにまとめる処理を省略することも可能となる。

【００８３】本発明においては、例えば第３の実施形態
において送信側プロキシによって選択されたバッファト
ークンによって指定される受信側ノードの物理メモリ領
域上のバッファに転送データが格納され、その領域が受
信側での関数を実行するスレッドに渡されて関数の実行
が行われるが、データの受信領域、すなわちバッファの
物理メモリ固定を、データの受信完了時点で、関数を実
行するスレッドに渡す前に解除することも可能である。
そのような実施形態を第４の実施形態として説明する。

【００８４】図２６、図２７は第４の実施形態における
遠隔呼出し処理のフローチャートである。図２６を第３
の実施形態における図２１と比較すると、受信側スケル
トンの処理において、ＲＤＭＡされたデータからヘッダ
が逆変換され、呼び出すべきオブジェクトが特定された
後に、ヘッダ中のメソッド名から呼び出すべき関数を検
索する前に、トークンによって示されるバッファの物理
メモリ固定が解除される。すなわち受信側プログラムに
制御が移る前に受信メッセージ格納領域の物理メモリへ
の固定が解除され、受信データの仮想メモリ領域へのペ
ージアウトを可能にすることによって、物理メモリの使
用効率が改善される。

【００８５】同様に図２７と図２２とを比較すると、図
２７では送信側プロキシの処理においてリプライヘッダ
の中のトークン情報から引数領域の入ったバッファが特
定された後に、バッファの物理メモリ固定解除が行われ
る点が異なっている。これによって送信側ノードにおい
ても物理メモリの使用効率が改善される。

【００８６】この第４の実施形態においては、図２６に
おいて受信側スケルトンによってトークンによって示さ
れるバッファの物理メモリ固定解除が行われる。この解
除すべきバッファの領域、すなわち受信メッセージ格納
領域は、受信側ＲＤＭＡドライバによってメッセージ到
着が検出された時点で、バッファトークンによって示さ
れる領域、すなわち受信メッセージ格納領域として受信
側スケルトンに通知さる。

【００８７】受信側ＲＤＭＡドライバはこの領域の通知
を行うだけであり、バッファの物理メモリ固定解除は受
信側スケルトンによるオペレーションシステムへのシス
テムコール発行によって、システムコールを通じて行わ
れる。このため処理に時間がかかってしまう。そこで受
信側ＲＤＭＡドライバがメッセージの到着時点で、オペ
レーションシステム内の処理として、あらかじめ物理メ
モリ固定解除を行っておくことも可能である。そのよう
な実施形態を本発明の第５の実施形態として説明する。

【００８８】図２８、図２９は第５の実施形態における
遠隔手続き呼出し処理のフローチャートである。まず図
２８を第４の実施形態における図２６と比較すると、図
２６ではトークンによって示されるバッファの物理メモ
リ固定解除が受信側スケルトンによって行われるのに対
して、図２８では受信側ＲＤＭＡドライバが、メッセー
ジ到着の時点でハードウェア割込みを行うと共に、ユー
ザ側に制御を渡す前に、オペレーションシステム内の処
理としてトークンによって示されるバッファの物理メモ
リ固定解除をあらかじめ行っておくことになる。

【００８９】また図２９と図２７とを比較すると、図２
７では送信側プロキシによってリプライメッセージの格
納されたバッファの物理メモリ固定解除が行われるのに
対して、図２９では送信側ＲＤＭＡドライバによってメ
ッセージ到着割込みに続いてバッファの物理メモリ固定
解除が行われることになる。これによって受信側でも送
信側でも、システムコール呼出し回数が減るために、処
理時間を短縮することが可能となる。

【００９０】第３の実施形態として前述したように、本
発明においては図２０の獲得バッファ管理テーブルを用
いて交換しているバッファトークンの数の管理が行われ
る。残っているバッファトークンの数が少なくなった時
には、図２３で説明したように追加のバッファトークン
要求処理が行われるが、バッファトークンの数が少なく
なった時に、ノード間でのメッセージの流量に応じて、
あらかじめ確保しているバッファの領域を増大させる、
すなわちバッファトークンの追加要求処理を行うことも
可能である。そのような発明の実施形態を第６の実施形
態として説明する。

【００９１】図３０、図３１は第６の実施形態における
遠隔手続き呼出し処理のフローチャートである。まず図
３０を第３の実施形態における図２１と比較すると、送
信側プロキシにおいてリクエストヘッダが受信側にＲＤ
ＭＡ送信された後に、リストに残っているトークンがあ
る値より小さいか否かが判定される。このリストに残っ
ているトークンの数は、例えばバッファトークンのリス
トに現在登録されているトークンの数を示すカウンタの
値として管理される。

【００９２】このリストに残っているトークンの数の判
定基準としてのある値は、例えば図２０において不足と
判断する数に相当する。すなわち現在までのメッセージ
の流れ方に応じて、今後の処理のために不足と判断され
るバッファトークンの数よりリストに残っているトーク
ンの数が少ないと判定された時に、追加バッファトーク
ンのリクエスト処理が行われる。この処理は図２３と同
様である。

【００９３】図３１には示していないが、受信側スケル
トンにおいてリプライヘッダをＲＤＭＡ送信した後に、
送信側プロキシにおけると同様にリストに残っているバ
ッファトークンの数がある値より小さいか否かを判定
し、小さい場合にはリプライメッセージ格納用の送信側
物理メモリ領域に対するバッファトークンの追加要求処
理を行うことも当然可能である。

【００９４】図３２は今まで述べた本発明に関する処理
を実行する一般的なコンピュータの構成ブロック図であ
る。同図においてコンピュータは、全体の動作を制御す
る中央処理装置２１、中央処理装置２１によって実行さ
れるプログラムや演算処理されたデータなどを格納す
る、半導体メモリやハードディスク装置などの記憶装置
２２、中央処理装置２１によって実行されるプログラム
やデータが入出力される、キーボードやプリンタなどの
入出力装置２３、ネットワークを介して他のコンピュー
タ装置との間でデータの送受信を行うための外部インタ
フェース装置２４を備え、各構成要素はシステムバス２
５を介して接続されている。記憶装置２２は、本発明の
第１〜第６の実施形態として説明したフローチャートな
どにおいて、データ送信側、または／およびデータ受信
側において必要となるプログラムを記憶し、そのプログ
ラムは中央処理装置２１によって実行される。

【００９５】ここで本発明の処理に必要となるプログラ
ムを可搬型記憶媒体に記憶させ、そのプログラムを例え
ば記憶装置２２に格納することによって、本発明の実行
に必要な処理を行うことも可能である。図３２はこのよ
うなプログラムを記憶させるための、コンピュータによ
って読取り可能な記憶媒体の説明図である。同図におい
てコンピュータ３０は、本体３１と半導体メモリやハー
ドディスクなどのメモリ３２とから構成されており、コ
ンピュータ３０に対しては可搬型記憶媒体３３からプロ
グラムなどをロードすることも、またプログラムサーバ
３４側の記憶装置３５から、ネットワーク回線３６を介
してプログラムなどをロードすることも可能である。

【００９６】本発明の特許請求の範囲の請求項２８，２
９などに記憶されているプログラムや、例えば図３、図
４、図１５，図１６、図２１、図２２、図２６〜図３１
などのフローチャートに示されているプログラムは可搬
型記憶媒体３３に記憶され、コンピュータ３０にそのプ
ログラムをロードすることによって、本発明の処理を実
行することも可能である。この可搬型記憶媒体３３とし
てはメモリカード、フロッピーディスク、ＣＤ／ＲＯ
Ｍ、光ディスク、光磁気ディスクなど市販され、流通可
能な任意の記憶媒体を用いることができる。更に本発明
の処理のためのプログラムなどは、プログラムサーバ３
４側からネットワーク回線３６を介してコンピュータ３
０側に送られ、そのプログラムがロードされることによ
って本発明の処理を実現することも可能である。

【００９７】

【発明の効果】以上詳細に説明したように、本発明によ
れば従来科学技術計算などに用いられていたシステムエ
リアネットワークによる遠隔直接メモリアクセス（ＲＤ
ＭＡ）を利用することによって、オブジェクトリクエス
トブローカ機構や遠隔手続き呼出し機構を有する計算機
の間での、データ転送の遅延短縮を実現することが可能
になり、分散コンピューティング環境におけるデータ処
理の効率化に寄与するところが大きい。

【００９８】また本発明においては、自計算機と通信相
手側計算機とのデータ表現形式が同一の時には、転送デ
ータの共通データ形式、例えばＣＯＲＢＡにおけるＣＤ
Ｒへの変換を省略することや、データ表現形式が異なる
時に送信側の計算機が転送データを相手側のデータ表現
形式に変換した後に転送を行うことや、相手側計算機か
ら転送されたデータの表現形式を自計算機のデータ表現
形式に変換した後に、自計算機の物理メモリ領域上に格
納することもできる。

【００９９】また本発明によれば、自計算機の物理メモ
リ領域上のデータとしての関数のデータを、その関数に
対する引数によって指定される領域を物理メモリ上に固
定した状態で相手側の計算機に向けて直接に転送するこ
とが可能となり、データ転送中に転送すべきデータが仮
想記憶領域に退避されることを防止することが可能とな
る。

【０１００】更に本発明においては、相手側計算機から
送られた転送データを含むメッセージの到着時点で自計
算機に対するハードウェア割込みを行うスレッドが、そ
の転送データを用いて行われる処理が軽い関数／メソッ
ドの処理を自身で実行することも可能となる。

【図面の簡単な説明】

【図１】本発明の原理構成ブロック図である。

【図２】メッセージコントローラによるリモートダイレ
クトメモリアクセスの説明図である。

【図３】本発明の第１の実施形態における遠隔手続き呼
出し処理のフローチャートである。

【図４】本発明の第１の実施形態における遠隔手続き呼
出し処理のフローチャート（続き）である。

【図５】エンディアンとアラインメントの相違によるデ
ータ表現形式の相違の説明図である。

【図６】各ノードにおけるデータ表現形式などを示すテ
ーブルの例である。

【図７】通常時のコネクション開設手順の処理フローチ
ャートである。

【図８】図７の開設手順の直後に行われるデータ表現形
式交換処理のフローチャートである。

【図９】図８のデータ表現形式交換処理において交換さ
れるメッセージの構造を示す図である。

【図１０】送信用ＲＤＭＡ領域をあらかじめ物理メモリ
に固定する場合の処理フローチャートである。

【図１１】関数を実行するスレッドを呼出して引数を渡
す処理の詳細フローチャートである。

【図１２】割込み処理スレッド自身が関数／メソッドの
処理を行う場合のフローチャートである。

【図１３】メソッドの処理が軽いか否かを記録するテー
ブルの例を示す図である。

【図１４】ユーザが処理のライトまたはヘビーを設定し
たいコマンドによって呼び出されるメソッドの例を示す
図である。

【図１５】第２の実施形態における遠隔手続き呼出し処
理のフローチャートである。

【図１６】第２の実施形態における遠隔手続き呼出し処
理のフローチャート（続き）である。

【図１７】バッファトークン要求処理のフローチャート
である。

【図１８】バッファ要求メッセージの構造を示す図であ
る。

【図１９】バッファ要求メッセージに対するリプライメ
ッセージの構造を示す図である。

【図２０】バッファトークンの数を管理するための獲得
バッファ管理テーブルの例を示す図である。

【図２１】第３の実施形態における遠隔手続き呼出し処
理のフローチャートである。

【図２２】第３の実施形態における遠隔手続き呼出し処
理のフローチャート（続き）である。

【図２３】バッファトークン追加要求処理のフローチャ
ートである。

【図２４】受信側ノードにおいて受信データ格納領域を
そのまま関数／メソッドに引き渡す動作の説明図であ
る。

【図２５】図２４に対応する送信側ノードにおける動作
を説明する図である。

【図２６】第４の実施形態における遠隔手続き呼出し処
理のフローチャートである。

【図２７】第４の実施形態における遠隔手続き呼出し処
理のフローチャート（続き）である。

【図２８】第５の実施の形態における遠隔手続き呼出し
処理のフローチャートである。

【図２９】第５の実施の形態における遠隔手続き呼出し
処理のフローチャート（続き）である。

【図３０】第６の実施の形態における遠隔手続き呼出し
処理のフローチャートである。

【図３１】第６の実施の形態における遠隔手続き呼出し
処理のフローチャート（続き）である。

【図３２】本発明に関する処理を実行する一般的なコン
ピュータの構成を示すブロック図である。

【図３３】コンピュータによって読み取り可能な記憶媒
体の例を示す図である。

【図３４】オブジェクトリクエストブローカおよび遠隔
手続き呼出し処理の仕組の従来例を説明する図である。

【図３５】遠隔手続き呼出し処理の従来例のフローチャ
ートである。

【図３６】遠隔手続き呼出し処理の従来例のフローチャ
ート（続き）である。

【図３７】ＣＤＲ領域の獲得方法の従来例を説明する図
である。

【図３８】リクエストメッセージの構造を説明する図で
ある。

【図３９】オブジェクトキーの構造を説明する図であ
る。

【符号の説明】

１遠隔手続き呼出し（ＲＰＣ）機構２オブジェクトリクエストブローカ（ＯＲＢ）機構３計算機（ノード）４遠隔直接データ転送手段５システムエリアネットワーク（ＳＡＮ）１０メッセージコントローラ（ＭＳＣ）１１オペレーティングシステムカーネル１２ダイレクトバーチャルメモリアクセス（ＤＶＭ
Ａ）空間１３物理メモリ１４ユーザプロセス１５ユーザ仮想記憶空間１６ネットワーク

Claims

【特許請求の範囲】

【請求項１】分散コンピューティング環境における遠
隔手続き呼出し（ＲＰＣ）機構、またはオブジェクトリ
クエストブローカ（ＯＲＢ）機構を有する計算機におい
て、自計算機の物理メモリ領域上のデータを、ネットワーク
を介して通信相手側計算機の物理メモリ領域に向けて、
直接に転送する遠隔直接データ転送手段を備えることを
特徴とする遠隔手続き呼出し機構、またはオブジェクト
リクエストブローカ機構を有する計算機。
【請求項２】前記遠隔直接データ転送手段が、前記ネ
ットワークを構成するシステムエリアネットワーク（Ｓ
ＡＮ）を物理通信路としてデータ転送を行うことを特徴
とする請求項１記載の遠隔手続き呼出し機構、またはオ
ブジェクトリクエストブローカ機構を有する計算機。
【請求項３】前記遠隔直接データ転送手段が、自計算
機と相手側計算機とのデータ表現形式が同一の時、転送
データの前記ネットワーク内での共通データ形式への変
換を省略することを特徴とする請求項１、または２記載
の遠隔手続き呼出し機構、またはオブジェクトリクエス
トブローカ機構を有する計算機。
【請求項４】前記遠隔直接データ転送手段が、前記自
計算機の物理メモリ領域のデータを含むメッセージに自
計算機側でのデータ表現形式を添付して転送することを
特徴とする請求項３記載の遠隔手続き呼出し機構、また
はオブジェクトリクエストブローカ機構を有する計算
機。
【請求項５】前記ネットワークに接続されている各計
算機のデータ表現形式を管理するデータ表現形式管理手
段を更に備え、前記遠隔直接データ転送手段が、該データ表現形式管理
手段の管理内容に対応して、前記データ表現形式変換の
省略を行うことを特徴とする請求項３記載の遠隔手続き
呼出し機構、またはオブジェクトリクエストブローカ機
構を有する計算機。
【請求項６】前記遠隔直接データ転送手段が、自計算
機と相手側計算機とのデータ表現形式が異なる時、転送
データを相手側計算機のデータ表現形式に変換した後に
データ転送を行うことを特徴とする請求項１、または２
記載の遠隔手続き呼出し機構、またはオブジェクトリク
エストブローカ機構を有する計算機。
【請求項７】前記ネットワークに接続されている各計
算機のデータ表現形式を管理するデータ表現形式管理手
段を更に備え、前記遠隔直接データ転送手段が、該データ表現形式管理
手段の管理内容に対応して、前記表現形式変化後のデー
タ転送を行うことを特徴とする請求項６記載の遠隔手続
き呼出し機構、またはオブジェクトリクエストブローカ
機構を有する計算機。
【請求項８】前記遠隔直接データ転送手段が、転送デ
ータを相手側計算機のデータ表現形式に変換した後に、
該変化後のデータを自計算機の物理メモリ上に固定され
た領域に格納し、該格納されたデータを相手側計算機に
向けて直接に転送することを特徴とする請求項６記載の
遠隔手続き呼出し機構、またはオブジェクトリクエスト
ブローカ機構を有する計算機。
【請求項９】自計算機と相手側計算機とのデータ表現
形式が異なる時、相手側計算機の遠隔直接データ転送手
段から転送されるデータを自計算機のデータ表現形式に
変換した後に、自計算機の物理メモリ領域上に格納する
データ形式変換手段を更に備えることを特徴とする請求
項１、または２記載の遠隔手続き呼出し機構、またはオ
ブジェクトリクエストブローカ機構を有する計算機。
【請求項１０】前記ネットワークに接続されている各
計算機のデータ表現形式を管理するデータ表現形式管理
手段を更に備え、前記データ形式変換手段が、該データ表現形式管理手段
の管理内容に対応して転送されたデータの表現形式変換
を行うことを特徴とする請求項９記載の遠隔手続き呼出
し機構、またはオブジェクトリクエストブローカ機構を
有する計算機。
【請求項１１】前記遠隔直接データ転送手段が、前記
自計算機の物理メモリ領域上のデータを含むメッセージ
に自計算機側でのデータ表現形式を添付して転送し、前記データ形式変換手段が該添付されたデータ表現形式
への該転送されたデータの変換を行うことを特徴とする
請求項９記載の遠隔手続き呼出し機構、またはオブジェ
クトリクエストブローカ機構を有する計算機。
【請求項１２】自計算と相手側計算機との通信コネク
ションの開始にあたり、自計算機上のデータ表現形式を
相手側計算機に通知するデータ表現形式通知手段を更に
備えることを特徴とする請求項１、または２記載の遠隔
手続き呼出し機構、またはオブジェクトリクエストブロ
ーカ機構を有する計算機。
【請求項１３】前記遠隔直接データ転送手段が、前記
自計算機の物理メモリ領域上のデータとしての関数のデ
ータを、該関数に対する引数によって指定される領域を
物理メモリ上に固定した状態で、相手側の計算機に向け
て直接に転送することを特徴とする請求項１、または２
記載の遠隔手続き呼出し機構、またはオブジェクトリク
エストブローカ機構を有する計算機。
【請求項１４】前記遠隔直接データ転送手段が、前記
自計算機の物理メモリ領域上のデータとしての関数のデ
ータを、該関数に対する引数としての複数の値によって
指定される複数の領域をそれぞれ物理メモリ領域上に固
定した状態で、該複数の領域のデータをそれぞれ相手側
計算機に向けて直接に転送することを特徴とする請求項
１、または２記載の遠隔手続き呼出し機構、またはオブ
ジェクトリクエストブローカ機構を有する計算機。
【請求項１５】前記相手側計算機の遠隔直接データ転
送手段から転送され、あらかじめ固定された物理メモリ
領域に格納されたデータのデータ格納領域をそのまま自
計算機の受信関数／メソッドに引き渡すデータ引渡し手
段を更に備えることを特徴とする請求項１、または２記
載の遠隔手続き呼出し機構、またはオブジェクトリクエ
ストブローカ機構を有する計算機。
【請求項１６】前記相手側計算機からの転送が完了し
たデータの格納領域の物理メモリ領域への固定を、前記
データ引渡し手段による受信関数／メソッドへの引き渡
しに先立って解除するメモリ領域固定解除手段を更に備
えることを特徴とする請求項１５記載の遠隔手続き呼出
し機構、またはオブジェクトリクエストブローカ機構を
有する計算機。
【請求項１７】前記メモリ領域固定解除手段が、前記
相手側計算機から転送されるデータを含むメッセージに
添付された固定解除対象領域の指定に従って、物理メモ
リ領域への固定を解除することを特徴とする請求項１６
記載の遠隔手続き呼出し機構、またはオブジェクトリク
エストブローカ機構を有する計算機。
【請求項１８】通信相手側計算機の物理メモリ上で、
あらかじめ固定され、自計算機から転送されるデータが
格納されるべき領域の容量変化を要求する固定領域容量
変化要求手段を更に備えることを特徴とする請求項１、
または２記載の遠隔手続き呼出し機構、またはオブジェ
クトリクエストブローカ機構を有する計算機。
【請求項１９】前記固定領域容量変化要求手段が、自
計算機から通信相手側計算機への通信量に応じて、前記
領域の容量変化を要求することを特徴とする請求項１８
記載の遠隔手続き呼出し機構、またはオブジェクトリク
エストブローカ機構を有する計算機。
【請求項２０】通信相手側計算機の前記固定領域容量
変化要求手段から送られる要求に対応して、該相手側計
算機から転送されるデータを格納するためにあらかじめ
物理メモリ上に固定する領域の容量を調整する物理メモ
リ固定領域調整手段を更に備えることを特徴とする請求
項１８、または１９記載の遠隔手続き呼出し機構、また
はオブジェクトリクエストブローカ機構を有する計算
機。
【請求項２１】相手側計算機の前記遠隔直接データ転
送手段から送られる転送データを含むメッセージの到着
時点でハードウェア割込みを行うと共に、該転送データ
を用いて行われる関数／メソッドの処理が軽い時、該関
数／メソッドの処理を実行する割込み処理手段を更に備
えることを特徴とする請求項１、または２記載の遠隔手
続き呼出し機構、またはオブジェクトリクエストブロー
カ機構を有する計算機。
【請求項２２】前記転送データを用いて行われる関数
／メソッドの処理が軽いか否かを区別するデータを記憶
する軽量処理記憶手段を更に備え、前記割込み処理手段が該記憶内容に従って処理の軽い関
数／メソッドの処理を実行することを特徴とるす請求項
２１記載の遠隔手続き呼出し機構、またはオブジェクト
リクエストブローカ機構を有する計算機。
【請求項２３】前記軽量処理記憶手段が、前記転送デ
ータを用いて行われる関数／メソッドの処理が軽いか否
かを区別するデータをユーザの指定に従って記憶するこ
とを特徴とする請求項２２記載の遠隔手続き呼出し機
構、またはオブジェクトリクエストブローカ機構を有す
る計算機。
【請求項２４】前記軽量処理記憶手段が、前記処理が
軽いか否かを区別するデータを前記関数／メソッドをコ
ンパイルするコンパイラ／リンカの判定に従って記憶す
ることを特徴とする請求項２２記載の遠隔手続き呼出し
機構、またはオブジェクトリクエストブローカ機構を有
する計算機。
【請求項２５】前記軽量処理記憶手段が、前記処理が
軽いか否かを区別するデータを前記関数／メソッドを実
行時にコンパイルする実行時コンパイラ／リンカの判定
に従って記憶することを特徴とする請求項２２記載の遠
隔手続き呼出し機構、またはオブジェクトリクエストブ
ローカ機構を有する計算機。
【請求項２６】分散コンピューティング環境における
遠隔手続き呼出し（ＲＰＣ）機構、またはオブジェクト
リクエストブローカ（ＯＲＢ）機構を有する計算機にお
けるデータ転送方法であって、自計算機の物理メモリ領域上のデータを、ネットワーク
を介して通信相手側計算機の物理メモリ領域に向けて直
接に転送することを特徴とするデータ転送方法。
【請求項２７】分散コンピューティング環境における
遠隔手続き呼出し（ＲＰＣ）機構、またはオブジェクト
リクエストブローカ（ＯＲＢ）機構を有する計算機にお
けるデータ受信方法であって、通信相手側計算機から自計算機の物理メモリ上の領域に
ネットワークを介してデータが直接に転送された時点で
のハードウェア割込みを受け付け、該転送されたデータの読出し処理を実行することを特徴
とするデータ受信方法。
【請求項２８】分散コンピューティング環境における
遠隔手続き呼出し（ＲＰＣ）機構、またはオブジェクト
リクエストブローカ（ＯＲＢ）機構を有する計算機にお
いて使用される記憶媒体であって、自計算機の物理メモリ領域上のデータを、ネットワーク
を介して通信相手側計算機の物理メモリ領域に向けて直
接に転送させる機能を備えるプログラムを格納した計算
機読出し可能記憶媒体。
【請求項２９】分散コンピューティング環境における
遠隔手続き呼出し（ＲＰＣ）機構、またはオブジェクト
リクエストブローカ（ＯＲＢ）機構を有する計算機にお
いて使用される記憶媒体であって、通信相手側計算機から自計算機の物理メモリ上の領域に
ネットワークを介してデータが直接に転送された時点で
のハードウェア割込みを受け付けさせる機能と、該転送されたデータの読出し処理を実行させる機能とを
備えるプログラムを格納した計算機読出し可能記憶媒
体。