JP3361663B2 - 通信管理方法 - Google Patents

Description

【発明の詳細な説明】 【０００１】 【発明の属する技術分野】本発明は、概して言えばネッ
トワーク通信、より詳細に言えば、コンピュータ・ネッ
トワークにおいて、クライアント処理（クライアント・
プロセス）を行なうホスト・コンピュータと同じホスト
・コンピュータによってサーバ処理（サーバ・プロセ
ス）が行なわれる場合、クライアント処理とサーバ処理
との間の遠隔手続の呼び出し（remote procedure call-
ＲＰＣ）を効率的に管理する方法に関する。 【０００２】 【従来の技術】相互接続された複数個のコンピュータの
間で情報交換を行なわせ、資源を共有させるために、ロ
ーカル・エリア・ネットワーク（ＬＡＮ）の中に複数個
のコンピュータを相互接続する技術は公知である。ロー
カル・エリア・ネットワークは、ユーザが分散された資
源にアクセスすることができ、かつ複数個のコンピュー
タ中のアプリケーションを処理することのできる分散さ
れた計算処理環境を与える。ネットワーク通信は、所
謂、通信プロトコルを用いて遂行される。ローカル・エ
リア・ネットワークの代表的な通信アーキテクチャは、
規則に従って下記の階層を持つ７層モデルを形成するも
のとして特徴付けられる。即ち、この階層は、物理的な
ハードウェア層、論理リンク層、ネットワーク層、伝送
層、セッション層、プレゼンテーション層及びアプリケ
ーション層で構成される。物理的なハードウェア層は、
情報を伝送するために使用される実際の装置及び媒体を
含んでいる。論理リンク層はデータ・パケットを区分
し、物理層のデータ流を制御して、実際の物理的な媒体
とは関係無くデータ伝送を確保する。ネットワーク層は
データ・パケットをアドレスし、かつ通信路の設定処理
を行なう。ネットワーク層は、ソース（発信）ノード及
び宛先ノード間で、ネットワーク中の通信路を設定し維
持する。伝送層は、ノード間の伝送パイプラインを作成
し、かつネットワーク層の接続を管理する。セッション
層は、通常、遠隔手続の呼び出し（ＲＰＣ）のサポート
を与え、ノード間の接続の一貫性を維持し、そしてデー
タ交換を制御する。プレゼンテーション層はデータをエ
ンコードし、かつデコードし、そしてノード間の透明性
を与える。最後に、アプリケーション層は、最終ユーザ
の処理に対してインターフェースを与え、かつアプリケ
ーションに対して標準化されたサービスを提供する。 【０００３】上述の７層モデルは、特定のアーキテクチ
ャに従って多くの類型がある。例えば、ＡＩＸ（商標）
オペレーティング・システムの下でＩＢＭ社のＲＩＳＣ
ＳＹＳＴＥＭ／６０００（商標）コンピュータのワー
クステーションを動作させるＴＣＰ／ＩＰ（伝送制御プ
ロトコル／インターネット・プロトコル）のインターフ
ェースに基づくネットワーク・アーキテクチャにおい
て、セッション層と伝送層との間に存在するソケット層
と呼ばれる他の層がある。このソケット層は、物理的な
ポートに類似した論理構造である、所謂「ソケット」を
作成する。このアーキテクチャにおいて、ＲＰＣ機構は
セッション層においてサポートされるばかりでなく、セ
ッション層の機能も含んでいる。分散された計算処理環
境（distributed computing environment-ＤＣＥ）にお
いて有用な公知のＲＰＣ機構は、オープン・システム・
ファンデイション（Open Systems Foundation-ＯＳＦ）
によって与えられたソフトウェアのコードを含んでい
る。 【０００４】ＯＳＦでＤＣＥのＲＰＣ機構は、分散され
た計算処理環境内に設置された「クライアント」と「サ
ーバ」との間の通信を、遠隔手続の呼び出し（ＲＰＣ）
を用いてサーバからのサービスを要求するクライアント
によって管理するために従来から使用されている。広く
知られているように、「クライアント」とは、分散され
た計算処理環境内にある任意の場所からアクセス可能な
サービスを要求することのできるネットワークの参加者
を意味する用語である。「サーバ」は、クライアントに
より要求されたサービスをクライアントに与えるもので
ある。ＯＳＦでＤＣＥのＲＰＣ機構によって、各クライ
アント処理（即ち、クライアントの装置中で実行する処
理）は、ソケット層によって作成される関連ソケットを
持っている。同様に、各サーバ処理は１つのソケットに
関連される。呼び出しディレクトリ・サービス（ＣＤ
Ｓ）は、ＲＰＣに応答して「バインディング・ハンド
ル」と呼ばれるデータ構造を戻し、このバインディング
・ハンドルは、サーバ処理の位置をネットワーク・アド
レスとして特定し、かつサーバ処理を実行しているポー
トのポート番号を特定する。その後、バインディング・
ハンドルは、クライアント処理とサーバ処理との間の通
信パス（communication path）を定義するために、ＲＰ
Ｃ機構によって用いられる。このパスは、ソケットをオ
ープンするために、インターネットのネットワーク・ア
ドレス・ファミリィ（ＡＦ＿ＩＮＥＴ）のｉｐベース
（即ち、ネットワーク層ベース）のプロトコル・シーケ
ンスを用いて定義される。このパスのループは、クライ
アント処理から、伝送層及びネットワーク層を通ってネ
ットワークへ出た後に、サーバ処理が行なわれるホスト
・コンピュータに関連した層に復帰する。 【０００５】上述したＯＣＦでＤＣＥのＲＰＣの従来の
機構は、クライアント処理及びサーバ処理が同じホスト
・コンピュータ中で動作しているか否かを判別すること
はできない。すべての場合において、この機構は伝送
（ＴＣＰまたはＵＤＰ）層及びネットワーク（ＩＰ）層
を通る通信パスを設定するＡＦ＿ＩＮＥＴのプロトコル
・シーケンスを含むクライアント処理にバインディング
・ハンドルを戻す。ＴＣＰを介した通信は、接続式（co
nnection-oriented）プロトコル・シーケンスを使用
し、他方、ＵＤＰを介した通信は、非接続式（connecti
on-less）プロトコル・シーケンスを使用する。然しな
がら、ネットワーク（ＩＰ）層が宛先ネットワーク・ア
ドレスを受信した後に、ネットワーク層はＲＰＣが「ロ
ーカル」であることを認識するので、従って、パスは、
アプリケーション層中のサーバ処理まで、伝送層を通っ
てループ・バックされねばならないから、上述のプロト
コル・シーケンスの何れを用いる場合でも、クライアン
ト処理及びサーバ処理が同じホスト・コンピュータで行
なわれる時には、ＲＰＣは、所謂ループバック・メッセ
ージを発生する。このループ・バックを必要とするため
に、同じコンピュータ中のクライアント処理及びサーバ
処理の間のＲＰＣは、それらの処理が伝送層及びネット
ワーク層を必要以上に使用するから、性能の観点から見
た場合、最適化されたものではない。 【０００６】 【発明が解決しようとする課題】従って、本発明の主目
的は、ネットワーク中の同じホスト・コンピュータの中
で動作しているクライアント処理及びサーバ処理間の遠
隔手続の呼び出し（ＲＰＣ）を効率的に管理することに
ある。 【０００７】本発明の他の目的は、クライアント処理及
びサーバ処理が同じホスト・コンピュータ中で動作して
いるか否かをネットワークのＲＰＣ機構によって判別さ
せ、若しクライアント処理及びサーバ処理が同じホスト
・コンピュータ中で動作しているならば、ローカルの処
理間通信（プロセス間通信−ＩＰＣ）構造を創設する代
替のプロトコル・シーケンスを用いてネットワーク層及
び伝送層をバイパスさせることにある。 【０００８】本発明の他の目的は、ＤＣＥ内にあるクラ
イアント処理及びサーバ処理が同じホスト・コンピュー
タ中に存在することを検出し、これにより、ＲＰＣを実
行するために、ネットワーク層（ＩＰ層）のパスの代わ
りにローカルＩＰＣ構造を使用するＲＰＣ機構を提供す
ることにある。ＩＰ層をバイパスさせることは、顕著な
性能改善を与える。 【０００９】本発明の他の目的は、同じホスト・コンピ
ュータ中で動作する２つの処理の間で行なわれるＲＰＣ
である「ローカル」ＲＰＣを動作させるＩＰＣ機構を使
用することにある。本発明の１実施例において、ＩＰＣ
機構は「ＵＮＩＸ領域」のソケットであり、本発明は、
ＵＮＩＸネットワーク・アドレス・ファミリィ（ＡＦ＿
ＵＮＩＸ）に基づいて上述のソケットをオープンするた
めに接続式プロトコル・シーケンスを使用する。ＡＦ＿
ＵＮＩＸを有するオペレーティング・システム核は同じ
ホスト・コンピュータ中の２つの処理の間の通信を橋絡
するタスクを取り扱う。 【００１０】本発明の他の目的は、ローカルＲＰＣの性
能を改善するために有用なデータ構造である新規なプロ
トコル・シーケンスを提供することにある。独特のソケ
ット・ファイルがクライアント処理及びサーバ処理の間
に設定された各組合せに使用されるように、上述のデー
タ構造は独特の識別子を含んでいることが望ましい。Ｄ
ＣＥの１つのアプリケーションが複数回呼び出されたと
しても、この独特の識別子によって、１つのソケット・
ファイルが再使用されないことを保証する。 【００１１】本発明の他の目的は、ＤＣＥの従来のアプ
リケーションに対して両立性の問題、または相互オペラ
ビリティの問題を生じないようなプロトコル・シーケン
スを与えることにある。従って、ＤＣＥの共有ライブラ
リの種々のバージョンを用いたアプリケーションは、そ
のプロトコル・シーケンスをサポート（支援）するＤＣ
Ｅの共有ライブラリを用いたアプリケーションと通信す
ることができる。従って、本発明を実施した場合、本発
明は、ユーザに対して透明性を持っており、そして従来
のクライアント／サーバ・アプリケーションに対して逆
方向の両立性を持っている。 【００１２】 【課題を解決するための手段】本発明の上述の目的及び
他の目的は、伝送層及びネットワーク層を有する物理的
なネットワークに接続されたホスト・コンピュータ中に
クライアント処理が存在する分散された計算処理環境内
にあるクライアント処理及びサーバ処理間の通信を管理
する方法を実施することによって達成される。本発明の
方法は、遠隔手続の呼び出しによって識別されたサーバ
処理がホスト・コンピュータ中に存在するか否かを検出
することによって、クライアント処理が遠隔手続の呼び
出し（ＲＰＣ）を行なった時に開始する。若し上述のサ
ーバ処理がホスト・コンピュータの中に存在すれば、物
理的なネットワークの伝送層及びネットワーク層を通る
パスの代わりに、クライアント処理及びサーバ処理間の
通信パスを設定するプロトコル・シーケンスを持つ少な
くとも１つのバインディング・ハンドルを含むクライア
ント処理に、１つのバインディング・ハンドルのベクト
ルが戻される。次に、遠隔手続の呼び出しは、望ましく
はホスト・コンピュータのオペレーティング・システム
の送信及び受信メッセージ伝送手段を使用することによ
って実行される。 【００１３】本発明に従って、ローカルＲＰＣが可能な
限り新しいプロトコル・シーケンスを用いることを保証
するために、種々の参照子が設定される。従って、新し
いプロトコル・シーケンスを持つバインディング・ハン
ドルを有するバインディング・ハンドルのベクトルがク
ライアント処理に戻される。若しｉｐベース（ネットワ
ーク・ベース）のプロトコル・シーケンスを持つバイン
ディング・ハンドルのベクトルが戻されたならば、新し
いプロトコル・シーケンスを持つバインディング・ハン
ドルは、ｉｐベースのプロトコル・シーケンスを持つバ
インディング・ハンドルを用いる前に使用される。 【００１４】上述したことは、本発明の幾つかの関連目
的を概括している。これらの目的は本発明の幾つかの顕
著な特徴及びアプリケーションを単に説明したものとし
て解釈されるべきものである。他の多くの有用な結果
は、以下に説明する本発明の異なった態様、または本発
明の変形を適用することによって得ることができる。従
って、本発明の技術は下記に説明される良好な実施例を
参照することによってより容易に理解することができ
る。 【００１５】 【発明の実施の形態】既に述べたように、本発明は、ユ
ーザが、分散された資源にアクセスすることができ、か
つ複数個のコンピュータ中のアプリケーションを処理す
ることのできる分散された計算処理環境を与えるローカ
ル・エリア・ネットワーク中のクライアント処理及びサ
ーバ処理の間の通信を管理することを全体として指向し
ている。図１を参照すると、ネットワーク１４を介する
クライアント１０及びサーバ１２を含む公知の分散され
た計算処理環境（ＤＣＥ）が示されている。クライアン
ト１０及びサーバ１２の各々はコンピュータである。例
えば、各コンピュータは、ＡＩＸ（Advanced Interacti
ve Executive）（商標）オペレーティング・システムで
動作するＩＢＭ社のＲＩＳＣ ＳＹＳＴＥＭ／６０００
（縮小されたインストラクションを持つコンピュータ・
システム、あるいは、ＲＩＳＣベースのワークステーシ
ョン）であってよい。ＡＩＸオペレーティング・システ
ムはＡＴ＆Ｔ社のＵＮＩＸオペレーティング・システ
ム、バージョン５．２で動作されるアプリケーション・
インターフェース・レベルと互換性を持つている。ＲＩ
ＳＣベースのパーソナル・コンピュータの種々のモデル
は、例えばＩＢＭ社で発行された「RISC System/6000、
7073 and 7016 POWERstation and POWERserver Hardwar
e Technical Reference（注文番号ＳＡ２３−２６４４
−００）と題する刊行物など多くの刊行物に記載されて
いる。ＡＩＸオペレーティング・システムは、１９８５
年１１月にＩＢＭ社で発行された「AIX Operating Syst
em Technical Reference」と題する刊行物の第１版など
の刊行物に記載されている。ＵＮＩＸオペレーティング
・システムのデザインの細部は、プレンティス・ホール
社（Prentice Hall）によって１９８６年に発行された
バッハ（Maurice J. Bach）著の刊行物「Design of the
Unix Operating System」に記載されている。 【００１６】本発明の特定の実施例において、本発明
は、ＩＢＭ社のシステム・ネットワーク・アーキテクチ
ャ（ＳＮＡ）、より詳細に言えば「SNA LU 6.2 Advance
d program to Program communication（ＡＰＰＣ）」に
よって相互接続されたＩＢＭ社の複数個のＲＩＳＣシス
テム／６０００の中で実行される。ＳＮＡは「イーサネ
ット」、ゼロックス社によって開発されたローカル・エ
リア・ネットワーク（ＬＡＮ）、またはＳＤＬＣ（Sync
hronous Data Link Control）をリンク・レベルとして
使用する。ローカル・エリア・ネットワークの簡単な説
明は、プレンティス社のブラデイ（Robert J. Brady）
により１９８３年に刊行されたジョーダン（Larry E. J
ordan）及びチャーチル（Bruce Churchill）共著の「Co
mmunications and Networking for the IBM PC」と題す
る刊行物に記載されている。本発明は上述の刊行物に記
載された技術をベースとして説明されるけれども、本発
明の技術は、イーサネットＬＡＮ、またはＩＢＭのＳＮ
Ａ以外の他のネットワークによって相互接続されたＩＢ
Ｍ社のＲＩＳＣベースのパーソナル・コンピュータ以外
の他の異なったコンピュータを使用して実施することが
できるのは注意を払う必要がある。従って、例えば本発
明はＯＳ／２オペレーティング・システムの下で動作す
るＩＢＭ社のＰＳ／２コンピュータの種々のモデルにお
いても実施可能である。ＰＳ／２コンピュータのグルー
プ及びＯＳ／２オペレーティング・システムに関する情
報は、ＩＢＭ社で発行された「Technical Reference Ma
nual Personal Systems/2 Model 50、 60 Systems」と題
する刊行物（部品番号６８Ｘ２２２４、注文番号Ｓ６８
Ｘ−２２２４）や、「OS/2 2.0 Technical Library、 Pr
ogramming Guide Volumes 1-3 Version 2.00」と題する
刊行物（注文番号１０Ｇ６２６４、１０Ｇ６４９５及び
１０Ｇ６４９４）に記載されている。 【００１７】図１を再度参照して説明を続けると、クラ
イアント１０及びサーバ１２の各々は、前者がサービス
を要求しているか、または後者がサービスを供給するか
に基づいてクライアント、またはサーバとして動作す
る。通常、クライアント処理は、遠隔手続の呼び出し
（ＲＰＣ）を用いてサーバ処理からのサービスを要求す
る少なくとも１つのクライアント処理を含んでいる。然
しながら、多くのＤＣＥのアプリケーションは、「クラ
イアント」及び「サーバ」処理の両方が同じホスト・コ
ンピュータ中で動作するような態様で書かれている。こ
れは、図１においてクライアント／サーバ１５によって
示されている。クライアント／サーバ１５中のサーバ処
理のために意図されたクライアント処理からのＲＰＣ
は、下記の説明を行なう便宜上、「ローカル」、または
「ローカルＲＰＣ」と称される。 【００１８】従来の技術のＯＳＦでＤＣＥのＲＰＣ機構
において、ローカルＲＰＣであるか否かに拘わらず、す
べてのＲＰＣは、ネットワーク・ベース（即ちｉｐベー
ス）のプロトコル・シーケンス「ncacn_ip_tcp」か、ま
たは「ncadg_ip_udp」を用いて遂行されてきた。この場
合、「ncacn」は接続式のＯＳＦでＤＣＥのＲＰＣプロ
トコルを参照し、そして「ncadg」は非接続式のＯＳＦ
でＤＣＥのＲＰＣプロトコルを参照する。これらのプロ
トコルを使用した時、「ip」と言う術語によって明らか
なように、「インターネット・アドレス・ファミリィ
（ＡＦ＿ＩＮＥＴ）」の通信領域が使用される。各プロ
トコル・シーケンスの最後のコンポーネントはソケット
・タイプを参照し、従って、例えば「udp」はデータグ
ラムを参照する。ＲＰＣに応答して、呼び出しディレク
トリ・サービスdaemon（call directory service daemo
n-ＣＤＳＤ）は、サーバ処理の位置をネットワーク・ア
ドレスとして特定し、かつ、サーバ処理が行なわれるポ
ートのポート番号を特定する、所謂「バインディング・
ハンドル」を戻す。また、バインディング・ハンドルは
ＲＰＣによって要求されたサーバ処理を識別する。次
に、バインディング・ハンドルは、クライアント処理及
びサーバ処理間のパス（path）を定義するためのＲＰＣ
機構によって使用される。このパスは、ソケットをオー
プンするために、ＡＦ＿ＩＮＥＴのipベース（即ち、ネ
ットワーク層ベース）のプロトコル・シーケンスを用い
て定義される。このパスのループは、クライアント処理
から、伝送層及びネットワーク層を通ってネットワーク
に出た後に、サーバ処理が行なわれるホスト・コンピュ
ータと関連された層に戻る。 【００１９】従って、クライアント及びサーバ処理が同
じホスト・コンピュータの中に存在したとしても、伝送
（ＴＣＰまたはＵＤＰ）層及びネットワーク（ＩＰ）層
はループ・バックのメッセージを送るために使用され
る。この態様は図２に示されている。本発明に従うと、
ｉｐベースのプロトコル・シーケンスを使用する代わり
に、新しいプロトコル・シーケンス「ncacn_unix_strea
m」が、ローカルＲＰＣを行なうクライアント処理に戻
される。この新しいプロトコル・シーケンスは、ＵＮＩ
Ｘネットワーク・アドレス・ファミリィ（ＡＦ＿ＵＮＩ
Ｘ）の通信領域を使用することによって伝送層及びネッ
トワーク層の通過を回避する。ＡＦ＿ＵＮＩＸを有する
オペレーティング・システム核は、同じホスト・コンピ
ュータ中の２つの処理間の通信を橋絡するタスクを取り
扱う。ＡＦ＿ＵＮＩＸはクライアント処理とサーバ処理
との間の通信（ＩＰＣ）を実行するために望ましい技術
であるけれども、他のＯＳのＩＰＣ機構（共有メモリと
か、メッセージの待ち行列）も同じように使用すること
ができる。どのような場合でも、ローカルＩＰＣ機構の
使用は、伝送層及びネットワーク層を通過するループバ
ック呼び出しを行なうよりも顕著に速度を高めるから、
性能が改善されるのは明らかである。本発明のこの機能
は図３に示されている。 【００２０】ncacn_unix_streamプロトコル・シーケン
スは、同じホスト・コンピュータ中に存在するＤＣＥの
アプリケーション処理の間で行なわれるＲＰＣだけでし
か使用されない。若しサーバ処理が同じホスト・コンピ
ュータ中に存在しなければ、ＲＰＣのランタイムは、nc
acn_unix_streamのバインディング・ハンドルをクライ
アントのアプリケーションに戻さない。何故ならば、nc
acn_unix_streamプロトコル・シーケンスは、同じホス
ト・コンピュータ中のＤＣＥのアプリケーションで使用
するためのものであり、これらのバインディング・ハン
ドルはネットワーク・アドレスを含んでいないからであ
る。また、ncacn_unix_streamのバインディング・ハンド
ルの終端部は、ＵＮＩＸソケット・ファイルへのフル・
パス名（フルネーム）として表示される。この独特のソ
ケット・ファイルはクライアント処理及びサーバ処理間
で設定された各組み合わせに対して使用される。これら
のソケット・ファイルは、デフォルトで、ディレクト
リ、var/dce/rpc/soket中にオープンされる。また、デ
フォルトで、各ソケット・ファイルの名称は、各ファイ
ル名の独特さを保証する普遍的に独特のオブジェクト識
別子（object universal unique identifier-オブジェ
クトＵＵＩＤ）である。オブジェクトＵＵＩＤは、オブ
ジェクトＵＵＩＤの発生ルーチンによって作成された実
質的に長くランダムな数字である。ＲＰＣのランタイム
がncacn_unix_streamのバインディング・ハンドルに対
して終端部を割り当てる時、このバインディング・ハン
ドルは、独特であることが保証されているオブジェクト
ＵＵＩＤである。これは、ソケット・ファイルが１つの
ＤＣＥのアプリケーションの２回の呼び出しについて再
使用されることはないことを意味する。 【００２１】ＵＮＩＸベースのオペレーティング・シス
テムにおいて、オペレーティング・システム（ＯＳ）核
は、ＯＳ核がユーザのための仕事をする前に、ファイル
をオープンすることをユーザに要求する。本発明によっ
て作成されたソケット・ファイルは、ＯＳ核のための位
置ホルダとして使用される長さゼロのファイルである。
独特の各ソケット・ファイルは、作成されたファイル・
システム中のinodeエントリを占領する。ＯＳ核は、フ
ァイル・システムにおいて位置ホルダとしてソケット・
ファイルを使用し、そして、ＲＰＣを実行するためにク
ライアント及びサーバ処理間のデータを転送しかつ受信
するためのそれ自身のデータ構造を制御することによっ
てＲＰＣを遂行する。従って、上述の目的のために、Ｏ
Ｓ核は、例えば「Mbuf」データ構造を使用することがで
きる。 【００２２】下記の例示は、本発明において有用なncac
n_unix_streamストリングのバインディング・ハンドル
の例を示している。 ncacn_unix_stream:[] ncacn_unix_stream:[/var/dce/rpc/socket/0063980e-35
7b-le07-878b-10005a4f3bce] 【００２３】従って、このプロトコル・シーケンスは、
接続式の「ncacn」ＲＰＣプロトコル・シーケンスと、
ＡＦ＿ＵＮＩＸ通信領域（「unix」コンポーネントによ
って識別される）と、「stream」タイプのソケットとに
再構成することを含んでいる。上述の第１の例示におい
て、終端部（即ち、括弧［ ］内のデータ）は空であ
る。第２の例示において、終端部はデフォルトのソケッ
ト・ディレクトリ「/var/dce/rpc/socket/」及びオブジ
ェクトＵＵＩＤとを識別する。 【００２４】従って、終端部は、/var/dce/rpc/socket
ディレクトリ中のオブジェクトＵＵＩＤでなければなら
ないという必要はない。インターフェースの定義言語
（Interface Definition Language-ＩＤＬ）仕様のファ
イル中の「終端部」の属性は、独特のファイルへのパス
名を特定するために使用することができる。あるいは、
アプリケーションは、コマンド・ラインの引数としてnc
acn_unix_streamストリングのバインディング・ハンド
ルを取り、そして、このバインディング・ハンドルを、
rpc_binding_from_string_binding()ルーチンを使用し
たバインディング・ハンドルへ変換することができる。
ユーザにより特定されるソケット・ファイルのパスの例
は下記の通りである。 ncacn_unix_stream:[/var/dce/rpc/socket/foo] ncacn_unix_stream:[/tmp/6094] ncacn_unix_stream:[/5423] 【００２５】最後の場合において、終端部は絶対的なパ
スによって表示されていないから、ncacn_unix_stream:
[/var/dce/rpc/socket/5423]が想定され、ソケット・フ
ァイルを作成するために、これを使用していることには
注意を向けられたい。また、終端部マップ中のエントリ
は絶対的なパスを持っている。このことは、相対的なパ
スが最初に使用される前に、相対的なパスは、絶対的な
パスまで常に拡大されるから、２つのフォームを相互に
交換可能に使用した場合でも問題を生じることはない。 【００２６】以下に、ncacn_unix_streamプロトコル・
シーケンスの特徴を詳細に説明する。本発明に従って、
ＲＰＣランタイム・ライブラリは、クライアント及びサ
ーバ処理が同じホスト・コンピュータ中に存在する場合
を認識し、そして、適用可能である場合には、ncacn_un
ix_streamプロトコル・シーケンスの使用を、下記のよ
うに「促進」する。 ＊ rpc_ns_binding_import_next()が他のプロトコル・
シーケンスのためのバインディング・ハンドルを戻す前
に、rpc_ns_binding_import_next()は、すべてのncacn_
unix_streamのバインディング・ハンドルを戻す。 ＊ rpc_ns_binding_lookup_next()は、戻されたバイン
ディング・ベクトルの低位の位置中のすべてのncacn_un
ix_streamのバインディング・ハンドルを戻す。例え
ば、若し、戻されたバインディング・ベクトルが５個の
バインディング・ハンドルで構成されており、そして５
個の内の２個がncacn_unix_streamのバインディング・
ハンドルであるならば、ncacn_unix_streamのバインデ
ィング・ハンドルは、アレイのエレメント［０］及び
［１］を占領し、そして他のプロトコル・シーケンスの
ためのバインディング・ハンドルは残りのエレメント
［２］、［３］及び［４］を占領する。ncacn_unix_str
eamのバインディング・ハンドルは、バインディング・
ベクトルの低位のエレメント中にあるけれども、残りの
バインディング・ハンドルの順序付けは、確定されない
ことには注意を向けられたい。 ＊ rpc_ns_binding_select()は、ncacn_unix_streamの
バインディング・ハンドルのすべてが使用されるまで、
バインディング・ベクトルからncacn_unix_streamのバ
インディング・ハンドルを選択する。次に、これは、他
のプロトコル・シーケンスのバインディング・ハンドル
の間からランダムにバインディング・ハンドルを選択す
る通常の方針を再開始する。 【００２７】ＲＰＣのランタイムがncacn_unix_stream
に与える上述の特性は、ＤＣＥのアプリケーションに性
能改善を与える正味の効果を持っている。従来のアプリ
ケーションによって、これらの特性は認識されるもので
はない。これらの特性は、アプリケーションに対して実
際上可視的なものではなく、従来のプログラムに対して
如何なる変更も要求しない。 【００２８】これらの特性の幾つかを遂行するためにＲ
ＰＣを管理する方法を、図４を参照して以下に説明す
る。図４に示された方法は、ＯＣＦでＤＣＥの遠隔手続
の呼び出し（ＲＰＣ）を用いてクライアント処理がサー
バ処理からのサービスを要求する分散された計算処理環
境の中にあるクライアント及びサーバ処理間の通信を管
理する。クライアント処理は、伝送層及びネットワーク
層を有する物理的なネットワークに接続されたホスト・
コンピュータ中に存在する。ホスト・コンピュータはＵ
ＮＩＸベースのオペレーティング・システムをサポート
することが望ましい。 【００２９】図４に示した方法は、遠隔手続の呼び出し
によって識別されたサーバ処理がホスト・コンピュータ
中に存在しているか否かを検出するステップ３０におい
て開始する。若し、サーバ処理がホスト・コンピュータ
中に存在するならば、図１に示したクライアント／サー
バ１５が使用されており、ステップ３２において、図２
のＲＰＣは、バインディング・ハンドルの第１のセット
及び第２のセットを含むバインディング・ハンドルのベ
クトルをクライアント処理に戻す。第１のセットの各バ
インディング・ハンドルは、伝送層及びネットワーク層
を使用することなく、クライアント処理及びサーバ処理
間の通信（ＩＰＣ）のパスを設定するプロトコル・シー
ケンスを含んでおり、そして、第２のセットの各バイン
ディング・ハンドルは、伝送層及びネットワーク層を使
用してクライアント処理及びサーバ処理間のパスを設定
するプロトコル・シーケンスを含んでいる。ステップ３
４において、第１のセットを用いて遠隔手続の呼び出し
の実行が試行される。若しこの実行が失敗したならば、
ステップ３６において、第１のセット中のすべてのバイ
ンディング・ハンドルが用い尽くされたか否かを決定す
るテストが行なわれる。若しこのテストの結果が否定的
であれば、ルーチンはループ・バックして、他の「ncac
n_unix_stream」プロトコル・シーケンスによってＲＰ
Ｃを実行する試みを行なう。ステップ３６において、若
しテスト結果が肯定的である、即ち、すべての第１のセ
ットのプロトコル・シーケンスが用い尽くされたことが
表示されたならば、図４に示した方法は、遠隔手続の呼
び出しの実行を試行するために第２のセット中のバイン
ディング・ハンドルの１つを使用するステップ３８に進
む。第２のセット中のバインディング・ハンドルはラン
ダムにアクセスされる。 【００３０】ncacn_unix_streamプロトコル・シーケン
スが利用されない条件は、下記の通りである。 ＊ ＤＣＥのサーバ・アプリケーションが、特定のプロ
トコル・シーケンスをサポートすることを明白に特定し
ている場合。この１例は、プロトコル・シーケンスを制
限するために、サーバによってrpc_server_use_protseq
()が使用されている場合であり、これは、利用可能なす
べてのプロトコル・シーケンスをサブセットとしてサポ
ートする。 ＊ バインディング・ハンドルの特定のコンポーネント
を比較することによって、ＤＣＥのクライアント・アプ
リケーションが名称空間から戻されたバインディング・
ハンドルのうちから選択する場合。この１例は、バイン
ディング・ハンドルのネットワーク・アドレスを比較す
る例である。ncacn_unix_streamバインディング・ハン
ドルはネットワーク・アドレスを含んでいないから、こ
の比較動作は決して成功しない（クライアント・アプリ
ケーションが‘‘‘‘ ストリングに対して比較されな
ければ）。他の例は、各バインディング・ハンドルにつ
いてチェックを行なって、クライアントが特定のプロト
コル・シーケンスを検索する場合である。上述の両方の
例は、通常、rpc_binding_to_string_binding()のルー
チンを使用し、次に、バインディング・ハンドルを作成
するコンポーネントのストリング・フォーマットを比較
することによって遂行される。 【００３１】性能を向上するために、rpc_ns_binding<i
mport/lookup>_next()ルーチンから戻されたncacn_unix
_streamバインディング・ハンドルは、すべて結合され
る。これは、バインディング・ハンドルがＲＰＣの終端
部マップから送られることと、バインディング・ハンド
ル中に終端部を持っていることによる。ncacn_unix_str
eamのバインディング・ハンドルの情報は、ＲＰＣのＡ
ＰＩルーチン、rpc_ns_binding_export()が呼び出され
た時、ＣＤＳの名称空間のデータベースに転送されな
い。この理由は、クライアント及びサーバのＤＣＥのア
プリケーションが同じホスト・コンピュータ中にある時
にのみ、ncacn_unix_streamのバインディング・ハンド
ルが使用可能であるからである。ＣＤＳの名称空間は、
「ＤＣＥセル」中のすべての装置中のＤＣＥのアプリケ
ーションによって読み取ることができるから、ＣＤＳの
名称空間のデータベース中のncacn_unix_streamのバイ
ンディング・ハンドルは、遠隔サーバと通信する必要の
あるクライアントが使用する必要はない。 【００３２】その代わりに、ncacn_unix_streamのバイ
ンディング・ハンドルは、ＤＣＥのサーバのアプリケー
ションがＲＰＣのＡＰＩルーチン、rpc_ep_register()
を呼び出した時に、ＲＰＣの終端部マップのデータベー
スの中にレジスタされるだけである。これは、ホスト・
コンピュータの特別情報をストアするためにより大きな
論理空間を作るＤＣＥセル中のすべてのホスト・コンピ
ュータ中で動作するＲＰＣの終端部マップdaemonが存在
するためである。両立性を持つサーバのバインディング
・ハンドル用のＣＤＳの名称空間を、クライアントが問
い合せた時、ＲＰＣのランタイムは、その呼び出しがロ
ーカル・ホスト・コンピュータのサーバ用であるか否か
を決定する。若し呼び出しがローカル・ホスト・コンピ
ュータ中のサーバ用であれば、ＣＤＳの名称空間からの
すべてのバインディング・ハンドルを戻すことに加え
て、ＲＰＣのランタイムは、両立性を持つncacn_unix_s
treamバインディング・ハンドルがあるか否かを決定す
るためにＲＰＣの終端部マップの検索に進む。若し両立
性を持つバインディング・ハンドルがあれば、このバイ
ンディング・ハンドルは、ＣＤＳの名称空間から戻され
るバインディング・ハンドル以上の特性が与えられる。
若しクライアント及びサーバが異なったホスト・コンピ
ュータ中にあれば、終端部マップの検索が、使用可能な
バインディング・ハンドルを検出することはあり得ない
から、この検索は行なわれない。 【００３３】ＤＣＥのサーバ・アプリケーションが通常
の条件の下で存在する場合、そのアプリケーションは、
終端部が出る前に、他のものと同様、ＲＰＣの終端部マ
ップからのそのアプリケーションの終端部をレジスタし
ない。ncacn_ip_tcp及びncadg_ip_udpのようなｉｐベー
スのプロトコルの場合において、ＤＣＥのアプリケーシ
ョンが聴取していたポートは、オペレーティング・シス
テムによって消去されるから、ポートを解放するため
に、アプリケーションの動作は必要としない。ncacn_un
ix_streamの終端部は、ユーザ用空間のファイルであ
り、これらの終端部は、ＤＣＥのアプリケーションが存
在する場合には、オペレーテイング・システムによって
除去されない。 【００３４】ＲＰＣのランタイムによって、ncacn_unix
_streamバインディング・ハンドルに終端部を割り当て
る時、既に述べたように、バインディング・ハンドル
は、独特さを保証するオブジェクトＵＵＩＤである。こ
のことは、１つのＤＣＥのアプリケーションが２度呼び
出された場合でも、１つのソケット・ファイルが２度重
複して使用されることがないことを意味する。従って、
失効したソケット・ファイルが残されると言う事実は、
短い時間の間では実際問題とはならない。然しながら、
時間の経過と共に、これらの失効ソケット・ファイルは
累積する。既に述べたように、このソケット・ファイル
はゼロの長さを持つファイルであるけれども、各ソケッ
ト・ファイルは、それが作成されたファイル・システム
中のinodeのエントリを占領する。従って、これらの失
効ソケット・ファイルを除去するためのある種の手段を
設けることが望ましい。この除去処理は、ＲＰＣの終端
部のマップ手段（ＲＰＣのdaemon）によって行なわれ
る。 【００３５】/var/dce/rpc/socketディレクトリ中のソ
ケット・ファイルだけが自動的に除去されるのは注意を
払う必要がある。若しＤＣＥのアプリケーションが、nc
acn_unix_streamのディレクトリ以外のディレクトリを
用いてそのncacn_unix_streamの終端部を作成したなら
ば、失効した終端部が除去されたことを保証すること
は、アプリケーションか、またはアプリケーションのユ
ーザの責任である。これは、rpc.cleanユティリティを
使用して行なわれる。rpc.cleanユティリティは、失効
したソケット・ファイルに対してチェックされるべきデ
ィレクトリを、ユーザが特定できることを可能にする。
このユティリティはディレクトリを検索して、検出され
たすべての失効ソケット・ファイルを除去する。このユ
ティリティは、ＲＰＣの終端部マップが行なうのと同じ
除去動作を遂行する。ＤＣＥの管理スクリプト、dce.cl
ean、rc.dce、またはrmdceが実行される場合には、失効
したソケット・ファイルの蓄積を回避する付加的な保全
手段として、rpc.cleanユティリティが含まれる。 【００３６】本発明の実施例において、ローカルＲＰＣ
の性能は１０％乃至４０％の範囲まで改善された。これ
は、ＤＣＥの多くの内部活動（これらの活動はＲＰＣの
daemon及びデータ保護／名称空間サービスを持つ通信を
含む）が同じコンピュータ中で実行される処理の間でＲ
ＰＣを用いて遂行されるので、ＤＣＥのシステム全体の
性能を向上する。 【００３７】本発明の良好な１実施例は、パーソナル・
コンピュータ、またはワークステーションのランダム・
アクセス・メモリ中のコード・モジュールの常駐位置中
のインストラクション・セットとして実施される。コン
ピュータ・システムによって必要とされるまで、このイ
ンストラクション・セットは、例えばハードディスク駆
動装置とか、または光学ディスク（ＣＤ ＲＯＭで使用
される）とかフロッピ・ディスク（フロッピ・ディスク
駆動装置で使用される）などの交換可能なメモリ等の他
のコンピュータ・メモリ中にストアすることができる。 【００３８】本発明のこれ以上の細部は下記の実施例に
記載されている。この実施例はncacn_unix_streamプロ
トコル・シーケンスのためにＲＰＣのサポートをどのよ
うに付加するかを記載している。既に述べたように、こ
のプロトコル・シーケンスはＵＮＩＸ領域のソケットを
使用している。 【００３９】 【実施例】 ０．１．１ 外部インターフェースの説明 ＲＰＣのランタイム及びＲＰＣＤの外部インターフェー
スは下記のように変更される。ユーザは、既にサポート
されているプロトコル・シーケンスに加えて付加的なプ
ロトコル・シーケンスを特定する新しい能力を持つこと
になる。この新しいプロトコル・シーケンスは「ncacn_
unix_stream」プロトコル・シーケンスと名付けられ
る。ＡＰＩの機能パラメータ、環境的な変数、あるいは
コマンド・ラインの引数が、プロトコル・シーケンスの
ためのストリング・フォーマットの仕様を用いている場
合には、ストリング「ncacn_unix_stream」を使用する
ことができる。 【００４０】０．１．２ 内部デザインの説明 本発明に従ってＲＰＣを強化することは、クライアント
及びサーバが同じホスト・コンピュータ中に存在する時
に使用される新しいプロトコル・シーケンス（ncacn_un
ix_stream）のためのサポートを付加する。 【００４１】このＲＰＣの強化は、ユーザに対して事実
上目で見ることはできず、従来のクライアント／サーバ
・アプリケーションに対して逆方向の両立性（compatib
le）を持っている。 【００４２】本発明はＩＢＭのＯＳ／２プラットフォー
ムのような他のプラットフォームにも使用することがで
きる。ＯＳ／２は、ＵＮＩＸ領域（ＭＰＴＳを介して）
をサポートする能力を持っている。ＯＳ／２中の共通ポ
ート用プラットフォーム（Common Porting Platform-Ｃ
ＰＰ）のＤＬＬは、ＯＳ／２を変更することなく、殆ど
すべてのＵＮＩＸ特有のサブルーチン・コールを使用す
ることができる。 【００４３】ＲＰＣのランタイム・ライブラリのデザイ
ンは、従来のコードに殆ど変更を加えることなく、新し
いプロトコル・シーケンスを付加することができるよう
な設計である。このことは、（１）モジュラー・データ
構造を持つ手段と、（２）エントリ・ポイント・ベクト
ルを使用する手段との２つの手段を介して達成されてい
る。モジュラー・データ構造は、プロトコル・シーケン
スを作る種々のコンポーネントに関して両立する機構を
与えることによって、新しいプロトコル・シーケンスを
付加する作業を容易にする。ＲＰＣのランタイム・コー
ドの大部分はすべてのプロトコルに対して共通なので、
エントリ・ポイント・ベクトルを使用することによっ
て、プロトコル特有のルーチンは、機能のアレイ中のイ
ンデックスを介してライン中でアクセスすることができ
る。プロトコルの識別子（ｉｄ）は、エントリ・ポイン
ト・ベクトル中のインデックスとして使用される。新し
いプロトコル・シーケンスは、そのプロトコル・シーケ
ンス特有の処理を行なうための新しいルーチンを付け加
えることが必要である。 【００４４】ncacn_unix_streamプロトコル・シーケン
スは、ＵＮＩＸネットワーク・アドレス・ファミリィ
（ＡＦ＿ＵＮＩＸ）と、SOCK_STREAMのソケット・タイ
プとを用いて作られる。ソケット・アドレスは、処理間
通信の構造としての完全なパス名指定を用いた構造sock
addr_unを使用する。クライアント及びサーバは、この
プロトコル・シーケンスを使用するために同じホスト・
コンピュータ中に存在しなければならない。このプロト
コル・シーケンスは、接続式のものであり、ＣＮプロト
コル識別子を使用する。 【００４５】本明細書の以下の記載は、新しいプロトコ
ル・シーケンスを実施するために変更を必要とするＲＰ
Ｃのソース・ファイルを説明している。この説明におい
て、可能性ある変形例を広範囲に捕えて説明を開始し、
特定した狭い範囲の変形例に限定したファイルをリスト
する試みがなされている。 【００４６】０．１．２．１ src/rpc/runtime/com.h これは従来のファイルである。下記の定数識別子を付加
することが必要である。これらの定数は、適正な構造に
アクセスするためと、エントリ・ポイント・ベクトルを
適正にインデックスするためにＲＰＣのランタイム・コ
ードを通じて使用される。 【００４７】ＲＰＣのプロトコル・シーケンスの識別子
定数は、 #define rpc_c_protseq_id_ncacn_unix_stream 5 であり、ＲＰＣのプロトコル・シーケンスのストリング
定数は、 #define rpc_protseq_ncacn_unix_stream "ncacn_unix_stream" であり、ＲＰＣのネットワーク・アドレス・ファミリィ
定数は、 #define rpc_c_naf_id_unix 1 である。 【００４８】０．１．２．２ src/rpc/runtime/comp.c これは従来のファイルである。以下のテーブル・エレメ
ントを付加することが必要である。これらのテーブル・
エレメントは「ＵＮＩＸ領域アドレス・ファミリィ」及
びncacn_unix_streamプロトコル・シーケンスのサポー
トを付加する。 【００４９】大域アレイ、rpc_g_protseq_id[]は下記の
ように拡張される。 GLOBAL rpc_protseq_id_elt_t rpc_g_protseq_id[rpc protseq_id_max] = { .../* 従来のテーブル・エレメント */ { 0, rpc_c_protseq_id_ncacn_unix_stream, rpc_c_protocol_id_ncacn, rpc_c_naf_id_unix, rpc_c_network_protocol_id_uns /* 特定されない */ rpc_protseq_ncacn_unix_stream } {; 【００５０】大域アレイ、rpc_g_naf_id[]は下記のよう
に拡張されなければならない。 GLOBAL rpc_naf_id_elt_t rpc_g_naf_id[rpc_naf_id_max] = { ... */ 従来のテーブル・エレメント */ { rpc_unix_init, rpc_c_naf_id_unix, rpc_c_network_if_id_stream, NULL } ... */ 従来のテーブル・エレメント */ }; 【００５１】 ０．１．２．３ src/rpc/runtime/unixnaf.c このファイルは、作成する必要のある新しいファィルで
ある。このファイルは、「ＵＮＩＸ領域のネットワーク
・アドレス・ファミリィ」のために必要なエントリ・ポ
イント・ベクトルのルーチンのためのサポートを与え
る。rpc_naf_epv_tと呼ばれるＲＰＣ構造があり、これ
は以下のように定義される。 typedef struct { rpc_naf_addr_alloc_fn_t naf_addr_alloc; rpc_naf_addr_copy_fn_t naf_addr_copy; rpc_naf_addr_free_fn_t naf_addr_free; rpc_naf_addr_set_endpoint_fn_t naf_addr_set endpoint; rpc_naf_addr_inq_indpoint_fn_t naf_addr_inq endpoint; rpc_naf_addr_set_netaddr_fn_t naf_addr_set netaddr; rpc_naf_addr_inq_netaddr_fn_t naf_addr_inq netaddr; rpc_naf_addr_set_options_fn_t naf_addr_set options; rpc_naf_addr_inq_options_fn_t naf_addr_inq options; rpc_naf_desc_inq_addr_fn_t naf_desc_inq_addr; rpc_naf_desc_inq_network_fn_t naf_desc_inq network; rpc_naf_inq_max_tsdu_fn_t naf_inq_max_tsdu; rpc_naf_get_broadcast_fn_t naf_get_broadcast; rpc_naf_addr_compare_fn_t naf_addr_compare; rpc_naf_inq_pth_unfrg_tpdu_fn_t naf_inq_max_pth unfrg_tpdu; rpc_naf_inq_loc_unfrg_tpdu_fn_t naf_inq_max_loc unfrg_tpdu; rpc_naf_set_pkt_nodelay_fn_t naf_set_pkt nodelay; rpc_naf_is_connect_closed_fn_t naf_is_connect closed: rpc_naf_twr_flrs_from_addr_fn_t naf_tower_flrs from_addr; rpc_naf_twr_flrs_to_addr_fn_t naf_tower_flrs_to addr; rpc_naf_desc_inq_peer_addr_fn_t naf_desc_inq peer_addr; }rpc_naf_epv_t *rpc_naf_epv_p_t; 【００５２】各ＮＡＦはこの構造をロードする初期化ル
ーチンを持ち、そして、特定されたＮＡＦのためのrpc_
g_naf_id[]テーブル・エントリにこのＮＡＦを加える。
このポイントから、「ＵＮＩＸネットワーク・アドレス
・ファミリィ」に対するすべての呼び出しはこれらのＥ
ＰＶを通して行なわれる。 【００５３】下記のルーチンが「ＵＮＩＸネットワーク
・アドレス・ファミリィ」を実行するために作成されな
ければならない。 【００５４】 ０．１．２．３．１ rpc_unix_init() PRIVATE void rpc_unix_init(naf_epv,status) rpc_naf_epv_p_t*naf_epv; unsigned32*status: { Load the rpc_unix_eqv structure with the static routines defined in this file(unixnaf.c). （このファイル（unixnaf.c）において定義されている静的なルーチンに よってrpc_unix_epv構造をロードせよ。） Return the NAF epv, so it can be added to the global NAF table. （ＮＡＦ＿ＥＰＶを大域ＮＡＦテーブルに加えることができるように、 NAF epvを戻せ。） } 【００５５】 ０．１．２．３．２ addr-alloc() INTERNAL void-addr-alloc(rpc_protseq_id_naf_id, endpoint,netaddr,network_options,rpc_addr,status) rpc_addr_p_t src_rpc_addr; rpc_addr_p_t*dst_rpc_addr; unsigned32*status; { Alocate memory for the destination RPC address （宛先ＲＰＣアドレスのためのメモリを割り当てよ。） Copy source rpc adress to destination rpc address. （ソースＲＰＣアドレスを宛先ＲＰＣにコピーせよ。） } 【００５６】 ０．１．２．３．４ addr_free() INTERNAL void addr_free (rpc_addr,status) rpc_addr_p_t *rpc_addr; unsigned 32 *status; { Free memory of RPC addr and set the RPC address pointer to NULL. （ＲＰＣアドレスのメモリを解放し、そしてＲＰＣアドス・ポインタ を無効にセットせよ。） } 【００５７】 ０．１．２．３．５ addr_set_endpoint() INTERNAL void add_set_endpoint (endpoint,rpc addr,status) unsigned_char_p_t endpoint; rpc_addr_p_t *rpc_addr; unsigned32 *status; { Check for the special case where endpoint is a pointer to a zero length string (as opposed to NULL). In this case, the caller is requesting that the endpoint be zeroed out of the rpc_addr structure, so just set rpc_addr->sa.sun_path[0] = '?0' and return. （終端部が長さゼロのストリングを指示するポインタである特別の場合 をチェックせよ（NULLとは反対に）。この場合、呼び出し側は、終端部 がrpc_addr構造をゼロにすることを要求するので、rpc_addrをsa.sun _path[0] = '?0' にセットし、これを戻せ。） BEGIN AIX ONLY （ＡＩＸのみを開始せよ） Check for the existence of the RPC_UNIX_DOMAIN DIR_PATH environment variable. （RPC_UNIX_DOMAIN_DIR_PATH環境変数の存在をチェックせよ。） if it exists then use it as the base for file name paths. （若し環境変数が存在するならば、その変数をファイル名のパスのた めのベースとして使用せよ。） if it dosenot exist, then use the default: /var/dce/rpc/socket on AIX. （若しこの変数が存在しなければ、ＡＩＸ中のディホルト、/var/dce/ rpc/socketを使用せよ。） if an endpoint was specified, then check if it is a full path (i.e. starts with '?' chracter) or just a relative filename. （若し終端部が特定されたならば、その終端部はフル・パス名であるか （即ち、‘／’記号で開始するか）、あるいは相対的なファイル名であ かるかをチェックせよ。） if it is a relative path, then append it to the base path. （若し終端部が相対的なパスならば、それをベースパスに付けよ。） if it is an absolute path, then overwrite what has been given as the path up to this point, no matter what it is. （若し終端部が絶対的なパスであれば、このポイントまでのパスとして 与えられているものをどんなものであれ書き重ねよ。） END AIX ONLY （ＡＩＸのみを終了せよ） if no endpoint was given, create one using uuid create() and uuid_to_string(). （若し終端部が与えられなければ、uuid_create()及びuuid_to_string() を使用したものを作成せよ。） Now have a 32 chrater uuid string as the filename. （現在、ファイル名として３２ＵＵＩＤストリングを持っている。） append the filename to the path. （パスにそのファイル名を付けよ。） Now that a full path has been built, add the pathname to the RPC addr structure (sa.sun_path) and set the length of the filename. （現在、フル・パス名が作成されており、そのパス名をＲＰＣのアドレ ス構造（sa.sun_path）に付加し、そして、ファイル名の長さを設定せ よ。） } 【００５８】 ０．１．２．３．６ addr_inq_endpoint() INTERNAL void addr_inq_endpoint (rpc_addr, endpoint,status) rpc_addr_p_t rpc_addr; unsigned_char_t**endpoint; unsigned32*status: { Allcate memory for the filename (i.e. the endpoint). （ファイル名（即ち、終端部）のためのメモリを割り当てよ。） strcpy() the filename from the RPC addr structure into the newly allocated string. （ＲＰＣのアドレス構造からファイル名を新しく割り当てられたストリン グの中にstrcpy()せよ。） } 【００５９】 ０．１．２．３．７ addr_set_netaddr() INTERNAL void addr_set_netaddr(netaddr,rpc addr,status) unsigned_char_p_t netaddr; rpc_addr_p_t*rpc_addr; unsigned32*status; { これはno-op（不動作）のルーチンである。ＵＮＩＸ領域を使用する時に はnetaddrの概念はない。 このルーチンを必要とする他のＮＡＦ（ネットワーク・アドレス・ファ ミリィ）に対して両立性を持たせるために、このルーチンは存在しなければ ならない。 } 【００６０】 ０．１．２．３．８ addr_inq_netaddr() INTENAL void addr_inq_netaddr(rpc addr,netaddr,status) rpc_addr_p_t rpc_addr; unsigned_char_5**netaddr; unsegned32*status; { これはno-opのルーチンである。ＵＮＩＸ領域を使用する時にはnetaddr の概念はない。 このルーチンを必要とする他のＮＡＦに対して両立性を持たせるために 、このルーチンは存在しなければならない。 } 【００６１】 ０．１．２．３．９ addr_set_options() INTERNAL void addr_set_options(network_options,rpc addr,status) unsigned_char_p_t network_options; rpc_addr_p_t*rpc_addr; unsigned32*status; { これはno-opのルーチンである。ＵＮＩＸ領域を使用する時にはnetaddr の概念はない。 このルーチンを必要とする他のＮＡＦに対して両立性を持たせるために 、このルーチンは存在しなければならない。 } 【００６２】 ０．１．２．３．１０ addr_inq_options() INTERNAL void addr_inq_options(rpc_addr, network options, status) rpc_addr_p_t rpc_addr; unsigned_char_t **network_options; unsigned 32 *status; { これはno-opのルーチンである。ＵＮＩＸ領域を使用する時にはnetaddr の概念はない。 このルーチンを必要とする他のＮＡＦに対して両立性を持たせるために 、このルーチンは存在しなければならない。 【００６３】 ０．１．２．３．１１ inq_max_tsdu() INTENAL void inq_max_tsdu (naf_id, if type, protocol, max_tsdu, status) rpc_naf_id_t naf_id; rpc_network_if_id_t iftype; rpc_network_protocol_id_t protocol; unsigned 32 *max_tsdu; unsigned 32 *status; { これはno-opのルーチンである。このパケットはネットワーク上には出 ないので、ＩＰの設定には無関係である。 } 【００６４】 ０．１．２．３．１２ addr_compare() INTERNAL boolean addr_compare (addr1, addr2, status) rpc_addr_p_t addr1, addr2; unsigned 32 *status; { Compare the socket address file name paths of the 2 RPC addr passed in. （転送された２ＲＰＣアドレスのソケット・アドレスのファイル名のパ スを比較せよ。） Return TRUE or FALSE. （「真」または「偽」を戻せ。） } 【００６５】 ０．１．２．３．１３ inq_max_pth_unfrag_tpdu() INTERNAL void inq_max_pth_unfrag_tpdu (rpc_addr, iftype, protocol, max_tpdu, status) rpc_addr_p_t rpc_addr; rpc_network_if_id_t iftype; rpc_network_protocol_id_t protocol; unsigned32 *max_tpdu; unsigned 32 *status; これはno-opのルーチンである。パケットはネットワークから外に出ない から、ＩＰの設定には無関係である。 } 【００６６】 ０．１．２．３．１４ inq_max_loc_unfrag_tpdu() INTERNAL void inq_max_loc_unfrag_tpdu (naf_id,iftype,protocol,max_tpdu,status) rpc_naf_id_t naf_id; rpc_network_if_id_t iftype; rpc_network_protocol_id_t protocol; unsigned32*mas_tpdu; unsigned32*status; { これはno-opのルーチンである。パケットはネットワークから外に出ない から、ＩＰの設定には無関係である。 } 【００６７】 ０．１．２．３．１５ desc_inq_network() INTERNAL void desc_inq_network(desc,socket_type, protocol_id,status) rpc_socket_t desc; rpc_network_if_id_t *socket_type; rpc_network_protocol_id_t *protocol_id; unsigned32*status; { Call RPC_socket_get_if_id() to get the socket type. （ソケット・タイプを得るためにrpc_socket_get_if_id()を呼び出せ。 ） Based on the socket type, return the protocol id. In our case it will always be rpc_c_network protocol_id_uns (Unspecified). （ソケット・タイプに基づいて、プロトコルの識別子を戻せ。この実施 例において、これは、常に、rpc_c_network_protocol_id_uns（特定されて いない）である。） } 【００６８】 ０．１．２．３．１６ set_pkt_nodelay() INTERNAL void set_pkt_nodelay(desc,status) rpc_sicket_t desc; unsigned32*status; { これはno-opのルーチンである。パケットはネットワークから外に出ない から、ＩＰの設定には無関係である。 } 【００６９】 ０．１．２．３．１７ is_connect_closed() INTERNAL boolean is_connect_closed(desc, status) rpc_spcket_desc; unsigned 32 *status; { このルーチンは常に「真」に戻る。 } 【００７０】 ０．１．２．３．１８ tower_flrs_from_addr() INTERNAL void tower_flrs_from_addr (rpc_addr, lower flrs, status) rpc_addr_p_t rpc_addr; twr_p_t *lower_flrs; unsigned 32 *status; { Get the network protocol id (aka transport layer protocol) for this RPC addr. （このＲＰＣのアドレスのためのネットワーク・プロトコル（ａｋａ伝 送層プロトコル）の識別子を獲得せよ。） Use the network protocol id as a parameter to the routine twr_unix_lower_flrs_from_sa(). This routine will return a tower octet string representing the lower floors of a tower reference for the Unix Domain RPC adress. See the file twr_unix.c (Later in this docment) for details of the twr_unix_lower_flrs_from sa() routine. （ルーチン、twr_unix_lower_flrs_from_sa()に対するパラメータとし てこのネットワーク・プロトコルの識別子を使用せよ。このルーチン は「ＵＮＩＸ領域のＲＰＣアドレス」のためのタワー参照子の低位フロ アを表示するタワー・オクテット（８ビット・バイト）を戻す。 twr_unix_lower_flrs_from_sa()ルーチンの細部に関してはtwr_unix.c を参照されたい。） } 【００７１】 ０．１．２．３．１９ tower_flrs_to_addr() INTERNAL void tower_flrs_to_addr (tower_octet_string, rpc_addr,status) byte_p_t tower_octet_string; rpc_addr_p_t *rpc_addr; unsigned 32 *status; { Convert the lower floors of a tower to a sockaddr, calling the routine twr_unix_lower flrs_to_sa(). See the file twr_unix.c (Later in this document) for details of the twr_unix lower_flrs_to_sa() routine. （ルーチン、twr_unix_lower_flrs_to_sa()を呼び出して、タワーの低位 のフロアをソケット・アドレスに変換せよ。twr_unix_lower_flrs_to _sa()ルーチンの細部に関してはファイルtwr_unix.cを参照されたい。） Add the socket address to an RPC address and return it. （ソケット・アドレスをＲＰＣアドレスに加えて、それを戻せ。） } 【００７２】 ０．１．２．３．２０ desc_inq_peer_addr() INTERNAL void desc_inq_peer_addr (protseq_id, desc, rpc_addr, status) rpc_oritseq_id _t protseq_id; rpc_socket_t desc; rpc_addr_p_t *rpc_addr; unsigned32 *status; { Allocate memory for the new RPC address, and fill in the protseq id and length of the sockaddr structure. （新しいＲＰＣアドレスのためのメモリを割り当て、そして、 protseq id及びソケット・アドレス構造の長さでこのメモリを満たせ。 Call rpc_socket_inq_endpoint(), which will fill in the peer endpoint, which is always the same as the current processes endpoint, in the case of Unix Domain. （ＵＮＩＸ領域の場合において、現在の処理の終端部と常に同じである ピア終端部を満たすrpc_socket_inq_indpoint()を呼び出せ。） } 【００７３】 ０．１．２．４ src/rpc/runtime/unixnaf.h これは作成されなければならない新しいファイルであ
る。このファイルは主としてＵＮＩＸnaf_epvのルーチ
ンのためのプロトタイプ（原型）を含んでいる。加え
て、このファイルはＵＮＩＸ領域のＲＰＣアドレスの表
示用の定義を含んでいる。これは下記のように定義され
る。 【００７４】ＲＰＣがコマンド・コードを実行した時、
ＲＰＣのアドレスは疑似コードの不透明構造（rpc_addr
_t）として通されるけれども、この構造は、この構造が
ＮＡＦ特有のルーチンに通された時に、使用するファミ
リィのためのＲＰＣアドレス構造に入れられる。ＵＮＩ
Ｘストリームの場合、この構造はrpc_unix_addr_tに入
れられる。 【００７５】このファイルに対して更に付加する必要の
あるものは、ＡＩＸにおけるＵＮＩＸ領域のソケット呼
び出しで使用するファイル名を作成するために使用され
るべきデフォルトのパス名である。これは、オペレーテ
ィング・システムにより特有のものであって、ＯＳ／２
オペレーティング・システムにおいては必要としない。
終端部を作成する時に、若し終端部が存在しないか、あ
るいは使用されるべき終端部が若しフル・パス名を特定
しなければ、デフォルトのパス名が用いられる。デフォ
ルトのパス名は下記のように定義される。 #ifdefined(AIX_PROD) #define RPC_DEFAULT_UNIX_DOMAIN_PATH"_"/var/dce/rpc/socket" #endif 【００７６】ＯＳ／２オペレーティング・システムにお
いて、ＵＮＩＸ領域のソケット・ファイルは内部的だけ
にしか使用されない。ユーザが目視できるファイルは作
成されることはない。ＯＳ／２オペレーティング・シス
テムはソケット・ファイルに関連した管理的なタスク
（即ち、消去）を取り扱う。特別なパスの発生は必要と
しない。 【００７７】 ０．１．２．５ src/rpc/runtime/RIOS/unixnaf_sys.c このファイルは、作成されねばならない新しいファイル
である。このファイルは、「ＵＮＩＸ領域のネットワー
ク・アドレス・ファミリィ」に属しているＲＩＯＳプラ
ットフォームに特有なシステムであるルーチンを含んで
いる。 【００７８】 ０．１．２．５．１ rpc_unix_desc_inq_addr() これは、ＵＮＩＸ領域のネットワーク・アドレス・ファ
ミリィ、終端部及びネットワーク・アドレスを得るため
に問い合わされるソケット記述子を受け取る。若しこの
情報がＵＮＩＸ領域アドレスに対して有効であると表示
されたならば、このソケットから得られた情報によって
初期化されるＲＰＣアドレスのための空間が割り当てら
れる。作成されたＲＰＣアドレスを表示したアドレスは
rpc_addrの中に戻される。 PRIVATE void rpc_unix_desc_inq_addr (protseq_id, desc, rpc_addr_vec, status) rpc_protseq_id_t protseq_id; rpc_socket_t desc; rpc_addr_vector_p_t *rpc_addr_vec; unsigned 32 *status; { Simply do a "getsockname" into a local Unix Domain RPC address. （ローカルＵＮＩＸ領域のＲＰＣアドレス中に「getsocketname」を単に 実行せよ。） Allocate memory for the RPC address, ane RPC address vector. （ＲＰＣアドレス及びＲＰＣアドレス・ベクトルに対してメモリを割り 当てよ。） Fill in the RPC address structure with the protocol sequence id, and the Unix sockaddr structure. （ＲＰＣアドレス構造中に、プロトコル・シーケンス識別子及びＵＮＩ Ｘソケット・アドレス構造を入れよ。） Add the RPC address to the RPC address vector. （ＲＰＣアドレスをＲＰＣアドレス・ベクトルに加えよ。） } 【００７９】 ０．１．２．５．２ rpc_unix_get_broadcast() このルーチンはno-opであるが、必要であるから、naf_e
qvの中にはエントリがある。 PRIVATE void rpc_unix_get_broadcast (naf_id, protseq id_, rpc_addr_vec, status) rpc_naf_id_t naf_id; rpc_protseq_id_t protseq_ed; rpc_addr_vector_p_t *rpc_addr_vec; unsigned32 *status; { Do nothing. Set output parameters to NULL and return. （なにもしない。出力パラメータを無効にセットして、復帰せよ。） } 【００８０】 ０．１．２．６ src/rpc/runtime/twr_unix.h これは、作成されねばならない新しいファイルである。
このファイルは、twr_unix.cファイルに特有の宣言及び
プロトタイプを含んでいる。この実施例において、この
ファイルは、ルーチンrpc_rpcd_is_running()のための
プロトタイプだけしか含んでいない。 【００８１】 ０．１．２．７ src/rpc/runtime/twr_unix.c これは、作成されねばならない新しいファイルである。
このファイルは、タワー表示からソケット・アドレスに
変換を行ない、かつ、ソケット・アドレスからタワー表
示に変換を行なうために特有なルーチンを含んでいる。
また、このファイルは、ＲＰＣランタイム及びＲＰＣＤ
の両方によって使用されるユティリティ・ルーチンを含
んでいる。 【００８２】 ０．１．２．７．１ twr_lower_flrs_from_sa() これは、ＵＮＩＸ領域のためのソケット・アドレスか
ら、タワーの低位フロアの基準的な表示を作成する。こ
の基準形式は電線で伝送することができるし、あるいは
ＤＳＮタワー中に含ませることができる。 PUBLIC void twr_unix_lower_firs_from_sa(trans prot,sa,lower_firs,status) unsigned32 trans_prot;/* 無視される */ sockaddr_p_t sa; twr_p_t*lower_flrs; unsigned32*status; { Make sure the NAF is Unix Domain. If so, then set the first lower floor (Floor 4) to be the file name prot id (twr_c_flr_prot_id_fname) and the second lower floor (Floor 5) to be a dummy place holder. If the NAF id is not Unix domain, return an error, indicating an unknown socket address. (ＮＡＦはＵＮＩＸ領域であることを確認せよ。若しＵＮＩＸ領域であ れば、第１の低位フロア（フロア４）をファイル名のポート識別子（twr _c_flr_prot_id_fname）にセットし、かつ、第２のフロア（フロア５） をダミー位置ホルダにセットせよ。若しＮＡＦ識別子がＵＮＩＸ領域で なければ、不知のソケット・アドレスを表示してエラー信号を戻せ。) Allocate space for the tower octet string. （タワーのオクテット・ストリングのための空間を割り当てよ。） Build up the tower octet string, using the syntax specified in Appendix I of the RPC/AES document. The syntax will be the same as building a tower reference when using tcp/ip, except that the first floor (floor 4) will contain a filename instead of a port number. Also the second floor (floor 5) will be empty, since it is just a place holder, and is not used for anything. （ＲＰＣ／ＡＥＳ文書の付表Ｉ中に特定されている構文を用いてタワー のオクテット・ストリングを作成せよ。この構文は、第１のフロア（フ ロア４）がポート番号の代わりにファイル名を含んでいる場合を除き、 tcp/ipを用いた時のタワー参照子を作成する構文と同じである。また、 第２のフロア（フロア５）は位置ホルダだけであり、かつ他のものには 用いられないから、第２のフロアは空である。） } 【００８３】 ０．１．２．７．２ twr_unix_lower_flrs_to_sa() これは、ＵＮＩＸ領域プロトコル・タワーの低位フロア
の標準的な表示からＵＮＩＸ領域のソケット・アドレス
を作成する。 PUBLIC void twr_unix_lower_flrs_to_sa(tower_octet string,sa,sa_len,status) byte_p_t tower_octet_string; socketaddr_p_t *sa; unsigned32*sa_len; unsigned32*status: { Skip over the upper 3 floors of the tower reference, ane position to the lower network floors. （タワー参照子の上部３つのフロアを飛び越えて、低位のネットワーク のフロアに置け。） Sequence thru the tower octet string, and build a unix socket address. This is the converse of the routine twr_unix_lower_flrs_from_sa(). Refer to Appendix I of the RPC/AES document, for details of the syntax for a tower reference. （タワーのオクテット・ストリングを通して順序付け、そしてＵＮＩＸ ソケット・アドレスを作成せよ。これは、ルーチンtwr_unix_lower_ flrs_from_sa()の逆である。タワー参照子のための構文の細部に関し てはＲＰＣ／ＡＥＳ文書の付表Ｉを参照されたい。） } 【００８４】 ０．１．２．７．３ rpc_rpcd_is_running() これは新しいルーチンである。このルーチンは、２つの
目的、即ち（１）ＲＰＣＤのインスタンスが既に動作し
ているか否かを決定するための初期化の間でＲＰＣＤが
このルーチンを使用する目的と、（２）ローカル・ホス
ト・コンピュータ中のＲＰＣＤが動作しているか否か
と、そのルーチンがncacn_unix_streamプロトコル・シ
ーケンスをサポートするか否かとを決定するために、Ｒ
ＰＣランタイムがこのルーチンを使用する目的とのため
に使用される。 【００８５】このルーチンはncacn_unix_streamをサポ
ートするＲＰＣＤのインスタンスをチェックする。これ
は、ＲＰＣＤの終端部ファイル（/var/dce/rpc/socket/
135）の存在を検索することによって行なわれる。若し
このファイルが存在しなければ、ＵＮＩＸストリームを
サポートするＲＰＣＤは動作しない。若しこのファイル
が存在するならば、このファイルは、ＲＰＣＤインスタ
ンスを接続する試みを行なうために使用される。若しこ
の接続が失敗に終れば、ＵＮＩＸストリームをサポート
するＲＰＣＤは動作しない。このファイルを除去する。
若し接続が成功裡に終れば、ＲＰＣＤは動作する。この
ファイルを除去しない。 PRIVATE boolean32 rpc_rpcd_is_running(status) unsigned32 *status; { Check if the Unix Streams protocol sequence is supported. If not, return the error rpc_s protseq_not_supported. （ＵＮＩＸストリームのプロトコル・シーケンスがサポートされるか否 かをチェックせよ。若しサポートされていなければ、エラー、rpc_s_ protseq_not_supportedを戻せ。） Inspect the interface specification for the RPCD (ept_v3_0_cifspec) and get the well-known endpoint for the Unix Stream protocol sequence. （ＲＰＣＤ（ept_v3_0_cifspec）用のインターフェース仕様を検査し、 そして、ＵＮＩＸストリームのプロトコル・シーケンスのための公知の 終端部を獲得せよ。） The endpoint is used as a socket file for the communicating to the RPCD. First, check if the file exists. If it does exist, then we expect it to be a file associated with a socket, and the fopen() shoud fail with the appropriate error. If it doesnot exist, then there is no rpcd running (at least with support for ncacn_ unix_stream). So just return. Everything is ok. （終端部はＲＰＣＤと通信するためのソケット・ファイルとして使用さ れる。先ず、ソケット・ファイルが存在するか否かをチェックする。若 し存在すれば、我々はそのファイルをソケットに関連されたファイルで あるものと予測し、そしてfopen()は失敗して、適当なエラーを表示す る。若しソケット・ファイルが存在しなければ、rpcdの動作（少なくと もncacn_unix_streamのサポートによる）はない。従って、復帰するだ けである。すべてＯＫである。） If this file can be opened, then it is NOT a socket file. Therefore remove it (i.e. it should not be therein the first place) and return. （若しこのファイルをオープンすることができたならば、そのファイル はソケット・ファイルではない。従って、そのファイルは除去し（第１ の位置にあるべきでない）、そして復帰する。） If the file exists, and is a socket file, check if there is an RPCD actively using it. Do this via a socket()/connect() sequence. （若しファイルが存在し、かつソケット・ファイルであれば、それを実 際的に使用したＲＰＣＤがあるか否かをチェックせよ。socket()/ connect()シーケンスを通してこのチェックを行え。） If no rpcd is running, we expect the connect call to fail. We check for the proper error, and flag the case where an unexpected error occurs. （若しＲＰＣＤが動作しなければ、我々は接続呼び出しが失敗したことを 予測する。我々は適正なエラーであるか否かをチェックし、そして予測 しなかったエラーが発生した場合にはフラグを発生せよ。） If able to connect to the RPCD, return true. Otherwise, return false. （若しＲＰＣＤへ接続することが可能ならば、真を戻せ。そうでなけれ ば、偽を戻せ。） } 【００８６】０．１．２．８ src/rpc/runtime/twrp.h これは従来のファイルである。このファイルは、ＲＰＣ
タワー参照子の構造及びオクテット・ストリングの構成
及び検査に関する宣言を含んでいる。このファイルは下
記の付加的なラインを含ませるために修正される。 /* 各低位のタワー・フロアのためのプロトコル識別子
*/#define twr_c_flr_prot_id_fname 0X20 /* ＵＮＩＸ
領域のファイル名 */#dufine twr_c_flr_prot_id_dumm
y 0x21 /* フロア５のためのダミーprot識別子 */ */ ＵＮＩＸアドレス・ファミリィ中の低位のフロアの
数 */#define twr_c_num_unix_lower_flrs 2 /* ＵＮＩ
Ｘタワー中の低位フロアの数 */ /* ＵＮＩＸファミリィのファイル名のサイズ */ #define twr_c_unix_frame_size 108 注記： ＵＮＩＸ領域のタワー参照子だけが、４つのタ
ワー・フロアの使用を作るけれども、５番目のフロアが
含まれており、これはデータを含まない。この理由は、
タワー・オクテット・ストリングを検査するためにＲＰ
Ｃランタイムが使用しているアルゴリズムが全タワー数
であると見做すために５つのタワーを必要とするからで
ある。ＵＮＩＸ領域は全タワーであるけれども、４つの
フロアだけがそれらのフロアに関連したデータを持つて
いる。 【００８７】 ０．１．２．９ src/rpc/runtime/comtwrref.c これは、従来のファイルである。このファイルはプロト
コル・タワーのランタイム参照子の表示に動作するルー
チンを含んでいる。 【００８８】 ０．１．２．９．１ rpc_tower_ref_inq_protseq_id() このルーチンは修正されなければならない。このルーチ
ンは、上部フロア３と、そのプロトコル・シーケンスの
ためのタワー参照子を作る下部タワーのフロアとのため
のプロトコル識別子の組み合せに対して、使用可能なす
べてのプロトコル・シーケンスをマップすることを含む
静的なテーブルを含んでいる。このテーブルは、ncacn_
unix_streamプロトコル・シーケンス用のエントリの付
加を含ませるために修正されねばならない。 status rpc_tower_prot_ids_t rpc_tower_prot_ids[rpc_c protseq_id_max+1] = { {rpc_c_protseq_id_ncacn_unix_stream,3, {{rpc_c_cn_proto_id, {0}}, {twr_c_flr_prot_id_fname,{0}}, {twr_c_flr_prot_id_dummy,{0}}, {0x00, {0}} } }, .../* 他の従来のテーブル・エレメント */ }; 【００８９】 ０．１．２．１０ src/rpc/runtime/nsp.h これは従来のファイルである。このファイルはプライベ
ートの名称空間のtypedef、定数の定義などを含んでい
る。ルーチン、rpc_ns_binding_lookup_next()において
使用するために新しいデータ構造が必要とされる。この
データ構造はリストのエレメントをストアするために使
用される。これらのエレメントは検索の間で名称空間か
ら戻される夫々独特の名称空間エントリについての情報
を含んでいる。ストアされている情報は、名称空間エン
トリの名称と、名称空間エントリに関連されたインター
フェース特定子及びオブジェクトＵＵＩＤ（選択的）と
を含んでいる。また、若し検索動作の間で検出されたと
すれば、ＵＮＩＸストリームのバインディング・ハンド
ルを含むフィールドがある。このデータ構造がどのよう
に使用されるかの細部に関しては、下記に示したrpc_ns
_binding_lookup_next()の記載を参照されたい。このデ
ータ構造は下記のようなものである。 【００９０】０．１．２．１１ nslookup.c これは従来のルーチンである。このルーチンは、名称サ
ービスのデータベースからの１つまたはそれ以上の両立
性あるサーバ（若し検出されたならば）のバインディン
グ・ハンドルのリストを戻す。このルーチンは、検索に
おいて解決された各独特の名称空間エントリと関連され
たncacn_unix_streamのバインディング・ハンドルがユ
ーザに戻されたバインディング・ベクトルに添付される
ように修正されなければならない。これは、検索動作が
通常通り進行し、次に、ユーザに戻す前に、バインディ
ング・ベクトル中に存在するバインディング・ハンドル
のオブジェクトＵＵＩＤ及びインターフェース識別子と
マッチする、終端部マップ中のncacn_unix_streamバイ
ンディング・ハンドルがあるか否かを検査するための呼
び出しを、このルーチンが作ることを意味する。若し上
述のバインディング・ハンドルがあるならば、これらの
バインディング・ハンドルはバインディング・ベクトル
に付加され、そして連鎖されたベクトルがユーザに与え
られる。rpc_ns_binding_lookup_next()中の下記のリタ
ーン・ステートメントは、戻す前にローカル・バインデ
ィング・ハンドルを得るために修正する必要がある。 注記： 下記のルーチンrpc_prepend_local_bindings()
の細部を参照されたい。 .... ..../* ここでは無関係のコード */ .... case rpc_s_priority_group_donbe: rpc_next_priority_group_count(lookup)_node); if((*binding_vector)->count>0) { *status = rpc_s_ok; roc_prepend_lcl_bndgs(binding vector,lookup_rep,status; return; } case rpc_s_binding_vector_full: *status=rpc_s_ok; rpc_prepend_lcl_budgs(binding_vector,lookup rep,status); return; .... ..../* ここでは無関係のコード */ .... /* ＊若し両立性バインディング・ハンドルが検出されたならば、そのエントリ ＊中の他のすべての属性を処理する前に、これらのバインディング・ハンド ＊ルを戻せ。 */ if ((*bonding_vector)->count>0) { *status = rpc_s_ok; rpc_prepend_lcl_budgs (binding_vector,lookup rep, status); return; } .... ..../* ここでは無関係のコード */ .... /* ＊若しノード・リストで行なわれたならば、バインディング・ベクトルの中 ＊に何があるかを見よ。 */ if ((*binding_vector)->count>0) { /* ＊若しバインディング・ベクトルの中に何かがあれば、それを戻せ。 */ *status = rpc_s_ok; rpc_prepend_lcl_budgs (binding_vector, lookup rep, status); return; } .... ..../* ここでは無関係のコード */ .... 【００９１】 ０．１．２．１１．２ rpc_prepend_local_bindings() このルーチンは作成されるルーチンである。このルーチ
ンは名称空間から戻されたエントリのリストを入力する
時に用いられる。これらのエントリは、名称空間エント
リと関連されたインターフェース特定子及びオブジェク
トＵＵＩＤなどを含んでいる。このルーチンは、一致し
たバインディング・ハンドルがあるか否かを検査する終
端部マップに対して呼び出しを行なうために、上述のイ
ンターフェース特定子及びオブジェクトＵＵＩＤを用い
る。若し一致が検出されたならば、バインディング・ハ
ンドルのプロトコル・シーケンスが検査される。若しプ
ロトコル・シーケンスがncacn_unix_streamであれば、
バインデイング・ハンドルはバインディング・ベクトル
に添付される。このようにして、このルーチンが復帰し
た時、インターフェース特定子及びオブジェクトＵＵＩ
Ｄと一致したすべてのvcacn_unix_streamのバインディ
ング・ハンドルは、バインディング・ベクトルの頭部に
添付されている。このルーチンは下記の通りである。 If there is support for protocols other than ncacn unix_stream （若しncacn_unix_stream以外の他のプロトコルをサポートする能力がある ならば） For each entry in the binding vector （バインディング・ベクトル中の各エントリに対して） Copy the entry-name into an entry_name array （エントリの名称をエントリ名アレイ中にコピーせよ） Endfor /* この段階で、各独特のエントリ名（重複したものを除去した名称） で構成されたリンク・リストを作成せよ。 */ For each entry in the entry-name array （エントリ名アレイ中の各エントリに対して） If the entry does NOT exist in the linked list （若しそのエントリ名がリンクされたリスト中に存在していなけれ ば） Add it to the tail, entering all pertinent into (entry name, interface id, object uuids, and the binding itself). （すべての関連情報（エントリ名、インターフェース識別子、 オブジェクトＵＵＩＤ及びバインディング・ハンドルそれ自 身）を入力して、リンクされたリストの端部に付加せよ。） Endif Endfor Get the address of the local host. （ローカル・ホスト・コンピュータのアドレスを獲得せよ。） For each linked list entry （リンクされたリストの各エントリに対して） If the entries binding handle ip address (sa.sin_addr.s_addr) is not equal to the local host address （若しエントリ、バインディング・ハンドルのｉｐアドレス （sa.sin_addr.s_addr）がローカル・ホスト・コンピュータの アドレスと同じでなければ） Remove the entry from the linked list since the binding cannot possible have an entry in the local endpoint map, since the server resides on another host system. （サーバは他のホスト・コンピュータ・システム中にあっ て、バインディング・ハンドルはローカル終端部マップ中 にエントリを持つはずがないから、リンクされたリストか らそのエントリを除去せよ。） Endif Endfor Endif If rpcd is NOT running on the local host, or does NOT support ncacn_unix_stream （若しＲＰＣＤがローカル・ホスト・コンピュータ中で動作していないか、 またはncacn_unix_streamをサポートしていなければ） Return （復帰せよ。） Endif Allocate memory for a binding vector that can hold all of the existing binding handles, as well as those that could potentially come back from the rpcd endpoint map. （存在しているバインディング・ハンドルのすべてと、ＲＰＣＤ終端部マッ プから将来戻されるであろうバインディング・ハンドルとを保持することの できるバインディング・ベクトルのためのメモリを割り当てよ。） while the linked list is not empty （リンクされたリストが空でない間で） get the head element, and using its interface specifier and object uuid, ditermine the inquiry type for making the endpoint map inquiry. （頭部エレメントを獲得し、そして、そのインターフェース特定子と、 オブジェクトＵＵＩＤとを用いて、終端部マップの問い合せを行なうた めの問い合せのタイプを決定せよ。） call rpc_mgmt_ep_elt_inq_begin() （rpc_mgmt_ep_elt_inq_begin()を呼び出せ。） Do （実行せよ） call rpc_mgmt_ep_elt_inq_next() （rpc_mgmt_ep_elt_inq_next()を呼び出せ。） if the protocol sequence for the returned element is ncacn_unix_stream （若し戻されたエレメントのためのプロトコル・シーケンスが ncacn_unix_streamであれば） break out of the do loop （実行ループを遮断せよ。） Endif While the status is OK （状態がＯＫである間で） call rpc_mgmt_ep_elt_inq_done() （ rpc_mgmt_ep_elt_inq_done()を呼び出せ。） If there was a uuid used to qualify the endpoint inquiry （若し終端部の問い合せを有効化するために使用するＵＵＩＤがある ならば） add the object to the binding handle (rpc binding_set_object()) （バインディング・ハンドル（rpc_binding_set_object())に、 オブジェクトを付加せよ。） Endif call rpc_binding_reset() to get rid of the endpoint. We only want a partially bound handle, so it will be consistent with the other binding handles in the binding vector. Also, since we only do the endpoint map inquity until we find one unix stream binding, we donot want the endpoint because it would be deterministic as to what the binding endpoint would be. By resetting the binding, and forcing a call to resolve the binding, we are making the selection non-deterministic, or random, which is what we want. （終端部を除去するrpc_ninding_reset()を呼び出せ。我々は、部分的 にバインディング・ハンドルを欲しているだけなので、このバインディ ング・ハンドルはバインディング・ベクトル中の他のバインディング・ ハンドルと両立する。また、我々は、１つのunix_streamバインディン グ・ハンドルを検出するまで、終端部マップの問い合せを行なっている だけだから、我々は終端部を欲しない。何故ならば、バインディング・ ハンドルの終端部とは何であるかに関しては決定論的なものだからであ る。バインディング・ハンドルをリセットすることにより、そしてバイ ンディング・ハンドルを解決するための呼び出しを強制することよって 、非決定論的なものか、またはランダムなものかの何れかを我々が欲し ているように選択する。） add the binding to the new binding vector （新しいバインディング・ベクトルにそのバインディング・ハンドルを 加える。） Endwhile If any unix stream binding were found in the endpoint map （若し終端部マップの中にunix_streamのバインディング・ハンドルが検出 されたならば） copy the original binding vector elements to the end of the newly formed vector （オリジナルのバインディング・ベクトル・エレメントを新しく作成 されたバインディング・ベクトルの終端部にコピーせよ。） free the original binding vector （オリジナルのバインディング・ベクトルを解放せよ。） assign the newly formed binding vector to the return parameter for the binding vector. （新しく作成されたバインデイング・ベクトルをバインディング・ベ クトルのリターン・パラメータに割り当てよ。） Endif 注記： 若しバインディング・ベクトルのエレメントが検出されなければ、オ リジナルのバインディング・ベクトルが戻されて、何も変更されない。 } 【００９２】 ０．１．２．１１．３ rpc_ns_binding_select() これは従来のルーチンである。このルーチンはルーチン
に通されたバインディング・ハンドルのベクトルからバ
インディング・ハンドルをランダムに選択する。このル
ーチンは、ＵＮＩＸストリームのバインディング・ハン
ドルが先ず選択されるように修正される。すべてのＵＮ
ＩＸストリームのバインディング・ハンドルが選ばれた
後、残りのバインディング・ハンドル（他のプロトコル
・シーケンスを表わす）がランダムに選択される。１つ
以上のＵＮＩＸストリームのバインディング・ハンドル
がある場合には、ルーチンによる選択はこれらのバイン
ディング・ストリームの間でランダムに行なわれる。こ
のアルゴリズムは下記のようなものである。 ..../* Determin that there are still unused bindings in the binding vector （バインディング・ベクトルの中に依然として未使用のバインディング・ハ ンドルがあることを決定せよ） */ .... If ncacn_unix_stream protocol sequence is supported （若しncacn_unix_streamのプロトコル・シーケンスがサポートされて いるならば） For each binding in the binding vector （バインデイング・ベクトル中の各バインディング・ハンドルに 対して） IF the protocol sequence for this binding is ncacn_unix_stream （若しこのバインディング・ハンドルのプロトコル・シーケ ンスがncacn_unix_streamであるならば） select the binding NULL out the binding vector element （そのバインディング・ハンドルを選択し、バインデ ィング・ベクトルのエレメントを「無効」にする。） return （復帰せよ） endif endfor endif endif .... ....//* If we get here, there are no ncacn_unix stream bindings, so continue as usual （若しncacn_unix_streamのバインディング・ハンドルが無いことが判った ならば、通常のルーチンを続ける。） */ 【００９３】 ０．１．２．１２ src/rpc/runtime/nsbndexp.c これは従来のファイルである。このファイルは、ＣＤＳ
の名称空間にバインディング・ハンドルを転送するのに
使用するルーチンを含んでいる。これらのルーチンは、
ＣＤＳの名称空間にバインディング・ハンドルを転送す
る要求が行なわれた時に「ＵＮＩＸ領域のネットワーク
・アドレス・ファミリィ（ＡＦ＿ＵＮＩＸ）」が取り除
かれるように、修正される。ＵＮＩＸのＮＡＦバインデ
ィング・ハンドルはＲＰＣＤの終端部マップだけにしか
レジスタされない。 【００９４】 ０．１．２．１２．１ rpc_ns_binding_export() これは従来のルーチンである。これは、名称空間にバイ
ンディング・ハンドルのベクトルを転送する。我々はＵ
ＮＩＸストリームのバインディング・ハンドルが転送さ
れるのを望まないから、バインディング・ハンドルが転
送される前に下記のアルゴリズムが使用される。 For each binding handle in the binding vector （バインディング・ベクトル中の各バインディング・ハンドルに対して） if ncacn_unix_stream protocol sequence is supported （若しncacn_unix_streamプロトコル・シーケンスがサポートされてい るならば） rpc_binding_to_string_binding() rpc_string_binding_parse() /* Return only the protseq string */ if the protseq string = ncacn_unix_stream rpc_binding_free() endif endif endfor 注記： ncacn_unix_streamのバインディング・ハンド
ルであるバインディング・ハンドルを解放することは、
オリジナルのバインディング・ベクトルのコピー中にあ
るバインディング・ベクトル・エレメントに行なわれ
る。従って、ユーザがルーチンに転送するバインディン
グ・ベクトルに対しては変更がない。 【００９５】 ０．１．２．１３ src/rpc/runtime/nsmgmt.c これは修正を要する従来のファイルである。ncacn_unix
_streamがサポートされるべき唯一のプロトコル・シー
ケンスである場合に、エラーが発生されないように、名
称空間エントリからのバインディング／オブジェクト情
報を転送しないようにするための管理ルーチンは変更さ
れなければならない。 【００９６】 ０．１．２．１３．１ rpc_ns_mgmt_binding_unexport
() 注記： このルーチンrpc_ns_binding_unexport()はこ
のルーチンを直接に呼び出す。これは、修正を要する従
来のルーチンである。ＵＮＩＸストリームのバインディ
ング・ハンドルは、名称空間中には存在しないから、若
しncacn_unix_streamがサポートされる唯一のプロトコ
ル・シーケンスであれば、要求されたエントリのための
名称空間中にはバインディング・ハンドルは存在するは
ずがないから、インターフェース識別子を単純に無効に
する。若し呼び出し側が転送しないことを望んでいるオ
ブジェクトＵＵＩＤがあれば、これらのオブジェクトＵ
ＵＩＤは通常通りに取り扱われる。 .... If rpc_local_host_support_only() （若しＲＰＣがローカル・ホスト・コンピュータをサポートするだけならば （下記のルーチン参照）） Null out the interface identifier （インターフェース識別子を無効にせよ。） endif .... 【００９７】 ０．１．２．１３．２ rpc_local_host_support_only() これは新しいルーチンである。このルーチンは、大域プ
ロトコル・シーケンスのテーブルを必要とし、そしてnc
acn_unix_streamがサポートされる唯一のプロトコル・
シーケンスなのか否かを決定する。これは「真」または
「偽」を戻す。このルーチンは、ncacn_unix_streamが
サポートされていることを知っている位置だけから呼び
出されるので、ncacn_unix_streamがサポートされてい
るか否かに関するチェックは必要としない。コードは下
記の通りである。 For each element in the rpc_g protocol_id table （rpc_gのプロトコル識別子のテーブル中の各エレメントに対して） if the protocol is supported and the protocol is not ncacn_unix_stream （若しそのプロトコルがサポートされており、そのプロトコルは ncacn_unix_streamでなければ） return FALSE （偽を戻せ。） endif return TRUE （真を戻せ。） endfor 【００９８】 ０．１．２．１４ src/rpc/sys_idl/ep.ids このファイルsrc/rpc/sys_ids/ip.idsは、ＲＰＣＤの終
端部のデータベースにアクセスするために使用されるＲ
ＰＣのインターフェースを含んでいる。このｉｄｌファ
イルは、ＲＰＣＤが動作する時には常に使用する公知の
終端部を含んでいる。この終端部はプロトコル・シーケ
ンス・ベース毎にこのファイル中に特定されるので、nc
acn_unix_streamのプロトコル・シーケンスのために、
このファイルに下記のような付加が行なわれねばならな
い。 { uuid(elaf8308-5dlf-11c9-91a4-08002b14a0fa), version(3.0), endpoint( "ncadg_id_udp:[135]", "bcadg_dds;[12]", "ncacn_ip_tcp:[135]", "ncacn_dnet_nsp:[#69]", "ncacn_unix_stream"[135]"), pointer_default(ptr) } interface ept .../* idl 仕様書の残り */ { 注記： 終端部は、既に記載したルーチンrpc_addr_set
_endpoint()において与えられた規則を使用して、ファ
イル名に変換される。これは、使用しているプラットフ
ォームに従って、「１３５」が、RPC_DEFAULT_UNIX_DOM
AIN_PATHの定義（ファイル「twr_unix.c」の記載を参
照）で決められたパスに加えられることを意味する。 【００９９】 ０．１．２．１５ src/rpc/rpcd/rpcd.c これは従来のファイルである。このファイルは、ＲＰＣ
Ｄのサーバがきたとき、ncacn_unix_streamを介した要
求を聴取するために使用されるソケット・ファイルが存
在するか否かを、このサーバがチェックするように、修
正する必要がある。若しソケット・ファイルが存在して
いるならば、それを削除する必要がある。何故ならば、
若しソケット・ファイルが既に存在しているならば、ソ
ケット・ファイルを作成することはできないからであ
る。 【０１００】０．１．２．１５．１ main () データベースが初期化された後であって、プロトコル・
シーケンスのサポートが設定される前に、以下のコード
を付加しなければならない。 ..../* データベースの初期化 */ .... if (rpc_rpcd_is_running(&status)) { fprintf(stderr, "(rpcd) Instance already running. Can not continue.?n"); exit(1); } if ((status !=rpc_s_ok) && (status !=rpc_s_protseq not_supported)) { fprintf(stderr, "(rpcd) Error checking for other rpcd indtances.?n"); exit(1); } .... ..../*rest of rpcd setup */ 【０１０１】 ０．１．２．１６ src/libdce/RIOS/libdce.syms これは従来のファイルである。このファイルは、ルーチ
ンrpc_rpcd_is_running()を含ませるために更新する必
要がある。これは、libdce.aの外側のルーチンまたはプ
ログラムがこのルーチンにアクセスすることができる場
合に必要である。rpcdがこのルーチンを呼び出すので、
このルーチンが必要である。必要とするすべてのこと
は、libdce.-symsに下記のラインを加えることである。 rpc_rpcd_is_running 【０１０２】 ０．１．２．１７ Auto Handles（自動処理） [auto_handle]属性の使用は、アプリケーションのコード
がバインディング・ハンドルを獲得すること、または、
バインディング・ハンドルのための終端部を解決するこ
とに対して責任を持たないことを表示する。[Auto_hand
le]属性は、ＲＰＣのランタイムがこれらのすべてを取
り扱うことを特定する。ユーザが特定するすべてのもの
は、バインディング・ハンドルを検索するために、ＲＰ
Ｃのランタイムが開始すべき名称空間エントリ位置であ
る（これは環境変数RPC_DEFAULT_ENTRYを通して行なわ
れる）。クライアント及びサーバが同じホスト・コンピ
ュータの中に存在する場合には、ＲＰＣのランタイム
は、ncacn_unix_streamを使用するための知識を持って
いる。 【０１０３】０．１．２．１８ ユティリティ このフィーチャの実行は、管理的責任を遂行するために
幾つかのユティリティの作成を必要とする。これらの概
略を下記に説明する。 【０１０４】 ０．１．２．１８．１ src/rpc/utils/rpcclean このユティリティはＲＰＣのランタイムのルーチン、rp
c_network_inq_protseqs()を呼び出し、そして、結果の
プロトコル・シーケンスのストリング・ベクトルの１つ
のプロトコル・シーケンスを１つのラインにプリントす
る。このユティリティは、与えられたホスト・コンピュ
ータ中で使用可能なプロトコル・シーケンスを決定する
ためのmkdceに使用される。ここでサポートされている
プロトコル・シーケンスはmkdceスクリプトに配線され
ている。このスクリプトは、与えられたホスト・コンピ
ュータにおいてサポートされているプロトコル・シーケ
ンスを決定するための迅速な管理方法にも使用すること
ができる。このユティリティ用のコードは下記の通りで
ある。 *include <stdio.h> *include <dce/rpc.h> *include <dce/ecd_error.h> char message[dce_c_error_string_len]; main(unsigned32argc,unsigned_char_p_t argv[]); { rpc_protseq_vector_p_t psvp; unsigned32i,status=0, tmp_status=); rpc_network_inq_protseqs( &psvp, &status); if (status !=rpc_s_ok) { dce_error_inq_text(status, message,&tmp status); printf("%s: %s/n" , argv[0], message); exist(1); } for (i = 0; i<psvp->count; i++) { printf("%s/n", psvp->protseq[i]); } } 【０１０５】０．１．２．１９ Installp Utility ＤＣＥのためのイメージの設置は、それがディレクト
リ、/usr/tmp/rpcを作成（または重ね書き）するように
強化されなければならない。このディレクトリなしで
は、ＤＣＥ及び他のすべてのＤＣＥアプリケーションは
ncacn_unix_streamを介して動作しない。 【０１０６】０．１．２．３ 両立性 このフィーチャはあらゆる両立性の問題を発生すべきで
はない。 【０１０７】０．１．３．１ 逆方向の両立性 従来のアプリケーションは、このフィーチャを含むよう
にＤＣＥを昇格することができ、修正を施すことなく実
行することができる。クライアント／サーバのうちの何
れか一方がこのフィーチャを使用するように強化され、
他方が強化されていない場合であって、異なったホスト
・コンピュータ中のクライアント／サーバ・アプリケー
ションは、修正することなく実行することができる。こ
れは、ＵＮＩＸ領域がacrodd装置を使用できないので、
両立性の問題ではなく、むしろ共存性の問題である。 【０１０８】０．１．３．２ 交差プラットフォーム
（Cross-Platform）の両立性 このフィーチャはＡＩＸ及びＯＳ／２を使用するために
実行される。ＡＩＸ及びＯＳ／２のプラットフォームの
間で通信するクライアント／サーバ・アプリケーション
は、このフィーチャの利益を受けることはできないけれ
ども、従来のアプリケーションはこのフィーチヤを含ま
せるようにＤＣＥを昇格することができ、そして修正を
施すことなく実行することができる。 【０１０９】逆方向の両立性は、このフィーチャを導入
する前に可能であった範囲まで、交差プラットフォーム
を拡張するだけである。すべての両立性の要求は、勿
論、このフィーチャの範囲を越えたソースからの他の非
両立性の導入とは無関係である。 【０１１０】０．１．４ 設置及びコンフィギュレーシ
ョン（構成）の問題 ＤＣＥがコンピュータに導入された時、ディレクトリ、
/use/tmp/rpcが作成されなければならない。若しこのデ
ィレクトリが既に存在しているならば、そのディレクト
リは消去され、再度作成されなければならない。これ
は、ＵＮＩＸ領域のソケット・ファイルが作成される場
合であり、このディレクトリに関して取り残されたすべ
てのファイルは偽ファイルである。何故ならば、ＤＣＥ
を導入して昇格が行なわれた時には、すべてのＤＣＥの
アプリケーションは中止されたと見做されるからであ
る。 【０１１１】ＤＥＣの構成は拡張される。ncacn_unix_s
treamでサポートされたプロトコル・シーケンスとして
のncacn_unix_streamをＤＥＣインスタンスだけが使用
することを、管理者は特定することができる。ＵＮＩＸ
領域のソケットは、すべての処理間通信が同じホスト・
コンピュータ中で処理されることを必要とするから、Ｄ
ＣＥの構成の拡張は、異なったホスト・コンピュータ中
の処理と通信することのできないセルを作成することに
なる。 【０１１２】０．１．５ ＲＡＳの問題 このフィーチャからＲＡＳ（信頼性）に関する問題は生
じない。 【０１１３】０．１．６ ＮＬＳの問題 このフィーチャからはＮＬＳに関する問題は生じない。 【０１１４】０．１．７ 性能及びストレージ容量の概
算 ＲＰＣ呼び出しの性能は、クライアント及びサーバが同
じコンピュータ中にある場合、１０％乃至４０％まで改
善された。クライアント及びサーバが異なったホスト・
コンピュータ中にある場合でも、性能には影響を及ぼさ
ない。 【０１１５】ストレージ容量の概算は問題にはならな
い。ＲＰＣＤは、ＵＮＩＸ領域のソケットが許容される
場合、rpc_ip_register()を実行する各サーバのための
臨時の終端部をストアする。ソケット・ファイルは各Ｕ
ＮＩＸ領域の終端部のために作成され、この終端部はサ
ーバのレジスタであるけれども、このファイルは長さが
ゼロである。 【０１１６】rpccleanユティリティ（既に説明された）
は、システムの中で取り残された偽のソケット・ファイ
ルを除去するために実行することができる。これは、フ
ァイル・システム中で使用されるinodeの数を減少す
る。 【０１１７】０．１．８ テスト計画 テスト計画は別の文書にされる。テスト計画は、このフ
ィーチャが正しく動作することを保証するために必要と
するすべての実験例またはテスト計画を表示した従来の
ＲＰＣのＦＶＴテスト計画の付属書類である。 【０１１８】以上、特定のオペレーティング・システム
と特定のネットワーク環境において本発明の実施例を説
明してきたが、本発明の技術的範囲内で、他の異なった
オペレーティング・システム及びネットワーク・アーキ
テクチャにおいて本発明を実施することができるのは当
業者であれば容易に理解できる。例えば、ＤＣＥのＲＰ
Ｃアーキテクチャと言う術語において、クライアント処
理はサーバ処理に「バインディング・ハンドル」を通過
する。然しながら、本発明はＤＣＥのＲＰＣアーキテク
チャのみに限定されるべきでなく、本発明の技術思想
は、クライアント処理がサーバ処理の位置を特定するデ
ータ構造をサーバ処理に通過し、そして、クライアント
及びサーバ処理間に使用される通信プロトコルを設定す
るようなすべてのネットワーク環境を包括するように解
釈されるべきである。 【０１１９】 【０１２０】 【０１２１】 【発明の効果】本発明は、伝送層及びネットワーク層を
有する通信ネットワークにおいて、必要に応じて伝送層
及びネットワーク層を使用するパスをバイパスさせるこ
とによって、伝送層及びネットワーク層を必要以上に使
用しないような通信管理方法を与える。本発明の１実施
例によると、ローカルＲＰＣ（遠隔手続の呼び出し）の
性能は１０％乃至４０％の範囲で改善される。

【図面の簡単な説明】 【図１】本発明が実行されるコンピュータ・ネットワー
クを示すブロック図である。 【図２】物理的なネットワークのネットワーク層及び伝
送層とを用いた従来の遠隔手続の呼び出し（ＲＰＣ）を
説明するための図である。 【図３】ホスト・コンピュータの内部処理通信（ＩＰ
Ｃ）構造を使用して、ローカルＲＰＣが遂行される本発
明を説明するためのブロック図である。 【図４】ｉｐベースのプロトコル・シーケンスを越えて
ＡＦ＿ＵＮＩＸのプロトコル・シーケンスを選択するた
めにＲＰＣ機構をバイアスするための特性を用いてロー
カルＲＰＣを管理する良好な実施例を説明するための流
れ図である。 【符号の説明】 １０ クライアント １２ サーバ １４ ネットワーク １５ クライアント／サーバ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 グラント・マシュー・アルビス アメリカ合衆国 テキサス州、オースチ ン、イースト・フォーティサード・スト リート 603 (56)参考文献 特開 平６−180715（ＪＰ，Ａ) 特開 平６−259387（ＪＰ，Ａ) 特開 昭61−289458（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 13/00 G06F 9/46 H04L 29/00 - 29/12 H04L 12/00 - 12/26 H04L 12/50 - 12/66

Claims (1)

1. (57)【特許請求の範囲】 【請求項１】 伝送層及びネットワーク層を有する物理
   的なネットワークに接続されたホスト・コンピュータ上
   にクライアント処理が存在する分散された計算処理環境
   において、上記クライアント処理とサーバ処理との間の
   通信を管理する方法にして、 （ａ）上記クライアント処理によって遠隔手続の呼び出
   しが行なわれた時、当該遠隔手続の呼び出しによって識
   別されたサーバ処理が上記ホスト・コンピュータ上に存
   在するか否かを検出するステップと、 （ｂ）若し上記サーバ処理が上記ホスト・コンピュータ
   上に存在するならば、第１のセットと第２のセットとを
   含むバインディング・ハンドルのベクトルを上記クライ
   アント処理に戻すステップであって、上記第１のセット
   中の各バインディング・ハンドルは、上記伝送層及び上
   記ネットワーク層を使用することなく上記クライアント
   処理と上記サーバ処理との間に通信パスを設定するプロ
   トコル・シーケンスを含み、上記第２のセット中の各バ
   インディング・ハンドルは、上記伝送層及び上記ネット
   ワーク層を使用して上記クライアント処理と上記サーバ
   処理との間に通信パスを設定するプロトコル・シーケン
   スを含む、上記戻すステップと、 （ｃ）上記第１のセット中のすべてのバインディング・
   ハンドルが用い尽くされるまで、上記第１のセット中の
   １つのバインディング・ハンドルを使用して上記遠隔手
   続の呼び出しの実行を試行するステップと、 （ｄ）若し上記第１のセット中のすべてのバインディン
   グ・ハンドルが用い尽くされ、かつ上記クライアント処
   理と上記サーバ処理との間に通信パスが設定されていな
   ければ、上記遠隔手続の呼び出しの実行を試行するため
   に、上記第２のセット中の１つのバインディング・ハン
   ドルを使用するステップとを含む通信管理方法。