JPH07503569A - ネットワークにおける協調作業用ワークステーション及び協調作業方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 ネットワークにおける協調作業用ワークステーション及び協調作業方法 し技術分野］ 本発明は、ネットワークでの協調作業に関し、さらに具体的には、そのような協 調作業環境で使用するプログラマブル・ワークステーションと方法に関する。

［背景技術］ パーソナル・コンピュータは現在、実業界全体に広く普及しており、その多くは 、固定接続、たとえばローカル・エリア・ネットワークを介して、あるいは動的 に確立されるリンク、たとえば公衆交換電話網のｌ５ＤＮや非同期回線を介して 相互に通信することができる。これらの接続されたパーソナル・コンピュータを 使用して、遠く離れた個人の間の協調作業を拡大できることが増加してきている 。典型的な例は、デスク・トップ会議ソフトウェアを使用することである。協調 作業を成功させるには一般に、参加者の間に簡単なデータ・リンク以上のものが 必要である。通常、音声機能が必須であり、しばしば、ビデオ・リンクが必要に なる。したがって、リモート協調作業は従来の電話呼出しの拡張とみなせること が多い。従来の電話呼出しが、パーソナル・コンピュータを介して机上で利用可 能なデータおよびプログラムによって拡張され、時にはビデオ・サービスによっ て拡張されているものとみなされる。

ワークステーションのデータおよびアプリケーションを利用するユーティリティ 、たとえば画面ウィンドウおよびファイルの共用から、特有のクラスのリモート ・ユーザのニーズを満たすように設計された新しい協調アプリケーション、たと えばジャストインタイム・エジュケーション、リモート・プレゼンテーション、 エグゼグティブ・ブロードキャスト、ヘルプ・デスクまで、広い範囲の協調アプ リケーションを構想することができる。これらの例の共通の要件を以下に示す。

○ハードウェアとソフトウェアを共に含む広範囲のパーソナル・コンピュータ・ プラットフォームのサポート○既存の通信ネットワークを介した運用○グループ 通信およびマルチメディア・データ・サービスマルチメディア装置および通信チ ャネルを使用するデスク・トップ会議システムが存在するが、これらは一般に、 固定された１組のシステム・ソフトウェアおよびユーティリティ・アプリケーシ ョンを備えており、すべての潜在的なアプリケーションのニーズを満たすほど柔 軟ではない。

［発明の開示コ したがって、本発明は、ノードの間でデータを送信するための物理リンクによっ て接続されたネットワークのノードを形成するワークステーションのネットワー クでの協調作業用のプログラマブル・ワークステーションを提供する。

このワークステーションは、オペレーティング・システムと、 ノードの間のマルチメディア・データの物理経路指定を制御するための、オペレ ーティング・システム上で動作するネットワーク制御プログラム層と、 ワークステーション上で動作し、所定のアプリケーション・プログラム呼出しに 応答するアプリケーション・プログラムとのインタフェースをとり、ノード内で およびノードを介してデータおよび資源を共用する共用アプリケーション・プロ グラム・セットと、それぞれがアプリケーション・プログラムに関連する送信側 ボートおよび受信側ボートによってそれぞれが定義される、共用アプリケーショ ン・プログラム・セットのメンバを接続する論理専用データ・チャネルとを備え た協調環境の論理ネットワーク・モデルを作成し、かつネットワーク制御プログ ラム層と協働して、アプリケーション・プログラムに透過的に、物理ネットワー クで論理ネットワーク・モデルを実施するのに必要な物理リンクを確立するよう になされた協調アプリケーション・プログラム・サポート・プログラム層とを備 えている。

他の態様によれば、本発明は、第１のアプリケーションの受信側ボートおよび送 信側ボートを介して、他の２つのアプリケーションの間でデータを転送するため に使用されている第１のアプリケーション・プログラムによる事前に決定された プログラム呼出しに応答して、データ転送が第１のアプリケーション・プログラ ムをバイパスするように、第１のアプリケーションの受信側ボートが反転可能に 直接送信側ボートに接続される方法も提供する。

ここで、本発明を、例を介して、添付の図面の第１図ないし２５を参照して説明 する。

［発明の好ましい実施例コ 第１図には、ＬＡＮやＷＡＮなどのネットワークでリンク１１によって接続され た２台のプログラマブル・ワークステーション１０および１２が示されている。

ワークステーションの主要な構成要素は従来、ハードウェア１３から始まる層と して説明されている。詳細に図示していないハードウェアは、メイン・メモリを もつプロセッサ装置と、ディスク°ファイルなどの二次記憶域と、表示装置と、 キーボードやマウスなどの入出力装置から構成される装置サポート・ソフトウェ ア１４は、ハードウェア装置がＩＢＭのオペレーティング・システム／２　（○ Ｓ／２）などの周知のオペレーティング・システム１５内で機能できるようにす る。

従来のワークステーションをネットワークで使用する際、前記ワークステーショ ンの一部になるのは、ネットワーク１１との接続と、ネットワークを介したワー クステーションの間の通信をサポートするためのネットワーキング・ソフトウェ ア１６である。典型的なネットワーキング・ソフトウェア１６は、ＩＢＭのＮｅ ｔｂｉｏｓプログラム製品である。ここまでで説明したものは、アプリケーショ ン・プログラム１８を実行することができる従来のネットワーキング・ワークス テーションだけである。

本発明を実施するために、各ワークステーションは、分散協調作業環境を作成す るためのアプリケーション・プログラムの開発を容易にする協調アプリケーショ ン・サポート・システム・ソフトウェア１７も含む。この環境では、ワークステ ーションのエンドユーザは、マルチメディア・チャネルを介してネットワーク中 の他のワークステーションのユーザと通信し、かつ共用データおよびタスクに関 して協調作業を行うことができる。

サポート・システム１７の全体的な構造を、前記システム１７が直接インタフェ ースをとるワークステーションの他のソフトウェア構成要素と関連付けて第２図 に示す。サポート・システム１７の内部構造の詳細は、第１０図に示す。大まか に言って、システム１７の主機能構成要素は、点線で示した２つのインタフェー ス２０と２１の間にある。

アプリケーション・プログラミング・インタフェース２０によって、アプリケー ション１８はサポート・サービスを要求することができる。装置ドライバ・イン タフェース２１によって、システムは、トークン・リング・ドライバ２５、工Ｓ ＤＮドライバ２６、Ｒ３２３２ドライバ２７、その他の装置ドライバ２８などの 装置ドライバを介して広範囲なソフトウェアおよ゛びハードウェア通信サブシス テムをサポートすることができる。リンク・サポート・モジュール２２８．２２ ９は装置ドライバとのインタフェースをとる。これらは、ワークステーションで 利用可能なハードウェア・オプションに応じて交換可能であり　（第１０図は、 可能な選択だけを示す）、どのハードウェアが存在するのかをサポート・システ ムが正確に知らなくて済むように働く。暗示的な資源インタフェース（図示せず ）を介して、サポート・システムでも、アプリケーションでも、装置ドライバで も、資源ファイル２９に、ノード・アドレスやディレクトリ・データなどの通信 ネットワークの詳細を要求することができる。

ＡＰＩ２０によって、アプリケーション１８は、多様で複雑な通信ネットワーク を介して、ノード上に配置された様々なハードウェアおよびソフトウェア・プラ ットフォーム上で、対等アプリケーションを開始し、資源を共用することができ る。ＡＰＩ２０によって、アプリケーションは、基礎物理ネットワークの構造と は独立に、広範囲のマルチメディア・トラフィックに適した、共用アプリケーシ ョン間の複数の専用論理データ・チャネルを定義することができる。

ＡＰＩ２０によって、アプリケーションは共用アプリケーション間のデータ・ス トリーミングを直列化し、同期化し、組み合わせ、またはコピーすることができ る。ＡＰＩ２０によって、アプリケーションは一連の接続された装置をサポート することができ、装置データのインターセプトおよびリダイレクトを可能にする 。

サポート・システムは、外部アプリケーションおよび装置とのインタフェースを とる拡張可能な１組の論理装置３０などのアプリケーション開発を助けるための 他の構成要素を含む。ＡＰＩに書き込まれた、アプリケーションからコマンド・ インタフェースを介して呼び出すこともできる１組のエンドユーザ・インタフェ ース（図示せず）も、設けられている。

ネットワーク、ノード、およびアプリケーション最高レベルでは、ＡＰＩによっ て提供されるプログラミング・モデルは通信ノード・セットから構成される。ノ ードとは、ユーザを表すアドレス可能なエンティティであり、サポート・システ ム・ソフトウェアのインスタンスと、アプリケーション・プログラム、データな どの１組の資源を備えている。通常、ノードは、その対等サブシステムと通信で きる専用プログラムマブル・ワークステーション１ｏである。マルチユーザ・シ ステムでは、ノードは各ユーザに関連づけられる。

ノードは、サポート・ノードまたは非サポート・ノードである。サポート・ノー ドは、サポート・システム・ソフトウェア１７が実行されるものである。相互通 信サポート・ノードの集合をサポート・ネットワークと呼ぶ。

ノードは名前で識別される。理想的には、ノード名はすべて特有のものであるべ きだが、関連するノードが相互通信する必要がないかぎり重複が許容される。ノ ード命名方式の選択は、本発明に直接関連していない。ただし、インタネット・ プロトコルによって定義されたような階層システムは多数の利点を有する。ノー ドがネットワークに動的に参加し、あるいはネットワークを動的に抜けられるこ とが、アーキテクチャの基本である。

ノードは、論理装置３ｏを含むことができる。論理装置とは、アプリケーション がアーキテクチャ中の他のエンティティと矛盾せずにソフトウェアまたは装置を 操作または管理できるようにするサポート・システムのソフトウェア拡張機能で ある。プレゼンテーション・ウィンドウ、プリンタ、ディスク・ドライバ、モデ ム、およびアプリケーション・プログラムを含む広範囲の論理装置がある。

ノードでは、オペレーティング・システムおよびウィンドウ・システムによって ノードに課される制限に従って、複数のアプリケーションを実行することができ る。アプリケーションは、ａｗａｒｅまたはｕｎａｗａｒｅであり、ａｗａｒｅ アプリケーションはＡＰＴのサービスを使用し、ｕｎａｗａｒｅアプリケーショ ンは使用しない。ａｗａｒｅアプリケーションとｕｎａｗａｒｅアプリケーショ ンは共に、一般に、ノードで同時に実行する。

あるノードでサポート・システムが完全に活動状態のとき、そのノードでは１つ の特定のａｗａｒｅアプリケーションが動作しなければならない。このアプリケ ーションは、そのノードで特有の役割を果たし、呼出しマネージャ３２といわれ る。特定のノードでは、多数の呼出しマネージャを実行することができるが、１ 度に１つしか実行できない。呼出しマネージャの特別な機能は、サポート・シス テムが生成するある種の事象に応答することである。たとえば、呼出しマネージ ャはアプリケーションのインスタンスに特定的に向けられていない要求を解決し 、かつ任意選択でノードの資源管理を処理することもできる。呼出しマネージャ の責任は、１つの呼出しマネージャから他の呼出しマネージャに移すことができ る。適宜、役割をユーザ・アプリケーション機能と組み合わせることもできる。

サポート・システム１７は、あるノードの資源を他の２つのノードの間の通信に 利用するよう要求することができる。

これを受動命令と呼び、許可は受動ノードにある呼出しマネージャによって制御 される。−例として、ＬＡＮ上の２つのノードＡおよびＢがあり、第３のノード Ｃが非同期通信リンクによってＢに接続されているものとする。ＡとＣにあるア プリケーションが通信を望む場合、トラフィックをＢを介して経路指定する必要 がある。Ｂのノードをこのように使用するには、Ｂにある呼出しマネージャの同 意が必要である。

ａｗａｒｅアプリケーションは、データおよび資源を、同じノードまたは異なる ノードにある他のａｗａｒｅアプリケーションと共用することができる。共用を 行うアプリケーションの集合を共用セットと呼ぶ。ａｗａｒｅアプリケーション は、共用要求を開始し、アプリケーション共用セット、ターゲット・アプリケ− ジョン、および宛先ノードを指定する。この要求はまず、サポート・ソフトウェ アによって、送信側ノードにある呼出しマネージャに渡される。該呼出しマネー ジャは通常、宛先ノードにある呼出しマネージャに要求を転送する。通常、この 第２の呼出しマネージャは、要求されたアプリケーションをローンチし、発信元 アプリケーションは通知を受ける。このプロセスに呼出しマネージャが参加する ことによって、共用プロセスのローカル制御と、必要に応じて開始すべきその他 のアクションが共に可能になる。呼出しマネージャは、アプリケーションが他の ノードおよびアプリケーションを識別するために使用する名前を処理する上で重 大な役割を果たす。

共用機構は連鎖することができる。たとえば、２つのアプリケーションがすでに 共用を行っている場合、それらの一方が、同じ共用セットを指定する第３のアプ リケーションとの共用を開始することができ、その結果、３つのアプリケーショ ンはすべて、相互に共用を行うことになる。

アプリケーションは、他のアプリケーションに代わってローカル共用要求を行う ことができ、それによって、代行すべき共用セットのメンバシップ制御を可能に する。共用要求の発行側またはターゲットがアプリケーション共用セットを指定 するための機能が存在する。このような名前は、特有のものである必要はない。

したがって、同じ名前の共用セットが複数存在できる。

それぞれのアプリケーションは、いつでも共用を終了し、共用セットを抜けるこ とができる。共用セット中の他のアプリケーションには、このことが通知される 。第３図は、多数のアプリケーションＡないしＥの共用を示す。この結果、第４ 図に示すように、共用が要求された順序にかかわらず２つの共用セットが生成さ れる。

通信、チャネル、およびボート 第５図の概略例に示すように、４０．４１．４２などの共用セット中のアプリケ ーションは、チャネルといわれるデータ通信リンクを相互に確立することができ る。４３．４４などのチャネルは、論理的に専用の単一方向バイブであり、アプ リケーションで指定された送信特性を有する。チャネルは常に、送信側アプリケ ーションによって定義され、送信側アプリケーションから受信側アプリケーショ ンに向かう。チャネルの端部はボートといわれる。したがって、チャネルはすべ て、１つの送信側ボートと１つの受信側ボートを有する。

４５などの送信側ポートは、チャネルを介してパケット・データを送信する。４ ６などの受信側ポートはチャネルからのデータ・パケットを、それらが送信され た順序で受信する。

ａｗａｒｅアプリケーションに見える論理チャネル構造と、ノードの間に存在す る物理通信ネットワークの間に直接マツピングがない場合がある。

アプリケーションは、他のアプリケーションへの複数のチャネルを、異なるタイ プのデータ・トラフィックを分離する好都合な方法として確立することができる 。第２図のシステム・ネットワーク・マネージャ３１は、論理チャネルの一部ま たはすべてを、第１図のリンク１１などの単一の物理リンク上にマツプすること ができるが、これはアプリケーションには見えない。

チャネルは、多数のサービス品質特性を有する。これらの特性に作成プロセス中 にサポート・システム１７がまず交渉する。これによって、データ伝送特性を、 予期されるトラフィックの要件に合わせて調整することができる。これらの特性 は、暗号化、圧縮ヒントを含む。暗号化によって、チャネルに沿った伝送時にデ ータを暗号化することができる。圧縮ヒントによって、狭い帯域幅のリンクを介 してデータを圧縮するオプションがシステムに与えられる。

サービス品質パラメータは、アナログ・データとディジタル・データを区別する 信号タイプによって定義される。サービス・パラメータは、明示的に指定しなく てよいが、データ・クラスに関してはサポート・システムに通知することができ る。この機構によって、ビデオ・チャネル、音声チャネル、およびその他のデー タ・チャネルを都合よく確立することができる。チャネルの特性は、チャネルを 作成した後に再折衝することができる。データ送信特性は、ＡＰＩを介するチャ ネル作成呼出しで指定された特性に応じて、第２図のデータ送信マネージャ３２ によって実際のネットワークで実施される。

標準、組合せ、同期、および直列化の４つのチャネル・タイプがサポートされる 。標準チャネルはデフォルト・ケースである。他のタイプは、チャネル・セット といわれるチャネルの集合に関連して使用される。組合せチャネル・セットを介 して、複数のチャネルからのデータ・パケットが組み合わされ、単一のボートを 介して各受信側アプリケーションに送られる。各アプリケーションがすべてのデ ータ・パケットを同じシーケンスで受信することは保証されず、各アプリケーシ ョンがすべてのパケットを受信することだけが保証される。

直列化チャネル・セットを介して、異なるチャネルからのデータ・パケットが組 み合わされ、直列化され、各受信側ボートが同じシーケンスのデータを受信する ように各アプリケーションに送られる。同期チャネル・セットを介して、データ が同期され、それによって、別々のチャネル上のデータ・パケットが調子を合わ せて結合される（たとえば、音声とビデオ）が、そのチャネルに属するそれぞれ のボートを介して送られる。

データ直列化の一例を第６図に示した共用ドローイング・ボード・アプリケーシ ョンによって示す。２つの同じアプリケーションＡおよびＢ（５０および５２） によって、ユーザは単一の共用表面上で描画することができる。ＡおよびＢにい るユーザが同じ結果を見るには、ＡとＢで処理されるシーケンスが同じになるよ うに、Ａにあるすべての描画命令をボート５３および５４を介してＢに送り、Ｂ にあるすべての描画命令をボート５５および５６を介してＡに送らなければなら ない。これは、それぞれのアプリケーションが、共通の直列化チャネル・セット ５９のメンバである２つのチャネル５７および５８を介して、相互にかつそれ自 体にそれ自体のデータを伝送することによって行われる。

第４図を参照すると、リップ同期されたビデオと音声をアプリケーションＢ（６ １）に送信する必要があるアプリケーションＡ（６０）によってデータ同期が示 されている。２つのチャネル６２および６３は送信に使用され、それぞれが同じ 同期チャネル・セット６４のメンバである。

必要なチャネル特性を指定するサポート・システムへのＡＰＩ呼出しによってチ ャネルを明示的に作成することができ、既存のボートに新しいチャネルを追加す ることもできる。後者の機構によって、異なるチャネル・セットに属するチャネ ルを介してボートを共用することができる。たとえば、単一のボートから、組合 せチャネル・セットに属する１組の宛先、および直列化チャネル・セットに属す る第２の組みの宛先にデータを送信することができる。ディジタル・チャネルと アナログ・チャネルが同じチャネル・セットのメンバになることはできない。チ ャネルは削除することができ、送信側ボートと受信側ボートを指定することによ って固有に識別される。

チャネルは、アプリケーション共用セットのメンバである、または該メンバにな るアプリケーションの結果として暗示的に作成することができる。たとえば、未 共用アプリケーションがすでに、組合せチャネルまたは直列化チャネルを有する 場合、使用されるチャネル・セット名はこれらのアプリケーションのどれでも同 じであり、アプリケーションが相互に共用を行うと、必要な追加チャネルが自動 的に作成される。アプリケーションには、このように暗示的に作成されたチャネ ルが通知される。

ボートは、事象、コマンド、または空の割り当てられた接続タイプを有する。事 象ボートは、データが利用可能か□、または必要なときに事象を生成する。コマ ンド・ボートによって、アプリケーションはデータの受信またはボートへの供給 を駆動することができる。空ボートは、データをアプリケーションに供給できな いボート、すなわち、ビデオ・カメラの送信側ポートなどの、アナログ・チャネ ルに関連するボートのために予約される。ボートは、ボート事象ハンドラに送信 される”ｓｉｇｎａｌ　ｐｏｒｔ”コマンドを介して制御することができる。こ のコマンドは、ローカル・ボートに発行し、チャネル中の他のボートに渡すこと ができる。通常、チャネル・ボート用のｓｉｇｎａｌコマンドは、データを供給 または受信するアプリケーションのボート事象ハンドラに送信され、たとえば、 データ・フローを停止、開始、削減、または増加するために使用できる。発信元 とターゲットの間の信号の順序は維持される。直列化チャネル・セット中の受信 側ポートに送信される信号は、それ自体が直列化され、それによって、すべての 発信元が同じシーケンスのコマンドを受信する。他の典型的な信号はテープ・ド ライブに対する”ｒｅｗｉｎｄ’″または”ｐａｕｓｅ”　、あるいはプリンタ 装置に対する”ｃｈａｎｇｅ　ｐａｐｅｒｓｉｚｅ”である。

ユーザ出口は、任意選択でボートに関連付けることができる。これによって、デ ータが送信側ポートに供給された後、または受信側ポートによって供給される前 に、データを監視、または操作することができる。同期チャネルの場合、同期は 、データが送信側ポート・ユーザ出口を離れてから、受信側ポート・ユーザ出口 に供給されるまで実行される。

標準送信側コマンド・ボートの全体的な構造を第８図に示す。データは、アプリ ケーションからの”５ｅｎｄ　ｄａｔａ”コマンドに応答して、ボート７０のバ ッファ７１中で待機する。アプリケーションは、バッファを空にして、ユーザ出 ロア２とチャネル７３を介して非同期的にデータを送信する。着信した”ｓｉｇ ｎａｌ　ｐｏｒｔ”コマンドは、回線７５上でチャネル７３とは独立に、ボート 事象ハンドラ７４によって受信され、回線７６上で外部に再伝送することができ る。　゛受信側ボートは実際上、対応する送信側ポートのミラー・イメージであ る。標準受信側事象ボートの場合、構造が類似しているが、この場合、事象ハン ドラはデータとｐｏｒｔコマンドを共に処理する。

同期を呼び出すときには状況はより複雑である。この場合、ユーザ出口およびバ ッファの前に、着信側チャネル上に同期プロセスを含めることによって、標準受 信側バッファ・ホードを修正しておかなければならない。

同期は論理的に、すべての事象を中央点に集合させることと、その後に、各事象 を、その事象のすべての宛先に回報通信することを伴う。図では、チャネル８０ および８１上の２つのボートＡおよびＢの場合に関する第９図でこれを表す。

この図では、直列化プロセス８５で、８２および８３でのボートＡおよびＢの出 力が、ボートＣ（８４）および他のボート（図示せず）に対して直列化される。

直列化は、すべてのデータを、直列化し、その後に分散するために単一の中央点 に送信することによって、該中央点で実施することができる。

直列化プロセス自体を分散することもできる。

受信側ポートは、送信側ポートに、チャネルに沿ったデータの送信を停止させ、 チャネル中の残りのデータを破棄するか、送るかのオプションを与える。後で、 中断されたデータ伝送を再開することができる。

チャネルとボートの使用を不要にするアプリケーション相互通信の代替方法は、 アプリケーションの間で制御情報を送信できるようにする’ｓｉｇｎａｌ”コマ ンドを介して提供される。

ボートは、データ・タイプおよびデータ・サブタイプを指定するデータ・クラス に関連している。データ・タイプはデータの性質、たとえば音声、ビデオ、ファ イルなどを識別し、アナログ・データとディジタル・データも区別する。データ ・タイプはさらに、データの厳密なフォーマットによって細分される。したがっ て、音声サブタイプの例はＧ、７１１、Ｇ、７２１、Ｇ、７２２である。

データ・クラスは、他のアプリケーションに依存せずに、データ・ストリーム自 体とは独立に、データ・フォーマットを得るためにアプリケーションによって照 会することができる。ＡＰＩより下位でＬａｋｅｓが変換を実行すれば、データ ・タイプは、送信側ボートと受信側ボートで異なってもよい。

ボートおよびチャネルのある種の特性、たとえばサービス品質、データ・クラス 、圧縮ヒントは、最初に確立した後に変更することができる。これによって、ア プリケーションが実行時に通信使用法を修正するための柔軟性が提供される。

−例は、ビデオ品質を一時的に低下させ、ファイル交換性能を高めることである 。

アプリケーションが、処理のために、入力を他のアプリケーションに経路指定で きるように、拡張通信リンクを確立するようにボートを接続することができる。

ボートをこのように接続し、ユーザ出口を確立していない場合、経路指定を確立 した後、それ以上アプリケーションを関与させる必要はない。これによって、ア プリケーションと装置の間のデータのストリーム化が可能になる。１つのボート が送信側であり、１つのボートが受信側でありさえすれば、異なるデータ・クラ スまたは異なる接続タイプの、異なるサービス品質特性を有する、異なるタイプ の異なるチャネル・セット中のチャネルの間で（１つのボートが空であるかぎり ）接続が許可される。接続が永続的になり、ローカル・アプリケーションを終了 したときでも持続するように、接続したボートをウェルドすることもできる。チ ャネルは、すべての点で、最初から、発信元から直接宛先まで作成された場合と 同様に動作する。

存在するすべてのユーザ出口は削除することができる。

論理装置 論理装置３０（第２図）は、（ｉ）クリップボード、ＤＤＥ１プリンタ、ビデオ 装置などのシステム資源および装置へのより容易なアクセス、（ｉｉ）たとえば 、ｕｎａｗａｒｅアプリケーションのウィンドウ内容およびファイル活動へのア クセスを与えることによって、ｕｎａｗａｒｅアプリケーションを協調作業に使 用すること、および（ｉｉｉ）アプリケーションの関与しない端末間データ・ス トリーム化、をイネーブルにするためにサポート・システムによってサポートさ れる。頻繁に使用される装置は、ビデオ・キャプチャ、ビデオ・プレイバック、 オーディオ・プレイバックなどを含み、追加装置を定義するために機能が提供さ れる。

論理装置はタイプによって識別される。タイプ名は、ノードに対してローカルで ある。論理装置はオープンされると、アプリケーションにボートを提供する。単 一の論理装置が複数のボートを有することができ、さらに、装置は同じノードに ある異なるアプリケーションに同時にボートを提供することができる。ボートを オープンするための関連ＡＰＩ呼出しによって、その装置に特有の特性、たとえ ば使用すべきデータ・フォーマットを設定することができる。オープンされた論 理装置は、単一のボートに送信される、特定の論理装置に特有のコマンドを介し て制御することができる。装置ポートへの典型的なコマンドは、テープ・ドライ ブへのリワインドまたはポーズである。装置の状況、たとえばデータが利用可能 かどうかを照会することもできる。

装置は、ユーザ出口が存在しないことを除き、チャネル・ボートによく似ている 。アプリケーションは、論理装置上のボートをチャネル・ボートに接続すること ができる。これによって、データは、装置との間を流れ、かつチャネルを介して 流れることができる。このデータ・フローは、接続が確立された後、それ以上ア プリケーションを関与させることを必要としない。たとえば、データをチャネル を介してカメラからカメラ論理装置までストリーム化し、ウィンドウ論理装置に よって表示することができる。アプリケーションは２つの論理装置をそれらの信 号ボートを介して制御することができる。もはや伝送が必要ないとき、アプリケ ーションはボートを切断し、装置をクローズし、チャネルを削除することができ る。

装置ボートをチャネル・ボートにウェルドすることはできない。なぜなら、こう すると、装置がローカル・アプリケーションの制御外に存在できるようになるが らである。論理装置は、サポート・システムにＡＰＩ呼出しを発行することを許 可されており、この点では、所有アプリケーション（すなわち、装置をオープン したアプリケーション）の代わりに働く。装置はたとえば、その所有アプリケー ションに、他のアプリケーションと共用を行わせ、チャネルを作成させ、かつデ ータを送受信させることができる。

潜在的な装置には以下のようなものがある。

−システム・クリップボード　−ＬＰＴｘ−ＤＤＥ　−ウィンドウ −共用クリップボード　−プリンタ ー直列エミュレータ　−ファイル ービデオ　−符復号器 −オーディオ　−電話 クリップボードの共用は、システム・クリップボード装置および共用クリップボ ード装置によって容易になる。システム・クリップボード装置をアプリケーショ ンによってオープンして、そのノードでのウィンドウ・システム・クリップボー ドへのアクセスを与える送信側ポートおよび受信側ポートを提供することができ る。いつでも送信側ポートは１つしか存在できないが、そのノードにあるどのア プリケーションでも受信側ボートをオープンすることができる。チャネルを使用 すると、あるノードからのシステム・クリップボード・データを単純に、アプリ ケーション共用セットの他のメンバに経路指定することができる。

他の装置、共用クリップボードは、データ共用を容易にするために提供されてい る。共用クリップボードは共用セットに特有のものである。送信側ポートは１つ しか許可されないが、複数の受信側ボートがサポートされる。これらの違いは別 として、共用クリップボードは、システム・クリップボードと同様に動作し、ア プリケーションが共通データを共用するための単純な機構を提供する。

ウィンドウ装置によって、画面上に定義されたウィンドウを送信側ボートまたは 受信側ボート（状況によってはその両方）と関連付けることができる。送信側ボ ートをチャネル・ボートに接続することができ、データをウィンドウにストリー ム化して表示することができる。様々なデータ・フォーマットがサポートされる 。

ＤＤＥ装置をオープンして、動的データ交換機構に結合された送信側ボートおよ び受信側ボートを提供することができる。ａｗａｒｅアプリケーションは、この 装置を介して、ＤＤＥをサポートするアプリケーションを制御し、あるいはそれ 自体を制御することができる。さらに、適切なチャネルを確立することによって 、２つのリモートＤＤＥアプリケーションをリンクすることができる。

プリンタ装置によって、データをシステム・プリンタに送信することができる。

送信側ボートは１つしか許可されない。

非同期直列装置は、１つの送信側ボートと複数の受信側ボートをサポートし、Ｒ ３２３２、Ｒ３４２２、オヨヒソノ他の直列通信とのインタフェースをとる。

ビデオ・ディスプレイ・プレイバック装置（ＩＢＭ／インテル・アクションメデ ィアエ■アダプタ／　Ａ　（ＩＢＭ／ＩｎｔｅｌＡｃｔｉｏｎＭｅｄｉａ　ＩＩ 　Ａｄａｐｔｅｒ／Ａ）をサポートする）、ビデオ・キャプチャ装置（ＩＢＭＭ ビデオ・キャプチャ・アダプタ／Ａ　（ＩＢＭ　Ｍ−Ｖｉｄｅｏ　Ｃａｐｔｕｒ ｅ　Ａｄａｐｔｅｒ／Ａ）をサポートする）、オーディオ・キャプチャ・プレイ バック装置（ＩＢＭ　Ｍオーディオ・キャプチャ・プレイバック・アダプタ／Ａ （ＩＢＭＭ−Ａｕｄｉｏ　Ｃａｐｔｕｒｅ　ａｎｄ　Ｐｌａｙｂａｃｋ　Ａｄａ ｐｔｅｒ／Ａ）　をサポートする）、およびその他の特殊オーディオ／ビデオ装 置（Ｈ３２０準拠符復号誰々どの）を含む、多数のビデオおよびオーディオ装置 が存在する。

ａｗａｒｅアプリケーションの多（はシステム・ユーティリティとして出荷され ており、これらの装置を利用して、ネットワークを介した協調作業のための汎用 エンド・ユーザ機能を提サポート・システム１７用のカストマイズ情報は、適切 なプラットフォーム指定リポジトリに記憶される。ＷｉｎｄｏｗｓおよびＯ５／ ２）場合、コノ情報線、ＬＡＫＥＳ、　ＩＮＩ　オｃｌ：びＬＡＫＥＳＱＯ３， ＩＮＩ　ト呼ばれるファイルである。これらのファイルは、キーワードとその値 が維持される、識別子で始まるセクションを含む標準ＡＳＣＩＩファイルとして フォーマットされる。アプリケーションは、それ自体の追加初期設定フィールド を有することもできる。ＬＡＫＥＳ、　ＩＮＩは、構成および始動オプション、 ａｗａｒｅアプリケーション、装置、および物理通信リンクに関する情報を含む 標準セクションを含む。そのようなアプリケーションに特有のデータを含むアプ リケーション・セクションを存在させることもできる。ＬＡＫＥＱＯ３，ＩＮＩ は、物理リンクおよびデータ・クラスに関するサービス品質情報を含む。これら のファイルにアクセスし、それらを更新するための呼出しはＡＰＩに提供されて いる。

資源管理 協調作業では多くの場合、ノードが所有する資源、たとえばプリンタ装置を他の ノードと共用できることが必要になる。

そのような資源は、グローバル資源とみなされ、アクセスはグローバル・トーク ンを介して制御される。その他の資源、たとえば共用ポインタは、アプリケーシ ョン共用セットにローカルであり、これへのアクセスはアプリケーション・トー クンを介して管理される。

トークン所有者は、トークンの重要度を判定し、それを要求上に割り振る。所有 者の裁量で、待機中の要求を許可することができ、特定のトークンの複数の同時 保持者を許可することができる。トークン所有者は、任意選択で、保持者にトー クンを戻させることができる。

グローバル・トークンは、ネットワーク全域にわたって共通名前空間を共用する が、アプリケーションは′、それが必要とするグローバルに利用可能な資源の位 置を知っているとみなされるので、重複グローバル・トークン名が許可される。

可用性情報を同報通信するための機能は提供されない。その代わり、グローバル 資源をもつノードにある呼出しマネージャは、資源管理の責任を負い、したがっ て、あらゆるグローバル・トークンを保持する。グローバル・トークンは、アプ リケーション・インスタンスによって排他的に保持し、あるいは共用することが できる。しかし、トークン所有権をアプリケーションに移すことはできない。グ ローバル・トークンをめる要求は、ＡＰＩより上位で保持され、ノード呼出しマ ネージャによって管理される待ち行列によって待機させることができる。グロー バル・トークンへのアクセスは共用アプリケーション・セットだけに制限されな い。

アプリケーション・トークン名空間は、アプリケーション共用セットだけに制限 されない。トークンはどのメンバ・アプリケーションでも所有することができ、 所有権を移すことができる。アプリケーション・トークンは排他的に保持し、あ るいは共用することができ、トークンに対する要求は、ＡＰＩより上位で保持さ れ、現アプリケーション・トークン保持者によって管理される待ち行列で待機す ることができる。

初期設定および終了 サポート・システムは、ＬＡＫＥＳ、ＥＸＥファイルを動作させることによって 始動される。このファイルは、ファイルＬＡＫＥＳ。

ＩＮＩからプロファイル・データを読み取る。指定された呼出しマネージャが、 サポート・システムによって始動され、次いで、それ自体をａｗａｒｅアプリケ ーションとして登録する。次いで、”ｓｅｔ　ｃａｌｌ　ｍａｎａｇｅｒ”コマ ンドがこの特定のアプリケーションをそのノード用の呼出しマネージャとして確 立する。

このコマンドの後に、サポート・システムはそのノードで完全に活動状態になり 、着信事象および要求を処理できるようになる。

ａｗａｒｅアプリケーションは、アイコンのダブル・クリックなどの通常のオペ レーティング・システム手順、または”　１ａｕｎｃｈ”コマンドによって開始 することができる。前者の場合、アプリケーションはサポート・システムに登録 され、リターン・データで、アプリケーション・ハンドルおよびノード・ハンド ルを受信する。呼出しマネー、ジャにこの登録のことが通知され、アプリケーシ ョンへのハンドルが供給される。後者の場合、ローンチする側のアプリケーショ ンにアプリケーションへのハンドルが返される。ローンチされる側のアプリケー ションがサポート・システムに登録されるまで、このハンドルは非常に限られた 状況でしか有効ではない。リターン・データは、ローンチされる側のアプリケー ションにアプリケーション・ハンドルとノード・ハンドルを提供する。

呼出しマネージャと、ローンチを指定したアプリケーション（呼出しマネージャ と異なる場合）は共に、適宜、通知を受ける。

アプリケーションは、登録が取り消され、呼出しマネージャが通知を受けること によってｕｎａｗａｒｅアプリケーション状況に戻ることができる。保持されて いるすべてのトークンが解除され、トークン所有者が通知を受け、所有されてい るすべてのトークンが無効になる。アプリケーションがアプリケーション共用セ ットのメンバである場合は削除され、該アプリケーションが前記セットを抜けた ことが他のメンバに通知される。アプリケーションによって作成されたすべての ボートが破壊され、影響を受けるチャネルへのボートを所有する他のアプリケー ションが通知を受ける。終了するアプリケーションによって接続されたすべての チャネルがウェルドされ、端末チャネル・ボートで適切な事象がレイズされる。

適切な事象をレイズすることは、ローカル呼出しマネージャと、登録を取り消す 側のアプリケーションに代わって、ウェルドされたチャネルをサポートするあら ゆるノードの呼出しマネージャに必要である。オープンしている論理装置はすべ てクローズされる。ボートに接続された論理装置がある場合は登録取消しプロセ スの一部として破壊され、次いで、接続されたチャネル全体が破壊され、適当な 事象がレイズされる。

ノードにあるサポート・システムを通常の方法でクローズするために、アプリケ ーションによって遮断要求を発行することができる。これによって、ローカル呼 出しマネージャで事象がレイズされ、呼出しマネージャが要求を受け入れる場合 は、他のアプリケーションで対応する遮断事象がレイズされる。次いで、これら のアプリケーションは閉止し登録を取り消す準備をして、各登録取消しが呼出し マネージャに通知される。すべてのアプリケーションが登録を取り消したことが 呼出しマネージャに通知された後、前記呼出しマネージャも登録を取り消して遮 断を完了する。

サポート・システムの通常の操作は、呼出しマネージャの存在によって変化する 。既存の呼出しマネージャを他の呼出しマネージャと交換することが可能である が、既存の呼出しマネージャは、その要求を拒否することができる。

アプリケーションは、”５ｈａｒｅ　ａｐｐ’″要求を発行してアプリケーショ ン共用セットを指定することによって、共用セット中の他のアプリケーションに 加わることができる。通常の場合には、ターゲット・アプリケーションとノード を共に名前で指定する。あるノードにあるアプリケーションが他のノードにすで に存在するアプリケーション・インスタンスと名前によって共用を行いたい場合 の手順は次のとおりである。ノード１にあるａｐｐ　１が、それ自体のアプリケ ーション・ハンドルおよびノード・ハンドルを発信元として、ａｐｐ　２および ノード２の名前をターゲットとして指定した”　５ｈａｒｅ−ａｐｐ”要求を発 行する。ノード１にある呼出しマネージャによる検証の後、サポート・システム によって、ノード２にある呼出しマネージャに適切な要求が送信される。この呼 出しマネージャが要求を受け入れる場合、要求はａｐｐ　２上に渡され、ａｐｐ 　２は、それが共用の受入れを希望していることを示す確認を返すことができる 。この方式は、アプリケーション共用においてかなりの柔軟性を提供する。各呼 出しマネージャは、アプリケーションが”５ｈａｒｅ−ａｐｐ”要求の発信元で あれ、ターゲットであれ、そのノードでの共用活動を知る。

呼出しマネージャは、共用要求の受信時に、（ｉ）共用自体を処理する、（ｉｉ ）共用要求を転送する、（ｉｉｉ）共用を拒否する、（ｉｖ）共用を処理する新 しいアプリケーションをローンチする、（Ｖ）アプリケーションおよびノード名 を変更するというオプションを有する。

アプリケーションは、ローンチされるとき、アプリケーション共用セットのメン バではない。発信元アプリケーションは、”５ｈａｒｅ　ａｐｐ”要求を発行す るとき、その結果得られる共用セットを命名するオプションを有する。共用セッ トを命名しない場合、ターゲットが名前を供給しなければならない。

共用を行った後、ターゲットと発信元は共に、この名前の新しい共用セットに加 わる。発信元またはターゲット、あるいはその両方がすでに、これと同じ名前の 共用セットのメンバだった場合、それらの共用セットは新たに作成された共用セ ットと組合わされる。アプリケーションは、”ｕｎｓｈａｒｅ　ａｐｐ”要求を 使用して共用セットを抜けることができる。

データ送信および受信 アプリケーションがデータを交換するための機構が４つある。

（ｉ）ユーザ情報文字列 これは実際上、ＡＰＩ呼出し中のパラメータとしてサポート・システムに渡され 、次いでターゲット・アプリケーションに渡される文字列である。

（１１）信号関数呼出し このコマンドは、アプリケーションの間で制御情報を送信できるようにし、単一 の共用セット内のアプリケーションだけに制限されない。使用されるＡＰＩ呼出 しに応じて、応答が提供されることも、提供されないこともある。この方法が異 なるノード自体のデータ制御フローのために該ノード上のサポート・システムの 間に確立された通信径路を使用するため、この技術は、軽いデータ・トラフィッ クに制限されることに留意されたい。

（ｉｉｉ）チャネル送信 チャネルは、アプリケーションの間のボリューム・データの転送をサポートする ものである。チャネルは、転送特性を制御する手段だけを提供する。チャネルの 使用は、同じアプリケーション共用セット内のアプリケーションだけに制限され る。チャネルの作成を要求する際は、ターゲット・アプリケーション・ハンドル 、チャネル・セット・タイプおよび識別子、データ・クラス、最大バッファ・サ イズ、ユーザ出口、ノード・ハンドル、サービス品質、接続タイプ、ボート事象 ハンドラ、ユーザ情報の情報を指定する。チャネル作成の代替手法は、既存の組 合せチャネル・セットまたは直列化チャネル・セットをもつアプリケーションが アプリケーション共用に関与しているときに作成されたチャネルを利用すること である。

データは、アプリケーションによってチャネルを介してデータ単位で送信される 。物理レベルでは、データ送信の単位はフレームである。ある種のデータはスポ イル可能である。

すなわち、ある状況の下では、サービス品質要件を満たすようにデータを送れな い場合、そのデータを破棄することができる。パケットによっては、スポイル可 能とマーク付けできるものと、そうできないものがある。スポイラ・パケットは 、存在する場合、それに関連するスポイル可能パケットを削除する。この技術は たとえば、あるパケットがデルタ・フレーム・パケットで、他のパケットが完全 フレーム・パケットである、ビデオ用のバッファ管理方式の実施態様をサポート する。完全フレームが利用できる場合、選択されたデルタ・フレーム・パケット ・シーケンスを削除することができ、かつ削除しなければならない。

（ｉ　ｖ）論理装置 ある特殊な状況では、論理装置を使用してデータを交換するのが妥当である。単 一の論理装置が、複数のアプリケーションにポートを提供することができる。論 理装置は次いで、ポートの間でデータを移動することができる。この転送機構は 、同じ共用セット内のアプリケーションだけに制限されず、したがってチャネル に課された限界を解消する。しかし、論理装置は複数のノードをカバーすること はできない。さらに、必要なサービス品質サポートは、特定の論理装置によって 明示的に提供しなければならない。

サービス品質の折衝 アプリケーションは、サービス品質および帯域幅の折衝および制御に関して異な るニーズを有する。たとえば、以下のものが必要になることがある。

○事前に決定された一定のサービス品質、たとえばＧ、７１１音声 ○チャネル作成時に柔軟であり、その後は一定である要件、たとえばファイル転 送 Ｏチャネル資源の単一アプリケーション管理、たとえば、制限された帯域幅条件 の下で、すなわち、データ・トラツイツタを許可するためにビデオ品質を間欠的 に低下させなければならない場合に、アプリケーションがビデオ、音声、データ などの複数のデータ・タイプを伝達する。

Ｏチャネル資源のアプリケーション間管理、たとえば、一群のアプリケーション が、制限された帯域幅条件の下で複数のデータ・タイプを伝達し、該データ・タ イプの活動を、異なるタイプのデータ・トラフィックのための優先順位変更とし て調整する。

ある種のアプリケーションは、他のアプリケーションと通信するのに必要なチャ ネルの固定サービス品質要件を有する。

このような場合には、”ｃｒｅａｔｅ　ｃｈａｎｎｅｌ”要求を使用してチャネ ルを直接確立することができる。この要求上のパラメータは、受信側アプリケー ションと、チャネルと送信側ボートとの特性を識別する。資源が利用可能であり 、受信側アプリケーションが要求を受け入れる場合、チャネルが作成される。

一部のアプリケーションは、サービス品質要件がより柔軟であり、特定のノード に何が利用可能かを判定し、次いで”ｃｒｅａｔｅ　ｃｈａｎｎｅｌ”要求のパ ラメータを設定する際にこの情報を使用する必要がある。これは、ターゲット・ ノードを指定する”ｑｕｅｒｙ　ｒｅｓｏｕｒｃｅ’″コマンドを介して行う。

この後の“ｃｒｅａｔｅ−ｃｈａｎｎｅｌ”は、通信資源をめる競争がない場合 、前と等しいか前よりも低いサービス品質を要求して、要求を満たしてもらうこ とができる。

他のアプリケーションは、柔軟なサービス品質要件を有するが、多数のチャネル に対して指定を行う必要がある。このためには、アプリケーションが資源を予約 し、次いでこの予約されたプールから割振りを行う必要がある。

これは、資源セット識別子、サービス品質、およびターゲット・ノードを指定す る’ｃｌａｉｍ　ｒｅｓｏｕｒｃｅ”コマンドによって行う。このコマンドは、 その資源を予約して、指定された識別子と関連付ける効果を有する。この識別子 は次いで、その後の“ｃｒｅａｔｅ　ｃｈａｎｎｅｌ”コマンドで指定すること ができ、この場合、そのようなリザーブから資源が割り振られる。

ｑｕｅｒｙ　ｒｅｓｏｕｒｃｅ”コマンドを使用して、資源セット中の残りの資 源を判定することができる。

ある種のアプリケーションは、実行時にチャネル特性を動的に変更する必要があ る。たとえば、利用可能な帯域幅をチャネルごとに再割振りしなければならない 。これは、資源セット識別子を指定する”　ｃｈａｎｇｅ　ｃｈａｎｎｅｌ　” 要求を介して行うことができる。資源は、その識別子に関連する資源に与えられ 、あるいは後者の資源から取られる。この技術によって、たとえば、固定資源を アプリケーション間通信用に確保し、次いで、トラツイツタに応じて動的に再割 振りすることができる。たとえば、ビデオ帯域幅を一時的に削減して、より高速 のファイル転送を可能にすることができる。

資源セット識別子は、アプリケーション・インスタンスにローカルであり、１つ の特定のサービス品質に適した資源を含む。

ネットワーク アプリケーションは、チャネルを作成する際に、あるいは後でチャネルに割り振 るために資源を予約する際に、サービス品質特性を指定することができる。この 場合、チャネルは物理リンク上にマツプされる。論理チャネルを介してアプリケ ーションによって送信されるデータ・パケットは、リンクを介して送信されるデ ータ・フレームとして実施される。

リンクは交換リンクであれ固定リンクであれ、順序と、タイムアウト・パラメー タと、サービス品質特性によって特徴付けられる。順序は、サポート・システム が、適切なデータ送信特性があればリンクの選択が可能であると仮定して、リン クをデータ送信に使用しようとする順序を決定する。交換リンクであれ、固定リ ンクであれ、順序とタイムアウト・パラメータは初期設定ファイルに指定する。

任意選択でサービス品質特性を含むリンク記述は、サポート・システムの外部の リンク・データベースに記憶される。

サービス品質情報用のデフォルトは初期設定ファイルに含まれている。データベ ースは、サポート・プログラムによって呼び出される、導入先が供給した実行可 能ファイルによってアクセスされる。ディジタル・リンクに関連するサービス品 質パラメータは、スループット、待ち時間、ジッタ、フレーム・サイズ、フレー ム・エラー・レート、フレーム再伝送時間、圧縮ヒント、暗号化である。

アプリケーションが論理チャネルを介して必要とするサービス品質を特徴付ける ために使用される主要パラメータは、スループット、待ち時間、ジッタ、パケッ ト・サイズ、パケット・エラー・レート、暗号化、圧縮ヒント、優先順位である 。サポート・システムが、チャネルの間に資源競合が存在すると仮定して、その ノードにあるすべてのチャネルを介したデータ送信を実行しようとする順序を指 定するチャネル優先順位と、送信の損失またはエラーのために送る必要のない受 入れ可能なランダム比率のパケットを指定するパケット・エラー・レート（サポ ート・システムがこのような限定に従うという保証はない。ここでゼロを指定す ると、アプリケーションにあらゆる失敗が通知される）を除き、これらのパラメ ータの大部分は、対となるリンクを反映する。

上記の情報は、アプリケーション間通信にどのリンクを使用すべきかを判定する ために使用される。リンクのタイプやサービス特性などの情報を含むデータベー スは資源インタフェースを介してアクセスできるが、チャネル情報はアプリケー ションから得られる。サポート・システムは次いで、（ａ）異なるノードにある サポート・システムの間で制御情報を交換する必要と、（ｂ）リンクに関連する 順序値とを考慮に入れて、完全に満たされたチャネル要件と、完全に満たされた 利用可能リンク情報との一致に基づいて、使用するのにふされしいリンクを選択 する。

ソフトウェアおよびハードウェアの圧縮と暗号化が共にサポートされる。物理リ ンク上のハードウェア機構は、オプションの様々な組合せを、それぞれが特定の 転送特性に関連する異なる利用可能リンク・タイプとみなすことによって収容さ れる。ソフトウェア・ルーチンも使用できるが、特定の待ち時間要件およびジッ タ要件を設定していない場合は呼び出されない。

リンク情報を検索するために使用されるＲＬＩ呼出しも、必要に応じて、サポー ト・システムの外部で複雑な経路選択プロセスを実行できるようにするために、 すべての必要なチャネル・サービス品質特性を供給する。この機構を介して、外 部ルーチン自体が、適切な経路を決定し、その経路をサポート・システムに返す ことができる。この必要がある例は、送信コストが時刻によって変わることであ ろう。

チャネルをもつアプリケーションが相互に共用を行うとき、アプリケーションの 既存のチャネルが同じ名前の組合せチャネル・セットまたは直列化チャネル・セ ットに属する場合、サポート・システムは追加チャネルを作成する。そのボート にふされしいサービス品質によって、各送信側ボートからこのような新しいチャ ネルを確立することが試みられる。すなわち、暗示的に作成されたチャネルが、 そのポートから１つの既存のチャネルを介して送信する予定のデータ・パケット を首尾よく転送できるような特性をもとうとする。場合によっては、利用可能な 物理リンクの機能によって課される制限のために、そのような特性をもつチャネ ルを作成できないこともある。しかし、すべての場合に、チャネルが作成され、 チャネル機能が重要である可能性が大きい場合、それを照会することは、アプリ ケーション・プログラムの責任である。

ノードの間のチャネルは、単一の物理リンクまたは複数の直列接続リンクを介し て実現することができる。２つのノードの間に存在する物理接続を経路と呼ぶ。

ａ）永続ディジタル・ネットワーク サポート・システムは、専用リンクであれ、共用リンクであれ、交換リンクであ れ、永続リンクであれ、ノードの間のディジタル・リンクと共に動作する。共用 リンクは、帯域幅管理機能を使用しないかぎり、予測できない待ち時間特性およ び帯域幅特性を有する。そのような特徴によって、永続リンクには交換接続の特 性が多数与えられている。

ｂ）永続アナログ・ネットワーク サポート・システムは、以下の状況で、ディジタル通信と非常に類似した方法で アナログ通信をサポートする。

Ｏノードの間にアナログ・リンクが存在する。

Ｏ各ノードでの接続性および経路指定を、そのノードにあるシステムによって制 御することができる。

Ｏノードの間にディジタル制御チャネルが存在する。

アナログ・チャネルは、送信側アプリケーションによって確立される論理的に専 用の単一方向通信リンクであり、複数の受信側アプリケーションで終了すること ができる。このチャネルは、そのサービス品質特性によってディジタル・チャネ ルと区別することができる。このアナログ・チャネルを終了するボートは、アプ リケーションにデータを供給することも、アプリケーションからデータを受信す ることもできないので、空接続タイプを有する。標準チャネルまたは組合せチャ ネルだけしか確立できず、直列化チャネルおよび同期チャネルは許可されない。

論理装置は、オープンされると、アナログ・ボートを提供することができる。し たがって、ビデオ・プレーヤ装置をアナログ・ビデオの発信元として使用するこ とができ、ＡＰＩコマンドを介してアナログ・チャネルに接続することができる 。アナログ・チャネルとディジタル・チャネルの直接接続は許可されない。しか し、ある装置、たとえば符複合器は、オープンされるとアナログ・ボートとディ ジタル・ボートを共に提供し、そのような結合を有効化するために使用するこ交 換ディジタル・ネットワークは、接続の交換性の影響を受けずに、サポート・シ ステムによってノード間通信に使用することができる。資源インタフェースを介 してアクセスされた情報は、非活動状態の交換接続をいつ終了すべきかを決定す るためにシステムによって使用される。

交換ネットワークに接続された、ディジタル電話などの機器は、アプリケーショ ンによって２つの方法のうちの１つでアクセスされる。簡単な接続だけが必要な 場合、電話を仮想ノードで実行する仮想電話アプリケーションとみなすことがで きる。電話との接続は、仮忍ノードをターゲットとして指定する共用要求によっ て開始され、ローカル・ノードに関連する電話とリモート電話の間に電話呼出し が確立される。着信電話呼出しは同じように、すなわち共用要求として処理する ことができる。

電話を論理装置としてアクセスすることもできる。したがって、Ｉ　ＳＤＮ電話 装置をオープンして、関連する事象接続タイプまたはコマンド接続タイプの受信 側ボートおよび送信側ボートを提供することができる。ダイアリングおよびその 他の制御機能は、”ｓｉｇｎａｌ　ｐｏｒｔ″′コマンドを介して実施される。

ディジタル電話機器の間のサード・パーティ接続は同様に、該当する装置へのコ マンドによって影響を受ける。これは、ローカル・スイッチへのコマンドを介し て物理的に実施される。

データまたは経路指定を動的に修正する潜在的に活動状況の分岐制御装置、たと えばオーディオ・ビジュアル通信用のＣＣＩＴＴ勧告を実施するＭＣＵをアプリ ケーションに対する装置として使用することもできる。

ｄ）交換アナログ・ネットワーク 公衆交換網に接続されたアナログ電話およびその他の機器は、ディジタル電話と 同様に、仮想ノードで実行する仮想電話アプリケーションとして、または論理装 置を介してアクセスすることができる。ＰＳＴＮ電話論理装置をオープンして、 空接続タイプのボートを提供することができる。すなわち、該ボートはアプリケ ーションにデータを供給することも、アプリケーションからデータを受信するこ ともできない。

”ｓｉｇｎａｌ　ｐｏｒｔ’″コマンドは、装置を制御するために使用される。

ファースト・パーティ接続は、ローカル回線にダイアリング・トーンを挿入する モデム、サード・パーティ接続、およびローカル・スイッチへのコマンドを介す る多方向呼出しを介して実施することができる。

ｕｎａｗａｒｅアプリケーションとのインタフェースサポート・システムは、ｕ ｎａｗａｒｅアプリケーションを協調作業に使用できるようにする機能を提供す る。ａｗａｒｅアプリケーションは、ユーザ・インタフェース・ダイアログを供 給し、仮想装置を介して特定のｕｎａｗａｒｅアプリケーションと対話する。

この同じａＷａｒｅアプリケーションは次いで、リモート・ノードにある関連ａ ｗａｒｅアプリケーションと通信し、リモート・ユーザに情報を渡す。そのよう なアプリケーションの幾つかは、汎用ユーティリティとして含められている。

共通要件は、第１１図に示すように、ｕｎａｗａｒｅアプリケーションのアプリ ケーション・ウィンドウをリモート・ノードで表示することである。実施態様は 次のとおりである。ノードＸにあるａｗａｒｅアプリケーションＡｘがユーザと 対話して、ここではｕｎａｗａｒｅアプリケーションＵ、Ｉと仮定された必要な ウィンドウを識別する。Ａ８は次いで、適切なパラメータによってウィンドウ表 示論理装置をオープンする。この効果は、ウィンドウ・データのコピーを得るた めのボートを生成することである。Ａｘは、宛先ノードＹにあるａｗａｒｅアプ リケーションＡＹに至るチャネル上のボートにこれを接続する。ＡＹは次いで、 実際のウィンドウ論理装置をオープンして、作成されたボートを受信側チャネル ・ボートに接続する。データが、ノードの間を流れ、それ以上アプリケーション Ａ８にもＡＹにも干渉されずにＹで表示される。ウィンドウ論理装置オープン要 求で利用可能なオプションによって、アプリケーションはビット／ピクセル、更 新の頻度、データ・フォーマット（たとえば、テキスト、ビット・マツプ、およ び組込みポインタ位置のオプション）などのパラメータを指定することができる 。

ｕｎａＷａｒｅアプリケーションＵｘの共用ウィンドウ上のリモート・ポインタ を八〇およびＡＹで処理し、対話型データ・クラスに適したチャネルをセット・ アップすることができる。次いで、各ノード上の実際のポインタを使用して、共 用ウィンドウ中の機能を識別する。これは、指示したい各ユーザがポインタを共 用ウィンドウ内に移動する、などのアルゴリズムによって行うことができる。ポ インタが共用ウィンドウ中にあるとき、その座標が共用アプリケーションに送信 される。

次いで、組合わされた座標を使用して、ポインタが制御される。この結果、だれ であれ、最後にカーソルを移動した人が、すべてのリンクされたポイントを位置 決めすることになる。

リモート印刷とリモート・ファイル生成は同様に、論理装置を介して行う。印刷 の場合、発信元ノードにプリンタ・エミュレータ装置を設置する。この装置がユ ーザによってプリンタ装置として選択されると、その結果、プリンタ・データ・ ストリームがボートにリダイレクトされる。このストリームは次いで、ａｗａｒ ｅアプリケーションを介して、宛先ノードにある実際のプリンタ装置に接続され る。この汎用技術は、動的データ交換（ＤＤＥ）やシステム・クリップボードな どの他の機能の範囲で拡張される。

アプリケーションまたはシステムのリモート制御は直接には供給されない。しか し、リモート制御を実行するアプリケーションをＡＰＩより上位で実現すること ができ、Ｌａｋｅｓはグループ通信およびマルチメディア・データ送信機能を提 供する。

プログラミングの留意事項 ａ）プログラム呼出しタイプおよび構造ＡＰＩへのプログラム呼出しは一般に、 要求、指示、応答、確認シーケンスになる。サービスを必要とするアプリケーシ ョンＡは、適切なパラメータを供給してそのサービスを要求する。要求は通常、 他のアプリケーションＢにその要求を認識させることを必要とする。このための 機構は、アプリケーションＢで指示として出現する非送信請求事象である。この 指示事象に対してＢが取るアクションは、適切なデータをもつ応答としてサポー ト・システムに与えられる。システムは、この情報を確認事象として再びアプリ ケーションＡに渡す。

これを、チャネルにボートを追加する上で関与するシーケンスの例を使用して第 １２図に示す（図を単純にするために、パラメータはいっさい示さない）。

ＡＰＩ呼出しは、特定の機能に応じて、同期呼出しでも非同期呼出しでもよい。

同期呼出しは、要求が完了すると制御を戻す。非同期呼出しはただちに制御を戻 す。アプリケーションが非同期呼出しの進行を監視できるようにするために、こ れらの呼出しは参照識別子を含む。この識別子は、要求が満たされ、状況を得る ために照会を発行できるようになるまで、有効である。この同じ識別子を使用し て、保留中の要求を取り消すこともできる。呼出しはすべて、呼出し状況を示す リターン・コードを返す。

ｂ）アドレス可能性 アプリケーションは、ノード名を使用してノードへのアドレス可能性を要求する 。この名前はまず、それを修正するオプションを有するローカル呼出しマネージ ャに渡される。その結果得られる名前は次いで、接続性情報を判定するためにサ ポート・システムによって使用される。接続性情報の判定は、資源インタフェー スを使用する、外部に保持されたネットワークおよびユーザ・データベースへの アクセスを必要とする。したがって、サポート・システムは、第２図の資源イン タフェース２９を介するネットワーク構成への照会を介してその名前に関する物 理アドレス可能性を判定する。このノード名の分解能を反映するノード・ハンド ルがアプリケーションに返される。１つのアプリケーションから他のアプリケー ションへのアドレス可能性にはアプリケーション名の分解能が必要である。両方 のアプリケーションが同じノードにある場合、ローカル呼出しマネージャがこの 分解能を実行することができ、そうでない場合は、両方の呼出しマネージャが関 与しなければならない。この分解能の結果、アプリケーション・ハンドルによっ て、ターゲット・アプリケーションが発信元アプリケーションに対して識別され る。アプリケーション名を使用する呼出しは常に、分解能のために呼出しマネー ジャに渡される。アプリケーション・ハンドルを使用する呼出しは、指定された アプリケーションに直接向かう。

アプリケーションがチャネルを作成するとき、チャネル・ボートへのアドレス可 能性が、ボート・ハンドルを返すシステムを介して提供される。同様に、論理装 置をオープンすると、装置ボート・ハンドルが得られる。

すべてのハンドルは、使用する側のアプリケーションに特有のものであるが、他 のアプリケーションまたはノードに渡される場合は有効でな（なる。

Ｃ）事象クラスおよび事象ハンドラ ＡＰＩ要求は、事象および呼出し制御を援助するために提供される。”ｂｅｇｉ ｎ　ｍｏｎｉｔｏｒ″′要求によって、アプリケーションはノードでの要求およ び事象を監視することができる。監視の範囲は、以下のものの１つから監視クラ スを選択することによって制御される。

Ａｌｌ：すべでの事象またはＡＰＩ呼出しＡｐｐｌｉｃａｔｉｏｎ　Ｓｉｇｎａ ｌｌｉｎｇ　：信号事象／ＡＰＩＡＰＩ呼出ｌｊｍａｎａｇｅｒ　：呼出しマネ ージャ事象／ＡＰＩ呼出しＤａｔ、ａ：データ送信事象／ＡＰＩ呼出しＤｅｖｉ ｃｅ　：装置事象／ＡＰＩＡＰＩ呼出ｎ１ｔｏｒ　：モニタ事象／ＡＰＩ呼出し Ｐｏｒｔ　：ボートおよびチャネル事象／ＡＰＩ呼出しＰｒｏｆｉｌｅニブ０７ フイル事象／ＡＰＩ呼出し５ｈａｒｅ　：共用および非共用事象／ＡＰＩ呼出し ５ｙｎｃｈｒｏｎｉｓａｔｉｏｎ　：同期事象／ＡＰＩＡＰＩ呼出ｋｅｎニド− クン事象／ＡＰＩ呼出し監視の範囲は事象クラス・レベルまたはＡＰＩクラス・ レベルで制御される。事象は、データがあってもなくても監視することができる 。監視は、”ｅｎｄ−ｍｏｎｉ　ｔｏｒ”コマンドによって終了する。アプリケ ーションは、”ｅｎａｂｌｅ　ｅｖｅｎｔｓ”コマンドおよび”ｄｉｓａｂｌｅ 　ｅｖｅｎｔｓ”コマンドを使用して、どの事象を受信すべきかも決定する。有 効な事象クラスは以下のとおりである。

Ａ１１：すべての事象 Ｄｅｖｉｃｅ　：装置事象 Ｐｏｒｔ　：ポートおよびチャネル事象Ｐｒｏｆｉｌｅ：プロファイル事象また はＡＰＩ呼出しＳｈａｒｉｎｇ　：共用要求事象またはＡＰＩ呼出しデフォルト の事象ハンドラは、アプリケーションを介して明示的に処理されないすべての事 象に対する応答を生成する。

事象は、登録された事象ハンドルによって処理される。

ａＷａｒｅアプリケーションには４つのタイプが存在できる。

Ａｐｐｌｉｃａｔｉｏｎ　：これは、一時事象ハンドラであり、ａｗａｒｅアプ リケーションの一般動作に関連する主な事象を処理する。

この事象ハンドラは、呼出しマネージャを含むすべてのａｗａｒｅアプリケーシ ョンに存在しなければならない。

Ｃａ１ｌ　ｍａｎａｇｅｒ　：これは幾分特殊であり、アプリケーション登録、 名前分解能、遮断要求、受動ノード、呼出しマネージャ転送、およびグローバル ・トークン状況に関する事象を処理する。この事象ハンドラがすべての呼出しマ ネージャになければならない。

Ｐｏｒｔ、ｅｖｅｎｔ　ｂａｎｄｌｅｒ　：複数のボート事象ハンドラが存在で き、それぞれがデータ通信関連事象を処理する。

Ｍｏｎ１ｔｏｒ　：これは任意選択で存在し、すべての事象監視を処理する。

ｄ）その他のプログラミング機能 データ・トラフィックを監視し、あるいはデータを処理するように、すべてのチ ャネル・ボートをユーザ出口と関連付けることができる。送信側ボートの場合、 ユーザ出口は、データが受信側ボートに送信される直前に呼び出される。受信側 ポートの場合、ユーザ出口は、データが受信側ポートに到着した直後であるが、 受信側アプリケーションに提供される前に呼び出される。データはユーザ出口に 移動しなければならないので、接続されているボート上にユーザ出口ルーチンを 指定すると性能に影響が及ぶことがある。

アプリケーションが状況情報を追跡しな（て済むように、完全な１組の照会が提 供されている。

アプリケーション・プログラム・デバッグは、最初に単一のノードで協調アプリ ケーションを動作させることによって簡単にすることができる。これによって、 プログラム開発の初期段階で物理ネットワークが不要になる。

ＡＰＩより下位にユーザ・インタフェースは存在しない。

すべてのユーザ対話は、アプリケーション・プログラム、または資源インタフェ ースを介して要求を実行するコードの責任である。

ユーティリティ コマンド・インタフェースを介してアクセス可能な共通機能を提供することによ って、エンド・ユーザに有用な機能をただちに提供し、新しい協調アプリケーシ ョンを開発するのに必要なプログラミング作業を削減するために、多数の事前に プログラムされたユーティリティが提供されている。

すべてのユーティリティは交換可能なアプリケーション・プログラムである。提 供したユーティリティの構造を第１３図に示す。供給したユーティリティは、プ ログラム・グループとしてインストールされ、協調する一連のアプリケーション として設計されている。主要なユーティリティ機能は、ユーザが直接呼び出すだ けでなく、”ｓｉｇｎａｌ”コマンドによって他のアプリケーション・プログラ ムから呼び出すこともできる。

アドレス・ブック・ユーティリティ１００によって、エンド・ユーザはディレク トリおよび接続性情報を追加し、削除し、更新することができる。データは、標 準プログラムで容易に編集される簡単なファイル構造に記憶される。ただし、他 の潜在的により広範囲で複雑なアドレス・データベースとのインタフェースをと るための機構が提供されている。ユーザ・データをフォーン・ブックという論理 集合にグループ化することができる。ユーティリティ・インタフェースは直接、 呼出しマネージャとのインタフェースをとる。また、資源インタフェースを介し て照会に応答する。

ｉｌ）呼出しマネージャ 呼出しマネージャ・ユーティリティ１０１は、呼出しの概念を実施する。呼出し とは、一群のユーザが共用アプリケーションを使用することによって協調するこ とを言う。いつでも複数の呼出しが存在でき、ユーザは複数の同時呼出しに参加 することができ、同じアプリケーションを複数の呼出しで実行することができる 。たとえば、ユーザＡ、Ｂ、Ｃは文書を検討するために呼出しＸに参加すること ができる。すべてのユーザが相互に音声通信を使用することができ、ＡとＢはビ デオ・リンクも、ＡとＣは共用チョークボードも有することもできる。一方、Ａ 、Ｂ、Ｄは第２の文書を検討するために第２の呼出しｙに参加することができる 。ＡとＤはチョークボードを、ＢとＤは音声リンクを使用する。

ＡＰＩには呼出しの概念が存在しないが、アプリケーション共用セットを介して 呼出しマネージャによって実施される。

このサポートを提供することによって、呼出しセットアツプや切断にａＷａｒ８ アプリケーションを関与させる必要がなくなり、呼出し管理とアプリケーション ・プログラミングが明確に分離される。呼出しマネージャは、エンド・ユーザが アドレス・ブックから名前を選択し、分岐呼出しを論理的に確立するためのダイ アログを提供する。パーティを動的に追加し、削除することができる。提供され るオプションは、自動応答および呼出し禁止を含む。ある呼出しが現行活動呼出 しとみなされ、共用アプリケーション・セットは通常、呼び出されるところの呼 出しに追加される。現行活動呼出しは、他の呼出しがセットアツプされている間 は背景に移される。

このユーティリティは、呼出し中のユーザのために以下の機能を実施する。

○既存のアプリケーション・ウィンドウをスナップショットとして、または連続 的に直接ミラーリングし、システム・ボインティング・デバイスをリモート・ポ インタとしてイネーブルにする。

○システム・クリップボード・サポート。すなわち、あるノードにあるシステム ・クリップボードの内容を任意選択で他のノードで共用し、あるいは表示する能 力○異なるノードしあるアプリケーションの間に確立できるリモートＤＤＥリン ク Ｏ他のノードにあるプリンタへの印刷のりダイレクトｉｉ）チョークボード チョークボード１０３は、２つのイメージ・プレーンをもつ共通描画領域を実施 する。この描画領域には、呼出し中のすべてのユーザがアクセスできる。背景プ レーンは、ビットマツプ・ファイル、システム・クリップボード、またはアプリ ケーション・ウィンドウの内容からロードすることができる。前景プレーンは、 一連の簡単なテキストおよびグラフィクス・ツールを使用する対話型注釈に使用 することができる。

チョークボード」二のリモート・ポインタもサポートされる。

１ｉｉ）ファイル転送 ファイル転送１０４によって、呼出し中のユーザの間のファイルの送信が可能に なる。１つまたは複数のファイルを転送することができ、ファイルをコメントと 共に送信することができ、元のファイル名を宛先が利用できるようになる。受信 側ノードはファイル受信およびファイル命名を完全に制御メツセージ行１０５は 、呼出し中のユーザの間でテキスト・データを直接共用できるようにする。複数 の同期ユーザが許可され、各参加者はすべての交換されるメツセージを同じシー ケンスで見る。メツセージ・ユーティリティは、呼出しセット・アップおよび終 了、ファイル転送などの、呼出し時の活動も記録する。実際の実施例では、この ユーティリティを呼出しマネージャの一部として提供している。

■）ビデオ／音声リンク このユーティリティ１０６によって、呼出し中のユーザの間にビデオおよび音声 リンクを確立することができる。利用可能な厳密な機能は、物理ネットワークの 機能とワークステーションのハードウェア・サポートによって異なる。

規格 全体的なアーキテクチャは、広範囲の協調アプリケーションをサポートするもの である。インタフェースは、実施できるアプリケーション・モデルの範囲に対し て重大な制限を課さないように、できるだけ高いレベルにセットされている。

関与する透過ネットワークの性質は完全にＡＰＩより下位に隠されている。これ は、アプリケーションがネットワーク経路指定（たとえば直接または間接）と関 与するネットワーク・タイプ（たとえば、単一リンクまたは複数リンク、交換接 続または固定接続）を完全に知っていることを意味する。この手法の結果、たと えば特定の通信サービス品質をめる要求が失敗する恐れがあることを予期してア プリケーションを書かなければならない。なぜなら、基礎ネットワークが必要な 機能を有していないことがあるからである。

サード・パーティ・アプリケーションが他のアプリケーションの代わりに動作す ることを要求できるようにエージェント原理が実施されている。これによって、 呼出しマネージャ・アプリケーション、電話アプリケーション、および交換アプ リケーションを開発することができる。現在の技術の状態では、アナログ・ネッ トワークおよび装置をサポートすべきである。アプリケーションの移行を容易に するために、アナログ・ネットワークをディジタル・ネットワークのように扱う ことが試みられている。

ＡＰＴレベルで、使用される主要概念の１つは、アプリケーション共用セットの 概念である。アプリケーションは、他のアプリケーションと協調するとみなされ 、この協調のための機構は、アプリケーションが、指定された共用セットに相互 に参加することである。そのようなアプリケーション共用セットの肝要な点は、 すべてのセット・メンバが他のすべてのメンバの状況に関する情報を受信するこ とである。セットに参加することは、アプリケーションが関心をもつものを宣言 する方法である。これに対し、呼出しの概念は、ＡＰＩよす上位、特に呼出しマ ネージャに存在する。異なる呼出しマネージャが異なる呼出しモデルを有するこ とができる。

アプリケーション共用セットの他に、チャネルもアーキテクチャの基本概念であ る。回報通信と２方向通信を共に効率的にサポートするための基礎通信ビルディ ング・ブロックとして１方向チヤネルを使用している。チャネルは、送信側アプ リケーションによって確立され、受信側アプリケーションによって受け入れられ る。というのは、データをどのように送信すべきかを示すデータの特性を知って いるのは送信側アプリケーションだけだからである。２つのアプリケーションは 共に、それぞれのポートに供給し、あるいは前記ボートから受信すべきフォーマ ットを独立に制御することができる。

各種のデータ・フロー用の複数の論理チャネルによって、サポート・システムは 基礎転送ネットワークにトラフィックを正しく割り振ることができる。さらに、 サポート・システムは、データが、それぞれが別々に記述された別々の同種フロ ーで他のアプリケーションに提供されるようにする。このようにアプリケーショ ン間のトラフィックを別々のデータ・タイプに分割することによって、サポート ・システムはデータ変換機能を提供することができる。

チャネルの接続およびウェルドによって、アプリケーションがもはやデータの移 動に関与しなくなるように、データの転送をＡＰＩより下位にすることができる 。サポート・システムは、場合によっては、そのノードにある非常に低いレベル での接続を有効化するか、フローの経路をそのノードに向かわないように変更す る接続を有効化するかのオプションを有する。

サポート・システム・アーキテクチャは、異なるコンピュータ・プラットフォー ムの間の相互作用を許可し、様々な通信ネットワークを介して動作し、関連する 通信およびデータ規格をサポートするように設計されている。

データ・トラフィックを同種データの論理１方向フローに分けることによって、 混合ネットワーク上へのマツピングが簡単になり、ノードの間で異なる機能の複 数の物理リンクを使用できるようになる。データ多重化は、アプリケーションよ り下位で処理され、基礎転送機構に応じて異なる方法で、たとえば、各論理フロ ーをそれぞれの物理リンクに割り振ることと、サポート層中のすべてのデータを 多重化することを組み合わせ、あるいは多重化の態様を装置ドライバに任せるこ とによって、実施することができる。この手段によって、複数のチャネル、１ｓ ｏ−ＬＡＮまたは１ｓｏ−Ｅｔｈｅｒｎｅｔ　１あるいはＣＣＴＴＴ　Ｈ３２０ 勧告を使用するＩ　ＳＤＮを介して、音声、ビデオ、およびデータ・トラフィッ クを送信することができる。サービス品質要件は、必要な転送機能に対して条件 を課す。したがって、音声およびビデオには通常、優先順位および帯域幅管理を 伴う方式を介して実施される、等時機能をもつ専用物理リンクまたは共用リンク が必要である。

データ構成要素が別々に提供され、該構成要素の性質およびフォーマットが独立 に得られるので、チャネルによって提供される別々の論理データ経路は、該経路 に関連するデータ・タイプと共にアプリケーション間動作を容易にする。サポー ト・システムがネットワークでデータ変換を実行できるため、この機構を介して 、音声、ビデオ、イメージ、ファイル転送、およびコード化データに関する広範 囲の既存の規格をサポートすることができる。システムは、リモート・プリンタ 、カーソル、ジエスチャなどの、協調アプリケーションで一般に使用される対話 オブジェクト用の別々のデータ・クラスも提供する。

ＡＰ丁コマンドの概要 以下で、ＡＰＩ呼出しで提供される主要な機能について詳細に説明する。この趣 旨は適用範囲の概要を述べることにすぎないので、実際の呼出しの構文およびパ ラメータについては説明しない。

ＡＰＩ機能要求 セツションおよびアプリケーション共用ｃａｎｃｅｌ　ｒｅｑｕｅｓｔ　：前の 非同期要求がまだ満たされていなＮ場合にその要求を取り消す。

ｄｅｒｅｇｉｓｔｅｒ　ａｐｐ　：アプリケーション・インスタンスによって、 ＡＰＩの使用を終了するために発行される。

１ａｕｎｃｈ　ａｐｐ　：あるアプリケーションによって、他のアプリケーショ ンを呼び出すために発行される。

ｒｅｇｉｓｔｅｒ　ａｐｐ　：　’Ｑ行側アプリケーション・インスタンスをワ イヤとして識別し、アプリケーション事象ハンドラを確立する。

ｓｅｔ　ｃａｌｌ−ｍａｎａｇｅｒ　：そのノード用の呼出しマネージャを識別 し、呼出しマネージャ事象ハンドラを確立する。

５ｈａｒｅ−ａｐｐ　＋アプリケーション・インスタンスが、あるアプリケーシ ョンと他のアプリケーションの共用を要求するために発行する。

ｓｈｕｔｄｏｗｎ　ｎｏｄｅ　：アプリケーション・インスタンスによって、そ のローカル・ノードにあるサポート・システムの遮断を要求するために発行され る。

ｕｎｓｈａｒｅ　ａｐｐ　：アプリケーション・インスタンスによって、あるア プリケーションと他のアプリケーションの共用を終了するために発行される。

装置およびボート ａｄｄ　ｃｈａｎｎｅｌ　：指定されたアプリケーション・インスタンス中で、 指定された送信側ボートに他のチャネルを追加する。

ｃｈａｎｇｅ　ｃｈａｎｎｅｌ　：指定されたチャネル特性を変更する。

ｃｈａｎｇｅ　ｄｅｖｉｃｅ−ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ　：指定された 装置特性を変更する。

ｃｈａｎｇｅ　ｐｏｒｔ　：指定されたボート特性を変更する。

ｃｌａｉｍ　ｒｅｓｏｕｒｃｅ　：特定のサービス品質に関連する資源の資源マ ネージャに対する呼出し ｃｌｏｓｅ　ｄｅｖｉｃｅ　ｐｏｒｔ　：定義された装置上の関連するボートを クローズする。

ｃｏｎｎｅｃｔ　ｐｏｒｔｓ　：指定された受信側ボートを指定された送信側ボ ートに接続する。

ｃｒｅａＬｅ　ｃｈａｎｎｅｌ　：発行側アプリケーションにある送信側ボート と、指定されたターゲット・アプリケーションにある受信側ボートから成るデー タ送信チャネルを作成する。

ｄｉｓｃｏｎｎｅｃｔ　ｐｏｒｔｓ　：指定された送信側ボートから指定された 受信側ボートを切断する。

ｏｐｅｎ　ｄｅｖｉｃｅ−ｐｏｒｔ　：定義された装置上のボートをオーブンす る。

ｒｅｍｏｖｅ　Ｃｈａｎｎｅｌ　：指定された受信側ボートと指定された送信側 ボートに関連するチャネルを削除する。

ｒｅｑｕｅＳｔ　ｒｅｓｏｕｒｃｅ　：特定のサービス品質に関連する資源の資 源マネージャに対する照会 ｒｅｓｕｍｅ　ｐｏｒｔ　：指定されたボートを介してデータ送信を再開する。

ｓｉｇｎａｌ　ｐｏｒｔ　：指定されたボートを介して制御文字列を送信する。

５ｕｓｐｅｎｄ　ｐｏｒｔ　：まだ受信されていないデータをドレーンまたはフ ラッシュした後に、指定されたボートを介するデータ送信を中断する。

ｗｅｌｄ　ｃｏｎｎｅｃｔｉｏｎ　：指定された受信側ボートと送信側ボートの 接続を永続的にする。

データ送信および受信 ｒｅｃｅｉｖｅ　ｃｌａｔａ　：指定された受信側コマンド・ボートからデ−タ を受信する。

５ｅｎｄ　ｄａｔａ　：指定された送信側ボートを介してデータを非同期的に送 信する。様々な送信肯定応答を要求することができる。

ｓｉｇｎａｌ　：サポート・システムが確立した制御チャネルを介して、サポー ト・システムまたはアプリケーションが定義した制御データを、指定されたアプ リケーション・インスタンスに送信する。

ｓｉｇｎａｌ　ａｐｐ　ｗｉｔｈ　ｒｅｐｌｙ：サポート・システムが確立した 制御チャネルを介して、サポート・システムまたはアプリケーションが定義した 制御データを、指定されたアプリケーション・インスタンスに送信し、応答デー タを返す。

５ｔａｒｔ−ｓｙｎｃ　：指定されたチャネル・セットに関連する受信側ボート を介して受信されたデータの同期を開始する。

５ｔｏｐ　５ｙｎｃ　：指定されたチャネル・セットに関連するすべての受信側 ボートのデータの同期を停止する。

トークン管理 ｇｅｔ−ｔｏｋｅｎ　：指定されたグローバル・トークンまたはアプリケーショ ン・トークンをただちに、排他的に保持し、あるいは共用することを要求する。

ｇｉｖｅ　ｔｏｋｅｎ：指定された要求元に、指定されたトークンを与える。

ｑｇｅｔ　ｔｏｋｅｎ　：指定されたグローバル・トークンまたはアプリケーシ ョン・トークンをただちに、排他的に保持し、あるいは共用することを要求し、 トークンが得られない場合は、現所有者が維持している要求待ち行列への参加を 要求する。

ｒｅｃｌａｉｍ　ｔｏｋｅｎ　：指定されたアプリケーション・インスタンスが 保持している指定されたトークンをただちにトークンの現所有者に返すことを強 制する。

ｒｅｆｕｓｅ　ｔｏｋｅｎ　：指定された要求元に、指定されたトークンを与え ることを拒否する。

ｒｅｌｅａｓｅ　ｔｏｋｅｎ　：指定された保持しているトークンを現所有者に 返す。

ｒｅｔｕｒｎ−ｔｏｋｅｎ　：指定されたトークンを保持している指定されたア プリケーションがトークンをできるだけ早く現所有者に返すことを要求する。

ｓｅｔ　ｔｏｋｅｎ　ｏｗｎｅｒ　：指定されたアプリケーション・インスタン スに指定されたトークンの所有者をセットする。

事象制御 ｂｅｇｉｎ　ｍｏｎｉｔｏｒ　：　Ａ　Ｐ　Ｉ呼出しの各オカレンスを識別する 特殊監視事象を発生させ、または指定された監視事象ハンドラに標準事象を提供 する。

ｄｅｆａｕｌｔ　ｅｖｅｎｔ　ｈａｎｄｉｅｒ　：アプリケーション・プログラ ムが明示的に処理することを所望しないすべての事象に対してデフォルト応答を 返す。

ｄｉｓａｂｌｅ−ｅｖｅｎｔｓ　：指定された事象クラスの事象が発行側アプリ ケーション・インスタンスの事象ハンドラに渡されるのを停止する。

ｅｎａｂｌｅ　ｅｖｅｎｔｓ　：指定された事象クラスの事象が発行側アプリケ ーション・インスタンスの事象ハンドラに渡されるようにする。

ｅｎｃｊｍｏｎｉＬｏｒ　：　Ａ　Ｐ　Ｉ呼出しの各オカレンスを識別する特殊 監視事象、または提供中の標準事象を停止する。

プロファイル管理 ｒｅａｄ　ｐｒｏｆｉｌｅ　ｓｔｒｉｎｇ　：プロファイル・ファイルの指定さ れたセクション中の指定されたキーワードの文字列を返す。

ｗｔｒｉｔｅ　ｐｒｏｆｉｌｅ　ｓｔｒｉｎｇ：プロファイル・ファイルの指定 されたセクション中の指定されたキーワードに文字列をコピーする。

ＡＰＩ照会 ｑｕｅｒｙ−ａｄｄｒｅｓｓ　：指定された共用セットに属するアプリケーショ ン・インスタンスの完全なフル・アドレスを返す。

ｑｕｅｒｙ　ａｐｐｌｉｃａｔｉｏｎ　５ｔａｔｕｓ　：アプリケーションの状 況（ｕｎａｗａｒｅ、　ａｗａｒｅ、または呼出しマネージャ）を返す。

ｑｕｅｒｙ　ｃｈａｎｎｅｌ　ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ　：指定された 送信側ボートおよび受信側ボートに関連するチャネルのチャネル特性を返す。

ｑｕｅｒｙ　ｃｈａｎｎｅｌ　ｓｅｔ　：指定されたチャネル・セット中のすべ てのボートのハンドルを返す。

ｑｕｅｒｙ−ｄｅｖｉｃｅ　ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ　：指定された装 置の装置特性を返す。

ｑｕｅｒｙ　ｄｅｖｉｃｅ　５ｔａｔｕｓ　：指定された装置の状況を返す。

ｑｕｅｒｙ　ｍｏｎｉｔｏｒ　：現在モニタ事象ハンドラに渡されている機能ま たは事象のクラスを返す。

ｑｕｅｒｙ　ｐｏｒｔ　ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ　：指定されたボート の特性を返す。

ｑｕｅｒｙ　ｐｏｒｔ　５ｔａｔｕｓ　：指定されたボートの状況を返す。

ｑｕｅｒｙ　ｒｅｓｏｕｒｃｅ　：指定された資源セット中で利用可能な資源を 返す。

ｑｕｅｒｙ　ｓｈａｒｉｎｇ　ｓｅｔ　：アプリケーション・インスタンス用の 共用セット識別子を返す。

ｑｕｅｒｙ　ｔｏｋｅｎ　ｈｏｌｄｅｒ　：　トークンの所有者（アプリケーシ ョン・トークンのみ）および保持者を返す。

ｑｕｅｒｙ　ｔｏｋｅｎ　５ｔａｔｅ　：指定されたトークンの状態を返す。

ＡＰＩ事象 呼出しマネージャ事象 ＡＰＰ　ＤＥＲＥＧＩＳＴＥＲＥＤ　：アプリケーション・インスタンスがＡＰ Ｉの使用を終了するときの、ローカル呼出しマネージャへの事象。

ＡＰＰ　ＲＥＧＩＳＴＥＲＥＤ　：アプリケーションがＡＰＩの使用を初期設定 するときの、ローカル呼出しマネージャへの事象ＣＡＬＬ　ＭΔＮＡＧＥＲＥＲ ＲＯＲ：呼出しマネージャに影響を及ぼすエラーが発生した。

ＣΔＬＬ　ＭΔＮΔＧＥＲＲＥＱＵＥＳＴ　：他のローカル・アプリケーション がｓｅｔ　ｃａｌｊｍａｎａｇ、ｅｒ機能要求を発行したことを示す、ローカル 呼出しマネージャへの事象 Ｎ０ＤＥ　５ＨＵＴＤＯＷＮ　ＲＥＱＵＥＳＴ　：サポート・システムの遮断を める要求 ＰＡＳＳＩＶＥ−ＮＯＤＥ　ＲＥＬＥＡＳＥＤ　：　／　−１’カ受動要求ヲサ ポートテキルようにするために割り振られた資源の解除をめる指示。

ＰＡＳＳＩＶＥ−ＮＯＤＥ　ＲＥＱＵＥＳＴ　：　／　−トカ受動要求ヲサポー トスルタめに資源を割り振ることをめる要求 ５ＨＡＲＥ　ＲＥＱＵＥＳＴ　：指定されたアプリケーションとの共用をめる要 求 ＴＯＫＥＮ　５ＴＡＴＵＳ　ＲＥＱＵＥＳＴ　ニゲローバル・トークンの状況を める要求 アプリケーション事象 ＡＰＰ　５ＩＧＮＡＬ　：信号が受信された。

ＡＰＰ　５ＩＧＮＡＬ　ＲＥＪＥＣＴＥＤ　：信号が拒否された。

ＡＰＰ　５ＩＧＮΔＬ　ＷＩＴＨＲＥＰＬＹ　：　ｓｉｇｎａｌ　ｗｉｔｈ　ｒ ｅｐｌｙが受信された。

八ＰＰ　５ＩＧＮＡＬ　ＴＲＡＮＳＦＥＲＲＥＤ　：信号が転送された。

ＡＰＰ−ＵＮＳＨＡＲＥ　ＲＥＱＵＥＳＴ　：受信側がアプリケーション共用セ ットを抜けることをサード・パーティ・アプリケーションが要求した。

ＡＩ’Ｐ−ＵＮＳＨＡＲＥＤ　：発行側がアプリケーション共用セットを抜ける という通知が受信された。

八ＰＰ−ＥＲＲＯＲ：関連アプリケーション・エラーが検出された。

Ｎ０ＤＥ　５ＨＵＴＤＯＷＮ　：遮断が開始された。

ＰＯＲＴ　ＲＥＭＯＶＥＤ　：ボートが削除されたことの確認ＰＯＲＴ　ＲＥＱ ＵＥＳＴ　：受信側ボートの追加をめる要求ＲＥＳＯＵＲＣＥ−ＣＬＡＩＭ　： アプリケーションがサービス品質資源を請求すると必ずレイズされる。

ＲＥＳＯＵＲＣＥ　ＲＥＱＵＥＳＴ　：アプリケーションがサービス品質資源を 要求すると必ずレイズされる。

ＰＲＯＦＩＬＥ　ＣＨＡＮＧＥＤ　：　ＬＡＫＥＳ、　ＩＮ■ファイルまたはＬ ＡＫＥＳＱＯ３，ＩＮＩファイルの変更をめる指示 ５ＨＡＲＥ　ＣＯＮＦＩＲＭＥＤ　：共用要求が処理されたことの確認が受信さ れた。

５ＨＡＲＥ　ＲＥＪＥＣＴＥＤ　：共用要求が拒否された。

５ＨＡＲＥ　ＲＥＱＵＥＳＴ　：共用要求が受信された。

５ＨＡＲＥ−ＴＲＡＮＳＦＥＲＲＥＤ　：共用要求が転送された。

ＴＯＫＥＮ　ＣＡＮＣＥＬ　ＲＥＱＵＥＳＴ　：待機中のトークン要求の取消し をめる要求が受信された。

ＴＯＫＥＮ　ＧＩＶＥＮ　：要求元にトークンが与えられた。

ＴＯＫＥＮ　ＱＲＥＱＵＥＳＴ　：　ｌ−−クンを保持し、あるいはトークンが 得られない場合は待ち行列に参加することをめる要求ＴＯＫＥ）ｊＲＥＣＬＡＩ ＭＥＤ　：　トークンが所有者によって取り去られた。

ＴＯＫＥＮ　ＲＥＣＬΔＩＭＥＤ　ニド−クンが所有者によって取り去られた。

ＴＯＫＥＮ　ＲＥＦＵＳＥＤ　：　トークンをめる要求が拒否された。

ＴＯＫＥＮ　ＲＥＱＵＥＳＴ　：　トークンの保持をめる要求ＴＯＫＥＮ　ＲＥ ＴＵＲＮ　ＲＥＱＵＥＳＴ　：　）−−クンの所有者が、トークンをできるだけ 早く返すことを要求している。

装置事象およびボート事象 ＣＨＡＮＮＥＬ　ＣＨＡＮＧＥＤ　ニ一部のチャネル特性が変更された。

ＣＨＡＮＮＥＬ　ＣＯＮＦＩＲＭＥＤ　：新しいチャネルが作成された。

ＣＨＡＮＮＥＬ　ＤＥＳＴＲＯＹＥＤ　：チャネルが破壊された。

ＣＨＡＮＮＥＬ−ＲＥＪＥＣＴＥＤ　：チャネルが作成されなかった。

Ｃ０ＮＮＥＣＴｌ０Ｎ　ＷＥＬＤＥＩ）　：ウエル接続通知が受信された。

ＤＡＴＡ−ＡＶΔＩＬＡＢＬＥ　：受信側ボートでデータが利用可能である。

ＤＡＴＡ　ＣＯＮＦＩＲＭＥＤ　：データ送信の確認またはデータ送信の進行の 推定が受信された。

ＤＡＴ／ｊＲＥＱＵＥＳＴＥＤ　＋送信側ボートからデータが要求されている。

ＤＥＶＩＣＥ−ＩＮＦＯＲＭＡＴＩＯＮ　：装置情報を供給する予定のアプリケ ーション・インスタンスの送信側ボート事象ハンドラにレイズされる事象 ＰＯＲＴ　ＥＲＲＯＲ：ボート・エラーが検出された。

ＰＯＲＴ　ＲＥＳＬＩＭＥ　ＲＥＱＵＥＳＴ　：ポート再開要求が受信′された 。

ＰＯＲＴ　５ＩＧＮＡＬＬＥＤ　：信号ボート事象が受信された。

ＰＯＲＴ　５ＵＳＰＥＮＤ−ＲＥＱＵＥＳＴ　：ボート中断要求が受信された。

ＰＯＲＴ　５ＹＮＣＲＥＱＵＥＳＴ　：同期制御の調整をめる要求が受信された 。

モニタ制御事象 ＥＶＥＮＴ　ＭＯＮＩＴＯＲＥＤ　：機能要求および事象活動の通知が受信され た。

チャネル、ボート、およびリンクの特性チャネルの特性 以下のパラメータは、チャネルと関連しており、ｃｒｅａｔｅ−ｃｈａｎｎｅｌ 要求およびａｃｉｄ　ｃｈａｎｎｅｌ要求で設定される。

ｑｕａｌｉｔｙ　ｏｆ　５ｅｒｖｉｃｅ　：信号タイプ（アナログまたはディジ タル）スループット 待ち時間 ジッタ 遅延 優先順位 サービス品質特性は、ＬＡＫＥＳＱＯ３，ＩＮＩファイル中のデータ・タイプお よびサブタイプを介して関連付けられるが、明示的に指定することができる。こ の特性は、未定義のままにすることができる。これによって、データがチャネル を介して送信されるときに、動作特性が、利用可能な資源に依存するチャネルを 作成することができる。

ｃｈａｎｎｅｌ　ｔｙｐｅ　： 標準 同期 以下のパラメータは、ボートと関連している。ボート・タイプを除くすべてのパ ラメータは明示的に定義される。送信側ボートは、ｃｒｅａｔｅ　ｃｈａｎｎｅ ｌ要求でこれらのパラメ・−夕を指定し、受信側ポートはＰＯＲＴ　ＲＥＱＵＥ ＳＴ応答でこれらのパラメータを指定する。

Ｃ０ｎｎ８ＣＬ　ｔｙｐｅ　： コマンド 事象 空 ｅｖｅｎｔ　ｈａｎｄｌｅｒ　： ｐｏｒｔ　ｔｙｐｅ　’ 送信 受信 ｕｓｅｒ−ｉｎｆｏｒｍａｔｉｏｎ　：リンクの特性 以下のサービス品質パラメータは、物理リンクに関連しており、リンク・ロケー タを介してアクセスされるデータベースに指定するか、あるいはデフォルトとし てＬＡＫＥＳＱＯ３，ＩＮＩファイルから得られる。

信号タイプ（アナログまたはディジタル）スループット 待ち時間 ジッダ フレーム・サイズ フレーム再送信時間 圧縮ヒント 暗号化 サポート・システム構造 再び、第１０図に示したサポート・システム構造を参照して、該構造の構成要素 の様々なタスクについて詳細に説明する。アプリケーション・マネージャ２２３ は、サポート・システムの残りとのインタフェースとして働き、ある程度のパラ メータ検証の後に適切な構成要素に分散されるすべてのＡＰＩ呼出し用の入口点 を提供する。監視が必要な場合（以下参照）、アプリケーション・マネージャ２ ２３は着信呼出し／発信事象の走査にも使用される。

アプリケーション・マネージャ２２３は、チャネルの作成時に指定された事象ハ ンドラでアプリケーションをコール・バックする責任を負う。事象は、ローカル ・アプリケーションがチャネルを作成した場合は送信側ポートで、あるいは次い でリモート・アプリケーションがチャネルを作成した場合は受信側ボートでレイ ズされるものである。アプリケーション・マネージャ２２３は、ボートを作成す る際に、特定のアプリケーションのためのすべての事象を処理し待ち行列に入れ る事象待機ハンドラのアドレスを渡す。次いで、事象を連続的に読み取るディス パッチ・スレッドなどのある種の機構がアプリケーションの事象ハンドラに事象 を送信する。

チャネル・マネージャ２２７は、他のすべての構成要素を始動し遮断する責任を 負うチャネル・スーパバイザと、異なるノードにあるサポート・システムの間の 制御チャネル通信を処理する制御チャネル副構成要素と、他のすべての非制御チ ャネル・データ通信を処理するデータ・チャネル副構成要素と、ノード・ハンド ルおよび数組のノード・ハンドルを作成し、破壊し、維持するノード・マネージ ャと、ポートを作成し、破壊し、操作し、ボート照会機能を実行するポート・マ ネージャの５つの副構成要素を有する。

資源マネージャ２２５は、サポート・システムで第１に制御を得る構成要素であ る。資源マネージャ２２５は、他のすべての構成要素を初期設定し、かつアドレ ス・ブックまたは経路選択機能とのインタフェースをとる責任を負う。トークン ・マネージャ２２４は、名前から分かるように、グローバル・トークンとアプリ ケーション・トークン（グローバル・トークンはそれぞれの呼出しマネージャ構 成要素によって所有され、これに対し、アプリケーション・トークンは共用セッ ト中のノードによって所有される）とのロギングおよび管理に責任を負う。

装置マネージャ２２４は、サポート・システムと装置の間の対話に責任を負い、 特に、装置名を完全修飾経路などに変形すること、適切な動的リンク・ライブラ リ　（ＤＬＬ）のロード、ボート番号、ポート・ハンドラ、および事象ワードを 含む記録の生成、初期設定入口点の呼出し、ＤＬＬ中のすべての項目ハンドルを アプリケーション呼出しマネージャ用の物理アドレスに変形することなどの機能 を実行する。信号マネージャ２２６は、アプリケーション（応答の有無にかかわ らない）およびボートに発信する責任を負う。

チャネルおよびポートの記述 ａ）チャネルの記述 以下のパラメータは、チャネルに関連し、”ｃｒｅａｔｅ−ｃｈａｎｎｅｌ”要 求で指定される。

ｑｕａｌｉｔｙ　ｏｆ　５ｅｒｖｉｃｅ　ニースループット（たとえば、ビット ／秒）−チャネル優先順位 ｃｈａｎｎｅｌ　ｔｙｐｅ　＋ ｃｏｍｐｒｅｓｓｉｏｎ−ｈｉｎｔｓ　：ｂ）ボートの記述 以下のパラメータは、ポートに関連する。送信側ボートは、これらのパラメータ を’ｃｒｅａｔｅ　ｃｈａｎｎｅｌ”要求で指定し、受借倒ポートは応答で指定 する。

Ｃ０ｎｎＣＩＣｔ　ｔｙｐｅ　ニ 一部 ｅｖｅｎｔ　ｈａｎｄｉｅｒ　： ｐｏｒｔ　ｔｙｐｅ　＋ 一複合オーディオ／ビデオ 協調アプリケーション・サポート・システムの全体的な動作について説明したの で、今度は、様々なチャネルとボートの動作について詳細に説明する。チャネル およびボートを作成するＡＰＩコマンドは”ｃｒｅａｔｅ−ｃｈａｎｎｅｌ”で ある。

ｃｒｅａｔｅ　ｃｈａｎｎｅ１機能は、発行側アプリケーションからターゲット ・アプリケーションへの、指定された特性をもつチャネルを作成する。

ｃｒｅａｌ、ｅ　ｃｈａｎｎｅｌコマンドに指定するパラメータは以下のとおり である。

ａｓｙｎｃ　ｉｄ　この呼出しと、この呼出しに関連するすべての事象との識別 に使用される、ユーザが供給する参照ｉｄ。このパラメータをゼロにすることは できない。

ｔａｒｇｅｔ　ａｐｐｌｉｃａｔｉｏｎ　ターゲット・アプリケーションの類ア ドレスを含む構造を指すポインタ ｓｈａｒｉｎｇ　ｓｅｔ　ｉｄ　作成すべきチャネル中のユーザ定義共用セット 名 ｃｈａｎｎｅｌ　ｔｙｐｅ　チャネル・セット関連のタイプ：０３ＴＡＮＤＡＲ Ｄ ＥＲＧＥＤ ＳＥＲＩＡＬＩＳＥＤ ＳＹＮＣＨＲＯＮＩＳＥＤ ｃｈａｎｎｅｌ　ｓｅｔ　ｉｄ　作成されたボートが関連付けられるべきチャネ ル・セットのユーザ定義識別子 ｑｕａｌｉｔｙ　ｏ「５ｅｒｖｉｃｅ　サービス品質パラメータを含む構造を指 すポインタ ｄａｔａ　ｃｌａｓｓ　作成された送信側ポートを介して送信できるデータのタ イプおよびサブタイプを記述する２つのフィールドを含む構造を指すポインタ ｍａｘ　ｂｕｆｆｅｒ　５ｉｚｅ　５ｅｎｄ　ｄａｔａ上で使用される最大バッ ファ・サイズ Ｃｏｎｎｅｃｔ　ｔｙｐｅ　送信側ボートの接続タイプ：ＵＬＬ ＶＥＮＴ ＢＵＦＦＥＲＥＤ ｅｖｅｎｔ　ｈａｎｄｌｅｒ　作成されたボートに対する着信事象を処理するた めに呼び出すべき事象ハンドラのアドレスｕｓｅｒ　ｅｖｅｎｔ、ｗｏｒｄ　こ のボートに関連するすべての事象上でボート事象ハンドラに渡されるユーザ指定 データ・ポインタｕｓｅｒ　ｅｘ］ｔ　送信側ボートを介してデータが送信され るときに必ず呼び出すべき発行側アプリケーション中のユーザ出口のアドレス ｕｓｅｒ　１ｎｆｏ　ＰＯＲＴ　ＲＥＱＵＥＳＴ事象上でリモート・アプリケー ションに渡されるユーザ指定情報 ５ｔａｒｔｕｐ　ｍｏｄｅ　チャネルが中断状態または始動状態で作成されるこ とを指定する。

チャネル作成関数からのリターン・コードは、動作が首尾よく完了したことを示 すＲＣ：　ＯＫと、多数の失敗コードを含む。

この関数呼出しは、１方向論理チヤネルを作成するために使用される。このチャ ネルは、発行側アプリケーションとターゲット・アプリケーションの間に作成さ れる。送信側ボートは発行側アプリケーションで作成され、受信側ボートはター ゲット・アプリケーションで作成される（第８図参照）。

ｃｒｅａｔｅ　ｃｂａｎｎｅｌ関数呼出しの結果、リモート・アプリケーション は、初期設定事象ハンドラを介してレイズされたＰＯＲＴＲＥＱＵＥＳＴを得る 。この時点で、リモート・アプリケーションはこの要求を受け入れることも、拒 否することもできる。

ＣＨＡＮＮＥＬ〜ＣＯＮＦＩＲＭＥＤ事象は、ＰＯＲＴ　ＲＥＱＵＥＳＴ応答を 与えるアプリケーション初期設定事象ハンドラを介してレイズされる。

ｃｈａｎｎｅｌ　ｔｙｐｅは、前述の４つのチャネル・タイプ、すなわち、標準 、組合せ、直列化、および同期を定義する。

ａｓｙｎｃ　ｉｃ！パラメータ値は、アプリケーション定義であり（この値は、 取消し関数呼出しで使用することができる）、ローカル端末でＣＨＡＮＮＥＬ　 ＣＯＮＦＩＲＭＥＤ事象またはＣＨＡＮＮＥＬ−ＲＥＪＥＣＴＥＤ事象で返され る。しかし、リモート端末でのＦＯＲＴ−ＲＥＱＵＥＳＴ事象、ＣＨＡＮＮＥＬ 　ＣＯＮＦＩＲＭＥＤ事象、またはＣＨＡＮＮＥＬ−ＲＥＪＥＣＴＥＤ事象はａ ｓｙｎｃ−ｉｄ値ゼロを有する。

ｃｈａｎｎｅｌ　５ｅｔ−ｉｄは、ユーザ定義識別子であり、論理チャネルが１ 組のチャネルに属することをシステムに通知する。

ｃｈａｎｎｅｌ　５ｅ５ｉｄはアプリケーション共用セット内で特有のものでな ければならず、前記セットの一部となるべきチャネルはどれも同じ識別子を指定 しなければならない。これは、ｃｈａｎｎｅｌ　ｔｙｐｅを５ＴＡＮＤＡＲＤと して指定した場合だけ空になる。

サービス品質パラメータは、資源セットの識別子と所望の　′サービス品質資源 とを含む構造である。資源セット識別子が空でない場合、指定された資源はこの セットから獲得される。

資源識別子が空の場合、資源は使用可能資源から獲得される。

資源セットのセットアツプについての詳細は、ｒｅｓｅｒｖｅ−ｒｅｓｏｕｒｃ ｅ関数呼出しの定義を参照されたい。

ｃｏｎｎｅｃｔ　ｔｙｐｅパラメータは、データをどのようにシステムに与え、 あるいはシステムから受け取るか、すなわち、前述の空、事象、またはバッファ を指定する。

データ・チャネルとそれに関連するボートを作成するための典型的なフローを第 １４図に示し、以下の注によって説明する。

ステップ】　最初に、ノード１中のアプリケーション又は、アプリケーションＸ の送信側ポートとノード２中のアプリケーションＹの受信側ボートから成るデー タ・チャネルを作成するためにサポート・システムにａｓｙｎｃｈｒｏｎｏｕｓ 　ｃｒｅａｔｅ−ｃｈａｎｎｅｌ要求を発行する。

ステップ２　サポート・システムは、Ｙの初期設定事象ハンドラに対してＰＯＲ Ｔ　ＲＥＱＵＥＳＴをレイズする。ｃｒｅａｔｅ　ｃｈａｎｎｅｌが、すでに作 成されたボートを使用して組合せチャネルまたは直列化チャネルを作成すること を要求している場合、ＰＯＲＴＲＥＱＵＥＳＴはレイズされないことに留意され たい。ＰＯＲＴ−ＲＥＱＵＥＳＴは、送信側ポート・ハンドル（完全アドレス） 、受信側ボート・ハンドル、および発信元アプリケーションＸの完全アドレスを 指すポインタを含む。

ステップ３　Ｙの初期設定事象ハンドラが、要求を拒否しくＲＣＰＯＲＴ　ＲＥ ＪＥＣＴ）　、または受け入れる（ＲＣニーＰＯＲＴ−ＡＣＣＥＰＴ）。

要求を受け入れる場合、Ｙの事象ハンドラは事象データ中のフィールドを、受信 側ボートを構築するのに必要なパラメータで埋めなければならない。

ステップ４　ＹがＲＣＰＯＲＴ　ＲＥＪＥＣＴを返す場合、システムはＣ）（Ａ ＮＮＥＬ　ＲＥＪＥＣＴＥＤ事象をレイズする。ＹがＲＣ−ＰＯＲＴ　ＡＣＣＥ ＰＴを返す場合、システムは送信側ボート事象ハンドラでＣＨＡＮＮＥＬ−ＣＯ ＮＦ　Ｉ　ＲＭＥＤ事象をレイズする。

ステップ５　また、Ｙは、システムが受信側ボートを確立したことを示すＣＨＡ ＮＮＥＬ　ＣＯＮＦＩＲＭＥＤ事象を、受信側ボート事象ハンドラで受信する。

ステップ６　すべでの新たに作成されたチャネルの送信側および受信側ボート事 象ハンドラに対してＣＨＡＮＮＥＬ−ＣＯＮＦ　ＩＲＭＥＤ事象がレイズされる 。これは、明示的に作成されたチャネルと同じチャネル・セットに属し、含まれ るアプリケーション・インスタンスが、ノード３にあるアプリケーションＺなど の、新しいチャネルの作成光と同じアプリケーション・セットに属する、すべて のチャネルの送信側および受信側ボート事象ハンドラに対してＣＨＡＮＮＥＬ　 ＣＯＮＦＩＲＭＥＤ事象がレイズされることを意味することに留意されたい。

協調グループ作業では多（の場合、参加者が定常的に参加したり抜けたりするグ ループのメンバ間にｎ方向通信を確立することが必要である。すべての参加者が 常に現メンバのリストを更新し、すべての必要なデータ・リンクを修正すること は困難であり、あるいは時間がかかる。組合せチャネルを作成すると、それぞれ の参加者が最小限に関与することによって、すべての必要なデータ経路を基礎シ ステムで維持することができる。

論理チャネルは、一方の端末にある送信側ポートと他方の端末にある受信側ボー トとを備えた１方向データ・パイプから構成されるように定義されている。デー タは常に、送信側ポートから受信側ボートに流れる。表記上、これを［送信側ボ ート：受信側ボートコで示す。

チャネルは、１つの送信側ポートを多数の受信側ボートと関連付けることができ る、すなわち、単一の送信側ポートを介して送信されたデータがすべての受信側 ボートに送られるように確立することができる。これを第１５図に示し、表記上 、［ＳＰ：　ＲＰＩ、　ＲＰ２１１、ＲＰｎ］で示す。

論理チャネルも、表記上、Ｃ５ｎａｍｅ［ＳＰ：ＲＰＩ、ＲＰ２．、、、ＲＰｎ コｔｙｐｅとして示した、異なるタイプのチャネル・セットごとに関連付けるこ とができる。組合せチャネル・セット・タイプは、複数の送信側ポートがすべて 、単一の受信側ボートにデータを送信するものである。概念的には、すべての「 通常の」受信側ボートが組合わされて、この単一の受信側ボートになっている。

これを添付の第１６図に示し、表記上、以下のように表す。

Ｃ３ｎａｍｅ［ＳＰｌ、ＳＰ２．、、、ＳＰｎ　：　ＲＰＩ］ｒ、ｅｒｇｅａ２ つ以上のアプリケーションが、異なる送信側ポートと受信側ボートから成る同じ チャネル・セット名を使用して組合せチャネル・セットを定義することができる 。たとえば、アプリケーションＡは組合せチャネル・セットＣ３１［ＳＰａ　： 　ＲＰｂ。

ＲＰｃｌ。ｅアｇｃｄを定義することができ、アプリケーションＢは組合せチャ ネル・セットＣ３１［ＳＰｄ　：　ＲＰＧ、ＲＰｆ］、ｅｒｇｃｄを定義するこ とができる。

アプリケーションが、それによって確立されたデータ・チャネルを参照する、す なわち５ｈａｒｅコマンドを使用するのでなくアプリケーション名を参照するこ とによって協調セツションを開設することに留意されたい。

上記の場合、アプリケーションＡはアプリケーションＢと共用を行い、協調作業 グループを形成する。これによって、送信側ポートめ結合セットがすべての受信 側ボートの結合セットにデータを送信するように、組合せチャネル・セットＣ８ １の２つの定義が組み合わせられる。表記上、この結果得られるチャネル・セッ トＣ３Ｉを次のように定義する。

Ｃ３１［ＳＰａ、ＳＰｄ　二　ＲＰｂ、ＲＰｃ、ＲＰｅ、ＲＰｆ　コｅｍｅｒｇ ｅｄこの場合、アプリケーションＡによって明示的に作成されるチャネル（すな わち、［ＳＰａ　：　ＲＰｂ］、［ＳＰａ　：　ＲＰｃｌ）およびアプリケーシ ョンＢによって明示的に作成されるチャネル（すなわち、［ＳＰｄ　：　ＲＰＧ コ、［ＳＰｄ　：　ＲＰｆコ）だけでな（、新しいチャネル［ＳＰａ　：　ＲＰ ｃｌ、［ＳＰａ　：　ＲＰｆ］、［ＳＰｄ　：　ＲＰｂ］、および［ＳＰｄ　： 　ＲＰｃｌもシステムによって作成される。したがって、送信側ポートと受信側 ボートのすべての交差接続の間に現在、データ・チャネルが存在している。

これによって、各メンバが、グループの他のメンバによって確立されたデータ・ チャネルに関して何も知る必要なしに、協調グループのすべてのメンバの間に２ 方向データ・チャネルを確立する極めて簡単な方法が得られる。

このプロセスは、協調作業グループの各潜在的メンバ・アプリケーションが、同 じアプリケーションに定義された送信側ボートとそれに関連する受信側ボートか ら成り、合意されたチャネル・セット名を使用する、組合せチャネル・セットを 確立するためのものである。すなわち、各潜在的アプリケーションは、Ｃ３１［ ＳＰａ　：　ＲＰａ］ｍａｒｇｅｔなどのチャネル・セットを確立する。２つ以 上のアプリケーション（たとえば、アプリケーションＡ、Ｂ、Ｃ）が協調グルー プを形成するとき、Ｃ８１の異なる定義が、以下の組合せセットを形成するよう に結合される。

Ｃ５１［ＳＰａ、ＳＰｂ、ＳＰｃ　：　ＲＰａ、ＲＰｂ、ＰＲＣ］ｏ＋ｅｒｇｅ ａこれを第１７図に示す。

グループには新しいメンバを容易に追加することができ、必要なデータ・チャネ ルは基礎システムによって自動的に確立される。唯一の要件は、新しいメンバが 既存のメンバのアプリケーション名を知り、同じチャネル・セット名を使用する ことである。新しいメンバは、他のメンバに関して何も知る必要がなく、さらに 、グループに参加するために使用されたアプリケーション名を提供したアプリケ ーション・メンバによって確立されたデータ・チャネルに関して知る必要もない 。同様に、アプリケーションがグループを抜けるとき、無効なデータ・チャネル は自動的に削除される。

グループの複数のメンバによって送信されたデータがグループのすべてのメンバ に同じシーケンスで到着するように、グループのメンバの間にｎ方向通信を確立 することが必要な特殊なケースが発生する。直列化チャネルを作成すると、それ ぞれの参加者が最小限に関与することによって、データ・パケットの順序付けを 基礎システムで行うことができる。

第１８図に示した直列化チャネル・セットは、複数の送信側ボートがすべて、複 数の受信側ボートにデータを送信し、かつデータがすべての受信側ボートに同じ 順序で到着することを要求するものである。概念的には、すべての送信側ボート （Ａ、Ｃ）からのデータ・パケットを直列化し、すべての受信側ボート（Ｂ、Ｄ ）に同じシーケンスのパケットを送るという特性を有する指定されたチャネル・ セットを介してデータが送信される。表記上、これを以下のように表す。

Ｃ５ｎａｍｅ［ＳＰｌ、ＳＦ３．、、、、ＳＰｎ　：　ＲＰＩ、ＲＰ２．、、、 ＲＰｎ］Ｉ！ｅｒ、ａｌｌａｅ、ａ組合せチャネルと同様に、２つ以上のアプリ ケーションが、異なる送信側ボートと潜在的に共通の受信側ボートから成る同じ チャネル・セットを使用して直列化チャネル・セットを定義することができる。

たとえば、アプリケーションＡは直列化チャネル・セットＣＳ１［ＳＰａ　：　 ＲＰｂ］１Ｉｅｒｓａ＋、ａｅａを定義することができ、アプリケーションＣは 直列化チャネル・セットＣ５１［ＳＰｃ　：　ＲＰｄコ５ｅｒｉａ１１ｅ＋ｅｄ を定義することができる。

組合せの場合と同様に、アプリケーションは、それによって確立されたデータ・ チャネルを参照せずにアプリケーション名を参照することによって協調セツショ ンを開設する。第１８図を参照すると、アプリケーションＡはアプリケーション Ｃと協働して、協調作業グループを形成する。これによって、送信側ボートの結 合セットがすべての受信側ボートの結合セットに同じシーケンスでデータを送信 するように、直列化チャネル・セットＣ３Ｉの２つの定義が組み合わせられる。

表記上、この結果得られるチャネル・セットＣ３Ｉを次のように定義する。

Ｃ３１［ＳＰａ、ＳＰｃ　：　ＲＰｂ、ＲＰｄ］５ｅア、ａ）１．ｅｄこの場合 、アプリケーションＡによって明示的に作成されるチャネル（すなわち、［ＳＰ ａ　：　ＲＰｂ］）およびアプリケーションＣによって明示的に作成されるチャ ネル（すなわち、［ＳＰｃ：　ＲＰａコ）だけでな（、新しいチャネル［ＳＰａ 　：　ＲＰｄ］、［ＳＰｃ　：ＲＰｂ］もシステムによって作成される。したが って、送信側ボートと受信側ボートのすべての交差接続の間に現在、データ・チ ャネルが存在している。これは、組合せチャネル・セット概念と類似している。

しかし、データ・パケットがすべての受信側ボートに同じシーケンスで到着する という重要な追加制約がある。

組合せの場合と同様に、これによって、各メンバが、グループの他のメンバによ って確立されたデータ・チャネルに関して何も知る必要なしに、協調グループの すべてのメンバの間に両方向直列化データ・チャネルを確立する極めて簡単な方 法が得られる。

このプロセスは、協調作業グループの各潜在的メンバ・アプリケーションが、同 じアプリケーションに定義された、送信側ボートとそれに関連する受信側ボート から成り、合意されたチャネル・セット名を使用する、組合せチャネル・セット を確立するためのものである。すなわち、各潜在的アプリケーションは、Ｃ５１ ［ＳＰａ　：　ＲＰａ］、ｅｒｉａｌｌａｅｄなどのチャネル・セットを確立す る。２つ以上のアプリケーション（たとえば、アプリケーションＡ、Ｂ、Ｃ）が 協調グループを形成するとき、Ｃ８１の異なる定義が、以下の直列化セットを形 成するように結合される。

Ｃ３１［ＳＰａ、ＳＰｂ、ＳＰｃ　：　ＲＰａ、ＲＰｂ、ＰＲｃ］、、、１ａ１ １５ｅ、、１これを第１９図に示す。

グループには新しいメンバを容易に追加することができ、必要なデータ・チャネ ルは基礎システムによって自動的に確立され直列化される。唯一の要件は、新し いメンバがアプリケーション名または既存のメンバを知り、同じチャネル・セッ ト名を使用することである。新しいメンバは、他のメンバに関して何も知る必要 がなく、さらに、グループに参加するために使用されたアプリケーション名を提 供したアプリケーション・メンバによって確立されたデータ・チャネルに関して 知る必要もない。同様に、アプリケーションがグループを抜けるとき、自動的に 、有効なデータ・チャネルが再確立される。

サポート・システムによる組合せチャネルおよび直列化チャネルの作成を第２０ 図の流れ図によって示す。

サブシステム１７は、もちろんプログラミングのためのモデルにすぎない組合せ チャネルを実施するために、少なくとも受信側ボートのアドレスを含む、各組合 せチャネル用のチャネル・セット・テーブルを維持する。第２１図の流れ図（二 示すように、サブシステム１７は、組合せチャネル・セットの一部である指定さ れたバッファ受信側ポートへのデータの送信をめる５ｅｎｃｊｄａｔａコマンド に応答して、テーブルを使し１尽（すまで、チャネル・セット中の各受信側ポー トにデータを送信し続ける。

サブシステム１７は、第２２図の流れ図に示した直列化チャネルを実施するため に、すべての受信側ボートのアドレスを含むチャネル・セット・テーブルを確立 する同様な技術を使用する。しかし、サブシステム１７は、直列化すべきデータ 項目が、送信側ボートからロードされ、かつ該データ項目をすべての受信側ボー トに送信する上で所望される順序（二保持される、チャネル用の直列化待ち行列 を維持する必要カミある。

チャネル・タイプが「同期」のときは、チャネル・セットのチャネルの同期も提 供される。たとえば、グループの１人（または複数の可能性もある）のメンバに よって送信された複数のデータ・タイプ（たとえば、オーディオ、ビデオ、キー ストローク、マウス・ボインティング）がグループのすべての受信側メンバで同 期式に送られるようにグループのメンバの間にｎ方向通信を確立する必要がある ことが多い。データ・パケットの同期は、それぞれの参加者が最小限に関与する ことによって基礎システムで行われる。

このチャネル・セット・タイプは、ターゲット・アプリケーションへの別々のデ ータ・チャネルを介してオーディオやビデオなどの異なるデータ・タイプを発信 元アプリケーションが送信するものである。通常、単一の発信元アプリケーショ ンと単一のターゲット・アプリケーションがある。しかし、この場合には、同期 受信側チャネルが同じアプリケーションにあれば、単一の発信元アプリケーショ ンが複数のターゲット・アプリケーションに送信することができ、複数の発信元 アプリケーションが複数のターゲット・アプリケーションに送信することができ る。以下で、典型的な例を示す。

概念的には、送信側ポートからのデータ・パケットを同期し、データの送信時に データ・ストリームに同期パルスを押入する、特性を有する指定されたチャネル ・セットを介してデータが送信される。関連するチャネルのうちの１つの受信側 端末に同期パルスが到着するときに必ず、そのチャネルのデータは、一致する同 期パルスが他のすべてのチャネルに到着するまで保持される。すべての同期パル スが到着すると、データは次の同期パルスが１つのチャネルに到着するまですべ てのチャネルを介して流れることを許可される。同期パルスは、データが提供さ れる前に、基礎システムによって削除される。これを第２３図に示し、表記上、 以下のように表す。

Ｃ３ｎａｍｅ（［ＳＰｌ　：　ＲＰｌ］ｌ［ＳＦ３　：　ＲＰ２］＋−−１）ａ ｙｎｃｂｒｏｎ＋ａｅａアプリケーションＡが、まず第２のアプリケーションＢ との以下の同期チャネル・セットを確立する場合、Ｃ３ｎａｍｅ（［５Ｐａｌ　 ：　ＲＰｂｌ］、［５Ｐａ２　：　ＲＰｂ２］）、ｙｎｃｈｒｏｎ４．ｅａ次い で、他のアプリケーションＣとの協調セツションを形成し、同じ送信側ボートと のそれ以上の同期チャネルを追加することができる。すなわち、 Ｃ５ｎａｍｅ（［５Ｐａｌ　：　ＲＰｃｌ］、［５Ｐａ２　：　ＲＰＣ２］１ｌ ｙｎｃｈｒｏｎｓｌｌｅａこの場合、アプリケーションＢの受信側ボートとアプ リケーションＣの受信側ボートとに到着するデータの間で同期が取られる。表記 上、この結果径られるチャネル・セットは以下のとおりである。

ＣＳｎａｍｅ（［５Ｐａ１　：ＲＰｂｌ、ＲＰｃｌコ、［５Ｐａ２：ＲＰｂ２． ＲＰｃ２］）ａｙｎｃｈｒｏｎｉａｅｄ同様に、アプリケーションＡが１つのデ ータ・タイプ用のチャネル・セットを確立し、 Ｃ３ｎａｍｅ（［５Ｐａｌ　：　ＲＰｂｌ、ＲＰＣＩ］）ｓｙｎｃｈｒｏｎ＋、 ｅ、ｉアプリケーションＤが第２のデータ・タイプ用の同じチャネル・セットを 確立し、 Ｃ：Ｓｎａｍｅ　（［５Ｐｄ２　：　ＲＰｂ２　＋　ＲＰｃ２］　）　ｅ　ｙｎ 　ｃ　ｐ　ｒ　ｏ　ｎ　１６　ｅｄアプリケーションＡおよびＤが現在、協調グ ループを形成している場合、データ・タイプ１とデータ・タイプ２の通信はアプ リケーションＢおよびアプリケーションＣで同期される。すなわち、同期チャネ ル・セットは現在、以下のとおりである。

Ｃ３ｎａｍｅ（［５Ｐａｌ　：ＲＰｂｌ、ＲＰｃｌコ、［５Ｐｄ２：ＲＰｂ２． ＲＦｅ５コ）ａｙｎｃｈｒｏｎｌｓｅｄすべての同期パルスが一致する前にかな りの遅延がある場合、基礎システムは関連ポートの速度を上げ、あるいは下げる ことを要求する適切な制御信号を送信側ボートに送信する。

協調グループ作業では、アプリケーションは２つのリモート・アプリケーション の間にリンクをセットアツプする媒介として働くことが多い。

ポートを接続しウェルドしてデータのストリーム化をサポートすることによって 、アプリケーションは２つのリモート・ワークステーションの間でデータを送信 する上でのリンクとしての働きに関与する作業の大部分（あるいはすべての場合 もある）を基礎システム１７に移すことができる。リンクが確立されると、アプ リケーションはデータのストリーム化を完全に基礎システムによって実行するた めの手段を提供することによってデータ送信への関与を削減することができる。

論理チャネルは、一方の端にある送信側ボートと他方の端にある受信側ボートを 含む１方向データ・パイプから成ると定義されている。送信側ボートの構造は第 ８図に示した。アプリケーションに関するかぎり、ポートはチャネルとのインタ フェースとして働く。

アプリケーションは、さまざまな事象を通知される事象ハンドラを備えているこ とも必要である。システム定義事象は、データ送受信エラーの肯定応答を含む。

どちらの端にあるアプリケーションでも他方の端にアプリケーション定義文字列 を送信できるようにする機能が提供されている。この信号機能は、他力の端で信 号事象をレイズする。

アプリケーションはこれで、データを送信しようとする際に呼び出されるユーザ 出口を任意選択で提供することができる。このユーザ出口は、フィルタとして働 き、所望どおりにデータを挿入し、削除し、修正することができる。ユーザ出口 に割り当てることができるタスクには、圧縮と暗号化がある（対応する圧縮解除 と非暗号化は受信側ボートにあるユーザ出口で行われる）。

同じアプリケーション内で、あるタイプのボートを数個使用することができる。

各タイプのボートを１つ有するアプリケーションは、受信側ボートで受信され、 送信側ボートを介して送られるあらゆるデータ・パケットを単に送信することに よって、単純な媒介として働くことができる。この機能を実行するためのプログ ラムは、概念的には非常に簡単だが、それにもかかわらずかなりのオーバヘッド を伴う。というのは、各データ・パケットを読み取り、データを受信側バッファ から送信側バッファに移動し、次いで書き込む必要があるからである。このオー バヘッドを削減できるように、基礎システムによって２つの機能、接続とウェル ドが提供される。

第２４図に示したように、第１の機能、接続は実際上、受信側ボートを送信側ボ ート上に接着し、２つのボートは依然としてアプリケーションによって参照でき るが、データ・フローは自動的に接続を介して流れるようにする。このデータの ストリーム化は、関与するオーバヘッドを削減する。なぜなら、アプリケーショ ンはもはや、各データ・パケットを受信し、移動し、次いで送信する必要がなく なるからである。

図から明らかなように、現在、基礎システムによって維持する必要がある待ち行 列は１つだけである。

接続後、２つのボートはそのままアプリケーション内に存在し、したがって様々 なボート関連機能は引き続き使用することができる。たとえば、ボートを再び切 断して削除することができ、引き続き信号を送信することができる。もはやデー タ経路へのアクセスはないので、もはや送信（送信側ボートを介する）も受信（ 受信側ポートを介する）も不可能である。

リモート信号が自動的に渡されないので、もはや事象ハンドラは必要とされない ことに留意されたい。しかし、２つのユーザ出口は共に保持される。これは、こ れらの出口がデータの保全性を維持するのに必要なデータ変換などのタスクを実 行できるからである。ユーザ出口はアプリケーション・プログラムの一部なので 、アプリケーションが終了すると、接続は（両方のボートと共に）失われる。

どちらのボートもユーザ出口を必要としない場合は、接続をウェルドすることが できる。ウェルドは、ボートの削除、したがってアプリケーションとチャネルの 間のすべてのリンクの切断を伴う。ボートはもはや存在しないので、ウェルドを 取り消すことはできない。最終的な結果は、２つのりモート端末の間にチャネル を直接接続した場合と同様である。アプリケーションは、もはや関与していなし ＼ので、ウェルド＜ｋに、所望なら終了することができる。第２５図（よ、ウェ ルドの結果を示す。

これによって、ウェルド後に、基礎システム（二よって力）なりの最適化を実行 できることに留意されたし１゜たとえ！、ｆ、データ・トラフィックを、このノ ードを介して流れなｌ／飄よう（二経路変更することができる。

ＩＧ−Ｉ ＩＧ−４ ＦＩＧ−６ ＦＩＧ−７ ＦＩＧ−９ ＦＩＧ−ＴＯ ＦＩＧ−１１ ＦＩＧ−１２ ＦＩＧ−１３ ＦＩＧ−ｆ４ ＦＩＧ−１７ ＦＩＧ、１Ｂ ＦＩＧ、１９ ＦＩＧ−２０ ＦＩＧ−２１ 同期挿入　同期削除 ＩＧ−２３ ＦＩＧ−２４ ＦＩＧ−２５ フロントページの続き （７２）発明者　ランバード、ハワードイギリス国ハンプシャー、サザンプトン 、ヘッダ・エンド、ノルデック・ガーデンズ（７２）発明者　ミッチェル、バリ ー、デヴイッドイギリス国す−レイ、リッチモンド・アポン・テイームズ、ザ・ ハーミテイジ１８

Claims (22)

【特許請求の範囲】
1. １．ノードの間でデータを送信するための物理リンクによって接続されたネット ワークのノードを形成するワークステーションのネットワークでの協調作業用の プログラマブル・ワークステーションにおいて、 オペレーティング・システムと、 ノードの間のマルチメディア・データの物理経路指定を制御するための、オペレ ーティング・システム上で動作するネットワーク制御層と、 ワークステーション上で作動し、所定のアプリケーション呼出しに応答する、ア プリケーションとのインタフェースをとり、ノード内でおよびノードを介してデ ータおよび資源を共用する共用アプリケーション・セットと、それぞれがアプリ ケーションに関連する送信側ポートおよび受信側ポートによってそれぞれが定義 される、共用アプリケーション・セットのメンバを接続する論理専用データ・チ ャネルとを備えた協調環境の論理ネットワーク・モデルを作成し、かつネットワ ーク制御層と協働して、アプリケーションに透過的に、物理ネットワークで論理 ネットワーク・モデルを実施するのに必要な物理リンクを確立するようになされ た協調アプリケーション・サポート手段とからなることを特徴とするワークステ ーション。
2. ２．論理データ・チャネルがチャネル・タイプとチャネル・セット名の両方を有 し、同じ共用アプリケーション・セット中の同じタイプおよびセット名のチャネ ルが、チャネル・タイプに関連する所定の特性に応じて、チャネル・セットのチ ャネルで受信されるデータがチャネル・セットの他のチャネル上のデータに依存 するチャネル・セットを形成することを特徴とする請求項１に記載のワークステ ーション。
3. ３．所定の特性が、組合せチャネル・セットのチャネルの送信側ポートからのデ ータが組合わされてターゲット・アプリケーションにある少なくとも１つの受信 側ポートに単一のデータ・ストリームとして送られることである、組合せチャネ ル・タイプが定義されていることを特徴とする請求項２に記載のワークステーシ ョン。
4. ４．複数の送信側ポートおよび受信側ポートを含む組合せチャネル・セットにお いて、送信側ポートと受信側ポートのすべての交差接続の間にサポート・システ ムによってデータ・チャネルが作成されることを特徴とする請求項３に記載のワ ークステーション。
5. ５．所定の特性が、直列化チャネル．セットのチャネルの送信側ポートからのデ ータが組合わされてチャネル・セット中の複数の受信側ポートのそれぞれに同じ 直列順序で送られることである、直列化チャネル・タイプが定義されていること を特徴とする請求項２に記載のワークステーション。
6. ６．それぞれが同じ名前の組合せチャネル・セットまたは直列化チャネル・セッ トを含む、複数の共用アプリケーションセット自体が組合わされてより大きな共 用セットを形成している場合に、共用アプリケーションによって明示的に作成さ れないデータ・チャネルが、すべての送信側ポートと受信側ポートのすべての交 差接続の間にサポート・システムによって作成されることを特徴とする請求項４ または５に記載のワークステーション。
7. ７．アプリケーションが、既存の共用セットに加わり、それ自体の送信側ポート と受信側ポートの間に同じチャネル．セット名の単一の組合せチャネルを作成す ることによって、組合せチャネル・セットまたは直列化チャネル・セットによっ てメンバが接続された共用セットのすべてのメンパとの２方向通信を確立するこ とができることを特徴とする請求項６に記載のワークステーション。
8. ８．所定の特性が、同期チャネル・セットの異なるチャネル上のデータが該チャ ネル・セットの各受信側ポートで時間同期されることである、同期チャネル・タ イプが定義されていることを特徴とする請求項２に記載のワークステーション。
9. ９．各送信側ポートで同期信号を挿入し、同期チャネル・セットの各受信側ポー トで同期信号を削除することによって同期を取ることを特徴とする請求項８に記 載のワークステーション。
10. １０．第１のアプリケーションの受信側ポートと送信側ポートを介して、他の２ つのアプリケーションの間でデータを送信する第１のアプリケーションによる所 定の呼出しに応答して、データ転送が第１のアプリケーションをバイパスするよ うに、第１のアプリケーションの受信側ポートがその送信側ポートに反転可能に 直接接続されることを特徴とする請求項１に記載のワークステーション。
11. １１．第１のアプリケーションの受信側ポートと送信側ポートを介して、他の２ つのアプリケーションの間でデータを送信する第１のアプリケーションによる所 定の呼出しに応答して、第１のアプリケーションがそれ以上役割を果たさない直 接データ・チャネルが他の２つのアプリケーションの間に作成されるように、第 １のアプリケーションの受信側ポートがその送信側ポートに永続的に直接接続さ れることを特徴とする請求項１に記載のワークステーション。
12. １２．ノードの間のデータ送信用の物理リンクによって接続されたネットワーク のノードを形成するプログラマブル・ワークステーションでの協調作業方法にお いて、ワークステーション上で作動するアプリケーションからの所定のアプリケ ーション呼出しに応答して、ノード内でおよびノードを介してデータおよび資源 を共用する共用アプリケーション・セットと、それぞれかアプリケーションに関 連する送信側ポートおよび受信側ポートによってそれぞれが定義される、共用ア プリケーション・セットのメンパを接続する論理専用データ・チャネルとを備え た、アプリケーションが使用する協調環境の論理ネットワーク・モデルを作成す るステップと、アプリケーションに透過的に、物理ネットワークで論理ネットワ ーク・モデルを実施するのに必要な物理リンクを確立するステップとを備えるこ とを特徴とする方法。
13. １３．論理データ・チャネルがチャネル・タイプとチャネルセット名の両方を有 し、同じ共用アプリケーション・セット中の同じタイプおよびセット名のチャネ ルが、チャネル・タイプに関連する所定の特性に応じて、チャネル・セットのチ ャネルで受信されるデータがチャネル・セットの他のチャネル上のデータに依存 するチャネル・セットを形成することを特徴とする請求項１２に記載の方法。
14. １４．所定の特性が、組合せチャネル・セットのチャネルの送信側ポートからの データが組合わされてターゲット・アプリケーションにある少なくとも１つの受 信側ポートに単一のデータ・ストリームとして送られることである、組合せチャ ネル・タイプが定義されていることを特徴とする請求項１２に記載の方法。
15. １５．複数の送信側ポートおよび受信側ポートを含む組合せチャネル・セットに おいて、送信側ポートと受信側ポートのすべての交差接続の間にサポート・シス テムによってデータチャネルが作成されることを特徴とする請求項１４に記載の 方法。
16. １６．所定の特性が、直列化チャネル・セットのチャネルの送信側ポートからの データが組合わされてチャネル・セット中の複数の受信側ポートのそれぞれに同 じ直列順序で送られることである、直列化チャネル・タイプが定義されているこ とを特徴とする請求項１３に記載の方法。
17. １７．それぞれが同じ名前の組合せチャネル・セットまたは直列化チャネル・セ ットを含む、複数の共用アプリケーション・セット自体が組合わされてより大き な共用セットを形成している場合に、共用アプリケーションによって明示的に作 成されないデータ・チャネルが、すべての送信側ポートと受信側ポートのすべて の交差接続の間にサポート・システムによって作成されることを特徴とする請求 項１５または１６に記載の方法。
18. １８．アプリケーションが、既存の共用セットに加わり、それ自体の送信側ポー トと受信側ポートの間に同じチャネル・セット名の単一の組合せチャネルを作成 することによって、組合せチャネル・セットまたは直列化チャネル・セットによ ってメンパが接続された該共用セットのすべてのメンパとの２方向通信を確立す ることができることを特徴とする請求項１７に記載の方法。
19. １９．所定の特性が、同期チャネル．セットの異なるチャネル上のデータが該チ ャネル・セットの各受信側ポートで時間同期されることである、同期チャネル・ タイプが定義されていることを特徴とする請求項１３に記載の方法。
20. ２０．各送信側ポートで同期信号を挿入し、同期チャネル・セットの各受信側ポ ートで同期信号を削除することによって同期を取ることを特徴とする請求項１９ に記載の方法。
21. ２１．第１のアプリケーションの受信側ポートと送信側ポートを介して、他の２ つのアプリケーションの間でデータを送信するための、第１のアプリケーション による所定の呼出しに応答して、データ転送が第１のアプリケーションをバイパ スするように、第１のアプリケーションの受信側ポートがその送信側ポートに反 転可能に直接接続されることを特徴とする請求項１３に記載の方法。
22. ２２．第１のアプリケーションの受信側ポートと送信側ポートを介して、他の２ つのアプリケーションの間でデータを送信するための、第１のアプリケーション による所定の呼出しに応答して、第１のアプリケーションがそれ以上役割を果た さない直接データ・チャネルが他の２つのアプリケーションの間に作成されるよ うに、第１のアプリケーションの受信側ポートがその送信側ポートに永続的に直 接接続されることを特徴とする請求項１３に記載の方法。