(57)【特許請求の範囲】
【請求項１】
分散計算環境内におけるクライアント・プロセスとサーバ・プロセスの間の通信を管理する方法であって、上記クライアント・プロセスは、トランスポート層及びネットワーク層を有する物理ネットワークに接続されたホスト・コンピュータ中に存在し、
上記方法は、
（ａ）  クライアント・プロセスによって行なわれた遠隔プロシージャ呼び出し（ＲＰＣ）に応答して、該ＲＰＣによって識別されたサーバ・プロセスが上記ホスト・コンピュータ中に存在するか否かを決定するステップであって、上記ＲＰＣは、トランスポート層及びネットワーク層の使用を介した通信路を定義するプロトコル順序を持つところの前記ステップと、
（ｂ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記ＲＰＣのプロトコル順序には関係なく、上記クライアント・プロセスと上記サーバ・プロセスとの間にインタープロセス通信路を設定するステップと、
（ｃ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記クライアント・プロセスがＲＰＣを生成するときにそれが予期するプロトコル順序を得るように、上記ＲＰＣのプロトコル順序を上記クライアント・プロセスに戻すステップと、及び
（ｄ）  上記ＲＰＣのプロトコル順序を使用する代わりに、上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含む通信管理方法。
【請求項２】
上記プロトコル順序はＲＰＣに影響を与えないで使用される、請求項１に記載の通信管理方法。
【請求項３】
上記プロトコル順序は接続指向プロトコル順序である、請求項１に記載の通信管理方法。
【請求項４】
上記プロトコル順序は非接続プロトコル順序である、請求項１に記載の通信の管理方法。
【請求項５】
上記遠隔プロシージャ呼び出しは、上記ホスト・コンピュータのオペレーティング・システムのメッセージ送受信機能を用いて実行される、請求項１に記載の通信管理方法。
【請求項６】
分散計算環境内におけるクライアント・プロセスとサーバ・プロセスの間の通信を管理する方法であって、上記クライアント・プロセスは、トランスポート層及びネットワーク層を有する物理ネットワークに接続されたホスト・コンピュータ中に存在し、
上記方法は、
（ａ）  遠隔プロシージャ呼び出し（ＲＰＣ）が上記クライアント・プロセスによって行なわれた時、上記遠隔プロシージャ呼び出しによって識別されたサーバ・プロセスが上記ホスト・コンピュータ中に存在しているか否かを決定するステップと、
（ｂ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、トランスポート層及びネットワーク層の使用を介した通信路を定義するプロトコル順序を含む第１データ構造を上記クライアント・プロセスに戻すステップと、
（ｃ）  上記第１データ構造を、上記クライアント・プロセス及び上記サーバ・プロセス間のインタープロセス通信路を定義するプロトコル順序を含む第２データ構造にマップするステップと、
（ｄ）  上記第１データ構造中の前記プロトコル順序を使用する代わりに、上記第２データ構造中のプロトコル順序によって定義された上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含む通信管理方法。
【請求項７】
上記遠隔プロシージャ呼び出しは、上記ホスト・コンピュータのオペレーティング・システムのメッセージ送受信機能を用いて実行される、請求項６に記載の通信管理方法。
【請求項８】
上記第１データ構造のプロトコル順序は上記ＲＰＣに影響を与えることなく使用される、請求項６に記載の通信管理方法。
【請求項９】
上記第１データ構造のプロトコル順序は接続指向プロトコル順序である、請求項６に記載の通信管理方法。
【請求項１０】
上記第２データ構造のプロトコル順序はソケット・ファイルに対するフル・パス名を含んでいる、請求項９に記載の通信管理方法。
【請求項１１】
命名規則及びエンドポイントが上記パス名を決定するのに用いられる、請求項１０に記載の通信管理方法。
【請求項１２】
ホスト・コンピュータがＵＮＩＸベースのオペレーティング・システムをサポートし、クライアント・プロセスがトランスポート層及びネットワーク層を有する物理ネットワークに接続された上記ホスト・コンピュータ中に常駐している分散計算環境内において、上記クライアント・プロセスが遠隔プロシージャ呼び出しを行なった時に、上記クライアント・プロセス及びサーバ・プロセス間の通信を管理する方法であって、
（ａ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を持つバンインディング・ハンドルを上記クライアント・プロセスに戻すステップと、
（ｂ）  上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を、上記クライアント・プロセス及び上記サーバ・プロセス間のインタープロセス通信路を設定する代替プロトコル順序にマップするステップと、及び
（ｃ）  上記ＵＮＩＸベースのオペレーティング・システムのメッセージ送受信機能を用いて、上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含み、
上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序は接続指向プロトコル「ncacn_ip_tcp」であり、且つ上記代替プロトコル順序は「ncacn_unix_stream」であり、「ncacn」は接続指向ＲＰＣプロトコルであり、「unix」は「ＵＮＩＸネットワーク・アドレス・ファミリィ（ＡＦ＿ＵＮＩＸ）通信ドメイン」を識別し、及び「stream」はＵＮＩＸドメイン・ソケットを識別するところの通信管理方法。
【請求項１３】
ホスト・コンピュータがＵＮＩＸベースのオペレーティング・システムをサポートし、クライアント・プロセスがトランスポート層及びネットワーク層を有する物理ネットワークに接続された上記ホスト・コンピュータ中に常駐している分散計算環境内において、上記クライアント・プロセスが遠隔プロシージャ呼び出しを行なった時に、上記クライアント・プロセス及びサーバ・プロセス間の通信を管理する方法であって、
（ａ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を持つバンインディング・ハンドルを上記クライアント・プロセスに戻すステップと、
（ｂ）  上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を、上記クライアント・プロセス及び上記サーバ・プロセス間のインタープロセス通信路を設定する代替プロトコル順序にマップするステップと、及び
（ｃ）  上記ＵＮＩＸベースのオペレーティング・システムのメッセージ送受信機能を用いて、上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含み、
上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序は非接続指向プロトコル「ncadg_ip_udp」であり、且つ上記代替プロトコル順序は「ncadg_unix_dgram」であり、「ncadg」は非接続ＲＰＣプロトコルであり、「unix」は「ＵＮＩＸネットワーク・アドレス・ファミリィ（ＡＦ＿ＵＮＩＸ）通信ドメイン」を識別し、「dgram」はＵＮＩＸドメイン・ソケットを識別するところの通信管理方法。
【請求項１４】
ユーザが分散されたリソース及びプロセス・アプリケーションにアクセスすることのできる分散計算環境を与え、且つトランスポート層及びネットワーク層を有するローカル・エリア・ネットワークに接続されたホスト・コンピュータを含むコンピュータ・システムであって、
前記ホスト・コンピュータ中に存在するクライアント・プロセスからの遠隔プロシージャ呼び出し（ＲＰＣ）に応答して、該ＲＰＣによって識別されたサーバ・プロセスが上記ホスト・コンピュータ中にあるか否かを検出する検出手段と、及び
該検出手段に応答して、予期されたプロトコル順序を上記クライアント・プロセスに戻し、且つ前記予期されたプロトコル順序の代わりに代替プロトコル順序を用いて、上記ＲＰＣを助長する手段であって、前記代替プロトコルは前記トランスポート層及びネットワーク層を経由しない通信路を設定するところの前記手段と
を含み、
上記予期されたプロトコル順序は、接続指向プロトコル「ncacn_ip_tcp」或いは非接続指向プロトコル「ncadg_ip_udp」であり、且つ上記代替プロトコル順序はそれぞれ「ncacn_unix_stream」或いは「ncadg_unix_dgram」であり、
上記代替プロトコル順序の使用は上記クライアント・プロセスに透過的であるコンピュータ・システム。
【請求項１５】
ホスト・コンピュータによって読み取り可能であり、かつ、上記ホスト・コンピュータで実行されるクライアント・プロセスからの通信を管理する方法を実施するための、該ホスト・コンピュータによって実行可能な命令からなるプログラムを記録したコンピュータ読み取り可能な記録媒体であって、上記ホスト・コンピュータはトランスポート層及びネットワーク層を有するローカル・エリア・ネットワークに接続されており、
（ａ）  遠隔プロシージャ呼び出しが上記クライアント・プロセスによって行なわれた時、上記遠隔プロシージャ呼び出しによって識別されたサーバ・プロセスが上記ホスト・コンピュータ中にあるか否かを検出するステップと、
（ｂ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記トランスポート層及びネットワーク層の使用を介した通信路を定義するプロトコル順序を含む第１データ構造を上記クライアント・プロセスに戻すステップと、
（ｃ）  上記第１データ構造を、上記クライアント・プロセス及び上記サーバ・プロセス間のインタープロセス通信路を定義するプロトコル順序を含む第２データ構造にマップするステップと、及び
（ｄ）  上記第１データ構造中の前記プロトコル順序を使用する代わりに、上記第２データ構造のプロトコル順序によって定義された上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含むプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク通信、より詳細に言えば、コンピュータ・ネットワーク中のクライアント・プロセス及びサーバ・プロセスが同じホスト・コンピュータにおいてサポートされている時、クライアント・プロセス及びサーバ・プロセスとの間の遠隔プロシージャ呼び出しを効率的に管理する方法に関する。
【０００２】
【従来の技術】
複数のコンピュータが、情報を交換し、かつリソースを共有することができるように、ローカル・エリア・ネットワーク（ＬＡＮ）に複数のコンピュータを相互に接続する技術は公知である。ローカル・エリア・ネットワークは、分散されたリソースと複数のコンピュータ中のプロセス・アプリケーションとに対して、ユーザがアクセスできるような分散計算環境を与える。ネットワーク通信は、いわゆる通信プロトコルを用いて遂行される。この通信規則によって、ローカル・エリア・ネットワークにおける通信アーキテクチャは、通常、物理層、論理リンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層及びアプリケーション層からなる７層モデルに標準化したものとして特徴付けられる。物理層は、情報を伝送するために使用される実際の物理的な装置及び媒体を含んでいる。論理リンク層は、データ・パケットをフレームし、かつ物理層のデータ・フローを制御して、実際の物理的媒体とは無関係にデータのデリバリーを保証する。ネットワーク層は、データ・パケットをアドレスし、そして経路指定を行なう。この層は、ソース・ノードと宛先ノードとの間で、ネットワーク中の経路を作成し、そして維持する。トランスポート層は、ノード間の伝送パイプラインを作成し、そしてネットワーク層との接続を管理する。セッション層は、通常、遠隔プロシージャ呼び出し（ＲＰＣ）のサポートを与え、ノード間の接続の一貫性を維持し、そしてデータ交換を制御する。プレゼンテーション層は、データをエンコードし、かつデコードし、そしてノード間の透過性動作態様を与える。最後に、アプリケーション層は、エンド・ユーザのプロセスに対してインターフェースを与え、かつアプリケーションに対して標準化されたサービスを与える。
【０００３】
７層モデルは特定のネットワークに応じて多くの変形を持っている。従って、例えばＡＩＸオペレーティング・システムの下でＩＢＭ社のRISC System/6000（商標）のコンピュータ・ワークステーションを動作するＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）アーキテクチャに基づいたネットワーク・アーキテクチャにおいては、セッション層とトランスポート層との間に存在するソケット層と呼ばれる他の層がある。ソケット層は、物理的なポートと等価な論理構造を持つ所謂「ソケット」を作成する。このアーキテクチャにおいて、ＲＰＣ機構は、セッション層においてサポートされるばかりでなく、セッション層の機能も含んでいる。分散計算環境（ＤＣＥ）において有用な周知のＲＰＣ機構は「オープン・システムズ・ファンデーション（ＯＳＦ）」によって与えられたソフトウェア・コードを含んでいる。
【０００４】
ＯＳＦ−ＤＣＥ−ＲＰＣ機構は、クライアントが遠隔プロシージャ呼び出し（ＲＰＣ）を用いてサーバにサービスを要求する場合に、「クライアント」及び「サーバ」間の通信を管理するために従来から使用されている。「クライアント」とは、計算環境内の何処かでアクセス可能なサービスを要求したネットワークの参加者のことである。「サーバ」は、クライアントにより要求されたサービスを提供する。ＯＳＦ−ＤＣＥ−ＲＰＣ機構において、各クライアント・プロセス（クライアントのコンピュータ中で実行されるプロセス）は、ソケット層によって作成される１つの関連ソケットを持っている。同様に、各サーバ・プロセスは１つのソケットに関連付けられる。ＲＰＣに応答して、呼び出しディレクトリ・サービスは、サーバ・プロセスが実行されるネットワーク・アドレス及びポート番号として、サーバ・プロセスの位置を特定する「バインディング・ハンドル」と呼ばれるデータ構造を戻す。次に、バインディング・ハンドルは、クライアント・プロセスとサーバ・プロセスとの間の通信路を定義するためにＲＰＣ機構によって使用される。この通信路は、ソケットをオープンするために、「インターネット・ネットワーク・アドレス・ファミリィ（ＡＦ＿ＩＮＥＴ）」のｉｐベース（即ち、ネットワーク層）プロトコル順序を用いて定義される。この通信路は、クライアント・プロセスから出発して、トランスポート層及びネットワーク層を通ってネットワークへ出た後に、サーバ・プロセスが実行されるホスト・コンピュータに関連した層へ戻るループ路を構成している。
【０００５】
上述のＯＳＦ−ＤＣＥ−ＲＰＣ機構は、クライアント・プロセス及びサーバ・プロセスが同じホスト・コンピュータ中で動作されているか否かを判別することはできない。すべての場合において、この機構は、トランスポート（ＴＣＰまたはＵＤＰ）層及びネットワーク（ＩＰ）層を通過する通信路を設定するＡＦ＿ＩＮＥＴプロトコル順序を含むクライアント・プロセスに、バインディング・ハンドルを戻す。ＴＣＰを通る通信は、接続指向プロトコル順序を使用するけれども、ＵＤＰを通る通信は、非接続プロトコル順序を使用する。然しながら、いずれの場合においても、クライアント・プロセス及びサーバ・プロセスが同じホスト・コンピュータ中に存在する時には、ＲＰＣは、所謂ループバック・メッセージを生成する。何故ならば、ネットワーク層（ＩＰ層）が宛先ネットワーク・アドレスを受け取ったならば、ＩＰ層は、ＲＰＣが「ローカル」であると認識し、従って、その通信路がトランスポート層を通ってアプリケーション層上のサーバ・プロセスにループ・バックされねばならないと認識するからである。このループ・バックの要件のために、同じコンピュータ中のクライアント・プロセス及びサーバ・プロセス間のＲＰＣは、性能の観点から見て最適化されていない。何故ならば、それらのＲＰＣは、必要としないトランスポート層及びネットワーク層を使用するからである。
【０００６】
【発明が解決しようとする課題】
従って、本発明の主目的は、ネットワーク中の同じホスト・コンピュータ中で実行しているクライアント・プロセス及びサーバ・プロセス間の遠隔プロシージャ呼び出し（ＲＰＣ）を効率的に管理することにある。
【０００７】
本発明の他の目的は、クライアント・プロセス及びサーバ・プロセスが同じホスト・コンピュータ中で実行されているか否かを、ネットワークのＲＰＣ機構によって識別させ、若しクライアント及びサーバ・プロセスの両方が同じホスト・コンピュータ中で実行されているならば、ローカル・インタープロセス通信（ＩＰＣ）機能を活用する代替プロトコル順序を用いてネットワーク層及びトランスポート層をバイパスさせることにある。
【０００８】
本発明のより特別の目的は、ＤＣＥ内のクライアント・プロセス及びサーバ・プロセスが同じホスト・コンピュータ中に存在する場合を検知し、これにより、遠隔プロシージャ呼び出しを動作させるためのネットワーク層（ＩＰ）またはトランスポート層（ＴＰ）の経路の代わりに、ローカルＩＰＣ機構を使用することにある。ＩＰ層またはＴＰ層をバイパスさせることは、性能に顕著な向上を与える。
【０００９】
本発明の他の目的は、同じホスト・コンピュータ中で実行されている２つのプロセスの間で行なわれるＲＰＣである「ローカル」ＲＰＣに影響するためのＩＰＣ機構を使用することにある。特定の実施例において、ＩＰＣ機構は「ＵＮＩＸドメイン」ソケットであって、本発明は「ＵＮＩＸネットワーク・アドレス・ファミリィ（ＡＦ＿ＵＮＩＸ）」に基づいた上述のソケットをオープンするために、接続指向プロトコル順序を使用している。ＡＦ＿ＵＮＩＸを使用することによって、そのオペレーティング・システム・カーネルは、同じホスト・コンピュータ中の２つのプロセス間のブリッジ通信のタスクを操作する。
【００１０】
本発明の他の目的は、サーバ・プロセス及びクライアント・プロセスが同じホスト・コンピュータ中で動作している時に、ローカルＲＰＣ機構の使用を自動化することにある。サーバ・プロセス及びクライアント・プロセスが同じホスト・コンピュータ中に存在する時に、アプリケーションがＲＰＣのローカル性に気づくことなく、ローカルＲＰＣ用のプロトコル順序が使用される。
【００１１】
【課題を解決するための手段】
ローカルＲＰＣ機能は常に使用可能にされていることが望ましく、そして「ローカル」ＲＰＣはクライアント・プロセスに対して透過的な動作態様を持っている。従って、ローカル・サーバ・プロセスに対するＲＰＣの検出に応答して、予期されたプロトコル順序が、クライアント・プロセスに戻され、他方、ホスト・コンピュータのＩＰＣ機構を通るＲＰＣを促進するために、代替のプロトコル順序が使用される。
【００１２】
本発明の上述の目的及び他の目的は、トランスポート層及びネットワーク層を有する物理的ネットワークに接続されたホスト・コンピュータ中に常駐するクライアント・プロセス及びサーバ・プロセス間の通信であり、かつ分散計算環境内にある通信を管理するための方法によって具現化される。本発明の方法は、クライアント・プロセスが遠隔プロシージャ呼び出し（ＲＰＣ）を行なった時に、遠隔プロシージャ呼び出しによって識別されたサーバ・プロセスが同じホスト・コンピュータ中に存在するか否かを検出することによって開始する。若し、クライアント・プロセスとサーバ・プロセスとが同じホスト・コンピュータ中に存在すれば、物理的ネットワークのトランスポート層及びネットワーク層を通る通信路の代わりに、クライアント・プロセス及びサーバ・プロセス間にインタープロセス通信路を設定するプロトコル順序を持つ少なくとも１つのバインディング・ハンドルを含んでいるバインディング・ハンドル・ベクトルがクライアント・プロセスに戻される。次に、望ましくはホスト・コンピュータのオペレーティング・システムの送信及び受信メッセージ伝達機能を用いて、遠隔プロシージャ呼び出しが実行される。
【００１３】
本発明の良好な実施例に従った「ローカル」ＲＰＣは、クライアント・プロセスに対する影響が透過的である（クライアント・プロセスに対して影響を与えない）。従って、ローカル・サーバ・プロセスに対するＲＰＣの検出に応答して、予期されたプロトコル順序がクライアント・プロセスに戻され、他方、ＲＰＣを助長するために、代替プロトコル順序が使用される。代替プロトコル順序は同じホスト・コンピュータのＩＰＣ機構を通る通信路を設定する。
【００１４】
より包括的に言えば、本発明の方法は、トランスポート層及びネットワーク層の両方を使用する通信路を定義するプロトコル順序を含む第１のデータ構造をクライアント・プロセスへ先ず戻すことによって、ローカルＲＰＣに応答する。次に、第１のデータ構造は、クライアント・プロセス及びサーバ・プロセス間のインタープロセス通信路を定義するプロトコル順序を含む第２のデータ構造にマップされる。次に、遠隔プロシージャ呼び出しは、第２のデータ構造中のプロトコル順序によって定義されたインタープロセス通信路を介して実行される。従って、本発明の良好な実施例において、第１のデータ構造のプロトコル順序は、ＲＰＣに影響を与えないで使用される。
【００１５】
ホスト・コンピュータがＵＮＩＸベースのオペレーティング・システムをサポートしている特定の実施例において、本発明の方法は、ＲＰＣによって識別されたサーバ・プロセスが同じホスト・コンピュータ中に存在するか否かを検出することによってＲＰＣに応答する。若し、ＲＰＣによって定義されたサーバ・プロセスが同じホスト・コンピュータ中に存在しているならば、本発明の方法は、遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を持っているバインディング・ハンドルをクライアント・プロセスに戻す。遠隔プロシージャ呼び出しに関連しているプロトコル順序は、通常、接続指向プロトコル「ncacn_ip_tcp」か、または非接続プロトコル「ncadg_ip_udp」かの何れかである。次に、プロトコル順序は、クライアント・プロセス及びサーバ・プロセス間のインタープロセス通信路を設定する代替プロトコル順序にマップされる。ＲＰＣが接続指向プロトコルを識別した場合には、このステップは、「ncacn_ip_tcp」をプロトコル順序「ncacn_unix_stream」にマップする。ＲＰＣが非接続プロトコルを識別した場合には、このステップは、「ncadg_ip_udp」を「ncadg_unix_dgram」プロトコル順序にマップする。次に、クライアント・プロセスは、クライアント・プロセスが予期したプロトコル順序を「検出する（見る）」けれども、しかし、そのプロトコル順序は、ＲＰＣに影響せずに使用される。上述の動作態様とは異なって、本発明の方法は、代表例において、ＵＮＩＸベースのオペレーティング・システムのメッセージ送受信機能を用いることによって、クライアント・プロセスに対して透過的に実行される。
【００１６】
上述の記載は、本発明に特に関連を持つ幾つかの目的の概略を説明したものである。これらの目的は、本発明の幾つかの特別な特徴及び適用例について単に説明したものとして理解されるべきである。本発明の実施の態様は以下に説明する通りであり、本発明を適用することによって、多くの他の有益な結果を得ることができる。
【００１７】
【発明の実施の形態】
上述したように、本発明は、総括的に言えば、複数のコンピュータに分散されたリソース及びプロセス・アプリケーションに、ユーザがアクセスすることのできる分散計算環境を提供するローカル・エリア・ネットワーク中のクライアント・プロセス及びサーバ・プロセス間の通信を管理することに向けられている。従来の分散計算環境（ＤＣＥ）は、図１に示されており、そしてネットワーク１４を介してサーバ１２に相互接続されたクライアント１０を含んでいる。クライアント１０及びサーバ１２の各々はコンピュータである。例えば、各コンピュータは、ＡＩＸ（Advanced Interactive Executive）オペレーティング・システムを実行するＩＢＭ（商標）社のRISC System/6000（商標）（縮小されたインストラクション・セット、即ち、所謂ＲＩＳＣをベースとしたワークステーション）であってもよい。ＡＩＸオペレーティング・システムは、アプリケーションのインターフェース・レベルにおいて、ＡＴ＆Ｔ社のＵＮＩＸオペレーティング・システムのバージョン５．２と互換性を持っている。ＲＩＳＣベースのワークステーション型コンピュータの種々のモデルは、例えば刊行物「RISC System/6000, 7073 and 7016 POWERstation and POWERserver Hardware Technical Reference, -- Order No. SA23-2644-00」など、ＩＢＭ社の多くの刊行物に記載されている。
ＡＩＸオペレーティング・システムは、ＩＢＭ社で刊行された刊行物「AIX Operating System Technical Reference, First Edition（１９８５年１１月）及び他の刊行物に記載されている。ＵＮＩＸオペレーティング・システムの設計に関する細部については、Prentice-Hall社により刊行された（１９８６年）バッハ（Maurice J. Bach）著の刊行物「Design of the Unix Operating System」を参照されたい。
【００１８】
本発明は、特定の１実施例において、ＩＢＭのシステム・ネットワーク・アーキテクチャ（ＳＮＡ）、より特定して言えばＳＮＡのＬＵ６．２の拡張プログラム間通信（Advanced Program to Program Communication-ＡＰＰＣ）によって相互接続された複数個のＩＢＭ社のRISC System/6000において実行される。ＳＮＡは、そのリンク・レベルとして、ゼロックス社によって開発されたローカル・エリア・ネットワーク（ＬＡＮ）のイーサネットまたはＳＤＬＣ（同期データ・リンク制御）を使用する。ローカル・エリア・ネットワークの簡単な説明は、ブレディ（Robert J. Brady、Prentice-Hall社）により刊行された（１９８３年）ジョーダン及びチャーチル（Larry E. Jordan and Bruce Churchill）共著の刊行物「Communications and Networking for the IBM PC」に記載されている。本発明は、上述した刊行物に記載されている技術を対象としているけれども、イーサネットＬＡＮ及びＩＢＭのＳＮＡ以外の他のネットワークによって相互接続されたＩＢＭのＲＩＳＣベースのパーソナルコンピュータ以外の他の異なったコンピュータを用いて実施することができることには注意を払う必要がある。従って、本発明は、例えば、ＯＳ／２オペレーティング・システムの下で動作するＩＢＭ社のＰＳ／２において実施することができる。ＰＳ／２コンピュータ及びＯＳ／２オペレーティング・システムに関する情報については、ＩＢＭ社で刊行した刊行物「Technical Reference Manual Personal Systems/2 Model 50, 60 Systems, Part No. 68x2224 -- Order Number S68X-2224」と、「OS/2 2.0 Technical Library, Programming Guide Volume 1~3 Version 2.00 -- Order No. 10G6495及び10G6494」とを参照されたい。
【００１９】
図１に戻って説明を続けると、クライアント１０及びサーバ１２の各々は、そのコンピュータがサービスを要求しているのか、またはそのコンピュータがサービスを提供するのかに応じて、クライアントとしてか、またはサーバとして動作する。通常、クライアントは、遠隔プロシージャ呼び出し（ＲＰＣ）を用いてサーバ・プロセスにサービスを要求する少なくとも１つのプロセスを含んでいる。然しながら、多くのＤＣＥアプリケーションは、「クライアント」プロセス及び「サーバ」プロセスの両方が同じホスト・コンピュータ中で実行されるような態様で書かれている。この態様は、クライアント／サーバ１５によって図１に示されている。クライアント／サーバ１５中のサーバ・プロセスのために意図されたクライアント・プロセスからのＲＰＣは、下記の説明を行なう目的のために、「ローカル」または「ローカルＲＰＣ」と呼ぶ。
【００２０】
従来のＯＳＦ−ＤＣＥ−ＲＰＣ機構において、ローカルであると否とに拘らずすべてのＲＰＣは、「ncacn_ip_tcp」か、または「ncadg_ip_udp」プロトコル順序であるネットワーク・ベース（例えば、「ｉｐベース」）プロトコル順序を用いて遂行される。この場合、「ncacn」は接続指向のＯＳＦ−ＤＣＥ−ＲＰＣプロトコル順序を表わし、そして「ncadg」は非接続のＯＳＦ−ＤＣＥ−ＲＰＣプロトコル順序を表わす。これらのプロトコルを用いた時、「ｉｐ」術語によって明らかなように、インターネット・アドレス・ファミリィ（ＡＦ＿ＩＮＥＴ）通信ドメインが使用される。各プロトコル順序の最後の構成要素はソケット・タイプを参照するから、従って、例えば、「udp」はデータグラムを参照する。ＲＰＣに応答して、セル・ディレクトリ・サービス・デーモン（cell directory service daemon−ＣＤＳＤ）の呼び出しは、サーバ・プロセスが実行されているネットワーク・アドレス及びポート番号としてのサーバ・プロセスの位置を特定する、所謂、「バインディング・ハンドル」を戻す。また、バインディング・ハンドルは、ＲＰＣによって要求されたサーバ・プロセスを識別する。次に、バインディング・ハンドルは、クライアント・プロセス及びサーバ・プロセス間の通信路を定義するために、ＲＰＣ機構によって用いられる。この通信路は、ソケットをオープンするために、ＡＦ＿ＩＮＥＴのｉｐベース（即ちネットワーク層）のプロトコル順序を用いて定義される。この通信路は、クライアント・プロセスからトランスポート層及びネットワーク層を通ってネットワークに出た後に、サーバ・プロセスが動作しているホスト・コンピュータに関連された層に戻るループを形成する。
【００２１】
従って、クライアント・プロセス及びサーバ・プロセスが同じホスト・コンピュータ中に存在しているとしても、トランスポート層（ＴＣＰまたはＵＤＰ）及びネットワーク（ＩＰ）層がループバック・メッセージを送るのに使用される。これは、図２に示されている。
【００２２】
本発明に従うと、ｉｐベースのプロトコル順序を使用する代りに、クライアント・プロセスに対して透過的な態様（影響を与えない）でローカルＲＰＣを助長するための代替プロトコル順序が用いられる。この透過的な態様のために、ローカルＲＰＣは、アプリケーションに「隠されて」遂行されると言われる。若しオペレーティング・システムがＡＩＸ、またはＯＳ／２オペレーティング・システムであれば、プロトコル順序「ncacn_unix_stream」は、接続指向ｉｐベースのプロトコル順序（即ち、「ncacn_ip_tcp」）を識別するローカルＲＰＣに使用される。指定子「ncacn」は、接続指向ＲＰＣプロトコルを指定し、「unix」はＵＮＩＸネットワーク・アドレス・ファミリィ（ＡＦ＿ＵＮＩＸ）通信ドメインを識別し、そして「stream」はＵＮＩＸドメインのストリーム・ソケットを識別する。ＯＳ／２オペレーティング・システムの下でローカルＲＰＣ機能が動作している場合、非接続ｉｐベースのプロトコル順序（即ち、「ncadg_ip_udp」）の下で発行されたＲＰＣは、プロトコル順序「ncadg_unix_dgram」の使用を生じる。この場合、「ncadg」は非接続ＲＰＣプロトコルを表わし、そして「unix_dgram」はＵＮＩＸドメイン・データグラム・ソケットを識別する。勿論、上述したオペレーティング・システムは、単なる例示であって、本発明はこれらのオペレーティング・システムのみに限定して解釈されるべきものではない。何れの場合でも、クライアント・プロセスには、実際のＲＰＣが、異なったローカルの機構を用いて遂行されたとしても、クライアント・プロセスが予期するプロトコル順序が戻される。使用される実際のプロトコル順序は、「ＵＮＩＸネットワーク・アドレス・ファミリィ（ＡＦ＿ＵＮＩＸ）」を使用することによって、トランスポート層及びネットワーク層の使用を回避する。
【００２３】
ＡＦ＿ＵＮＩＸを使用することによって、オペレーティング・システム・カーネルは、同じホスト・コンピュータ中の２つのプロセスの間の通信を連結するタスクを操作する。ＡＦ＿ＵＮＩＸは、クライアント・プロセスとサーバ・プロセスとの間のインタープロセス通信（ＩＰＣ）を実行するために好ましい技術であるけれども、他のオペレーティング・システム（ＯＳ）のＩＰＣ機構（共有メモリとかメッセージ待ち行列など）も同じように使用することができる。どのような場合でも、ローカルＩＰＣ機構の使用は、トランスポート層及びネットワーク層を通したループバック呼び出しを行なうよりも著しく速いので、性能の改善は顕著なものがある。本発明の機能は図３に示されている。
【００２４】
ncacn_unix_streamプロトコル順序は、同じホスト・コンピュータ中に存在するＤＣＥ（分散計算環境）アプリケーションのプロセスの間で行なわれるＲＰＣによってのみ用いられるのが好ましい。ＲＰＣランタイム（runtime）は、若しサーバが同じホスト・コンピュータ中に存在しなければ、クライアント・アプリケーションに、ncacn_unix_streamのバインディングを戻さない。ncacn_unix_streamプロトコル順序は、同じホスト・コンピュータ中のＤＣＥアプリケーションによって使用されるものだから、これらのバインディングはネットワーク・アドレスを含んでいない。また、ncacn_unix_streamのバインディング・ハンドルのエンドポイント（endpoint）は、ＵＮＩＸソケット・ファイルのフル通信路名（full pathname）として表示される。固有のソケット・ファイルが、クライアント・プロセスとサーバ・プロセスとの間で設定された各アソシエーション（組み合せ）のために使用される。デフォルトによって、これらのソケット・ファイルは、接頭部、DCE_CNを持つファイル名を有するディレクトリ、/var/dce/rpc/socket中にオープンされる。また、デフォルトによって、各ソケット・ファイルの名前は、オブジェクトＵＵＩＤ（universal unique identifier−ユニバーサル・ユニーク識別子）であり、このユニバーサル・ユニーク識別子は各ファイル名の固有性を保証する。ＵＵＩＤは、ＵＵＩＤゼネレータ・ルーチンによって作成された実質的に長くランダムな数字である。ＲＰＣランタイムによって、エンドポイントをncacn_unix_streamのバインディングに割り当てる時、そのバインディングは、「オブジェクトＵＵＩＤ」であり、これは、ソケット・ファイル名の固有性を保証する。これは、ＤＣＥアプリケーションの２つの呼び出しにおいて、ソケット・ファイルが再度使用されるような場合が皆無であることを意味する。
【００２５】
ＵＮＩＸベースのオペレーティング・システムにおいて、ＯＳカーネルは、そのカーネルがユーザのために作業を行なう前に、ファイルをオープンすることをユーザに要求する。本発明によって作成されたソケット・ファイルは、ＯＳカーネルのプレースホルダーとして保存される長さのないファイルである。固有の各ソケット・ファイルは、作成されたファイル・システム中にｉノードのエントリを占領する。ＯＳカーネルは、ファイル・システム中のプレースホルダーとしてソケット・ファイルを用いることによってＲＰＣを遂行し、次に、それ自身のデータ構造を制御して、ＲＰＣを具現させるために、クライアント・プロセス及びサーバ・プロセスの間でデータを送信し、かつ受信する。従って、ＯＳカーネルは、この目的のために、例えば「Ｍｂｕｆ」のデータ構造を使用することができる。
【００２６】
下記の記載は、本発明において使用されるncacn_unix_streamストリングのバインディングの幾つかの例を示している。
ncacn_unix_stream:[]
ncacn_unix_stream:[/var/dce/rpc/socket/0063980e357b-le07-878b-10005a4f3bce]
このように、プロトコル順序は、接続指向の「ncacn」ＲＰＣプロトコル、AF_UNIX通信ドメイン（「ｕｎｉｘ」のコンポーネントによって識別される）及び「stream」タイプのソケットの返却を含んでいる。１番目の例示において、エンドポイント（つまり、括弧［］内のデータ）は空である。２番目の例示においては、エンドポイントは、デフォルトのソケット・ディレクトリ「/var/dce/rpc/socket/_」及びＵＵＩＤを識別する。
【００２７】
従って、エンドポイントは、/var/dce/rpc/socketディレクトリ中のオブジェクトＵＵＩＤである必要はない。ＩＤＬ（Interface Definition Langauge-インターフェース定義言語）仕様書のファイル中の「エンドポイント」の属性は、固有のファイルに対する通信路名を特定するのに用いることができる。あるいは、アプリケーションは、ncacn_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]が仮定され、ソケット・ファイルを作成するために使用される。また、エンドポイント・マップのエントリは、絶対通信路を持っている。このことは、相対通信路が初めて使用される前に、相対通信路は、絶対通信路まで常に拡張され得るので、２つのフォームが相互に交換可能に用いられた時に問題を生じることがない。
【００２８】
ローカルＲＰＣ技術のオリジナルの実施において、ＲＰＣランタイム（実行時）ライブラリは、クライアント及びサーバが同じホスト・コンピュータ中に存在する場合を認識し、そして、機能rpc_ns_binding_import_next()が他のプロトコル順序のためのバインディングを戻す前に、そのようなバインディングを、機能rpc_ns_binding_import_next()に戻させることによるか、あるいは、バインディング・ベクトルの低い位置中のすべてのncacn_unix_streamのバインディングを、機能rpc_ns_binding_lookup_next()に戻させることによってncacn_unix_streamの使用を促進する。性能上の理由のために、そのような実施例においてrpc_ns_binding_<import/lookup>_next()ルーチンから戻されたncacn_unix_streamのバインディング・ハンドルは、完全に結合される。これは、そのバインディングのベクトルがＲＰＣエンドポイント・マップから到来し、そのバインディングの中にエンドポイントを持っていたことによる。この実施例において、ncacn_unix_streamのバインディング情報は、ＲＰＣのＡＰＩルーチンrpc_ns_binding_export()が呼び出された時、ＣＤＳ（セル・ディレクトリ・サービス）ネーム・スペースのデータベースへエクスポートされない。この理由は、クライアント及びサーバのアプリケーションが同じホスト・コンピュータ中に存在する時だけに、ncacn_unix_streamのバインディングが使用可能だからである。ＣＤＳネーム・スペースは、「ＤＣＥセル」中の任意のコンピュータ中のＤＣＥのアプリケーションによって読み取ることができるから、ＣＤＳネーム・スペースのデータベース中のncacn_unix_streamストリームのバインディングは、遠隔地のサーバと通信する必要のあるクライアントに対して使用不能である。
【００２９】
その代わりに、ncacn_unix_streamのバインディングは、ＤＣＥのサーバ・アプリケーションがＲＰＣのＡＰＩルーチンrpc_ep_register()を呼び出した時に、ＲＰＣエンドポイント・マップのデータベース中にのみ登録される。この理由は、ＤＣＥセル中の各ホスト・コンピュータで実行するＲＰＣエンドポイント・マップのデーモンがあるためであり、これは、ホスト・コンピュータ特定の情報をストアするために、更に良い論理的位置にする。クライアントが、互換性を有するサーバのバインディング用のＣＤＳネーム・スペースを問い合わせた時、ＲＰＣランタイムは、セルがローカル・ホスト・コンピュータ中のサーバ用であるか否かを決定する。若しセルがサーバ用であれば、ＣＤＳネーム・スペースから、すべてのバインディングを戻すことに加えて、ＲＰＣランタイムは、互換性を有するncacn_unix_streamのバインディングがあるか否かを検出するためにＲＰＣエンドポイント・マップに行く。若し互換性を持つncacn_unix_streamのバインディングがあれば、そのバインディングはＣＤＳネーム・スペースから戻されたバインディングよりも高い優先権を与えられる。若しクライアント及びサーバが異なったホスト・コンピュータの中にあれば、エンドポイント・マップの検索は行なわれない。何故ならば、この場合のエンドポイント・マップの検索は、使用可能なバインディングを生じないからである。
【００３０】
ＤＣＥサーバ・アプリケーションが通常の状態で存在する時、この状態は、ＤＣＥサーバ・アプリケーションが存在する前に、ＲＰＣのエンドポイント・マップから、他のものと共に、そのエンドポイントを登録しない。ncacn_ip_tcp及びncacn_ip_udpのようなｉｐベースのプロトコルの場合において、ＤＥＣアプリケーションを受信しようとしていたポートは、オペレーティング・システムによって整理されるから、ポートを解放するためのアプリケーション動作は要求されない。ncacn_unix_streamのエンドポイントは、ユーザ・スペース・ファイルであり、これらのファイルは、ＤＣＥアプリケーションが存在する時には、オペレーティング・システムによって除去されない。
【００３１】
既に説明したように、ＲＰＣランタイムによって、エンドポイントをncacn_unix_streamのバインディングに割り当てる時に、このバインディングは、固有であることが保証されている「オブジェクトＵＵＩＤ」である。このことは、ＤＣＥアプリケーションの２つの呼び出し中で、ソケット・ファイルが再度使用されることはあり得ないことを意味する。従って、古いソケット・ファイルが残留している事実は、短時間では問題にはならない。然しながら、時間の経過と共に、これらのソケット・ファイルは累積されるであろう。既に述べたように、ソケット・ファイルは、長さがゼロであるけれども、しかし、各ソケット・ファイルは、ソケット・ファイルが作成されたファイル・システム中にｉノード・エントリを占める。従って、これらの古いソケット・ファイルを整理するための何らかの手段を持つことが必要である。これは、ＲＰＣエンドポイント・マッパ（ＲＰＣデーモン）によって行なわれる。
【００３２】
/var/dce/rpc/socketディレクトリ中のソケットだけが自動的に整理されることには注意を払う必要がある。若しＤＣＥアプリケーションがＤＣＥアプリケーション以外のディレクトリを用いて、そのncacn_unix_streamエンドポイントを作成したならば、古いエンドポイントが整理されることを保証することは、アプリケーション、またはアプリケーションのユーザの責任である。これは、rpc.cleanユティリティを用いて行なわれる。rpc.cleanユティリティは、検査されるべき古いソケット・ファイルに関するディレクトリを、ユーザにより特定させる。このユティリティは、そのディレクトリを検索し、そして検出されたすべての古いソケット・ファイルを除去する。これは、ＲＰＣのエンドポイント・マップが行なう整理と同じ整理を遂行する。ＤＣＥ管理記述、dce.clean、rc.dce、またはrmdceが実行される時には常に、ソケット・ファイルの累積問題を解決する付加的な保護策として、rpc.cleanユティリティが含まれる。
【００３３】
ＤＣＥの多くの内部活動（即ち、ＲＰＣデーモン及びセキュリティ／ネーム・スペースのサービスを含む通信活動）が、同じコンピュータにおいて実行されている２つのプロセスの間でＲＰＣを用いて遂行された場合であって、上述のローカルＲＰＣのアプローチ（ｕｎｉｘドメイン・ソケットを用いた方法）が実施された場合、ＤＣＥシステム全体の性能は約４０％向上した。このローカルＲＰＣ構造は、本発明に従って更に改善される。本発明の実施例において理解できるように、すべてのローカルＲＰＣ動作はデフォルト動作として最適化されることが望ましい。明示的な接続指向（ＣＮ）プロトコルは、ＲＰＣのアプリケーション及びクライアント・プロセスに対して透過的な態様（影響を与えない）で、しかも、速いローカルunix_streamプロトコルに自動的に切換えられる。同様に、明示的な非接続（ＤＧ）プロトコルは、速いローカルunix_dgramプロトコルに自動的に切換えられる。本発明の実施例において、明示的なunix_streamプロトコルをクライアント・プロセスに戻すことは最早や必要としない。プロトコルの切り換えは、ＲＰＣ機構及びアプリケーションに「隠されて」遂行され、これは性能を更に向上させる。
【００３４】
特に、上述したオリジナルのローカルＲＰＣアプローチにおいて、unix_streamプロトコルは、明示的に与えられており、ＤＣＥデーモンの「エンドポイント・マッパ」中に現われる異なったタイプのエンドポイントの形式でユーザに可視的である。アプリケーションが、接続指向プロトコル順序かまたは非接続プロトコル順序を使用するように選択し、かつローカルＲＰＣ機構が暗黙的に優先権を取る場合か、または、アプリケーションが、unix_streamプロトコルを使用するように選択した場合に、改良型のローカルＲＰＣが行なわれる。改良型のローカルＲＰＣは、unix_streamのエンドポイントのための動作に関連された「エンドポイント・マッパ」を除去する。
【００３５】
従って、本発明の上述の改良型の実施例において、透過的な態様の切換えはユーザのプロトコル順序（ＲＰＣにおいて識別される）から、ある種のローカル・プロトコルに移り、そして、この透過的な態様の切換えは自動的に生じるのが望ましい。このアプローチは、明示的なunix_streamまたはunix_dgramプロトコルを取り除き、そして、接続指向（ＣＮ）及び非接続（ＤＧ）プロトコルのために最適化されたローカルＲＰＣをデフォルトとして設定する。然しながら、ＣＮ及びＤＧデフォルトの意味を保存するために、別個のＣＮローカルＲＰＣ内部サポート（ncacn_unix_stream）及びＤＧローカルＲＰＣ内部サポート（ncacn_unix_dgram）が作成される。
【００３６】
クライアント・プロセスが遠隔プロシージャ呼び出しを行なった時に、分散計算環境内のクライアント・プロセス及びサーバ・プロセス間の通信を管理する方法における主要なステップを示した図４の流れ図において、上述の代替プロトコル順序の処理方法が示されている。この方法において、クライアント・プロセスは、ホスト・コンピュータがＡＩＸのようなＵＮＩＸベースのオペレーティング・システムをサポートしており、かつ、トランスポート層及びネットワーク層を有する物理的ネットワークに接続されている同じホスト・コンピュータ中に常駐しているものと仮定する。この方法は、サーバ・プロセスが同じホスト・コンピュータ中に存在しているか否かを決定するステップ３０で開始する。若しサーバ・プロセスが同じホスト・コンピュータ中にあれば、この方法は、遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を持つバインディング・ハンドルをクライアント・プロセスへ戻すステップ３２に続く。次に、クライアント・プロセスは、予期しているプロトコル順序（ＲＰＣで与えられたプロトコル順序）を「検出」する。次に、この方法は、遠隔プロシージャ呼び出しと通常関連しているプロトコル順序を、クライアント・プロセス及びサーバ・プロセス間のインタープロセス通信路を設定する代替プロトコル順序にマップ処理するステップ３４に続く。（ステップ３２及び３４を反対にすることができる。）従って、例示的な説明目的に限定して、若し遠隔プロシージャ呼び出しに関連したプロトコル順序が接続指向のプロトコル「ncacn_ip_tcp」であれば、このステップは、そのプロトコル順序を、同じコンピュータ上で実行している代替プロトコル順序にマップする。この機能は常に使用可能にされていることが望ましい。従ってサーバ・プロセス及びクライアント・プロセスが同じコンピュータ中に存在する場合には、「ncacn_ip_tcp」プロトコル順序の代わりに「ncacn_unix_stream」プロトコル順序が使用され、そして、「ncadg_ip_udp」プロトコル順序の代わりに「ncadg_unix_dgram」プロトコル順序が使用される。上述した２つの代表的なオペレーティング・システムのコンテキストにおいて、この技術は、ＡＩＸ及びＯＳ／２の両方のオペレーティング・システムに対して、「ncacn_ip_tcp」プロトコル順序を「ncacn_unix_stream」に切換え、そして、ＯＳ／２オペレーティング・システムだけに対して、この機能が動作可能にされる時に「ncacn_ip_udp」プロトコル順序を「ncadg_unix_dgram」に切換えることが望ましい。ＯＳ／２オペレーティング・システムだけに限定した後者の場合の理由は、「ncadg_unix_dgram」プロトコル順序を実行することが、ＡＩＸオペレーティング・システムの性能を顕著に改善しないからである。従って、若しアプリケーションがＡＩＸの「ncadg_ip_udp」プロトコル順序を使用したならば、ローカルＲＰＣは、サーバ及びクライアントのプロセスが同じコンピュータ中に存在したとしても推奨されるものではない。この機能を使用不能にするために、環境変数、DISABLE_AUTO_LRPCは１にセットされる。
【００３７】
以下の記載は、最適化されたローカルＲＰＣ機構の細部を更に詳しく説明したものである。この説明を総括的に言えば、ＤＣＥのプログラミング規則に精通していること、より特定して言えば、ＲＰＣ機構に精通していることが前提とされる。設計の第１の局面は、どのプロトコル順序がサポートされているかをユーザが識別することであり、この識別はＲＰＣ初期化ルーチンの間で行なわれる。若しユーザがＲＰＣ＿ＳＵＰＰＯＲＴＥＤ＿ＰＲＯＴＳＥＱＳを、１つまたはそれ以上のプロトコル順序にセットしたならば、これらのプロトコル順序だけがサポートされる。然しながら、ＲＰＣ初期化ルーチンを終了する時に、ＤＩＳＡＢＬＥＤ＿ＡＵＴＯ＿ＬＲＰＣ変数がチェックされる。若しこの変数が１にセットされていなければ、大域変数「defaultrpc」が「真」にセットされる。次に、ＲＰＣ「ランタイム」は最適化されたローカルＲＰＣ機能をサポートする。これは、「ncacn_unix_stream」及び「ncadg_unix_dgram」プロトコル順序がＲＰＣ「ランタイム」によってサポートされていることを意味する。「ランタイム」コードのすべての変更は、defaultlrpc変数が「真」である時だけに実行される。
【００３８】
最適化されたローカルＲＰＣ機能をサポートするために必要な変更であって、アプリケーションのサーバ・プロセスに関連する変更は、以下に説明する通りである。以下の説明は、ncacn_ip_tcpプロトコル順序の場合に関連するものであるけれども、同じ考え方をncacn_ip_udpプロトコル順序に適用することができるのは理解されるべきである。ローカルＲＰＣの１つの機能は、サーバ・プロセスが聴取しているプロトコル順序用の公知のエンドポイント及び動的エンドポイントのすべてのエンドポイントを含む「Ｕｎｉｘドメイン」ソケットをオープンしなければならないことである。この理由は、若しストリング・バインディングが公知のエンドポイントまたは動的エンドポイントを用いてクライアントに与えられたならば、ＤＣＥデーモンが同じコンピュータ中で実行されるものと推測することができないからである。従って、ncacn_unix_streamプロトコル順序及び特別のエンドポイントを用いて、完全な宛先rpcアドレスを作成し、次に、その宛先rpcアドレスをバインディング表示中にストアする必要がある。これは、「Ｕｎｉｘドメイン」ソケットに結合されている特別な公知のエンドポイント及び動的エンドポイントのすべてを持っている「Ｕｎｉｘドメイン」ソケットを、サーバ・プロセスが聴取しなければならないことを意味する。
【００３９】
最適化されたローカルＲＰＣを実施するために、ファイルsrc/rpc/runtime/cnnet.cの中のrpc_cn_network_use_protseq()は変更されねばならない。このルーチンにおいて、ｔｃｐソケットがオープンされる時には常に、対応するｕｎｉｘストリーム・ソケットがオープンされる。この処理が、図４に示したマップ作成ステップである。このｕｎｉｘストリーム・ソケットのために、ｕｎｉｘのrpc_addrが割り当てられ、tcpエンドポイントが命名規則に従ってｕｎｉｘストリームのエンドポイントに変換される。また、このｕｎｉｘストリーム・ソケットは、ソケット記述子に加えられる。従って、rpc_cn_network_use_protseq()ルーチンは以下のように実行される。
0003962112.tif 000002
以上の説明は、アプリケーション・サーバ・プロセスに関係した変更に関するものである。
【００４０】
アプリケーションのクライアント・プロセスに関係した変更を以下に説明する。クライアントのアプリケーションがＲＰＣランタイムに対して先ず最初に行なう第１の呼び出しは、rpc_call_start()であり、この呼び出しは、転じて、バインディング・ハンドル中のプロトコル識別子に従って、プロトコル特定のルーチン、つまりrpc_dg_call_start()か、またはrpc_cn_call_start()を呼び出す。プロトコル特定のルーチンを呼び出す前に、rpc_call_start()に対して下記のような変更が行なわれる。
【００４１】
このルーチンは、バインディング・ハンドル中の宛先アドレスがローカル・ホスト・コンピュータのipアドレスの１つと等しいか否かを決定することによって開始する。（この比較は、若しＴＣＰ／ＩＰがコンピュータ中に導入されていなければ動作しない。むしろ、ＮｅｔＢｉｏｓ用のＲＰＣプロトコル順序に関係したアドレスのために、異なったタイプの比較が必要とされる。）若しこの比較が真であれば、アプリケーションがrpc_call_start()に通されたプロトコル順序に代わって、ncacn_unix_streamプロトコル順序が使用されるように、バインディング表示中の該当するフィールドが変更される。バインディング表示は下記のフィールドを持っている。
typedef struct {
rpc_list_t link;
rpc_protocol_id_t protocol_id;
signed8 refcnt;
uuid_t obj;
rpc_addr_p_t rpc_addr;
unsigned is_server: 1;
unsigned addr_is_dynamic: 1;
rpc_auth_info_p_t auth_info;
unsigned32fork_count;
unsigned bound_server_instance: 1;
unsigned addr_has_endpoint: 1;
unsigned32 timeout;
signed8 calls_in_progress;
pointer_t ns_specific;
rpc_clock_t call_timeout_time; }
rpc_binding_rep_t, rpc_binding_rep_p_t;
このルーチンに従って、バインディング表示中のプロトコル識別子フィールドは、接続指向ＲＰＣプロトコル識別子、つまり０で置き換えられる。バインディング表示は、その中にストアされた宛先ｒｐｃアドレスを持っており、そしてrpc_addrは、rpc_addr_p_tタイプである。
typedef struct {
rpc_protseq_id_t rpc_protseq_id;
unsigned32 len;
sockaddr_t sa;
} rpc_addr_p_t;
【００４２】
ファイルsrc/rpc/runtime/cncall.c中の機能rpc_cn_call_start()は変更されなければならない。先ず、元のrpc_addr構造が保存される。この時点において、rpc_addrは公知のエンドポイントを持っている。ルーチンは、このエンドポイントをｕｎｉｘストリーム・エンドポイントに変換した後にｕｎｉｘストリームのための宛先rpcアドレスを作成する。次に、ルーチンは、バインディング表示中のrpc_addrを、新しいrpc_addrに置き換える。ncacn_unix_streamプロトコルを持つこのrpc_addrは「エンドポイント・マッパ」に登録されず、従って、ユーザに対して可視的ではない。その後、ＲＰＣはｕｎｉｘストリーム及び接続指向ＲＰＣプロトコルを使用して可視的になる。すべての送信及び受信が完了した後、元のrpc_addr構造は、バインディング表示にコピーされ、そしてクライアント・プロセスに戻される。rpc_cn_call_start()の機能は下記の通りである。
0003962112.tif 000003
【００４３】
最適化されたローカルＲＰＣ機構において、ｕｎｉｘストリームを持つバインディングは、「エンドポイント・マッパ」中に登録されず、あるいはネーム・スペースにエクスポートされない。クライアント・プロセスが、import_begin及びimport_next呼び出し機能を用いてバインディングに問い合せを行なった時、クライアント・プロセスは、ncacn_unix_streamを持つバインディングを獲得しない。ＡＰＩ呼び出しrpc_server_inq_bindingsは、ＲＰＣが行なわれるサーバのバインディングを戻す。この機能はバインディングを得るために、聴取側のソケットからのソケットを使用する。サーバはストリーム・ソケットにおいて聴取しているから、下記のフィルタが与えられる。
0003962112.tif 000004
【００４４】
既に説明したように、本発明に従って、アプリケーションのクライアントは、ｕｎｉｘストリーム・プロトコルを使用してアプリケーションのサーバと対話するから、従って、このプロトコルはアプリケーションのサーバに露呈される。これを遮蔽するために、rpc_binding_from_string_bindingルーチンが変更される。この場合、rpc_addrは、バインディング・ハンドルからのものではなく、ローカル・コンピュータのアドレス及びncacn_ip_tcpプロトコル順序によって満たされる。これを行なうことによって、クライアント・プロセスは、それが予期していたプロトコル順序を「検知」し、そして代替プロトコル順序が通信路に影響するように使用される。その結果、ncacn_unix_streamが、ユーザから隠蔽される。この機能は下記の通りである。
0003962112.tif 000005
【００４５】
上述した設計は、最適化されたローカルＲＰＣ構造を実行するために必要な変更を説明するものである。この改善の重要な目標は、この最適化されたＲＰＣ構造の実施がユーザに不可視的にすることと、従来のクライアント／サーバ・アプリケーションに対して逆向きの互換性を持たせることとを保証することである。
【００４６】
ncacn_unix_streamプロトコル順序に対してどのようにしてＲＰＣのサポートを付加するかについての細部の説明を以下に記載する。
【００４７】
0.1.1  外部インターフェースの説明
ＲＰＣランタイム及びＲＰＣＤの外部インターフェースは以下のように変更される。
ユーザは、従来からサポートされているプロトコル順序に加えて、付加的なプロトコル順序を指定するための新しい能力を持っている。この新しいプロトコル順序は「ncacn_unix_stream」と名付けられる。ＡＰＩ機能パラメータ、環境変数、またはコマンド・ライン引数を、プロトコル順序用ストリング・フォーマットの仕様に用いることができる場合には常に、ストリーム「ncacn_unix_stream」の使用が可能である。
【００４８】
0.1.2  内部設計の説明
ＲＰＣの拡張は、クライアント及びサーバが同じホスト・コンピュータ中に存在する場合に使用される新しいプロトコル順序（ncacn_unix_stream）のためのサポートを加える。
【００４９】
このＲＰＣの拡張は、ユーザに対して仮想的に不可視であり、そして、従来のクライアント／サーバ・アプリケーションとは逆向きの互換性を有する。
【００５０】
本発明は、ＩＢＭのＯＳ／２プラットホームのような他のプラットホームに対して移植性（portable）がある。ＯＳ／２はＵＮＩＸドメインに対するサポートを有する（ＭＰＴＳを介して）。ＯＳ／２の「共通ポーティング・プラットホーム（ＣＰＰ）」のＤＬＬは、ＯＳ／２を変更することなく、殆どすべてのＵＮＩＸ特定サブルーチン呼び出しを使用可能にする。
【００５１】
新しいプロトコル順序の付加が従来のコードを殆ど変更することなく、ＲＰＣランタイム・ライブラリの設計を行なうことができる。これは、２つの手段、即ち（１）モジュラー・データ構造と、（２）エントリ・ポイント・ベクトルとを使用することによって達成される。モジュラー・データ構造は、プロトコル順序を作る幾つかの要素に関する一貫した機構を与えることによって新しいプロトコル順序を付加することを容易にする。ＲＰＣランタイム・コードの大部分がすべてのプロトコルに共通なので、エントリ・ポイント・ベクトルを使用することは、インデックスを通して機能アレイのライン毎に、プロトコル特定のルーチンにアクセスすることができる。プロトコル識別子は、エントリ・ポイント・ベクトル中のインデックスとして使用される。新しいプロトコル順序には、そのプロトコル順序に特定された処理を操作するための新しいルーチンを加えることが必要である。
【００５２】
ncacn_unix_streamプロトコル順序は、AF_UNIXアドレス・ファミリィと、ＳＯＣＫ＿_ＳＴＲＥＡＭのソケット・タイプとを用いて作成される。ソケット・アドレスは、インタープロセス通信機構としてのフル通信路名の仕様を用いて、構造sockaddr_unを使用する。クライアント及びサーバはこのプロトコル順序を用いるために同じホスト・コンピュータ中に常駐していなければならない。このプロトコル順序は接続指向であり、そしてＣＮプロトコル識別子を使用する。
【００５３】
以下の項において、新しいプロトコル順序を実行するために変更を必要とするＲＰＣソース・ファイルを説明する。以下の説明において、広範な含意変更（implication change）から開始して、より特別な変更に減縮するようなファイルのリストを作るように試みられている。
【００５４】
0.1.2.1  src/rpc/runtime/com.h
このファイルは既存のファイルである。下記のような定数識別子を付加することが必要である。これらの定数は、使用する構造及び適正なインデックス・エントリ・ポイント・ベクトルにアクセスするために、すべてのＲＰＣランタイム・コードに亙って使用される。
ＲＰＣプロトコル順序識別子定数：
#define rpc_c_protseq_id_ncacn_unix_stream 5
ＲＰＣプロトコル順序ストリング定数：
#difine rpc_protseq_ccacn_unix_stream "ncacn_unix_stream"
ＲＰＣ「ネットワーク・アドレス・ファミリィ」定数：
#define rpc_c_naf_id_unix 1
【００５５】
0.1.2.2  src/rpc/runtime/comp.c
このファイルは既存のファイルである。下記に示すテーブル・エレメントを付加することが必要である。これらのテーブル・エレメントは、「Ｕｎｉｘドメイン・アドレス・ファミリィ」と、ncacn_unix_streamプロトコル順序とのためのサポートを付加する。
【００５６】
大域アレイrpc_g_protseq_id[]は下記のように拡張された。
0003962112.tif 000006
【００５７】
大域アレイrpc_g_naf_id[]は下記のように拡張されなければならない。
0003962112.tif 000007
【００５８】
0.1.2.3  src/rpc/runtime/unixnaf.c
このファイルは作成を必要とする新しいファイルである。このファイルは、「Ｕｎｉｘドメイン・ネットワーク・アドレス・ファミリィ」のために必要なエントリ・ポイント・ベクトルのルーチンのためのサポートを与える。下記のように定義されたrpc_naf_epv_tと呼ばれるＲＰＣ構造がある。
0003962112.tif 000008
【００５９】
各ＮＡＦは、この構造をロードし、かつ、特定されたＮＡＦのためのrpc_g_naf_id[]テーブルのエントリにそれを付加する初期化ルーチンを持っている。この時点から、「Ｕｎｉｘネットワーク・アドレス・ファミリィ」のすべての呼び出しは、これらのＥＰＶを通して行なわれる。
「Ｕｎｉｘネットワーク・アドレス・ファミリィ」を実施するために、下記のルーチンを作成しなければならない。
【００６０】
0003962112.tif 000009
【００６１】
0003962112.tif 000010
【００６２】
0003962112.tif 000011
【００６３】
0003962112.tif 000012
【００６４】
0003962112.tif 000013
0003962112.tif 000014
【００６５】
0003962112.tif 000015
【００６６】
0003962112.tif 000016
【００６７】
0003962112.tif 000017
【００６８】
0003962112.tif 000018
【００６９】
0003962112.tif 000019
【００７０】
0003962112.tif 000020
【００７１】
0003962112.tif 000021
【００７２】
0003962112.tif 000022
【００７３】
0003962112.tif 000023
【００７４】
0003962112.tif 000024
【００７５】
0003962112.tif 000025
【００７６】
0003962112.tif 000026
【００７７】
0003962112.tif 000027
【００７８】
0003962112.tif 000028
【００７９】
0003962112.tif 000029
【００８０】
0003962112.tif 000030
【００８１】
ＲＰＣがコマンド・コードを実行している時に、ＲＰＣアドレスは、疑似透明構造（rpc_addr_t）として通過されるが、しかし、この構造がＮＡＦ特定ルーチンに通された時、この構造は使用するファミリィ用のＲＰＣアドレス構造に与えられる。ｕｎｉｘストリームの場合、この構造はrpc_unix_addr_tに与えられる。
【００８２】
このファイルに対して必要とする他の付加部分は、ＡＩＸオペレーティング・システムにおける「Ｕｎｉｘドメイン」ソケット呼び出しに使用するためのファイル名を作成するために使用されるデフォルト・パス名である。これは、「オペレーティング・システム」特定のものであり、ＯＳ／２に関しては必要としない。エンドポイントを作成する時に、若しエンドポイントが存在しないか、または使用されるエンドポイントがフル・パス名を特定しなければ、デフォルト・パス名が用いられる。デフォルト・パス名は下記のようにして定義される。
0003962112.tif 000031
【００８３】
ＯＳ／２オペレーティング・システムに関しては、「Ｕｎｉｘドメイン」ソケット・ファイルは内部的のみに使用される。ユーザが目視できるファイルは作成されない。ＯＳ／２オペレーティング・システムは、ソケット・ファイルに関連した管理的なタスク（即ち、整理動作）を取り扱う。特別なパスを生成する必要はない。
【００８４】
0.1.2.5  src/rpc/runtime/RIOS/unixnaf_sys.c
これは、作成しなければならない新しいファイルである。このファイルは、「Ｕｎｉｘドメイン・ネットワーク・アドレス・ファミリィ」に付属するような、ＲＩＯＳプラットフォームに対してシステム特定のルーチンを含んでいる。
【００８５】
0.1.2.5.1  rpc_unix_desc_inq_addr()
ファミリィ、エンドポイント及びネットワーク・アドレスを得るために問い合せられたソケット記述子を受信する。若しこの情報が「Ｕｎｉｘドメイン」アドレスに対して有効ならば、ソケットから得られた情報によって初期化されるＲＰＣアドレス用のスペースが割り当てられる。作成されたＲＰＣアドレスを表示したアドレスはrpc_addr中に戻される。
0003962112.tif 000032
【００８６】
0.1.2.5.2  rpc_unix_get_broadcast()
このルーチンは不動作であるけれども、必要なルーチンであり、NAF_epvの中にエントリがある。
0003962112.tif 000033
【００８７】
0.1.2.6  src/rpc/runtime/twr_unix.h
これは新しいファイルであって、作成しなければならない。このファイルは宣言と、twr_unix.cファイルに特定するプロトタイプとを含んでいる。現在、このファイルだけが、ルーチンrpc_rpcd_is_running()のためのプロトタイプを含んでいる。
【００８８】
0.1.2.7  src/rpc/runtime/twr_unix.c
これは新しいファイルであって、作成しなければならない。このファイルは、タワー表示からソケット・アドレスへの変換を行なうことと、ソケット・アドレスからタワー表示への変換を行なうこととを特定するルーチンを含んでいる。また、このファイルは、ＲＰＣランタイム及びＲＰＣＤの両方によって使用されるユティリティ・ルーチンを含んでいる。
【００８９】
0.1.2.7.1  rpc_rpcd_is_running()
これは新しいルーチンである。このルーチンは、下記の２つの目的のために使用される。２つの目的とは（１）ＲＰＣＤのインスタンスが既に実行されているか否かを決定するための初期化の間で、ＲＰＣＤがこのルーチンを使用する目的と、（２）ローカル・ホスト・コンピュータ中のＲＰＣＤが実行されているか否かと、このプロシージャがncacn_unix_streamプロトコル順序をサポートするか否かとを決定するためにＲＰＣランタイムがこのルーチンを使用する目的とである。
【００９０】
このルーチンは、ucacn_unix_streamをサポートするＲＰＣＤのインスタンスをチェックする。これは、ＲＰＣＤエンドポイント・ファイルの存在を検索することによって行なわれる。若しこのファイルが存在しなければ、ＲＰＣＤは、Ｕｎｉｘストリームのサポートによって実行されない。若しこのファイルが存在すれば、このファイルは、ＲＰＣＤインスタンスへの接続を試みるために使用される。若し接続が不成功に終わったならば、ＲＰＣＤはＵｎｉｘストリームのサポートによって実行されない。このファイルは除去される。若し接続が成功したならば、ＲＰＣＤは実行される。このファイルは除去されない。
0003962112.tif 000034
0003962112.tif 000035
【００９１】
0.1.2.8  src/rpc/runtime/twrp.h
これは既存のファイルである。このファイルは、ＲＰＣタワー参照子構造及びオクテット・ストリングの構造及び検査に関する宣言を含んでいる。このファイルは下記の付加的なラインを含ませるために変更される。
0003962112.tif 000036
【００９２】
注記  :「Ｕｎｉｘドメイン」タワー参照子はタワー・フロアを４個しか使用しないけれども、しかし、第５のフロアが含まれており、これはデータを含んでいない。これは、５個のフロアが「フル・タワー」であると見做されるタワー・オクテット・ストリングを検査するのに用いられるＲＰＣランタイムのアルゴリズムに原因がある。「Ｕｎｉｘドメイン」はフル・タワーであるけれども、タワーに関連するデータを持つフロアは４個だけしかない。
【００９３】
0.1.2.9  src/rpc/runtime/comtwrref.c
これは既存のファイルである。このファイルはプロトコル・タワーのランタイム参照子表示に関して動作するルーチンを含んでいる。
【００９４】
0.1.2.9.1  rpc_tower_ref_inq_protseq_id()
このルーチンは変更される。このルーチンは、そのプロトコル順序のためのタワー参照子を作る上位フロア３及び下位タワー・フロアのためのプロトコル識別子の組み合せに対して使用可能なすべてのプロトコル順序のマッピングを含む静的テーブルを含んでいる。このテーブルは、ncacn_unix_streamプロトコル順序用のエントリの付加を含ませるために変更されなければならない。
0003962112.tif 000037
【００９５】
0.1.2.10  src/rpc/rpcd/rpcd.c
これは既存のファイルである。このファイルは、rpcdサーバが来た時、ncacn_unix_streamを介する要求を聴取するのに使用されるソケット・ファイルが存在するか否かを、rpcdサーバがチェックするように、変更される必要がある。若しソケット・ファイルが存在していれば、そのソケット・ファイルは削除する必要がある。これは、ファイルが既に存在しているならば、ソケット・ファイルは作成できないからである。
【００９６】
0.1.2.10.1  main()
データベースが初期化された後で、プロトコル順序のサポートが設定される前に、下記のコード付加されなければならない。
0003962112.tif 000038
【００９７】
0.1.2.11  src/libdce/RIOS/libdce.syms
これは既存のファイルである。このファイルは、ルーチンrpc_rpcd_is_running()を含ませるために更新する必要がある。これは、libdce.aの外側のルーチンまたはプログラムがこのルーチンにアクセスできるようにするためである。rpcdがこのルーチンを呼び出すので、このルーチンが必要である。下記のラインをlibdce.-symsに付加するだけでよい。
rpc_rpcd_is_running
【００９８】
0.1.2.12  Auto Handles
[auto_handle]の属性の使用は、アプリケーション・コードがバインディング・ハンドルを獲得し及び／又はそのバインディング・ハンドルのエンドポイントを分析するための責任を持たないことを表示する。[auto_handle]の属性は、ＲＰＣランタイムがこれのすべてを操作することを特定する。ユーザが特定するすべてのものは、ＲＰＣランタイムがバインディング・ハンドルの検索を開始するネーム・スペースのエントリ位置を特定するだけである。（これは、環境変数RPC_DEFAULT_ENTRYを介して行なわれる。）クライアント及びサーバが同じホスト・コンピュータに存在する場合に、ＲＰＣランタイムは、ncacn_unix_streamを使用するインテリジェンスを持つ。
【００９９】
0.1.2.13  Utilities
この機能の実施は管理的な責任を遂行するための幾つかのユティリティの作成を必要とする。これらのユティリィティは下記に説明されている。
【０１００】
0.1.2.13.1  src/rpc/utils/rpcclean
このユティリティは、ＲＰＣランタイムのルーチンrpc_network_inq_protseqs()を単に呼び出し、そして、呼び出されたプロトコル順序のストリング・ベクトルを、１行に１プロトコル順序づつ印刷する。このユティリティは、与えられたホスト・コンピュータに使用可能なプロトコル順序を決定するためのmkdceに対して使用される。１実施例において、サポートされたプロトコル順序はmkdce記述子に配線される。また、この記述子は、与えられたホスト・コンピュータにおいてサポートされたプロトコル順序を決定するための管理用の迅速な方法に使用することができる。このユティリティのためのコードは以下の通りである。
0003962112.tif 000039
【０１０１】
0.1.2.13.2  src/rpc/utils/rpcprotseqs
このユティリティはＲＰＣランタイムのルーチンrpc_network_inq_protseqs()を単純に呼び出し、そして、呼び出されたプロトコル順序のストリング・ベクトルを、１行に１プロトコル順序づつ印刷する。このユティリティは、与えられたホスト・コンピュータに使用可能なプロトコル順序を決定するためのmkdceに対して使用される。１実施例において、サポートされたプロトコル順序はmkdce記述子に配線される。また、この記述子は、与えられたホスト・コンピュータにおいてサポートされたプロトコル順序を決定するための管理用の迅速な方法に使用することができる。このユティリティのためのコードは以下の通りである。
0003962112.tif 000040
【０１０２】
0.1.3  互換性
この機能は互換性の問題を全く生じない。
【０１０３】
0.1.3.1  逆方向の互換性
既存のアプリケーションはこの機能を含ませるためにＤＣＥをアップグレードすることができ、修正を施すことなく実行することができる。また、クライアント／サーバ・アプリケーションが異なったホスト・コンピュータにあり、一方のアプリケーションがこの機能を使用し、他方のアプリケーションがこの機能を使用しない場合でも、修正することなく実行することができる。複数のコンピュータに跨がって「Ｕｎｉｘドメイン」を使用することはできないので、上述のことは、互換性の問題ではなく、共存の問題である。
【０１０４】
0.1.3.2  Cross-Platformの互換性
この機能は、ＡＩＸ及びＯＳ／２を使用して実行される。ＡＩＸ及びＯＳ／２プラットフォームの間を通信するクライアント／サーバ・アプリケーションは、この機能の利益を享受することができないけれども、既存のアプリケーションは、この機能を含ませるためにＤＣＥをアップグレードすることができ、そして修正することなく実行することができる。
【０１０５】
逆方向の互換性は、この機能の導入前に可能であった範囲内で、プラットフォームに跨がってのみ拡大する。この機能の範囲を越えたソースからの他の非互換性の導入があるにも拘らず、勿論、互換性のすべてのクレームがある。
【０１０６】
0.1.4  ＤＣＥの導入及び構成の影響
ＤＣＥがコンピュータに導入される時、ディレクトリ/var/dce/rpc/socketが作成されなければならない。若しこのディレクトリが既に存在しているならば、そのディレクトリは消去され、再作成されねばならない。これは、ＤＣＥ導入のアップグレードが起きた時、すべてのＤＣＥアプリケーションが停止されるものと仮定され、「Ｕｎｉｘドメイン」ソケット・ファイルが作成される場合、このディレクトリ中に残されたすべてのファイルは古いファイルとなるからである。
【０１０７】
0.1.5  ＲＡＳ（信頼性、可用性、保守性）に対する影響
この機能によってＲＡＳに及ぼす影響はない。
【０１０８】
0.1.6  ＮＬＳ（各国語サポート）に対する影響
この機能によってＮＬＳに及ぼす影響はない。
【０１０９】
0.1.7  性能及び記憶域の見積り
ＲＰＣの性能は、クライアント及びサーバが同じホスト・コンピュータ中に存在する場合、１０％乃至２０％までの性能向上がある。クライアント及びサーバが異なったホスト・コンピュータ中にある場合でも、性能は影響されない。
【０１１０】
記憶域の見積りは問題にはならない。サーバが登録する各「Ｕｎｉｘドメイン」のエンドポイントに対してソケット・ファイルが作成されるけれども、このファイルは長さが０である。
【０１１１】
システム中に取り残されている古いソケット・ファイルを除去するために、rpccleanユティリティ（この明細書において既に説明されている）を実行することができる。これは、ファイルシステム中に用いられているｉノードの数を減小する。
【０１１２】
0.1.8  テストの計画
テストの計画はこの明細書には記載しない。この機能が正しく動作することを保証するのに必要とする付加的なテストケースまたはテスト構成を示した現用のＲＰＣ  ＦＶＴテスト計画の付属書を参照されたい。
【０１１３】
本発明の良好な実施例は、パーソナル・コンピュータ、またはワークステーションのランダム・アクセス・メモリ中に常駐するコード・モジュール中のインストラクションの組として実行される。コンピュータ・システムによって要求されるまで、インストラクションの組は、例えばハード・ディスク・ドライブ、またはオプティカル・ディスク（ＣＤ−ＲＯＭ中に使用されている）や、フロッピィ・ディスク（フロッピィ・デイスク・ドライブ中で使用されている）などの取り外し可能なメモリなどの他のコンピュータ・メモリ中にストアすることができる。
【０１１４】
以上、本発明は特定のオペレーティング・システム及びネットワーク環境における良好な実施例について説明してきたが、本発明の技術思想の範囲内で、本発明の実施例を他のオペレーティング・システム及びネットワーク・アーキテクチャによって変更し、または置換することは当業者であれば容易に行なうことができるのは自明であろう。従って、例えば、ＤＣＥ−ＲＰＣアーキテクチャの術語において、クライアント・プロセスはサーバ・プロセスに「バインディング・ハンドル」を渡す。然しながら、本発明はＤＣＥ−ＲＰＣアーキテクチャに限定して解釈されるべきではなく、従って、本発明は、例えば、サーバ・プロセスの位置を特定し、そしてクライアント及びサーバ・プロセスの間で使用される通信プロトコルを設定するデータ構造を、サーバ・プロセスに通過することなどにより、クライアント・プロセスがローカル通信を獲得し、かつ設定する任意のネットワーク環境をカバーするようなより包括的な観点から解釈されるべきである。
【０１１５】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１１６】
(１)  分散計算環境内におけるクライアント・プロセスとサーバ・プロセスの間の通信を管理する方法であって、上記クライアント・プロセスは、トランスポート層及びネットワーク層を有する物理ネットワークに接続されたホスト・コンピュータ中に存在し、
上記方法は、
（ａ）  クライアント・プロセスによって行なわれた遠隔プロシージャ呼び出し（ＲＰＣ）に応答して、該ＲＰＣによって識別されたサーバ・プロセスが上記ホスト・コンピュータ中に存在するか否かを決定するステップであって、上記ＲＰＣは、トランスポート層及びネットワーク層の使用を介した通信路を定義するプロトコル順序を持つところの前記ステップと、
（ｂ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記ＲＰＣのプロトコル順序には関係なく、上記クライアント・プロセスと上記サーバ・プロセスとの間にインタープロセス通信路を設定するステップと、
（ｃ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記クライアント・プロセスがＲＰＣを生成するときにそれが予期するプロトコル順序を得るように、上記ＲＰＣのプロトコル順序を上記クライアント・プロセスに戻すステップと、及び
（ｄ）  上記ＲＰＣのプロトコル順序を使用する代わりに、上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含む通信管理方法。
(２)  上記プロトコル順序はＲＰＣに影響を与えないで使用される、(１)に記載の通信管理方法。
(３)  上記プロトコル順序は接続指向プロトコル順序である、(１)に記載の通信管理方法。
(４)  上記プロトコル順序は非接続プロトコル順序である、(１)に記載の通信の管理方法。
(５)  上記遠隔プロシージャ呼び出しは、上記ホスト・コンピュータのオペレーティング・システムのメッセージ送受信機能を用いて実行される、(１)に記載の通信管理方法。
(６)  分散計算環境内におけるクライアント・プロセスとサーバ・プロセスの間の通信を管理する方法であって、上記クライアント・プロセスは、トランスポート層及びネットワーク層を有する物理ネットワークに接続されたホスト・コンピュータ中に存在し、
上記方法は、
（ａ）  遠隔プロシージャ呼び出し（ＲＰＣ）が上記クライアント・プロセスによって行なわれた時、上記遠隔プロシージャ呼び出しによって識別されたサーバ・プロセスが上記ホスト・コンピュータ中に存在しているか否かを決定するステップと、
（ｂ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、トランスポート層及びネットワーク層の使用を介した通信路を定義するプロトコル順序を含む第１データ構造を上記クライアント・プロセスに戻すステップと、
（ｃ）  上記第１データ構造を、上記クライアント・プロセス及び上記サーバ・プロセス間のインタープロセス通信路を定義するプロトコル順序を含む第２データ構造にマップするステップと、
（ｄ）  上記第１データ構造中の前記プロトコル順序を使用する代わりに、上記第２データ構造中のプロトコル順序によって定義された上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含む通信管理方法。
(７)  上記遠隔プロシージャ呼び出しは、上記ホスト・コンピュータのオペレーティング・システムのメッセージ送受信機能を用いて実行される、(６)に記載の通信管理方法。
(８)  上記第１データ構造のプロトコル順序は上記ＲＰＣに影響を与えることなく使用される、(６)に記載の通信管理方法。
(９)  上記第１データ構造のプロトコル順序は接続指向プロトコル順序である、(６)に記載の通信管理方法。
(１０)  上記第２データ構造のプロトコル順序はソケット・ファイルに対するフル・パス名を含んでいる、(９)に記載の通信管理方法。
(１１)  命名規則及びエンドポイントが上記パス名を決定するのに用いられる、(１０)に記載の通信管理方法。
(１２)  ホスト・コンピュータがＵＮＩＸベースのオペレーティング・システムをサポートし、クライアント・プロセスがトランスポート層及びネットワーク層を有する物理ネットワークに接続された上記ホスト・コンピュータ中に常駐している分散計算環境内において、上記クライアント・プロセスが遠隔プロシージャ呼び出しを行なった時に、上記クライアント・プロセス及びサーバ・プロセス間の通信を管理する方法であって、
（ａ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を持つバンインディング・ハンドルを上記クライアント・プロセスに戻すステップと、
（ｂ）  上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を、上記クライアント・プロセス及び上記サーバ・プロセス間のインタープロセス通信路を設定する代替プロトコル順序にマップするステップと、及び
（ｃ）  上記ＵＮＩＸベースのオペレーティング・システムのメッセージ送受信機能を用いて、上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含み、
上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序は接続指向プロトコル「ncacn_ip_tcp」であり、且つ上記代替プロトコル順序は「ncacn_unix_stream」であり、「ncacn」は接続指向ＲＰＣプロトコルであり、「unix」は「ＵＮＩＸネットワーク・アドレス・ファミリィ（ＡＦ＿ＵＮＩＸ）通信ドメイン」を識別し、及び「stream」はＵＮＩＸドメイン・ソケットを識別するところの通信管理方法。
(１３)  ホスト・コンピュータがＵＮＩＸベースのオペレーティング・システムをサポートし、クライアント・プロセスがトランスポート層及びネットワーク層を有する物理ネットワークに接続された上記ホスト・コンピュータ中に常駐している分散計算環境内において、上記クライアント・プロセスが遠隔プロシージャ呼び出しを行なった時に、上記クライアント・プロセス及びサーバ・プロセス間の通信を管理する方法であって、
（ａ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を持つバンインディング・ハンドルを上記クライアント・プロセスに戻すステップと、
（ｂ）  上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序を、上記クライアント・プロセス及び上記サーバ・プロセス間のインタープロセス通信路を設定する代替プロトコル順序にマップするステップと、及び
（ｃ）  上記ＵＮＩＸベースのオペレーティング・システムのメッセージ送受信機能を用いて、上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含み、
上記遠隔プロシージャ呼び出しに通常関連しているプロトコル順序は非接続指向プロトコル「ncadg_ip_udp」であり、且つ上記代替プロトコル順序は「ncadg_unix_dgram」であり、「ncadg」は非接続ＲＰＣプロトコルであり、「unix」は「ＵＮＩＸネットワーク・アドレス・ファミリィ（ＡＦ＿ＵＮＩＸ）通信ドメイン」を識別し、「dgram」はＵＮＩＸドメイン・ソケットを識別するところの通信管理方法。
(１４)  ユーザが分散されたリソース及びプロセス・アプリケーションにアクセスすることのできる分散計算環境を与え、且つトランスポート層及びネットワーク層を有するローカル・エリア・ネットワークに接続されたホスト・コンピュータを含むコンピュータ・システムであって、
前記ホスト・コンピュータ中に存在するクライアント・プロセスからの遠隔プロシージャ呼び出し（ＲＰＣ）に応答して、該ＲＰＣによって識別されたサーバ・プロセスが上記ホスト・コンピュータ中にあるか否かを検出する検出手段と、及び
該検出手段に応答して、予期されたプロトコル順序を上記クライアント・プロセスに戻し、且つ前記予期されたプロトコル順序の代わりに代替プロトコル順序を用いて、上記ＲＰＣを助長する手段であって、前記代替プロトコルは前記トランスポート層及びネットワーク層を経由しない通信路を設定するところの前記手段と
を含み、
上記予期されたプロトコル順序は、接続指向プロトコル「ncacn_ip_tcp」或いは非接続指向プロトコル「ncadg_ip_udp」であり、且つ上記代替プロトコル順序はそれぞれ「ncacn_unix_stream」或いは「ncadg_unix_dgram」であり、
上記代替プロトコル順序の使用は上記クライアント・プロセスに透過的であるコンピュータ・システム。
(１５)  ホスト・コンピュータによって読み取り可能であり、かつ、上記ホスト・コンピュータで実行されるクライアント・プロセスからの通信を管理する方法を実施するための、該ホスト・コンピュータによって実行可能な命令からなるプログラムを記録したコンピュータ読み取り可能な記録媒体であって、上記ホスト・コンピュータはトランスポート層及びネットワーク層を有するローカル・エリア・ネットワークに接続されており、
（ａ）  遠隔プロシージャ呼び出しが上記クライアント・プロセスによって行なわれた時、上記遠隔プロシージャ呼び出しによって識別されたサーバ・プロセスが上記ホスト・コンピュータ中にあるか否かを検出するステップと、
（ｂ）  もし上記サーバ・プロセスが上記ホスト・コンピュータ中に存在するならば、上記トランスポート層及びネットワーク層の使用を介した通信路を定義するプロトコル順序を含む第１データ構造を上記クライアント・プロセスに戻すステップと、
（ｃ）  上記第１データ構造を、上記クライアント・プロセス及び上記サーバ・プロセス間のインタープロセス通信路を定義するプロトコル順序を含む第２データ構造にマップするステップと、及び
（ｄ）  上記第１データ構造中の前記プロトコル順序を使用する代わりに、上記第２データ構造のプロトコル順序によって定義された上記インタープロセス通信路を介して上記遠隔プロシージャ呼び出しを実行するステップであって、前記インタープロセス通信路は前記トランスポート層及びネットワーク層を経由しないところの前記ステップと、
を含むプログラムを記録したコンピュータ読み取り可能な記録媒体。
【図面の簡単な説明】
【図１】本発明が適用されるコンピュータ・ネットワークを説明するための図である。
【図２】物理的ネットワークのネットワーク層及びトランスポート層を使用した従来のＲＰＣを説明するための図である。
【図３】ローカルＲＰＣがホスト・コンピュータのＩＰＣ構造を用いて遂行された本発明の実施例を説明するための図である。
【図４】ローカル遠隔プロシージャ呼び出しを与えるためのプロシージャを最適化するための本発明の実施例を説明するための図である。
【符号の説明】
１０  クライアント
１２  サーバ
１４  ネットワーク
１５  クライアント／サーバ
【図１】
0003962112.tif 000041
【図２】
0003962112.tif 000042
【図３】
0003962112.tif 000043
【図４】
0003962112.tif 000044