JP2967521B2 - データ処理システムのクライエント装置のアクセス制御システム - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明は、ネットワークを介して接続された処理シス
テムに関し、具体的には、ネットワーク内の局所処理シ
ステムと遠隔処理システムの間のファイルのアクセスに
関する。

B.従来の技術 第１図に示すように、分散ネットワーキング環境１
は、通信リンク１またはネットワーク３を介して接続さ
れた２つ以上のノードＡ、Ｂ、Ｃから成る。ネットワー
ク３は、ローカル・エリア・ネットワーク（LAN）でも
広域ネットワーク（WAN）でもよい。

ノードＡ、Ｂ、Ｃのどのノードにも、ワークステーシ
ョンなどの処理システム10A、10B、10Cがある。これら
の処理システム10A、10B、10Cはそれぞれ、遠隔ノード
にあるファイルにアクセスするために、ネットワーク３
を使用する能力を有する、単一ユーザ・システム、また
は複数ユーザ・システムである。たとえば、局所ノード
Ａにある処理システム10Aは、それぞれ遠隔ノードＢと
Ｃにあるファイル5Bと5Cにアクセスすることができる。

本明細書では、「サーバ」という用語は、ファイルが
永久に記憶される処理システムを示すために使用し、
「クライエント」という用語は、ファイルにアクセスす
る処理を有する他の処理システムを意味するのに使用す
る。ただし、「サーバ」という用語は、あるローカル・
エリア・ネットワーク・システムで使用されるような専
用サーバを意味しないことを理解されたい。本発明が実
施される分散サービス・システムは、真に、システム内
の異なるノードで走行し、システム内のどこかにあるフ
ァイルにアクセスする広範囲のアプリケーションを支援
する分散型システムである。

上記のように、以下に記述する本発明は、通信ネット
ワーク内の分散データ処理システムを対象とする。この
環境では、ネットワーク内のあるノードにある各処理装
置は、ファイルがどのノードにあろうと、ネットワーク
内のすべてのファイルにアクセスすることができる。

分散データ処理システムを支援するための他の手法も
知られている。たとえば、AIXオペレーティング・シス
テム用のIBM分散サービスが、特開昭63−20024号公報に
開示されている。さらに、サン・マイクロシステムズ
（Sun Microsystems）社はネットワーク・ファイル・シ
ステム（NFS）を発表し、ベル研究所は遠隔ファイル・
システム（RFS）を開発した。サン・マイクロシステム
ズのNFSは、S.R.クライマン（Kleiman）の報文「Ｖノー
ド：サンUNIXの多重ファイル・システム・タイプ用アー
キテクチャ（Vnodes:An Architecture for Multiple Fi
le System Type in Sun UNIX）」、USENIX1986年夏期国
際技術会議／展示会紀要（Conference Proceedings,USE
NIX 1986 Summer Technical Conference and Exhibitio
n）、pp.238〜247;ラッセル・サンドバーグ（Russel Sa
ndberg）他の報文「サン・ネットワーク・ファイル・シ
ステムの設計と実施態様（Design and Implementation
of the Sun Network Filesystem）」、USENIX1985年国
際会議紀要、pp.119〜130;ダン・ウォールシュ（Dan Wa
lsh）他著「サン・ネットワーク・フィルム・システム
の概要（Overview of the Sun Network File Syste
m）」、pp.117〜124;ジョメイ・チャン（JoMei Chang）
の論文「状況モニタはNFSに対するネットワーク・ロッ
キング・サービスを提供する（Status Monitor Provide
s Network Locking Service for NFS）」、ジョメイ・
チャン著「サンネット（SunNet）」、pp.71〜75;ブラッ
ドリー・テイラー（Bradley Taylor）著「サン環境での
安全なネットワーキング（Secure Networking in the S
un Environment）」、pp.28〜36を含む一連の刊行物に
記載されている。AT ＆ T RFSも、アンドリューP.リフ
キン（Andrew P.Rifkin）他の報文「RFSアーキテクチャ
概要（RFS Architectural Overview）」、USENIX国際会
議紀要、米国ジョージア州アトランタ（1986年６月）、
pp.1〜12;リチャード・ハミルトン（Richard Hamilto
n）他著「管理者から見た遠隔ファイル共用（An Admini
strator's View of Remote File Sharing）」、pp.1〜
9;トム・フートン（Tom Houghton）他著「ファイル・シ
ステム・スイッチ（File System Switch）」、pp.1〜2;
デーヴィッドJ.オランダー（David J.Olander）他著
「システムＶにおけるネットワーキング用フレームワー
ク（A Framework for Networking in System V）」、p
p.1〜８を含む一連の刊行物に記述されている。

本発明が実施される分散サービス・システムを、たと
えばサン・マイクロシステムズのNFSから区別する１つ
の特徴は、サンの手法が、本質的にいわゆる無状態サー
バを設計することであったということである。すなわ
ち、サーバは、どのクライエント・ノードがサーバ・フ
ァイルを開いたか、あるいはクライエント処理が読取り
専用モードと読み書きモードのどちらでファイルを開い
たかなどのクライエント・ノードに関する情報を記憶し
ない。そのような方式は、クライエントが、サーバ資源
に対するその要求を解除したことをサーバに正しく通知
せずに障害を起こしたりオフ・ラインになったりする時
に生じる、エラー回復状況をサーバが取り扱わなくてす
むので、サーバの設計が簡単になる。

本発明が実施される分散サービス・システムの設計で
は、まったく異なる手法が取られた。具体的に言うと、
分散サービス・システムは、「有状態」サーバとして特
徴づけることができる。本明細書で述べるような「有状
態」サーバは、誰がそのファイルを使い、そのファイル
がどのように使用されるのかに関する情報を保持する。
それには、サーバが、そのクライエントに関する蓄積さ
れた状態情報を捨てることができるように、クライエン
トとの接触の喪失を検出する何らかの手段を有すること
が必要である。本明細書で述べるキャッシュ管理戦略
は、サーバがそのような状態情報を保持しない限り、実
施できない。

遠隔ノードにあるデータにアクセスする際にぶつかる
問題は、独立型システムがファイルにどのようにアクセ
スするかをまず検討すると、よりよく理解できる。第２
図に示した10などの独立型システムにおいては、オペレ
ーティング・システム11内の局所バッファ12が、ワーク
ステーション内のハード・ファイルやディスクなどの永
久記憶装置２とユーザ・アドレス空間14との間で転送さ
れるデータをバッファするために使われる。オペレーテ
ィング・システム11内の局所バッファ12はまた、局所バ
ッファ・キャッシュあるいはカーネル・バッファとも呼
ばれる。

この独立型システム10において、カーネル・バッファ
12は、ブロック15に分けられている。それらのブロック
は、装置番号と装置内の論理ブロック番号で識別され
る。読取りシステム・コール16が出される時、それは、
第３図のステップ101に示すように、ファイル５内のあ
るバイト範囲を表すファイル５のファイル記述子と共に
出される。オペレーティング・システム11は、第３図の
ステップ102でこの情報を読み取り、それを装置番号と
装置内の論理ブロック番号に変換する。ステップ103
で、そのブロックがキャッシュ内にある場合、データ
は、ステップ105でキャッシュから直接得られる。ステ
ップ103で、キャッシュが探しているブロックをまだ含
んでいない場合は、ステップ104で、データがキャッシ
ュ中に読み込まれてから、ステップ105に進んでデータ
がキャッシュから得られる。

ディスク２から読み取ったどんなデータも、キャッシ
ュ・ブロック15が他の何らかの目的で必要になるまで、
キャッシュ・ブロック15内に保持される。その結果、そ
の後に処理システム10上で走行するアプリケーション４
からすでに読み取られたものと同じデータに対して読取
り要求が出されたとき、ディスク２からではなくキャッ
シュ12からアクセスされる。キャッシュからの読取り
は、ディスクからの読取りより時間がずっとかからな
い。

同様に、アプリケーション４から書き込まれたデータ
は、直ちにディスク２上にセーブされず、キャッシュ12
に書き込まれる。このため、同じブロックに対して別の
書込み動作が出された場合、ディスクへのアクセスが節
約される。キャッシュ12内の修正されたデータ・ブロッ
クは、定期的にディスク２にセーブされる。

AIXオペレーティング・システムを利用した独立型シ
ステム内でキャッシュを使用すると、その後の読取り及
び書込みでディスクへのアクセスが不要となるので、シ
ステムの全体的性能が向上する。全体的性能が高まるの
は、永久記憶装置へのアクセスが、キャッシュへのアク
セスより遅く、コストがより高いためである。

上記のように、オペレーティング・システム内の局所
バッファを使って、ファイルに対する独立型アクセスの
性能を向上させることができる。ファイルは通常ディス
ク装置などのより低速の永久記憶装置内に保持される
が、これらの局所バッファは高速メモリに保持される。
バッファ・キャッシュが大きいほど、データ処理システ
ムの性能を高めることができる。なぜなら、キャッシュ
はシステムのファイルに属するデータをより多く保持す
ることができ、したがって、より低速のディスク装置を
使用する必要性が減るからである。システムの高速物理
メモリは、サイズが限られている。物理メモリを区分し
てオペレーティング・システムのカーネル・バッファ用
に一定の部分をとっておくのではなく、仮想メモリ技術
を使って、システムのディスク・ファイルへのアクセス
速度を上げることができる。このような仮想メモリ技術
では、ディスク・ブロックの固定キャッシュはなく、そ
の代り、データは、非物理的仮想メモリ内にキャッシュ
される。

仮想メモリは、利用可能な物理メモリより大きなメモ
リ空間を提供する。この仮想メモリ空間は、ページに分
割され、仮想メモリ空間が物理メモリであるかのよう
に、プログラムによって使用される。システムの仮想メ
モリ・ページは、実際の物理メモリ・フレーム、ディス
ク・ブロック、あるいはその両方の中に存在する。仮想
メモリ・ページが物理フレーム中にない時は、そのペー
ジを使用しようと試みても、ページ不在と呼ばれる例外
を生ずる。そのようなページの使用を試みるプログラム
はページ不在を生成し、仮想メモリ・ページが現在ある
ディスク・ブロックから探索されて物理メモリ・フレー
ム中にコピーされる間、一時的に中断される。仮想メモ
リ・ページに物理フレームが割り当てられた後、元の障
害を起こしたプログラムが続行できるようになり、仮想
メモリ・ページ内のデータが利用可能なことを見出す。

AIXオペレーティング・システムにおいて、プログラ
ムは、読取りや書込みなどのシステム・コールを介し
て、あるいはマップ式アクセスによって直接に、ファイ
ルの内容にアクセスすることができる。マップ式アクセ
スでは、ファイルがプログラムの仮想アドレス空間の一
部分にマップされ、プログラムのアドレス空間のその部
分に対するロードまたは記憶がそれぞれファイルに対す
るアクセスとして反映される。ファイルに対するマップ
式アクセスは、アクセスまたは修正すべきバイトを単に
直接アドレスするだけで、ファイルまたはファイル内容
を直接取り扱うことができるという利点を有する。しか
し、複数のプログラムが同時にファイルを開きマップし
た場合、ファイルへのアクセスの調整は、プログラム自
体が行なわなければならない。すなわち、一方のプログ
ラムが、単に10バイトを順次記憶することによってファ
イルに一連の10バイトを書き込もうと試み、他方のプロ
グラムが、単にバイトから順次ロードすることによって
これらのバイトを読み取ろうと試みている。第１のプロ
グラムが終了する前に、第２のプログラムが実行するス
ケジュールを立てられ、第２のプログラムには、ファイ
ルからロードするデータ中の修正されたデータの半分し
か見えないことがあり得る。これらの問題は、ファイル
を共用するプログラム間の協力により、あるいは、マッ
プ式ファイルの使用を避け、読取り及び書込みシステム
・コールの使用だけに動作を限定することにより、解決
される。AIXの読取りシステム・コールと書込みシステ
ム・コールは、直列化可能な方式で動作するように設計
されている、すなわち、両方のシステム・コールが２つ
のプログラムによって同時に試みられた場合、一方が完
全に実行された後で初めて、他方が実行を許される。

分散環境では、ある機械上で走行する処理が、他の機
械上のファイルにアクセスすることがある。このような
環境の下では、すべての処理が単一の機械上で走行する
独立型環境の場合と全く同様に、ファイルに対する読取
り動作及び書込み動作が直列化可能な方式で実行される
ことを保証することが重要である。この困難が生じるの
は、性能上の必要から、ファイルがクライエント機械で
キャッシュまたはバッファできる必要があるためであ
る。

第１図に示したような分散環境では、局所ノードＣに
ある処理システム10Cが、ノードＡからファイル5Aを読
み取る方法が２つある。第１の方法では、処理システム
10Cがファイル5A全体をコピーし、その後、そのファイ
ルがノードＣにある局所ファイル5Cであるかのようにそ
れを読み取ることができる。このようにしてファイルを
読み取ると、ファイル5AがノードＣでファイル5Cとして
コピーされた後で、別のノードＡにある別の処理システ
ム10Aがファイル5Aを修正した場合に、問題が生ずる。
処理システム10Cは、ファイル5Aに対するこれら最新の
修正にアクセスすることができない。

処理システム10CがノードＡにあるファイル5Aにアク
セスするための第二の方法は、ノードＣにある処理シス
テムがそれを要求する時に、あるブロック、たとえばN1
を読み取るものである。この方法に伴う問題は、どの読
取りもネットワーク通信リンク３を横切ってファイルが
あるノードＡに行かなければならないことである。連続
する読取りのためにデータを逐次送るのは時間がかか
る。

このように、ネットワークを横切ってファイルにアク
セスすると、上記の２つの競合する問題を生じる。１つ
の問題は、連続する読取り及び書込みのためにネットワ
ークを横切ってデータを転送するのに必要な時間に関す
るものである。一方、ネットワーク通信量を減らすため
にフィルム・データをノードに記憶する場合は、ファイ
ルの保全性が失われる恐れがある。たとえば、いくつか
のノードの１つがそのファイルに書込み中の場合、その
ファイルにアクセスしている他のノードは、書き込まれ
たばかりの最新のデータにアクセスしていないことこと
があり得る。したがって、ノードが、正しくない古くな
ったファイルにアクセスしているので、ファイル保全性
が失われる。

要約すると、分散データ処理システムでは、データ
は、複数のノードからアクセスすることができる。デー
タは、サーバと呼ばれるこのデータ処理システム内の１
つのノードによって制御される。このデータにアクセス
する他のノードは、クライエントと呼ばれる。クライエ
ントは、要求をサーバに送ることにより、データへのア
クセス権を得る。サーバは、データへのアクセスを要求
したクライエントにデータを戻す。次いでクライエント
が要求されたデータを読み取り、それに加えて、場合に
よってはそれを修正する。したがって、サーバが複数の
ユーザに同じデータを提供することができ、同時に、そ
のユーザが処理中のデータがすべてのユーザによって加
えられた最新の変更を反映して有効なままとなることを
各ユーザに保証することができれば、そのようなシステ
ムのユーザにとって非常に好都合である。

C.発明の要旨 したがって、多数のクライエントがデータに関心をも
っている時、サーバ・ノードは、データの一貫性を保つ
ため、データに対するアクセスを同期しなければならな
い。サーバは、そうするために、所与のある時間にある
ノードで修正のためにアクセスできるデータの各部分
が、他のノードからは読取りや修正のためにアクセスで
きず、かつ読取りのためにアクセスできるデータの部分
が、読取りのためにのみいくつのノードからでもアクセ
スできるようにする。

これらの要件を実施するために、衝突する要求が異な
るクライエントから出された場合、サーバは、以前にあ
るクライエントに配布されたデータを取り消さなければ
ならない。たとえば、データの一部分に対するあるクラ
イエントの読取りアクセス要求に応じて、サーバは、デ
ータのコピーをそのクライエントに配布することによ
り、そのアクセスを許可する。続いて、第２のクライエ
ントがデータの同じ部分への読取りアクセスを要求した
場合、サーバは、同様にそのデータを第２のクライエン
トに配布することができる。このようにして、第２のク
ライエントは、第１のクライエントが読取りアクセスを
許されたのと同様に、データに対する読取りアクセスを
許される。しかし、第３のクライエントがこのデータに
対する書込みアクセスを要求した場合は、サーバは、第
３のクライエントの要求を許可する前に、第１と第２の
クライエントに配布されたデータを取り消さなければな
らない。サーバは、それによって、第３のクライエント
がデータを修正する可能性を有する間、第１と第２のク
ライエントのデータを読み取る能力を一時的に中断す
る。サーバは、第３のクライエントからのデータのある
部分に対する書込みアクセスが取り消されるかまたは撤
回されるまで、（第３のクライエント以外の）クライエ
ントに対してデータのその部分に対する読取りアクセス
を許可できず、許し続けることもできない。

データのブロックは、“get_bytes"、“put_bytes"、
及び“revoke_bytes"要求に基づいて移動、または管理
される。第１のクライエントがget_bytes要求を出し、
その結果、サーバが第２のクライエントにrevoke_bytes
要求を送らなければならず、その間に第２のクライエン
トも同じ範囲のバイトに対するget_bytes要求を出した
時、デッドロック状況が発生することがある。サーバ
は、それらのバイトに対する第１のクライエントの要求
にサービスしている最中なので、第２のクライエントが
サーバからバイトを得ることはできない。しかし、サー
バは、第２のクライエント中のバイトが取り消されるま
で、第１のクライエントの要求を完了することができな
い。それらのバイトが取り消される前に、第２のクライ
エントがそれらのバイトを得るために待とうとする場
合、デッドロックが発生する。

デッドロック状況を起こさずにバイト取消し動作を正
しく行なうため、クライエントでのrevoke_bytes要求の
処理は、未処理のget_bytes要求が完了するのを待たな
い。その代り、すべての未処理get_bytes要求にはマー
クが付され、これらは取消しが要求されているバイトが
クライエントに到着した時に捨てられる。

ファイル上の読取り及び書込みシステム・コールが、
分散環境の全体にわたって直列化可能な方式で実行され
ることを保証するために、読取りが実行される各機械は
読取りトークンを獲得しなければならず、書込みが実行
される各機械は、そのファイル４のサーバからのみ読取
り／書込みトークンを獲得しなければならない。いずれ
かの機械が読取り／書込みトークンを有する場合、他の
どの機械も読取りトークンを有することはできない。同
時に何台の機械が読取りトークンを持つこともできる。
サーバは、書込みトークンが要求された時、すべての読
取りトークンを取り消し、読取りトークンが要求された
時は、書込みトークンを取り消すことにより、これらの
トークンの配布を調整する。

D.実施例 第７図を参照すると、分散データ処理システム40内
に、共用データにアクセスできる複数のノード10A、10
B、10Cがある。本発明は、この分散データ処理システム
内の複数のノードによるファイル5A、5B、5Cへのアクセ
スを管理するものである。ファイルは、サーバと呼ばれ
るノードに物理的に記憶される。サーバとは、ファイル
を長期間記憶する処理システムである。通信ネットワー
ク３によってサーバに接続された他のノードも、このフ
ァイルにアクセスできる。これらのノードは、これらの
状況の下でクライエントと呼ばれる。どのノードも、あ
るファイルのサーバとなり、別のファイルのクライエン
トとなることができる。ノードは、同時に両方の機能で
活動することができ、クライエントとして遠隔ファイル
にアクセスすると同時に、サーバとして他のノードにサ
ービスすることができる。

クライエントとしてのノードの活動とサーバとしての
ノードの活動は、互いに独立している。したがって、こ
れらの２つの活動が同時に起こることが可能であるが別
々に説明することにする。

クライエントがファイル内のデータにアクセスしよう
とする時、クライエントは、get_bytes要求と呼ばれる
要求またはメッセージを、そのファイルのサーバに送
る。get_bytes要求は、他の項目に加えて、このクライ
エントがアクセスしようとするバイトの範囲を指定す
る。get_bytes要求は、クライエントからサーバに送ら
れる。サーバは、準備ができると、get_bytes要求に応
えてその範囲内のデータを要求側クライエントに送る。
このget_bytes回答により、クライエントはこのデータ
にアクセスできるようになる。

あるサーバが以前に満足したあるget_bytes要求の後
で別のget_bytes要求がサーバに達した場合、サーバ
は、他のクライエントに以前に送ったバイトを取り消す
必要がある。

バイトは、revoke_bytesメッセージで取り消される。
revoke_bytesメッセージは、サーバからクライエント機
械に送られる。クライエントは、取り消されるバイトの
範囲内の変更されたデータを送り戻して、revoke_bytes
要求に応答せざるを得ない。クライエントはまた、その
範囲内の変更されていないデータを捨てざるを得ない。

クライエントは、修正されたデータをput_bytesメッ
セージと共にサーバに戻す。このメッセージは、get_by
tesメッセージやrevoke_bytesメッセージと同様に受信
側が送信側に送り戻す回答を含む。この回答は、３つの
場合すべてに、所期の受信側がメッセージを受け取り、
それに作用を加えたことを送信側に知らせる。データ
は、実際には、get_bytes要求に対する回答中でサーバ
からクライエントに移動し、さらにput_bytesメッセー
ジ中でクライエントからサーバに移動する。

サーバがrevoke_bytes要求を出さなければならない状
況は、この範囲内のバイトへの書込みアクセスを望むク
ライエントからのget_bytes要求がサーバに到着した時
に生じる。サーバは、以前にクライエントに送られてい
て、その後取り消されなかった、この範囲内のすべての
バイトを取り消さなければならない。クライエントがge
t_bytes要求を出すごとに、サーバは、サーバがそのク
ライエントに出したget_bytes回答の記録を保持する。
このようにして、サーバは、クライエント・ノードに送
り出されたファイルに属するデータのすべてのコピーを
記録することができる。書込みのためにこれらのバイト
を要求するクライエントからのget_bytes要求が到着し
た時、サーバは、その記録を検査して、他のクライエン
トが現在読取りまたは書込みのために同じバイトを使用
していないことを確かめる。他のクライエントがこれら
のバイトを使用している場合、サーバはまず、これらの
バイトを使用している各クライエントにrevoke_bytesメ
ッセージを送ることにより、それらのバイトを取り消
す。これらのクライエントは、バイトが修正されている
場合、put_bytesメッセージと共にそれらのバイトをサ
ーバに送り戻し、バイトが修正されていない場合は、そ
れらのバイトを捨てる。しかし、どの場合にも、バイト
が取り消された後、クライエントはそれらのバイトにア
クセスできない。put_bytes回答を受け取った後、クラ
イエントは、戻されたデータをサーバが受け取ったとの
通知を受け、revoke_bytes要求に回答する。

サーバは、revoke_bytes回答を受け取った時（リボー
クによってトリガされたput_bytesメッセージを受け取
った後）、要求側クライエントにget_bytes回答中でそ
れらのバイトを送ることにより、書込みのため自由にge
t_bytes要求に応答して、クライエントにこれらのバイ
トを修正する許可を与えることができる。このようにし
て、ファイル内のデータは、ただ１箇所で修正される。
データが修正されている場合、他のクライエントはその
範囲のデータにアクセスできない。このため、クライエ
ントは、再びデータへのアクセス権を得るまでに、後続
のすべての書込み動作から生じるデータを見ることがで
きる。これは、データに対するアクセスを直列化する効
果がある。

上記の例を続けると、クライエントＣは、クライエン
トＸに出されたバイトの範囲を含む、またはそれとオー
バラップするバイトに対する読取りアクセスを得たいと
の希望を表すことができる。クライエントＣが読取りの
ためget_bytes要求をサーバに送ると、サーバはその記
録を調べて、クライエントＸが書込みのためにこれらの
バイトを使用しているかどうかを判定する。次にサーバ
がクライエントＸからバイトを取り消さないと、それら
のバイトをget_bytes回答中でクライエントＣに送るこ
とができない。クライエントＣがそのget_bytes要求か
らの回答を待っている間に、サーバは、クライエントＸ
に取消し要求を出す。クライエントＸは、自分が修正し
たバイトを送ることができるようになるとすぐ、そのバ
イトを送る。クライエントＸは、バイトをサーバに送り
戻すのを完了すると、取消し範囲内の修正されたすべて
のバイトが送り戻され、取消し範囲内のすべてのバイト
がＸによって捨てられたことを、サーバに知らせる（ク
ライエントＸは、取消し要求に対する回答を戻すことに
よって、サーバに通知する）。サーバはこのとき、クラ
イエントＣから要求されたバイトの範囲内のすべてのバ
イトが現在最新状態であり、サーバで利用可能であり、
クライエントＣにget_bytes回答中で送るのに利用でき
ることを、サーバの記録から決定することができる。こ
の間、クライエントＣは、そのget_bytes要求に対する
回答を待っている。

重要な規則は、ファイル内のどのバイトについても、
ただ一つの機械が書込みのためにそのバイトを持つこと
ができ、一方何台の機械でも、読取りのためにそのバイ
トを使用できることである。好ましい実施例では、それ
らのバイトは個々に追跡されず、その代り、クライエン
トから要求されたバイトの範囲が追跡される。好ましい
実施例では、どの範囲のバイトについても、ただ１つの
クライエントが書込みアクセスのためにそのバイトの範
囲にアクセスできることが保証される。

本発明には、いくつかの利点がある。第１に、実際に
並行アクセスがある時だけ、ファイルに対する並行アク
セスを同期させればよい。以前の方法では、たとえその
処理がデータを実際に修正できなくても、ある処理がデ
ータを修正する可能性があるファイルを開いた時、並行
アクセスを同期させる必要があった。

本発明の他の重要な利点は、バイトの範囲が、その使
用の前後に各クライエントにキャッシュされることであ
る。このため、大部分の状況の下でデータのより効率的
な使用が可能になる。たとえば、ファイルに対するマッ
プ式アクセスの場合、ファイルをある処理のアドレス空
間にマップするマッピング動作が実行される。このマッ
ピングが実施されると、ファイルの内容が、通常のメモ
リ中にあるかのように、アクセス可能となる。このマッ
ピング動作は仮想メモリ管理によって支援され、ファイ
ルにアクセスするための効率的な方法となる。

本発明のシステム及び方法は、バイトの取消しをどう
扱うかを制御するものである。サーバとクライエントの
間を送られるメッセージの数を最小限にすることが望ま
しい。また各ノードが先に進むために他のノードを待
ち、どのノードも先に進めないという、デッドロック状
況の発生する可能性をなくすことも望ましい。またノー
ドがあるバイトの範囲に対するアクセスを許可されたと
信じているのに、サーバはそれらのバイトが取り消され
たと信じている可能性を最小限にすることも望ましい。

本発明を、次のシナリオ中で例示する。本発明の改良
によって機能が改良された、第１図の従来技術のネット
ワークを参照すると、クライエントは、ファイル内のあ
る範囲のバイトに対するget_bytes要求を、ファイル・
サーバ10Cに送る。ファイル・サーバ10Cは、要求された
バイトでget_bytes要求に回答して、それらのバイトを
クライエント10Aに送り戻す。第２のクライエント10B
が、衝突するモードで同じバイトを要求する。たとえ
ば、クライエント10Bは読取りのためにそれらのバイト
を要求するが、クライエント10Aは書込みのためにそれ
らのバイトを要求し、あるいはその逆を行なう。この場
合、サーバは、クライエント10Aに送ったばかりのバイ
トを取り消さなければならない。サーバ10Cは、revoke_
bytes要求をクライエント10Aに送ることによって、それ
を行なう。

次に第５図を参照して、サーバでのget_bytes要求処
理の動作について説明する。ステップ501で、クライエ
ントＣからget_bytes要求を受け取ると、サーバは、ス
テップ502に進んで、get_bytes要求中で指定されたファ
イル・ハンドルで識別されるファイルに対応するクライ
エント・リストを探し出す。ステップ503で、変数Ｅを
このクライエント・リストの第１のエントリに設定する
ことにより、ステップ504で、サーバはこのエントリＥ
に対するノードを検査し、それが要求側ノードと異なる
場合は、ステップ505に進んで、リスト上のエントリの
読取り／書込みフラグを検査する。このフラグが読取り
専用フラグの場合、ステップ507に進み、交差する範囲
を決定する。この交差範囲は、ステップ507で、get_byt
esメッセージ中のオフセットと長さで指定される要求さ
れた範囲と、エントリ内で書込みに対して指定された範
囲の間のオーバラップを求めることによって見つける。
ステップ505でエントリに対する再書込みフラグが読取
り専用フラグでない、すなわち読取り／書込みフラグで
あることが判明した場合、ステップ506に進んで、要求
された範囲とエントリＥに対する書込み範囲及び読取り
範囲との間のオーバラップを見つけることにより、交差
範囲を決定する。ステップ508で、サーバは、その時決
定されたばかりの交差範囲に対してエントリ内で指定さ
れたノードにrevoke_bytesメッセージを送る。ステップ
509で、クライエント・リストの終りに達していないと
判定された場合、ステップ512で、変数Ｅがクライエン
ト・リストの次のエントリに設定され、ステップ504に
戻って、そのエントリに対する処理を行なう。

ステップ509でリストの終りに達した場合、ステップ5
10に進んで、サーバは、このget_bytes要求のために出
されたすべての取消しに対する回答を待つ。ステップ51
1で、get_bytes回答が要求側クライエントに戻される。
その回答は、要求されたデータを含んでおり、処理は完
了する。

下記のプログラミング設計言語リストは、サーバにお
ける上記のget_bytes要求処理を別の形で記述したもの
である。このリストは、第５図に関して上記で述べた動
作と並行するものである。

／^＊サーバでのget_bytes処理^＊／ 変数： c:クライエント要求バイト； e:クライエント・リスト上のエントリ； fh:要求されたファイルに対するファイル・ハンド
ル； req_range:要求されたバイトの範囲； req_mode:要求されたモード、読取り専用モードまた
は読取り／書込みモード； get_bytes（c,fh,req_range,req_rmode）を受け取る； 手順： ファイル・ハンドルfhをもつファイルに対するクライエ
ント・リストを見つける； FOR e＝クライエント・リストの最初のエントリ TOクライエント・リストの最後のエントリDO IF eのノードがｃに等しくないTHEN IF req_modeがReadOnlyに等しいTHEN IF ebの何れかのr/wバイトがreq_range内にあるTHEN オーバーラップする範囲についてrevoke_bytesをｅの
ノードに送る； ENDIF; ELSE/＊req_modeは読取り／書込みモード＊／ IF eのr/wバイトまたはReadOnlyバイトの何れかがreq
_range内にあるTHEN オーバラップする範囲についてrevoke_bytesをｅのノ
ードに送る； ENDFOR; すべての取消しに対する回答を待つ； get_bytes回答を要求されたデータと共にクライエント
に送る； 次に第６図を参照して、クライエント・ノードでのre
voke_bytesメッセージの動作について説明する。ステッ
プ601で、revoke_bytesメッセージをサーバＳから受け
取る。このrevoke_bytesメッセージは、ファイルのブロ
ックの範囲に対するものである。ステップ602で、その
ファイルに対するいずれかのブロックが、このクライエ
ント・ノードにあると判定された場合、ステップ603
で、変数Ｂがこのクライエント・ノードにあるファイル
の第１ブロックに設定される。ステップ604で、このブ
ロックが取り消される範囲内にあると判定され、ステッ
プ605でそれが既に修正されていると判定された場合、
ステップ606に進んで、そのブロックがput_bytesメッセ
ージ中でサーバＳに送られる。ステップ605で、そのブ
ロックが修正されていないと判定された場合は、このブ
ロックに対するメッセージは、サーバに送られない。ど
ちらの場合でも、ステップ607に進んで、そのブロック
が捨てられる。ステップ608で、このファイルに対する
ブロックがまだ他にもあると判定された場合は、変数Ｂ
が次のブロックに設定され、次のブロックに対するステ
ップ604に戻る。

ステップ608で、このクライエント・ノードにこのフ
ァイルに対するブロックがもう他にはないと判定された
場合、ステップ610に進んで、このファイルに対する未
処理のget_bytes要求があるかどうか検査する。このフ
ァイルに対する未処理のget_bytes要求がある場合は、
ステップ611で、変数Ｇがそのうちの最初のものに設定
される。ステップ612で、変数Ｇを検査して、それが取
り消された範囲を交差するブロックの範囲に対するもの
かどうか判定する。そうである場合、ステップ613で、g
et_bytes要求は、その回答が到着した時に捨てられるよ
うにマークされる。ステップ614で、このファイルに対
する未処理のget_bytes要求がまだ他にもあると決定さ
れた場合は、ステップ615で、変数Ｇがこれらのうち次
のものに設定され、ステップ612に戻る。ステップ614で
未処理のget_bytes要求がもうないと決定された場合、
あるいはステップ610でファイルに対する未処理のget_b
ytes要求がないと決定された場合は、ステップ616に進
んで、このrevoke_bytesメッセージによって生じた以前
に出されたすべてのput_bytesメッセージに対する回答
を待つ。最後に、ステップ617で、revoke_bytesメッセ
ージに対する回答がサーバに送られ、取消し動作の処理
は完了する。

下記のプログラム設計言語リストは、クライエント・
ノードにおけるrevoke_bytesメッセージの上記の動作を
他の形で記述したものである。このリストは、第６図に
関して上記で述べた動作と並行するものである。

／^＊クライエント・ノードでのrevoke_bytes処理^＊／ 変数： fh:ファイルを識別するファイル・ハンドル； range:取り消される範囲； b:このノードにあるファイルのブロック； g:get_bytes要求； 手順： サーバｓからrevoke_bytes（fh,range）を受け取る； ／＊このノードに既にあるデータ・ブロックを取り消す
＊／ FOR b＝ハンドルfhをもつファイルのこのノードにある
最初のブロック TOこのノードにあるファイルの最後のブロックD
O IF bがrangeを交差するTHEN IF bが修正されているTHEN put_bytes（ｂ）をサーバに送る； ENDIF; このノードにあるキャッシュからｂをパージする； ENDIF; ENDFOR; ／＊ファイルに対する未処理のget_bytes要求を取り消
す＊／ FOR g＝最初の未処理get_bytes要求 TO最後の未処理get_bytes要求DO IF gがハンドルfhをもつファイルに対するget_bytes
であり、AND gがrangeと交差するTHEN ｇをその回答が捨てられるようにマークする； ENDIF; ENDFOR; put_bytesメッセージに対する回答を待つ； revoke_bytesメッセージに対する回答をｓに送る； ファイル上の読取り及び書込みシステム・コールが、
分散環境の全体にわたって直列化可能な方式で実行され
ることを保証するために、読取りがそこで実行されてい
る各機械は、読取りトークンを獲得しなければならず、
書込みがそこで実行されている各機械は、そのファイル
に対するサーバからのみ読取り／書込みトークンを獲得
しなければならない。いずれかの機械が読取り／書込み
トークンを有している場合、どの機械も読取りトークン
を有することはできない。何台もの機械が同時に読取り
トークンを有することもできる。サーバは、書込みトー
クンが要求される時、すべての読取りトークンを取り消
し、また読取りトークンが要求される時、その書込みト
ークンを取り消すことにより、これらのトークンの配布
を調整する。第８図ないし第11図に示した動作は、この
処理を図示したものである。

第８図は、クライエントで実行される読取りシステム
・コールの動作を示す流れ図である。ステップ800で、
ファイルＦに対する読取りシステム・コールが開始され
る。ステップ801で、そのファイルに対するトークンが
クライエント機械に保持されているかどうかを判定する
ためにテストを行なう。このトークンは、読取りトーク
ンでも読取り／書込みトークンでもよい。トークンがク
ライエントの所で現在保持されていない場合、ステップ
802で、get_tokenメッセージがサーバに送られる。この
get_tokenメッセージは、そのファイルに対する読取り
トークンを要求する。クライエントは、ステップ803で
回答を待ち、次いでステップ804に進んで、トークンを
ロックする。この動作は、ロック解除されるまで、トー
クンが取り消されるのを防止し、それによって、ステッ
プ805で実行される読取り動作の全持続期間中クライエ
ントでトークンを維持するものである。読取り動作が実
行された後、ステップ806でトークンはロック解除さ
れ、そのためその後は、サーバからのrevoke_tokenメッ
セージに応答してトークンが取り消せるようになるが、
トークンがこのノードから離れることはない。

下記のプログラミング設計言語リストは、クライエン
トで実行される読取りシステム・コールの上記の動作を
他の形で記述したものである。このリストは、第８図に
関して上記で述べた動作と並行するものである。

／＊クライエントでの読取りのためのトークン処理＊／ ／＊ファイルｆに対する読取りシステム・コール＊／ IFこのノードでｆに対するトークンを保持していないTH
EN 読取りトークンが求められていることを示すget_tkn
メッセージをｆのサーバに送る； 回答を待つ； ENDIF; ／＊トークンが現在このクライエントにある＊／ トークン上のロック・カウントを増分する； ／＊ロック・カウントが非ゼロのトークンがrevoke_tkn
を生じさせる＊／ ／＊ロック・カウントが０になるまで待つようにとのメ
ッセージ＊／ 読取り動作を実行する； トークンをロック解除する； 第９図は、クライエントでの書込みシステム・コール
の動作を示す流れ図である。ステップ900から処理が始
まり、ファイルＦに対する書込みシステム・コールが実
行される。ステップ901で、ファイルＦに対する読取り
／書込みトークンが現在クライエント・システムにある
かどうかを判定するために、テストを行なう。それがな
い場合、ステップ902でget_tokenメッセージが、このフ
ァイルに対する読取り／書込みトークンを要求するサー
バに送られる。ステップ903で、クライエントは、このg
et_tokenメッセージに対する回答を待つ。それが到着す
ると、クライエントは、読取り／書込みトークンを与え
られ、ステップ904に進んで、ステップ905で実行される
書込み動作中にこのクライエントから取り消されるのを
防止するためにトークンをロックする。書込み動作の完
了後、ステップ906でトークンはロック解除されて、rev
oke_tokenメッセージに応答して取り消せるようにな
る。

下記のプログラミング設計言語リストは、クライエン
トでの書込みシステム・コールの上記の動作を他の形で
記述したものである。このリストは、第９図に関して上
記で述べた動作と並行するものである。

／＊クライアントでの書込みのためのトークン処理＊／ ／＊ファイルｆに対する書込みシステム・コール＊／ IFこのノードでｆに対する書込みトークンを保持してい
ないTHEN 書込みトークンが求められていることを示す get_tknメッセージをｆのサーバに送る； 回答を待つ； ENDIF; ／＊書込みトークンが現在このクライエントの所にある
＊／ トークン上のロック・カウントを増分する ／＊ロック・カウントが非ゼロのトークンがrevoke_tkn
を生じさせる＊／ ／＊ロック・カウントが０になるまで待つようにとのメ
ッセージ＊／ 書込み動作を実行する； トークンをロック解除する； 第10図は、サーバによるget_token要求の動作を示す
流れ図である。ステップ1000で、サーバは、ノードＣか
らファイルＦに対するget_token要求を受け取る。ステ
ップ1001で、この要求が読取り／書込みトークンに対す
る要求である場合は、ステップ1003に進んで、現在トー
クンを保持している各クライエントにrevoke_tokenメッ
セージを送る。このrevoke_tokenメッセージは、サーバ
が以前にトークンを送ったノードにのみ送られ、それに
加えて、get_token要求をそこから受け取った先のノー
ドＣを除外する。ステップ1001で要求が読取り／書込み
トークンに対する要求でないと判定された場合は、その
要求は、読取りトークンに対する要求と見なされ、ステ
ップ1002に進んで、サーバは、他のクライエントがその
読取り／書込みトークンを有するかどうかを判定する。
そうである場合は、ステップ1004で、revoke_tokenメッ
セージがそのクライエントに送られる。ステップ1005に
進んで、サーバは、このget_token要求のために出され
たすべての取り消されたトークン・メッセージに対する
回答を待つ。ステップ1006で、get_token要求に対する
回答がクライエントＣに送り戻され、最後にステップ10
07で、元の要求に応じて、ノードＣがファイルに対する
読取り／書込みトークン、またはファイルに対する読取
りトークンを保持していると記録される。

下記のプログラミング設計言語リストは、サーバによ
るget_token要求の上記の動作を他の形で記述したもの
である。このリストは、第10図に関して上記で述べた動
作と並行するものである。

／＊サーバ・ノードでのget_tkn処理＊／ 変数： fh:ファイルを識別するファイル・ハンドル； モード:ReadOnlyまたはReadWrite; 手順： クライエントｃからget_tkn（fh,mode）要求を受け取
る； IFモードがReadWriteであるTHEN FORファイルｆに対するクライエント・リスト上の各
クライエントDO IFそのクライエントにトークンが送られたTHEN revoke_tknをクライエントに送る； ENDIF; ENDFOR; ELSE IFあるクライエントがｆのReadWriteトークンをもつT
HEN revoke_tknをそのクライエントに送る； ENDIF; ENDIF; revoke_tknの回答を待つ； get_tknの回答をクライエントｃに送る； ｃを要求されたモードのトークンの保持者として記録す
る； 第11図は、revoke_token要求に応答して発生するクラ
イエントでのrevoke_token処理の動作を示す流れ図であ
る。ステップ1100で、テストを行なって、取り消されて
いるトークンがクライエントにあるかどうかを判定す
る。ない場合は、ステップ1101で、クライエントは、ト
ークンが到着するのを待ってから先に進む。ステップ11
02でトークンを検査して、それが現在ロックされている
かどうか調べる。ロックされている場合、ステップ1103
で、クライエントは、トークンがロック解除されるのを
待つ。ステップ1104で、クライエントはこのとき、トー
クンが存在し、ロック解除されていると決定する。した
がってステップ1105で、トークンがこのクライエントか
ら除去され、回答が元のrevoke_token要求に送られる。

下記のプログラミング設計言語リストは、revoke_tok
en要求に応答して発生するクライエントでのrevoke_tok
en処理の上記の動作を他の形で記述したものである。こ
のリストは、第11に関して上記で述べた動作と並行する
ものである。

／＊クライエントでのrevoke−tkn処理＊／ 変数： fh:ファイルを識別するファイル・ハンドル； 手順： サーバｓからrevoke_tkn（fh）要求を受け取る； IF fhに対するトークンを保持していないTHEN トークンの到着を待つ； ENDIF; IFトークン上のロック・カウントがゼロより大きいTHEN ロック・カウントがゼロになるのを待つ； ENDIF; トークンを削除する； revoke_tkn要求に対する回答をサーバに送る； 第4a図は、ファイルからのデータ・バイトを要求する
get_bytesメッセージ440を示す。オフセット441は、要
求されるデータの始めを示すファイル中のオフセットで
ある。長さ442は、要求されるバイトの数である。読取
り／書込みフラグ443は、クライエントが、データの読
取り専用コピーを要求しているのか、それともデータの
書込み可能なコピーを要求しているのかを示すために使
用される。サーバは、クライエント・ノードが互換モー
ドであファイルを以前に開いており、まだ閉じていない
場合に、get_bytes動作を実行するだけである。rwフラ
グ443が読取り専用である場合、クライエントは、読取
りのためにファイルを開かなければならない。rwフラグ
443が読取り／書込みである場合は、クライエントは書
込みのためにファイルを開かなければならない。get_by
tesメッセージ440の回答中で、データ447は要求された
実際のデータである。

第4b図は、サーバからトークンを要求するためにクラ
イエントが使用するget_tknメッセージ450を示す。トー
クン・タイプ451は、要求されるトークンの種類を指定
する。サーバは、クライエント・ノードが互換モードで
ファイルを以前に開いており、まだ閉じていない場合、
get_tkn動作を実行するだけである。ファイル・サイズ4
52は、ファイルのサイズである。修正カウント453は、
サーバが維持する、ファイルの修正を反映した値であ
る。アクセス・カウント454は、サーバが維持する、フ
ァイルに対するアクセスを反映する値である。

第4c図は、put_bytesメッセージ460を示す。クライエ
ントは、put_bytesメッセージ460と共に、修正済みのデ
ータをサーバに戻す。サーバは、クライエントが書込み
のためにファイルを以前に開いており、まだ閉じていな
い場合、put_bytes動作を実行するだけである。オフセ
ット461は、長さ462のデータ・バイト463を置くべきフ
ァイル内でのオフセットである。

第4d図は、revoke_bytesメッセージ470を示す。この
メッセージは、get_bytesメッセージ440に対する回答中
でクライエントに以前に与えられたバイトを取り消すた
めにファイルのサーバからクライエントに送られる。ク
ライエントは、オフセット471と長さ472で示されるバイ
ト範囲について、すべての未修正キャッシュ・データを
捨て、サーバに対してすべての修正済みデータを書き込
み、回答を受け取るまで、回答を送らない。クライエン
トは、回答を送る時、取り消されたバイト範囲に対する
キャッシュされたデータを有していてはならない。revo
ke_bytesが処理される時、未処理であったget_bytes要
求によって戻される取り消されたバイト範囲中のどのデ
ータも、それが到着した時、捨てなければならない。

第4e図は、revoke_tknメッセージ480を示す。このメ
ッセージは、クライエントがget_token450メッセージに
対する回答中で受け取ったトークンを取り消すために、
サーバからクライエントに送られる。残存トークン・タ
イプ481は、クライエントがどの種類のトークンを残す
のかを指定する。許される条件は、（ａ）クライエント
が読取り専用のトークンを保持する、（ｂ）クライエン
トが読取り／書込みトークンを保持する、あるいは
（ｃ）クライエントがどのトークンも保持しないのいず
れかである。ファイル・サイズ482は、データ修正の後
にクライエントに見えるファイルのサイズである。シス
テムの状態についてサーバとクライエントの間の混乱を
避けるために、次の規則に従わなければならない。クラ
イエントでのファイルに対するrevoke_tkn480の処理
は、そのファイルに対する未処理のget_tkn450に対する
回答が処理されるまで遅延される。

要約すると、データの整合性を保つため、サーバにあ
るデータにアクセスするクライエントが同期されるシス
テムと方法を示した。サーバ・ノードは、そうするため
に、所与の時間に、あるノードにある修正のためにアク
セスできるデータの各部分が、他のノードから読取りま
たは修正のためにアクセスできず、同時に、そのデータ
の読取りのためにだけアクセスできる部分が、いくつの
ノードによってもアクセスできるようにする。これらの
要件を実施するため、サーバは、衝突する要求が異なる
クライエントから出た場合、クライエントに以前に配布
したデータを取り消さなければならない。

データのブロックは、“get_bytes"、“put_bytes"、
及び“revoke_bytes"要求に基づいて移動または管理さ
れる。デッドロック状況を起こさずにバイト取消し動作
を正しく行なうために、クライエントでのrevoke_bytes
要求の処理は、未処理のget_bytes要求が完了するのを
待たず、その代り、すべての未処理get_bytes要求は、
取消しを要求されているバイトがクライエントに到着し
た時に捨てられるように、マークされる。

ファイル上の読取り及び書込みシステム・コールが、
分散環境の全体にわたって直列化可能な方式で実行され
ることを保証するために、読取りがそこで実行されてい
る各機械は、読取りトークンを獲得しなければならず、
書込みがそこで実行されている各機械は、そのファイル
のサーバからのみ読取り／書込みトークンを獲得しなけ
ればならない。いずれかの機械が読取り／書込みトーク
ンを有する場合、どの機械も読取りトークンを有するこ
とはできない。同時に何台の機械が読取りトークンを持
つこともできる。サーバは、書込みトークンが要求され
た時、すべての読取りトークンを取り消し、読取りトー
クンが要求された時は、書込みトークンを取り消すこと
により、これらのトークンの配布を調整する。

E.発明の効果 本発明では、衝突する要求が異なるクライエントから
出された場合、サーバは以前にあるクライエントに配布
されたデータを取り消さなければならないが、この際に
デッドロック状態が起こるのを避けるために、クライエ
ントでのrevoke bytes要求の処理は、未処理のget byte
s要求が完了するのを待つ代わりに、すべての未処理get
bytes要求にはマークが付され、これらは取り消しが要
求されているバイトがクライエントの到着したときに捨
てるようにし、また、サーバが読取りトークン、読取り
／書込みトークンの配布を調整するようにしたので、分
散データ処理システムにおいて、サーバとクライエント
の間でバイトの取り消しを有効に制御しつつ、サーバと
クライエントの間で送られるメッセージの数を最少に抑
えて、かつデッドロックの状況の発生を最少に抑えつ
つ、サーバが複数のクライエントの同じデータを提供す
ることができ、同時に、クライエントが処理中のデータ
がすべてのクライエントによって加えられた最新の変更
を反映していることを各クライエントに保証することが
できる。

【図面の簡単な説明】

第１図は、従来技術の分散データ処理システムのブロッ
ク・ダイヤグラムである。 第２図は、システム・コールを使ってファイルにアクセ
スするための従来技術の独立型データ処理システムを示
すブロック・ダイヤグラムである。 第３図は、システム・コールを使ってファイルにアクセ
スする第２図の従来技術のデータ処理システムの流れ図
である。 第4a図は、ファイルからデータ・バイトを要求するため
のget_bytesメッセージのデータ構造である。 第4b図は、ファイルの読取り、または読取りと書込みの
許可を要求するための、get_tknメッセージのデータ構
造である。 第4c図は、修正されたバイトを、クライエント・データ
処理システムからサーバ・データ処理システムに戻すた
めの、put_bytesメッセージのデータ構造である。 第4d図は、get_bytesメッセージに対する回答中で以前
に送られたバイトを取り消すための、revoke_bytesメッ
セージのデータ構造である。 第4e図は、ファイルに対する読取り許可を与えるトーク
ンを取り消すか、またはファイルに対する読取りと書込
みの許可を与えるトークンを取り消すためのrevoke_tkn
メッセージのデータ構造である。 第５図は、サーバでの本発明のget_bytes要求処理の動
作を示す流れ図である。 第６図は、クライエント・ノードでの本発明のrevoke_b
ytesメッセージの動作を示す流れ図である。 第７図は、本発明の分散データ処理システム内のクライ
エント・データ処理システムとサーバ・データ処理シス
テムのブロック・ダイヤグラムである。 第８図は、クライエントで読取りシステム・コールの動
作を示す流れ図である。 第９図は、クライエントで書込みシステム・コールの動
作を示す流れ図である。 第10図は、サーバでのget_token要求の動作を示す流れ
図である。 第11図は、revoke_token要求に応じたクライエントでの
revoke_token処理の動作を示す流れ図である。 ３……通信ネットワーク、５、25……ファイル、10……
ノード、20……サーバ・ノード、30……クライエント・
ノード、21、31……オペレーティング・システム（O
S）、23、33……VMM、34……アプリケーション、26、36
……FS、27、37……メモリ・セグメント。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ステフアン・ポール・モーガン アメリカ合衆国ニユーヨーク州マホパツ ク、ボツクス97、クデイー・ロード、ア ールエフデイ５番地 (72)発明者 トツド・アレン・スミス アメリカ合衆国テキサス州オースチン、 アプリコツト・グレン1802番地 (56)参考文献 特開 昭63−200244（ＪＰ，Ａ) 特開 昭63−201845（ＪＰ，Ａ) 特開 昭63−204572（ＪＰ，Ａ) 特開 昭63−201743（ＪＰ，Ａ) 特開 昭63−201864（ＪＰ，Ａ) 特開 昭63−204437（ＪＰ，Ａ)

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】データ処理システムのサーバ装置に貯蔵さ
   れたファイルの可変長部分に対する、特定のデータ単位
   の指定による、クライエント装置によるアクセスを制御
   するシステムであって、 前記ファイルの前記部分に対して読取り専用のアクセス
   権を有する前記クライエント装置の各々に対して前記サ
   ーバ装置により読取り専用トークンを発行させる手段及
   び読取り動作中前記読取りトークンが前記クライエント
   装置の各々に存在することを要求する手段を含み、前記
   クライエント装置の各々が前記ファイルの前記部分に対
   して読取り専用のアクセス権を持っている間前記ファイ
   ルの前記部分の前記クライエント装置への転送を許可す
   る第１の手段と、 前記第１の手段につながれ、単一のクライエント装置に
   よる読取り／書込みトークンの要求に応答して前記サー
   バにより読取り／書込みトークンを前記単一のクライエ
   ント装置に対して発行させ、かつ書込み動作中前記読取
   り／書込みトークンが前記単一のクライエント装置に存
   在することを要求する手段を含み、前記単一のクライエ
   ント装置が前記ファイルの前記部分に対して読取り／書
   込みアクセス権を持っている間前記ファイルの前記部分
   の前記単一のクライエント装置への転送を許可する第２
   の手段と、 前記第１及び第２の手段につながれ、前記単一のクライ
   エント装置による読取り／書込みトークの要求に応答し
   て前記読取り専用トークンの各々を取り消す手段と、 前記第１及び第２の手段につながれ、他のクライエント
   装置の１つによる読取り／書込みトークンまたは読取り
   専用トークンの要求に応答して前記単一のクライエント
   装置に対して発行された読取り／書込みトークンを取り
   消す手段と、 前記第２の手段につながれ、クライエント装置の１つが
   読取り専用のアクセス権を持っているときに、他のクラ
   イエント装置による前記ファイルの前記部分への読取り
   ／書込みアクセス要求を前記サーバ装置が受けた際に、
   前記クライエント装置の１つから前記ファイルの前記部
   分を取り消し、前記クライエント装置の１つに前記ファ
   イルの前記部分を破棄させる手段と、 前記第１及び第２の手段につながれ、他のクライエント
   装置による前記ファイルの前記部分への読取り／書込み
   または読取り専用アクセス要求を前記サーバ装置が受け
   た際に前記単一のクライエント装置から前記ファイルの
   前記部分を取り消し、前記ファイルの前記部分のうち前
   記単一のクライエント装置により変更された部分を前記
   単一のクライエント装置により前記サーバ装置に返送さ
   せ、前記ファイルの前記部分のうち変更されなかった部
   分を前記単一のクライエント装置により破棄させる手段
   と、 を具備するデータ処理装置のクライエント装置のアクセ
   ス制御システム。