JPS60239144A - 名前決定方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は複数のノードを有するデータ通信ネットワーク
におけるメツセージ交換の技術に関する。

〔従来技術〕

現行の分散型データ処理ネットワークは、これまで、別
名の使用をサポートするに際し集中化されたアプローチ
を採用してきた。このアプローチでは、メツセージを、
命名されたエンティティに向けられたものからネットワ
ークアドレス場所（個々のエンティティが物理的に所在
するところ）に向けられたものへと変換しなければなら
ない。

したがってネットワークで取り扱われる必要な通信トラ
フィックのボリュームが増えるだけでな（、そうした変
換に依存して通信中にエラーが発生する確率も増す。そ
の上、成るノードの゛′マスター″コンピュータシステ
ムによって名前指定型のメツセージから場所指定型のメ
ツセージへの変換が行われる場合は、マスターコンピュ
ータシステムの障害によってネットワークが働かなくな
ることもある。

安全保護のような明らかな目的から、単一の検査機構に
よるシステムへのアクセスの一意性を検証することを必
要とした分散型データ処理システムが構成されてきた。

単一の検査機構は、通常、複数の処理ノードで共有され
た通信媒体またはチャネル上の１つのアクセスノードの
ところに所在する。

そうしたシステムへのアクセスは、通常、６０ゲイン（
Ｌｏｇｉｎ　）　”コマンドおよびパスワードを介して
中央機構によって制御される。そのようなシステムは、
パスワードの名前で許可されたオペレータの宛先、およ
び物理的な場所を表わすアドレスまたは物理的な場所に
は直接関係がない論理名前による資源の宛先を認可する
よう構成されている。これに伴い、アクセスを制御する
ための中央機構は、名前のディレクトリとそれらの各々
の名前で使用可能な資源とを保持し、ネットワーク通信
およびディレクトリの参照によりそうした資源へのアク
セスを制御するよう構成されている。

こうしたタイプの制御センタは管理するのが面倒であり
、またシステムの性能や可用性に悪影響を及ぼすような
固有の制限を持っている。制御センタは名前と物理的エ
ンティティとの間の連関およびアドレス場所を追跡する
ために監視ソフトウェアまたはそれと等価なものを必要
とし、１つのセンタが故障するだけでネットワーク全体
が働かなくなる。障害時に中央制御機構を自動的に再配
置できるシステムでさえも、再配置の間はシステムの機
能は停止している。しかもこうした制御センタは、一般
に、中央制御機構のために専用の処理機構を必要とする
ので、効率が悪い。

〔発明が解決しようとする問題点３ 以上説明したように名前の使用に関する従来の集中的な
管理手法は、ネットワークの通信量が必要以上に多いと
いうだけでな（、マスターシステムに障害が発生したと
きはネットワーク全体の機能が停止してしまうという問
題がある。

したがって本発明の目的は以−上の問題を解決する分散
的な管理手法を採るのに都合の良いメツセージ交換方法
を提供するにある。

〔問題を解決するための手段〕

本発明に基づ（メツセージ交換方法は、通信媒体または
チャネルでり／りされた複数のノードを有するデータ通
信ネットワークにおいて、メツセージの発信源である起
点ノードの物理的な場所を表わす起点アドレスを含み、
送信先のノードからの応答を要求するメツセージを通信
媒体またはチャネルを介して同報通信するステップと、
このメツセージを受信したノードが、該メツセージ中の
情報により定義される所定の条件を有するかどうかを判
断するステップと、 この判断に応じて所定の条件を有するノードから起点ノ
ードに応答、メツセージを送信するステップと、 を有することを特徴とする。

ｆＡｉ　はじめに 本実施例によれば、通信ネットワークの複数のノードに
リンクされた複数のデータ処理システムは分散的なアプ
ローチに基づいて別名を生成し使用し、様々な名前で識
別される資源間および分散型ネットワーク全体でデータ
通信をサポートすることができる（中央ディレクトリま
たはマスターディレクトリを必要としない）。

本実施例に従って全てのネットワークのノードのところ
の処理システムは関連するエンティティ（オペレータ、
記憶資源、内部プロセッサ等）にそれぞれ割り当てられ
た名前のテーブルを保持する。このテーブルは名前の一
意性を確認しその名前（アドレスではない）で識別され
るエンティティ間のセツションを確立する際の参照とな
るものである。

ノードのところの処理システムは以下に示す一意的な名
前連関を生成する。処理システムは初めにローカル名前
テーブルを調べてローカルに（すなわちそのノード内で
）名前が既に割り当てられていれば別の名前を選択する
。名前がローカルに重複しているときは処理システムは
他の全てのノードにおいても重複の検査を行わせるため
にネットワーク全体にわたって“名前検査°“メツセー
ジを回報通信する。名前の一意性の検査をこのように２
ステツプで行うこと尾より、（ａ）名前がローカルに重
複しないときは名前検査メツセージがネットワークの負
荷にならない、（ｂ）ローカルの名前検査はローカルの
アプリケーション機能およびオペレーティングシステム
機能に対してトランスペアレントであるので名前生成オ
ペレーションがこれらの機能の負荷にならない、という
利点が生ずる。

名前検査メツセージを受信するノードは、そのノードの
名前テーブルで重複したエントリを検出した場合にのみ
、要求を行ったノード（起点ノード）に肯定応答を返す
。この肯定応答で、起点ノードに既存の名前が使用され
ていることを知らせて、以後の競合（名前使用の競合）
を防ぐ。

名前検査メツセージを発する起点ノードは名前検査メツ
セージの送信を所定の回数だけ繰り返して、それが全て
試行されても肯定応答が戻ってとないときはその名前を
自身のテーブルに加える。

所定の回数の範囲内で２以上の肯定応答が戻ってきた場
合（すなわち他の２以上のノードが各自のテーブルに、
指定された名前を有する場合）は起点ノードは゛重複使
用”′メツセージを回報通信する。この重複使用メツセ
ージは指定された名前に関して他のノードどうしが競合
する可能性があるということを効果的に示すものである
。名前検査メツセージに肯定応答したノードはこれを認
識して各自の名前テーブルのエン）　＋７に競合の可能
性が高いものとしてこれをマークし、競合が解決される
まではこの名前がこれ以上使用されないようにする。

各々の名前の一意性が検証可能でそれが維持できる限り
は、名前検査メツセージおよび重複使用メツセージの使
用は１ノードが２以上の名前ヲ有することを防げない。

起呼エンティティ（送信側）および被呼エンティティ（
受信側）のペアの間でセツショ／ヲ確立する（すなわち
論理的な接続）ために本発明を用℃・れば、複数のノー
ド間で名前の識別により資源を共有できるのでそうした
資源を直接にサポートする処理システムの負荷を最小限
に抑えることができる。

上記の名前検査プロセスと同様に、セツション確立プロ
セスは、リンクすべきエンティティが同じノードのとこ
ろに存在する場合、そのプロセスの通信がネットワーク
媒体の負荷とならないよう構成される。セツション確立
プロセスを開始するノードはローカル名前テーブルを調
べて被呼エンティティがローカルでない場合にのみネッ
トワークを介するプロセスに拡張される。両エンティテ
ィともローカルな場合は、セツションは内部的に確立さ
れる。すなわちネットワーク上での通信は行われない。

名前生成プロセスおよびセツション確立プロセスは主プ
ロセツサで実現されるか、またはネットワークアクセス
を制御する副プロセツサで実現される。基本的なプロセ
スを変更しない限りは価格対性能比のトレードオフによ
り、その実現方法は色々考えられる。

好適な実施例ではセツション確立は一意的な名前を有す
る被呼エンティティ、および後で説明する準備された状
態（以下リスニング状態という）にある被呼エンティテ
ィで条件付けられる。被呼エンティティがローカルでな
いときは、起呼エンティティをサポートするノードはネ
ットワークを介して名前検査メツセージを回報通信する
ことによって被呼エンティティの名前の一意性を検証す
る。被呼エンティティの名前が存在しないかまたは一意
的でないときは（すなわち名前検査メツセージに対して
肯定応答が戻ってとないかまたは２以上の肯定応答が戻
ってきたときは）、セツション確立プロセスは打ち切ら
れる。名前が一意的であるか、または両エンティティと
もローカルであるときは、セツション確立プロセスは続
行すれる。

本実施例では１エンテイテイはそれをサポートする処理
システムでリスニングコマンドを実行することによって
リスニング状態に置かれる（すなわちセソ７ヨン確立の
ための準備が行われる）。

リスニングコマンドはりスニング状態に置＜ヘキローカ
ルエンテイテイの名前を識別し、名前で起呼エンティテ
ィ（ローカルでも遠隔でもよい）を限定的に識別するこ
とができる。リスニングエンティティはセツション確立
のためにこの識別された起呼エンティティを受け入れる
。ノードのところで保持されるセツションテーブルはそ
のエンティティがりスニング状態にあるということを示
すようにマークされ、これにより、そのエンティティを
サポートするプロセッサは適切に発せられたセツション
確立要求に対して肯定応答するよう条件付けられる。以
上に示したりスニング状態を発生させる手順はネットワ
ーク通信の負荷および資源の競合を調整するために各ノ
ードで使用することができる。

セツションの起点ノードが、被呼エンティティはローカ
ルでないとわかって、エンティティの名前が一意的であ
ること（１つだけ肯定応答が戻される場合）を名前検査
メツセージで検証すれば、起点ノードは、ネットワーク
を介して、名前検査メツセージに肯定応答したノードを
直接にアドレス指定する呼出し要求メツセージを送るこ
とによりセツション確立プロセスヲ続行する。セツショ
ンが供給できれば、アドレス指定されたそのノードは被
呼エンティティのためにパセッション確立プロセス″状
況を示すように自身のセツションテーブルをマークし、
その状況を表わす゛°リスニング肯定応答′°で呼出し
要求メツセージに肯定応答する。被呼エンティティがセ
ツション確立には使用不可能であるときは、そのノード
は゛非すスニング肯定応答″で呼出し要求に応答する。

こうした要求と応答のプロセスは数回繰り返される。各
回で返事が全くないかまたは１つの否定的な応答がある
場合は、起呼ノードはセツション確立プロセスを打ち切
る。被呼エンティティがリスニング状態にあるときは、
関連するりスニング肯定応答が起呼ノードにセツション
確立プロセスを完了するよう要請する。このため、起呼
ノードは被呼ノードに呼出し確認メツセージを送って、
これが正しく受信されれば、受信ノードはりスニング確
認メソセージで応答してセツション確立プロセスを終結
する。セツション確立プロセスは絶対必要というわけで
はないが、以上に示した確認はこのプロセスの信頼性を
高める上で有益なものである。

呼出し要求メツセージおよびリスニング確認メツセージ
により、起呼ノードおよび被呼ノードはそれらのエンテ
ィティに関連すべきセツション番号を交換する。起呼ノ
ードおよび被呼ノードは後のセツション通信を指示する
際に用いられる各自のセツションテーブルにそれらの番
号を登録する。

リスニング確認の後は、エンティティのペアの間のメツ
セージはいずれの方向でも各々あノードに特定にアドレ
ス指定されセツション番号で識別される（したがってエ
ンティティの１ペアは現に進行中の複数のセツションを
有することができ、しかもこれらのセツションは全て独
立に区別可能である）。セツションが確立した後は、デ
ータ転送が全く行われないときには活動セツションの検
証を要求するメツセージを周期的に交換することでセツ
ションの信頼性を高めることができる。

次に図面を参照して本実施例の概要を説明する。

第１図に示すような最も簡単な形で、物理的に分離した
データ処理資源およびその他のエンティティを含む処理
システム１ないし６がバス（ネットワーク媒体またはチ
ャネル）４を介して分散型データ処理ネットワークにリ
ンクされても・る。各処理システムは各自のアクセスノ
ード（単にノードともいう）１ａないし３ａでバス４と
インターフェースする。参照番号１で代表するように、
アクセスノード１ａのところの処理システムは主プロセ
ツサ１ｂ、通信Ｉ１０コントローラとして働く副プロセ
ツサ１Ｃ１および媒体との直接のインターフェースを行
う送受部１ｄの階層構造を有していてもよい。主プロセ
ツサ１ｂおよび副プロセツサ１Ｃは、バス４の他に、周
辺装置（図示せず）と接続することもできる。これによ
り周辺装置とバス４との間で通信ができる。バス４は連
続的なライン（たとえばキャリア検知多重アクセスロー
カルエリアネットワークを構成するもの）、リングタイ
プもしくはスタータイブのネットワークを構成する複数
のラインセグメント、またはマイクロ波中継器間もしく
はマイクロ波中継器と地球衛星との間の自由空間の無線
リンクであってもよい。

ノードで使用可能な処理資源に依存して、そのノードで
必要な名前および資源管理のための処理機能は主プロセ
ツサと副プロセツサとの間で配分することができる。副
プロセツサが特定のＩ１０コントローラである場合は、
これらの処理機能は全て主プロセツサに集中する。副プ
ロセツサが十分な能力を持った汎ＦｆＪ−’＝ンピュー
タである場合は、それがこれらの処理機能の多くを取扱
うようにプログラムされる。後者のシステムの方は前者
のシステムより高価になるかもしれないが、主プロセツ
サは幾つかの処理機能から解放されるのでそれから生ず
る実現可能な性能上の利点によって高価であるという欠
点は相殺される。

アクセスノード１ａ、２ａ、および３ａのところの処理
システム１．２、および６は第２Ａ図ないし第２Ｃ図に
例示する形式を有する個別のパケットまたはフレームで
制御情報およびデータを交換する。第２Ａ図に示す制御
フレームは固定長のヘッダＨおよびそれに続くＣＲＣ／
Ｈフィールド（先行する情報の内容を検査するためのも
の）を含む。第２Ｂ図に示すデータフレームは固定長の
へラダＨおよびそれに続く可変長のデータフィールドＤ
を含む。データフィールドＤはＣＲＣ／Ｄフィールドで
終わる。さらに第２Ｂ図に示すように、ヘッダＨが中間
的なＣＲＣ／Ｈフィールドで終わるようにしてもよい。

中間的なＣＲＣ／Ｈフィールドを設ける場合は、ＣＲＣ
／ＨフィールドおよびＣＲＣ／ＤフィールドはへラダＨ
およびデータフィールドＤの検証用に使用される。中間
的なＣＲＣ／’Ｈフィールドを設けない場合は、最後の
ＣＲＣ／Ｄフィールドを用いて先行する全ての情報を検
証する。制御動作を要求するため、およびフレームの受
取りを肯定応答するために制御フレームを使用する。デ
ータフレームはデータ転送用に使用される。

一般的にヘッダＨは第２Ｃ図に示すように同期用のフラ
グＦ、起点ノードのアドレスを表わす起点フィールドＯ
１宛先ノードのアドレスを表わす宛先フィールドＤ、そ
のフレームのタイプを表わすタイプフィールドＴ、その
フレームの順番を表わす７−ケンスフィールドＳ、およ
びそのフレームの長さを表わす長さフィールドＬを含む
。

第２Ａ図ないし第２Ｃ図で（）内に示した数字はそのフ
ィールドのバイト数を表わしている。

バス４へのアクセス権を獲得すれば、°゛送信可能゛′
なノードがバス４を介して制御フレームまたＩｔｔｆ−
タフレームを送出する（アクセス権獲得の方法は本発明
とは関係がなく、また本発明はどのような媒体をどのよ
うなアクセスプロトコルでも良好に機能する）。このフ
レームのヘッダＨにある宛先フィールドＤおよびタイプ
フィールドＴは１つの特定のノードでの受信を指示する
こともあれば、全てのノードでの受信を指示することも
ある。

全テのノードへ向けられたフレームのことを１回報通信
′”フレームと呼ぶ。１つの特定のノードに向けられた
フレームをそのノードが受信すればそのノードはそうし
た受信を肯定応答する。すなわち、そのノードは制御フ
レームを返す。この制御フレームには受信したフレーム
に対する関連したシーケンス番号と、受信の状況（エラ
ー／エラーなし）を示す情報が含まれている。本実施例
に関連する一定のフレームを除いて、回報通信フレーム
は一般には肯定応答されない。特定の宛先に送信された
フレームが所定の時間内に肯定応答されないときは、起
点ノードはその送信（または少なくともそれに含まれる
宛先情報）が認識不能であったと推定し、送信を繰り返
す（所定の再試行回数まで）。

これまでに説明してきた環境は最も簡単なものである。

後に説明するように、本実施例はさらに複雑なネットワ
ーク環境（異なるチャネルまたは媒体に関連するサブネ
ットワークがチャネルまたは媒体をす／゛りするプリッ
ジア夛ブタまたはゲートウェイアダプタを介して主ネッ
トワークにリンりされるような環境）にも適用すること
ができる。

これまでに説明した環境で、アクセスノードのところの
処理システムは名前管理機能、セツション管理機能、お
よび資源管理機能を提供する。以下、これについて説明
する。

ＦＢ）　名前生成プロセス 本実施例に従ってアクセスノードのところの処理システ
ムは表−１０（後出）に示す形式でそのメモリに名前テ
ーブルを保持する。各々の名前テーブルは、各自のノー
ドを介してネットワークとインターフェースするエンテ
ィティに現に割り当てられている名前だけを有する。

これらの名前テーブルのエントリは名前検査メツセージ
、セツション確立メツセージ、オヨヒネットワークを介
して受信された他のメツセージに対して応答する際、各
自のノードで使用される。

命名されたエンティティがネットワーク内に存在するか
、送信ノードで選択されたエンティティ塩がネットワー
クの全体または一部で一意的なものであるか、を検証す
るために名前検査メツセージが使用される。名前で識別
された起呼エンティティと被呼エンティティとの間のセ
ツション（スナわち論理的な接続）を確立するためにセ
ツション確立メツセージが使用される。これらのメツセ
ージについては後でさらに詳しく説明する。これらのメ
ツセージを用いればノード計算機システムは名前により
（すなわち、そうした通信を中央ディレクトリを介して
変換する必要なしに、またはエンティティのペアをリン
クするのに要する経路もしくはネットワークの物理的な
構造に関する詳細な情報を各システムが有する必要なし
に）ネットワークを越えて資源の共有ができるようにな
るリセッション確立で使用されるエンティティに割り当
てられた名前はネットワークを越えても一意的である。

各ノードの処理システムは第４図に示すメモリマツプで
示唆されたソフトウェア階層に従った処理のために構成
される。アプリケーションソフトウェアまたはユーティ
リティソフトウエア６１は監視ソフトウェアまたはオペ
レーティングシステムソフトウェア６３の指示の下でテ
ーク３２を処理するために主プロセツサを制御する。さ
らに監視ソフトウェア３３は、副プロセツサおよび他の
Ｉ１０装置の両方に接続された主プロセツサのＩ１０チ
ャネルを介して、Ｉ１０オペレーションをスケジュール
する。インターフェースソフトウェア６４は主プロセツ
サと副プロセツサとの間の情報交換をサポートする。ネ
ットワーク制御プロゲラ＊（Ｎ、ＣＰ１３５は副で°″
″すと／＜　２４との間の通信を指示する。参照番号３
６のところにブロック形式で示しであるのが前述の名前
テーブルである。セツションテーブル６７は確立される
セツション接続のパラメータを保持する。送信バッファ
３８はネットワーク媒体へ送出される情報フレームを保
持する。受信バッフ７６９は各自のノードへ送られてく
るフレームを一時的に記憶する（これらのバッファは各
々複数存在してもよい）。

１つのエンティティに対する名前連、関を生成するため
、そのエンティティを受け持つノードの主プロセツサは
第５図に示す形式を有するネツトワ−り制御ブロック（
ＮＣＲ）情報のアレイ（１つのコマンドを表わす）を構
成して、別の処理エンティティによる問合せをスケジュ
ールする。別の処理エンティティは主プロセツサまたは
副プロセツサで走行する別のソフトウェアモジュールで
あってもよい。これは副プロセツサの能力に依存する（
副プロセツサおよび主プロセツサが共通のメモリ機構へ
のアクセスを有する場合は、ＮＣＲ転送は制御信号の単
一の交換で達成できる）。このＮＣＲは名前生成または
セツション確立のために使用される。　。

ＮＣＲプレイの各フィールドは第５図で定義される。コ
マンドＣＭＤフィールドは遂行すべきオペレーションｔ
ｊｉ［ｊる（ＮＣＲは多数のオペレーションに使用でき
る）。遂行すべき機能が名前生成の場合は、そのＣＭＩ
）のオペレーションコードは６０■である（名前付加コ
マンド）。遂行すべき機能がセツション確立の場合は、
そのＣＭＤのオペレーションコードは１０Ｈまたは１１
Ｈである（第７図および第８図参照）。すなわちＮＣＢ
コマンドは名前生成およびセツション確立に関連したオ
ペレーションの１つを導くものである）。

ＮＣＢが取り出される前に走行していたプログラムに戻
るための′戻りコード′を保持するためにＲＣフィール
ドが用いられる。ＮＵＭ（番号）フィールドおよびＬＳ
Ｎ（ローカルセツション番号）フィールドは名前生成機
能およびセツション確立機能に関する情報を記憶するた
めにそれぞれ設けられる。ＮＣＲが名前生成に使用され
るときは、ＮＵ’Ｍフィールドはその名前を表わす番号
を短縮形式で記憶する。ＮＣＲがセツション確立に使用
されるときは、ＬＳＮフィールドはそのセツションに対
応する番号（そのセツションの識別用に短縮表示されて
いる）を記憶する。

ＮＣＲが名前生成のためのものである場合は、生成すべ
き名前およびそれに関連するエンティティを識別する情
報はＮＣＲ名前フィールドに記憶される。ＮＣＲがセツ
ション確立のためのものである場合は、接続すべきエン
ティティの名前は呼出し名前フィールドに記憶される。

ＲＴＯフィールドは受信メツセージのタイムアウト値を
記憶し、ＳＴＯフィールドは送信メソセージのタイムア
ウト値を記憶する。

通知フィールドは、ＮＣＲを発行したプログラムへ完了
状況を通知するためのプログラムルーチンのアドレスを
記憶する（ＮＣＲに関連するコマンドの実行は割込み可
能であり、従ってこま切れ式に実行されることがある。

成功にせよ不成功にセヨオペレーションが終結すれば、
通知アドレスを用いて、ＮＣＲを発行した監視ソフトウ
ェアに終結状況の情報を転送するためのプログラムをア
クセスする。）。

（Ｂ−１）　名前生成オペレーション 名前を選ぶため、生成プロセッサエンティティは第６図
に示す流れ図に従って動作する。

（ａ）　ＮＣＢで指定された名前を使用するに関しロー
カルに競合があるかどうかをみるためローカル名前テー
ブルを検査する（ステップ６１）。

ｆｂ）　ローカルに競合が検知された場合はコマンド解
釈オペレーションを中止して、もとのグログラムへ対応
する状況標識を送る（ステップ６２）。

これは通常の割込み（または、プログラム等のエンティ
ティ間で状況情報の受渡しを行うためにシステムで使用
されている他の手順）によって行うことができる。

（ｃ）競合が検知されない場合は、そのノードは表−１
（後出）に示す形式を有する６名前検査′”パケット（
フレーム）を生成し、そのフレームをネットワークに送
信する（ステップ６３）。このフレームが回報通信の宛
先を有するフレームであるということを示す標識は、表
−１に示すようにその宛先フィールドの値Ｂで明示して
もよいし、あるいは、そのタイプフィールドの値（０１
）で暗に示してもよい。

（ｄ）　本実施例に従って名前検査フレームを受信する
ノードは、そのフレームで指定された名前をそこで使用
するために各自の名前テーブルを調べるよう要求され（
ステップ６４）、一致が見出された場合にのみ表−２（
後出）に示す形式を有する肯定応答を戻す。本実施例に
基づくシステムおよび他の現行の通信システムでは回報
通信フレームは通常は肯定応答されないが、上記の一致
が見出されたと−きの肯定応答はこの一般的な規則に対
する例外として取扱われる。

（ｅ）　名前検査フレームを発した起点ノードは肯定応
答のために所定のタイムアウト時間を待って（ステップ
６６）、初め所定の値にセットされている再試行カラン
）ＲＴＣを減分する（ステップ６８）。肯定応答が受信
されたときは、初め値ゼロにセットされている回答カウ
ントＲＰｃが増分される（ステップ６７）。ただしこの
増分は異なるノードから肯定応答が返ってきたときだけ
行われる。減分後のＲＴＣＯ値がゼロでないときは（ス
テップ６９）、名前検査フレームの送信が繰り返される
（経路７０）。所定の回数の繰返しの後、肯定応答が１
つも受信されない場合は、前述の通知フィールドを介し
て°゛完完了状状況通知され（ステップ７１）、名前テ
ーブルは、指定された名前、それに関連するエンティテ
ィ、そのノードの物理的な場所（■１０チャネルポート
）、および状況情報（後出）を示すエン）　ＩＪを含む
よう更新される。

（ｆｌ　肯定応答が１つだけ受信されたときは（ＲＰＣ
＝１）、最終の゛名前使用中″状況が通知される（ステ
ップ７２）。これは名前の重複を表わすので他の名前の
選択が必要である。

（ｇ）２以上の肯定応答が受信されたときは、“名前使
用中′°状況が通知され、起点ノードは゛′重複使用“
フレームを生成しこれを回報通信する（ステップ７４）
。゛重複使用″フレームの形式は表−３（後出）に示す
。このフレームは肯定応答を必要としない。オペレーシ
ョン７５に示すように重複使用フレームを受信したノー
ドは指定された名前を自身の名前テーブルで調べて、一
致が見出されたときは、そのエントリは競合としてマー
クされる（そのようなエントリは競合が解決されるまで
は使用されない）。

以上に示した各オペレーションが完了する際には、その
オペレーションの状態を表わす最終的な状況標識がそれ
ぞれ通知される。

上記の手順によってノードのエンティティに名前が割り
当てられると、その名前とエンティティとの間の連関は
本発明に関係のない手段（たとえばオペレータ間の電話
呼出し）により他のノードに知らせることができる。し
たがって他のノードはセツション（後出）を介してその
エンティティへのアクセスを共有することができる。

（Ｃ）　セツション確立 本実施例に基づくシステムでは、単一のノードまたは異
なる２つのノードのところの処理システムでサポートさ
れるエンティティペアでの２地点間通信は”セツション
”によって管理される。１セツシヨンはエンティティの
１ペアの間の論理的な接続である（たとえば一方のノー
ドでサポートされるキーボードのところのオペレータと
、他方のノードのところで保持されている記憶ファイル
との間）。１セツシヨンが複数フレームに及ぶこともあ
る。アプリケーションプログラムまたはキーボードのオ
ペレータのようなエンティティが記憶ファイルのような
他のエンティティへの参照を要求すると、セツションが
開始される。

°“起呼エンティティ″（他のエンティティへの参照を
要求するエンティティ；要求される側は“。

被呼エンティティ”′という）から適切な割込み要求を
受け取ると、起呼エンティティをサポートする監視ソフ
トウェアは被呼エンティティとのセツションを成立させ
るために１つのＮＣＢをセットアツプする。起呼エンテ
ィティがアプリケーションプログラムであるときは、他
の有益な作業を自由に続行できる（ただし継続されるオ
ペレーションが被呼エンティティへの参照に依存しない
場合）。

ＮＣＲを初期設定しく第７図、呼出しＮＣＲ）、名前に
よって起呼エンティティおよび被呼エンティティを指定
するこのセツションは、解釈のために別の処理エンティ
ティへ（主プロセツサにある別の仮想プロセッサもしく
はソフトウェアモジュールまたは副プロセツサへ）渡さ
れる。ＮＣＲは第９Ａ図および第９Ｂ図に示すオペレー
ションを呼び出す呼出しコマンドを有する。

解釈プロセッサは初めに自身のローカル名前テーブルを
調べる（第９Ａ図ステップ２００）。指名された両エン
ティティがローカルに接続され、かつ被呼エンティティ
が”リスニング状態″にあるときは、ローカル（または
内部）−ド）セツションがセツションテーブル（表−１
１）のエントリ情報によって確立される（ステップ２０
２）。

このエントリは起呼エンティティと被呼エンティティの
名前、その物理的な場所と識別子、ローカルセツション
であることを示すフラグピット、およびセツション番号
（エンティティの１ペアは同時に処理される２以上のセ
ツションを有することができ、この番号によりローカル
システムは正しいセツションを有するペアでの通信を関
連付けることができる）を含む。その後、ことしたエン
ティティ間の通信はいずれの方向でも名前（または名前
番号）によって開始され、セツションテーブルの保持を
担当するプロセッサに送られ、セツション番号への参照
を介してそのプロセッサにより適切なアプリケーション
およびエンティティへ経路指定される。

被呼エフティティがローカルでないときは、ＮＣＲを発
行したプロセッサは被呼エフティティの名前が存在する
かどうかを調べるため呼出し名前検査フレーム（表−４
）を回報通信し、肯定応答（表−２）を検査する。呼出
し名前検査フレームと名前検査フレーム（表−１）はタ
イプフィールドの値および名前フィールドの内容のとこ
ろが異なる。すなわちタイプフィールドの値は呼出し名
前検査フレームの場合は０８であり、名前検査フレーム
の場合は０１である。呼出し名前検査フレームの名前フ
ィールドの内容は選択される名前ではなく被呼エフティ
ティの名前を表わしている。

これ顛より前述の名前管理機構は制限のない呼出し名前
検査通信を無視しまたは許可することができる。これは
肯定応答の場合にも当てはまる。

この回報通信は、要求の転送および応答の解釈を誤りな
く行えるよう、所定の回数まで繰り返される（第９Ａ図
の経路２０６を介して）。肯定応答が全く受信されない
かまたは２以上受信された場合は、ＮＣＲプロセッサは
”呼出し名前未検出”状況標識をセントしてそのオペレ
ーションヲ不成功に終了する。肯定応答が２以北戻され
た場合は、ＮＣＲプロセッサは名前生成のために重複使
用フレームを生成し回報通信する（第９Ｂ図ステップ２
１０）。肯定応答が１つだけ戻される場合は、起呼ノー
ドは表−６に示す形式を有する呼出し要求フレームを対
応するノードへ送信する（ステップ２１２）。呼出し要
求フレームは、それが正しく受信され、かつ、被呼エン
ティティがりスニング状態にあるときに、表−７に示す
形式を有するリスニング肯定応答フレームで肯定応答さ
れる（ステップ２１４）。

呼出し要求フレームおよびリスニング肯定応答フレーム
はセツション番号ヲ有する。セツションの確立はこれら
の番号の突合せで条件付けられる。

これらの番号が一致したときは、起呼ノードは被呼エン
ティティをサポートするノードへ、表−８に示す形式を
有する特別にアドレス指定された呼出１〜確認フレーム
を送る（ステップ２１６）。呼出し確認フレームが正し
く受信されれば、それは表−９に示す形式を有するリス
ニング確認フレームで肯定応答される（ステップ２１８
）。それから起呼ノードおよび被呼ノードをサポートす
る各プロセッサは各自のセツションテーブルに適切なエ
ントリを生成してセツションを確立する（エンティティ
ベア、セツション番号、およびネットワークでの物理的
な場所を識別する）。その後、これらのエンティティ間
の通信はいずれの方向でも名前によって開始され、セツ
ションテーブルを介して、セツション番号およびユニッ
ト識別子を示す２地点間フレームに変換される。

第１０図は主にステップ２１２およびステップ２１４、
ならびにステップ２１６およびステップ２１８のところ
を示す図である。そのオペレーションは図から明らかな
ので説明は省略する。

次にリスニング状態の確立について説明する。

どのノードのところのりスニングソフトウェアモジュー
ルもリスニング状態を確立するために第８図に示す形式
のりスニングＮＣＲをそれぞれ使用する。指令された起
呼エンティティに向けられるリスニンクコマンドを有す
るこれらのりスヱングＮＣＲは、ＮＣＲ起点プロセッサ
によって各自の処理エンティティに送られる。処理エン
ティティは各自のテーブルを参照して起呼エンティティ
の物理的識別子および動作状況をＮＣＲ起点プロセッサ
に返す。そのエンティティが、ＮＣＲにおいて指名され
た被りスニングエンティティまたは被呼エンティティに
関して、セツション確立のために使用可能ならば、ＮＣ
Ｒ起点プロセッサは、名前テーブルにリスニング状況を
マークしその状況と被りスニングエンティティを関連さ
せてそれを起呼エンティティに関連させるようＮＣＲ評
価プロセッサに指示を送ル。

その結果、ノードが呼出し要求を受信し被呼エンティテ
ィのために事前にマークされた適切なりスニング状況を
有している場合は、そのノードはり＾ニング肯定応答を
戻す。こうした手順によれば各ノードが各自のセツショ
ントラフィックを管理することができる。

以上に説明した手順によりどのノードの資源も名前によ
りネットワークを越えて共有にすることができる。これ
らのプロセスはノードのところで走行するアプリケーシ
ョンプロセスとは別のものであり各々独立に働く。これ
らのプロセスによりアプリケーションプロセスおよび関
連する監視ソフトウェアは名前で資源を呼び出すことが
できる（ネットワークにおけるその資源の物理的な場所
はわからなくてもよい）。

の）　ノードブリッジおよびゲートウェイによる名前通
信の拡張 名前生成プロセスは異なる媒体または共通の媒体の異な
るチャネルを介して動作するように拡張することができ
る（複数のネットワーク間で動作する）。そのような複
数ネットワークはブリッジまたはゲートウェイアクセス
を提供するノードアダゲタを介して物理的にり／りする
ことができる。

以下、この拡張について説明する。

（Ｄ−１）　拡張された名前生成 （ａ）第３図に示すような簡単な構成を例にとって説明
する。第６図では、ゲートウェイ３００．６０２、およ
び３０４を介して６つのネットワークＡ、Ｂ、およびＣ
が相互通信できるようにリンクされている。ゲートウェ
イろ００はネットワークＡのノード６００ａとネットワ
ークＢのノード６００ｂをリンクし、ゲートウェイ６０
２はネットワークＡのノード６０２ａとネットワークＣ
のノード３０２Ｃをリンクし、ゲートウェイ６０４はネ
ットワークＢのノード６０４ｂとネットワークＣのノー
ド６０４ｃをリンクする。

（ｂ）　ホップカウントの制約（後で説明する）を考慮
して、１つのネットワーク内の成るノードから発せられ
た名前検査要求および呼出し名前検査要求がゲートウェ
イを介して別のネットワークへ無条件に送られると仮定
する（たとえば、ネットワークＡにおける要求がゲート
ウェイ３００および６０２を介してネットワークＢおよ
びＣに送られ、ネットワークＢにおける要求がゲートウ
ェイ３００および３０４を介してネットワークＡおよび
Ｃに送られ、ネットワークＣにおける要求がゲートウェ
イ３０２および３０４を介してネットワークＡおよびＢ
に送られる）。これらの要求に関連した肯定応答および
他のメツセージ（たとえば重複使用フレーム）も同様に
して送らねるものと仮定する。

（ｃ）　これまでの説明から明らかなように、とれもの
要求は、媒体またはチャネルの境界を越える拡張のでき
る名前／エンティティの連関を確立すせる目的で送信さ
れる。

（ｄｌ　位相幾可学的な制約がないと、そのような要求
は際限なく循環する。たとえば、ネットワークＡにおい
て発せられたメツセージは、ゲートウェイ３００、ネッ
トワークＢ１ゲートウェイ３０４、ネットワークＣ１お
よびゲートウエイ３０２の経路、またはその逆の経路で
ネットワークＡに戻ってくる。

（ｅ）　このような好ましくない非生産的なネットワー
クトラフィックの増殖を防ぐため、名前生成またはセツ
ション確立に関係する回報通信を発するノードはネット
ワークの境界を越える転送を制限する目的でそのメツセ
ージに゛ホップカウント″を設ける。この番号（表−１
ないし表−９参照）はそのメツセージが越えることので
きるネットワーク境界の数を示す。

＋ｆ）　そのようなメツセージは直ちに境界を越えて転
送してもよいし、あるいはゲートウェイでいったん保持
してから、先のネットワークで肯定応答が１つしか戻っ
てとないときにだけ先へ進むようにしてもよ（・。後者
の手順は少し複雑でコスト高であるが、重複使用フレー
ムの示す条件が確立された後はメツセージを必要以上に
先に進めることがないのでネットワーク相互間のトラフ
ィックは減る。

（ｇ）　前の例でホップカウントか２にセットされ、こ
れを有するメツセージがゲートウェイを越えるときにホ
ップカウントが１だけ減分されるものとする。こうして
、ネットワークＡにおいて発せられた名前検査フレーム
はノード６００ａおヨヒ３０２ａを介してネットワーク
ＢおよびＣにそれぞれ転送され、これらの接合点のとこ
ろでそのホップカウントが値１に減分される。対応する
メッセ−ンはゲートウェイ３０４を介してネットワーク
Ｂ−Ｃ間を進む。このときホップカウントは減分されて
ゼロになる。ホップカウントがゼロになれば、メツセー
ジはそれ以上先に進むことはなく、したがってネットワ
ークＡに戻ってくることはできない。ホップカウントは
各ノードで個別に決定してもよいし、あるいは共通のノ
ードが他の全てのノードにメツセージを発して名前で関
連付けられたメツセージのためのホップカウントの制限
を設定することによって決定してもよい。この方法は本
発明とは関係がないが、この決定は、少な（とも、ネッ
トワーク媒体またはチャネル間の連係トポロジーの知識
に基づくものであることに留意されたい。

（ｈ）　ホップカウントを用いる代わりに、先のノード
が識別用のタグを進めるべきメツセージに挿入するよう
にしてもよい。この場合は、ノードをサポートするゲー
トウェイがそのノードに送られてきた入力メツセージ中
にそのノードのタグを見出したときは、このメツセージ
はそれ以上先には進められない。

以上に説明したメツセージ進行方法に次のような要件を
加えてもよい。すなわち、名前検査およびセツション確
立メツセージに対する応答の時を調整する目的で各ノー
ドで用いられるタイムアウト機構を、ネットワークシス
テムのトポロジーに適合させることである。換言すれば
、そのようなタイムアウトはシステムの最大通信遅延と
機能的に関連付けられる。システムにおいてリンクされ
た複数のネットワークがそれぞれ異なる遅延を持ってい
るときは、これらのタイムアウトは全てのネットワーク
を介する遅延の合計に関係する。

表−１名前検査フレーム（ノードｎより）左から、起点
フィールド、宛先フィールド（回報通信）、タイプフィ
ールド、名前フィールド（検査すべき名前）、内部ＩＤ
フィールド、ホップカウントフィールドを表わす 表−２名前検査肯定応答フレーム（ノードｍより）左か
ら、起点フィールド、宛先フイニルド、タイプフィール
ド、エコーＩＤフィールド、ホップカウントフィールド
を表わす 表−６重複使用フレーム（ノードｎより）左から、起点
フィールド、宛先フィールド、タイプフィールド、名前
フィールド、ホップカウントフィールドを表わす 表−４呼出し名前検査フレーム（ノードｎより）左から
、起点フィールド、宛先フィールド、タイプフィールド
、名前フィールド、ＩＤフィールド、ホップカウントフ
ィールドを表わす表−５呼出し名前検査肯定応答フレー
ム（ノードｍより） 左から、起点フィールド、宛先フィールド、タイプフィ
ールド、エコーＩＤフィールド、ホップカウントフィー
ルドを表わす 表−６呼出し要求フレーム（表−６以下はアドレスフィ
ー゛ルドは省略） 左から、タイプフィールド、名前フィールド（起呼側）
、セツション番号フィールド（起呼側）、名前番号フィ
ールド（起呼側）、ホップカウントフィールドを表わす
；セツション番号および名前番号は事前に割り当てられ
ている 表−７”　ＩＪ　、ｒ、　Ｌ、、７ケ肯定。６７ツー□
左から、タイプフィールド、セツション番号フイールド
（起呼側）、リスニング番号フィールド（リスニング側
）、ホップカウントフィールドを表わす 表−８呼出し確認フレーム 左から、タイプフィールド、セツション番号フィールド
（リスニング側）、ホップカウントフィールドを表わす 表−９１）スニンク確認フレーム 左から、タイプフィールド、セツション番号フィールド
（起呼側）、ホップカウントフィールドを表わす 表−１０名前テーブル（ノードｎ） 表−１１セツションテーブル 〔発明の効果〕 以上説明したように本発明に基づくメツセージ交換方法
を利用すれば、分散型ネットワーク内の各メートのとこ
ろの処理システムは中央ノードと通信せずに各ノードの
エンティティに対して名前連関を生成することができ、
さらに処理システムはそうして生成された名前を用いて
セツションを確立することができるので、処理システム
および処理システムで走行するアプリケーションプログ
ラムは、ネットワークトポロジーまたはネットワークの
エンティティの物理的な場所がわからなくてもセツショ
ンを開始することができる。

【図面の簡単な説明】

第１図は本発明を利用することができる簡単なネットワ
ーク環境を示すブロック自、第２Ａ図は制御フレームの
形式を示す図、第２Ｂ図はデータフレームの形式を示す
図、第２Ｃ図はヘッダの形式を示す図、第６図は”ホッ
プカウント”′が利用されるような多重ネットワークト
ポロジーの構成例を示す図、第４図は各ノードのメモリ
に記憶された情報の構成を示すブロック図、第５図は名
前生成に有益なネットワーク制御ブロック（ＮＣＲ）の
形式を示す図、第６図は名前生成のプロセスを示す流れ
図、第７図はセツション確立のためのＮＣＢの形式を示
す図、第８図はりスニング状況をセットするためのＮＣ
Ｈの形式を示す図、第９Ａ図および第９Ｂ図はセツショ
ン確立のプロセスを示す流れ図、第１０図は第９Ｂ図に
おいてリスニング状況を利用するところのプロセスを示
す流れ図である。 出願人インターナシヨナル・ビジネス・マシ←Ｚズ・コ
ー汁しくクヨン代理人　弁理士　頓　宮　孝　− （外１名） １ｄ−・−・送受部 第１図 ＊２Ａ図 第２Ｂ図 第２Ｃ図 第４図 、　、第９Ｂ図

Claims (1)

1. 【特許請求の範囲】 通信媒体またはチャネルでリンクされた複数のノードを
   有するデータ通信ネットワークにおいて前記ノード間で
   メツセージを交換するための方法であって、 メツセージの発信源である起点ノードのアドレスを含み
   、ネットワークの他のノードからの応答を要求するメツ
   セージを前記通信媒体またはチャネルを介して回報通信
   するステップと、ネットワークの他のノードで前記メツ
   セージを受信し、該メツセージ中の情報により定義され
   た所定の条件が前記他のノードに存在するかどうかを判
   断するステップと、 該判断に応じて前記所定の条件を有するノードから前記
   起点ノードに応答メツセージを送信するステップと、 を布中７．ごとを＠微ｙすＡメツセージ交橡力炊−