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

ネットワ―クにおける協調作業用ワ―クステ―ション及び協調作業方法

Info

Publication number
JP2544905B2
JP2544905B2 JP6511850A JP51185094A JP2544905B2 JP 2544905 B2 JP2544905 B2 JP 2544905B2 JP 6511850 A JP6511850 A JP 6511850A JP 51185094 A JP51185094 A JP 51185094A JP 2544905 B2 JP2544905 B2 JP 2544905B2
Authority
JP
Japan
Prior art keywords
application
channel
data
port
channels
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP6511850A
Other languages
English (en)
Other versions
JPH07503569A (ja
Inventor
アルドレッド、バリイ、キイース
ボンサル、ゴードン、ウイリアム
ランバート、ハワード
ミッチェル、ハリー、デヴィッド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JPH07503569A publication Critical patent/JPH07503569A/ja
Application granted granted Critical
Publication of JP2544905B2 publication Critical patent/JP2544905B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Description

【発明の詳細な説明】 ［技術分野］ 本発明は、ネットワークでの協調作業に関し、さらに
具体的には、そのような協調作業環境で使用するプログ
ラマブル・ワークステーションと方法に関する。
［背景技術］ パーソナル・コンピュータは現在、実業界全体に広く
普及しており、その多くは、固定接続、たとえばローカ
ル・エリア・ネットワークを介して、あるいは動的に確
立されるリンク、たとえば公衆交換電話網のISDNや非同
期回線を介して相互に通信することができる。これらの
接続されたパーソナル・コンピュータを使用して、遠く
離れた個人の間の協調作業を拡大できることが増加して
きている。典型的な例は、デスク・トップ会議ソフトウ
ェアを使用することである。協調作業を成功させるには
一般に、参加者の間に簡単なデータ・リンク以上のもの
が必要である。通常、音声機能が必須であり、しばし
ば、ビデオ・リンクが必要になる。したがって、リモー
ト協調作業は従来の電話呼出しの拡張とみなせることが
多い。従来の電話呼出しが、パーソナル・コンピュータ
を介して机上で利用可能なデータおよびプログラムによ
って拡張され、時にはビデオ・サービスによって拡張さ
れているものとみなされる。
ワークステーションのデータおよびアプリケーション
を利用するユーティリティ、たとえば画面ウィンドウお
よびファイルの共用から、特有のクラスのリモート・ユ
ーザのニーズを満たすように設計された新しい協調アプ
リケーション、たとえばジャストインタイム・エジュケ
ーション、リモート・プレゼンテーション、エグゼグテ
ィブ・ブロードキャスト、ヘルプ・デスクまで、広い範
囲の協調アプリケーションを構想することができる。こ
れらの例の共通の要件を以下に示す。
○ハードウェアとソフトウェアを共に含む広範囲のパー
ソナル・コンピュータ・プラットフォームのサポート ○既存の通信ネットワークを介した運用 ○グループ通信およびマルチメディア・データ・サービ
スマルチメディア装置および通信チャネルを使用するデ
スク・トップ会議システムが存在するが、これらは一般
に、固定された１組のシステム・ソフトウェアおよびユ
ーティリティ・アプリケーションを備えており、すべて
の潜在的なアプリケーションのニーズを満たすほど柔軟
ではない。
［発明の開示］ したがって、本発明は、ノードの間でデータを送信す
るための物理リンクによって接続されたネットワークの
ノードを形成するワークステーションのネットワークで
の協調作業用のプログラマブル・ワークステーションを
提供する。
このワークステーションは、オペレーティング・シス
テムと、 ノードの間のマルチメディア・データの物理経路指定
を制御するための、オペレーティング・システム上で動
作するネットワーク制御プログラム層と、 ワークステーション上で動作し、所定のアプリケーシ
ョン・プログラム呼出しに応答するアプリケーション・
プログラムとのインタフェースをとり、ノード内でおよ
びノードを介してデータおよび資源を共用する共用アプ
リケーション・プログラム・セットと、それぞれがアプ
リケーション・プログラムに関連する送信側ポートおよ
び受信側ポートによってそれぞれが定義される、共用ア
プリケーション・プログラム・セットのメンバを接続す
る論理専用データ・チャネルとを備えた協調環境の論理
ネットワーク・モデルを作成し、かつネットワーク制御
プログラム層と協働して、アプリケーション・プログラ
ムに透過的に、物理ネットワークで論理ネットワーク・
モデルを実施するのに必要な物理リンクを確立するよう
になされた協調アプリケーション・プログラム・サポー
ト・プログラム層とを備えている。
他の態様によれば、本発明は、第１のアプリケーショ
ンの受信側ポートおよび送信側ポートを介して、他の２
つのアプリケーションの間でデータを転送するために使
用されている第１のアプリケーション・プログラムによ
る事前に決定されたプログラム呼出しに応答して、デー
タ転送が第１のアプリケーション・プログラムをバイパ
スするように、第１のアプリケーションの受信側ポート
が反転可能に直接送信側ポートに接続される方法も提供
する。
ここで、本発明を、例を介して、添付の図面の第１図
ないし25を参照して説明する。
［発明の好ましい実施例］ 第１図には、LANやWANなどのネットワークでリンク11
によって接続された２台のプログラマブル・ワークステ
ーション10および12が示されている。ワークステーショ
ンの主要な構成要素は従来、ハードウェア13から始まる
層として説明されている。詳細に図示していないハード
ウェアは、メイン・メモリをもつプロセッサ装置と、デ
ィスク・ファイルなどの二次記憶域と、表示装置と、キ
ーボードやマウスなどの入出力装置から構成される。装
置サポート・ソフトウェア14は、ハードウェア装置がIB
Mのオペレーティング・システム/2（OS/2）などの周知
のオペレーティング・システム15内で機能できるように
する。
従来のワークステーションをネットワークで使用する
際、前記ワークステーションの一部になるのは、ネット
ワーク11との接続と、ネットワークを介したワークステ
ーションの間の通信をサポートするためのネットワーキ
ング・ソフトウェア16である。典型的なネットワーキン
グ・ソフトウェア16は、IBMのNetbiosプログラム製品で
ある。ここまでで説明したものは、アプリケーション・
プログラム18を実行することができる従来のネットワー
キング・ワークステーションだけである。
本発明を実施するために、各ワークステーションは、
分散協調作業環境を作成するためのアプリケーション・
プログラムの開発を容易にする協調アプリケーション・
サポート・システム・ソフトウェア17も含む。この環境
では、ワークステーションのエンドユーザは、マルチメ
ディア・チャネルを介してネットワーク中の他のワーク
ステーションのユーザと通信し、かつ共用データおよび
タスクに関して協調作業を行うことができる。
サポート・システム17の全体的な構造を、前記システ
ム17が直接インタフェースをとるワークステーションの
他のソフトウェア構成要素と関連付けて第２図に示す。
サポート・システム17の内部構造の詳細は、第10図に示
す。大まかに言って、システム17の主機能構成要素は、
点線で示した２つのインタフェース20と21の間にある。
アプリケーション・プログラミング・インタフェース
20によって、アプリケーション18はサポート・サービス
を要求することができる。装置ドライバ・インタフェー
ス21によって、システムは、トークン・リング・ドライ
バ25、ISDNドライバ26、RS232ドライバ27、その他の装
置ドライバ28などの装置ドライバを介して広範囲なソフ
トウェアおよびハードウェア通信サブシステムをサポー
トすることができる。リンク・サポート・モジュール22
8、229は装置ドライバとのインタフェースをとる。これ
らは、ワークステーションで利用可能なハードウェア・
オプションに応じて交換可能であり（第10図は、可能な
選択だけを示す）、どのハードウェアが存在するのかを
サポート・システムが正確に知らなくて済むように働
く。暗示的な資源インタフェース（図示せず）を介し
て、サポート・システムでも、アプリケーションでも、
装置ドライバでも、資源ファイル29に、ノード・アドレ
スやディレクトリ・データなどの通信ネットワークの詳
細を要求することができる。
API20によって、アプリケーション18は、多様で複雑
な通信ネットワークを介して、ノード上に配置された様
々なハードウェアおよびソフトウェア・プラットフォー
ム上で、対等アプリケーションを開始し、資源を共用す
ることができる。API20によって、アプリケーション
は、基礎物理ネットワークの構造とは独立に、広範囲の
マルチメディア・トラフィックに適した、共用アプリケ
ーション間の複数の専用論理データ・チャネルを定義す
ることができる。
API20によって、アプリケーションは共用アプリケー
ション間のデータ・ストリーミングを直列化し、同期化
し、組み合わせ、またはコピーすることができる。API2
0によって、アプリケーションは一連の接続された装置
をサポートすることができ、装置データのインターセプ
トおよびリダイレクトを可能にする。
サポート・システムは、外部アプリケーションおよび
装置とのインタフェースをとる拡張可能な１組の論理装
置30などのアプリケーション開発を助けるための他の構
成要素を含む。APIに書き込まれた、アプリケーション
からコマンド・インタフェースを介して呼び出すことも
できる１組のエンドユーザ・インタフェース（図示せ
ず）も、設けられている。
ネットワーク、ノード、およびアプリケーション 最高レベルでは、APIによって提供されるプログラミ
ング・モデルは通信ノード・セットから構成される。ノ
ードとは、ユーザを表すアドレス可能なエンティティで
あり、サポート・システム・ソフトウェアのインスタン
スと、アプリケーション・プログラム、データなどの１
組の資源を備えている。通常、ノードは、その対等サブ
システムと通信できる専用プログラムマブル・ワークス
テーション10である。マルチユーザ・システムでは、ノ
ードは各ユーザに関連づけられる。
ノードは、サポート・ノードまたは非サポート・ノー
ドである。サポート・ノードは、サポート・システム・
ソフトウェア17が実行されるものである。相互通信サポ
ート・ノードの集合をサポート・ネットワークと呼ぶ。
ノードは名前で識別される。理想的には、ノード名は
すべて特有のものであるべきだが、関連するノードが相
互通信する必要がないかぎり重複が許容される。ノード
命名方式の選択は、本発明に直接関連していない。ただ
し、インタネット・プロトコルによって定義されたよう
な階層システムは多数の利点を有する。ノードがネット
ワークに動的に参加し、あるいはネットワークを動的に
抜けられることが、アーキテクチャの基本である。
ノードは、論理装置30を含むことができる。論理装置
とは、アプリケーションがアーキテクチャ中の他のエン
ティティと矛盾せずにソフトウェアまたは装置を操作ま
たは管理できるようにするサポート・システムのソフト
ウェア拡張機能である。プレゼンテーション・ウィンド
ウ、プリンタ、ディスク・ドライバ、モデム、およびア
プリケーション・プログラムを含む広範囲の論理装置で
ある。
ノードでは、オペレーディング・システムおよびウィ
ンドウ・システムによってノードに課される制限に従っ
て、複数のアプリケーションを実行することができる。
アプリケーションは、awareまたはunawareであり、awar
eアプリケーションはAPIのサービスを使用し、unaware
アプリケーションは使用しない。awareアプリケーショ
ンとunawareアプリケーションは共に、一般に、、ノー
ドで同時に実行する。
あるノードでサポート・システムが完全に活動状態の
とき、そのノードでは１つの特定のawareアプリケーシ
ョンが動作しなければならない。このアプリケーション
は、そのノードで特有の役割を果たし、呼出しマネージ
ャ32といわれる。特定のノードでは、多数の呼出しマネ
ージャを実行することができるが、１度に１つしか実行
できない。呼出しマネージャの特別な機能は、サポート
・システムが生成するある種の事象に応答することであ
る。たとえば、呼出しマネージャはアプリケーションの
インスタンスに特定的に向けられていない要求を解決
し、かつ任意選択でノードの資源管理を処理することも
できる。呼出しマネージャの責任は、１つの呼出しマネ
ージャから他の呼出しマネージャに移すことができる。
適宜、役割をユーザ・アプリケーション機能と組み合わ
せることもできる。
サポート・システム17は、あるノードの資源を他の２
つのノードの間の通信に利用するよう要求することがで
きる。これを受動命令と呼び、許可は受動ノードにある
呼出しマネージャによって制御される。一例として、LA
N上の２つのノードＡおよびＢがあり、第３のノードＣ
が非同期通信リンクによってＢに接続されているものと
する。ＡとＣにあるアプリケーションが通信を望む場
合、トラフィックをＢを介して経路指定する必要があ
る。Ｂのノードをこのように使用するには、Ｂにある呼
出しマネージャの同意が必要である。
awareアプリケーションは、データおよび資源を、同
じノードまたは異なるノードにある他のawareアプリケ
ーションと共用することができる。共用を行うアプリケ
ーションの集合を共用セットと呼ぶ。awareアプリケー
ションは、共用要求を開始し、アプリケーション共用セ
ット、ターゲット・アプリケーション、および宛先ノー
ドを指定する。この要求はまず、サポート・ソフトウェ
アによって、送信側ノードにある呼出しマネージャに渡
される。該呼出しマネージャは通常、宛先ノードにある
呼出しマネージャに要求を転送する。通常、この第２の
呼出しマネージャは、要求されたアプリケーションをロ
ーンチし、発信元アプリケーションは通知を受ける。こ
のプロセスに呼出しマネージャが参加することによっ
て、共用プロセスのローカル制御と、必要に応じて開始
すべきその他のアクションが共に可能になる。呼出しマ
ネージャは、アプリケーションが他のノードおよびアプ
リケーションを識別するために使用する名前を処理する
上で重大な役割を果たす。共用機構は連鎖することがで
きる。たとえば、２つのアプリケーションがすでに共用
を行っている場合、それらの一方が、同じ共用セットを
指定する第３のアプリケーションとの共用を開始するこ
とができ、その結果、３つのアプリケーションはすべ
て、相互に共用を行うことになる。
アプリケーションは、他のアプリケーションに代わっ
てローカル共用要求を行うことができ、それによって、
代行すべき共用セットのメンバシップ制御を可能にす
る。共用要求の発行側またはターゲットがアプリケーシ
ョン共用セットを指定するための機能が存在する。この
ような名前は、特有のものである必要はない。したがっ
て、同じ名前の共用セットが複数存在できる。
それぞれのアプリケーションは、いつでも共用を終了
し、共用セットを抜けることができる。共用セット中の
他のアプリケーションには、このことが通知される。第
３図は、多数のアプリケーションＡないしＥの共用を示
す。この結果、第４図に示すように、共用が要求された
順序にかかわらず２つの共用セットが生成される。
通信、チャネル、およびポート 第５図の概略例に示すように、40、41、42などの共用
セット中のアプリケーションは、チャネルといわれるデ
ータ通信リンクを相互に確立することができる。43、44
などのチャネルは、論理的に専用の単一方向パイプであ
り、アプリケーションで指定された送信特性を有する。
チャネルは常に、送信側アプリケーションによって定義
され、送信側アプリケーションから受信側アプリケーシ
ョンに向かう。チャネルの端部はポートといわれる。し
たがって、チャネルはすべて、１つの送信側ポートと１
つの受信側ポートを有する。45などの送信側ポートは、
チャネルを介してパケット・データを送信する。46など
の受信側ポートはチャネルからのデータ・パケットを、
それらが送信された順序で受信する。awareアプリケー
ションに見える論理チャネル構造と、ノードの間に存在
する物理通信ネットワークの間に直接マッピングがない
場合がある。
アプリケーションは、他のアプリケーションへの複数
のチャネルを、異なるタイプのデータ・トラフィックを
分離する好都合な方法として確立することができる。第
２図のシステム・ネットワーク・マネージャ31は、論理
チャネルの一部またはすべてを、第１図のリンク11など
の単一の物理リンク上にマップすることができるが、こ
れはアプリケーションには見えない。
チャネルは、多数のサービス品質特性を有する。これ
らの特性に作成プロセス中にサポート・システム17がま
ず交渉する。これによって、データ伝送特性を、予期さ
れるトラフィックの要件に合わせて調整することができ
る。これらの特性は、暗号化、圧縮ヒントを含む。暗号
化によって、チャネルに沿った伝送時にデータを暗号化
することができる。圧縮ヒントによって、狭い帯域幅の
リンクを介してデータを圧縮するオプションがシステム
に与えられる。
サービス品質パラメータは、アナログ・データとディ
ジタル・データを区別する信号タイプによって定義され
る。サービス・パラメータは、明示的に指定しなくてよ
いが、データ・クラスに関してはサポート・システムに
通知することができる。この機構によって、ビデオ・チ
ャネル、音声チャネル、およびその他のデータ・チャネ
ルを都合よく確立することができる。チャネルの特性
は、チャネルを作成した後に再折衝することができる。
データ送信特性は、APIを介するチャネル作成呼出しで
指定された特性に応じて、第２図のデータ送信マネージ
ャ32によって実際のネットワークで実施される。
標準、組合せ、同期、および直列化の４つのチャネル
・タイプがサポートされる。標準チャネルはデフォルト
・ケースである。他のタイプは、チャネル・セットとい
われるチャネルの集合に関連して使用される。組合せチ
ャネル・セットを介して、複数のチャネルからのデータ
・パケットが組み合わされ、単一のポートを介して各受
信側アプリケーションに送られる。各アプリケーション
がすべてのデータ・パケットを同じシーケンスで受信す
ることは保証されず、各アプリケーションがすべてのパ
ケットを受信することだけが保証される。直列化チャネ
ル・セットを介して、異なるチャネルからのデータ・パ
ケットが組み合わされ、直列化され、各受信側ポートが
同じシーケンスのデータを受信するように各アプリケー
ションに送られる。同期チャネル・セットを介して、デ
ータが同期され、それによって、別々のチャネル上のデ
ータ・パケットが調子を合わせて結合される（たとえ
ば、音声とビデオ）が、そのチャネルに属するそれぞれ
のポートを介して送られる。
データ直列化の一例を第６図に示した共用ドローイン
グ・ボード・アプリケーションによって示す。２つの同
じアプリケーションＡおよびＢ（50および52）によっ
て、ユーザは単一の共用表面上で描画することができ
る。ＡおよびＢにいるユーザが同じ結果を見るには、Ａ
とＢで処理されるシーケンスが同じになるように、Ａに
あるすべての描画命令をポート53および54を介してＢに
送り、Ｂにあるすべての描画命令をポート55および56を
介してＡに送らなければならない。これは、それぞれの
アプリケーションが、共通の直列化チャネル・セット59
のメンバである２つのチャネル57および58を介して、相
互にかつそれ自体にそれ自体のデータを伝送することに
よって行われる。
第４図を参照すると、リップ同期されたビデオと音声
をアプリケーションＢ（61）に送信する必要があるアプ
リケーションＡ（60）によってデータ同期が示されてい
る。２つのチャネル62および63は送信に使用され、それ
ぞれが同じ同期チャネル・セット64のメンバである。
必要なチャネル特性を指定するサポート・システムへ
のAPI呼出しによってチャネルを明示的に作成すること
ができ、既存のポートに新しいチャネルを追加すること
もできる。後者の機構によって、異なるチャネル・セッ
トに属するチャネルを介してポートを共用することがで
きる。たとえば、単一のポートから、組合せチャネル・
セットに属する１組の宛先、および直列化チャネル・セ
ットに属する第２の組みの宛先にデータを送信すること
ができる。ディジタル・チャネルとアナログ・チャネル
が同じチャネル・セットのメンバになることはできな
い。チャネルは削除することができ、送信側ポートと受
信側ポートを指定することによって固有に識別される。
チャネルは、アプリケーション共用セットのメンバで
ある、または該メンバになるアプリケーションの結果と
して暗示的に作成することができる。たとえば、未共用
アプリケーションがすでに、組合せチャネルまたは直列
化チャネルを有する場合、使用されるチャネル・セット
名はこれらのアプリケーションのどれでも同じであり、
アプリケーションが相互に共用を行うと、必要な追加チ
ャネルが自動的に作成される。アプリケーションには、
このように暗示的に作成されたチャネルが通知される。
ポートは、事象、コマンド、または空の割り当てられ
た接続タイプを有する。事象ポートは、データが利用可
能か、または必要なときに事象を生成する。コマンド・
ポートによって、アプリケーションはデータの受信また
はポートへの供給を駆動することができる。空ポート
は、データをアプリケーションに供給できないポート、
すなわち、ビデオ・カメラの送信側ポートなどの、アナ
ログ、チャネルに関連するポートのために予約される。
ポートは、ポート事象ハンドラに送信される“signal_p
ort"コマンドを介して制御することができる。このコマ
ンドは、ローカル・ポートに発行し、チャネル中の他の
ポートに渡すことができる。通常、チャネル・ポート用
のsignalコマンドは、データを供給または受信するアプ
リケーションのポート事象ハンドラに送信され、たとえ
ば、データ・フローを停止、開始、削減、または増加す
るために使用できる。発信元とターゲットの間の信号の
順序は維持される。直列化チャネル・セット中の受信側
ポートに送信される信号は、それ自体が直列化され、そ
れによって、すべての発信元が同じシーケンスのコマン
ドを受信する。他の典型的な信号はテープ・ドライブに
対する“rewind"または“pause"、あるいはプリンタ装
置に対する“change paper size"である。
ユーザ出口は、任意選択でポートに関連付けることが
できる。これによって、データが送信側ポートに供給さ
れた後、または受信側ポートによって供給される前に、
データを監視、または操作することができる。同期チャ
ネルの場合、同期は、データが送信側ポート・ユーザ出
口を離れてから、受信側ポート・ユーザ出口に供給され
るまで実行される。
標準送信側コマンド・ポートの全体的な構造を第８図
に示す。データは、アプリケーションからの“send_dat
a"コマンドに応答して、ポート70のバッファ71中で待機
する。アプリケーションは、バッファを空にして、ユー
ザ出口72とチャネル73を介して非同期的にデータを送信
する。着信した“signal_port"コマンドは、回線75上で
チャネル73とは独立に、ポート事象ハンドラ74によって
受信され、回線76上で外部に再伝送することができる。
受信側ポートは実際上、対応する送信側ポートのミラ
ー・イメージである。標準受信側事象ポートの場合、構
造が類似しているが、この場合、事象ハンドラはデータ
とportコマンドを共に処理する。
同期を呼び出すときには状況はより複雑である。この
場合、ユーザ出口およびバッファの前に、着信側チャネ
ル上に同期プロセスを含めることによって、標準受信側
バッファ・ポートを修正しておかなければならない。
同期は論理的に、すべての事象を中央点に集合させる
ことと、その後に、各事象を、その事象のすべての宛先
に同報通信することを伴う。図では、チャネル80および
81上の２つのポートＡおよびＢの場合に関する第９図で
これを表す。この図では、直列化プロセス85で、82およ
び83でのポートＡおよびＢの出力が、ポートＣ（84）お
よび他のポート（図示せず）に対して直列化される。直
列化は、すべてのデータを、直列化し、その後に分散す
るために単一の中央点に送信することによって、該中央
点で実施することができる。直列化プロセス自体を分散
することもできる。
受信側ポートは、送信側ポートに、チャネルに沿った
データの送信を停止させ、チャネル中の残りのデータを
破棄するか、送るかのオプションを与える。後で、中断
されたデータ伝送を再開することができる。
チャネルとポートの使用を不要にするアプリケーショ
ン相互通信の代替方法は、アプリケーションの間で制御
情報を送信できるようにする“signal"コマンドを介し
て提供される。
ポートは、データ・タイプおよびデータ・サブタイプ
を指定するデータ・クラスに関連している。データ・タ
イプはデータの性質、たとえば音声、ビデオ、ファイル
などを識別し、アナログ・データとディジタル・データ
も区別する。データ・タイブはさらに、データの厳密な
フォーマットによって細分される。したがって、音声サ
ブタイプの例はG.711、G.721、G.722である。
データ・クラスは、他のアプリケーションに依存せず
に、データ・ストリーム自体とは独立に、データ・フォ
ーマットを得るためにアプリケーションによって照会す
ることができる。APIより下位でLakesが変換を実行すれ
ば、データ・タイプは、送信側ポートと受信側ポートで
異なってもよい。
ポートおよびチャネルのある種の特性、たとえばサー
ビス品質、データ・クラス、圧縮ヒントは、最初に確立
した後に変更することができる。これによって、アプリ
ケーションが実行時に通信使用法を修正するための柔軟
性が提供される。
一例は、ビデオ品質を一時的に低下させ、ファイル交換
性能を高めることである。
アプリケーションが、処理のために、入力を他のアプ
リケーションに経路指定できるように、拡張通信リンク
を確立するようにポートを接続することができる。ポー
トをこのように接続し、ユーザ出口を確立していない場
合、経路指定を確立した後、それ以上アプリケーション
を関与させる必要はない。これによって、アプリケーシ
ョンと装置の間のデータのストリーム化が可能になる。
１つのポートが送信側であり、１つのポートが受信側で
ありさえすれば、異なるデータ・クラスまたは異なる接
続タイプの、異なるサービス品質特性を有する、異なる
タイプの異なるチャネル・セット中のチャネルの間で
（１つのポートが空であるかぎり）接続が許可される。
接続が永続的になり、ローカル・アプリケーションを終
了したときでも持続するように、接続したポートをウェ
ルドすることもできる。チャネルは、すべての点で、最
初から、発信元から直接宛先まで作成された場合と同様
に動作する。存在するすべてのユーザ出口は削除するこ
とができる。
論理装置 論理装置30（第２図）は、（ｉ）クリップボード、DD
E、プリンタ、ビデオ装置などのシステム資源および装
置へのより容易なアクセス、（ii）たとえば、unaware
アプリケーションのウィンドウ内容およびファイル活動
へのアクセスを与えることによって、unawareアプリケ
ーションを協調作業に使用すること、および（iii）ア
プリケーションの関与しない端末間データ・ストリール
ム化、をイネーブルにするためにサポート・システムに
よってサポートされる。頻繁に使用される装置は、ビデ
オ・キャプチャ、ビデオ・プレイバック、オーディオ・
プレイバックなどを含み、追加装置を定義するために機
能が提供される。
論理装置はタイプによって識別される。タイプ名は、
ノードに対してローカルである。論理装置はオープンさ
れると、アプリケーションにポートを提供する。単一の
論理装置が複数のポートを有することができ、さらに、
装置は同じノードにある異なるアプリケーションに同時
にポートを提供することができる。ポートをオープンす
るための関連API呼出しによって、その装置に特有の特
性、たとえば使用すべきデータ・フォーマットを設定す
ることができる。オープンされた論理装置は、単一のポ
ートに送信される、特定の論理装置に特有のコマンドを
介して制御することができる。装置ポートへの典型的な
コマンドは、テープ・ドライブへのリワインドまたはポ
ーズである。装置の状況、たとえばデータが利用可能か
どうかを照会することもできる。
装置は、ユーザ出口が存在しないことを除き、チャネ
ル・ポートによく似ている。アプリケーションは、論理
装置上のポートをチャネル・ポートに接続することがで
きる。これによって、データは、装置との間を流れ、か
つチャネルを介して流れることができる。このデータ・
フローは、接続が確立された後、それ以上アプリケーシ
ョンを関与させることを必要としない。たとえば、デー
タをチャネルを介してカメラからカメラ論理装置までス
トリーム化し、ウィンドウ論理装置によって表示するこ
とができる。アプリケーションは２つの論理装置をそれ
らの信号ポートを介して制御することができる。もはや
伝送が必要ないとき、アプリケーションはポートを切断
し、装置をクローズし、チャネルを削除することができ
る。
装置ポートをチャネル・ポートにウェルドすることは
できない。なぜなら、こうすると、装置がローカル・ア
プリケーションの制御外に存在できるようになるからで
ある。論理装置は、サポート・システムにAPI呼出しを
発行することを許可されており、この点では、所有アプ
リケーション（すなわち、装置をオープンしたアプリケ
ーション）の代わりに働く。装置はたとえば、その所有
アプリケーションに、他のアプリケーションと供用を行
わせ、チャネルを作成させ、かつデータを送受信させる
ことができる。
潜在的な装置には以下のようなものがある。
−システム・クリップボード −LPTx −DDE −ウィンドウ −共用クリップボード −プリンタ −直列エミュレータ −ファイル −ビデオ −符復号器 −オーディオ −電話 クリップボードの共用は、システム・クリップボード
装置および共用クリップボード装置によって容易にな
る。システム・クリップボード装置をアプリケーション
によってオープンして、そのノードでのウィンドウ・シ
ステム・クリップボードへのアクセスを与える送信側ポ
ートおよび受信側ポートを提供することができる。いつ
でも送信側ポートは１つしか存在できないが、そのノー
ドにあるどのアプリケーションでも受信側ポートをオー
プンすることができる。チャネルを使用すると、あるノ
ードからのシステム・クリップボード・データを単純
に、アプリケーション共用セットの他のメンバに経路指
定することができる。
他の装置、共用クリップボードは、データ共用を容易
にするために提供されている。共用クリップボードは共
用セットに特有のものである。送信側ポートは１つしか
許可されないが、複数の受信側ポートがサポートされ
る。これらの違いは別として、共用クリップボードは、
システム・クリップボードと同様に動作し、アプリケー
ションが共通データを共用するための単純な機構を提供
する。
ウィンドウ装置によって、画面上に定義されたウィン
ドウを送信側ポートまたは受信側ポート（状況によって
はその両方）と関連付けることができる。送信側ポート
をチャネル・ポートに接続することができ、データをウ
ィンドウにストリーム化して表示することができる。様
々なデータ・フォーマットがサポートされる。
DDE装置をオープンして、動的データ交換機構に結合
された送信側ポートおよび受信側ポートを提供すること
ができる。awareアプリケーションは、この装置を介し
て、DDEをサポートするアプリケーションを制御し、あ
るいはそれ自体を制御することができる。さらに、適切
なチャネルを確立することによって、２つのリモートDD
Eアプリケーションをリンクすることができる。
プリンタ装置によって、データをシステム・プリンタ
に送信することができる。送信側ポートは１つしか許可
されない。
非同期直列装置は、１つの送信側ポートと複数の受信
側ポートをサポートし、RS232、RS422、およびその他の
直列通信とのインタフェースをとる。
ビデオ・ディスプレイ・プレイバック装置（IBM/イン
テル・アクションメディアIIアダプタ/A（IBM/Intel Ac
tionMedia II Adapter/A）をサポートする）、ビデオ・
キャプチャ装置（IBM Mビデオ・キャプチャ・アダプタ/
A（IBM M-Video Capture Adapter/A）をサポートす
る）、オーディオ・キャプチャ・プレイバック装置（IB
M Mオーディオ・キャプチャ・プレイバック・アダプタ/
A（IBM M-Audio Capture and Playback Adapter/A）を
サポートする）、およびその他の特殊オーディオ／ビデ
オ装置（H320準拠符復号器などの）を含む、多数のビデ
オおよびオーディオ装置が存在する。
awareアプリケーションの多くはシステム・ユーティ
リティとして出荷されており、これらの装置を利用し
て、ネットワークを介した協調作業のための汎用エンド
・ユーザ機能を提供する。
カストマイズ サポート・システム17用のカストマイズ情報は、適切
なプラットフォーム指定リポジトリに記憶される。Wind
owsおよびOS/2の場合、この情報は、LAKES.INIおよびLA
KESQOS.INIと呼ばれるファイルである。これらのファイ
ルは、キーワードとその値が維持される、識別子で始ま
るセクションを含む標準ASCIIファイルとしてフォーマ
ットされる。アプリケーションは、それ自体の追加初期
設定フィールドを有することもできる。LAKES.INIは、
構成および始動オプション、awareアプリケーション、
装置、および物理通信リンクに関する情報を含む標準セ
クションを含む。そのようなアプリケーションに特有の
データを含むアプリケーション・セクションを存在させ
ることもできる。LAKEQOS.INIは、物理リンクおよびデ
ータ・クラスに関するサービス品質情報を含む。これら
のファイルにアクセスし、それらを更新するための呼出
しはAPIに提供されている。
資源管理 協調作業では多くの場合、ノードが所有する資源、た
とえばプリンタ装置を他のノードと共用できることが必
要になる。そのような資源は、グローバル資源とみなさ
れ、アクセスはグローバル・トークンを介して制御され
る。その他の資源、たとえば共用ポインタは、アプリケ
ーション共用セットにローカルであり、これへのアクセ
スはアプリケーション・トークンを介して管理される。
トークン所有者は、トークンの重要度を判定し、それ
を要求上に割り振る。所有者の裁量で、待機中の要求を
許可することができ、特定のトークンの複数の同時保持
者を許可することができる。トークン所有者、任意選択
で、保持者にトークンを戻させることができる。
グローバル・トークンは、ネットワーク全域にわたっ
て共通名前空間を共用するが、アプリケーションは、そ
れが必要とするるグローバルに利用可能な資源の位置を
知っているとみなされるので、重複グローバル・トーク
ン名が許可される。可用性情報を同報通信するための機
能は提供されない。その代わり、グローバル資源をもつ
ノードにある呼出しマネージャは、資源管理の責任を負
い、したがって、あらゆるグローバル・トークンを保持
する。グローバル・トークンは、アプリケーション・イ
ンスタンスによって排他的に保持し、あるいは共用する
ことができる。しかし、トークン所有権をアプリケーシ
ョンに移すことはできない。グローバル・トークンを求
める要求は、APIより上位で保持され、ノード呼出しマ
ネージャによって管理される待ち行列によって待機させ
ることができる。グローバル・トークンへのアクセスは
共用アプリケーション・セットだけに制限されない。
アプリケーション・トークン名空間は、アプリケーシ
ョン共用セットだけに制限されない。トークンはどのメ
ンバ・アプリケーションでも所有することができ、所有
権を移すことができる。アプリケーション・トークンは
排他的に保持し、あるいは共用することができ、トーク
ンに対する要求は、APIより上位で保持され、現アプリ
ケーション・トークン保持者によって管理される持ち行
列で待機することができる。
初期設定および終了 サポート・システムは、LAKES.EXEファイルを動作さ
せることによって始動される。このファイルは、ファイ
ルLAKES.INIからプロファイル・データを読み取る。指
定された呼出しマネージャが、サポート・システムによ
って始動され、次いで、それ自体をawareアプリケーシ
ョンとして登録する。次いで、“set_call_manager"コ
マンドがこの特定のアプリケーションをそのノード用の
呼出しマネージャとして確立する。このコマンドの後
に、サポート・システムはそのノードで完全に活動状態
になり、着信事象および要求を処理できるようになる。
awareアプリケーションは、アイコンのダブル・クリ
ックなどの通常のオペレーティング・システム手順、ま
たは “launch"コマンドによって開始することができる。前
者の場合、アプリケーションはサポート・システムに登
録され、リターン・データで、アプリケーション・ハン
ドルおよびノード・ハンドルを受信する。呼出しマネー
ジャにこの登録のことが通知され、アプリケーションへ
のハンドルが供給される。後者の場合、ローンチする側
のアプリケーションにアプリケーションへのハンドルが
返される。ローンチされる側のアプリケーションがサポ
ート・システムに登録されるまで、このハンドルは非常
に限られた状況でしか有効ではない。リターン・データ
は、ローンチされる側のアプリケーションにアプリケー
ション・ハンドルとノード・ハンドルを提供する。呼出
しマネージャと、ローンチを指定したアプリケーション
（呼出しマネージャと異なる場合）は共に、適宜、通知
を受ける。
アプリケーションは、登録が取り消され、呼出しマネ
ージャが通知を受けることによってunawareアプリケー
ション状況に戻ることができる。保持されているすべて
のトークンが解除され、トークン所有者が通知を受け、
所有されているすべてのトークンが無効になる。アプリ
ケーションがアプリケーション共用セットのメンバであ
る場合は削除され、該アプリケーションが前記セットを
抜けたことが他のメンバに通知される。アプリケーショ
ンによって作成されたすべてのポートが破壊され、影響
を受けるチャネルへのポートを所有する他のアプリケー
ションが通知を受ける。終了するアプリケーションによ
って接続されたすべてのチャネルがウェルドされ、端末
チャネル・ポートで適切な事象がレイズされる。適切な
事象をレイズすることは、ローカル呼出しマネージャ
と、登録を取り消す側のアプリケーションに代わって、
ウェルドされたチャネルをサポートするあらゆるノード
の呼出しマネージャに必要である。オープンしている論
理装置はすべてクローズされる。ポートに接続された論
理装置がある場合は登録取消しプロセスの一部として破
壊され、次いで、接続されたチャネル全体が破壊され、
適当な事象がレイズされる。
ノードにあるサポート・システムを通常の方法でクロ
ーズするために、アプリケーションによって遮断要求を
発行すことができる。これによって、ローカル呼出しマ
ネージャで事象がレイズされ、呼出しマネージャが要求
を受け入れる場合は、他のアプリケーションで対応する
遮断事象がレイズされる。次いで、これらのアプリケー
ションは閉止し登録を取り消す準備をして、各登録取消
しが呼出しマネージャに通知される。すべてのアプリケ
ーションが登録を取り消したことが呼出しマネージャに
通知された後、前記呼出しマネージャも登録を取り消し
て遮断を完了する。
サポート・システムの通常の操作は、呼出しマネージ
ャの存在によって変化する。既存の呼出しマネージャを
他の呼出しマネージャと交換することが可能であるが、
既存の呼出しマネージャは、その要求を拒否することが
できる。
アプリケーションは、“share_app"要求を発行してア
プリケーション共用セットを指定することによって、共
用セット中の他のアプリケーションに加わることができ
る。通常の場合には、ターゲット・アプリケーションと
ノードを共に名前で指定する。あるノードにあるアプリ
ケーションが他のノードにすでに存在するアプリケーシ
ョン・インスタンスと名前によって共用を行いたい場合
の手順は次のとおりである。ノード１にあるapp1が、そ
れ自体のアプリケーション・ハンドルおよびノード・ハ
ンドルを発信元として、app2およびノード２の名前をタ
ーゲットとして指定した“share_app"要求を発行する。
ノード１にある呼出しマネージャによる検証の後、サポ
ート・システムによって、ノード２にある呼出しマネー
ジャに適切な要求が送信される。この呼出しマネージャ
が要求を受け入れる場合、要求はapp2上に渡され、app2
は、それが共用の受入れを希望していることを示す確認
を返すことができる。この方式は、アプリケーション共
用においてかなりの柔軟性を提供する。各呼出しマネー
ジャは、アプリケーションが“share_app"要求の発信元
であれ、ターゲットであれ、そのノードでの共用活動を
知る。
呼出しマネージャは、共用要求の受信時に、（ｉ）共
用自体を処理する、（ii）共用要求を転送する、（ii
i）共用を拒否する、（iv）共用を処理する新しいアプ
リケーションをローンチする、（ｖ）アプリケーション
およびノード名を変更するというオプションを有する。
アプリケーションは、ローンチされるとき、アプリケ
ーション共用セットのメンバではない。発信元アプリケ
ーションは、“share_app"要求を発行するとき、その結
果得られる共用セットを命名するオプションを有する。
共用セットを命名しない場合、ターゲットが名前を供給
しなければならない。共用を行った後、ターゲットと発
信元は共に、この名前の新しい共用セットに加わる。発
信元またはターゲット、あるいはその両方がすでに、こ
れと同じ名前の共用セットのメンバだった場合、それら
の共用セットは新たに作成された共用セットと組合され
る。アプリケーションは、“unshare_app"要求を使用し
て共用セットを抜けることができる。
データ送信および受信 アプリケーションがデータを交換するための機構が４
つある。
（ｉ）ユーザ情報文字列 これは実際上、API呼出し中のパラメータとしてサポ
ート・システムに渡され、次いでターゲット・アプリケ
ーションに渡される文字列である。
（ii）信号関数呼出し このコマンドは、アプリケーションの間で制御情報を
送信できるようにし、単一の共用セット内のアプリケー
ションだけに制限されない。使用されるAPI呼出しに応
じて、応答が提供されることも、提供されないこともあ
る。この方法が異なるノード自体のデータ制御フローの
ために該ノード上のサポート・システムの間に確立され
た通信経路を使用するため、この技術は、軽いデータ・
トラフィックに制限されることに留意されたい。
（iii）チャネル送信 チャネルは、アプリケーションの間のボリューム・デ
ータの転送をサポートするものである。チャネルは、転
送特性を制御する手段だけを提供する。チャネルの使用
は、同じアプリケーション共用セット内のアプリケーシ
ョンだけに制限される。チャネルの作成を要求する際
は、ターゲット・アプリケーション・ハンドル、チャネ
ル・セット・タイプおよび識別子、データ・クラス、最
大バッファ・サイズ、ユーザ出口、ノード・ハンドル、
サービス品質、接続タイプ、ポート事象ハンドラ、ユー
ザ情報の情報を指定する。チャネル作成の代替手法は、
既存の組合せチャネル・セットまたは直列代チャネル・
セットをもつアプリケーションがアプリケーション共用
に関与しているときに作成されたチャネルを利用するこ
とである。
データは、アプリケーションによってチャネルを介し
てデータ単位で送信される。物理レベルでは、データ送
信の単位はフレームである。ある種のデータはスポイル
可能である。すなわち、ある状況の下では、サービス品
質要件を満たすようにデータを送れない場合、そのデー
タを破棄することができる。パケットによっては、スポ
イル可能とマーク付けできるものと、そうできないもの
がある。スポイラ・パケットは、存在する場合、それに
関連するスポイル可能パケットを削除する。この技術は
たとえば、あるパケットがデルタ・フレーム・パケット
で、他のパケットが完全フレーム・パケットである、ビ
デオ用のバッファ管理方式の実施態様をサポートする。
完全フレームが利用できる場合、選択されたデルタ・フ
レーム・パケット・シーケンスを削除することができ、
かつ削除しなければならない。
（iv）論理装置 ある特殊な状況では、論理装置を使用してデータを交
換するのが妥当である。単一の論理装置が、複数のアプ
リケーションにポートを提供することができる。論理装
置は次いで、ポートの間でデータを移動することができ
る。この転送機構は、同じ共用セット内のアプリケーシ
ョンだけに制限されず、したがってチャネルに課された
限界を解消する。しかし、論理装置は複数のノードをカ
バーすることはできない。さらに、必要なサービス品質
サポートは、特定の論理装置によって明示的に提供しな
ければならない。
サービス品質の折衝 アプリケーションは、サービス品質および帯域幅の折
衝および制御に関して異なるニーズを有する。たとえ
ば、以下のものが必要になることがある。
○事前に決定された一定のサービス品質、たとえばG.71
1音声 ○チャネル作成時に柔軟であり、その後は一定である要
件、たとえばファイル転送 ○チャネル資源の単一アプリケーション管理、たとえ
ば、制限された帯域幅条件の下で、すなわち、データ・
トラフィックを許可するためにビデオ品質を間欠的に低
下させなければならない場合に、アプリケーションがビ
デオ、音声、データなどの複数のデータ・タイプを伝達
する。
○チャネル資源のアプリケーション間管理、たとえば、
一群のアプリケーションが、制限された帯域幅条件の下
で複数のデータ・タイプを伝達し、該データ・タイプの
活動を、異なるタイプのデータ・トラフィックのための
優先順位変更として調整する。
ある種のアプリケーションは、他のアプリケーション
と通信するのに必要なチャネルの固定サービス品質要件
を有する。このような場合には、“create_channel"要
求を使用してチャネルを直接確立することができる。こ
の要求上のパラメータは、受信側アプリケーションと、
チャネルと送信側ポートとの特性を識別する。資源が利
用可能であり、受信側アプリケーションが要求を受け入
れる場合、チャネルが作成される。
一部のアプリケーションは、サービス品質要件がより
柔軟であり、特定のノードに何が利用可能かを判定し、
次いで“create_channel"要求のパラメータを設定する
際にこの情報を使用する必要がある。これは、ターゲッ
ト・ノードを指定する“query_resource"コマンドを介
して行う。この後の“ceate_channel"は、通信資源を求
める競争がない場合、前と等しいか前よりも低いサービ
ス品質を要求して、要求を満たしてもらうことができ
る。
他のアプリケーションは、柔軟なサービス品質要件を
有するが、多数のチャネルに対して指定を行う必要があ
る。このためには、アプリケーションが資源を予約し、
次いでこの予約されたプールから割振りを行う必要があ
る。
これは、資源セット識別子、サービス品質、およびタ
ーゲット・ノードを指定する“claim_resource"コマン
ドによって行う。このコマンドは、その資源を予約し
て、指定された識別子と関連付ける効果を有する。この
識別子は次いで、その後の“create_channel"コマンド
で指定することができ、この場合、そのようなリザーブ
から資源が割り振られる。
“query_resource"コマンドを使用して、資源セット中
の残りの資源を判定することができる。
ある種のアプリケーションは、実行時にチャネル特性
を動的に変更する必要がある。たとえば、利用可能な帯
域幅をチャネルごとに再割振りしなければならない。こ
れは、資源セット識別子を指定する“change_channel"
要求を介して行うことができる。資源は、その識別子に
関連する資源に与えられ、あるいは後者の資源から取ら
れる。この技術によって、たとえば、固定資源をアプリ
ケーション間通信用に確保し、次いで、トラフィックに
応じて動的に再割振りすることができる。たとえば、ビ
デオ帯域幅を一時的に削減して、より高速のファイル転
送を可能にすることができる。
資源セット識別子は、アプリケーション・インスタン
スにローカルであり、１つの特定のサービス品質に適し
た資源を含む。
ネットワーク アプリケーションは、チャネルを作成する際に、ある
いは後でチャネルに割り振るために資源を予約する際
に、サービス品質特性を指定することができる。この場
合、チャネルは物理リンク上にマップされる。論理チャ
ネルを介してアプリケーションによって送信されるデー
タ・パケットは、リンクを介して送信されるデータ・フ
レームとして実施される。
リンクは交換リンクであれ固定リンクであれ、順序
と、タイムアウト・パラメータと、サービス品質特性に
よって特徴付けられる。順序は、サポート・システム
が、適切なデータ送信特性があればリンクの選択が可能
であると仮定して、リンクをデータ送信に使用しようと
する順序を決定する。交換リンクであれ、固定リンクで
あれ、順序とタイムアウト・パラメータは初期設定ファ
イルに指定する。
任意選択でサービス品質特性を含むリンク記述は、サ
ポート・システムの外部のリンク・データベータに記憶
される。サービス品質情報用のデフォルトは初期設定フ
ァイルに含まれている。データベースは、サポート・プ
ログラムによって呼び出される、導入先が供給した実行
可能ファイルによってアクセスされる。ディジタル・リ
ンクに関連するサービス品質パラメータは、スループッ
ト、待ち時間、ジッタ、フレーム・サイズ、フレーム・
エラー・レート、フレーム再伝送時間、圧縮ヒント、暗
号化である。
アプリケーションが論理チャネルを介して必要とする
サービス品質を特徴付けるために使用される主要パラメ
ータは、スループット、待ち時間、ジッタ、パケット・
サイズ、パケット・エラー・レート、暗号化、圧縮ヒン
ト、優先順位である。サポート・システムが、チャネル
の間に資源競合が存在すると仮定して、そのノードにあ
るすべてのチャネルを介したデータ送信を実行しようと
する順序を指定するチャネル優先順位と、送信の損失ま
たはエラーのために送る必要のない受入れ可能なランダ
ム比率のパケットを指定するパケット・エラー・レータ
（サポート・システムがこのような限定に従うという保
証はない。ここでゼロを指定すると、アプリケーション
にあらゆる失敗が通知される）を除き、これらのパラメ
ータの大部分は、対となるリンクを反映する。
上記の情報は、アプリケーション間通信にどのリンクを
使用すべきかを判定するために使用される。リンクのタ
イプやサービス特性などの情報を含むデータベースは資
源イタフェースを介してアクセスできるが、チャネル情
報はアプリケーションから得られる。サポート・システ
ムは次いで、（ａ）異なるノードにあるサポート・シス
テムの間で制御情報を交換する必要と、（ｂ）リンクに
関連する順序値とを考慮に入れて、完全に満たされたチ
ャネル要件と、完全に満たされた利用可能リンク情報と
の一致に基づいて、使用するのにふさわしいリンクを選
択する。
ソフトウェアおよびハードウェアの圧縮と暗号化が共
にサポートされる。物理リンク上のハードウェア機構
は、オプションの様々な組合せを、それぞれが特定の転
送特性に関連する異なる利用可能リンク・タイプとみな
すことによって収容される。ソフトウェア・ルーチンも
使用できるが、特定の待ち時間要件およびジッタ要件を
設定していない場合は呼び出されない。
リンク情報を検索するために使用されるRLI呼出し
も、必要に応じて、サポート・システムの外部で複雑な
経路選択プロセスを実行できるようにするために、すべ
ての必要なチャネル・サービス品質特性を供給する。こ
の機構を介して、外部ルーチン自体が、適切な経路を決
定し、その経路をサポート・システムに返すことができ
る。この必要がある例は、送信コストが時刻によって代
わることであろう。
チャネルをもつアプリケーションが相互に共用を行う
とき、アプリケーションの既存のチャネルが同じ名前の
組合せチャネル・セットまたは直列化チャネル・セット
に属する場合、サポート・システムは追加チャネルを作
成する。そのポートにふさわしいサービス品質によっ
て、各送信側ポートからこのような新しいチャネルを確
立することが試みられる。すなわち、暗示的に作成され
たチャネルが、そのポートから１つの既存のチャネルを
介して送信する予定のデータ・パケットを首尾よく転送
できるような特性をもとうとする。場合によっては、利
用可能な物理リンクの機能によって課される制限のため
に、そのような特性をもつチャネルを作成できないこと
もある。しかし、すべての場合に、チャネルが作成さ
れ、チャネル機能が重要である可能性が大きい場合、そ
れを照会することは、アプリケーション・プログラムの
責任である。
ノードの間のチャネルは、単一の物理リンクまたは複
数の直列接続リンクを介して実現することができる。２
つのノードの間に存在する物理接続を経路と呼ぶ。
ａ）永続ディジタル・ネットワーク サポート・システムは、専用リンクであれ、共用リン
クであれ、交換リンクであれ、永続リンクであれ、ノー
ドの間のディジタル・リンクと共に動作する。共用リン
クは、帯域幅管理機能を使用しないかぎり、予測できな
い待ち時間特性および帯域幅特性を有する。そのような
特徴によって、永続リンクには交換接続の特性が多数与
えられている。
ｂ）永続アナログ・ネットワーク サポート・システムは、以下の状況で、ディジタル通
信と非常に類似した方法でアナログ通信をサポートす
る。
○ノードの間にアナログ・リンクが存在する。
○各ノードでの接続性および経路指定を、そのノードに
あるシステムによって制御することができる。
○ノードの間にディジタル制御チャネルが存在する。
アナログ・チャネルは、送信側アプリケーションによ
って確立される論理的に専用の単一方向通信リンクであ
り、複数の受信側のアプリケーションで終了することが
できる。このチャネルは、そのサービス品質特性によっ
てディジタル・チャネルと区別することができる。この
アナログ・チャネルを終了するポートは、アプリケーシ
ョンにデータを供給することも、アプリケーションから
データを受信することもできないので、空接続タイプを
有する。標準チャネルまたは組合せチャネルだけしか確
立できず、直列化チャネルおよび同期チャネルは許可さ
れない。
論理装置は、オープンされると、アナログ・ポートを
提供することができる。したがって、ビデオ・プレーヤ
装置をアナログ・ビデオの発信元として使用することが
でき、APIコマンドを介してアナログ・チャネルに接続
することができる。アナログ・チャネルとディジタル・
チャネルの直接接続は許可されない。しかし、ある装
置、たとえば符複合器は、オープンされるとアナログ・
ポートとディジタル・ポートを共に提供し、そのような
結合を有効化するために使用することができる。
ｃ）交換ディジタル・ネットワーク 交換ディジタル・ネットワークは、接続の交換性の影
響を受けずに、サポート・システムによってノード間通
信に使用することができる。資源インタフェースを介し
てアクセスされた情報は、非活動状態の交換接続をいつ
終了すべきかを決定するためにシステムによって使用さ
れる。
交換ネットワークに接続された、ディジタル電話など
の機器は、アプリケーションによって２つの方法のうち
の１つでアクセスされる。簡単な接続だけが必要な場
合、電話を仮想ノードで実行する仮想電話アプリケーシ
ョンとみなすことができる。電話との接続は、仮想ノー
ドをターゲットとして指定する共用要求によって開始さ
れ、ローカル・ノードに関連する電話とリモート電話の
間に電話呼出しが確立される。着信電話呼出しは同じよ
うに、すなわち共用要求として処理することができる。
電話を論理装置としてアクセスすることもできる。し
たがって、ISDN電話装置をオープンして、関連する事象
接続タイプまたはコマンド接続タイプの受信側ポートお
よび送信側ポートを提供することができる。ダイアリン
グおよびその他の制御機能は、“signal_port"コマンド
を介して実施される。ディジタル電話機器の間のサード
・パーティ接続は同様に、該当する装置へのコマンドに
よって影響を受ける。これは、ローカル・スイッチへの
コマンドを介して物理的に実施される。
データまたは経路指定を動的に修正する潜在的に活動
状況の分岐制御装置、たとえばオーディオ・ビジュアル
通信用のCCITT勧告を実施するMCUをアプリケーションに
対する装置として使用することもできる。
ｄ）交換アナログ・ネットワーク 公衆交換網に接続されたアナログ電話およびその他の
機器は、ディジタル電話と同様に、仮想ノードで実行す
る仮想電話アプリケーションとして、または論理装置を
介してアクセスすることができる。PSTN電話論理装置を
オープンして、空接続タイプのポートを提供することが
できる。すなわち、該ポートはアプリケーションにデー
タを供給することも、アプリケーションからデータを受
信することもできない。
“signal_port"コマンドは、装置を制御するために使用
される。ファースト・パーティ接続は、ローカル回線に
ダイアリング・トーンを挿入するモデム、サード・パー
ティ接続、およびローカル・スイッチへのコマンドを介
する多方向呼出しを介して実施することができる。
unawareアプリケーションとのインタフェース サポート・システムは、unawareアプリケーションを
協調作業に使用できるようにする機能を提供する。awar
eアプリケーションは、ユーザ・インタフェース・ダイ
アログを供給し、仮想装置を介して特定のunawareアプ
リケーションと対話する。この同じawareアプリケーシ
ョンは次いで、リモート・ノードにある関連awareアプ
リケーションと通信し、リモート・ユーザに情報を渡
す。そのようなアプリケーションの幾つかは、汎用ユー
ティリティとして含められている。
共通要件は、第11図に示すように、unawareアプリケ
ーションのアプリケーション・ウィンドウをリモート・
ノードで表示することである。実施態様は次のとおりで
ある。ノードＸにあるawareアプリケーションAXがユー
ザと対話して、ここではunawareアプリケーションUXと
仮定された必要なウィンドウを識別する。AXは次いで、
適切なパラメータによってウィンドウ表示論理装置をオ
プーンする。この効果は、ウィンドウ・データのコピー
を得るためのポートを生成することである。AXは、宛先
ノードＹにあるawareアプリケーションAYに至るチャネ
ル上のポートにこれを接続する。AYは次いで、実際のウ
ィンドウ論理装置をオープンして、作成されたポートを
受信側チャネル・ポートに接続する。データがノードの
間を流れ、それ以上アプリケーションAXにもAYにも干渉
されずにＹで表示される。ウィンドウ論理装置オープン
要求で利用可能なオプションによって、アプリケーショ
ンはビット／ピクセル、更新の頻度、データ・フォーマ
ット（たとえば、テキスト、ビット・マップ、および組
込みポインタ位置のオプション）などのパラメータを指
定することができる。
unawareアプリケーションUXの共用ウィンドウ上のリ
モート・ポインタをAXおよびAYで処理し、対話型データ
・クラスに適したチャネルをセット・アップすることが
できる。次いで、各ノード上に実際のポインタを使用し
て、共用ウィンドウ中の機能を識別する。これは、指示
したい各ユーザがポインタを共用ウィンドウ内に移動す
る、などのアルゴリズムによって行うことができる。ポ
インタが共用ウィンドウ中にあるとき、その座標が共用
アプリケーションに送信される。次いで、組合わされた
座標を使用して、ポインタが制御される。この結果、だ
れであれ、最後にカーソルを移動した人が、すべてのリ
ンクされたポイントを位置決めすることになる。
リモート印刷とリモート・ファイル生成は同様に、論
理装置を介して行う。印刷の場合、発信元ノードにプリ
ンタ・エミュレータ装置を設置する。この装置がユーザ
によってプリンタ装置として選択されると、その結果、
プリンタ・データ・ストリームがポートにリダイレクト
される。このストリームは次いで、awareアプリケーシ
ョンを介して、宛先ノードにある実際のプリンタ装置に
接続される。この汎用技術は、動的データ交換（DDE）
やシステム・クリップボードなどの他の機能の範囲で拡
張される。
アプリケーションまたはシステムのリモート制御は直
接には供給されない。しかし、リモート制御を実行する
アプリケーションをAPIより上位で実現することがで
き、Lakesはグループ通信およびマルチメディア・デー
タ送信機能を提供する。
プログラミングの留意事項 ａ）プログラム呼出しタイプおよび構造 APIへのプログラム呼出しは一般に、要求、指示、応
答、確認シーケンスになる。サービスを必要とするアプ
リケーションＡは、適切なパラメータを供給してそのサ
ービスを要求する。要求は通常、他のアプリケーション
Ｂにその要求を認識させることを必要とする。このため
の機構は、アプリケーションＢで指示として出現する非
送信請求事象である。この指示事象に対してＢが取るア
クションは、適切なデータをもつ応答としてサポート・
システムに与えられる。システムは、この情報を確認事
象として再びアプリケーションＡに渡す。これを、チャ
ネルにポートを追加する上で関与するシーケンスの例を
使用して第12図に示す（図を単純にするために、パラメ
ータはいっさい示さない）。
API呼出しは、特定の機能に応じて、同期呼出しでも
非同期呼出しでもよい。同期呼出しは、要求が完了する
と制御を戻す。非同期呼出しはただちに制御を戻す。ア
プリケーションが非同期呼出しの進行を監視できるよう
にするために、これらの呼出しは参照識別子を含む。こ
の識別子は、要求が満たされ、状況を得るために照会を
発行できるようになるまで、有効である。この同じ識別
子を使用して、保留中の要求を取り消すこともできる。
呼出しはすべて、呼出し状況を示すリターン・コードを
返す。
ｂ）アドレス可能性 アプリケーションは、ノード名を使用してノードへの
アドレス可能性を要求する。この名前はまず、それを修
正するオプションを有するローカル呼出しマネージャに
渡される。その結果得られる名前は次いで、接続性情報
を判定するためにサポート・システムによって使用され
る。接続性情報の判定は、資源インタフェースを使用す
る、外部に保持されたネットワークおよびユーザ・デー
タベースへのアクセスを必要とする。したがって、サポ
ート・システムは、第２図の資源インタフェース29を介
するネットワーク構成への照会を介してその名前に関す
る物理アドレス可能性を判定する。このノード名の分解
能を反映するノード・ハンドルがアプリケーションに返
される。１つのアプリケーションから他のアプリケーシ
ョンへのアドレス可能性にはアプリケーション名の分解
能が必要である。両方のアプリケーションが同じノード
にある場合、ローカル呼出しマネージャがこの分解能を
実行することができ、そうでない場合は、両方の呼出し
マネージャが関与しなければならない。この分解能の結
果、アプリケーション・ハンドルによって、ターゲット
・アプリケーションが発信元アプリケーションに対して
識別される。アプリケーション名を使用する呼出しは常
に、分解能のために呼出しマネージャに渡される。アプ
リケーション・ハンドルを使用する呼出しは、指定され
たアプリケーションに直接向かう。
アプリケーションがチャネルを作成するとき、チャネ
ル・ポートへのアドレス可能性が、ポート・ハンドルを
返すシステムを介して提供される。同様に、論理装置を
オープンすると、装置ポート・ハンドルが得られる。
すべてのハンドルは、使用する側のオプリケーション
に特有のものであるが、他のアプリケーションまたはノ
ードに渡される場合は有効でなくなる。
ｃ）事象クラスおよび事象ハンドラ API要求は、事象および呼出し制御を援助するために
提供される。“begin_monitor"要求によって、アプリケ
ーションはノードでの要求および事象を監視することが
できる。監視の範囲は、以下のものの１つから監視クラ
スを選択することによって制御される。
All:すべての事象またはAPI呼出し Application Signalling:信号事象/API呼出し Call_manager:呼出しマネージャ事象/API呼出し Data:データ送信事象/API呼出し Device:装置事象/API呼出し Monitor:モニタ事象/API呼出し Port:ポートおよびチャネル事象/API呼出し Profile:プロファイル事象/API呼出し Share:共用および非共用事象/API呼出し Synchronisation:同期事象/API呼出し Token:トークン事象/API呼出し 監視の範囲は事象クラス・レベルまたはAPIクラス・
レベルで制御される。事象は、データがあってもなくて
も監視することができる。監視は、“end_monitor"コマ
ンドによって終了する。アプリケーションは、“enable
_events"コマンドおよび“disable_events"コマンドを
使用して、どの事象を受信すべきかも決定する。有効な
事象クラスは以下のとおりである。
All:すべての事象 Device:装置事象 Port:ポートおよびチャネル事象 Profile:プロファイル事象またはAPI呼出し Sharing:共用要求事象またはAPI呼出し デフォルトの事象ハンドラは、アプリケーションを介
して明示的に処理されないすべての事象に対する応答を
生成する。事象は、登録された事象ハンドルによって処
理される。
awareアプリケーションには４つのタイプが存在でき
る。
Application:これは、一時事象ハンドラであり、awar
eアプリケーションの一般動作に関連する主な事象を処
理する。この事象ハンドラは、呼出しマネージャを含む
すべてのawareアプリケーションに存在しなければなら
ない。
Call_manager:これは幾分特殊であり、アプリケーシ
ョン登録、名前分解能、遮断要求、受動ノード、呼出し
マネージャ転送、およびグローバル・トークン状況に関
する事象を処理する。この事象ハンドラがすべての呼出
しマネージャになければならない。
Port_event handler:複数のポート事象ハンドラが存
在でき、それぞれがデータ通信関連事象を処理する。
Monitor:これは任意選択で存在し、すべての事象監視
を処理する。
ｄ）その他のプログラミング機能 データ・トラフィックを監視し、あるいはデータを処
理するように、すべてのチャネル・ポートをユーザ出口
と関連付けることができる。送信側ポートの場合、ユー
ザ出口は、データが受信側ポートに送信される直前に呼
び出される。受信側ポートの場合、ユーザ出口は、デー
タが受信側ポートに到着した直後であるが、受信側アプ
リケーションに提供される前に呼出される。データはユ
ーザ出口に移動しなければならないので、接続されてい
るポート上にユーザ出口ルーチンを指定すると性能に影
響が及ぶことがある。
アプリケーションが状況情報を追跡しなくて済むよう
に、完全な１組の照会が提供されている。
アプリケーション・プログラム・デバッグは、最初に
単一のノードで協調アプリケーションを動作させること
によって簡単にすることができる。これによって、プロ
グラム開発の初期段階で物理ネットワークが不要にな
る。
APIより下位にユーザ・インタフェースは存在しな
い。すべてのユーザ対話は、アプリケーション・プログ
ラム、または資源インタフェースを介して要求を実行す
るコードの責任である。
ユーティリティ コマンド・インタフェースを介してアクセス可能な共
通機能を提供することによって、エンド・ユーザに有用
な機能をただちに提供し、新しい協調アプリケーション
を開発するのに必要なプログラミング作業を削減するた
めに、多数の事前にプログラムされたユーティリティが
提供されている。
すべてのユーティリティは交換可能なアプリケーショ
ン・プログラムである。提供したユーティリティの構造
を第13図に示す。供給したユーティリティは、プログラ
ム・グループとしてインストールされ、協調する一連の
アプリケーションとして設計されている。主要なユーテ
ィリティ機能は、ユーザが直接呼び出すだけでなく、
“signal"コマンドによって他のアプリケーション・プ
ログラムから呼び出すこともできる。
ａ）ディレクトリおよび呼出し管理 ｉ）アドレス・ブック アドレス・ブック・ユーティリティ100によって、エ
ンド・ユーザはディレクトリおよび接続性情報を追加
し、削除し、更新することができる。データは、標準プ
ログラムで容易に編集される簡単なファイル構造に記憶
される。ただし、他の潜在的により広範囲で複雑なアド
レス・データベースとのインタフェースをとるための機
構が提供されている。ユーザ・データをフォーン・ブッ
クという論理集合にグループ化することができる。ユー
ティリティ・インタフェースは直接、呼出しマネージャ
とのイタフェースをとる。また、資源インタフェースを
介して照会に応答する。
ii）呼出しマネージャ 呼出しマネージャ・ユーティリティ101は、呼出しの
概念を実施する。呼出しとは、一群のユーザが共用アプ
リケーションを使用することによって協調することを言
う。いつでも複数の呼出しが存在でき、ユーザは複数の
同時呼出しに参加することができ、同じアプリケーショ
ンを複数の呼出しで実行することができる。たとえば、
ユーザＡ、Ｂ、Ｃは文書を検討するために呼出しｘに参
加することができる。すべてのユーザが相互に音声通信
を使用することができ、ＡとＢはビデオ・リンクも、Ａ
とＣは共用チョークボードも有することもできる。一
方、Ａ、Ｂ、Ｄは第２の文書を検討するために第２の呼
出しｙに参加することができる。ＡとＤはチョークボー
ドを、ＢとＤは音声リンクを使用する。
APIには呼出しの概念が存在しないが、アプリケーシ
ョン共用セットを介して呼出しマネージャによって実施
される。このサポートを提供することによって、呼出し
セットアップや切断にawareアプリケーションを関与さ
せる必要がなくなり、呼出し管理とアプリケーション・
プログラミングが明確に分離される。呼出しマネージャ
は、エンド・ユーザがアドレス・ブックから名前を選択
し、分岐呼出しを論理的に確立するためのダイアログを
提供する。パーティを動的に追加し、削除することがで
きる。提供されるオプションは、自動応答および呼出し
禁止を含む。ある呼出しが現行活動呼出しとみなされ、
共用アプリケーション・セットは通常、呼び出されると
ころの呼出しに追加される。現行活動呼出しは、他の呼
出しがセットアップされている間は背景に移される。
ｂ）ユーザ・ユーティリティ ｉ）アプリケーション・アシスタント このユーティリティは、呼出し中のユーザのために以
下の機能を実施する。
○既存のアプリケーション・ウィンドウをスナップショ
ットとして、または連続的に直接ミラーリングし、シス
テム・ポインティング・デバイスをリモート・ポインタ
としてイネーブルにする。
○システム・クリップボード・サポート。すなわち、あ
るノードにあるシステム・クリップボードの内容を任意
選択で他のノードで共用し、あるいは表示する能力 ○異なるノードにあるアプリケーションの間に確立でき
るリモートDDEリンク ○他のノードにあるプリンタへの印刷のリダイレクト ii）チョークボード チョークボード103は、２つのイメージ・プレーンを
もつ共通描画領域を実施する。この描画領域には、呼出
し中のすべてのユーザがアクセスできる。背景プレーン
は、ビットマップ・ファイル、システム・クリップボー
ド、またはアプリケーション・ウィンドウの内容からロ
ードすることができる。前景プレーンは、一連の簡単な
テキストおよびグラフィクス・ツールを使用する対話型
注釈に使用することができる。チョークボード上のリモ
ート・ポインタもサポートされる。
iii）ファイル転送 ファイル転送104によって、呼出し中のユーザの間の
ファイルの送信が可能になる。１つまたは複数のファイ
ルを転送することができ、ファイルをコメントと共に送
信することができ、元のファイル名を宛先が利用できる
ようになる。受信側ノードはファイル受信およびファイ
ル命名を完全に制御する。
iv）メッセージ行 メッセージ行105は、呼出し中のユーザの間でテキス
ト・データを直接共用できるようにする。複数の同期ユ
ーザが許可され、各参加者はすべての交換されるメッセ
ージを同じシーケンスで見る。メッセージ・ユーティリ
ティは、呼出しセット・アップおよび終了、ファイル転
送などの、呼出し時の活動も記録する。実際の実施例で
は、このユーティリティを呼出しマネージャの一部とし
て提供している。
ｖ）ビデオ／音声リンク このユーティリティ106によって、呼出し中のユーザ
の間にビデオおよび音声リンクを確立することができ
る。利用可能な厳密な機能は、物理ネットワークの機能
とワークステーションのハードウェア・サポートによっ
て異なる。
規格 全体的なアーキテクチャは、広範囲の協調アプリケー
ションをサポートするものである。インタフェースは、
実施できるアプリケーション・モデルの範囲に対して重
大な制限を課さないように、できるだけ高いレベルにセ
ットされている。
関与する透過ネットワークの性質は完全にAPIより下位
に隠されている。これは、アプリケーションがネットワ
ーク経路指定（たとえば直接または間接）と関与するネ
ットワーク・タイプ（たとえば、単一リンクまたは複数
リンク、交換接続または固定接続）を完全に知っている
ことを意味する。この手法の結果、たとえば特定の通信
サービス品質を求める要求が失敗する恐れがあることを
予期してアプリケーションを書かなければならない。な
ぜなら、基礎ネットワークが必要な機能を有していない
ことがあるからである。
サード・パーティ・アプリケーションが他のアプリケ
ーションの代わりに動作することを要求できるようにエ
ージェント原理が実施されている。これによって、呼出
しマネージャ・アプリケーション、電話アプリケーショ
ン、および交換アプリケーションを開発することができ
る。現在の技術の状態では、アナログ・ネットワークお
よび装置をサポートすべきである。アプリケーションの
移行を容易にするために、アナログ・ネットワークをデ
ィジタル・ネットワークのように扱うことが試みられて
いる。
APIレベルで、使用される主要概念の１つは、アプリ
ケーション共用セットの概念である。アプリケーション
は、他のアプリケーションと協調するとみなされ、この
協調のための機構は、アプリケーションが、指定された
共用セットに相互に参加することである。そのようなア
プリケーション共用セットの肝要な点は、すべてのセッ
ト・メンバが他のすべてのメンバの状況に関する情報を
受信することである。セットに参加することは、アプリ
ケーションが関心をもつものを宣言する方法である。こ
れに対し、呼出しの概念は、APIより上位、特に呼出し
マネージャに存在する。異なる呼出しマネージャが異な
る呼出しモデルを有することができる。
アプリケーション共用セットの他に、チャネルもアー
キテクチャの基本概念である。同報通信と２方向通信を
共に効率的にサポートするための基礎通信ビルディング
・ブロックとして１方向チャネルを使用している。チャ
ネルは、送信側アプリケーションによって確立され、受
信側アプリケーションによって受け入れられる。という
のは、データをどのように送信すべきかを示すデータの
特性を知っているのは送信側アプリケーションだけだか
らである。２つのアプリケーションは共に、それぞれの
ポートに供給し、あるいは前記ポートから受信すべきフ
ォーマットを独立に制御することができる。各種のデー
タ・フロー用の複数の論理チャネルによって、サポート
・システムは基礎転送ネットワークにトラフィックを正
しく割り振ることができる。さらに、サポート・システ
ムは、データが、それぞれが別々に記述された別々の同
種フローで他のアプリケーションに提供されるようにす
る。このようにアプリケーション間のトラフィックを別
々のデータ・タイプに分割することによって、サポート
・システムはデータ変換機能を提供することができる。
チャネルの接続およびウェルドによって、アプリケー
ションがもはやデータの移動に関与しなくなるように、
データの転送をAPIより下位にすることができる。サポ
ート・システムは、場合によっては、そのノードにある
非常に低いレベルでの接続を有効化するか、フローの経
路をそのノードに向かわないように変更する接続を有効
化するかのオプションを有する。
サポート・システム・アーキテクチャは、異なるコン
ピュータ・プラットフォームの間の相互作用を許可し、
様々な通信ネットワークを介して動作し、関連する通信
およびデータ規格をサポートするように設計されてい
る。
データ・トラフィックを同種データの論理１方向フロ
ーに分けることによって、混合ネットワーク上へのマッ
ピングが簡単になり、ノードの間で異なる機能の複数の
物理リンクを使用できるようになる。データ多重化は、
アプリケーションより下位で処理され、基礎転送機構に
応じて異なる方法で、たとえば、各論理フローをそれぞ
れの物理リンクに割り振ることと、サポート層中のすべ
てのデータを多重化することを組み合わせ、あるいは多
重化の態様を装置ドライバに任せることによって、実施
することができる。この手段によって、複数のチャネ
ル、iso-LANまたはiso-Ethernet、あるいはCCITT H320
勧告を使用するISDNを介して、音声、ビデオ、およびデ
ータ・トラフィックを送信することができる。サービス
品質要件は、必要な転送機能に対して条件を課す。した
がって、音声およびビデオには通常、優先順位および帯
域幅管理を伴う方式を介して実施される、等時機能をも
つ専用物理リンクまたは共用リンクが必要である。
データ構成要素が別々に提供され、該構成要素の性質
およびフォーマットが独立に得られるので、チャネルに
よって提供される別々の論理データ経路は、該経路に関
連するデータ・タイプと共にアプリケーション間動作を
容易にする。サポート・システムがネットワークでデー
タ変換を実行できるため、この機構を介して、音声、ビ
デオ、イメージ、ファイル転送、およびコード化データ
に関する広範囲の既存の規格をサポートすることができ
る。システムは、リモート・プリンタ、カーソル、ジェ
スチャなどの、協調アプリケーションで一般に使用され
る対話オブジェクト用の別々のデータ・クラスも提供す
る。
APIコマンドの概要 以下で、API呼出しで提供される主要な機能について
詳細に説明する。この趣旨は適用範囲の概要を述べるこ
とにすぎないので、実際の呼出しの構文およびパラメー
タについては説明しない。
API機能要求 セッションおよびアプリケーション共用 cancel_request:前の非同期要求がまだ満たされていな
い場合にその要求を取り消す。
deregistei_app:アプリケーション・インスタンスによ
って、APIの使用を終了するために発行される。
launch_app:あるアプリケーションによって、他のアプ
リケーションを呼び出すために発行される。
register_app:発行側アプリケーション・インスタンス
をワイヤとして識別し、アプリケーション事象ハンドラ
を確立する。
set_call_manager:そのノード用の呼出しマネージャを
識別し、呼出しマネージャ事象ハンドラを確立する。
share_app:アプリケーション・インスタンスが、あるア
プリケーションと他のアプリケーションの共用を要求す
るために発行する。
shutdown_node:アプリケーション・インスタンスによっ
て、そのローカル・ノードにあるサポート・システムの
遮断を要求するために発行される。
unshare_app:アプリケーション・インスタンスによっ
て、あるアプリケーションと他のアプリケーションの共
用を終了するために発行される。
装置およびポート add_channel:指定されたアプリケーション・インスタン
ス中で、指定された送信側ポートに他のチャネルを追加
する。
change_channel:指定されたチャネル特性を変更する。
change_device_characteristics:指定された装置特性を
変更する。
change_port:指定さたポート特性を変更する。
claim_resource:特定のサービス品質に関連する資源の
資源マネージャに対する呼出し close_device_port:定義された装置上の関連するポート
をクローズする。
connect_ports:指定された受信側ポートを指定された送
信側ポートに接続する。
create_channel:発行側アプリケーションにある送信側
ポートと、指定されたターゲット・アプリケーションに
ある受信側ポートから成るデータ送信チャネルを作成す
る。
disconnect_ports:指定された送信側ポートから指定さ
れた受信側ポートを切断する。
open_device_port:定義された装置上のポートをオープ
ンする。
remove_channel:指定された受信側ポートと指定された
送信側ポートに関連するチャネルを削除する。
request_resource:特定のサービス品質に関連する資源
の資源マネージャに対する照会 resume_port:指定されたポートを介してデータ送信を再
開する。
signal_port:指定されたポートを介して制御文字列を送
信する。
suspend_port:まだ受信されていないデータをドレーン
またはフラッシュした後に、指定されたポートを介する
データ送信を中断する。
weld_connection:指定された受信側ポートと送信側ポー
トの接続を永続的にする。
データ送信および受信 receive_data:指定された受信側コマンド・ポートから
データを受信する。
send_data:指定された送信側ポートを介してデータを非
同期的に送信する。様々な送信肯定応答を要求すること
ができる。
signal:サポート・システムが確立した制御チャネルを
介して、サポート・システムまたはアプリケーションが
定義した制御データを、指定されたアプリケーション・
インスタンスに送信する。
signal_app_with_reply:サポート・システムが確立した
制御チャネルを介して、サポート・システムまたはアプ
リケーションが定義した制御データを、指定されたアプ
リケーション・インスタンスに送信し、応答データを返
す。
start_sync:指定されたチャネル・セットに関連する受
信側ポートを介して受信されたデータの同期を開始す
る。
stop_sync:指定されたチャネル・セットに関連するすべ
ての受信側ポートのデータの同期を停止する。
トークン管理 get_token:指定されたグローバル・トークンまたはアプ
リケーション・トークンをただちに、排他的に保持し、
あるいは共用することを要求する。
give_token:指定された要求元に、指定されたトークン
を与える。
qget_token:指定されたグローバル・トークンまたはア
プリケーション・トークンをただちに、排他的に保持
し、あるいは共用することを要求し、トークンが得られ
ない場合は、現所有者が維持している要求待ち行列への
参加を要求する。
reclaim_token:指定されたアプリケーション・インスタ
ンスが保持している指定されたトークンをただちにトー
クンの現所有者に返すことを強制する。
refuse_token:指定された要求元に、指定されたトーク
ンを与えることを拒否する。
release_token:指定された保持しているトークンを現所
有者に返す。
return_token:指定されたトークンを保持している指定
されたアプリケーションがトークンをできるだけ早く現
所有者に返すことを要求する。
set_token_owner:指定されたアプリケーション・インス
タンスに指定されたトークンの所有者をセットする。
事象制御 begin_monitor:API呼出しの各オカレンスを識別する特
殊監視事象を発生させ、または指定された監視事象ハン
ドラに標準事象を提供する。
default_event_handler:アプリケーション・プログラム
が明示的に処理することを所望しないすべての事象に対
してデフォルト応答を返す。
disable_events:指定された事象クラスの事象が発行側
アプリケーション・インスタンスの事象ハンドラに渡さ
れるのを停止する。
enable_events:指定された事象クラスの事象が発行側ア
プリケーション・インスタンスの事象ハンドラに渡され
るようにする。
end_monitor:API呼出しの各オカレンスを識別する特殊
監視事象、または提供中の標準事象を停止する。
プロファイル管理 read_profile_string:プロファイル・ファイルの指定さ
れたセクション中の指定されたキーワードの文字列を返
す。
wtrite_profile_string:プロファイル・ファイルの指定
されたセクション中の指定されたキーワードに文字列を
コピーする。
API照会 query_address:指定された共用セットに属するアプリケ
ーション・インスタンスの完全なフル・アドレスを返
す。
query_application_status:アプリケーションの状況（u
naware、aware、または呼出しマネージャ）を返す。
query_channel_characteristics:指定された送信側ポー
トおよび受信側ポートに関連するチャネルのチャネル特
性を返す。
query_channel_set:指定されたチャネル・セット中のす
べてのポートのハンドルを返す。
query_device_characteristics:指定された装置の装置
特性を返す。
query_device_status:指定された装置の状況を返す。
query_monitor:現在モニタ事象ハンドラに渡されている
機能または事象のクラスを返す。
query_port_characteristics:指定されたポートの特性
を返す。
query_port_status:指定されたポートの状況を返す。
query_resource:指定された資源セット中で利用可能な
資源を返す。
query_sharing_set:アプリケーション・インスタンス用
の共用セット識別子を返す。
query_token_holder:トークンの所有者（アプリケーシ
ョン・トークンのみ）および保持者を返す。
query_token_state:指定されたトークンの状態を返す。
API事象 呼出しマネージャ事象 APP_DEREGISTERED:アプリケーション・インスタンスがA
PIの使用を終了するときの、ローカル呼出しマネージャ
への事象。
APP_REGISTERED:アプリケーションがAPIの使用を初期設
定するときの、ローカル呼出しマネージャへの事象 CALL_MANAGER_ERROR:呼出しマネージャに影響を及ぼす
エラーが発生した。
CALL_MANAGER_REQUEST:他のローカル・アプリケーショ
ンがset_call_manager機能要求を発行したことを示す、
ローカル呼出しマネージャへの事象 NODE_SHUTDOWN_REQUEST:サポート・システムを遮断を求
める要求 PASSIVE_NODE_RELEASED:ノードが受動要求をサポートで
きるようにするために割り振られた資源の解除を求める
指示。
PASSIVE_NODE_REQUEST:ノードが受動要求をサポートす
るために資源を割り振ることを求める要求 SHARE_REQUEST:指定されたアプリケーションとの共用を
求める要求 TOKEN_STATUS_REQUEST:グローバル・トークンの状況を
求める要求 アプリケーション事象 APP_SIGNAL:信号が受信された。
APP_SIGNAL_REJECTED:信号が拒否された。
APP_SIGNAL_WITH_REPLY:signal_with_replyが受信され
た。
APP_SIGNAL_TRANSFERRED:信号が転送された。
APP_UNSHARE_REQUEST:受信側がアプリケーション共用セ
ットを抜けることをサード・パーティ・アプリケーショ
ンが要求した。
APP_UNSHARED:発行側がアプリケーション共用セットを
抜けるという通知が受信された。
APP_ERROR:関連アプリケーション・エラーが検出され
た。
NODE_SHUTDOWN:遮断が開始された。
PORT_REMOVED:ポートが削除されたことを確認 PORT_REQUEST:受信側ポートの追加を求める要求 RESOURCE_CLAIM:アプリケーションがサービス品質資源
を請求すると必ずレイズされる。
RESOURCE_REQUEST:アプリケーションがサービス品質資
源を要求すると必ずレイズされる。
PROFILE_CHANGED:LAKES.INIファイルまたはLAKESQOS.IN
Iファイルの変更を求める指示 SHARE_CONFIRMED:共用要求が処理されたことを確認が受
信された。
SHARE_REJECTED:共用要求が拒否された。
SHARE_REQUEST:共用要求が受信された。
SHARE_TRANSFERRED:共用要求が転送された。
TOKEN_CANCEL_REQUEST:待機中のトークン要求の取消し
を求める要求が受信された。
TOKEN_GIVEN:要求元にトークンが与えられた。
TOKEN_QREQUEST:トークンを保持し、あるいはトークン
が得られない場合は待ち行列に参加することを求める要
求 TOKEN_RECLAIMED:トークンが所有者によって取り去られ
た。
TOKEN_RECLAIMED:トークンが所有者によって取り去られ
た。
TOKEN_REFUSED:トークンを求める要求が拒否された。
TOKEN_REQUEST:トークンの保持を求める要求 TOKEN_RETURN_REQUEST:トークンの所有者が、トークン
をできるだけ早く返すことを要求している。
装置事象およびポート事象 CHANNEL_CHANGED:一部のチャネル特性が変更された。
CHANNEL_CONFIRMED:新しいチャネルが作成された。
CHANNEL_DESTROYED:チャネルが破壊された。
CHANNEL_REJECTED:チャネルが作成されなかった。
CONNECTION_WELDED:ウェル接続通知が受信された。
DATA_AVAILABLE:受信側ポートでデータが利用可能であ
る。
DATA_CONFIRMED:データ送信の確認またはデータ送信の
進行の推定が受信された。
DATA_REQUESTED:送信側ポートからデータが要求されて
いる。
DEVICE_INFORMATION:装置情報を供給する予定のアプリ
ケーション・イスタンスの送信側ポート事象ハンドラに
レイズされる事象 PORT_ERROR:ポート・エラーが検出された。
PORT_RESUME_REQUEST:ポート再開要求が受信された。
PORT_SIGNALLED:信号ポート事象が受信された。
PORT_SUSPEND_REQUEST:ポート中断要求が受信された。
PORT_SYNC_REQUEST:同期制御の調整を求める要求が受信
された。
モニタ制御事象 EVENT_MONITORED:機能要求および事象活動の通知が受信
された。
チャネル、ポート、およびリンクの特性 チャネル特性 以下のパラメータは、チャネルと関連しており、create
_channel要求およびadd_channel要求で設定される。
quality_of_service: 信号タイプ（アナログまたはディジタル） スループット 待ち時間 ジッタ 遅延 優先順位 圧縮ヒント 暗号化 サービス品質特性は、LAKESQOS.INIファイル中のデー
タ・タイプおよびサブタイプを介して関連付けられる
が、明示的に指定することができる。この特性は、未定
義のままにすることができる。これによって、データが
チャネルを介して送信されるときに、動作特性が、利用
可能な資源に依存するチャネルを作成することができ
る。
channel_type: 標準 組合せ 直列化 同期 channel_set_id: 識別子 ポート特性 以下のパラメータは、ポートと関連している。ポート
・タイプを除くすべてのパラメータは明示的に定義され
る。送信側ポートは、create_channel要求でこれらのパ
ラメータを指定し、受信側ポートはPORT_REQUEST応答で
これらのパラメータを指定する。
connect_type: コマンド 事象 空 event_handler: port_type: 送信 受信 data_class: データ・タイプ データ・サブタイプ user_exit: user_information: リンクの特性 以下のサービス品質パラメータは、物理リンクに関連
しており、リンク・ロケータを介してアクセスされるデ
ータベースに指定するか、あるいはデフォルトとしてLA
KESQOS.INIファイルから得られる。
信号タイプ（アナログまたはディジタル） スループット 待ち時間 ジッタ フレーム・サイズ フレーム・エラー・レート フレーム再送信時間 圧縮ヒント 暗号化 サポート・システム構造 再び、第10図に示したサポート・システム構造を参照
して、該構造の構成要素の様々なタスクについて詳細に
説明する。アプリケーション・マネージャ223は、サポ
ート・システムの残りとのインタフェースとして働き、
ある程度のパラメータ検証の後に適切な構成要素に分散
されるすべてのAPI呼出し用の入口点を提供する。監視
が必要な場合（以下参照）、アプリケーション・マネー
ジャ223は着信呼出し／発信事象の走査にも使用され
る。
アプリケーション・マネージャ223は、チャネルの作
成時に指定された事象ハンドラでアプリケーションをコ
ール・バックする責任を負う。事象は、ローカル・アプ
リケーションがチャネルを作成した場合は送信側ポート
で、あるいは次いでリモート・アプリケーションがチャ
ネルを作成した場合は受信側ポートでレイズされるもの
である。アプリケーション・マネージャ223は、ポート
を作成する際に、特定のアプリケーションのためのすべ
ての事象を処理し待ち行列に入れる事象待機ハンドラの
アドレスを渡す。次いで、事象を連続的に読み取るディ
スパッチ・スレッドなどのある種の機構がアプリケーシ
ョンの事象ハンドラに事象を送信する。
チャネル・マネージャ227は、他のすべての構成要素
を始動し遮断する責任を負うチャネル・スーパバイザ
と、異なるノードにあるサポート・システムの間の制御
チャネル通信を処理する制御チャネル副構成要素と、他
のすべての非制御チャネル・データ通信を処理するデー
タ・チャネル副構成要素と、ノード・ハンドルおよび数
組のノード・ハンドルを作成し、破壊し、維持するノー
ド・マネージャと、ポートを作成し、破壊し、操作し、
ポート照会機能を実行するポート・マネージャの５つの
副構成要素を有する。
資源マネージャ225は、サポート・システムで第１に
制御を得る構成要素である。資源マネージャ225は、他
のすべての構成要素を初期設定し、かつアドレス・ブッ
クまたは経路選択機能とのインタフェースをとる責任を
負う。トークン・マネージャ224は、名前から分かるよ
うに、グローバル・トークンとアプリケーション・トー
クン（グローバル・トークンはそれぞれの呼出しマネー
ジャ構成要素によって所有され、これに対し、アプリケ
ーション・トークンは共用セット中のノードによって所
有される）とのロギングおよび管理に責任を負う。
装置マネージャ224は、サポート・システムと装置の
間の対話に責任を負い、特に、装置名を完全修飾経路な
どに変形すること、適切な動的リンク・ライブラリ（DL
L）のロード、ポート番号、ポート・ハンドラ、および
事象ワードを含む記録の生成、初期設定入口点の呼出
し、DLL中のすべての項目ハンドルをアプリケーション
呼出しマネージャ用の物理アドレスに変形することなど
の機能を実行する。信号マネージャ226は、アプリケー
ション（応答の有無にかかわらない）およびポートに発
信する責任を負う。
チャネルおよびポートの記述 ａ）チャネルの記述 以下のパラメータは、チャネルに関連し“create_cha
nnel"要求で指定される。
quality_of_service: −スループット（たとえば、ビット／秒） −チャネル優先順位 channel_type: −標準 −組合せ −直列化 −同期 channel_set_id: −識別子 encryption_parameters: compression_hints: ｂ）ポートの記述 以下のパラメータは、ポートに関連する。送信側ポー
トは、これらのパラメータを“create_channel"要求で
指定し、受信側ポートは応答で指定する。
connect_type: −バッファ −事象 −空 event_handler: port_type: −送信 −受信 user_exit: user_information: data_class −オーディオ −複合オーディオ／ビデオ −ファイル −対話 −バッチ −ビデオ チャネルおよびポート 協調アプリケーション・サポート・システムの全体的
な動作について説明したので、今度は、様々なチャネル
とポートの動作について詳細に説明する。チャネルおよ
びポートを作成するAPIコマンドは“create_channel"で
ある。
create_channel機能は、発行側アプリケーションから
ターゲット・アプリケーションへの、指定された特性を
もつチャネルを作成する。
create_channelコマンドに指定するパラメータは以下
のとおりである。
async_id この呼出しと、この呼出しに関連するすべ
ての事象との識別に使用される、ユーザが供給する参照
id。このパラメータをゼロにすることはできない。
target_application ターゲット・アプリケーション
の短アドレスを含む構造を指すポインタ sharing_set_id 作成すべきチャネル中のユーザ定義
共用セット名 channel_type チャネル・セット関連のタイプ:0 STANDARD MERGED SERIALISED SYNCHRONISED channel_set_id 作成されたポートが関連付けられる
べきチャネル・セットのユーザ定義識別子 quality_of_service サービス品質パラメータを含む
構造を指すポインタ data_class 作成された送信側ポートを会して送信で
きるデータのタイプおよびサブタイプを記述する２つの
フィールドを含む構造を指すポインタ max_buffer_size send_data上で使用される最大バッ
ファ・サイズ connect_type 送信側ポートの接続タイプ： NULL EVENT BUFFERED event_handler 作成されたポートに対する着信事象
を処理するために呼び出すべき事象ハンドラのアドレス user_event_word このポートに関連するすべての事
象上でポート事象ハンドラに渡されるユーザ指定データ
・ポインタ user_exit 送信側ポートを介してデータが送信され
るときに必ず呼び出すべき発行側アプリケーション中の
ユーザ出口のアドレス user_info PORT_REQUEST事象上でリモート・アプリケ
ーションに渡されるユーザ指定情報 startup_mode チャネルが中断状態または始動状態で
作成されることを指定する。
チャネル作成関数からのリターン・コードは、動作が
首尾よく完了したことを示すRC_OKと、多数の失敗コー
ドを含む。
この関数呼出しは、１方向論理チャネルを作成するた
めに使用される。このチャネルは、発行側アプリケーシ
ョンとターゲット・アプリケーションの間に作成され
る。送信側ポートは発行側アプリケーションで作成さ
れ、受信側ポートはターゲット・アプリケーションで作
成される（第８図参照）。
create_channel関数呼出しの結果、リモート・アプリ
ケーションは、初期設定事象ハンドラを介してレイズさ
れたPORT_REQUESTを得る。この時点で、リモート・アプ
リケーションはこの要求を受け入れることも、拒否する
こともできる。CHANNEL_CONFIRMED事象は、PORT_REQUES
T応答を与えるアプリケーション初期設定事象ハンドラ
を介してレイズされる。
channel_typeは、前述の４つのチャネル・タイプ、す
なわち、標準、組合せ、直列化、および同期を定義す
る。
async_idパラメータ値は、アプリケーション定義であ
り（この値は、取消し関数呼出しで使用することができ
る）、ローカル端末でCHANNEL_CONFIRMED事象またはCHA
NNEL_REJECTED事象で返される。しかし、リモート端末
でのPORT_REQUEST事象、CHANNEL_CONFIRMED事象、また
はCHANNEL_REJECTED事象はasync_id値ゼロを有する。
channel_set_idは、ユーザ定義識別子であり、論理チ
ャネルが１組のチャネルに属することをシステムに通知
する。channel_set_idはアプリケーション共用セット内
で特有のものでなけらばならず、前記セットの一部とな
るべきチャネルはどれも同じ識別子を指定しなければな
らない。これは、channel_typeをSTANDARDとして指定し
た場合だけ空になる。
サービス品質パラメータは、資源セットの識別子と所
望のサービス品質資源とを含む構造である。資源セット
識別子が空でない場合、指定された資源はこのセットか
ら獲得される。資源識別子が空の場合、資源は使用可能
資源から獲得される。資源セットのセットアップについ
ての詳細は、reserve_resource関数呼出しの定義を参照
されたい。
connect_typeパラメータは、データをどのようにシス
テムに与え、あるいはシステムから受け取るか、すなわ
ち、前述の空、事象、またはバッファを指定する。
データ・チャネルとそれに関連するポートを作成する
ための典型的なフローを第14図に示し、以下の注によっ
て説明する。
ステップ１ 最初に、ノード１中のアプリケーション
Ｘは、アプリケーションＸの送信側ポートとノード２中
のアプリケーションＹの受信側ポートから成るデータ・
チャネルを作成するためにサポート・システムにasynch
ronous create_channel要求を発行する。
ステップ２ サポート・システムは、Ｙの初期設定事
象ハンドラに対してPORT_REQUESTをレイズする。create
_channelが、すでに作成されたポートを使用して組合せ
チャネルまたは直列化チャネルを作成することを要求し
ている場合、PORT_REQUESTはレイズされないことに留意
されたい。PORT_REQUESTは、送信側ポート・ハンドル
（完全アドレス）、受信側ポート・ハンドル、および発
信元アプリケーションＸの完全アドレスを指すポインタ
を含む。
ステップ３ Ｙの初期設定事象ハンドラが、要求を拒
否し（RC_PORT_REJECT）、または受け入れる（RC_PORT_
ACCEPT）。要求を受け入れる場合、Ｙの事象ハンドラは
事象データ中のフィールドを、受信側ポートを構築する
のに必要なパラメータで埋めなければならない。
ステップ４ ＹがRC_PORT_REJECTを返す場合、システ
ムはCHANNEL_REJECTED事象をレイズする。ＹがRC_PORT_
ACCEPTを返す場合、システムは送信側ポート事象ハンド
ラでCHANNEL_CONFIRMED事象をレイズする。
ステップ５ また、Ｙは、システムが受信側ポートを
確立したことを示すCHANNEL_CONFIRMED事象を、受信側
ポート事象ハンドラで受信する。
ステップ６ すべての新たに作成されたチャネルの送
信側および受信側ポート事象ハンドラに対してCHANNEL_
CONFIRMED事象がレイズされる。これは、明示的に作成
されたチャネルと同じチャネル・セットに属し、含まれ
るアプリケーション・インスタンスが、ノード３にある
アプリケーションＺなどの、新しいチャネルの作成元と
同じアプリケーション・セットに属する、すべてのチャ
ネルの送信側および受信側ポート事象ハンドラに対して
CHANNEL_CONFIRMED事象がレイズされることを意味する
ことに留意されたい。
協調グループ作業では多くの場合、参加者が定常的に
参加したり抜けたりするグループのメンバ間にｎ方向通
信を確立することが必要である。すべての参加者が常に
現メンバのリストを更新し、すべての必要なデータ・リ
ンクを修正することは困難であり、あるいは時間がかか
る。組合せチャネルを作成すると、それぞれの参加者が
最小限に関与することによって、すべての必要なデータ
経路を基礎システムで維持することができる。
論理チャネルは、一方の端末にある送信側ポートと他
方の端末にある受信側ポートとを備えた１方向データ・
パイプから構成されるように定義されている。データは
常に、送信側ポートから受信側ポートに流れる。表記
上、これを［送信側ポート：受信側ポート］で示す。
チャネルは、１つの送信側ポートを多数の受信側ポー
トと関連付けることができる、すなわち、単一の送信側
ポートを介して送信されたデータがすべての受信側ポー
トに送られるように確立することができる。これを第15
図に示し、表記上、［SP:R1、RP2、、、RPn］で示す。
論理チャネルも、表記上、CSname［SP:RP1,RP2....RP
n］typeとして示した、異なるタイプのチャネル・セッ
トごとに関連付けることができる。組合せチャネル・セ
ット・タイプは、複数の送信側ポートがすべて、単一の
受信側ポートにデータを送信するものである。概念的に
は、すべての「通常の」受信側ポートが組合わされて、
この単一の受信側ポートになっている。これを添付の第
16図に示し、表記上、以下のように表す。
CSname［SP1,SP2,...SPn:RP1］merged ２つ以上のアプリケーションが、異なる送信側ポート
と受信側ポートから成る同じチャネル・セット名を使用
して組合せチャネル・セットを定義することができる。
たとえば、アプリケーションＡは組合せチャネル・セッ
トCS1［SPa:RPb,RPc］mergedを定義することができ、ア
プリケーションＢは組合せチャネル・セットCS1［SPd:R
Pe,RPf］mergedを定義することができる。
アプリケーションが、それによって確立されたデータ
・チャネルを参照する、すなわちshareコマンドを使用
するのでなくアプリケーション名を参照することによっ
て協調セッションを開設することに留意されたい。
上記の場合、アプリケーションＡはアプリケーション
Ｂと共用を行い、協調作業グループを形成する。これに
よって、送信側ポートの結合セットがすべての受信側ポ
ートの結合セットにデータを送信するように、組合せチ
ャネル・セットCS1の２つの定義が組み合わせられる。
表記上、この結果得られるチャネル・セットCS1を次の
ように定義する。
CS1［SPa,SPd:RPb,RPc,RPe,RPf］merged この場合、アプリケーションＡによって明示的に作成
されるチャネル（すなわち、［SPa:RPb］、［SPa:RP
c］）およびアプリケーションＢによって明示的に作成
されるチャネル（すなわち、［SPd:RPe］、［SPd:RP
f］）だけでなく、新しいチャネル［SPa:RPe］、［SPa:
RPf］、［SPd:RPb］、および［SPd:RPc］もシステムに
よって作成される。したがって、送信側ポートと受信側
ポートのすべての交差接続の間に現在、データ・チャネ
ルが存在している。
これによって、各メンバが、グループの他のメンバに
よって確立されたデータ・チャネルに関して何も知る必
要なしに、協調グループのすべてのメンバの間に２方向
データ・チャネルを確立する極めて簡単な方法が得られ
る。
このプロセスは、協調作業グループの各潜在的メンバ
・アプリケーションが、同じアプリケーションに定義さ
れた送信側とポートとそれに関連する受信側ポートから
成り、合意されたチャネル・セット名を使用する、組合
せチャネル・セットを確立するためのものである。すな
わち、各潜在的アプリケーションは、CS1［SPa:RPa］me
rgedなどのチャネル・セットを確立する。２つ以上のア
プリケーション（たとえば、アプリケーションＡ、Ｂ、
Ｃ）が協調グループを形成するとき、CS1の異なる定義
が、以下の組合せセットを形成するように結合される。
CS1［SPa,SPb,SPc:RPa,RPb,PRc］merged これを第17図に示す。
グループには新しいメンバを容易に追加することがで
き、必要なデータ・チャネルは基礎システムによって自
動的に確立される。唯一の要件は、新しいメンバが既存
のメンバのアプリケーション名を知り、同じチャネル・
セット名を使用することである。新しいメンバは、他の
メンバに関して何も知る必要がなく、さらに、グループ
に参加するために使用されたアプリケーション名を提供
したアプリケーション・メンバによって確立されたデー
タ・チャネルに関して知る必要もない。同様に、アプリ
ケーションがグループを抜けるとき、無効なデータ・チ
ャネルは自動的に削除される。
グループの複数のメンバによって送信されたデータが
グループのすべてのメンバに同じシーケンスで到着する
ように、グループのメンバの間にｎ方向通信を確立する
ことが必要な特殊なケースが発生する。直列化チャネル
を作成すると、それぞれの参加者が最小限に関与するこ
とによって、データ・パケットの順序付けを基礎システ
ムで行うことができる。
第18図に示した直列化チャネル・セットは、複数の送
信側ポートがすべて、複数の受信側ポートにデータを送
信し、かつデータがすべての受信側ポートに同じ順序で
到着することを要求するものである。概念的には、すべ
ての送信側ポート（Ａ、Ｃ）からのデータ・パケットを
直列化し、すべての受信側ポート（Ｂ、Ｄ）に同じシー
ケンスのパケットを送るという特性を有する指定された
チャネル・セットを介してデータが送信される。表記
上、これを以下のように表す。
CSname［SP1,SP2,....SPn:RP1,RP2,...RPn］serialised 組合せチャネルと同様に、２つ以上のアプリケーショ
ンが、異なる送信側ポートと潜在的に共通の受信側ポー
トから成る同じチャネル・セットを使用して直列化チャ
ネル・セットを定義することができる。たとえば、アプ
リケーションＡは直列化チャネル・セットCS1［SPa:RP
b］serialisedを定義することができ、アプリケーショ
ンＣは直列化チャネル・セットCS1［SPc:RPd］serialis
edを定義することができる。
組合せの場合と同様に、アプリケーションは、それに
よって確立されたデータ・チャネルを参照せずにアプリ
ケーション名を参照することによって協調セッションを
開設する。第18図を参照すると、アプリケーションＡは
アプリケーションＣと協働して、協調作業グループを形
成する。これによって、送信側ポートの結合セットがす
べての受信側ポートの結合セットに同じシーケンスでデ
ータを送信するように、直列化チャネル・セットCS1の
２つの定義が組み合わせられる。表記上、この結果得ら
れるチャネル・セットCS1を次のように定義する。
CS1［SPa,SPc:RPb,RPd］serialised この場合、アプケーションＡによって明示的に作成さ
れるチャネル（すなわち、［SPa:RPb］）およびアプリ
ケーションＣによって明示的に作成されるチャネル（す
なわち、［SPc:RPd］）だけでなく、新しいチャネル［S
Pa:RPb］、［SPc:RPb］もシステムによって作成され
る。したがって、送信側ポートと受信側ポートのすべて
の交差接続の間に現在、データ・チャネルが存在してい
る。これは、組合せチャネル・セット概念と類似してい
る。しかし、データ・パケットがすべての受信側ポート
に同じシーケンスで到着するという重要な追加制約があ
る。
組合せの場合と同様に、これによって、各メンバが、
グループの他のメンバによって確立されたデータ・チャ
ネルに関して何も知る必要なしに、協調グループのすべ
てのメンバの間に両方向直列化データ・チャネルを確立
する極めて簡単な方法が得られる。
このプロセスは、協調作業グループの各潜在的メンバ
・アプリケーションが、同じアプリケーションに定義さ
れた、送信側ポートとそれに関連する受信側ポートから
成り、合意されたチャネル・セット名を使用する、組合
せチャネル・セットを確立するためのものである。すな
わち、各潜在的アプリケーションは、CS1［SPa:RPa］se
rialisedなどのチャネル・セットを確立する。２つ以上
のアプリケーション（たとえば、アプリケーションＡ、
Ｂ、Ｃ）が協調グループを形成するとき、CS1の異なる
定義が、以下の直列化セットを形成するように結合され
る。
CS1［SPa,SPb,SPc:RPa,RPb,RPc］serialised これを第19図に示す。
グループには新しいメンバを容易に追加することがで
き、必要なデータ・チャネルは基礎システムによって自
動的に確立され直列化される。唯一の要件は、新しいメ
ンバがアプリケーション名または既存のメンバを知り、
同じチャネル・セット名を使用することである。新しい
メンバは、他のメンバに関して何も知る必要がなく、さ
らに、グループに参加するために使用されたアプリケー
ション名を提供したアプリケーション・メンバによって
確立されたデータ・チャネルに関して知る必要もない。
同様に、アプリケーションがグループを抜けるとき、自
動的に、有効なデータ・チャネルが再確立される。
サポート・システムによる組合せチャネルおよび直列
化チャネルの作成を第20図の流れ図によって示す。
サブシステム17は、もちろんプログラミングのための
モデルにすぎない組合せチャネルを実施するために、少
なくとも受信側ポートのアドレスを含む、各組合せチャ
ネル用のチャネル・セット・テーブルを維持する。第21
図の流れ図に示すように、サブシステム17は、組合せチ
ャネル・セットの一部である指定されたバッファ受信側
ポートへのデータの送信を求めるsend_dataコマンドに
応答して、テーブルを使い尽くすまで、チャネル・セッ
ト中の各受信側ポートにデータを送信し続ける。
サブシステム17は、第22図の流れ図に示した直列化チ
ャネルを実施するために、すべての受信側ポートのアド
レスを含むチャネル・セット・テーブルを確立する同様
な技術を使用する。しかし、サブシステム17は、直列化
すべきテータ項目が、送信側ポートからロードされ、か
つ該データ項目をすべての受信側ポートに送信する上で
所望される順序に保持される、チャネル用の直列化待ち
行列を維持する必要がある。
チャネル・タイプが「同期」のときは、チャネル・セ
ットのチャネルの同期も提供される。たとえば、グルー
プの１人（または複数の可能性もある）のメンバによっ
て送信された複数のデータ・タイプ（たとえば、オーデ
ィオ、ビデオ、キーストローク、マウス・ポインティン
グ）がグループのすべての受信側メンバで同期式に送ら
れるようにグループのメンバの間にｎ方向通信を確立す
る必要があることが多い。データ・パケットの同期は、
それぞれの参加者が最小限に関与することによって基礎
システムで行われる。
このチャネル・セット・タイプは、ターゲット・アプ
リケーションへの別々のデータ・チャネルを介してオー
ディオやビデオなどの異なるデータ・タイプを発信元ア
プリケーションが送信するものである。通常、単一の発
信元アプリケーションと単一のターゲット・アプリケー
ションがある。しかし、この場合には、同期受信側チャ
ネルが同じアプリケーションにあれば、単一の発信元ア
プリケーションが複数のターゲット・アプリケーション
に送信することができ、複数の発信元アプリケーション
が複数のターゲット・アプリケーションに送信すること
ができる。以下で、典型的な例を示す。
概念的には、送信側ポートからのデータ・パケットを
同期し、データの送信時にデータ・ストリームに同期パ
ルスを挿入する、特性を有する指定されたチャネル・セ
ットを介してデータが送信される。関連するチャネルの
うちの１つの受信側端末に同期パルスが到着するときに
必ず、そのチャネルのデータは、一致する同期パルスが
他のすべてのチャネルに到着するまで保持される。すべ
ての同期パルスが到着すると、データは次の同期パルス
１つのチャネルに到着するまですべてのチャネルを介い
て流れることを許可される。同期パルスは、データが提
供される前に、基礎システムによって削除される。これ
を第23図に示し、表記上、以下のように表す。
CSname｛［SP1:RP1］，［SP2:RP2］,...｝synchrorised アプリケーションＡが、まず第２のアプリケーション
Ｂとの以下の同期チャネル・セットを確立する場合、 CSname｛［SPa1:RPb1］，［SPa2:RPb2］｝synchronised 次いで、他のアプリケーションＣとの協調セッション
を形成し、同じ送信側ポートとのそれ以上の同期チャネ
ルを追加することができる。すなわち、 CSname｛［SPa1:RPc1］，［SPa2,:RPc2］synchronised この場合、アプリケーションＢの受信側ポートとアプ
リケーションＣの受信側ポートとに到着するデータの間
で同期が取られる。表記上、この結果得られるチャネル
・セットは以下のとおりである。
CSname｛［SPa1:RPb1,RPc1］，［SPa2:RPb2,RPc2］｝sy
nchronised 同様に、アプリケーションＡが１つのデータ・タイプ
用のチャネル・セットを確立し、 CSname｛［SPa1:RPb1,RPc1］｝synchronised アプリケーションＤが第２のデータ・タイプ用の同じ
チャネル・セットを確立し、 CSname｛［SPd2:RPb2,RPc2］｝synchronised アプリケーションＡおよびＤが現在、協調グループを
形成している場合、データ・タイプ１とデータ・タイプ
２の通信はアプリケーションＢおよびアプリケーション
Ｃで同期される。すなわち、同期チャネル・セットは現
在、以下のとおりである。
CSname｛［SPa1:RPb1,RPc1］，［SPd2:RPb2,RPc2］｝sy
nchronised すべての同期パルスが一致する前にかなりの遅延があ
る場合、基礎システムは関連ポートの速度を上げ、ある
いは下げることを要求する適切な制御信号を送信側ポー
トに送信す。
協調グループ作業では、アプリケーションは２つのリ
モート・アプリケーションの間にリンクをセットアップ
する媒介として働くことが多い。
ポートを接続しウェルドしてデータのストリーム化を
サポートすることによって、アプリケーションは２つの
リモート・ワークステーションの間でデータを送信する
上でのリンクとしての働きに関与する作業の大部分（あ
るいはすべての場合もある）を基礎システム17に移すこ
とができる。リンクが確立されると、アプリケーション
はデータのストリーム化を完全に基礎システムによって
実行するための手段を提供することによってデータ送信
への関与を削減することができる。
論理チャネルは、一方の端にある送信側ポートと他方
の端にある受信側ポートを含む１方向データ・パイプか
ら成ると定義されている。送信側ポートの構造は第８図
に示した。アプリケーションに関するかぎり、ポートは
チャネルとのインタフェースとして働く。
アプリケーションは、さまざまな事象を通知される事
象ハンドラを備えていることも必要である。システム定
義事象は、データ送受信エラーの肯定応答を含む。どち
らの端にあるアプリケーションでも他方の端にアプリケ
ーション定義文字列を送信できるようにする機能が提供
されている。この信号機能は、他方の端で信号事象をレ
イズする。
アプリケーションはこれで、データを送信しようとす
る際に呼び出されるユーザ出口を任意選択で提供するこ
とができる。このユーザ出口は、フィルタとして働き、
所望どおりにデータを挿入し、削除し、修正することが
できる。ユーザ出口に割り当てることができるタスクに
は、圧縮と暗号化がある（対応する圧縮解除と非暗号化
は受信側ポートにあるユーザ出口で行われる）。
同じアプリケーション内で、あるタイプのポートを数
個使用することができる。各タイプのポートを１つ有す
るアプリケーションは、受信側ポートで受信され、送信
側ポートを介して送られるあらゆるデータ・パケットを
単に送信することによって、単純な媒介として働くこと
ができる。この機能を実行するためのプログラムは、概
念的には非常に簡単だが、それにもかかわらずかなりの
オーバヘッドを伴う。というのは、各データ・パケット
を読み取り、データを受信側バッファから送信側バッフ
ァに移動し、次いで書き込む必要があるからである。こ
のオーバヘッドを削減できるように、基礎システムによ
って２つの機能、接続とウェルドが提供される。
第24図に示したように、第１の機能、接続は実際上、
受信側ポートを送信側ポート上に接着し、２つのポート
は依然としてアプリケーションによって参照できるが、
データ・フローは自動的に接続を介して流れるようにす
る。このデータのストリーム化は、関与するオーバヘッ
ドを削減する。なぜなら、アプリケーションはもはや、
各データ・パケットを受信し、移動し、次いで送信する
必要がなくなるからである。図から明らかなように、現
在、基礎システムによって維持する必要がある待ち行列
は１つだけである。
接続後、２つのポートはそのままアプリケーション内
に存在し、したがって様々なポート関連機能は引き続き
使用することができる。たとえば、ポートを再び切断し
て削除することができ、引き続き信号を送信することが
できる。もはやデータ経路へのアクセスはないので、も
はや送信（送信側ポートを介する）も受信（受信側ポー
トを介する）も不可能である。
リモート信号が自動的に渡されないので、もはや事象
ハンドラは必要とされないことに留意されたい。しか
し、２つのユーザ出口は共に保持される。これは、これ
らの出口がデータの保全性を維持するのに必要なデータ
変換などのタスクを実行できるからである。ユーザ出口
はアプリケーション・プログラムの一部なので、アプリ
ケーションが終了すると、接続は（両方のポートと共
に）失われる。
どちらのポートもユーザ出口を必要としない場合は、
接続をウェルドすることができる。ウェルドは、ポート
の削除、したがってアプリケーションとチャネルの間の
すべてのリンクの切断を伴う。ポートはもはや存在しな
いので、ウェルドを取り消すことはできない。最終的な
結果は、２つのリモート端末の間にチャネルを直接接続
した場合と同様である。アプリケーションは、もはや関
与していないので、ウェルド後に、所望なら終了するこ
とができる。第25図は、ウェルドの結果を示す。
これによって、ウェルド後に、基礎システムによって
かなりの最適化を実行できることに留意されたい。たと
えば、データ・トラフィックを、このノードを介して流
れないように経路変更することができる。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ランバート、ハワード イギリス国ハンプシャー、サザンプト ン、ヘッジ・エンド、ノルデック・ガー デンズ22 (72)発明者 ミッチェル、ハリー、デヴィッド イギリス国サーレイ、リッチモンド・ア ポン・テイームズ、ザ・ハーミテイジ18

Claims (22)

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB9223521A GB2272312A (en) 1992-11-10 1992-11-10 Collaborative working in a network.
GB9223521.7 1992-11-10

Publications (2)

Publication Number Publication Date
JPH07503569A JPH07503569A (ja) 1995-04-13
JP2544905B2 true JP2544905B2 (ja) 1996-10-16

Family

ID=10724821

Family Applications (1)

Application Number Title Priority Date Filing Date
JP6511850A Expired - Fee Related JP2544905B2 (ja) 1992-11-10 1993-11-10 ネットワ―クにおける協調作業用ワ―クステ―ション及び協調作業方法

Country Status (6)

Country Link
US (1) US5649105A (ja)
EP (1) EP0620936B1 (ja)
JP (1) JP2544905B2 (ja)
DE (1) DE69331660T2 (ja)
GB (1) GB2272312A (ja)
WO (1) WO1994011814A1 (ja)

Families Citing this family (118)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08153076A (ja) * 1994-11-30 1996-06-11 Canon Inc 協調作業支援方法及びその装置
US5799318A (en) * 1993-04-13 1998-08-25 Firstfloor Software Method and apparatus for collecting and displaying information from diverse computer resources
JP3326292B2 (ja) * 1994-05-24 2002-09-17 株式会社東芝 通信機器及びその通信方法
EP0715268B1 (en) * 1994-11-30 2007-04-25 Canon Kabushiki Kaisha Information processing system
US5854898A (en) 1995-02-24 1998-12-29 Apple Computer, Inc. System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
US7079177B2 (en) * 1995-02-27 2006-07-18 Canon Kabushiki Kaisha Remote control system and access control method for information input apparatus with limitation by user for image access and camemremote control
JPH0934843A (ja) * 1995-07-18 1997-02-07 Canon Inc 処理システム及び処理装置
US6301339B1 (en) 1995-11-15 2001-10-09 Data Race, Inc. System and method for providing a remote user with a virtual presence to an office
US5960173A (en) * 1995-12-22 1999-09-28 Sun Microsystems, Inc. System and method enabling awareness of others working on similar tasks in a computer work environment
US9094384B2 (en) * 1996-02-16 2015-07-28 Reference Ltd., Limited Liability Company TCP/IP protocol network with satellite nodes
US7130888B1 (en) * 1996-02-16 2006-10-31 G&H Nevada-Tek Method and apparatus for controlling a computer over a TCP/IP protocol network
US7100069B1 (en) * 1996-02-16 2006-08-29 G&H Nevada-Tek Method and apparatus for controlling a computer over a wide area network
US6173332B1 (en) 1996-03-06 2001-01-09 Paul L. Hickman Method and apparatus for computing over a wide area network
US5933597A (en) * 1996-04-04 1999-08-03 Vtel Corporation Method and system for sharing objects between local and remote terminals
JPH09274607A (ja) * 1996-04-08 1997-10-21 Hitachi Ltd コンピュータ・システムおよびその運用方法
US7167897B2 (en) * 1996-05-08 2007-01-23 Apple Computer, Inc. Accessories providing a telephone conference application one or more capabilities independent of the teleconference application
US5857189A (en) * 1996-05-08 1999-01-05 Apple Computer, Inc. File sharing in a teleconference application
US5799149A (en) * 1996-06-17 1998-08-25 International Business Machines Corporation System partitioning for massively parallel processors
US8145701B2 (en) 1996-06-28 2012-03-27 Jordaan Consulting Ltd. Iii, Llc Methods and systems for providing storage of a data file over a computer network
US6920507B1 (en) * 1996-06-28 2005-07-19 Metadigm Llc System and corresponding method for providing redundant storage of a data file over a computer network
US5862346A (en) 1996-06-28 1999-01-19 Metadigm Distributed group activity data network system and corresponding method
US5862330A (en) * 1996-07-16 1999-01-19 Lucent Technologies Inc. Technique for obtaining and exchanging information on wolrd wide web
US7031442B1 (en) 1997-02-10 2006-04-18 Genesys Telecommunications Laboratories, Inc. Methods and apparatus for personal routing in computer-simulated telephony
US6480600B1 (en) 1997-02-10 2002-11-12 Genesys Telecommunications Laboratories, Inc. Call and data correspondence in a call-in center employing virtual restructuring for computer telephony integrated functionality
US6104802A (en) 1997-02-10 2000-08-15 Genesys Telecommunications Laboratories, Inc. In-band signaling for routing
US6704785B1 (en) 1997-03-17 2004-03-09 Vitria Technology, Inc. Event driven communication system
US6122631A (en) * 1997-03-28 2000-09-19 International Business Machines Corporation Dynamic server-managed access control for a distributed file system
JPH10283293A (ja) * 1997-03-31 1998-10-23 Nec Corp アプリケーション共有システム及びプログラムを記録した機械読み取り可能な記録媒体
US6061741A (en) * 1997-05-28 2000-05-09 International Business Machines Corporation Method and apparatus for synchronization of connectionless applications across a network by using simple encryption tokens
US6182146B1 (en) * 1997-06-27 2001-01-30 Compuware Corporation Automatic identification of application protocols through dynamic mapping of application-port associations
US6711611B2 (en) 1998-09-11 2004-03-23 Genesis Telecommunications Laboratories, Inc. Method and apparatus for data-linking a mobile knowledge worker to home communication-center infrastructure
US6985943B2 (en) 1998-09-11 2006-01-10 Genesys Telecommunications Laboratories, Inc. Method and apparatus for extended management of state and interaction of a remote knowledge worker from a contact center
USRE46528E1 (en) 1997-11-14 2017-08-29 Genesys Telecommunications Laboratories, Inc. Implementation of call-center outbound dialing capability at a telephony network level
US7907598B2 (en) 1998-02-17 2011-03-15 Genesys Telecommunication Laboratories, Inc. Method for implementing and executing communication center routing strategies represented in extensible markup language
US6332154B2 (en) 1998-09-11 2001-12-18 Genesys Telecommunications Laboratories, Inc. Method and apparatus for providing media-independent self-help modules within a multimedia communication-center customer interface
US6138139A (en) * 1998-10-29 2000-10-24 Genesys Telecommunications Laboraties, Inc. Method and apparatus for supporting diverse interaction paths within a multimedia communication center
US6173287B1 (en) * 1998-03-11 2001-01-09 Digital Equipment Corporation Technique for ranking multimedia annotations of interest
USRE46153E1 (en) 1998-09-11 2016-09-20 Genesys Telecommunications Laboratories, Inc. Method and apparatus enabling voice-based management of state and interaction of a remote knowledge worker in a contact center environment
US6295535B1 (en) 1998-11-13 2001-09-25 Board Of Trustees Operating Michigan State University Method and system for creating designs using internet-based agents
US7043529B1 (en) * 1999-04-23 2006-05-09 The United States Of America As Represented By The Secretary Of The Navy Collaborative development network for widely dispersed users and methods therefor
US6853651B1 (en) 1999-06-17 2005-02-08 Cingular Wireless Ii, Inc. System and method for outbox-capable wireless transmission
US7929978B2 (en) 1999-12-01 2011-04-19 Genesys Telecommunications Laboratories, Inc. Method and apparatus for providing enhanced communication capability for mobile devices on a virtual private network
US6658498B1 (en) * 1999-12-08 2003-12-02 International Business Machines Corporation Method, system, program, and data structures for reconfiguring output devices in a network system
US20020026478A1 (en) * 2000-03-14 2002-02-28 Rodgers Edward B. Method and apparatus for forming linked multi-user groups of shared software applications
AU2001247462A1 (en) * 2000-03-15 2001-09-24 Quaadros Technologies, Inc. Method and system for linked communication between client stations
AU2001267581A1 (en) 2000-07-15 2002-01-30 Filippo Costanzo Audio-video data switching and viewing system
US6934766B1 (en) 2000-11-02 2005-08-23 Cisco Technology, Inc. Method and apparatus for exchanging event information between computer systems that reduce perceived lag times by subtracting actual lag times from event playback time
US7000011B1 (en) * 2000-11-06 2006-02-14 Hewlett-Packard Development Company, Lp. Designing interconnect fabrics
US20020065874A1 (en) * 2000-11-29 2002-05-30 Andrew Chien Method and process for virtualizing network interfaces
US8472931B2 (en) 2002-11-25 2013-06-25 Telesector Resources Group, Inc. Methods and systems for automatic communication line management based on device location
US8472428B2 (en) 2001-02-27 2013-06-25 Verizon Data Services Llc Methods and systems for line management
US8761363B2 (en) 2001-02-27 2014-06-24 Verizon Data Services Llc Methods and systems for automatic forwarding of communications to a preferred device
US8750482B2 (en) 2001-02-27 2014-06-10 Verizon Data Services Llc Methods and systems for preemptive rejection of calls
US8488766B2 (en) * 2001-02-27 2013-07-16 Verizon Data Services Llc Methods and systems for multiuser selective notification
US8798251B2 (en) 2001-02-27 2014-08-05 Verizon Data Services Llc Methods and systems for computer enhanced conference calling
US8472606B2 (en) 2001-02-27 2013-06-25 Verizon Data Services Llc Methods and systems for directory information lookup
US8494135B2 (en) 2001-02-27 2013-07-23 Verizon Data Services Llc Methods and systems for contact management
US8488761B2 (en) 2001-02-27 2013-07-16 Verizon Data Services Llc Methods and systems for a call log
US8467502B2 (en) 2001-02-27 2013-06-18 Verizon Data Services Llc Interactive assistant for managing telephone communications
US8503639B2 (en) 2001-02-27 2013-08-06 Verizon Data Services Llc Method and apparatus for adaptive message and call notification
US8873730B2 (en) 2001-02-27 2014-10-28 Verizon Patent And Licensing Inc. Method and apparatus for calendared communications flow control
US8503650B2 (en) 2001-02-27 2013-08-06 Verizon Data Services Llc Methods and systems for configuring and providing conference calls
US8774380B2 (en) 2001-02-27 2014-07-08 Verizon Patent And Licensing Inc. Methods and systems for call management with user intervention
US8751571B2 (en) * 2001-02-27 2014-06-10 Verizon Data Services Llc Methods and systems for CPN triggered collaboration
DE10114208A1 (de) * 2001-03-23 2002-05-08 Trw Automotive Safety Sys Gmbh Gassack-Modul
WO2003009126A1 (en) * 2001-07-19 2003-01-30 Digeo, Inc. System and method for managing television programs within an entertainment system
US20030018970A1 (en) * 2001-07-19 2003-01-23 Digeo, Inc. Object representation of television programs within an interactive television system
US20030061349A1 (en) * 2001-09-24 2003-03-27 George Lo Method and system for collaboratively developing programming code for programmable controllers
US20030088875A1 (en) * 2001-11-08 2003-05-08 Gay Lance J Simultaneous viewing of video files on networked computer systems
US7644144B1 (en) 2001-12-21 2010-01-05 Microsoft Corporation Methods, tools, and interfaces for the dynamic assignment of people to groups to enable enhanced communication and collaboration
US20030145294A1 (en) * 2002-01-25 2003-07-31 Ward Julie Ann Verifying interconnect fabric designs
US9009004B2 (en) * 2002-01-31 2015-04-14 Hewlett-Packasrd Development Comany, L.P. Generating interconnect fabric requirements
US9392120B2 (en) 2002-02-27 2016-07-12 Verizon Patent And Licensing Inc. Methods and systems for call management with user intervention
US7509577B2 (en) * 2002-03-08 2009-03-24 Toshiba Corp Oration Method and system for implementing a clipboard
US20030195994A1 (en) * 2002-04-16 2003-10-16 International Business Machines Corporation Online collaboration method and system
US8489742B2 (en) * 2002-10-10 2013-07-16 Convergys Information Management Group, Inc. System and method for work management
US7302674B1 (en) * 2002-11-26 2007-11-27 Unisys Corporation Automating document reviews in a project management system
US7743022B2 (en) 2003-02-28 2010-06-22 Microsoft Corporation Method and system for synchronizing data shared among peer computing devices
US7640324B2 (en) * 2003-04-15 2009-12-29 Microsoft Corporation Small-scale secured computer network group without centralized management
US20040210846A1 (en) * 2003-04-21 2004-10-21 Olsen Gregory P. Transparent network clipboard sharing
US7640506B2 (en) * 2003-06-27 2009-12-29 Microsoft Corporation Method and apparatus for viewing and managing collaboration data from within the context of a shared document
US20050010386A1 (en) * 2003-06-30 2005-01-13 Mvalent, Inc. Method and system for dynamically modeling resources
US7685598B1 (en) 2003-12-23 2010-03-23 The Weather Channel, Inc. Desktop application framework
EP1560137A1 (en) * 2004-01-30 2005-08-03 Sap Ag Technique for reliable message confirmation
US7895020B2 (en) * 2004-04-01 2011-02-22 General Dynamics Advanced Information Systems, Inc. System and method for multi-perspective collaborative modeling
US7818679B2 (en) * 2004-04-20 2010-10-19 Microsoft Corporation Method, system, and apparatus for enabling near real time collaboration on an electronic document through a plurality of computer systems
US20050265359A1 (en) * 2004-05-13 2005-12-01 Drew Julie W Optimizing switch port assignments
JP4626322B2 (ja) * 2005-02-03 2011-02-09 富士ゼロックス株式会社 プログラム
US8155014B2 (en) * 2005-03-25 2012-04-10 Cisco Technology, Inc. Method and system using quality of service information for influencing a user's presence state
US8015403B2 (en) 2005-03-28 2011-09-06 Cisco Technology, Inc. Method and system indicating a level of security for VoIP calls through presence
US7920847B2 (en) * 2005-05-16 2011-04-05 Cisco Technology, Inc. Method and system to protect the privacy of presence information for network users
US7764699B2 (en) * 2005-05-16 2010-07-27 Cisco Technology, Inc. Method and system using shared configuration information to manage network access for network users
US8079062B2 (en) * 2005-05-16 2011-12-13 Cisco Technology, Inc. Method and system using presence information to manage network access
US7424670B2 (en) * 2005-09-09 2008-09-09 Microsoft Corporation Annotating documents in a collaborative application with data in disparate information systems
US7870493B2 (en) 2005-10-03 2011-01-11 Microsoft Corporation Distributed clipboard
US8332470B2 (en) * 2005-11-30 2012-12-11 Oracle International Corporation Methods and apparatus providing collaborative access to applications
US9008075B2 (en) 2005-12-22 2015-04-14 Genesys Telecommunications Laboratories, Inc. System and methods for improving interaction routing performance
US7614060B2 (en) * 2006-04-28 2009-11-03 Microsoft Corporation Unified concept of presence
US20070297332A1 (en) * 2006-06-22 2007-12-27 James Andrew Broberg Distributed resource allocation in stream processing systems
US20080052355A1 (en) * 2006-08-25 2008-02-28 Lance John M Method, system, and program product for organizing the contributions of each of a plurality of participants to an electronic communication
US7852783B2 (en) * 2006-12-07 2010-12-14 Cisco Technology, Inc. Identify a secure end-to-end voice call
US7979550B2 (en) * 2007-05-24 2011-07-12 Sihai Xiao Methods and apparatuses for adjusting bandwidth allocation during a collaboration session
US8108777B2 (en) 2008-08-11 2012-01-31 Microsoft Corporation Sections of a presentation having user-definable properties
US20100077057A1 (en) * 2008-09-23 2010-03-25 Telefonaktiebolaget Lm Ericsson (Publ) File Transfer in Conference Services
FR2936628B1 (fr) * 2008-09-26 2011-04-01 Vincent Garnier Plate-forme de reseau informatique
US8046417B2 (en) * 2009-05-12 2011-10-25 At&T Intellectual Property I, L.P. System and method for quality of presence
US8838694B2 (en) * 2009-06-19 2014-09-16 Futurewei Technologies, Inc. System and method for shared multimedia experiences across multiple subscriptions
US9092115B2 (en) * 2009-09-23 2015-07-28 Microsoft Technology Licensing, Llc Computing system with visual clipboard
US9659265B2 (en) * 2009-10-12 2017-05-23 Oracle International Corporation Methods and systems for collecting and analyzing enterprise activities
US20130151970A1 (en) * 2011-06-03 2013-06-13 Maha Achour System and Methods for Distributed Multimedia Production
USD669487S1 (en) * 2011-09-12 2012-10-23 Microsoft Corporation Display screen with user interface
US9888568B2 (en) 2012-02-08 2018-02-06 Crane Electronics, Inc. Multilayer electronics assembly and method for embedding electrical circuit components within a three dimensional module
JP5962493B2 (ja) * 2012-12-20 2016-08-03 富士通株式会社 プログラム、情報処理装置およびオブジェクト送信方法
US10933209B2 (en) * 2013-11-01 2021-03-02 Georama, Inc. System to process data related to user interactions with and user feedback of a product while user finds, perceives, or uses the product
US9230726B1 (en) 2015-02-20 2016-01-05 Crane Electronics, Inc. Transformer-based power converters with 3D printed microchannel heat sink
US10015230B1 (en) 2016-02-09 2018-07-03 Robert Buergi Copying and pasting among networked devices
US10939872B2 (en) 2017-06-01 2021-03-09 Stryker Corporation Patient care devices with network variables
US10916073B2 (en) 2018-05-01 2021-02-09 Ford Global Technologies, Llc Vehicle network data streaming system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0201065A3 (en) * 1985-05-06 1989-08-16 Computer X, Inc. Virtual single machine with logical ring and with message-like hardware interrupts and processor exceptions
GB8814633D0 (en) * 1987-11-18 1988-07-27 Ibm Bus flow control mechanism
US5008853A (en) * 1987-12-02 1991-04-16 Xerox Corporation Representation of collaborative multi-user activities relative to shared structured data objects in a networked workstation environment
JP2791146B2 (ja) * 1989-11-15 1998-08-27 株式会社日立製作所 データ処理装置
JP2793308B2 (ja) * 1989-12-21 1998-09-03 株式会社日立製作所 対話システム
US5195086A (en) * 1990-04-12 1993-03-16 At&T Bell Laboratories Multiple call control method in a multimedia conferencing system
JP2865827B2 (ja) * 1990-08-13 1999-03-08 株式会社日立製作所 会議システムにおけるデータ蓄積方法
JP3161725B2 (ja) * 1990-11-21 2001-04-25 株式会社日立製作所 ワークステーションおよび共同情報処理システム
FR2683938B1 (fr) * 1991-11-20 1993-12-31 Gec Alsthom Sa Disjoncteur-auto sectionneur a hexafluorure de soufre et applications aux cellules et aux postes et sous-stations prefabriques.

Also Published As

Publication number Publication date
WO1994011814A1 (en) 1994-05-26
DE69331660D1 (de) 2002-04-11
US5649105A (en) 1997-07-15
DE69331660T2 (de) 2003-02-06
EP0620936A1 (en) 1994-10-26
GB9223521D0 (en) 1992-12-23
GB2272312A (en) 1994-05-11
EP0620936B1 (en) 2002-03-06
JPH07503569A (ja) 1995-04-13

Similar Documents

Publication Publication Date Title
JP2544905B2 (ja) ネットワ―クにおける協調作業用ワ―クステ―ション及び協調作業方法
JP2544904B2 (ja) 協調作業ネットワ―クでの呼出し管理ワ―クステ―ション及び方法
US5719942A (en) System and method for establishing a communication channel over a heterogeneous network between a source node and a destination node
US5652866A (en) Collaborative working method and system for a telephone to interface with a collaborative working application
US7167897B2 (en) Accessories providing a telephone conference application one or more capabilities independent of the teleconference application
US5764902A (en) Conditional insert or merge in a data conference
US5572582A (en) Method and apparatus for establishing communication between two teleconferencing endpoints
US6202085B1 (en) System and method for incremental change synchronization between multiple copies of data
US5854898A (en) System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
EP0497022B1 (en) Conference system
EP0453128A2 (en) Multiple call control method in a multimedia conferencing system
AU6815594A (en) Multimedia communications network
JPH10301871A (ja) 通信システムで比較的大きなデータ・オブジェクトの伝送を制御するシステムと方法
US5748618A (en) Multilevel arbitration in a data conference
JPH09269931A (ja) 協調作業環境構築システム、その方法及び媒体
US5491798A (en) Method for network call management
JPH06202997A (ja) ネットワーク・クリップボード機構を提供する方法及びネットワーク・クリップボード機構用の計算機
Akkoyunlu et al. Interprocess communication facilities for network operating systems
Ooi et al. Indiva: A middleware for managing distributed media environment
JP2001211438A (ja) コミュニケーション支援システム
JP2001103066A (ja) 通信装置及び通信方法
Aldred et al. Call Management in a Lakes environment
JP2949672B2 (ja) グループ通信システムのグループ接続制御方法
Aldred et al. Community networking-a LAKES approach
Aldred et al. Connection Management in a Lakes environment

Legal Events

Date Code Title Description
LAPS Cancellation because of no payment of annual fees