WO2012101855A1

WO2012101855A1 - 通信システム、通信装置、通信制御方法

Info

Publication number: WO2012101855A1
Application number: PCT/JP2011/069035
Authority: WO
Inventors: 伊藤　大輔; 秀貴青木
Original assignee: 株式会社日立製作所
Priority date: 2011-01-28
Filing date: 2011-08-24
Publication date: 2012-08-02

Abstract

　従来、関連のある複数のファイルを読み込む類のアプリケーションでは、個々のファイルの属性取得が重複し、その結果ＷＡＮを介したファイル共有が遅くなる点に鑑み、関連のある複数のファイルを読み込む類のアプリケーションの動作を高速化する。重複した属性取得を行わずに済むよう、属性取得メッセージに対するレスポンスをキャッシュし再利用する。各処理部１１７、１１８，１１９およびデータベース１２０，１２１、キャッシュ１２２は制御部１１６によって、一貫性制御が不要な期間のみ属性情報をキャッシュすることで、互いに連携して動作しＷＡＮを高速化する。

Description

通信システム、通信装置、通信制御方法

　本発明は、通信システム、通信装置、通信制御方法に係り、特に、ＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ，広域網）高速化装置や上位プロトコル高速化装置等の通信装置の構成及び制御方法に関する。

　ＷＡＮを介してデータセンタ（ＤＣ，Ｄａｔａ　Ｃｅｎｔｅｒ）と事業拠点の間で通信を行う場合、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）のフロー制御の制約から実効帯域がＷＡＮの遅延に律束され、ＷＡＮの契約帯域を太くしても効果が得られない。そこで、例えば非特許文献１のようにＴＣＰのフロー制御を改善したりといったＴＣＰ高速化手法が提案されている。

　また、遅延の大きいデータ取得を高速化する従来手法にキャッシュを用いたＷＡＮ高速化装置等の通信装置がある。キャッシュを用いた方式とは１度送受信したデータを記憶しておき、２回目以降の同じデータの送受信の際に再利用することで、データ取得を高速化する方式である。キャッシュを用いた通信装置は一般にＤＣおよび事業拠点のネットワークの出入り口に設置され、ネットワーク上でプロクシとして動作する。そこで事業拠点内にあるクライアントからのリクエストに対する、ＤＣ内にあるサーバからのレスポンスをキャッシュし再利用する。

　さらに、従来、以下のように先読み方式と呼ばれる手法がある。
　キャッシュとは異なるＷＡＮ高速化装置等の通信装置の制御方法の従来手法に、特許文献１に開示された手法がある。これはネットワーク上でプロクシとして動作してクライアントとサーバの間のメッセージを監視する。そして特許文献１のＦＩＧ．６に示すようにクライアントから次に来るメッセージを予測し、先にサーバにリクエストを送信しレスポンスを受信しておき、クライアントから予測通りのメッセージが届いた後に、先に受信しておいたレスポンスを返すという方式である。以下に例をあげて説明する。
　あるファイル共有プロトコルでは、ファイルサーバ上のファイルＡをクライアントにコピーする場合に、以下のような一連のメッセージをクライアントからサーバに送信する。
＃１．　ＱＵＥＲＹ＿ＰＡＴＨ＿ＩＮＦＯＲＭＡＴＩＯＮ１（Ｆｉｌｅ　Ａ）
＃２．　ＱＵＥＲＹ＿ＰＡＴＨ＿ＩＮＦＯＲＭＡＴＩＯＮ２（Ｆｉｌｅ　Ａ）
＃３．　ＱＵＥＲＹ＿ＰＡＴＨ＿ＩＮＦＯＲＭＡＴＩＯＮ３（Ｆｉｌｅ　Ａ）
＃４．　ＱＵＥＲＹ＿ＰＡＴＨ＿ＩＮＦＯＲＭＡＴＩＯＮ４（Ｆｉｌｅ　Ａ）
＃５．　ＯＰＥＮ（Ｆｉｌｅ　Ａ，　ｒｅａｄ＿ｏｎｌｙ）
＃６．　ＱＵＥＲＹ＿ＦＩＬＥ＿ＩＮＦＯＲＭＡＴＩＯＮ（ＦＩＤ　ｏｆ　Ｆｉｌｅ　Ａ）
＃７．　ＲＥＡＤ（ＦＩＤ　ｏｆ　Ｆｉｌｅ　Ａ）
＃８．　ＲＥＡＤ（ＦＩＤ　ｏｆ　Ｆｉｌｅ　Ａ）
…
＃ｙ．　ＲＥＡＤ（ＦＩＤ　ｏｆ　Ｆｉｌｅ　Ａ）
＃ｚ．　ＣＬＯＳＥ（ＦＩＤ　ｏｆ　Ｆｉｌｅ　Ａ）
　これらのメッセージのうち、＃１から＃４はファイルＡのサイズやアクセス時刻などファイルの属性を取得する命令である。続いて＃５でファイルを読込専用でオープンしファイル識別子（ＦＩＤ，Ｆｉｌｅ　ＩＤｅｎｔｉｆｉｅｒ）を取得する。その後＃６でさらに属性を取得し、＃７以降でファイルを先頭から１６ＫＢずつ読み込み、＃ｙでファイル全体を読み終えたあと＃ｚでファイルをクローズし、処理を終える。この場合、＃１のメッセージを通信装置が監視した際に、＃２から＃４までのメッセージを予測してサーバに送信することができる。また、＃５を監視した際に、多くのアプリケーションはファイル全体を一度に読み込むことから＃６から＃ｙまでのメッセージを予測してサーバに送信することができる。なお、＃５に関してはファイルを読込み専用でオープンするのか、それとも書込みもできるようにオープンするのか、＃１を観測した時点では予測できないため、ここでは先読みできないとした。

ＵＳ１０／６４０４０５、「Ｔｒａｎｓｐａｒｅｎｔ　ｃｌｉｅｎｔ－ｓｅｒｖｅｒ　ｔｒａｎｓａｃｔｉｏｎ　ａｃｃｅｌｅｒａｔｏｒ」　（［００６５］）

Ｌｉｓｏｎｇ　Ｘｕ，　Ｋｈａｌｅｄ　Ｈａｒｆｏｕｓｈ，　ａｎｄ　Ｉｎｊｏｎｇ　Ｒｈｅｅ，　Ｂｉｎａｒｙ　Ｉｎｃｒｅａｓｅ　Ｃｏｎｇｅｓｔｉｏｎ　Ｃｏｎｔｒｏｌ　ｆｏｒ　Ｆａｓｔ，　Ｌｏｎｇ　Ｄｉｓｔａｎｃｅ　Ｎｅｔｗｏｒｋｓ，　ＩＮＦＯＣＯＭ，　ＩＥＥＥ，　２００４　（ｐｐ．　５），ｈｔｔｐ：／／ｎｅｔｓｒｖ．ｃｓｃ．ｎｃｓｕ．ｅｄｕ／ｐ－ｔｃｐ２．ｈｔｍｌ

　しかし、非特許文献１のように、ＤＣと事業拠点間のＷＡＮを介したＴＣＰ通信が高速化されても、電子メールの送受信やネットワークストレージ（ＮＡＳ，Ｎｅｔｗｏｒｋ　Ａｔｔａｃｈｅｄ　Ｓｔｏｒａｇｅ）　を用いたファイル共有は十分に高速化されないという課題がある。特にＮＡＳの主要プロトコルであり、かつＷｉｎｄｏｗｓ（登録商標）の標準ファイル共有プロトコルであるＣＩＦＳ（Ｃｏｍｍｏｎ　Ｉｎｔｅｒｎｅｔ　Ｆｉｌｅ　Ｓｙｓｔｅｍ）はＴＣＰ高速化手法と組み合わせても契約帯域の１０％程度しか利用できない場合がある。

　上記課題を調査した結果、ＣＩＦＳは高々６０ＫＢのメッセージを１件ずつ往復させて送受信していることが判った。このためＴＣＰ高速化手法の効果が得られず、メッセージ１往復ごとにＲＴＴ（Ｒｏｕｎｄ　Ｔｒｉｐ　Ｔｉｍｅ）分の時間がかかる。この課題を解決するためには、ＣＩＦＳ実装を改善することが望ましい。しかしこれらは既に広く利用されているコンポーネントであるため現実的ではない。

　また、従来のキャッシュを用いたＷＡＮ高速化装置等の通信装置のように、１つのＤＣに対して複数の事業拠点がある環境において、ファイル共有に対してキャッシュを用いた通信装置を適用すると、キャッシュしたデータの一貫性制御のためのメッセージ交換が余計に発生するため、十分に高速化されない事が判っている。また電子メールのように同じメッセージを繰り返し送受信しないアプリケーションにおいてはキャッシュの効果を得ることはできない。

　さらに、上述のように特許文献１の手法によると、ＷＡＮを介したファイル共有が高速化できる可能性がある。しかし、それでもなお多くのクライアントから頻繁にアクセスされるファイルの転送速度が十分に高速化されないという課題がある。

　図１２に、複数クライアントが同じファイルに読込みアクセスする場合のメッセージシーケンスを示す。
　上記課題を、図１２を用いて説明する。図１２は同一の高速化装置等の通信装置に接続されたクライアントＡおよびクライアントＢが同じファイルに読込みアクセスする場合のメッセージシーケンスを表している。まずクライアントＡが属性取得１３０１を行い、続いてファイルを読込専用でオープン１３０２する。ここで、オープン１３０２の直後に同じファイルに読込みアクセスするクライアントＢの挙動に注目すると、クライアントＡと同じく属性取得１３０３を行い、続いてファイルを読込専用でオープン１３０４する。このように、あるファイルにアクセスする都度、属性取得（１３０１、１３０３）とオープン（１３０２、１３０４）の二回のアクセスが必要になる。先の例でみたとおり、属性取得をトリガに以降のメッセージを先読みすることは可能だが、属性取得そのものを先読みすることはできない。
　すなわち特定のファイルが多くのユーザから頻繁にアクセスされるアプリケーションにおいては、ファイルの属性取得メッセージが重複することが課題である。

　以上のように、本発明が解決しようとする課題は、関連のある複数のファイルを読み込む類のアプリケーションでは、個々のファイルの属性取得が重複し、その結果ＷＡＮ等のネットワークを介したファイル共有が遅くなる事である。
　つまり、通信装置は、複数のクライアントからのリクエストにより、ネットワークを介してファイルサーバに対して、ファイルの情報（ex属性情報）を重複して取得してしまい、ファイルアクセスに時間がかかる。
　また、属性情報を通信装置がキャッシュすると、クライアントから更新リクエストがあると、ファイルサーバ側の属性情報が変更されてしまうため、通信装置でキャッシュしている属性情報が、ファイルサーバで管理しているデータと整合性がとれなくなる。
　本発明は、以上の点に鑑み、関連のある複数のファイルを読み込む類のアプリケーションの動作を高速化したファイル共有を実現することを目的とする。

　上記課題の少なくとも一を解決するために、本発明の一態様は、ファイルサーバに接続する通信装置は、ファイルサーバから取得したファイルの排他権を管理し、拠点内のクライアントからの当該ファイルの排他制御に関するリクエストを監視し、監視状況によって、キャッシュヒットしたファイルに関するデータを送信するか制御する、という態様である。
　別の態様によると、排他制御権のやり取りを含む上位アプリケーションプロトコルを高速化する通信装置及び制御・構成方法であって、
ネットワーク上を流れる上位プロトコルのメッセージを監視し、配下のクライアントがあるファイルに対して保持した排他制御権を監視する処理手順と
前記配下のクライアントが排他制御権を保持するファイルの属性情報をキャッシュする処理手順と
前記配下のクライアントが排他制御権を保持するファイルに対する属性情報取得要求に対し、前記キャッシュ中の属性情報を返す処理手順を
有する事を特徴とする通信装置及び制御・構成方法、という態様である。
　また、別の態様は、上述の上位アプリケーションプロトコルを高速化する通信装置及び制御・構成方法であって、上位アプリケーションプロトコルとしてファイル共有プロトコルを高速化する、という態様である。

　また、別の態様は、クライアントとサーバとの間に設けられた通信装置を備え、前記クライアントが前記サーバのファイルにアクセスするための通信システムにおいて、
　前記通信装置は、第１のクライアントから属性取得リクエストを受信すると、第１のデータベース（ＤＢ）に該属性取得リクエストの対象となるファイルのエントリがなければレスポンスをキャッシュから返せないと判断し、該属性取得リクエストをメッセージ識別子とともに第１バッファに一時保存し、該属性取得リクエストをサーバ側に送り、
　前記通信装置は、前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の属性取得リクエストに対する属性取得レスポンスであると判断すると、属性取得リクエストと属性取得レスポンスの対を前記キャッシュに追加し、該属性取得レスポンスを前記第１のクライアントに送り、
　前記通信装置は、前記第１のクライアントから排他制御に関わる排他制御リクエスト受信すると、第２のバッファに一時保存し、前記第１のＤＢに該排他制御リクエストの対象となるファイルのエントリがなければレスポンスを前記キャッシュから返せないと判断し、該排他制御リクエストを前記第１バッファに一時保存し、該排他制御リクエストを前記サーバ側に送り、
　前記通信装置は、前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の前記排他制御リクエストに対する排他制御レスポンスであると判断すると、該排他制御リクエストと該排他制御レスポンスの対を前記キャッシュに追加し、前記第２バッファ内の該排他制御リクエストと照合し、該排他制御リクエストに対するレスポンスである場合は前記第１のＤＢに前記排他制御リクエストの対象となるファイルのエントリを挿入し、該排他制御レスポンスを前記第１のクライアントに送り、
　前記通信装置は、第２のクライアントから属性取得リクエストを受信すると、前記第１のＤＢに該属性取得リクエストの対象となるファイルのエントリがあればレスポンスを前記キャッシュから返せると判断し、既に属性取得リクエストおよびレスポンスの対が前記キャッシュにキャッシュされていると判断し、前記キャッシュから前記属性取得レスポンスを返す
通信システム、という態様である。

　また、別の態様は、
　クライアントとサーバとの間に設けられた通信装置を備え、前記クライアントが前記サーバのファイルにアクセスするための通信システムにおける前記通信装置、及び、通信制御方法において、
　第１のクライアントから属性取得リクエストを受信すると、第１のデータベース（ＤＢ）に該属性取得リクエストの対象となるファイルのエントリがなければレスポンスをキャッシュから返せないと判断し、該属性取得リクエストをメッセージ識別子とともに第１バッファに一時保存し、該属性取得リクエストをサーバ側に送り、
　前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の属性取得リクエストに対する属性取得レスポンスであると判断すると、属性取得リクエストと属性取得レスポンスの対を前記キャッシュに追加し、該属性取得レスポンスを前記第１のクライアントに送り、
　前記第１のクライアントから排他制御に関わる排他制御リクエスト受信すると、第２のバッファに一時保存し、前記第１のＤＢに該排他制御リクエストの対象となるファイルのエントリがなければレスポンスを前記キャッシュから返せないと判断し、該排他制御リクエストを前記第１バッファに一時保存し、該排他制御リクエストを前記サーバ側に送り、
　前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の前記排他制御リクエストに対する排他制御レスポンスであると判断すると、該排他制御リクエストと該排他制御レスポンスの対を前記キャッシュに追加し、前記第２バッファ内の該排他制御リクエストと照合し、該排他制御リクエストに対するレスポンスである場合は前記第１のＤＢに前記排他制御リクエストの対象となるファイルのエントリを挿入し、該排他制御レスポンスを前記第１のクライアントに送り、
　第２のクライアントから属性取得リクエストを受信すると、前記第１のＤＢに該属性取得リクエストの対象となるファイルのエントリがあればレスポンスを前記キャッシュから返せると判断し、既に属性取得リクエストおよびレスポンスの対が前記キャッシュにキャッシュされていると判断し、前記キャッシュから前記属性取得レスポンスを返す
通信装置、及び、通信制御方法、という態様である。

　本発明の一の態様によって、関連のある複数のファイルを読み込む類のアプリケーションの動作が高速化される。
　また、本発明の一の態様によると、通信装置のキャッシュ処理により、ファイル共有において整合性をとることができる。

本実施の形態を用いた高速通信システムの全体像を表す主要図面本実施の形態を用いた通信装置の構成図本実施の形態の通信装置の処理フローを表す図本実施の形態の排他状態監視部の処理フロー本実施の形態の排他管理部の処理フローＡ本実施の形態のキャッシュ制御部の処理フローＡ本実施の形態の排他管理部の処理フローＢ本実施の形態のキャッシュ制御部の処理フローＢ本実施の形態の排他状態管理ＤＢのスキーマとデータ例本実施の形態のＦＩＤ　ＤＢのスキーマとデータ例本実施の形態のキャッシュのデータ例複数クライアントが同じファイルに読込みアクセスする場合のメッセージシーケンス複数クライアントが同じファイルに読込みアクセスする場合のメッセージシーケンス

　本実施の形態は、遅延の大きい広域網を介して業務拠点からデータセンターのファイルサーバにアクセスを行う事例に通信装置を適用した例である（ファイルサーバとキャッシュに適用した実施の形態）。

　図１Ａに本実施の形態を用いた高速通信システムの全体像を表す主要図面、及び、図１Ｂに通信装置の構成図を示す。
　本実施の形態の構成を図１Ａ及び図１Ｂに示す。ここでは事業拠点１０１とＤＣ１０２がＷＡＮ１０３を介して接続されている。本実施の形態の制御方法を実装した通信装置１０４は事業拠点１０１のＷＡＮ側出口に設置され、事業拠点１０１の拠点内ネットワーク（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ，ＬＡＮ）１０５を介して複数のクライアント１０６と接続される。通信装置１０４は内部にＣＰＵ１１１と主記憶部１１２と二次記憶部１１３とＬＡＮ側ＮＩＦ（Ｎｅｔｗｏｒｋ　ＩｎｔｅｒＦａｃｅ）１１４とＷＡＮ側ＮＩＦ１１５を持つ。また、本実施の形態で扱う各処理手順は二次記憶部１１３内のプログラム１２３に実装される。実際に処理を行う際にはＣＰＵ１１１がプログラム１２３に従い主記憶部１１２中に制御部１１６、排他状態監視部１１７、排他管理部１１８、キャッシュ制御部１１９を展開し、また二次記憶部１１３には排他状態管理ＤＢ（データベース、Ｄａｔａ　Ｂａｓｅ）１２０、ＦＩＤ　ＤＢ１２１、キャッシュ１２２を展開する。その後、制御部１１６および各処理部１１７、１１８，１１９はＣＰＵ１１１によってプログラム１２３に従い実行される。

　図２は、本実施の形態の通信装置の処理フローを表す図である。
　各処理部１１７、１１８，１１９およびデータベース１２０，１２１、キャッシュ１２２は制御部１１６によって図２に示す通り接続され、互いに連携して動作しＷＡＮを高速化する。以下に、各処理部１１７、１１８、１１９の動作を説明する。なお、以下では説明を明確にするため、ＬＡＮ側ＮＩＦ１１４をＬＡＮ側ＮＩＦの入力（ＩＮ）２０１および出力（ＯＵＴ）２０２とし、同じくＷＡＮ側ＮＩＦ１１５をＷＡＮ側ＮＩＦのＩＮ２０４およびＯＵＴ２０３とする。

　図８に、排他状態管理ＤＢ１２０のスキーマとデータの例を表す。排他状態管理ＤＢ１２０は表中の通し番号列、ファイル名列、状態列を持つ。状態列には排他制御権の種別を持つ。ここで扱う排他制御とは複数のコンピュータプログラムや、単一コンピュータ内の複数のスレッドなど、何らかの動作単位の動作を考える（例えば、“Ｐｒｉｎｃｉｐｌｅｓ　ｏｆ　Ｔｒａｎｓａｃｔｉｏｎ　Ｐｒｏｃｅｓｓｉｎｇ”，　Ｐｈｉｌｉｐ　Ａ．　Ｂｅｒｎｓｔｅｉｎ　ａｎｄ　Ｅｒｉｃ　Ｎｅｗｃｏｍｅｒ，　１９９７　［ＩＳＢＮ　１－５５８６０－４１５－４］，　ｐ．　１９６等参照）。この場合に、例えばファイルサーバ上のファイルのように、システム内の複数の動作単位が利用できる共有資源に対して複数の動作単位が同時にアクセスを行うと競合が発生する可能性がある場合に、ある動作単位がアクセスを行う時に、そのアクセス種別に応じて他の動作単位からのアクセスを制限する制御である。排他制御の実装方法として代表的な物にロックを用いる方法がある。ロックを用いる第一の方法では、ある動作単位がある共有資源にアクセスするには、該共有資源のロックを、システムにただ一つ存在するロック管理部（排他管理部）から取得していなければならないという制約をシステムに与える。このようなロックを用いたシステムでは、動作単位が共有リソースにアクセスを行う場合、まずロック管理部（排他管理部）から該共有リソースへのロックを取得することを試みる。ここで該共有リソースへのロックが取得できれば該共有リソースへアクセスを行う。一方で該共有リソースへのロックが取得できなかった場合は、他の動作単位が既に該共有リソースへアクセスしている事を表している。この場合は、しばらく間を空けた後に、再びロック管理部（排他管理部）から該共有リソースへのロックを取得することを試みる。また、ロックを用いた第二の方法では、ロックの種類を「リードロック」「ライトロック」とし、動作単位が共有リソースに対してリードアクセスを行う場合はリードロックを、ライトアクセスを行う場合はライトロックを取得しなければならないという制約をシステムに与える。さらに、二種類のロックを用いる第二の方法では、ロック管理部（排他管理部）に「既にライトロックを取られている共有リソースに対して、いかなるロックも追加発行することはできない」「既にリードロックを取られている共有リソースに対して、ライトロックを追加発行することはできない」というルールを課す。このように二種類のロックを用いる第二の方法ではある共有リソースに対して複数の動作単位が並行してリードアクセスを行うことができる。また、ロックの種類をさらに細かく分けた方法も提案されている。なお、「リードロック」「ライトロック」の他にも、「シェアードロック」「エクスクルーシブロック」に適用することもできる。

　続いてロック取得に関する手続きについて説明する。ロック取得の第一の方法は明示的なロック取得である。第一の方法では、動作単位がリードやライトと言ったアクセス命令に先立ち明示的にロック取得という命令をロック管理部（排他管理部）に送信し、ロック管理部（排他管理部）は該共有リソースの状態に従い該動作単位にロックを渡したり、渡さなかったりと判断を行う。ロック取得の第二の方法はファイルサーバなどで用いられる暗示的なロック取得である。ファイルサーバではあるファイルへのＲＥＡＤやＷＲＩＴＥといったアクセスに先立ち、動作単位はＯＰＥＮという命令を送信し、該ファイルのファイル識別子を取得する。また、該動作単位は該ＯＰＥＮ命令を送信する際に、該ファイルに対しこれから行うアクセスがＲＥＡＤなのか、ＷＲＩＴＥなのか、両方なのかを判断可能なフラグをつけて送信する。そこで、ファイルサーバはＯＰＥＮ命令を受信すると、該ファイル名と該フラグをロック管理部（排他管理部）に渡し、ロック取得可否を問い合わせる。その結果、ロック取得可能であれば、該動作単位にＯＰＥＮ成功メッセージと共に該ファイルへの識別子を返信する。一方、ロック取得不可であれば、該動作単位にＯＰＥＮ失敗メッセージだけを返信し、該ファイルへの識別子は返信しない。
　本実施の形態では、一例として、上記ロックを用いる第二の排他制御方法を用いる。また、一例として、ロック取得に関する手続きには上記第二のロック取得方法を用いる。上記ロックを用いる第二の排他制御方法で扱う「リードロック」と「ライトロック」とを、排他状態管理ＤＢ１２０の状態列で管理する。

　図９に、ＦＩＤ　ＤＢ１２１のスキーマとデータの例を表す。ＦＩＤ　ＤＢ１２１は表中の通し番号列、ＦＩＤ列、ファイル名列を持つ。
　図１０は、キャッシュ１２２のスキーマとデータの例を表す。キャッシュ１２２は、第１のデータとして、キャッシュの識別子となるファイル名と属性情報のペアを保持する。また、キャッシュ１２２は、第２のデータとして、メッセージ識別子に対して、リクエストとレスポンスの対を保持する。
　ここで扱う属性情報とは、ファイルの所有者やアクセス権限、更新日時といったものである。一般的なファイルシステムでは、各ファイルに対して所有者、所有グループ、所有者のアクセス権限（読込み／書込み／実行）、グループのアクセス権限（読込み／書込み／実行）、その他のユーザのアクセス権限（読込み／書込み／実行）、ファイル作成日時、最終更新日時といった情報が管理される。ここでも所有者、所有グループ、所有者のアクセス権限、グループのアクセス権限、その他のユーザのアクセス権限、ファイ作成日時、最終更新日時を管理する。

　図３に、本実施の形態の排他状態監視部の処理フローを示す。図４に、本実施の形態の排他管理部の処理フローＡを示す。また、図５に、本実施の形態のキャッシュ制御部の処理フローＢを示す。

（クライアント１０６からファイルサーバ１０７へのメッセージ）
　ＬＡＮ側ＮＩＦのＩＮ２０１から入ったクライアント１０６からファイルサーバ１０７へのメッセージは排他状態監視部１１７の処理フローＡ（図３）とキャッシュ制御部１１９の処理フローＡ（図５）に渡される。ここではまず排他状態監視部側の処理を説明する。
　図３に示した排他状態監視部の処理フローＡでは、クライアント１０６からのメッセージが入力３０１されたら、そのメッセージが排他制御に関わるメッセージか否か判断３０２する。判断の結果、排他制御に関わるメッセージであれば排他管理部の処理フローＡ（図４）に入力したメッセージを渡して呼び出し３０３、処理を終える３０４。判断３０２において排他制御に関わる処理ではないと判断した場合はそのまま処理を終える３０４。なお、ここでは使用するファイル共有プロトコルに関する知識として、排他制御に関わるメッセージの一覧および排他制御に関わらないメッセージの一覧を事前にシステム設計者や管理者が登録しておくものとする。また、ここでは排他制御に関わるメッセージを、一例として、ＯＰＥＮとＣＬＯＳＥとする。また、ＯＰＥＮメッセージはファイルの絶対パスを含み、ＯＰＥＮに対するレスポンスメッセージはＦＩＤを含むとする。さらにＣＬＯＳＥメッセージはＦＩＤを含み、ＣＬＯＳＥに対するレスポンスメッセージは成否を表すメッセージを含むとする。

　図４に示した排他管理部の処理フローＡでは、まずメッセージを入力４０１し、そのメッセージがサーバからのレスポンスメッセージか判断４０２する。リクエストメッセージであると判断した場合は、リクエストメッセージを排他管理部１１８内のバッファに一時保存４０３し、処理を終える４０４。判断４０２において、サーバからのレスポンスメッセージであると判断した場合の説明は後述する。
　なお、ここで想定するファイル共有プロトコルは、あるリクエストに対するレスポンスには同じメッセージ識別子が振ってあり、あるリクエストに対するレスポンスを容易に識別可能であるものとする。これは多くのファイル共有プロトコルで一般的に用いられる手法である。

　続いてＬＡＮ側ＮＩＦのＩＮ２０１からのメッセージがキャッシュ制御部の処理フローＡに渡った後の処理を説明する。
　図５に示したキャッシュ制御部の処理フローＡでは、クライアント１０６からのメッセージが入力５０１されたら、そのメッセージをキャッシュから返せるか排他管理部の処理フローＢ（詳細は後述の図６参照）に問い合わせる５０２。より具体的には処理フローＢにおいて、そのメッセージの読込みもしくは書込みの対象であるファイルの排他管理権をクライアント１０６のいずれかが持っている場合にのみ、メッセージをキャッシュから返せると結果が返される。問い合わせの結果、キャッシュから返せるか否か判断５０３し、判断の結果キャッシュから返せないのであれば５０１で入力したリクエストメッセージをキャッシュ制御部１１９内のバッファに一時保存５０８し、リクエストメッセージをそのままＷＡＮ側ＮＩＦのＯＵＴ２０４に送り５０４、処理を終了５０５する。判断５０３でキャッシュから返せる場合は、続いて属性取得メッセージかの判断５０６を行う。ここでは使用するファイル共有プロトコルに関する知識として、属性取得メッセージの一覧を事前にシステム設計者や管理者が登録しておくものとする。背景技術に上げた例では、属性取得メッセージとは「ＱＵＥＲＹ＿ＰＡＴＨ＿ＩＮＦＯＲＭＡＴＩＯＮ１」「ＱＵＥＲＹ＿ＰＡＴＨ＿ＩＮＦＯＲＭＡＴＩＯＮ２」「ＱＵＥＲＹ＿ＰＡＴＨ＿ＩＮＦＯＲＭＡＴＩＯＮ３」「ＱＵＥＲＹ＿ＰＡＴＨ＿ＩＮＦＯＲＭＡＴＩＯＮ４」である。判断５０６の結果、属性取得メッセージでなければ、該属性取得メッセージの対象となるファイルに関するリクエストとレスポンスの対をキャッシュ１２２から削除５０７する。その後、リクエストメッセージをキャッシュ制御部１１９内のバッファに一時保存５０８し、リクエストメッセージをそのままＷＡＮ側ＮＩＦのＯＵＴ２０４に送り５０４、処理を終了５０５する。判断５０６の結果、属性取得メッセージであれば、続いてキャッシュ１２２に（第１のデータのファイル名に従い）該属性取得メッセージの対象となるファイルに関するエントリがあるか否か判断５０９する。判断５０９の結果エントリがなければリクエストメッセージをキャッシュ制御部１１９内のバッファに一時保存５０８し、処理を終え５０５、５０１で入力したメッセージはそのままＷＡＮ側ＮＩＦのＯＵＴ２０４に送る。判断５０９の結果エントリがあれば、キャッシュからレスポンスを作成し、ＬＡＮ側ＮＩＦの出力（ＯＵＴ）２０２に返し、処理を終える５０５。

　なお、キャッシュ制御部は、手順５０７や判断５０９および手順５１０においてキャッシュの探索を行う。ここではキャッシュのエントリをファイルの絶対パスで管理する。手順５０１にて入力されたメッセージがファイルの絶対パスではなくＦＩＤを用いていた場合には、後述のとおり手順５０２にて排他管理部の処理フローＢに問い合わせた際に、併せてＦＩＤに対応するファイル名を入手する。

　図６に、本実施の形態の排他管理部の処理フローＢを示す。
　図６に示した排他管理部の処理フローＢでは、キャッシュ制御部１１９からメッセージを入力６０１したら、そのメッセージがＦＩＤを使用しているか否か判断６０２する。判断６０２の結果ＦＩＤを使用していた場合はＦＩＤ　ＤＢ１２１を探索し、ＦＩＤをファイルの絶対パスに変換６０６する。続いて排他状態管理ＤＢに入力６０２に相当するファイルのエントリがあるか否か判断６０３する。判断６０３の結果エントリがあればキャッシュ制御部１１９に対しキャッシュから返せると返し６０７、判断６０３の結果エントリがなければキャッシュ制御部１１９に対しキャッシュから返せないと返す６０４。その後処理を終える６０５。

　以上がＬＡＮ側ＮＩＦのＩＮ２０１からの入力に対する動作である。

（サーバ１０７からクライアント１０６へのメッセージ）
　続いてＷＡＮ側ＮＩＦのＩＮ２０４からの入力に対する動作を記す。

　図７に、本実施の形態のキャッシュ制御部の処理フローＢを示す。
　ＷＡＮ側ＮＩＦのＩＮ２０４から入ったサーバ１０７からクライアント１０６へのメッセージはキャッシュ制御部１１９の処理フローＢ（図７）に渡される。図７に示したキャッシュ制御部の処理フローＢでは、まずサーバ１０７からのメッセージを入力７０１した後に、入力したメッセージがキャッシュ制御部の処理フローＡ（図５）の手順５０８においてキャッシュ制御部１１９内のバッファに一時保存したリクエストに対するレスポンスか否か判断７０２する。なお、先に記した通り、ここで想定するファイル共有プロトコルは、あるリクエストに対するレスポンスには同じ識別子が振ってあり、あるリクエストに対するレスポンスを容易に識別できる。判断７０２においてバッファしたリクエストに対するレスポンスではないと判断した場合は、メッセージを排他状態監視部の処理フロー（図３）に渡し７０３、ＬＡＮ側ＮＩＦのＯＵＴ２０２にメッセージを渡し７０４、処理を終える７０５。判断７０２においてバッファしたリクエストに対するレスポンスであると判断した場合は、リクエストとレスポンスの対をキャッシュ（第２のデータ）にエントリとして追加７０６し、その後メッセージを排他状態監視部の処理フロー（図３）に渡し７０３、ＬＡＮ側ＮＩＦのＯＵＴ２０２にメッセージを渡し７０４、処理を終える７０５。

　手順７０３からメッセージを受け取った排他状態監視部の処理フロー（図３）では、ＬＡＮ側ＮＩＦのＩＮ２０１からの入力に対する動作と同じく必要に応じて排他管理部の処理フローＡ（図４）を呼び出す３０３。
　排他管理部の処理フローＡ（図４）の判断４０２において、サーバからのレスポンスであると判断された場合は手順４０３にて排他管理部１１８内のバッファに一時保存したリクエストとメッセージ識別子を用いて突き合わせる４０５。ここでメッセージ識別子を用いて突き合わせることで、ＯＰＥＮの場合はクライアントが排他制御権を取ったファイルの絶対パスとＦＩＤを、またＣＬＯＳＥの場合はクライアントが排他制御権を解放したファイルのＦＩＤを取得できる。その後、メッセージがＯＰＥＮか否か判断４０６する。判断４０６の結果、メッセージがＯＰＥＮであれば排他状態管理ＤＢ１２０とＦＩＤ　ＤＢ１２１に、取得した絶対パスとＦＩＤを用いて、エントリを挿入する。判断４０６の結果、メッセージがＣＬＯＳＥであれば、取得したＦＩＤを用いて、ＦＩＤ　ＤＢからエントリを取得する。ここでファイルの絶対パスを知ることができる。そのＦＩＤとファイルの絶対パスを用いて、排他状態管理ＤＢとＦＩＤ　ＤＢから該当するエントリを削除する４０８。
　なお、ＷＡＮ側ＮＩＦのＩＮ２０４から入ったサーバ１０７からクライアント１０６へのメッセージにおいても、サーバからのリクエストである場合があるため、判断４０２にて全てのメッセージがＹと判断されるわけではない。

　以上がＷＡＮ側ＩＦのＩＮ２０４からの入力に対する動作である。

　図１１は、複数クライアントが同じファイルに読込みアクセスする場合のメッセージシーケンスを示す。
　上記動作を行う通信装置１０４を事業拠点１０１のＷＡＮ側出口に設置することで、全ての又は複数のクライアント１０６からのＷＡＮ１０３を介したＤＣ１０２内のファイルサーバ１０７へのアクセスが高速化される。高速化の具体例を、図１１を用いて説明する。図１１は図１２と同じく、同一の通信装置に接続されたクライアントＡおよびクライアントＢが同じファイルに読込みアクセスする場合のメッセージシーケンスを表している。
　まずクライアントＡが属性取得リクエスト１４０１を送信する。このとき、属性取得リクエスト１４０１が通信装置を通る１４０２際に、図２のＬＡＮ側ＮＩＦのＩＮ２０１から入り、排他状態監視部１１７の処理フロー３０１に入力され、該リクエストは排他制御に関わらないと判断３０２され、処理を終了する。一方で該リクエスト１４０１はキャッシュ制御部１１９の処理フローＡ５０１にも入力され、排他管理部の処理フローＢ６０１に問い合わせられる５０２。排他管理部の処理フローＢでは、該リクエスト１４０１はまだＦＩＤが発行されていないため判断６０２においてＦＩＤを使用していないと判断され、続いて先に排他状態監視部１１７の処理フロー３０１にて該メッセージは排他制御に関わらないと判断３０２されているため、排他状態管理ＤＢにエントリがないと判断６０３され、キャッシュから返せないと結果を返す６０４。その結果、判断５０３はキャッシュから返せない事になり、属性取得リクエストのメッセージをキャッシュ制御部１１９内のバッファに一時保存５０８し、メッセージをＷＡＮ側ＮＩＦのＯＵＴに送り５０４処理を終える。

　次に属性取得リクエスト１４０１のレスポンス１４０３がサーバより返信される。このとき、属性取得レスポンス１４０３が通信装置を通る１４０４際に、図２のＷＡＮ側ＮＩＦのＩＮ２０４から入り、キャッシュ制御部１１９の処理フローＢ７０１に入力され、バッファしたリクエストに対するレスポンスである７０２ため、メッセージ識別子に対するリクエストとレスポンスの対をキャッシュに追加７０６し、排他状態監視部１１７の処理フロー３０１に渡す。排他状態監視部１１７の処理フロー３０１では該レスポンス１４０３は排他制御に関わらないと判断３０２され、排他状態監視部１１７は処理を終える３０４。その後、キャッシュ制御部１１９は該レスポンス１４０３をＬＡＮ側ＮＩＦのＯＵＴに送り７０４、処理を終える。

　次にクライアントＡがＯＰＥＮリクエスト１４０５を送信する。このときＯＰＥＮリクエスト１４０５が通信装置を通る１４０６際に、図２のＬＡＮ側ＮＩＦのＩＮ２０１から入り、排他状態監視部１１７の処理フロー３０１に入力され、該リクエストは排他制御に関わると判断３０２され、排他管理部の処理フローＡを呼び出す３０３。排他管理部の処理フローＡ４０１では、該リクエスト１４０５はクライアントからのリクエストであると判断され４０２、該リクエスト１４０５を排他管理部１１８内のバッファに一時保存４０３し、処理を終える４０４。一方で該リクエスト１４０５はキャッシュ制御部１１９の処理フローＡ５０１にも入力され、排他管理部の処理フローＢ６０１に問い合わせられる５０２。排他管理部の処理フローＢでは、該リクエスト１４０５はまだＦＩＤが発行されていないため判断６０２においてＦＩＤを使用していないと判断され、続いて先に排他管理部の処理フローＡにてリクエストをバッファした４０３だけなので排他状態管理ＤＢにエントリはなく６０３、キャッシュから返せないと結果を返す６０４。その結果、判断５０３はキャッシュから返せない事になり、ＯＰＥＮリクエストのメッセージをキャッシュ制御部１１９内のバッファに一時保存５０８し、メッセージをＷＡＮ側ＮＩＦのＯＵＴに送り５０４処理を終える。

　次にＯＰＥＮリクエストのレスポンス１４０７がサーバより返信される。このとき、ＯＰＥＮレスポンス１４０７が通信装置を通る１４０８際に、図２のＷＡＮ側ＮＩＦのＩＮ２０４から入り、キャッシュ制御部１１９の処理フローＢ７０１に入力され、バッファしたリクエストに対するレスポンスである７０２ため、メッセージ識別子に対するリクエストとレスポンスの対をキャッシュに追加７０６し、排他状態監視部１１７の処理フロー３０１に渡す。排他状態監視部１１７の処理フロー３０１では該レスポンス１４０７は排他制御に関わると判断３０２され、排他管理部の処理フローＡを呼び出す３０３。排他管理部の処理フローＡ４０１では、該レスポンス１４０３はサーバからのレスポンスであると判断され４０２、先に手順４０３でバッファしたＯＰＥＮリクエスト１４０５と突き合わされ４０５、ＯＰＥＮリクエストに対するレスポンスであると判断され４０６、排他状態管理ＤＢとＦＩＤ　ＤＢにエントリが挿入４０９される。その後、ＯＰＥＮレスポンス１４０７をＬＡＮ側ＮＩＦのＯＵＴに送り７０４、処理を終える。
　この時点で該ファイルに関するエントリが排他状態管理ＤＢとＦＩＤ　ＤＢにあるため、これ以降はキャッシュから返せるようになる。

　続いてクライアントＢが該ファイルの属性取得リクエスト１４０９を送信する。このとき、属性取得リクエスト１４０９が通信装置を通る１４０２際に、図２のＬＡＮ側ＮＩＦのＩＮ２０１から入り、排他状態監視部１１７の処理フロー３０１に入力され、該リクエストは排他制御に関わらないと判断３０２され、処理を終了する。一方で該リクエスト１４０９はキャッシュ制御部１１９の処理フローＡ５０１にも入力され、排他管理部の処理フローＢ６０１に問い合わせられる５０２。排他管理部の処理フローＢでは、該リクエスト１４０９はまだＦＩＤが発行されていないため判断６０２においてＦＩＤを使用していないと判断され、続いて排他状態管理ＤＢにエントリがあると判断６０３され、レスポンスをキャッシュから返せると結果を返す６０７。その結果、判断５０３はキャッシュから返せる事になり、続いて属性取得メッセージであると判断され５０６、属性取得リクエスト１４０１およびレスポンス１４０４の対がキャッシュされているためキャッシュがあると判断され５０９、キャッシュからレスポンスが返される５１０。
　このように、一貫性制御が不要な期間のみ属性取得リクエストへのレスポンスをキャッシュから返すことで、一貫性制御に関わるメッセージのやり取りを行わなくて済む。

　上述の実施例では、重複した属性取得を行わずに済むよう、属性取得メッセージに対するレスポンスをキャッシュする場合は、一貫性制御が不要な期間のみ属性情報をキャッシュする。単純にキャッシュしてしまうと一貫性制御のためのメッセージ交換が発生後、キャッシュされているレスポンスが無駄になるのを防ぐ。
　具体的にはクライアント―サーバ間のメッセージやり取りを監視し、配下のクライアントが排他制御権を有するファイルに関する属性情報をキャッシュする。例えば、先に例示したファイルサーバ上のファイルＡをクライアントにコピーする場合のメッセージでは、＃５に対する受理（レスポンス）がサーバからクライアントに返った時点で「他のユーザもファイルＡを読む（Ｒｅａｄ）ことはできるが、書いたり（Ｗｒｉｔｅ）消したり（Ｄｅｌｅｔｅ）することはできない」事を意味するシェアードという排他制御権が発生する。そのため、高速化装置等の通信装置で＃１～＃４や＃６および＃７から＃ｙを安全にキャッシュすることができる。
　上述の実施例では、ＷＡＮ高速化装置等を用いて説明したが、ＬＡＮ等の有線ネットワークや無線ネットワークを含む様々なネットワークにおける通信装置に適用することができる。

１０４　通信装置
１１１　ＣＰＵ
１１２　主記憶部
１１３　二次記憶部
１１４　ＬＡＮ側ＮＩＦ（Ｎｅｔｗｏｒｋ　ＩｎｔｅｒＦａｃｅ）
１１５　ＷＡＮ側ＮＩＦ
１１６　制御部
１１７　排他状態監視部
１１８　排他管理部
１１９　キャッシュ制御部
１２０　排他状態管理ＤＢ（データベース、Ｄａｔａ　Ｂａｓｅ）
１２１　ＦＩＤ　ＤＢ
１２２　キャッシュ
１２３　プログラム

Claims

　クライアントとサーバとの間に設けられた通信装置を備え、前記クライアントが前記サーバのファイルにアクセスするための通信システムにおいて、
　前記通信装置は、第１のクライアントから属性取得リクエストを受信すると、第１のデータベース（ＤＢ）に該属性取得リクエストの対象となるファイルのエントリがなければレスポンスをキャッシュから返せないと判断し、該属性取得リクエストをメッセージ識別子とともに第１バッファに一時保存し、該属性取得リクエストをサーバ側に送り、
　前記通信装置は、前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の属性取得リクエストに対する属性取得レスポンスであると判断すると、属性取得リクエストと属性取得レスポンスの対を前記キャッシュに追加し、該属性取得レスポンスを前記第１のクライアントに送り、
　前記通信装置は、前記第１のクライアントから排他制御に関わる排他制御リクエスト受信すると、第２のバッファに一時保存し、前記第１のＤＢに該排他制御リクエストの対象となるファイルのエントリがなければレスポンスを前記キャッシュから返せないと判断し、該排他制御リクエストを前記第１バッファに一時保存し、該排他制御リクエストを前記サーバ側に送り、
　前記通信装置は、前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の前記排他制御リクエストに対する排他制御レスポンスであると判断すると、該排他制御リクエストと該排他制御レスポンスの対を前記キャッシュに追加し、前記第２バッファ内の該排他制御リクエストと照合し、該排他制御リクエストに対するレスポンスである場合は前記第１のＤＢに前記排他制御リクエストの対象となるファイルのエントリを挿入し、該排他制御レスポンスを前記第１のクライアントに送り、
　前記通信装置は、第２のクライアントから属性取得リクエストを受信すると、前記第１のＤＢに該属性取得リクエストの対象となるファイルのエントリがあればレスポンスを前記キャッシュから返せると判断し、既に属性取得リクエストおよびレスポンスの対が前記キャッシュにキャッシュされていると判断し、前記キャッシュから前記属性取得レスポンスを返す
通信システム。
　請求項１に記載の通信システムにおいて、
　前記第１のＤＢは、排他状態を管理するためのファイル名を含む情報を記憶し、
　前記キャッシュは、メッセージ識別子に対してリクエストとレスポンスの対を記憶し、
　前記通信装置は、
　前記第１のバッファを有し、前記キャッシュにアクセスし、キャッシュ制御を実行するためのキャッシュ制御部と
　前記第２のバッファを有し、前記第１のＤＢにアクセスし、排他制御を実行するための排他管理部と、
を備えたことを特徴とする通信システム。
　請求項２に記載の通信システムにおいて、
　前記排他管理部は、
　クライアントからの排他制御に関わるメッセージが入力された場合、
　前記メッセージがリクエストメッセージであるときは、該リクエストメッセージを前記第２のバッファに一時保存する
ことを特徴とする通信システム。
　請求項２又は３に記載の通信システムにおいて、
　前記キャッシュ制御部は、
　クライアントからのメッセージが入力されたら、
　レスポンスを前記キャッシュから返せない場合、入力したリクエストメッセージを、前記キャッシュ制御部内の前記第１のバッファに一時保存し、前記サーバ側に送り、
　レスポンスを前記キャッシュから返せる場合は、属性取得リクエストか否かの判断を行い、
　属性取得リクエストでなければ、リクエストメッセージを前記キャッシュ制御部内の前記第１のバッファに一時保存し、リクエストメッセージを前記サーバ側に送り、
　一方、属性取得リクエストであれば、前記キャッシュに該属性取得リクエストの対象となるファイルのエントリがあるか否か判断し、
　エントリがなければ、リクエストメッセージを前記キャッシュ制御部内の前記第１のバッファに一時保存して前記サーバ側に送り、一方、エントリがあれば、前記キャッシュからレスポンスを作成してクライアント側に返す
ことを特徴とする通信システム。
　請求項２乃至４のいずれかに記載の通信システムにおいて、
　前記排他管理部は、
　前記キャッシュ制御部から、レスポンスを前記キャッシュから返せるか問い合わせを入力したら、前記第１のＤＢに該入力に相当するファイルのエントリがあれば前記キャッシュ制御部に対し前記キャッシュから返せると応答し、一方、エントリがなければ前記キャッシュ制御部に対し前記キャッシュから返せないと応答することを特徴とする通信システム。
　請求項２乃至５のいずれかに記載の通信システムにおいて、
前記キャッシュ制御部は、
　前記サーバからのメッセージを入力すると、メッセージ識別子に基づき、入力したメッセージが前記キャッシュ制御部内の前記第１のバッファに一時保存したリクエストに対するレスポンスか否か判断し、
　前記第１のバッファに一時保存したリクエストに対するレスポンスではないと判断した場合は、メッセージをクライアント側に渡し、
　一方、前記第１のバッファに一時保存したリクエストに対するレスポンスであると判断した場合は、メッセージ識別子に対するリクエストとレスポンスの対を前記キャッシュにエントリとして追加し、メッセージをクライアント側に渡す
ことを特徴とする通信システム。
　請求項２乃至６のいずれかに記載の通信システムにおいて、
　前記排他管理部は、
　前記サーバからのメッセージが排他制御に関わるレスポンスのメッセージである場合、
　前記排他管理部内の第２のバッファに一時保存したリクエストとメッセージ識別子を用いて突き合わせ、ファイルの絶対パス及び／又はファイル識別子を取得し、
　前記メッセージがＯＰＥＮ又は他の第１の排他制御に関するメッセージか否か判断し、
　メッセージがＯＰＥＮ又は他の第１の排他制御に関するメッセージであれば、前記第１のＤＢにファイル名を含むエントリを挿入し、
　一方、メッセージがＣＬＯＳＥ又は他の第２の排他制御に関するメッセージであれば、前記第１のＤＢから該当するファイル名のエントリを削除する
ことを特徴とする通信システム。
　クライアントとサーバとの間に設けられた通信装置を備え、前記クライアントが前記サーバのファイルにアクセスするための通信システムにおける前記通信装置であって、
　第１のクライアントから属性取得リクエストを受信すると、第１のデータベース（ＤＢ）に該属性取得リクエストの対象となるファイルのエントリがなければレスポンスをキャッシュから返せないと判断し、該属性取得リクエストをメッセージ識別子とともに第１バッファに一時保存し、該属性取得リクエストをサーバ側に送り、
　前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の属性取得リクエストに対する属性取得レスポンスであると判断すると、属性取得リクエストと属性取得レスポンスの対を前記キャッシュに追加し、該属性取得レスポンスを前記第１のクライアントに送り、
　前記第１のクライアントから排他制御に関わる排他制御リクエスト受信すると、第２のバッファに一時保存し、前記第１のＤＢに該排他制御リクエストの対象となるファイルのエントリがなければレスポンスを前記キャッシュから返せないと判断し、該排他制御リクエストを前記第１バッファに一時保存し、該排他制御リクエストを前記サーバ側に送り、
　前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の前記排他制御リクエストに対する排他制御レスポンスであると判断すると、該排他制御リクエストと該排他制御レスポンスの対を前記キャッシュに追加し、前記第２バッファ内の該排他制御リクエストと照合し、該排他制御リクエストに対するレスポンスである場合は前記第１のＤＢに前記排他制御リクエストの対象となるファイルのエントリを挿入し、該排他制御レスポンスを前記第１のクライアントに送り、
　第２のクライアントから属性取得リクエストを受信すると、前記第１のＤＢに該属性取得リクエストの対象となるファイルのエントリがあればレスポンスを前記キャッシュから返せると判断し、既に属性取得リクエストおよびレスポンスの対が前記キャッシュにキャッシュされていると判断し、前記キャッシュから前記属性取得レスポンスを返す
通信装置。
　請求項８に記載の通信装置において、
　前記第１のＤＢは、排他状態を管理するためのファイル名を含む情報を記憶し、
　前記キャッシュは、メッセージ識別子に対してリクエストとレスポンスの対を記憶し、
　前記通信装置は、
　前記第１のバッファを有し、前記キャッシュにアクセスし、キャッシュ制御を実行するためのキャッシュ制御部と
　前記第２のバッファを有し、前記第１のＤＢにアクセスし、排他制御を実行するための排他管理部と、
を備えたことを特徴とする通信装置。
　請求項９に記載の通信装置において、
　前記排他管理部は、
　クライアントからの排他制御に関わるメッセージが入力された場合、
　前記メッセージがリクエストメッセージであるときは、該リクエストメッセージを前記第２のバッファに一時保存する
ことを特徴とする通信装置。
　請求項９又は１０に記載の通信装置において、
　前記キャッシュ制御部は、
　クライアントからのメッセージが入力されたら、
　レスポンスを前記キャッシュから返せない場合、入力したリクエストメッセージを、前記キャッシュ制御部内の前記第１のバッファに一時保存し、前記サーバ側に送り、
　レスポンスを前記キャッシュから返せる場合は、属性取得リクエストか否かの判断を行い、
　属性取得リクエストでなければ、リクエストメッセージを前記キャッシュ制御部内の前記第１のバッファに一時保存し、リクエストメッセージを前記サーバ側に送り、
　一方、属性取得リクエストであれば、前記キャッシュに該属性取得リクエストの対象となるファイルのエントリがあるか否か判断し、
　エントリがなければ、リクエストメッセージを前記キャッシュ制御部内の前記第１のバッファに一時保存して前記サーバ側に送り、一方、エントリがあれば、前記キャッシュからレスポンスを作成してクライアント側に返す
ことを特徴とする通信装置。
　請求項９乃至１１のいずれかに記載の通信装置において、
　前記排他管理部は、
　前記キャッシュ制御部から、レスポンスを前記キャッシュから返せるか問い合わせを入力したら、前記第１のＤＢに該入力に相当するファイルのエントリがあれば前記キャッシュ制御部に対し前記キャッシュから返せると応答し、一方、エントリがなければ前記キャッシュ制御部に対し前記キャッシュから返せないと応答することを特徴とする通信装置。
　請求項９乃至１２のいずれかに記載の通信装置において、
前記キャッシュ制御部は、
　前記サーバからのメッセージを入力すると、メッセージ識別子に基づき、入力したメッセージが前記キャッシュ制御部内の前記第１のバッファに一時保存したリクエストに対するレスポンスか否か判断し、
　前記第１のバッファに一時保存したリクエストに対するレスポンスではないと判断した場合は、メッセージをクライアント側に渡し、
　一方、前記第１のバッファに一時保存したリクエストに対するレスポンスであると判断した場合は、メッセージ識別子に対するリクエストとレスポンスの対を前記キャッシュにエントリとして追加し、メッセージをクライアント側に渡す
ことを特徴とする通信装置。
　請求項９乃至１３のいずれかに記載の通信装置において、
　前記排他管理部は、
　前記サーバからのメッセージが排他制御に関わるレスポンスのメッセージである場合、
　前記排他管理部内の第２のバッファに一時保存したリクエストとメッセージ識別子を用いて突き合わせ、ファイルの絶対パス及び／又はファイル識別子を取得し、
　前記メッセージがＯＰＥＮ又は他の第１の排他制御に関するメッセージか否か判断し、
　メッセージがＯＰＥＮ又は他の第１の排他制御に関するメッセージであれば、前記第１のＤＢにファイル名を含むエントリを挿入し、
　一方、メッセージがＣＬＯＳＥ又は他の第２の排他制御に関するメッセージであれば、前記第１のＤＢから該当するファイル名のエントリを削除する
ことを特徴とする通信装置。
　クライアントとサーバとの間に設けられた通信装置を備え、前記クライアントが前記サーバのファイルにアクセスするための通信システムにおける通信制御方法であって、
　第１のクライアントから属性取得リクエストを受信すると、第１のデータベース（ＤＢ）に該属性取得リクエストの対象となるファイルのエントリがなければレスポンスをキャッシュから返せないと判断し、該属性取得リクエストをメッセージ識別子とともに第１バッファに一時保存し、該属性取得リクエストをサーバ側に送り、
　前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の属性取得リクエストに対する属性取得レスポンスであると判断すると、属性取得リクエストと属性取得レスポンスの対を前記キャッシュに追加し、該属性取得レスポンスを前記第１のクライアントに送り、
　前記第１のクライアントから排他制御に関わる排他制御リクエスト受信すると、第２のバッファに一時保存し、前記第１のＤＢに該排他制御リクエストの対象となるファイルのエントリがなければレスポンスを前記キャッシュから返せないと判断し、該排他制御リクエストを前記第１バッファに一時保存し、該排他制御リクエストを前記サーバ側に送り、
　前記サーバからレスポンスを受信し、メッセージ識別子に従い、該レスポンスが前記第１のバッファ中の前記排他制御リクエストに対する排他制御レスポンスであると判断すると、該排他制御リクエストと該排他制御レスポンスの対を前記キャッシュに追加し、前記第２バッファ内の該排他制御リクエストと照合し、該排他制御リクエストに対するレスポンスである場合は前記第１のＤＢに前記排他制御リクエストの対象となるファイルのエントリを挿入し、該排他制御レスポンスを前記第１のクライアントに送り、
　第２のクライアントから属性取得リクエストを受信すると、前記第１のＤＢに該属性取得リクエストの対象となるファイルのエントリがあればレスポンスを前記キャッシュから返せると判断し、既に属性取得リクエストおよびレスポンスの対が前記キャッシュにキャッシュされていると判断し、前記キャッシュから前記属性取得レスポンスを返す
通信制御方法。
　ファイルサーバに接続する通信装置であって、
　前記ファイルサーバから取得したファイルの排他権を管理する排他権管理部と、
　クライアントからの当該ファイルの排他制御に関するリクエストを監視する監視部と、
　監視状況によって、キャッシュヒットしたファイルに関するデータを送信するか制御する送信制御部と、
を有することを特徴とする通信装置。