分散処理オペレーティングシステムの構築法に関する研究

(1)

九州大学学術情報リポジトリ

Kyushu University Institutional Repository

分散処理オペレーティングシステムの構築法に関する研究

谷口, 秀夫

https://doi.org/10.11501/3059382

出版情報：Kyushu University, 1991, 博士（工学）, 論文博士バージョン：

権利関係：

(2)

多再三玉主主貝元衣子o s宗吉壬きによるタテ置支鼻息望室o s

本章では、既存の同種o sを結合して分散処理o sを構築する場合について述べる。この場合、 2. 1節で述べた要求条件をすべて満足することは難しく、表 2. 3- 1に示したように成し得る限界がある。構築上の課題についても、新規に分散処理o sを作成する場合に比べ、採用できる方式が限られる。

ここでは、通信路の特徴を生かした機能として、 LANの放送機能を使って多くの資源に一度にアクセスできる機能をAPに提供することを特徴とするo s構成方式を提案する。具体的には、 LANの高速性と放送機能を利用したサービスを実現するために、ファイル管理機能をネットワーク化したリモートファイルアクセス機能について述べる。サービス例として、複数のワークステーションで同じ画面を見ながら作業を行なうことができる電子会議サービスがある。電子会議サーピスの詳細は6章で述べる。

具体的な実現上の課題解決策として、三つの方式を述べる。一つは、分散しているファイルを統一管理する方式である。二つめは、一つの資源だけではなく資源の集合(以降、グループファイルと呼ぶ。これに対し、一つの資源を単一ファイルと呼ぶ〉に対する一括アクセスを従来のAPインタフェースを保存して実現する方式についてである。最後に、リモートファイルアクセスの処理要求と処理結果を通信する制御方式についてである。また、 UNIXでの実現例により、リモートファイルアクセスとローカルファイルアクセスの性能を比較する。

以降、 5. 1節では、本分散処理o sの特徴について述べる。 5. 2節では、

リモートファイルアクセス機能の構成法を述べる。 5. 3節では、 UNIXにおけるリモートファイルアクセス機能の実現法を述べる。 5. 4節では、性能評価と考察を行なう。 5. 5節では、本章のまとめを述べる。

5 _ 1 ヌ幸之タミ計責女友岳王里o s ι〉牛寺宅設

- 67-

(3)

既存のo sを結合して分散処理o sを構築する場合、既にスタンドアロン環境で動く多くのAPがあると想定できる。したがって、「既存のAPを分散環境でも利用できる」ことが非常に大切である。そのためには、各計算機上のo sに自

律性をもたせたままリモートへの要求のみを他計算機へ転送するという機構を追加する方式が良い。その機構として、ライブラリコール転送とシステムコール転送が考えられる。既存のAPを再コンパイルなしにそのまま分散環境でも利用できるためにはシステムコール転送でなくてはならない。この方式をファイルアクセス処理に適用したリモートファイルアクセスの動作例を図5. 1 - 1に示す。

[ローカルシステム] [リモートシステム]

ユーザプログラム

図5. 1 - 1において、ユーザプログラムが要求したファイルアクセスのシステムコールは、ローカル/リモートの判断を行ない、ローカル処理であればディスク制御を介してファイルアクセスを行なう。リモート処理の場合、リモートアクセス制御がLAN制御を利用してシステムコール転送を行なう。リモートシステム側では、転送されたシステムコールに基づきディスク制御を介してファイルアクセスを行なう。ファイルアクセスの結果は、逆の経路によりユーザプログラム

AP部カーネル部

に返却される。

この方式によるリモートファイルアクセス機能の実現においては、 APの作成を容易にする等のために、対APインタフェースがローカルにあるファイルアクセスと同形式であることだけでは充分でない。さらに、プロセス制御などのファイルアクセス以外への拡張性があり、かつアクセス速度が速いことが求められる。

これらの要求を満足するためには、 ①ネットワーク内に分散しているファイルを統一管理する方式、 ②リモートへのアクセス要求転送方式、を実現する必要があ

リモートアクセス制御

イスク制御

図5. 1 - 1 リモートアクセスの動作例(ディスク1/0の場合)

る。

UNIXを基に上記方式の実現を図ったものとしては、 COCANET [Ro w82]， ALTOS-NET [Ka v83]， LOCUS [Wa183J， N ewcastle- Connection [B r 0 8 2 J， NM S _U [K a r 8 3 Jなどがあり、こ

れらの比較は文献[Br 082Jが詳しい。これらのo Sでは、 LANの高速性を生かした一対ーのリモートファイルアクセスを実現している。しかし、放送機能を生かした一対複数のリモートファイルアクセスは実現されていない。

ここで述べるo Sの特徴は、 LANの一つの特徴である放送機能を利用して、

一対複数のリモートファイルアクセスも実現したことである。つまり、上記の①

phU - 69-

(4)

と②に加え③グループファイルへの同時アクセス方式、を実現した。具体的には、

UNIXのディレクトリファイルの延長として「グループネットワークディレクトリ」の概念を導入し、グループファイルに対するリモートアクセス手段を実現した。本方式は、分散処理o sに対する要求条件と構築上の課題について表 5.

1 - 1の特徴を持っている。これにより、ローカルな環境を想定して作成されたプログラムに手を加えずに、そのまま電子会議などの放送形機能を必要とするサービス[坂本8 2 ]にも適用できる。

5 ^• 2 リモートファイノレアクセス者奨台包α〉

草君事尾文主主ミ

5. 2. 1 分散したファイルの統一管理方式

各計算機上で作成されたファイルについて、対APインタフェースを保存して分散環境内で一意に管理する。そのため、ファイルの先頭に、グローパル識別子と計算機識別子を付加する。グローパル識別子とは、ネットワーク化したことを示す識別子である。これは、分散したファイル全体の「ルート(根) Jになる。

計算機識別子は、そのファイルが存在する計算機に対応した特定の名前である。

これにより、ネットワーク内の全ファイルは、グローパル識別子の下で一つに管理できる。 APからのファイルアクセス要求に対し、 o s内部でAPが指定したファイル名に基づきそのファイルが存在する計算機を識別できる。

5. 2. 2 グループファイルへのアクセス方式

各計算機にある資源(グループファイル)に一度にアクセスできるリモートア

クセス機能を実現するため、複数の計算機からなるグループに対応する計算機識別子を導入する。これをグループ計算機識別子と呼ぶ。一方、一つの計算機に対応する計算機識別子は単一計算機識別子と呼んで区別する。

単一計算機識別子を利用したリモートアクセスは、二つの計算機関通信により実現される。これに対し、グループ計算機識別子を利用したリモートアクセスは、

複数の計算機関通信により実現される。しかし、アクセスを依頼した計算機の処

-70 -

表5. 1 - 1 本分散処理OSの特徴

一一一一一一一

^特徴

要求条件 ^{APインタフェース} ^{( 1})ファイルアクセスに関しローカル資源とリモート資源を統一的したインタフェースで提供

織能・負荷分散 ( 1 ) A Pについての分散が可能

分割単位 ( 1 ) 0 Sが単位

構築上の謀題インタフェース ( 1 )システムコール転送を実現

通信インタフェース ( 1 )完了型の通信インタフェース ( 2) 2階層を持つ

通信路 (1) LANを使用

(2) LANの放送機能を利用してグループ資源への一括アクセスを実現

- 71-

(5)

理を以下に述べる方式で行なうことにより、 APはグループファイルへのリモートアクセス処理を単一ファイルへのリモートアクセス処理の場合と同じ形で行なえる。

ムコール、さらにはライブラリ関数などいくつかの層が考えられる[Ka v83]

。既存o sを結合する場合、 o sの内部情報を送る内部コール転送は、内部コールのインタフェースが分散環境に適していないため、改造が非常に大変である。

また、ライブラリ関数を送るライブラリコール転送は、既存APを再コンパイルなしに利用できない。これらに対し、「システムコール転送Jは、ローカルな環境で作成したAPのソフトウェアを完全にそのまま分散環境でも実行できる。さらに、通信のオーバヘッド(回数〉が小さく、既存のo sの改造量が小さいため、

優れている。具体的には、 o s内で各システムコールがローカル処理かリモート処理かを判断した後、相手計算機にアクセス要求を転送する。相手計算機では、

要求に基づいてアクセスを代行実行後、その結果を返送する。

リモートファイルアクセスの通信制御手順は、通信速度の向上と機能の拡張性の点から、次の四つの点を実現した。第ーに、機能拡張が容易な2階層構成とする。一つは、リモートのファイルにアクセスする時の環境を設定する層であり、

リモートアクセス制御層と呼ぶ。具体的には、アクセスを代行するプロセス(以降、代行プロセスと呼ぶ)との通信パスの設定や開放およびその制御を行なう層である。もう一つは、実際にアクセスする内容や結果の転送を制御する層であり、

リモートアクセス転送層と呼ぶ。アクセスするファイル対応のパスを制御してリモートアクセス内容を転送(システムコール転送)する。

第二に、構成が容易な周期型( 1次局と2次局の構成〉とする。リモートファイルアクセスは、システムコールに基づいて行なわれる。つまり、そこにはアクセスを要求したAPプロセスが走行している計算機とファイルを持つ計算機の間に主従関係があり、同期型に合致する。

第三に、 LANは物理的信頼度が高くパケット異常は少ないことから、正常系の速度向上を重視して設計する。具体的には、単一リモートファイルアクセスではコマンド(アクセス要求のパケット) に対応するレスポンス(アクセス結果のパケット)をタイマ監視して通信での異常を検出する。グループリモートファイルアクセスでは、アクセス結果を返送しないためレスポンスはない。

第四に、リモートアクセス制御層にセグメンティング機能を持たせる。セグメンテイング機能とは、通信路の最大パケット長より大きいデータの転送が必要になった時、データを分割して転送し受信側で組み立てる機能である。この機能にグループファイルへの出力系のアクセスは、すべて放送形のアクセスとなり、

グループに属する全計算機lこアクセス内容を転送し、実行する。つまり、一つのアクセス要求で被数のファイルにアクセスできる。アクセス結果の返送を全計算機から行なうと、次のような問題があるためアクセス結果の返送は行なわない。

第一に、アクセスを要求したプロセスは、アクセス結果を受け取るため、グループ内の計算機数がわからないと終了時点が判断できない。そのために、グループ内の計算機数を管理しようとすると、各計算機で同様の管理が必要になり、その作成や変更および消去に伴う処理が複雑になる。第二に、通信の手順が複雑化して、アクセス速度の低下を招く。しかし、アクセス結果の返送を行なわないため、

アクセス結果を別の手段で確認する必要はある。例えば、目視確認できるウインドウの表示に利用する。

グループファイルからの入力系アクセスは、アクセス要求をグループの全計算機に転送するものの、指定された一つの計算機のみが実行して結果を返送する。

一方、アクセス要求を受けたグループの全計算機が実行し入力結果を返送することも考えられる。しかし、この場合には上記の出力系アクセス時の二つの問題に加え、さらに、対APインタフェースがグループファイルへのリモートアクセスと単一ファイルへのリモートアクセスで異なる、という問題がある。したがって、

特定の一つの計算機(以降、入力計算機と呼ぶ〉のみがアクセスを実行して結果を返すようにした方がよい。入力計算機の指定方法には、アクセス要求時に指定する方法もある。しかし、アクセスとは独立に入力計算機を指定する方式を採用する。これにより、既存の対APインタフェースを守って、放送形サービスのプログラム作成を容易にすることができる。具体的な入力計算機の決定法は、サービスに依存する。電子会議サービスの例を6章に述べる。

5. 2. 3 アクセス要求の転送単位と通信方式

他計算機へ転送するアクセス要求の単位として、 o s内の情報(例えば、ファイルを識別できる管理テープルのi d)や、対APインタフェースとなるシステ

内L 一73 -

(6)

より、 LANの最大パケット長よりも大きいデータのリモートアクセスが可能になる。また、データを分割してリモートアクセスを繰り返した場合に比べ、 LA Nのパケット数が減り、かっ代行プロセスの1/0回数も減る。

5 . 3 U N 1 X ，こまヨ&:rる言定王見、と去

前節に述べた分散処理o sの構成をUN 1 Xを基に実現した[谷口8 ₄] [坂本8 4 ]内容について以下に説明する。

5. 3. 1 グローバルトリーの導入

UNIXのファイル[Tho78Jは木構造で管理されており、パス名を持つディレクトリとファイルからなる。ファイルには、入出力機器を仮想化した特殊

ファイルとデータを持つ通常ファイルがある。ファイルは、すべてテープルで管理されている。ディレクトリや通常ファイルについては、管理テープルがそのファイル実体へのポインタを持っている。

U N 1 Xファイルシステムをネットワークに拡張するため、 3種の識別子を導入する。一つは、グローパル識別子としての「ネットワークルートディレクトリ

〈“//" と記述する) Jである。もう一つは、単一計算機識別子としての「単一ネットワークディレクトリ」である。最後に、グループ計算機識別子としての

「グループネットワークディレクトリ」である。これにより、分散環境内の全資源を図5. 3. 1-1に示すような一つのグローバルトリーで管理する。

図5. 3. 1-1は、単一ネットワークディレクトリn 0に対応する計算機におけるグローバルトリーの例を示したものである。図5. 3. 1-1において、

nO， n1， n2は単一ネットワークディレクトリであり、対応する各計算機におけるUNIXファイルシステムのルートディレクトリにあたる。したがって、

ローカル処理を行なう場合は、従来と同じようにパス名の先頭を “/" で書き始めることもできる。

グローバルトリー導入におけるディレクトリのファイル実体管理には、いくつかの方式が考えられる。集中管理方式とは、特定計算機がネットワーク全体のデ

- 74-

fo

nl

a b

//

、 -ー-ー " -

n2�・F 、-:_，�o

2 、、

，、

I \

，、、

I \

，、、

I \

fo

， J

，

fl

ハ

J 、

、

a c

リモートアクセスパス

4ー._.ーグループパス

図5. 3. 1-1 グローバルトリーの例(計算機nO上)

- 75-

(7)

イレクトリを持つ方式である。自己管理方式とは、各計算機が自計算機にある通常ファイルや特殊ファイルへのパスとなっているディレクトリを持つ方式である。

全体管理方式とは、各計算機がネットワーク全体のディレクトリを持つ方式である。さらに、集中管理方式と自己管理方式を併用した方式も考えられる。これらの方式の中で、以下の理由により、自己管理方式が優れている。一つは、ファイルの作成や削除などに伴う管理テープルの更新が容易である。二つめは、ローカルファイルへのアクセスは、従来のアクセス速度が維持できる。最後に、ファイルを管理する特別な計算機が不要である。

図5. 3. 1-1において、実線で結ばれたファイルの実体が、単一ネットワークディレクトリn 0に対応する計算機(以降、計算機n 0と記述する〉上に存在する。単一ネットワークディレクトリn 1， n 2は、各々計算機n 1や計算機 n 2にあるファイルへのアクセスパスとなる。破線がリモートアクセスのパスである。なお、グループネットワークディレクトリg 0および一点鎖線のグループパスに関しては、次項で説明する。

5. 3. 2 グループリモートファイルアクセス機能の実現

グループネットワークディレクトリの導入により、グループファイルへのリモートアクセス機能を実現する。このディレクトリは、 LANで定義されるグループアドレスと一対ーに対応させる。さらに、グループネットワークディレクトリを作成することにより、 “自計算機がそのグループに属する" という機能も兼ねる。例えば図5. 3. 1ー1において、 g 0は計算機n 0と計算機n 2からなるグループに対応するグループネットワークディレクトリである。具体的には、計算機n 2もグループネットワークディレクトリg 0を持っており、これにより、

g 0が持つLANのグループアドレスに対応するグループに計算機n 0と計算機

n 2が属する。

g 0を介した出力系のアクセスは、 “//gO/f1/a" のパス名指定により、計算機n 0上のファイル “f 1 / a " と計算機n 2上のファイル “f 1 / a

" に「一度に」アクセスできる。

r e a dシステムコールなどの入力系アクセスの処理は、入力計算機の指定状態に基づき実行する。 “//gO/f1/a" のパス名指定により、計算機n 0

-76 -

上のファイル “f1 / a .，または計算機n 2上のファイル “f1 / a tt にアクセスできる。例えば、入力計算機が計算機n 2に設定されている時には、入力処理は計算機n 2で行なわれ結果が返送される。この時、計算機n 0は何もしない。

入力計算機を指定する機能を独立した一つのシステムコールとした。これにより、グループ環境で動いているAPプロセスの入出力を別のプロセスにより制御できる。このことは分散環境でのサービス構築に非常に有効であり、その例については6章で説明する。入力計算機指定のシステムコール(s etn od)の例を表5. 3. 2-1に示すo このシステムコールに応じた処理については、次項で説明する。

5. 3. 3 アクセス要求の転送方式

リモートファイルアクセスの通信制御処理は、処理速度向上のためo s核内で実現した。各階層の内容と処理流れを以下に説明する。

リモートアクセス制御層では、相手計算機上の代行プロセスの生成や消去による通信パスの設定や開放およびデータの転送制御を行なう。さらに、リモートファイルをオープンしているプロセスがUNIXのf0 r kシステムコールを発行して二つのプロセスに分離した場合、対応する代行プロセスも分離させて通信パスを分離する。また、入力計算機指定のs e t n 0 dシステムコールに基づきグループの入力計算機を各計算機に通知する処理を行なう。ここで、代行プロセスとは、リモート処理を要求したAPプロセスに代わって、相手計算機上でシステムコールを実行するプロセスである。本層のパケット形式を図5. 3. 3 -1に示す。各構成要素は次の意味を持つ。パス番号は、代行プロセスに対応する通信パスを識別するものである。 D cは宛先/'{ス番号、 s cは送出元パス番号である。

具体的には、 D cは代行プロセスのプロセス番号、 s cはリモートファイルアクセスを要求したプロセスのプロセス番号を利用している。シーケンス番号は、同

一番号でのコマンドとレスポンスの対応づけと順次制御により、パケット欠落を監視する。制御部は、セグメンテイング機能を実現するためのパケット継続情報、

コマンドとレスポンスの識別情報、代行プロセスの設定や解放あるいは通信パスの分離や情報転送および入力計算機の設定指示の情報を持つ。情報部は、コマンドやレスポンスで必要となる情報を持つo

-77-

(8)

形式

J'\ラメータ

機能

表5. 3. 2-1 入力計算機指定のシステムコール例 s etn od ( path1. path2)

c h a _r * p a t h 1 グループネットワークディレクトリ名へのポインタ

c h a _r *path2; 単一ネットワークディレクトリ名へのポインタ

p a t h 1で指定されるグルーアネットワークディレクトリが持つグループにおいて、入力計算機をpath2で指定される単一ネ

ットワークディレクトリに対応する計算織に設定する。 _て三 _{土 ...}一一一-+^・4一一一ー→』

「τ;了卜Ic�

Dc，Sc ，パス番号 N : シーケンス番号

c _;制御都 1 :情報都

図5. 3. 3-1 リモートアクセス制御膚のパケット形式

- 78ー I - 79-

(9)

リモートアクセス転送層は、リモートファイルアクセス要求に基づき、アクセスするファイル対応の通信パスを制御して、アクセス情報の転送制御を行なう。

本層のパケット形式を図5. 3. 3-2に示す。各構成要素は次の意味を持つ。

パス番号は、通信ノマスを識別する。具体的には、アクセスを要求したプロセスと代行プロセス間で一致させたアクセスファイルを識別する「ファイル記述子」を利用している。シーケンス番号は、同一番号でのコマンドとレスポンスの対応づけと順次制御により、パケットの欠落を監視する。制御部は、コマンドとレスポンスの識別情報、 o p e nやw r i t eなどの1 4種類のシステムコールに対応したアクセス要求情報を持つo 情報部は、コマンドやレスポンスで必要となる情報を持つ。

以降、単一ファイルにアクセスする場合とグループファイルにアクセスする場合の各々について、処理の流れを説明する。

単一リモートファイルアクセスのシーケンス例として、ファイルをオープンし、

データをライト〈セグメンテイング処理あり)し、ファイルをクローズする場合

ldイト 1 ，{イ1・ 1バイト l，ぐイト

d ... ... ..._ ... __ --_ .... ， .... '----_ ....

司V 司，...- ...----_______"，....- __""，.， �

Dt St N C I

を図5. 3. 3-3に示し、以下に説明する。

Dt，St ^パス番号

o p e nシステムコールに基づく「ファイルのオープン処

シーケンス番号くs ^te p 1 >

NCI

帯IJ御都情報部理」は、最初に次の処理を行なう。リモートアクセス制御層のコマンド「代行プ

ロセス生成要求」により代行プロセスを生成し、リモートアクセス制御層の通信パスを設定する。ただし、当該APプロセスが同じ計算機上の別ファイルを既にオープンしている場合には、既にリモートアクセス制御層の通信パスが設定されている。そのため、この処理は行なわない。

図ち. 3. 3 -² リモートアクセス転送層のパケット形式

くs ^te p 2 > 次に、リモートアクセス転送層のコマンド「オープン要求」

によりファイルのオープン処理を行ない、結果をAPプロセスに返却する。

<step3> w r i t eシステムコールに基づく「ファイルへのライト

処理」は、次のように行なう。出力データがLANの最大パケット長より大きいため、リモートアクセス転送層のコマンド「ライト要求」によりデータを分割して転送する。 [被依頼側]の計算機では、パケットを組み立て、一つのw r i t eシステムコールを発行してライト処理を行ない、結果を返送する。

くs ^te p 4 > c 1 ₀s eシステムコールに基づく「ファイルのクローズ

処理」は、最初に次の処理を行なう。リモートアクセス転送層のコマンド「クロ

- 80- - 81-

(10)

ーズ要求」によりファイルのクローズ処理を行ない、結果をAPプロセスに返却する。

くst e p 5 > さらに、 <ste p4>の処理により、当該APプロセス

〔依頼側〕〔紋依願ffitl)

が同じ計算機上のファイルを一つもオープンしていない状態になった場合は、次の処理を行なう。リモートアクセス制御層のコマンド「代行プロセス消去要求」

により代行プロセスを消去して、リモートアクセス制御層の通信パスを開放する。

ウァイlレのオープン処理

代行プロセス生成処理

グループリモートファイルアクセスのシーケンス伊!として、ファイルをオープ

オープン処理

ンし、データをライト(セグメンテイング処理なし)し、入力計算機を[被依頼側B]に設定後データをリード(セグメンティング処理あり)し、ファイルをクローズする場合を図5. 3. 3-4に示し、以下に説明する。

オー7'ン結来通知l

くst e p 1 > ^o p e n システムコールに基づく「ファイルのオープン処

クローズ処理

理」は、最初に次の処理を行なう。リモートアクセス制御層のコマンド「代行プロセス生成要求」により、代行プロセスを生成し、リモートアクセス制御層の通信パスを設定する。ただし、当該APプロセスが同じグループの別ファイルを既にオープンしている場合には、この処理は行なわない。

くst e p 2 > 次に、リモートアクセス転送層のコマンド「オープン要求」

によりファイルのオープン処理を行なう。結果は返送しない。

ファイ/レのクローズ処理'

ライト処理ライト結扶辿知

くst e p 3 > w r i t eシステムコールに基づく「ファイルへのライト

代行プロセス消去処理処理」は、次のように行なう。出力データをリモートアクセス転送層のコマンド

「ライト要求」により転送する。グループに属する[被依頼側A]と[被依頼側代行プロセスmま結米辿知l

昨iuv ，，，ネカPHV 令制P A

B ]の各計算機では、パケットの内容に従いw r i t eシステムコールを発行し

図5. 3. 3-3 単一リモートファイルアクセスのシーケンス例

てライト処理を行なう。結果は返送しない。

くst e p 4 > s e t n ⁰ dシステムコールに基づく「入力計算機の設定処理」は、次のように行なう。リモートアクセス制御層のコマンド「入力計算機

設定要求」を使って、入力計算機を指定する。指定された[被依頼側B]は入力計算機であることを認識し、そうでない[被依頼側A]は入力計算機でないことを認識する。レスポンスは、新たに指定された入力計算機のみが返送する。

くst e p 5 > r e a dシステムコールに基づく「ファイルからのリード処理」は、次のように行なう。リモートアクセス転送層のコマンド「リード要求」

をグループに送る。 [被依頼側B]は入力計算機であるから、 r e ^a dシステム

- 82- - 83-

(11)

〔依頼側〕〔被依頼側A) 〔被依頼側B) (入カ計算織)

コールを発行してリード処理を実行する。さらに、入力データがLANの最大パケット長より大きいため、分割して転送する。一方、 [被依頼側AJは入力計算機でないから何もしない。最後に、入力を要求した[依頼側]の計算機は、受信したパケットを組み立てAPプロセスiこ返却する。

入力計算機の設定処理

代行プロセス生成処理

くs t e p 6 > c 1 ₀s eシステムコールに基づく「ファイルのクローズ

オープン処理

処理」は、最初に次の処理を行なう。リモートアクセス転送層のコマンド「クローズ要求」によりファイルのクローズ処理を行なう。結果は返送しない。

ワァイルへのライト処理

くst e p ⁷> さらに、くstep6>の処理により、当該APプロセスライト処理

が同じグループのファイルを一つもオープンしていない状態になった場合は、次

入力計算砲であることを認識

の処理を行なう。リモートアクセス制御層のコマンド「代行プロセス消去要求」

により代行プロセスを消去して、リモートアクセス制御層の通信パスを開放する。

政事�

クローズ処理

5. 3. 4 処理構成

U N ¹ Xの入出力制御が提供している内部コールは、処理を終了してから制御が戻ってくる完了型である。つまり、入力系処理を依頼すると何らかの入力があるまでそのプロセスの処理が停止させられてしまう。そのため、リモー卜ファイルアクセスの処理プロセスを入力系と出力系に分離した。また、アクセス速度の向上を考慮して、システムコール発行に基づくリモートファイルアクセス処理内容の送信処理は、 APプロセスの延長として走行する構成とした。処理内容は、

大きく次の五つに分類できる。 ( 1 )リモートファイルアクセス処理の全体を制御する部分。 (²)対応する通信相手の計算機からデータを受信する部分。 (³) 対応する通信相手の計算機へデータを送信する部分。 (⁴)リモートファイルアクセス内容の代行実行と実行結果の送信を行なう部分。 (5 )リモートへのアクセス依頼とアクセス結果の受信を行なう部分。構成を図5. ^3. ⁴ _- 1に示す。

図5. ^3. ⁴ - 1において、処理(²)や処理(³)のプロセスは通信相手の計算機対応に存在する。また、処理(⁴)のプロセス(代行プロセス〉はリモートファイルアクセスを要求した依頼側の計算機のAPプロセス対応に存在する。

ウァイルからの1 リード処理

リード処理

)一一メ

^{ンテイングして込出}

破棄

phuF 立U1V A小，J ，，，

都PEAA

代行プロセス消去処理

図5. 3. 3-4 グループリモートファイルアクセスのシーケンス例

5 _ -4 .t生台包言平イ面と三ぎ霧�

- 84- P「un6

(12)

|ロ) I

U N 1 XシステムEを基にして、リモートファイルアクセス機能を持つ分散処理o sを作成した。そのo sをMC68000 (8MHz)をCPUとする計算機上で走行させ、評価した結果について述べる。伝送路は、伝送速度10Mb P

sのイーサネット形LANを利用した。

5. 4. 1 アクセス速度

ローカルファイルアクセスとリモートファイルアクセスのアクセス速度を比較する。アクセス速度比を次のように定義する。

(リモートファイルアクセスに要する時間) アクセス速度比=

AP部!カーネル部 (ローカルファイルアクセスに要する時間)

ファイルアクセスに関するシステムコールを、その処理内容から次の4種類に

各プロセスの役割 ( 1 )全体の処理制御

( 2 )対応する計算機からのデータ受信

( 3 )対応する計算機へのデータ送信

( 4 )代行実行と実行結果の送信

( 5 )アクセス依頼の送信とアクセス結果の受取り

分ける。

(A)ファイルへのアクセス開始を示すものo 例えばファイルのオープン処理。

( B )ファイルへデータの入出力を行なうものo 例えばファイルの出力処理。

( C )ファイルへのアクセス終了を示すもの。例えばファイルのクローズ処理。

図5. 3. 4-1 処理構成

(D)ファイルの状態を制御するものo 例えばファイルのアクセス権変更処理。

測定は、測定用プログラムのみが走行する状態で行ない、 UNIXのitimeJ コマンドを利用したO 各処理項目のアクセス速度比を表5. 4. 1-1に示す。

表5. 4. 1-1から、いくつかのことがわかる。第ーに、項目(D )から、リモートファイルアクセスの処理は、代行プロセスの生成や消去の処理にかなりの時間を費やしている。アクセス権変更処理の場合は、代行プロセスの生成や消去の処理が、処理全体の約3/4を占めている。第二に、項目(B )から、リモートファイルへの出力は、出力データ長が短いほどオーパ‘ヘッドが小さし、。これは、

ローカル処理に比べ、パケ yト送受信処理による出力データのメモリ間転送回数が多いことによる。第三に、ディスク1/0を伴わない処理(例えば、アクセスするファイルのデータが既にメモリ上にある場合やファイルのクローズ処理の場合)は、ローカル処理時間が短いため、オーバヘッドが全体lこ占める割合は大きし、。

- 86- ^。。

(13)

( A ) ( B )

( c ) ( D )

表5. 4. 1-1 アクセス速度比

rø �

iI三一

^伴う場合^{ディスク1/0を} ^{ディスク1/0を}^{伴なわない場合}

ファイルのオープン処理 5 2 0

アクセスデータ長が 3 1 0 ファイルへの出 128バイト

力処理アクセスデータ長が 1 0 3 5 1 024バイト

ファイルのクローズ処理 200

代行プロセスの生成 2 0 2 0 ファイルのアクや消去が必要

セス権変更処理

代行プロセスの生成 5 6

や消去が不必要

(ローカルアクセスを1とした時のリモートアクセスの相対比) 一:存在しない

- 88-

5. 4. 2 セグメンテイング機能の効果

リモートファイルに対する入力と出力に関して、セグメンティング機能の効果について述べる。 LAN のパケットサイズは最大1 . 5キロバイトである。セグメ

ンティングを必要としない1キロバイトのデータ入出力に要する時間と、セグメンテイングを必要とする nキロバイト(n=2.3.….₁₀)のデータの入出力に要する時間の比を図5. 4. 2 -1に示す。図5. 4. 2 -1から次のことがわかる。第一に、 4キロバイト以下の1/0データサイズではセグメンテイング機能の効果がある。しかし、 4キロバイト以上については、セグメンテイング処理の増加とパケット送出処理の削減が相殺され、それ以上の効果はない。第二に、

出力処理より入力処理の方が効果が大きい。これは、セグメンティングの分割処理時に行なうメモリ聞のデータ転送処理が出力処理と入力処理で異なることによる。具体的には、出力処理では、異なった論理メモリ空間(A P空間とo s空間) の間でメモリ閣のデータ転送を行なう。これに対し、入力処理では、同ーの論理メモリ空間 (0 S空間〉の中で行なわれる。そのため、前者は後者に比ベメモリ間のデータ転送に時間を要する。

5. 4. 3 グループリモートファイルアクセス機能の有効性

複数のファイルに対して、グループリモートファイルアクセスを利用した場合と単一リモートファイルアクセスを繰り返し利用した場合の処理時間比を、次のように定義する。

(グループリモートアクセスの所要時間) 処理時間比=

(単一リモートアクセスの所要時間×送出先の計算機数 ) リモートファイルへの出力処理について、結果を図5. 4. 3 _{- 1に示す。}

図5. 4. 3 - 1に示すパケット送出制御時間とは、 LANの通信制御手順を制御しているプログラム部分(以降、 LAN制御と呼ぶ〉がパケット送出の割合を制御するパラメータである。具体的には、パケット送信要求とパケットの伝送路送出の聞に行なう遅延処理の時間である。 LAN制御は、パケットの受信処理能力が送信処理能力より劣っている。一方、グループファイルアクセスでは実行

- 89-

(14)

接近時・炉提り一O\同組卦凶凶同

記一一一一芝居岩

ー一一一4.096パイト単位の出力処理ー (パケット送出制御時間80ミリ秒) ---1.024バイト単位の出力処理

(パケット送出荷IJ御時間]80ミリ秒) ----1.024パイト単位の出力処理

• (パケット送出市1]1卸1時IllJ20ミリ秒)

。

0

1 2

数4機算計 ⁶ ⁷

Q

l 5

1回の1/0データサイズ

10 KB 図5. 4. 3-1 グループアクセス機能の有効性

図5. 4. 2-1 セグメンティング機能の効果

- 90- nコ

(15)

終了を待たないで次の処理要求を送出できるため、グループファイルアクセスが多発するとコマンドパケットが多く送信される。その結果、 LAN制御で受信パケットあふれが発生し、パケットの欠落を招いてしまう。これを防ぐため、この遅延処理が必要であり、 LANシステム全体のパケット負荷の平衡を図っている。

したがって、コマンドとレスポンスが対になっている単一リモートファイルアクセスでは不要な処理である。

図5. 4. 3 - 1から、次のことがわかる。第一に、グループファイルアクセスは、そのグループに属する計算機数に関係なく単一リモートファイルアクセスより速い。これは、図5. 3. 4-3と図5. 3. 3-4に示された両者の処理流れからわかるように、レスポンスパケットの有無によるものである。第二に、

グループリモートファイルアクセス機能は、例えばアクセスデータ長が短い場合のように、リモートファイルアクセスに要する時間が短いほど有効である。これは、パケット送出制御時間が短くてよいからである。つまり、 LAN制御の性能が、グループリモートファイルアクセス機能の有効性に大きな影響を与える。伝送路の信頼性が高いLANなどの場合、グループリモートアクセスの信頼性はL AN制御の性能に大きく影響される。例えば、 1024バイトのデータをリモートファイルへ出力する処理では、パケット送出制御時間が20ミリ秒の場合はパケット欠落が発生しないが、 10ミリ秒の場合は約1割のパケット欠落が発生し t:o したがって、レスポンスのないグループリモートファイルアクセス機能の利用においては、次の点を考慮する必要がある。

(1) LAN制御の性能が高いこと。

( 2 )パケット欠落を他の手段で発見できること。

例えば、ファイルへのアクセスでは、単一リモートファイルアクセスと組み合せて再確認する。また、ディスプレイ表示では、目視確認できるサービスに適用する。具体例として、電子会議サービスに利用した場合を考える。グループリモートファイルアクセス機能を利用して電子会議サービスを実現すると、単一リモートファイルアクセス機能を利用した場合に比べ数倍の応速速度が参加人数に関係なく保証できる。ただし、信頼性が低いため、会議参加者が異常を確認できるディスプレイ表示などに適用する。この時、電子会議サービスの機能として、再表示機能が必要である。

- 92-

5 5 まと反う

分散処理o sの構築方式として、分散したファイルを統一管理し、リモートファイルへのアクセス依頼をシステムコール転送の形で行なうリモートアクセス方式について説明した。本方式は、 LANの放送機能を用いたグループファイルへのリモートアクセス機能が特徴である。グループファイルへのリモートアクセスの機能は、信頼性を犠牲にして高い性能を実現している。この機能を利用する際には、他の手段で結果を確認できることが求められる。

UNIXシステム皿を基に実現した分散処理o sの場合、単一リモートファイルアクセスはローカルファイルアクセスに比べ数倍のアクセス時間が必要である。

これに対し、グループリモートファイルアクセスの性能は、下位の通信モジュールの性能に左右されるが、単一リモートファイルアクセスに比べ約5倍の能力を持つ。評価は、伝送路として伝送速度10M _bpsのイーサネット形LANを利用し Tこ。

ローカルファイルアクセスの利用環境と同じ形態でリモートファイルアクセスの利用環境を提供するため必要な技術を、以下にまとめる。

( 1 )ファイル名の先頭に、ネットワーク化したことを示すグローパル識別子と、そのファイルが存在する計算機に対応する単一計算機識別子を付加する。これにより、ローカルのファイル構成をそのままネットワーク化し、分散しているファイルを統一管理した。

(2) LANの放送機能を利用して、複数の計算機に対応するグループ計算機識別子の導入と、アクセスとは独立して入力処理を行なう計算機を指定する機能の実現を図った。これにより、アクセス速度が速いグループリモートファイルアクセス機能を自然な形で実現した。

( 3 )リモートへのアクセス要求の転送単位をシステムコールとし、機能拡張性のあるリモートアクセスの通信制御手順を確立した。

本方式を用いた分散処理o sは、実現と評価を終え、商用化されている。 UN 1 XシステムEを基に実現した分散処理o sを搭載した計算機は、ワークステー

- 93-

(16)

ションとして1 985年に開催された筑波の科学万博の「でんでん 1 N S館Jに展示された。この計算機では、 6章で述べる電子会議サービスだけではなく文書処理や電子ファイルや電子メールや電話などのサーピスを提供した。現在、 UN 1 XシステムVを基にした分散処理o Sが、 MC68020やMC68030をプロセッサに持つ計算機に搭載され、製品化されている。

- 94-

算言フ宍聾主宰霊弓三至宝言語表システム

本章では、 5章で述べた分散処理o Sを利用したサービスとして、電子会議システム[Mu r85][Su z86]について説明する。ピットマップディスプレイやマウスを有するワークステーションをLANで結合した環境において、ウインドウを共有し電話も利用して会議できるシステムである。このシステムは、

文字や図形や画像だけではなく音声も扱えるマルチメディアシステムであり、大きな二つの特徴を持つ。一つは、グループファイルアクセス機能などを利用して、

エディタや文書処理などのスタンドアロン環境で提供しているサービスプログラムをそのまま分散環境で動かし、電子会議のサービスとして実現していることである。もう一つは、マルチウインドウ機能[Sch88][横山86 ]などを利用して、一つのワークステーション上で電子会議サービスと同時にローカルなサービスの提供も可能にしていることである。さらに、ローカルなサービスで銭っているデータを即座に電子会議のサービスの中で利用できるようにしている。

6 . 1 4主主喜義寸テーービスcc>桧議台包

オフィスにおいて、人々は多くの時間を打ち合せや会議のようなグループコミュニケーションに費やしている。そのため、これらを計算機で可能にすること[

Sa r85]は非常に大切である。このような背景から、オフィスオートメーション(Office Autornation)における大切なサービスの1つに、電子会議サービス[坂本82] [鈴木83 ]がある。このサービスは、各ワークステーション〈

以降， w Sと略す)のウインドウと電話を使って会議を進めるものである。そのため、 WSのウインドウに同じ内容を表示し、常にこの内容を更新してその一致を保つ必要がある。さらに、電話の音声を共有することも必要である。

会議の中で利用する文書修正などの色々なサービス機能は、各WSから共有されなくてはならない(以降、共有サービスと呼ぶ〉。つまり、共有サービスをう

- 95-

(17)

まく制御する必要がある。共有サーピスにおける入力は1つのWSからであり、

アクセス権を持つ必要がある。それは、その瞬間の話す権限に対応する。一方、

共有サービスの出力は、それぞれのWSに行なう必要がある。したがって、アクセス権を各WSからの要求に応じて決められた優先権の下で制御する必要がある。

音声については、アクセス権とは関係なく自由に話しでもさしっかえない。

会議中にも別のウインドウを利用して、個人の処理をローカルにできる必要がある。また、そのローカルな処理で作成したものを共有サービスが利用しているウインドウ(以降、共有ウインドウと呼ぶ)に表示して、会議で利用できることが望ましい。

図6. 1 - 1にシステムの概要を示す。各WSは、 LANと構内交換機(P B X: Private BrancheXchange)により結合されている。音声の通信はP B X を利用し、ウインドウへの表示情報などの通信はLANを利用する。 WS上には、

共有サーピスが利用している共有ウインドウや、ローカルなサービスが利用しているローカルウインドウが表示されている。図6. 1 - 1では、司会者がアクセス権を保有している場合を示している。そのため、司会者のWSlでは、共有ウインドウ上にカーソルがある。これに対し、参加者のWS2やWS 3では、共有ウインドウとローカルウインドウの各々の上にカーソルがある。詳細については、

6. 4節で述べる。

W S 1 (司会者)

W S 2 (参加者)

-F\

W S 3 (参加者)

口夜、、ヘ

6

_

² 芸基ヱド桧捷肯忌

ここでは、電子会議サービスに必要な基本機能について述べる。共有サービスといっても特別なサービスではなく、エディタや文書処理などの普通のサーピスをそのまま共有サービスとして動作させる。このようにすることにより、電子会議サービスのために必要となるプログラムの量を削減できる。さらに、スタンドアロン環境用の新しいサービスをすぐに電子会議サービスとして利用できる。

このように、スタンドアロン環境を想定して動いているプログラムをそのまま分散環境で動かし、電子会議の共有サービスとして利用できるためには、以下の機能が必要である。第一に、グループ通信機能である。電子会議サーピスでは、

ウン

ウイ

ドウンルイカウ一有口共口口

仁コ

-V ソ

一ル

カソル一カカ一有口共

KK

図6. 1 - 1 電子会組システムの概要

- 97-

(18)

出力を共有し、そのアクセスは各wsで遅れなく行なわれる必要がある。そのため、ファイルや入出力装置などへのアクセスは、 LANの放送機能を利用したグループファイルアクセス機能が必要である。

第二に、アクセス権制御機能である。共有サービスの入力情報は、各wsから行なわれる。そのため、何らかの制御により、ある瞬間は一つのwsからの入力のみを有効にすることが必要である。また、入力したいwsは、アクセス権が得られるまで待たせることも必要である。

第三に、 PB Xによる会話機能である。このサービスでは色々なメディアを扱い、特に音声を扱うことが必須である。しかし、 LANを介して音声をリアルタイムに送受信することは難しい。そこで、音声の通信はPBXを利用する。つまり、このサービスはLANとPB Xで結合されたwsが多数存在する環境で提供する。

さらに、電子会議サーピスと同時に別のサービスを提供するには、次の特徴を持つマルチウインドウ機能が必要である。一つは、複数のサービスを同時に動かすために、各々のウインドウを独立した端末のように扱えることである。もう一つは、各サービス聞の協調処理を可能にするため、ウインドウ閣で自由にデータを転送できることである。しかも、この転送をサービスプログラムが意識するのではなく、別のプログラムにより制御できることが必要である。

6 ^_ 3 タミテ首交�王里o s ι〉核詫有tz

分散処理o sの機能については、 5章で述べた。ここでは、電子会議サーピスの実現および複数サーピスの共存と協調処理のために特に関係が深い機能について述べる。

6. 3. 1 電子会議サービスが求める機能

電子会議サーピスは、その実現を容易にするためには、次の四つの分散処理O Sの機能が大切である。

第一に、グローバルトリーである。グローバルトリーは、分散しているwsが

98 -

持つ全ての資源を一つの管理体系で見せている。他wsへのアクセスは、ネットワークディレクトリと呼ぶ特別なディレクトリを介する。ネットワークディレクトリは、各wsのルートディレクトリに対応し、 mk n odと呼ばれるシステムコールにより作成される。つまり、他wsの資源にアクセスするにはそのwsに対応するネyトワークディレク卜りを作成する必要がある。この機能により、サービスプログラムを一つのws上で動作させて会議サービスを実現できる。

第二は、システムコール転送とグループネットワークディレクトリによるグループリモートファイルアクセス機能である。グループネットワークディレクトリは、 LANの放送機能を利用する。各グループネットワークディレクトリはLA Nの物理グループアドレスで規定され、それぞれのwsグループに対応する。グループネットワークディレクトりを利用したアクセスは、システムコールが放送され、当該グループに属する全wsで同時に実行される。この機能は、ウインドウを含むいろいろな資源への「一度の」アクセスを可能にしているため、電子会議を行なうwsグループの資源アクセスに非常に有効である。また、そのアクセスインタフェースはローカルファイルアクセスと同じであるため、サーピスプログラムはその違いを意識する必要がない。

第三は、アクセス権制御である。グループネットワークディレクトリを利用したアクセスでの問題は、 r ^{e a}dのような入力型のシステムコールをどのように扱うかである。もし、 r ^{e a}dシステムコールをグループの全wsで実行すると、

そのすべてのwsからデータが転送されてくる。これをそのまま利用しようとすると、 r ^{e a}dの結果格納形式が従来とは異なり、グループのメンパ数を知らないとシステムコールの終了がわからない、という問題がある。このような問題をさけるため、事前に指定した1つのwsのみがシステムコールを実行し結果を返却する仕様とした。事前の入力ws指定を動的にプログラムで行なえるために、

s e t n ⁰dシステムコールを実現した。アクセス権を電子会議サービスの “話

す権利" に対応づけることにより、会議を制御できる。

第四は、 c h r ^{0 0}tシステムコールによるルートディレクトリの変更機能である。 c hr o otシステムコールによりルートディレクトリを変更後プログラムを走行させると、そのプログラムはそのファイルシステム環境で動作する。この機能は、元来UNIX自体が持っている機能である。ここでは、新たに、その

- 99-

(19)

変更先としてネットワークディレクトリを可能にした点が重要である。さらに、

ネットワークディレクトリ配下のリモートのディレクトリにワーキングディレクトリを変更できることも重要である。その結果、 c _h r 0 0 tシステムコールによりグループネットワークディレクトリをルートディレクトリに変更後サービスプログラムを走行させると、そのサービスプログラムのファイル入出力はグループアクセスになる。この機能により、電子会議サービスで提供する共有サービスとして、エディタや文書処理などのスタンドアロン環境で利用しているサーピスをそのまま分散環境に利用できる。

階では、アクセス権の制御とカーソルの制御を行ない、会議を進行させる。終了段階では、会議を終了させ、環境を会議前の状態に戻す。各段階について以降に

説明する。

6. 4. 1 企画段階

企画段階においては、会議名や参加者を選定し、日程の調整を行ない、招待状や会議資料を送る。これらの処理は、 wsの他のサービス機能を使って行なう。

6 . 4 電子会議サービス内容

6. 4. 2 準備段階

参加者が集まり、司会者を選定した後、電子会議サービスの環境を設定する。

環境設定プログラムは、司会者のwsで実行される。

表示されるウインドウを図6. 4. 2 -1から図6. 4. 2-4に示す。これらの図に基づき、操作の流れを以下に説明する。図6. 4. 2-1のウインドウに会議名を入力することによりサービスが始まる。次に、図6. 4. 2 - 2のウインドウによりこの会議に参加する者を登録する。この登録に基づいて、各参加者のwsに図6. 4. 2-3のウインドウが表示される。各参加者が「参加」を指示することにより、司会者のws上のプログラムは参加者を確認する。これを図6. 4. 2-4のウインドウで表示することにより、司会者は参加者を知ることができる。参加者が確認できると、司会者が「開始」を指示することにより会議が始まる。

途中での参加を認めることは、 wsを制御する点では可能である。しかし、 P

B Xの会話機能が途中参加を可能にしていないため、このサービスでは途中参加を実現していない。

プログラムの処理内容を以下に説明する。

くグループパス設定> LANの物理グループアドレスを選び、そのグルー

プに参加者の各wsが属するようにする。具体的には、ネットワークディレクトリを作成するm k n 0 dシステムコールを使い、参加者の各wsに単一リモートファイルアクセスを行なってグループネットワークディレクトリを作成する。

くサーピス走行環境設定> c _h r 0 0 tシステムコールにより、作成したグループネットワークディレクトリがルートディレクトりになるようにする。こ 6. 3. 2 複数サーピスの共存と協調処理が求める機能

一つのピットマッフディスプレイやキーボードやマウスを用いて、同時に複数のサービスを提供するためには、マルチウインドウに次の機能[横山8 4 ]が必要である。

一つは、キーボードやマウスとウインドウを一つの端末として独立して見せる仮想端末の機能である。この機能は、複数存在するウインドウとキーボードやマウスの対応づけが鍵であり、マウスクリック時にカーソルが載っているウインドウと結びつけることで実現している。この機能により、複数の無関係なサービスの同時走行が可能になる。

もう一つは、ウインドウ間のデータ転送機能である。この機能は、別のウインドウからのデータ転送と仮想端末が持つ入力装置からの入力を全く同械に扱うことで実現している。これにより、複数サービス聞のデータ送受信による協調処理を可能にでき、ローカルサービスで扱っていたデータを即座に共有サービスで扱

える。

電子会議サービスは、四つの段階から成る。企画段階では、会議開始前に他の OAサーピスを使って会議の開催準備を行なう。準備段階では、共有サービスで利用する共有ウインドウを作成するなどの会議環境の設定を行なう。討論制御段

nu -101-

(20)

|電子会畿(会議名入力) I 巨三日

図6. 4. 2-1

会滋名入力ウインドウ

|電子会組(参加予定者名入力)11アドレス傾11実行11取消11中止|

参加予定者名目囚

図6. 4. 2-2 参加予定者名入力ウインドウ

|電子会韻(参加要楕[] _{|参加|}

xxxx )殿

、t、4、司、t、'( y、'( y

)を始めます。

[参加Jを選択して下さい.

図6. 4. 2-3 参加要鏑ウインドウ

| ^電

^子

^会

^磁 ^{

^参

加^楓

) | 開始

.加予定者

LEj

^AAAAAA

仁コ

^BBBBBB

r、ーーM・ーー.「J cccccc

図6. 4. 2-4

.加確昆褒示ウインドウ

-102ー

の処理により、ファイルアクセスのパス名が “/" で始まるシステムコールはグ

ループ処理になる。この環境は、会議環境管理処理と呼ばれるプログラムにより保持される。会議環境管理処理は、アイコンで示されるすべてのサービスやデータを管理するものである。そのため、この共有された会議環境上で起動されたサービスは参加者の全wsを対象に入出力を行なう。したがって、例えば、この環境でのウインドウへのアクセスは、全てグループアクセスになる。つまり、このウインドウは共有ウインドウであり、言い換えれば共有ウインドウはグループファイルになっているといえる。

くアクセス権初期化〉会議の開始時は、司会者がアクセス権を持つ。そのため、グループの入力計算機を設定するs e t n 0 dシステムコールにより、入力計算機を司会者のwsに設定する。

く共有力一ソル初期化> 共有ウインドウ上にあるカーソルを共有力一ソル

と呼び、ローカルなサービスが利用しているカーソルと区別する。共有力一ソルは、参加者すべてのwsの共有ウインドウに表示され、同じ位置になるように制御するo カーソル移動動作は、アクセス権を持つ場合は共有力一ソル、そうでない場合はローカルカーソルに対応づける。したがって、会議開始時は、共有力一ソルを司会者のカーソル移動動作に対応づける。このような共有力一ソルの表示処理は、グループファイルになっている共有ウインドウへのアクセス機能を用いて実現する。具体的には、グループファイルになっている共有ウインドウからのカーソル位置入力により、アクセス権を持つwsのカーソル位置を読み取り、それをグループファイルアクセスを行なって共有ウインドウに出力する。これにより、他の各wsの共有ウインドウの同じ位置に共有カーソルを表示する。

く会議電話設定〉参加者との電話の接続を行なう。会議で利用する電話の環境は、 P B Xの会話機能を利用する。この環境の設定は、相手電話番号に特定の番号をつけることで行なわれる。これはP B Xの機能である。

上記の環境設定により、共有サービス制御プロセスや共有カーソル表示プロセスやアクセス権制御プロセス等が動作を開始し、会議が始まる。

6. 4. 3 討論制御段階

討論時には、討論に必要なサービスウインドウの他に二つの会議用ウインドウ

-103ー

(21)

が表示される。各ウインドウを図6. 4. 3 - 1と図6. 4. 3-2に示す。図 6. 4. 3-1のウインドウは、全員のwsに表示される。これは、参加者名の部分によりアクセス権の保持状況を示すと共に、アクセス権を制御するためのものである。図6. 4. 3 - 2のウインドウは、司会者のwsに表示される。会議の終了をプログラムに指示するものである。

アクセス権の変更は、要求時に優先度に応じて行なう。特定の参加者のみにアクセス権が専有され会議が混乱することを防ぐため、司会者はアクセス権の強制取得という優先権を持つ。一方、司会者は、参加者にアクセス権を委ねる権限も持つ。アクセス権を要求したwsがグループの入力計算機になるように、 s e t

n 0 dシステムコールで設定する。アクセス権の保有状況は、図6. 4. 3 -1

に示すウインドウにより、参加者名の欄の色表示で把握できる。

共有カーソルの制御は、 6. 4. 2項で述べた共有カーソルの表示処理を定期

|電子会議(入力構)I 要求I I放棄

参加者名

(司会者)

図6. 4. 3-1

入力指制御ウインドウ

的に行なうことにより、アクセス権を持ったwsのローカルカーソルに合わせて

|電子会議|

会議中、参加者はローカルなサーピスを利用することもできる。ローカルサービスが作成したウインドウは、放送されず他のwsからは見えない。しかし、ローカルウインドウの内容を共有ウインドウに転送することにより、その内容が放送され他のwsの共有ウインドウに表示される。これは、ローカルなマルチウインドウシステムにおけるウインドウ閣のデータ転送機能を利用して行なえる。

xxxxxxxxxx

E-

制御する。

図6. 4. 3-2

電子会議終了ウインドウ

6. 4. 4 終了段階

会議の終了は、図6. 4. 3-2のウインドウに司会者が「終了」を指示することにより行なわれるo さらに、図6. 4. 4 -1のウインドウにより終了を確認し、会議は終了する。すべてのプロセスは終了し、各wsのグループネットワークディレクトリを消去することによりグループパスを解放する。必要に応じて、

会議の議事録を回覧する。

|電子会議(終了確認)I |取消|

……附してもいーっl

図6. 4. 4 - 1

会議終了確認ウインドウ

6

_

⁵ 住主台E2言平イ面と乏言要実

-104- -105-

分散処理オペレーティングシステムの構築法に関す る研究

九州大学学術情報リポジトリ

Kyushu University Institutional Repository