JPH10207724A - 分散アプリケーション実行システム - Google Patents

Abstract

(57)【要約】 【課題】本発明は複数のプロセスから構成される分散ア
プリケーション空間を動的に設営可能な分散アプリケー
ション実行システムを提供することを目的とする。 【解決手段】複数のコンピュータノードがネットワーク
を介して結合された分散処理システム上でノード上に存
在するプロセス間のメッセージ受け渡しを行うアプリケ
ーションを実行する分散アプリケーション実行システム
において、アプリケーションを構成するプロセスの生成
元となるプログラムを識別する第１の識別手段と、第１
の識別手段により識別されたプログラムによって生成さ
れる少なくとも一つのプロセスを識別する第２の識別手
段とを具備し、プロセス間のメッセージ受け渡しは、第
１の識別手段によるプログラムの識別と、第２の識別手
段によるプロセスの識別とによって前記プロセスを特定
して行われる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、個人用コンピュー
タあるいはワークステーション等からなる複数のノード
がネットワークを介して有機的に結合された分散処理シ
ステムにおける分散アプリケーション実行システムに関
する。

【０００２】

【従来の技術】分散システムにおいて実行されるアプリ
ケーションは、ネットワークを介して隔てられた個々の
ノードで生成される複数のプロセスによって構成され
る。プロセスは、実行中にあるプログラムの状態を指
し、単なる命令の列としてのプログラムと区別する。プ
ロセスは、その元となるプログラムをプロセッサが実行
することにより生じる。

【０００３】複数の分散アプリケーションを実行する分
散アプリケーション実行システムを、既存のプロセス間
通信技術、例えば遠隔手続き呼び出し（リモートプロシ
ジャーコール；ＲＰＣ）を用いて実現する場合には、解
決すべき次のような問題がある。すなわち上記ＲＰＣに
おける呼び出し側からのプロシージャの特定は、プログ
ラムの識別によって行われるものとなっている。このこ
とは、複数のプロセスから構成される分散アプリケーシ
ョン空間を動的に設営しようとする際の制約になるとい
う問題点がある。

【０００４】

【発明が解決しようとする課題】したがって本発明は、
複数のプロセスから構成される分散アプリケーション空
間を動的に設営可能な分散アプリケーション実行システ
ムを提供することを目的とする。

【０００５】

【課題を解決するための手段】

（１）本発明の分散アプリケーション実行システムは、
複数のコンピュータノードがネットワークを介して結合
された分散処理システム上で前記ノード上に存在するプ
ロセス間のメッセージ受け渡しを行うアプリケーション
を実行する分散アプリケーション実行システムにおい
て、前記アプリケーションを構成するプロセスの生成元
となるプログラムを識別する第１の識別手段と、前記第
１の識別手段により識別されたプログラムによって生成
される少なくとも一つのプロセスを識別する第２の識別
手段とを具備し、前記プロセス間のメッセージ受け渡し
は、前記第１の識別手段によるプログラムの識別と、前
記第２の識別手段によるプロセスの識別とによって前記
プロセスを特定して行われることを特徴とする。

【０００６】この構成により、上記アプリケーションを
構成するプロセス間のメッセージ受け渡しは、当該アプ
リケーションのプロセスの生成元となるプログラムの識
別ではなくプロセスの識別によって行うことができる。
このため、例えば同一のプログラムから生成された複数
のプロセスを識別してプロセス間のメッセージ受け渡し
を行うことができる。

【０００７】

【発明の実施の形態】以下、図面を参照して本発明によ
る分散アプリケーション実行システムの実施形態を説明
する。まず第１実施形態においては、分散アプリケーシ
ョンを構成する複数プロセス間のメッセージパッシング
（メッセージ受け渡し）を、遠隔手続き呼び出し（ＲＰ
Ｃ）によって実現する場合のシステム構成例について説
明する。また第２実施形態においては、同様に分散アプ
リケーションを構成する複数プロセス間のメッセージパ
ッシングを、いわゆるソケットインタフェースによるプ
ロセス間通信により実現する場合のシステム構成例につ
いて説明する。

【０００８】（第１実施形態）図１は本発明の第１実施
形態に係る分散アプリケーション実行システムの一例を
示す論理構成図である。分散アプリケーション実行シス
テムは、一つあるいは複数の（コンピュータ）ノードを
有するイントラネット及びこれに相当する種々の局所的
なネットワークがインターネットを介して相互に接続さ
れて成る分散処理システム上において分散アプリケーシ
ョンを実行するものである。

【０００９】分散アプリケーション実行システムは、ネ
ットワークを介して隔てられた複数のプロセスのうち、
同図の一点鎖線Ｌによって包含されハッチングで示され
る特定のプロセスをその構成要素としている。また、分
散アプリケーション実行システムは、同空間内において
複数の分散アプリケーションを実行する。各々の分散ア
プリケーションは複数の実行プロセスを有し、これら実
行プロセス間においてメッセージパッシングを行って協
調動作する。

【００１０】図２はこのような分散アプリケーション間
におけるメッセージパッシングの機能を実現するための
ソフトウェア構成図である。図２に示すように、分散ア
プリケーションＡｐ１とＡｐ２の間のメッセージパッシ
ングは、メッセージパッシングオペレータ部Ｍ１及びＭ
２と、通信メディアインタフェース部Ｃ１及びＣ２を介
して行われる。

【００１１】図３はこのようなメッセージパッシングを
実現するためのより具体的な構成例を示すブロック図で
ある。分散評価部１０、開発ツール（モニタ及びデバッ
ガ）１１、そしてシステムイニシャライザ１２が上記ア
プリケーションＡｐ１（Ａｐ２）に相当する。また、メ
ッセージディスパッチャ３１及びメッセージ送信要求部
３２を含むメッセージパッシングオペレータ部３０が上
記メッセージパッシングオペレータ部Ｍ１（Ｍ２）に相
当する。ネットワークインタフェース６１を有する通信
メディアインタフェース６０が、上記通信メディアイン
タフェースＣ１（Ｃ２）に相当している。

【００１２】そして本実施形態においては、通信メディ
アインタフェース部６０が、同図に示すように通信メデ
ィア７０を介して他のノードの通信メディアインタフェ
ース部に対して遠隔手続き呼び出し（ＲＰＣ）を行うも
のとなっている。

【００１３】ここで、遠隔手続き呼び出しによるメッセ
ージパッシングを行う通信メディアインタフェース部６
０の具体的な構成例について説明する。図４は、ネット
ワークを介して隔てられたノード間（ノードＡ〜ノード
Ｂ）において、遠隔手続き呼び出しによりプロセス間の
メッセージパッシングを行う場合の構成を概略的に示す
ブロック図である。ノードＡ側のプロセス及びノードＢ
側のプロセスの両者は一つの分散アプリケーションの構
成要素である。

【００１４】そしてここでは、遠隔手続き呼び出しによ
りノードＡがノードＢに対してメッセージ送信を行う場
合について説明する。同図に示すように、ノードＡ及び
ノードＢの両プロセスは、遠隔手続呼び出しによるメッ
セージパッシングのための送信スレッド８００（７０
０）及び受信スレッド４００（９００）、そして受信ス
レッドにより生成されるメッセージ処理スレッド３００
（６００）から構成される。

【００１５】プロシージャ呼び出し要求としてのメッセ
ージ送信要求を受信する受信スレッド９００の通信メデ
ィアインターフェース５００は、受信準備プロシージャ
５０１と、ディスパッチプロシージャ５０２と、実処理
プロシージャ５０３と、ＲＰＣ５０４とから構成され
る。ＲＰＣ５０４は、受信準備プロシージャ５０１又は
ディスパッチプロシージャ５０２から呼び出されるラン
タイムライブラリとして実装され、このＲＰＣ５０４
は、メッセージ送信側のプロセスから送られてきたメッ
セージ送信要求（プロシージャ呼び出し要求）をポート
５０５を介して入力する。

【００１６】受信準備プロシージャ５０１は、メッセー
ジが到着した際にディスパッチプロシージャ５０２に制
御が渡るようＲＰＣ５０４に依頼する。ディスパッチプ
ロシージャ５０２はプロシージャ呼び出し要求を処理
し、実処理プロシージャ５０３を呼び出す。実処理プロ
シージャ５０３はメッセージ処理スレッド６００を生成
してメッセージディスパッチャ６０１を生成する。メッ
セージディスパッチャ６０１は、受信したメッセージを
処理する。メッセージ処理スレッド６００は、受信スレ
ッド５００とは別のスレッドにより実行される。このた
め受信スレッド５００の実処理プロシージャ５０３は速
やかに終了されることとなり、迅速に次のメッセージ待
ち状態に移行することになる。なお受信スレッド４００
は、受信スレッド９００と同様に構成される。図５に上
記メッセージ処理スレッド６００により処理されるプロ
シージャ呼び出し要求メッセージのデータ構造を模式的
に示す。

【００１７】図６は、受信準備プロシージャ５０１、デ
ィスパッチプロシージャ５０２、及び実処理プロシージ
ャ５０３の動作を示すフローチャートである。図６
（ａ）は受信準備プロシージャ５０１の動作を示すフロ
ーチャートである。先ずステップＳ１においてＲＰＣト
ランスポートハンドルを取得する。当該処理は自プロセ
スのプロセスＩＤをパラメータに指定してＲＰＣ５０４
の所定のライブラリルーチンを呼び出すことにより実現
される。ＲＰＣトランスポートハンドルは、通信に関す
る情報を維持するための特定のデータ構造を有してい
る。次にステップＳ２においてディスパッチプロシージ
ャ５０２をポートマップに登録する。当該処理は、以下
に記すパラメータを指定してＲＰＣ５０４の所定のライ
ブラリルーチンを呼び出すことにより実現される。

【００１８】指定パラメータ： ・ＲＰＣサービストランスポートハンドル ・プログラム番号（分散アプリケーション実行システム
ＩＤ） ・バージョン番号（プロセスＩＤ） ・ディスパッチプロシージャ ・伝送プロトコル（ＴＣＰ又はＵＤＰ）

【００１９】そしてステップＳ３においてプロシージャ
呼び出し要求として与えられるメッセージを待つイベン
ト待ち処理に移行する。ここで、プロシージャ呼び出し
側プロセスからのメッセージが到着すると、ＲＰＣは５
０４はディスパッチプロシージャ５０２に制御を渡す。
ここで、上記受信準備プロシージャ５０１のより具体的
な構成例として当該プロシージャのＣ言語ソースリスト
を記す。

【００２０】 /********************************************************** * cmirpc.x ；ＯＮＣ ＲＰＣ言語によるプロトコル定義ファイル * rpcgen -b cmirpc.x ***********************************************************/ struct packetInfo { opaque senderHostID[4]; /* 送信側ホストID */ u_long senderPID; /* 送信側プロセスID */ opaque receiverHostID[4];/* 受信側ホストID */ u_long receiverPID; /* 受信側プロセスID */ opaque msg<>; /* message本体 */ }; /********************* * progran definition *********************/ program CMIPROG { version CMIVERS { int CMISVC(packetInfo) = 1; /* プロシージャ番号 */ } = 1; /* バージョン番号( 仮) * / } = 0x211d1ae3; /* プログラム番号 */ /*************************** * cmirpc.h ；ヘッダファイル ****************************/ #ifndef _CMIRPC_H_RPCGEN #define _CMIRPC_H_RPCGEN #include <rpc/rpc.h> struct packetInfo { char senderHostID[4]; u_long senderPID; char receiverHostID[4]; u_long receiverPID; struct { u_int msg_len; char *msg_val; } msg; }; typedef struct packetInfo packetInfo; #define CMIPROG ((unsigned long)(0x211d1ae3)) #define CMIVERS ((unsigned long)(1)) #define CMISVC ((unsigned long)(1)) extern int * cmisvc_1(); extern int cmiprog_1_freeresult(); /* the xdr functions */ extern bool_t xdr_packetInfo(); #endif /* !_CMIRPC_H_RPCGEN */ /******************************************* * cmirpc_xdr.c ；外部データ表現変換ルーチン ********************************************/ #include "cmirpc.h" bool_t xdr_packetInfo(xdrs, objp) register XDR *xdrs; packetInfo *objp; { register long *buf; int i; if (!xdr_opaque(xdrs, objp->senderHostID, 4)) return (FALSE); if (!xdr_u_long(xdrs, &objp->senderPID)) return (FALSE); if (!xdr_opaque(xdrs, objp->receiverHostID, 4)) return (FALSE); if (!xdr_u_long(xdrs, &objp->receiverPID)) return (FALSE); if (!xdr_bytes(xdrs, (char **)&objp->msg.msg_val, (u_int *) &obj p->msg.msg_len, ~0)) return (FALSE); return (TRUE); } /**************************** * 受信準備プロシージャ ****************************/ void cmilisten(u_long SelfProcessID) { SVCXPRT *transp; int sock = RPC_ANYSOCK; int proto = IPPROTO_TCP; /* ポートマップから指定プログラム番号、バージョン番号の登録を削 除 */ (void) pmap_unset(CMIPROG, SelfProcessID); /* RPCサービストランスポートハンドルを取得 */ transp = svctcp_create(sock, 0, 0); if (transp == NULL) { exit(1); } /* ディスパッチプロシージャをポートマップに登録 */ /* svc_register() の第二引数はプログラム番号、 * 第三引数はバージョン番号である。

【００２１】 * 第二引数にアプリケーション実行システムIDであるCMIPROG * (ヘッダファイルに0x2211d1aeと言う値で定義されている) 、 * 第三引数に自プロセスのプロセスIDであるSelfProcessID を * 指定する。

【００２２】 */ if (!svc_register(transp, CMIPROG, SelfProcessID, cmiprog, proto)) { exit(1); } /* プロシージャ呼び出し要求を待つループに入る ＊／ ｓｖｃ＿ｒｕｎ（）； ｅｘｉｔ（１）； ｝

【００２３】図６（ｂ）は、ディスパッチプロシージャ
５０２の動作を示すフローチャートである。このディス
パッチプロシージャ５０２には、プロシージャ番号及び
ＲＰＣサービストランスポートハンドルがパラメータと
して指定される。また当該処理はＲＰＣ５０４の所定の
ライブラリルーチンを利用する。

【００２４】先ずステップＳ２１において、プロシージ
ャ番号による分岐処理を行う。すなわち、プロシージャ
番号に“０”が指定された場合は、ステップＳ２０に移
行し、値を返さす応答処理のみを実行して終了する。こ
のプロシージャ番号“０”は、特定の目的すなわち受信
側の動作確認のために予約されている。またプロシージ
ャ番号に“１”が指定された場合は、ステップＳ２３に
移行し、受け取った引数（メッセージ）のデコードを行
い、ステップＳ２４に移行して実処理プロシージャ５０
３を呼び出す。ここでは、デコードされた引数を指定
し、リモートから呼び出されたプロシージャを呼び出
す。呼び出し処理を終えるとステップＳ２６に移行し、
上記デコードによって割り当てられたメモリ領域を開放
して終了する。

【００２５】またプロシージャ番号に上記“０”もしく
は“１”以外の値が指定された場合はエラーとする。こ
こで、上記ディスパッチプロシージャ５０２のより具体
的な構成例として当該プロシージャのＣ言語ソースリス
トを記す。

【００２６】 ／＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊ ディスパッチプロシージャ ****************************/ static void cmiprog(struct svc_req *rqstp, SVCXPRT *transp) { union { packetInfo cmisvc_1_arg; } argument; char *result; bool_t (*xdr_argument)(), (*xdr_result)(); char *(*local)(); /* プロシージャ番号による切り分け */ switch (rqstp->rq_proc) { case NULLPROC: /* プロシージャ番号０: 値を返さず応答のみする */ (void) svc_sendreply(transp, xdr_void, (char *)NULL); return; case CMISVC: /* プロシージャ番号１: */ xdr_argument = xdr_packetInfo; xdr_result = xdr_int; local = (char *(*)()) cmisvc_1; break; default: /* その他 */ svcerr_noproc(transp); return; } (void) memset((char *)&argument, 0, sizeof (argument)); /* 受け取った引数をデコード */ if (!svc_getargs(transp, xdr_argument, &argument)) { svcerr_decode(transp); return; } /* 実処理プロシージャ呼び出し */ result = (*local)(&argument, rqstp); /* 返値をエンコードし呼び出し元へ送信 */ if (result != NULL && !svc_sendreply(transp, xdr_result, result) ) { svcerr_systemerr(transp); } /* デコードで割り当てられたメモリを解放 */ if (!svc_freeargs(transp, xdr_argument, &argument)) { exit(1); } return; }

【００２７】図６（ｃ）は、実処理プロシージャ５０３
の動作を示すフローチャートである。実処理プロシージ
ャ５０３は、ステップＳ３０においてメッセージ処理ス
レッド６００を生成し、引数（メッセージ）をメッセー
ジディスパッチャ６０１に渡す。メッセージディスパッ
チャ６０１はメッセージを処理する。メッセージ処理ス
レッド６００は、受信スレッド９００とは別のスレッド
により実行される。このため受信スレッド９００の実処
理プロシージャ５０３は速やかに終了されることとな
り、迅速に次のメッセージ待ち状態に移行することにな
る。ここで、上記実処理プロシージャ５０３のより具体
的な構成例として当該プロシージャのＣ言語ソースリス
トを記す。

【００２８】 /**************************** * 実処理プロシージャ ***************************/ int * cmisvc_1(packetInfo *packetInfoPtr, struct svc_req *rqstp) { struct packetInfo* packetInfoPtr2; int result; u_long tid; /* メモリを確保し、引数( メッセージ) をコピー */ packetInfoPtr2 = (struct packetInfo *)malloc(sizeof(packetInfo)); memcpy(packetInfoPtr2, packetInfoPtr, sizeof(packetInfo)); packetInfoPtr2->msg.msg_val = (char *)malloc(packetInfoPtr->msg.msg_le n); memcpy(packetInfoPtr2->msg.msg_val, packetInfoPtr->msg.msg_val, packetInfoPtr->msg.msg_len); /* Message処理スレッドを生成し、引数( メッセージ) を渡す */ result = thr_create(0,0,(void*(*)(void*))MessageDispatcher, packetInfo Ptr2, 0, &tid); return (&result); }

【００２９】一方、プロシージャが呼び出される側のプ
ロセスの受信スレッド９００に対しプロシージャ呼び出
し要求を送信する送信スレッド８００は、メッセージ送
信要求部１００と通信メディアインタフェース部２００
とから構成される。通信メディアインタフェース部２０
０は、送信プロシージャ２０１とＲＰＣ２０２とから構
成される。ＲＰＣ２０２は、送信プロシージャ２０１か
ら呼び出されるランタイムライブラリとして実装され、
このＲＰＣ２０２は、ポート２０３から上記要求メッセ
ージを出力し、プロシージャが呼び出される側のプロセ
スのポート５０５に送る。なお送信スレッド７００は、
送信スレッド８００と同様に構成される。

【００３０】図７は送信プロシージャ２０１の動作を示
すフローチャートである。この送信プロシージャ２０１
は、送信要求部１００により送信先ホストＩＤ、プロセ
スＩＤ、そしてメッセージがパラメータとして指定され
る。

【００３１】先ずステップＳ４０においてクライアント
ハンドルを取得する。このクライアントハンドルは、受
信側との接続情報を保持するための特定のデータ構造を
有している。当該処理は、以下に記すパラメータを指定
してＲＰＣ２０２の所定のライブラリルーチンを呼び出
すことにより実現される。

【００３２】指定パラメータ： ・ホストＩＤ ・プログラム番号（分散アプリケーション実行システム
ＩＤ） ・バージョン番号（プロセスＩＤ） ・その他（バッファサイズなど）

【００３３】次にステップＳ４１においてリモートプロ
シージャ呼び出しを行う。当該処理は、以下に記すパラ
メータを指定してＲＰＣ２０２の所定のライブラリルー
チンを呼び出すことにより実現される。

【００３４】指定パラメータ： ・クライアントハンドル ・プロシージャ番号 ・引数エンコード用プロシージャ ・引数本体（メッセージ） ・返値デコード用プロシージャ ・返値格納用フィールド ・タイムアウト時間

【００３５】ここで、上記送信プロシージャ２０１のよ
り具体的な構成例として当該プロシージャのＣ言語ソー
スリストを記す。

【００３６】 /**************************** * 送信プロシージャ ****************************/ int cmisend(const struct packetInfo *packetInfoPtr) { int clnt_res; CLIENT *clnt; struct sockaddr_in Sockaddr; static struct timeval TIMEOUT = { 5, 0 }; int sock = RPC_ANYSOCK; memset((char *)&Sockaddr, 0, sizeof(Sockaddr)); memcpy(&(Sockaddr.sin_addr.s_addr), packetInfoPtr->receiverHostID, sizeof(u_long)); Sockaddr.sin_family = AF_INET; /* クライアントハンドルを取得 */ /* clnttcp_create() の第二引数はプログラム番号、 * 第三引数はバージョン番号である。

【００３７】 * ここで、第二引数にアプリケーション実行システムIDであるCMIPROG * (ヘッダファイルに0x2211d1aeと言う値で定義されている) 、 * 第三引数に受信側プロセスのプロセスIDであるpacketInfoPtr->recei verPIDを * 指定する。

【００３８】 */ if ((clnt = clnttcp_create(&Sockaddr, CMIPROG, packetInfoPtr->receiver PID,&sock, 0, 0)) == NULL) { clnt_pcreateerror("clnttcp_create"); return -1; } /* リモートプロシージャ呼び出し */ if (clnt_call(clnt, CMISVC, (xdrproc_t) xdr_packetInfo, (caddr_t) packetInfoPtr, (xdrproc_t) xdr_int, (caddr_t) &clnt_res, TIMEOUT) != RPC_SUCCESS) { clnt_perror(clnt, "call failed"); return -1; } return(clnt_res); }

【００３９】ところで本実施形態は、上記したようにプ
ログラム番号には分散アプリケーション実行システムＩ
Ｄを指定し、バージョン番号にはプロセスＩＤを指定す
るものとなっている。すなわち本実施形態においては、
第１の識別手段として分散アプリケーション実行システ
ムＩＤを指定し、このアプリケーション実行システムＩ
Ｄにより識別されたプログラムによって生成される一つ
あるいは複数のプロセスを識別する第２の識別手段とし
てプロセスＩＤを指定する。この構成により、分散アプ
リケーションを構成するプログラムを遠隔手続き呼び出
しシステム上で稼動している他のプログラムから区別
し、なおかつ分散アプリケーションを構成するプログラ
ムから生成された個々のプロセスを識別してプロセス間
のメッセージ受け渡しを行うことができる。

【００４０】たとえば図８に示すように、分散アプリケ
ーション実行システムが、複数のノードＮ１〜Ｎ４と、
それらのノードに配置された分散アプリケーション実行
システム機能をもつ複数のプログラムＰｇ０〜Ｐｇ４
（同一の分散アプリケーション実行システムＩＤをも
つ）から構成されている場合を考える。本実施形態によ
れば、それらのプログラムから生成されたプロセスＰ０
〜Ｐ５を識別することが可能となり、プロセスＰ０〜Ｐ
５は独立した分散アプリケーション１と分散アプリケー
ション２として構成できる。

【００４１】かくして複数の分散アプリケーションを動
的に設営することが可能な分散アプリケーション実行シ
ステムを提供できる。 （第２実施形態）次に、本発明の第２実施形態を説明す
る。第１実施形態においては、分散アプリケーション実
行システムによって管理されるアプリケーションを構成
する複数プロセス間のメッセージパッシングを、遠隔手
続き呼び出し（ＲＰＣ）によって実現する場合のシステ
ム構成例について説明したが、第２実施形態において
は、上記アプリケーションを構成する複数プロセス間の
メッセージパッシングを、いわゆるソケットインタフェ
ースによるプロセス間通信により実現する場合のシステ
ム構成例について説明する。

【００４２】図９は、ネットワークを介して隔てられた
ノード間（ノードＡ〜ノードＢ）において、ソケットイ
ンターフェースによるプロセス間通信によりメッセージ
パッシングを行う場合の構成を概略的に示すブロック図
である。ノードＡ側のプロセス及びノードＢ側のプロセ
スの両者は一つのアプリケーションの構成要素である。
同図に示すように、ノードＡ及びノードＢの両プロセス
は、ソケットインタフェースによるプロセス間通信を用
いるメッセージパッシングのための送信スレッド５００
１（５０００）及び受信スレッド８０００（８００
１）、そして受信スレッドにより生成されるメッセージ
処理スレッド４０００（９０００）から構成される。

【００４３】送信スレッド５００１は送信要求部１００
０および通信メディアインターフェース部２０００から
構成される。通信メディアインタフェース部２０００
は、送信プロシージャ２００１と、ポート番号管理要求
プロシージャ２００２と、ソケットライブラリルーチン
２００３とから構成される。なお送信スレッド５０００
は、送信スレッド５００１と同様に構成される。

【００４４】受信スレッド８００１は、ポート番号管理
要求プロシージャ３００１と、受信プロシージャ３００
２と、ソケットライブラリルーチン３００３とから成る
通信メディアインタフェース部３０００を有している。
受信プロシージャ３００２から呼び出されるメッセージ
処理スレッド４０００は、メッセージディスパッチャ４
００１を呼び出す。なお、当該メッセージ処理スレッド
４０００及びメッセージディスパッチャ４００１は、第
１実施形態において説明したメッセージ処理スレッド６
００及びメッセージディスパッチャ６０１と同様の構成
である。

【００４５】ポート番号管理プロセス６０００は、ポー
ト番号表管理プロシージャ６００１と、ポート番号表６
００２と、ソケットライブラリルーチン６００３とから
構成される。なお、ポート管理プロセス７０００は、ポ
ート管理プロセス６０００と同様に構成される。

【００４６】図１０は、送信プロシージャ２００１及び
ポート番号管理要求プロシージャ２００２の動作を示す
フローチャートである。図１０（ａ）は、送信プロシー
ジャ２００１の動作を示すフローチャートである。送信
プロシージャ２００１は、送信先ホストＩＤ、送信先プ
ロセスＩＤ、そしてメッセージがパラメータとして指定
され、送信要求部１０００により呼び出される。先ずス
テップＳ７０において、ポート番号管理プロセス６００
０に対しポート番号を問い合わせる。すなわちポート番
号管理要求プロシージャ２００２を呼び出す。ここでは
送信先ホストのポート番号管理プロセス６０００に対
し、アプリケーション実行システムＩＤ及びプロセスＩ
Ｄに対応するポート番号を問い合わせる。

【００４７】次にステップＳ７１において、メッセージ
送信用のソケットを作成する。ここでは、上記ステップ
Ｓ７０の問い合わせ処理によって得たポート番号を指定
して接続要求を出す。続くステップＳ７２においてメッ
セージを送信する。ここでは先ず図５に示したデータ構
造を有するメッセージデータを送信する。そしてステッ
プＳ７３において結果を受信する。ここで、上記送信プ
ロシージャ２００１のより具体的な構成例として当該プ
ロシージャのＣ言語ソースリストを記す。

【００４８】 /****************************** * ヘッダファイル ******************************/ #include <stdlib.h> #include <errno.h> #include <sys/types.h> #include <sys/socket.h> #include <sys/uio.h> #include <netinet/in.h> struct portInfo { int flag; /* 0:ポート番号登録 1: ポート番号問い合わせ */ u_long progID; /* アプリケーション実行システムＩＤ */ u_long processID; /* プロセスID */ u_short portNo; /* ポート番号 */ }; #define CMIPROG ((unsigned long)(0x211d1ae3)) struct packetInfo { u_long senderHostID; u_long senderPID; u_long receiverHostID; u_long receiverPID; struct { u_int msg_len; char *msg_val; } msg; }; /**************************** * 送信プロシージャ ***************************/ int cmisend(const struct packetInfo *packetInfoPtr) { struct sockaddr_in ports, socks; int Sock, addrlen, nByteRecv, nByteSend, result, portNo; struct portInfo PortInfo; /* ポート番号管理プロセスにポート番号を問い合わせ */ PortInfo.flag = 1; PortInfo.progID = CMIPROG; /* ヘッダファイルに定義されている */ PortInfo.processID = packetInfoPtr->receiverPID; portNo = cmiportreq(packetInfoPtr->receiverHostID, &PortInfo); if(portNo == -1){ return -1; } /* メッセージ送信用のソケットを作成 */ Sock = socket(AF_INET, SOCK_STREAM, 0); socks.sin_addr.s_addr = packetInfoPtr->receiverHostID; socks.sin_family = AF_INET; socks.sin_port = htons(portNo);/* 問い合わせで得た送信相手ポート番号に 接続 */ connect(Sock, (struct sockaddr *)&socks, sizeof(socks)); /* packetInfo を送信 */ nByteSend = send(Sock, (char *)packetInfoPtr, sizeof(struct packetInfo ), 0); /* メッセージ本体を送信 */ nByteSend = send(Sock, (char *)packetInfoPtr->msg.msg_val, packetInfoPtr->msg.msg_len, 0); /* 結果を受信 */ nByteRecv = recv(Sock, (char *)&result, sizeof(result), 0); close(Sock); return result; }

【００４９】図１０（ｂ）はポート番号管理要求プロシ
ージャ２００２の動作を示すフローチャートである。当
該プロシージャは、以下のようなパラメータが指定され
て送信プロシージャ２００１から呼び出される。

【００５０】指定パラメータ： ・ホストＩＤ ・要求内容（登録又は問い合わせ） ・アプリケーション実行システムＩＤ ・プロセスＩＤ ・ポート番号

【００５１】先ずステップＳ８０において、要求送信用
のソケットを作成する。ここではポート番号表管理プロ
シージャ６００１のために予約されたポート番号（後述
のように“８８８８”が予約）を指定して接続要求を出
す。次にステップＳ８１において要求を送信し、ステッ
プＳ８２において結果を受信し、そしてステップＳ８３
において、呼び出し元である送信プロシージャ２００１
に対して受信結果を返す。ここで、上記ポート番号管理
要求プロシージャ２００２のより具体的な構成例として
当該プロシージャのＣ言語ソースリストを記す。

【００５２】 /************************************* * ポート番号管理要求プロシージャ *************************************/ int cmiportreq(u_long HostID, struct portInfo *portInfoPtr) { struct sockaddr_in ports; int portSock, addrlen, nByteRecv, nByteSend, result; /* 要求送信用のソケットを作成 */ memset((char *)&ports, 0, sizeof(ports)); portSock = socket(AF_INET, SOCK_STREAM, 0); ports.sin_addr.s_addr = HostID; ports.sin_family = AF_INET; ports.sin_port = htons(8888);/* 「ポート番号管理プロセス」のポートに接 続 */ connect(portSock, (struct sockaddr *)&ports, sizeof(ports)); /* 要求を送信 */ nByteSend = send(portSock, (char *)portInfoPtr, sizeof(*portInfoPtr), 0); /* 結果を受信 */ nByteRecv = recv(portSock, (char *)&result, sizeof(result), 0); close(portSock); if(result < 0){ printf("portreq error:%d\n", result); return -1; } return result; }

【００５３】図１１は、ポート番号表管理プロシージャ
６００１及び受信プロシージャ３００２の動作を示すフ
ローチャートである。図１１（ａ）はポート番号表管理
プロシージャ６００１の動作を示すフローチャートであ
る。当該プロシージャは、送信スレッドのポート番号管
理要求プロシージャ２００２からの要求により、ポート
番号の登録処理又はポート番号問い合わせ処理を行う。
先ずステップＳ５０において、要求受信用のソケットを
作成する。ここでは、ポート番号管理プロセス６０００
のために予約されたポート番号（ここでは“８８８８”
とする）を指定してソケットを作成する。

【００５４】次にステップＳ５１において、要求の受信
待ちを行い、ここで管理要求を受信したらステップＳ５
２に移行する。ステップＳ５２においては、ポート番号
管理要求プロシージャ２００２によって指定されたパラ
メータのうち要求内容を判別して処理を行う。すなわち
要求内容が「ポート番号の登録要求」である場合は、ス
テップＳ５３に移行しポート番号表６００２にアプリケ
ーション実行システムＩＤ，プロセスＩＤおよびポート
番号を格納する。また要求内容が「ポート番号の問い合
わせ要求」である場合は、ステップＳ５４に移行し、ポ
ート番号表６００２内において、指定パラメータのアプ
リケーション実行システムＩＤ及びプロセスＩＤに対応
するポートを検索する。対応するポートが見つかった場
合はそのポート番号を返す。

【００５５】そしてステップＳ５５において、呼び出し
元であるポート番号管理要求プロシージャ２００２に対
して結果を送信したのち、ステップＳ５１に移行し、再
び要求の受信待ちに入る。ここで、上記ポート番号表管
理プロシージャ６００１のより具体的な構成例として当
該プロシージャのＣ言語ソースリストを記す。

【００５６】 #include "port.h" /******************************************************** * ポート番号表管理プロシージャ * ********************************************************/ #define PORTTABLE_MAX 256 void main() { struct sockaddr_in listens, news; int i, listenSock, newSock, addrlen, opt, nByteRecv, nByteSend, result ; struct portInfo PortInfo; struct portTable { /* ポート番号表 */ u_long progID; u_long processID; u_short portNo; }PortTable[PORTTABLE_MAX]; int portTable_tail = -1; /* 要求受信用のソケット作成 */ listenSock = socket(AF_INET, SOCK_STREAM, 0); opt = 1; setsockopt(listenSock, SOL_SOCKET, SO_REUSEADDR, (char *)&opt, sizeof( int)); memset((char *)&listens, 0, sizeof(listens)); listens.sin_addr.s_addr = htonl(INADDR_ANY); listens.sin_family = AF_INET; listens.sin_port = htons(8888);/* 「ポート番号管理プロセス」のポート指 定 */ bind(listenSock, (struct sockaddr *)&listens, sizeof(listens)); listen(listenSock, 5); addrlen = sizeof(struct sockaddr_in); while(1){ /* 要求の受信待ち */ newSock = accept(listenSock, (struct sockaddr *)&news, &addrlen); /* 要求を受信 */ nByteRecv = recv(newSock, (char *)&PortInfo, sizeof(PortInfo), 0); switch(PortInfo.flag){ case 0: /* ポート番号の登録要求: ポート番号表にアプリケーション実行システムID、プロセスID、 ポート番号を格納 */ if(portTable_tail == PORTTABLE_MAX - 1){ result = -1; break; } for(i = 0; i <= portTable_tail; i++){ if(PortTable[i].progID == PortInfo.progID && PortTable[i].processID == PortInfo.processID){ break; } } if(i <= portTable_tail){ /* すでにある: 上書き */ PortTable[i].portNo = PortInfo.portNo; }else{ /* ない: 新規登録 */ PortTable[++portTable_tail].processID = PortInfo.processID; PortTable[portTable_tail].progID = PortInfo.progID; PortTable[portTable_tail].portNo = PortInfo.portNo; } result = 0; break; case 1: /* ポート番号の問い合わせ要求: ポート番号表をアプリケーション実行システムID、プロセスIDで検索 し、対応するポート番号を返却 */ result = -1; for(i = 0; i <= portTable_tail; i++){ if(PortTable[i].progID == PortInfo.progID && PortTable[i].processID == PortInfo.processID){ result = PortTable[i].portNo; break; } } break; default: result = -1; break; } /* 結果を送信 */ nByteSend = send(newSock, (char *)&result, sizeof(result), 0); close(newSock); } /* while */ }

【００５７】図１１（ｂ）は、受信プロシージャ３００
２の動作を示すフローチャートである。当該プロシージ
ャに対しては、自プロセスＩＤ及び自ホストＩＤがパラ
メータとして指定される。

【００５８】先ずステップＳ６０においてメッセージ受
信用のソケットを作成する。次に、ステップＳ６１にお
いて、ポート番号管理プロセス６０００に対し、ポート
番号の登録を要求する。すなわちメッセージ受信用に割
り当てられたポート番号を調べ、そのポート番号及びア
プリケーション実行システムＩＤ，プロセスＩＤを自ホ
ストのポート番号管理プロセスに対して登録要求する。
当該処理は、受信プロシージャ３００２がポート番号管
理要求プロシージャ３００１を呼び出すことによって行
われる。次にステップＳ６２においてメッセージ受信待
ちに入る。ここで、メッセージを受信した場合は、メッ
セージを格納するメモリ領域を確保し、当該領域にメッ
セージ本体を書き込む。

【００５９】次にステップＳ６３においてメッセージ処
理スレッド４００１を生成し、引数（すなわちメッセー
ジ）を渡す。ここでは上述したようにメッセージディス
パッチャ４００１によるメッセージ処理が行われる。そ
してステップＳ６４に移行し、送信スレッド側に結果を
送信する。ここで、上記受信プロシージャ３００２のよ
り具体的な構成例として当該プロシージャのＣ言語ソー
スリストを記す。

【００６０】 /**************************** * 受信プロシージャ * ***************************/ void cmilisten(u_long selfProcessID, u_long selfHostID) { struct sockaddr_in listens, news; int i, listenSock, newSock, addrlen, nByteRecv, nByteSend, result; struct packetInfo* packetInfoPtr; struct portInfo PortInfo; u_long tid; /* メッセージ受信用のソケットを作成 */ memset((char *)&listens, 0, sizeof(listens)); listenSock = socket(AF_INET, SOCK_STREAM, 0); listens.sin_addr.s_addr = htonl(INADDR_ANY); listens.sin_family = AF_INET; listens.sin_port = htons(0); bind(listenSock, (struct sockaddr *)&listens, sizeof(listens)); /* 割り当てられたポート番号を調べる */ addrlen = sizeof(struct sockaddr_in); getsockname(listenSock, (struct sockaddr *)&listens, &addrlen); /* ポート番号管理プロセスに登録を要求 */ PortInfo.flag = 0; PortInfo.progID = CMIPROG; /* ヘッダファイルに定義されている */ PortInfo.processID = selfProcessID; PortInfo.portNo = listens.sin_port; if(cmiportreq(selfHostID, &PortInfo) == -1){ exit(1); } listen(listenSock, 5); while(1){ /* メッセージの受信待ち */ newSock = accept(listenSock, (struct sockaddr *)&news, &addrlen); /* packetInfo を読み込み、メッセージ本体長を得る */ packetInfoPtr = (struct packetInfo *)malloc(sizeof(struct packetInfo )); nByteRecv = recv(newSock, (char *)packetInfoPtr, sizeof(struct packetInfo), 0); /* メッセージ本体を読み込む */ packetInfoPtr->msg.msg_val = (char *)malloc(packetInfoPtr->msg.msg_l en); nByteRecv = recv(newSock, (char *)packetInfoPtr->msg.msg_val, packetInfoPtr->msg.msg_len, 0); /* メッセージ処理スレッドを生成し、引数( メッセージ) を渡す */ result = thr_create(0,0,(void*(*)(void*))MessageDistributer, packetInfoPtr, 0, &tid); /* 結果を送信 */ nByteSend = send(newSock, (char *)&result, sizeof(result), 0); close(newSock); } /* while */ }

【００６１】このように、複数プロセス間のメッセージ
パッシングを、いわゆるソケットインタフェースによる
プロセス間通信により実現する第２実施形態によれば、
メッセージ送信先の特定を、アプリケーション実行シス
テムＩＤ及びプロセスＩＤの指定によって行うため、ソ
ケットインタフェースの通常の方法によりホストのアド
レス及びポート番号を用いて物理的に特定する場合に比
べて、論理的に、そして柔軟に行うことができる。な
お、本発明は上述した実施形態に限定されず、種々変形
して実施可能である。

【００６２】

【発明の効果】以上説明したように本発明によれば、複
数のアプリケーションから構成される分散アプリケーシ
ョン空間を動的に設営可能な分散アプリケーション実行
システムを提供できる。

【図面の簡単な説明】

【図１】本発明の第１実施形態に係る分散アプリケーシ
ョン実行システムの論理構成図。

【図２】上記第１実施形態に係るアプリケーション間に
おけるメッセージパッシングの機能を実現するためのソ
フトウェア構成図。

【図３】上記第１実施形態に係るメッセージパッシング
を実現するためのより具体的な構成例を示すブロック
図。

【図４】上記第１実施形態に係り、ネットワークを介し
て隔てられたノード間（ノードＡ〜ノードＢ）におい
て、遠隔手続き呼び出しによりプロセス間のメッセージ
パッシングを行う場合の構成を概略的に示すブロック
図。

【図５】上記第１実施形態に係るメッセージ処理スレッ
ド６００により処理されるプロシージャ呼び出し要求メ
ッセージのデータ構造を模式的に示す図。

【図６】上記第１実施形態に係る受信準備プロシージャ
５０１、ディスパッチプロシージャ５０２、及び実処理
プロシージャ５０３の動作を示すフローチャート。

【図７】上記第１実施形態に係る送信プロシージャ２０
１の動作を示すフローチャート。

【図８】上記第１実施形態に係る分散アプリケーション
の構築例を示す模式図。

【図９】本発明の第２実施形態に係るメッセージパッシ
ングを実現するためのより具体的な構成例を示すブロッ
ク図。

【図１０】送信プロシージャ２００１及びポート番号管
理要求プロシージャ２００２の動作を示すフローチャー
ト。

【図１１】ポート番号表管理プロシージャ６００１及び
受信プロシージャ３００２の動作を示すフローチャー
ト。

【符号の説明】

Ｌ…分散アプリケーション実行システム Ａｐ１，Ａｐ２…（分散）アプリケーション Ｍ１，Ｍ２…メッセージパッシングオペレータ部 Ｃ１，Ｃ２…通信メディアインターフェース部 １０…分散評価部 １１…開発ツール １２…システムイニシャライザ １３…メッセージ受け渡しインタフェース部 ２０…メッセージ評価スケジューラ ３０…メッセージパッシングオペレータ部 ３１…メッセージディスパッチャ ３２…メッセージ送信要求部 ６０…通信メディアインターフェース部 ６１…ネットワークインターフェース ７０…通信メディア １００…送信要求部 ２００，５００…通信メディアインターフェース部 ２０１…送信プロシージャ ２０２，５０４…ＲＰＣ ２０３，５０５…ポート ３００，６００…メッセージ処理スレッド ４００，９００…受信スレッド ５０１…受信準備プロシージャ ５０２…ディスパッチプロシージャ ５０３…実処理プロシージャ ６０１…メッセージディスパッチャ ７００，８００…送信スレッド

Claims (3)

【特許請求の範囲】
1. 【請求項１】 複数のコンピュータノードがネットワー
   クを介して結合された分散処理システム上で前記ノード
   上に存在するプロセス間のメッセージ受け渡しを行うア
   プリケーション、を実行する分散アプリケーション実行
   システムにおいて、 前記アプリケーションを構成するプロセスの生成元とな
   るプログラムを識別する第１の識別手段と、前記第１の
   識別手段により識別されたプログラムによって生成され
   る少なくとも一つのプロセスを識別する第２の識別手段
   とを具備し、 前記プロセス間のメッセージ受け渡しは、前記第１の識
   別手段によるプログラムの識別と、前記第２の識別手段
   によるプロセスの識別とによって前記メッセージの送り
   先を特定して行われることを特徴とする分散アプリケー
   ション実行システム。
2. 【請求項２】 前記メッセージ受け渡しは、遠隔手続き
   呼出しにより行われ、当該遠隔手続き呼出しに対する通
   信ポートの割り当ては、前記第１の識別手段によるプロ
   グラムの識別と、前記第２の識別手段によるプロセスの
   識別により行われ、前記メッセージは前記通信ポートに
   対して送られることを特徴とする請求項１に記載の分散
   アプリケーション実行システム。
3. 【請求項３】 前記メッセージ受け渡しは、ソケットイ
   ンタフェースによるプロセス間通信により行われ、当該
   ソケットインタフェースに対する通信ポートの割り当て
   は、前記第１の識別手段によるプログラムの識別と、前
   記第２の識別手段によるプロセスの識別とによって行わ
   れることを特徴とする請求項１に記載の分散アプリケー
   ション実行システム。