JPH0712174B2 - メッセージ交換方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

【０００４】安全保護のような明らかな目的から、単一
の検査機構によるシステムへのアクセスの一意性を検証
することを必要とした分散型データ処理システムが構成
されてきた。単一の検査機構は、通常、複数の処理ノー
ドで共有された通信媒体またはチャネル上の１つのアク
セス・ノードのところに所在する。

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

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

【０００７】

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

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

【０００９】

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

【００１０】

【実施例】

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

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

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

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

【００１４】名前検査メッセージを発する起点ノードは
名前検査メッセージの送信を所定の回数だけ繰り返し
て、それが全て試行されても肯定応答が戻ってこないと
きはその名前を自身のテーブルに加える。所定の回数の
範囲内で２以上の肯定応答が戻ってきた場合（すなわち
他の２以上のノードが各自のテーブルに、指定された名
前を有する場合）は起点ノードは"重複使用"メッセージ
を同報通信する。この重複使用メッセージは指定された
名前に関して他のノードどうしが競合する可能性がある
ということを効果的に示すものである。名前検査メッセ
ージに肯定応答したノードはこれを認識して各自の名前
テーブルのエントリに競合の可能性が高いものとしてこ
れをマークし、競合が解決されるまではこの名前がこれ
以上使用されないようにする。

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

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

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

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

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

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

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

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

【００２３】呼出し要求メッセージおよびリスニング確
認メッセージにより、起呼ノードおよび被呼ノードはそ
れらのエンティティに関連すべきセッション番号を交換
する。起呼ノードおよび被呼ノードは後のセッション通
信を指示する際に用いられる各自のセッション・テーブ
ルにそれらの番号を登録する。リスニング確認の後は、
エンティティのペアの間のメッセージはいずれの方向で
も各々のノードに特定にアドレス指定されたセッション
番号で識別される（したがってエンティティの１ペアは
現に進行中の複数のセッションを有することができ、し
かもこれらのセッションは全て独立に区別可能であ
る）。セッションが確立した後は、データ転送が全く行
われないときには活動セッションの検証を要求するメッ
セージを周期的に交換することでセッションの信頼性を
高めることができる。

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

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

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

【００２７】アクセス・ノード１ａ、２ａ、および３ａ
のところの処理システム１、２、および３は図２ないし
図４に例示する形式を有する個別のパケットまたはフレ
ームで制御情報およびデータを交換する。図２に示す制
御フレームは固定長のヘッダＨおよびそれに続くＣＲＣ
／Ｈフィールド（先行する情報の内容を検査するための
もの）を含む。図３に示すデータ・フレームは固定長の
ヘッダＨおよびそれに続く可変長のデータ・フィールド
Ｄを含む。データ・フィールドＤはＣＲＣ／Ｄフィール
ドで終わる。さらに図３に示すように、ヘッダＨが中間
的なＣＲＣ／Ｈフィールドで終わるようにしてもよい。
中間的なＣＲＣ／Ｈフィールドを設ける場合は、ＣＲＣ
／ＨフィールドおよびＣＲＣ／ＤフィールドはヘッダＨ
およびデータ・フィールドＤの検証用に使用される。中
間的なＣＲＣ／Ｈフィールドを設けない場合は、最後の
ＣＲＣ／Ｄフィールドを用いて先行する全ての情報を検
証する。制御動作を要求するため、およびフレームの受
取りを肯定応答するために制御フレームを使用する。デ
ータ・フレームはデータ転送用に使用される。

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

【００２９】図２ないし図４で（ ）内に示した数字は
そのフィールドのバイト数を表わしている。

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

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

【００３２】これまでに説明してきた環境は最も簡単な
ものである。後に説明するように、本実施例はさらに複
雑なネットワーク環境（異なるチャネルまたは媒体に関
連するサブネットワークがチャネルまたは媒体をリンク
するブリッジ・アダプタまたはゲートウエイ・アダプタ
を介して主ネットワークにリンクされるような環境）に
も適用することができる。これまでに説明した環境で、
アクセス・ノードのところの処理システムは名前管理機
能、セッション管理機能、および資源管理機能を提供す
る。以下、これについて説明する。

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

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

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

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

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

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

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

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

【００４１】通知フィールドは、ＮＣＢを発行したプロ
グラムへ完了状況を通知するためのプログラム・ルーチ
ンのアドレスを記憶する（ＮＣＢに関連するコマンドの
実行は割込み可能であり、従ってこま切れ式に実行され
ることがある。成功にせよ不成功にせよオペレーション
が終結すれば、通知アドレスを用いて、ＮＣＢを発行し
た監視ソフトウェアに終結状況の情報を転送するための
プログラムをアクセスする。）。

【００４２】（Ｂ−１）名前生成オペレーション 名前を選ぶため、生成プロセッサ・エンティティは図８
に示す流れ図に従って動作する。 （ａ）ＮＣＢで指定された名前を使用するに関しローカ
ルに競合があるかどうかをみるためローカル名前テーブ
ルを検査する（ステップ６１）。 （ｂ）ローカルに競合が検知された場合はコマンド解釈
オペレーションを中止して、もとのプログラムへ対応す
る状況標識を送る（ステップ６２）。これは通常の割込
み（または、プログラム等のエンティティ間で状況情報
の受渡しを行うためにシステムで使用されている他の手
順）によって行うことができる。 （ｃ）競合が検知されない場合は、そのノードは表１
（後出）に示す形式を有する"名前検査"パケット（フレ
ーム）を生成し、そのフレームをネットワークに送信す
る（ステップ６３）。このフレームが同報通信の宛先を
有するフレームであるということを示す標識は、表１に
示すようにその宛先フィールドの値Ｂで明示してもよい
し、あるいは、そのタイプ・フィールドの値（０１）で
暗に示してもよい。 （ｄ）本実施例に従って名前検査フレームを受信するノ
ードは、そのフレームで指定された名前をそこで使用す
るために各自の名前テーブルを調べるよう要求され（ス
テップ６４）、一致が見出された場合にのみ表２（後
出）に示す形式を有する肯定応答を戻す。本実施例に基
づくシステムおよび他の現行の通信システムでは同報通
信フレームは通常は肯定応答されないが、上記の一致が
見出されたときの肯定応答はこの一般的な規則に対する
例外として取扱われる。 （ｅ）名前検査フレームを発した起点ノードは肯定応答
のために所定のタイムアウト時間を待って（ステップ６
６）、初め所定の値にセットされている再試行カウント
ＲＴＣを減分する（ステップ６８）。肯定応答が受信さ
れたときは、初め値ゼロにセットされている回答カウン
トＲＰＣが増分される（ステップ６７）。ただしこの増
分は異なるノードから肯定応答が返ってきたときだけ行
われる。減分後のＲＴＣの値がゼロでないときは（ステ
ップ６９）、名前検査フレームの送信が繰り返される
（経路７０）。所定の回数の繰返しの後、肯定応答が１
つも受信されない場合は、前述の通知フィールドを介し
て"完了"状況が通知され（ステップ７１）、名前テーブ
ルは、指定された名前、それに関連するエンティティ、
そのノードの物理的な場所（Ｉ／Ｏチャネル・ポー
ト）、および状況情報（後出）を示すエントリを含むよ
う更新される。 （ｆ）肯定応答が１つだけ受信されたときは（ＲＰＣ＝
１）、最終の"名前使用中"状況が通知される（ステップ
７２）。これは名前の重複を表わすので他の名前の選択
が必要である。 （ｇ）２以上の肯定応答が受信されたときは、"名前使
用中"状況が通知され、起点ノードは"重複使用"フレー
ムを生成しこれを同報通信する（ステップ７４）。"重
複使用"フレームの形式は表３（後出）に示す。このフ
レームは肯定応答を必要としない。オペレーション７５
に示すように重複使用フレームを受信したノードは指定
された名前を自身の名前テーブルで調べて、一致が見出
されたときは、そのエントリは競合としてマークされる
（そのようなエントリは競合が解決されるまでは使用さ
れない）。

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

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

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

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

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

【００４８】解釈プロセッサは初めに自身のローカル名
前テーブルを調べる（図１１ステップ２００）。指名さ
れた両エンティティがローカルに接続され、かつ被呼エ
ンティティが"リスニング状態"にあるときは、ローカル
（または内部ノード）セッションがセッション・テーブ
ル（表１１）のエントリ情報によって確立される（ステ
ップ２０２）。このエントリは起呼エンティティと被呼
エンティティの名前、その物理的な場所と識別子、ロー
カル・セッションであることを示すフラグ・ビット、お
よびセッション番号（エンティティの１ペアは同時に処
理される２以上のセッションを有することができ、この
番号によりローカル・システムは正しいセッションを有
するペアでの通信を関連付けることができる）を含む。
その後、こうしたエンティティ間の通信はいずれの方向
でも名前（または名前番号）によって開始され、セッシ
ョン・テーブルの保持を担当するプロセッサに送られ、
セッション番号への参照を介してそのプロセッサにより
適切なアプリケーションおよびエンティティへ経路指定
される。

【００４９】被呼エンティティがローカルでないとき
は、ＮＣＢを発行したプロセッサは被呼エンティティの
名前が存在するかどうかを調べるため呼出し名前検査フ
レーム（表４）を同報通信し、肯定応答（表２）を検査
する。呼出し名前検査フレームと名前検査フレーム（表
１）はタイプ・フィールドの値および名前フィールドの
内容のところが異なる。すなわちタイプ・フィールドの
値は呼出し名前検査フレームの場合は０８であり、名前
検査フレームの場合は０１である。呼出し名前検査フレ
ームの名前フィールドの内容は選択される名前ではなく
被呼エンティティの名前を表わしている。これにより前
述の名前管理機構は制限のない呼出し名前検査通信を無
視しまたは許可することができる。これは肯定応答の場
合にも当てはまる。

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

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

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

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

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

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

【００５６】（Ｄ）ノード・ブリッジおよびゲートウエ
イによる名前通信の拡張 名前生成プロセスは異なる媒体または共通の媒体の異な
るチヤネルを介して動作するように拡張することができ
る（複数のネットワーク間で動作する）。そのような複
数ネットワークはブリッジまたはゲートウエイ・アクセ
スを提供するノード・アダプタを介して物理的にリンク
することができる。以下、この拡張について説明する。

【００５７】（Ｄ−１）拡張された名前生成 （ａ）図５に示すような簡単な構成を例にとって説明す
る。図５では、ゲートウエイ３００、３０２、および３
０４を介して３つのネットワークＡ、Ｂ、およびＣが相
互通信できるようにリンクされている。ゲートウエイ３
００はネットワークＡのノード３００ａとネットワーク
Ｂのノード３００ｂをリンクし、ゲートウエイ３０２は
ネットワークＡのノード３０２ａとネットワークＣのノ
ード３０２ｃをリンクし、ゲートウエイ３０４はネット
ワークＢのノード３０４ｂとネットワークＣのノード３
０４ｃをリンクする。 （ｂ）ホップ・カウントの制約（後で説明する）を考慮
して、１つのネットワーク内の或るノードから発せられ
た名前検査要求および呼出し名前検査要求がゲートウエ
イを介して別のネットワークへ無条件に送られると仮定
する（たとえば、ネットワークＡにおける要求がゲート
ウエイ３００および３０２を介してネットワークＢおよ
びＣに送られ、ネットワークＢにおける要求がゲートウ
エイ３００および３０４を介してネットワークＡおよび
Ｃに送られ、ネットワークＣにおける要求がゲートウエ
イ３０２および３０４を介してネットワークＡおよびＢ
に送られる）。これらの要求に関連した肯定応答および
他のメッセージ（たとえば重複使用フレーム）も同様に
して送られるものと仮定する。 （ｃ）これまでの説明から明らかなように、これらの要
求は、媒体またはチヤネルの境界を越える拡張のできる
名前／エンティティの連関を確立させる目的で送信され
る。 （ｄ）位相幾何学的な制約がないと、そのような要求は
際限なく循環する。たとえば、ネットワークＡにおいて
発せられたメッセージは、ゲートウエイ３００、ネット
ワークＢ、ゲートウエイ３０４、ネットワークＣ、およ
びゲートウエイ３０２の経路、またはその逆の経路でネ
ットワークＡに戻ってくる。 （ｅ）このような好ましくない非生産的なネットワーク
・トラフィックの増殖を防ぐため、名前生成またはセッ
ション確立に関係する同報通信を発するノードはネット
ワークの境界を越える転送を制限する目的でそのメッセ
ージに"ホップ・カウント"を設ける。この番号（表１な
いし表９参照）はそのメッセージが越えることのできる
ネットワーク境界の数を示す。 （ｆ）そのようなメッセージは直ちに境界を越えて転送
してもよいし、あるいはゲートウエイでいったん保持し
てから、先のネットワークで肯定応答が１つしか戻って
こないときにだけ先へ進むようにしてもよい。後者の手
順は少し複雑でコスト高であるが、重複使用フレームの
示す条件が確立された後はメッセージを必要以上に先に
進めることがないのでネットワーク相互間のトラフィッ
クは減る。 （ｇ）前の例でホップ・カウントが２にセットされ、こ
れを有するメッセージがゲートウエイを越えるときにホ
ップ・カウントが１だけ減分されるものとする。こうし
て、ネットワークＡにおいて発せられた名前検査フレー
ムはノード３００ａおよび３０２ａを介してネットワー
クＢおよびＣにそれぞれ転送され、これらの接合点のと
ころでそのホップ・カウントが値１に減分される。対応
するメッセージはゲートウエイ３０４を介してネットワ
ークＢ−Ｃ間を進む。このときホップ・カウントは減分
されてゼロになる。ホップ・カウントがゼロになれば、
メッセージはそれ以上先に進むことはなく、したがって
ネットワークＡに戻ってくることはできない。ホップ・
カウントは各ノードで個別に決定してもよいし、あるい
は共通のノードが他の全てのノードにメッセージを発し
て名前で関連付けられたメッセージのためのホップ・カ
ウントの制限を設定することによって決定してもよい。
この方法は本発明とは関係がないが、この決定は、少な
くとも、ネットワーク媒体またはチャネル間の連係トポ
ロジーの知識に基づくものであることに留意されたい。 （ｈ）ホップ・カウントを用いる代わりに、先のノード
が識別用のタグを進めるべきメッセージに挿入するよう
にしてもよい。この場合は、ノードをサポートするゲー
トウエイがそのノードに送られてきた入力メッセージ中
にそのノードのタグを見出したときは、このメッセージ
はそれ以上先には進められない。

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

【００５９】

【表１】 左から、起点フィールド、宛先フィールド（同報通
信）、タイプ・フィールド、名前フィールド（検査すべ
き名前）、内部ＩＤフィールド、ホップ・カウント・フ
ィールドを表わす

【００６０】

【表２】 左から、起点フィールド、宛先フィールド、タイプ・フ
ィールド、エコーＩＤフィールド、ホップ・カウント・
フィールドを表わす

【００６１】

【表３】 左から、起点フィールド、宛先フィールド、タイプ・フ
ィールド、名前フィールド、ホップ・カウント・フィー
ルドを表わす

【００６２】

【表４】 左から、起点フィールド、宛先フィールド、タイプ・フ
ィールド、名前フィールド、ＩＤフィールド、ホップ・
カウント・フィールドを表わす

【００６３】

【表５】 左から、起点フィールド、宛先フィールド、タイプ・フ
ィールド、エコーＩＤフィールド、ホップ・カウント・
フィールドを表わす

【００６４】

【表６】 左から、タイプ・フィールド、名前フィールド（起呼
側）、セッション番号フィールド（起呼側）、名前番号
フィールド（起呼側）、ホップ・カウント・フィールド
を表わす；セッション番号および名前番号は事前に割り
当てられている

【００６５】

【表７】 左から、タイプ・フィールド、セッション番号フィール
ド（起呼側）、リスニング番号フィールド（リスニング
側）、ホップ・カウント・フィールドを表わす

【００６６】

【表８】 左から、タイプ・フィールド、セッション番号フィール
ド（リスニング側）、ホップ・カウント・フィールドを
表わす

【００６７】

【表９】 左から、タイプ・フィールド、セッション番号フィール
ド（起呼側）、ホップ・カウント・フィールドを表わす

【００６８】

【表１０】

【００６９】

【表１１】

【００７０】

【発明の効果】以上説明したように本発明に基づくメッ
セージ交換方法を利用すれば、分散型ネットワーク内の
各ノードのところの処理システムは中央ノードと通信せ
ずに各ノードのエンティティに対して名前連関を生成す
ることができ、さらに処理システムはそうして生成され
た名前を用いてセッションを確立することができるの
で、処理システムおよび処理システムで走行するアプリ
ケーション・プログラムは、ネットワーク・トポロジー
またはネットワークのエンティティの物理的な場所がわ
からなくてもセッションを開始することができる。

【図面の簡単な説明】

【図１】本発明を利用することができる簡単なネットワ
ーク環境を示すブロック図である。

【図２】制御フレームの形式を示す図である。

【図３】データ・フレームの形式を示す図である。

【図４】ヘッダの形式を示す図である。

【図５】"ホップ・カウント"が利用されるような多重ネ
ットワーク・トポロジーの構成例を示す図である。

【図６】各ノードのメモリに記憶された情報の構成を示
すブロック図である。

【図７】名前生成に有益なネットワーク制御ブロック
（ＮＣＢ）の形式を示す図である。

【図８】名前生成のプロセスを示す流れ図である。

【図９】セッション確立のためのＮＣＢの形式を示す図
である。

【図１０】リスニング状況をセットするためのＮＣＢの
形式を示す図である。

【図１１】セッション確立のプロセスを示す流れ図であ
る。

【図１２】セッション確立のプロセスを示す流れ図であ
る。

【図１３】図１２においてリスニング状況を利用すると
ころのプロセスを示す流れ図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 デニス・ダレル・キブス アメリカ合衆国フロリダ州ライトハウス・ ポイント、ノースイースト・サーテイフア ースト・アベニユー3465番地 (72)発明者 ロバート・ザークサンメイヤー アメリカ合衆国フロリダ州ボカ・ラトン、 ノースイースト・エイスス・コート7320番 地 (56)参考文献 特開 昭58−36048（ＪＰ，Ａ) 特開 昭59−53924（ＪＰ，Ａ)

Claims (1)

【特許請求の範囲】
1. 【請求項１】各々が１以上のエンティティを含む複数の
   ノードが通信媒体またはチャネルでリンクされたデータ
   通信ネットワークにおいて前記ノード間でメッセージを
   交換するためのメッセージ交換方法であって、 前記ノードにおける自己のエンティティの各々に対して
   採用された名前を含む名前連関テーブルを前記ノードで
   保持するステップと、 第一の名前を有する自己の第一のエンティティと第二の
   名前を有する第二のエンティティとの間でセッションを
   確立しようとするノードにおいて、前記第二の名前と自
   己の名前連関テーブルにおいて記憶された名前とを比較
   するステップと、 自己の名前連関テーブルにおいて前記第二の名前と一致
   する名前があるときは、他のノードとの通信を行うこと
   なく、前記第一のエンティティと前記第二のエンティテ
   ィとの間のセッションを確立するステップと、 自己の名前連関テーブルにおいて前記第二の名前と一致
   する名前がないときは、前記セッションを確立しようと
   するノードが、前記第二の名前と自己のアドレスを含む
   呼出名前検査メッセージを同報通信するステップと、 前記同報通信を発したノードで同報通信の直後から所定
   の時間間隔を計時するステップと、 前記呼出名前検査メッセージを受信した他のノードの各
   々において、自己の名前連関テーブルにおいて前記第二
   の名前と一致する名前が存在する場合にのみ、前記呼出
   名前検査メッセージを発したノードに肯定応答メッセー
   ジを送信するステップと、 前記呼出名前検査メッセージを発したノードにおいて、
   前記所定の時間間隔の間、前記肯定応答メッセージを監
   視するステップと、 前記呼出名前検査メッセージを発したノードにおいて受
   信された前記肯定応答メッセージに基づいて、セッシッ
   ン確立のプロセスを続行するかまたは打ち切るステップ
   と、 を有するメッセージ交換方法。