JP2013218505A - クライアントとサーバ間の通信を中継する通信装置及び通信システム - Google Patents

Abstract

【課題】 従来の予測に基づくアプリケーション高速化手法では、多くのユーザに対して平等にサービスできない。
【解決手段】 多くのユーザに対して平等にサービスを提供できるよう、一度に先読みするデータ量に制限を設ける。また既に先読みしたデータへのアクセス進捗状況を監視し、必要に応じて後続のデータを先読みする。また、全てのＣＩＦＳメッセージのＴＩＤをつけかえ、不整合が生じないようにする。
【選択図】 図１

Description

本発明は、通信装置に関し、特に、クライアントーサーバ間のファイルデータの転送を制御する通信装置に関する。

広域網（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ， ＷＡＮ）を介してデータセンタ（ＤＣ）-拠点間で通信を行う場合に、TCPでの帯域制御を行い、WANの高速化を実現する技術が特許文献１に開示されている。

また、ＴＣＰの上位のレイヤであるアプリケーション層のプロトコルにファイル共有のためのプロトコルとして、ＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）がある。特許文献３では、CIFSプロトコルに従ったファイルサーバとクライアント間の通信する技術が開示されている。

特許文献２では、ネットワーク上でプロクシとして動作し、ユーザからのＣＩＦＳメッセージを予測（特許文献２では”ｐｒｅｄｉｃｔｉｏｎ”と呼ばれている）し、先にＮＡＳにメッセージを送信しレスポンスを受信しておき、高速化を実現するという技術が開示されている。

ＷＯ１１／０３３８９４ 米国特許公開公報番号２００４／０２１５７４６ 特開2004-280283

しかし、ＤＣ-拠点間のＷＡＮを介したＴＣＰ通信が高速化されても、ネットワークストレージ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ，ＮＡＳ）等のファイルサーバを用いたファイル共有は十分に高速化されないという問題がある。特にＮＡＳの主要プロトコルであり、かつＷｉｎｄｏｗｓの標準ファイル共有プロトコルであるＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）は特許文献１の手法と組み合わせても契約帯域の１０％程度しか利用できない。その理由は、ＣＩＦＳは高々６０ＫＢのメッセージを１件ずつ往復させて送受信しているためである。このため特許文献１の手法の効果が得られず、メッセージ１往復ごとにＲＴＴ分の時間がかかる。

また特許文献２の予測に基づく手法では、予測される系列（ルール）が長い場合にはＷＡＮ回線を一クライアントが長時間占有してしまう。また高速化装置内のバッファも一クライアントが長時間占有してしまう。そのため、予測の確度を高めるため「あるファイルのｏｐｅｎをトリガに全データをｒｅａｄする」といったルールを定義すると多くのユーザに対して平等にサービスを提供できない。一方で「あるファイルのｏｐｅｎをトリガに一部のデータをｒｅａｄする」だけでは高速化効果が低い。

したがって、背景技術では、多くのクライアントに対して平等に通信サービスを提供できないという課題がある。また、特許文献２では、予測が外れた場合にユーザからのコマンドを送信すると、処理の識別番号（Ｔｒａｎｓａｃｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）の不整合が生じ、ＮＡＳから通信を切断される。

上記少なくとも一の課題を解決するために、
本発明の一態様では、クライアントとサーバ間における通信装置は、クライアントからのアクセスに対して、先読みするデータ量に制限を設ける。また既に先読みしたデータへのクライアントからのアクセス進捗状況を監視し、監視結果に応じて追加の先読み処理を制御する。

先読みするデータの保持するリソース（バッファ）を効率よく使用することができる。また、先読みするデータのために、通信帯域を占有せずに済む。

実施例１のシーケンス例 実施例１のシステム構成 実施例１のシーケンス例 システムのフローチャート アプリケーション高速化装置の装置構成 入力処理部の処理フロー 出力処理部の処理フロー 出力処理部が管理する表 プリフェッチ処理部の処理フローＡ プリフェッチ処理部の処理フローＢ プリフェッチ処理部の処理フローＣ プリフェッチ処理部の処理フローＤ プリフェッチ処理部の処理フローＥ プリフェッチ処理部の処理フローＦ アクセスパターンとプリフェッチバッファサイズ 実施例２のシステム構成 実施例２のシーケンス例 入力処理部の処理フロー 出力処理部の処理フロー プリフェッチ処理部の処理フローＢ プリフェッチ処理部の処理フローＤ プリフェッチ処理部の処理フローＥ プリフェッチ処理部の処理フローＧ プリフェッチ要求管理テーブルを示す図。 プリフェッチデータ管理テーブルを示す図。 アクセスパタン管理テーブルを示す図。 アクセスパターンの状態遷移例を示す表

以下、実施例を図面を用いて説明する。

図２は、ファイルを利用するクライアントとファイルを管理するファイルサーバとを含む実施例１の全体構成を示す。本実施例で、ファイル共有のための記憶リソースや通信リソースの効率よい利用形態について説明する。また、クライアント計算機へのファイルデータの提供を高速化する。

ここではＷＡＮ２０１を介してクライアント１０１とファイルサーバ１０２が接続されている。

クライアント１０１は、ファイルサーバ１０２と、ネットワークを介して接続され、ファイルサーバが管理するファイルを利用する。クライアント１０１は、例えば計算機や情報処理端末や、またはスマートフォン等の携帯型情報処理端末であって、サーバにあるサーバを利用する、情報処理装置である。

ファイルサーバ１０２は、ファイル入出力制御部５８００と、複数のファイルを格納するストレージ５９００を有する、サーバー等であって、ネットワークを介してデータを提供する情報処理装置である。

ファイル入出力制御部５８００は、クライアント１０１に対して、該当するファイルの識別子を通知したり、ＷＡＮを介したリクエストに応じて、ファイルの部分データをストレージ５９００から読み出し、ＷＡＮに向けて送出する。

ただし、クライアント１０１は、アプリケーション高速化装置１（１０５）とＴＣＰ高速化装置１（１０３）を介してＷＡＮ１０２に接続し、またファイルサーバ１０２はアプリケーション高速化装置２（１０６）とＴＣＰ高速化装置２（１０４）を介してＷＡＮ２０１に接続する。

ＴＣＰ高速化装置１０３および１０４は例えば特許文献１で開示された高速化手法を用いて第４層トランスポート層（Ｌ４）の高速化機能を提供する。

TCP高速化装置は、ＷＡＮ帯域制御装置であってもよい。例えば、TCP高速化装置アプリケーション高速化装置１０５による先読み要求をＷＡＮの通信帯域を送信するための送信制御を行う。例えば、ＷＡＮ帯域制御装置１０３は、ＯＳＩ（Open Systems Interconnection）参照モデルで規定されるＬａｙｅｒ４のＴＣＰ（Transmission Control Protocol）に従い、ＷＡＮ上でのパケットの廃棄状況や再送発生状況によって送信する帯域を設定し、先読み要求を設定された帯域で送信する。また、ＷＡＮ帯域制御装置は、設定された帯域が、あらかじめ定められた上限の帯域内にあるかを判定し、判定結果、帯域内である場合に、先読み要求などのパケットを送信する遵守判定を行ってもよい。また、ＷＡＮ帯域制御装置間は、ＴＣＰに従って、データ通信を行う。パケットには、ファイルの識別子やファイルのデータ、サーバへのファイルの処理を制御するコマンド、または、クライアント側でファイルに関する処理を制御するコマンドが含まれる。

アプリケーション高速化装置は、ＯＳＩで規定される第５層から第７層までを担当し、たとえば、第７層アプリケーション層（Ｌ７）アプリケーションであるＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）を高速化するための制御を行う。なお、アプリケーション層は、TCP/IP参照モデルにおける4階層の内の第4層でもある。TCP/IP参照モデルでのアプリケーション層は、OSI参照モデルのアプリケーション層、プレゼンテーション層、およびセッション層に対応する。

例えば、アプリケーション高速化装置１０５は、クライアント１０１からファイルへアクセスするため取得要求を受信した場合に、ファイルサーバに対してファイルのデータの先読みをＷＡＮを介して実行する通信装置である。アプリケーション高速化装置１０５は、プリフェッチバッファを備え、ＷＡＮを介して先読みにより取得したデータをバッファに保持し、その後のクライアントからのリクエストに対し、保持されている先読みデータをプリフェッチバッファから返す。また、アプリケーション高速化装置１０５は、クライアント１０１からファイルへのアクセス状況、例えば、クライアントからのファイルのリード要求に該当する先読み要求の有無や、先読みデータのクライアントへの送信状況に応じて、先読み量、先読み位置を決定し、ファイルサーバ１０２に対して、さらにファイルデータの先読みを行い、先読みされたデータをプリフェッチバッファに保持する。

アプリケーション高速化装置１０５は、クライアント側、サーバ側双方ではなく、ファイルサーバー１０２側あるいはクライアント側いずれか一方（実施例２で後述）にあってもよい。この場合は、ファイルサーバー１０２側の場合は、アプリケーション高速化装置１０５は、ＷＡＮ２０１とファイルサーバ１０２との間に設けられる。

なお、アプリケーション高速化装置１０５とTCP高速化装置１０３は、別々の装置ではなく、一つの通信システムであってもよい。例えば、通信システムは、アプリケーション高速化装置１０５とTCP高速化装置１０３にそれぞれに対応する処理部とＬＡＮ送受信部とＷＡＮ送受信部とを有し、それぞれがＢＵＳなどの信号線や内部スイッチで接続される。ＬＡＮ送受信部は、クライアントとネットワークを介してリクエストの受信やデータを送信すると、先読み要求をファイルサーバ１０２に向けてＷＡＮに送出する。または、ＷＡＮ送受信部は、ファイルサーバ１０２から、ファイルの識別子やファイルのデータ、クライアント側でファイルに関する処理を制御するコマンドをＷＡＮから受信する。つまり、通信システムは、局所ネットワーク（ＬＡＮ）を介して複数のクライアント１０１と接続し、広域エリアネットワーク（ＷＡＮ）を介してファイルサーバ１０２と接続し、クライアント１０１とファイルサーバ１０２とのデータ通信の中継、データ通信帯域を制御する。また、通信システムは、ファイルサーバから取得する先読みデータをバッファに保持し、クライアントからのリード要求に応じたバッファから読み出し制御、さらなる先読みリクエストによりファイルデータの取得を行う。また、通信システムは、ＬＡＮのゲートウエイ装置であってもよい。

図２によると、アプリケーション高速化装置１０５により、Ｌａｙｅｒ５−７に基づいて、クライアントからのリクエストに対するレスポンスの高速化を実現し、ＴＣＰ高速化装置１０３により、Ｌａｙｅｒ４におけるＷＡＮ帯域の高速化を実現する。

以上が、アプリケーション高速化装置の構成例である。

図１は、実施例１のシーケンスの一例である。図１では、クライアント１０１側、ファイルサーバ１０２側に、アプリケーション高速化装置１（１０５），２（１０６）を備える。また、アプリケーション高速化装置の通信を高速化するために、ＷＡＮの通信帯域を制御するＴＣＰ高速化装置がＷＡＮの複数拠点に備えられる。

まずクライアント１０１からのＴＩＤ＝１のｏｐｅｎコマンド１１１が各装置１０５，１０３，１０４，１０６を経由しファイルサーバ１０２に到達する。ここでＴＩＤとは処理の識別番号（Ｔｒａｎｓａｃｔｉｏｎ ＩＤｅｎｔｉｆｉｅｒ）の略であり、同一セッション内ではＴＩＤによってリクエストを一意に識別可能であるとする。ただし、セッションとはあるユーザがログインしてからログアウトするまでの、あるクライアント１０１の一連のメッセージのやり取りの事とし、コマンドがどのセッションに属するかはセッションＩＤから容易に識別可能とする。また、ここではあるリクエストコマンドに対するレスポンスコマンドには同じＴＩＤをつけ、かつリクエストとレスポンスはフォーマットから容易に識別可能とする。さらに、特にＣＩＦＳを実装した一部のファイルサーバでは、ＴＩＤは単に一意に識別可能なだけではなく、前後のリクエストあるいはレスポンス、それらの組み合わせの関係を特定する通し番号である事が要求される。そのため、クライアント１０１側、ファイルサーバ１０２側それぞれでＴＩＤの不整合を起こさないために、アプリケーション高速化装置１（１０５）および２（１０６）がそれぞれＴＩＤを振り直し、個別に管理する。個別管理の具体例は後に記す。

また、ここでｏｐｅｎコマンドとは引数で指定したファイルを利用可能にするためのコマンドである。ｏｐｅｎコマンド１１１の場合は、引数で指定した“／ｆｏｏ／ｂａｒ．ｔｘｔ”が利用可能対象である。特にＣＩＦＳでは“ＳＭＢ２＿ＣＲＥＡＴＥ”コマンドがｏｐｅｎコマンドである。また、一部のファイル共有プロトコルでは、ｏｐｅｎコマンドの引数において排他制御の要求も行う。ｏｐｅｎコマンド１１１の場合は引数で指定した“ｘ（ｅｘｃｌｕｓｉｖｅ）”で排他制御権を要求している。特にＣＩＦＳでは“ＲｅｑｕｅｓｔｅｄＯｐｌｏｃｋＬｅｖｅｌ”という引数において排他制御の要求を行う。

ファイルサーバ１０２はｏｐｅｎコマンド１１１へのレスポンス１１２を返す。ｏｐｅｎコマンドのレスポンスはｏｐｅｎコマンドの引数で指定されたファイルの識別子（Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ、ＦＩＤ）を含む。以降、ファイルサーバ１０２に対してｏｐｅｎコマンドの引数で指定したファイルの読み込み命令（ｒｅａｄコマンド）や書込み命令（ｗｒｉｔｅコマンド）を出す時にはファイル名“／ｆｏｏ／ｂａｒ．ｔｘｔ”ではなく、ＦＩＤであるＡを引数にする。また、一部のファイル共有プロトコルでは、排他制御権の取得結果も返される。

なお、レスポンス１１２には、ファイルサーバに格納されるファイルの排他制御権の取得結果が含まれていてもよい。例えば、ファイル共有プロトコルの一つであるＣＩＦＳでは“ＯｐｌｏｃｋＬｅｖｅｌ”という引数において排他制御権の取得結果を返す。この取得結果は“ＳＭＢ２＿ＯＰＬＯＣＫ＿ＬＥＶＥＬ＿ＮＯＮＥ”、“ＳＭＢ２＿ＯＰＬＯＣＫ＿ＬＥＶＥＬ＿ＩＩ”“ＳＭＢ２＿ＯＰＬＯＣＫ＿ＬＥＶＥＬ＿ＥＸＣＬＵＳＩＶＥ”、“ＳＭＢ２＿ＯＰＬＯＣＫ＿ＬＥＶＥＬ＿ＢＡＴＣＨ”、“ＳＭＢ２＿ＯＰＬＯＣＫ＿ＬＥＶＥＬ＿ＬＥＡＳＥ”という値を取り、“ＳＭＢ２＿ＯＰＬＯＣＫ＿ＬＥＶＥＬ＿ＮＯＮＥ”以外の値であれば排他制御権が取れている。ｏｐｅｎコマンドのレスポンス１１２は、まずアプリケーション高速化装置２（１０６）に渡る（１１３）。このとき、アプリケーション高速化装置２（１０６）はｏｐｅｎコマンドのレスポンス１１２に含まれる排他制御権の取得結果を調べ、排他制御権が取れていればＦＩＤや、その他認証情報などファイルサーバ１０２との通信に必要な情報も併せて読込む。その後、ｏｐｅｎコマンドのレスポンス１１２は各装置１０４，１０３，１０５を経由しクライアント１０１に到達する。

一方でアプリケーション高速化装置２（１０６）は、レスポンス（１１３）で取得したＦＩＤを用いてファイルのプリフェッチを行う。具体的には、アプリケーション高速化装置２（１０６）は、ファイルサーバ（１０２）に対しｒｅａｄコマンドを送信１２１する。ｒｅａｄコマンドはＦＩＤ，読込みオフセット、読込み長の３つの引数を取る。シーケンス１２１において送信したｒｅａｄコマンドはＦＩＤがＡ（すなわち“／ｆｏｏ／ｂａｒ．ｔｘｔ”）であり、読込みオフセットが０（すなわちファイルの先頭から読込む）、読込み長が１０００である。

次に、アプリケーション高速化装置２（１０６）はファイルサーバ１０２からシーケンス１２１において送信したｒｅａｄコマンドのレスポンス（１２２）を受け取る。ここで受け取るレスポンス１２２には“／ｆｏｏ／ｂａｒ．ｔｘｔ”のデータ実体が含まれている。

続いてアプリケーション高速化装置２（１０６）は、送信したコマンド１２１と受け取ったレスポンス１２２の関係が判るように二つをペアにし、ＴＣＰ高速化装置１０４および１０３を介してアプリケーション高速化装置１（１０５）へ送信（１２３）する。

これを受信したアプリケーション高速化装置１（１０５）は、アプリケーション高速化装置２（１０６）は送信したコマンド１２１と受け取ったレスポンス１２２に分割し、ＦＩＤ＝Ａのオフセット＝０から１０００のデータである事が判るようにバッファに格納しておく。以後、同様にアプリケーション高速化装置２（１０６）はプリフェッチバッファサイズに達するまでプリフェッチ（１２５）を行い、その結果をアプリケーション高速化装置１（１０５）に渡す１２６。図１の例ではプリフェッチバッファサイズは、４０００である。プリフェッチバッファサイズの詳細は後に記す。

プリフェッチとは別に、クライアント１０１もｏｐｅｎコマンド１１１へのレスポンス１１２を受信した後にＦＩＤがＡのファイルに対するｒｅａｄを行う。ここではまず読込みオフセットが０、読込み長が５００のｒｅａｄコマンド（１３１）をファイルサーバ１０２に向けて送信する。ファイルサーバ１０２への経路上のアプリケーション高速化装置１（１０５）が、このｒｅａｄコマンド（１３１）を受領すると、ファイルサーバ１０２自らのプリフェッチバッファからコマンドに対する処理結果を返す。続いて読込みオフセットが５００、読込み長が５００のｒｅａｄコマンド（１３２）を送信しても同じくアプリケーション高速化装置１（１０５）がプリフェッチバッファから結果を返す。

続いて読込みオフセットが１０００、読込み長が１０００のｒｅａｄコマンドを送信１３３しても同じくアプリケーション高速化装置１（１０５）がプリフェッチバッファから結果を返すが、この時プリフェッチバッファの半分（２０００）のデータを読んだため、アプリケーション高速化装置１のプリフェッチバッファ管理の閾値に達する（１３４）。そこで、アプリケーション高速化装置１（１０５）は、アプリケーション高速化装置２（１０６）に追加先読み依頼（１３５）をし、プリフェッチバッファサイズのデータをプリフェッチする（１３６）。なお、ここでは閾値を５０％（半分）としたが、閾値はユーザ定義もしくはシステム定義の任意の値とする。 ところで、この時点でクライアント１０１側のＴＩＤは４（１３３）であり、一方ファイルサーバ（１０２）側のＴＩＤは６（１３６）である。これは先に書いた通りアプリケーション高速化装置１（１０５）および２（１０６）がそれぞれＴＩＤを振り直し、個別に管理しているためである。

ファイルサーバ側１０２のアプリケーション高速化装置２（１０６）が、openコマンド（１１１）に対するレスポンスを契機に、ファイルサーバ１０２に対してファイルＡのうち、所定量のデータの先読みを複数回分けて行い、複数回にわたって得られたデータを、アプリケーション高速化装置１（１０５）に転送する。アプリケーション高速化装置は、転送されたデータをバッファに保持し、クライアント１０１のreadコマンド(１３１)に対してデータを返答する。そして、クライアント１０１側のアプリケーション高速化装置１（１０５）は、バッファに保持されるデータに対して、クライアントからのread（131,132,133）が、閾値を超えたばあいは、さらに、ファイルサーバ（１０２）側のアプリケーション高速化装置２（１０６）は、追加先読み依頼（１３５）を、ファイルサーバ（１０２）に対して行う。

このように、本発明では、あるファイルのプリフェッチをエンドユーザの読込みに合わせて少しずつ取りに行くことで、特定クライアントに関するプリフェッチが回線を占有しないようにする。また、あるファイルのプリフェッチをクライアントのデータ取得リクエストに合わせて少しずつ取りに行くことで、クライアントがデータ取得をやめた場合や余分なデータをプリフェッチせずに、済む。あるファイルのプリフェッチを、クライアントのデータ取得リクエストに合わせて、通信回線の帯域を利用して少しずつ取りに行くことで、余分なデータをプリフェッチするための帯域を他の通信に有効に利用することができる。

図３を用いて、図１で、プリフェッチが外れ、バッファで保持されるデータとは異なるアドレスに対応するデータに対するreadコマンドをアプリケーション高速化装置１０５が受領した場合の動作を説明する。ここではクライアント１０１がｏｐｅｎコマンド３０１を送信し、それに伴いアプリケーション高速化装置２（１０６）がプリフェッチを行う所までは図１の１１２、１１３と同様である。

しかし、ここではクライアント１０１側ＴＩＤ＝４のｒｅａｄコマンド３０３がプリフェッチされていない領域のデータを要求する。
ここで、はクライアント１０１の要求が、６０００から６４９９までのデータの要求であるにも関わらず、アプリケーション高速化装置１（１０５）は、０から３９９９までのデータをプリフェッチしかしていない。そこで、アプリケーション高速化装置１（１０５）は、プリフェッチが外れたと判断３１１し、アプリケーション高速化装置２（１０６）に対して、オフセット６０００からの追加先読み依頼３１２を出す。その後、アプリケーション高速化装置２（１０６）はプリフェッチバッファサイズ分のプリフェッチを行う。 図３のように、ランダムアクセスをした場合であっても、余分なデータをプリフェッチせずに、済む。あるファイルのプリフェッチを、クライアントのデータ取得リクエストに合わせて、通信回線の帯域を利用して少しずつ取りに行くことで、余分なデータをプリフェッチするための帯域を他の通信に有効に利用することができる。

続いて図４を用いて、アプリケーション高速化装置１０５、１０６が行う、図１および図３で説明した実施例１の処理の流れを説明する。処理はアプリケーション高速化装置１（１０５）のｏｐｅｎコマンド受付４０１から始まり、その後各装置ＴＣＰ高速化装置１０３、１０４，アプリケーション高速化装置１０６を介してｏｐｅｎコマンドをファイルサーバ１０２に転送する。ファイルサーバ１０２からのレスポンスアプリケーション高速化装置１０５は、ファイル識別子（ＦＩＤ）レスポンスをアプリケーション装置１０６を介して受けると、クライアント１０１に返される（４０２）。

続いてアプリケーション高速化装置２（１０６）が、ＦＩＤ受領後、プリフェッチバッファサイズ分のｒｅａｄコマンド（図１での１２２）をファイルサーバ１０２に送信し、結果をアプリケーション高速化装置１（１０５）に転送（４０３）する（図１での１２４）。

次に、アプリケーション高速化装置１（１０５）はクライアント（１０１）からのコマンドを待ちうける。受信したコマンドがｃｌｏｓｅコマンドか否か判断し４０４、ｃｌｏｓｅではない場合は続いてｒｅａｄコマンドか否か判断する４０５。ｒｅａｄコマンドではない場合は、アプリケーション高速化装置１（１０５）および２（１０６）で、クライアント（１０１）からのreadコマンドに含まれるＴＩＤを付替え、ファイルサーバ１０２に転送し、結果をクライアントに返し４０６、手順４０４に戻る。

一方、手順４０５においてｒｅａｄコマンドである場合は、アプリケーション高速化装置１（１０５）は、ｒｅａｄ対象のデータをプリフェッチバッファに読込み中もしくは読込み済みか否か判断し４０７、そうではない（すなわち保持されていない）場合は、アプリケーション高速化装置１（１０５）からアプリケーション高速化装置２（１０６）へ追加先読み依頼をし、プリフェッチバッファ分の先読み（４０８）を行う（図１の追加先読み依頼（１３５）に対応）。

その後、アプリケーション高速化装置１（１０５）はＴＩＤを付替えし、プリフェッチバッファ内のデータをクライアント１０１へ返す（４０９）。その後、プリフェッチバッファ内データに対し閾値ｎ％を超えるアクセスがあったか否か判断し（４１０）、閾値を超えたと判断された場合、プリフェッチバッファ分の追加先読み（３１１）を行い、手順４０４に戻る。追加先読み依頼は、図１の１３５に対応する。

一方、手順４０４において、受領したコマンドが、ｃｌｏｓｅコマンドと判断した場合は、アプリケーション高速化装置１（１０５）は、プリフェッチバッファを解放し（４１２）、ｏｐｅｎコマンド受付４０１以降に同一ＦＩＤのファイルに対してｗｒｉｔｅ系のコマンドがなかったか否か判断する（４１３）。ここでｗｒｉｔｅ系コマンドとは、ファイルに何らかの変更を加えるコマンドである。

特にＣＩＦＳプロトコルの場合、ＳＭＢ２＿ＷＲＩＴＥとＳＭＢ２＿ＳＥＴＩＮＦＯがｗｒｉｔｅ系コマンドである。ｗｒｉｔｅ系コマンドがなかった場合は、アプリケーション高速化装置１（１０５）がｃｌｏｓｅレスポンスを作りクライアント１０１に返し（４１４）、その後各装置１０３、１０４，１０６を介しＴＩＤを付替えてｃｌｏｓｅコマンドをファイルサーバ１０２に転送し（４１５）、処理を終える４１７。ｗｒｉｔｅ系コマンドがないことを判別することにより、ｃｌｏｓｅコマンドが失敗する恐れがないと判定でき、close処理を完了できる。

手順４１３において、アプリケーション高速化装置１（１０５）は、ｗｒｉｔｅ系コマンドがあったと判断した場合は、各装置１０３、１０４，１０６を介しＴＩＤを付替えてｃｌｏｓｅコマンドをファイルサーバ１０２に転送し、ファイルサーバ１０２から送信される、結果を再びＴＩＤをつけかえてクライアント１０１に返し、処理を終える。 続いて、図５を用いて図１および図３で説明した動作を可能にするアプリケーション高速化装置１（１０５）および２（１０６）の構成と動作について説明する。

アプリケーション高速化装置１（１０５）および２（１０６）と同じアプリケーション高速化装置５０１はＬＡＮ側ＮＩＦ５０２とＷＡＮ側ＮＩＦ５０３と入力処理部５０４と出力処理部５０５とプリフェッチ処理部５０６を持つ。

ＬＡＮ側ＮＩＦ５０２は、アプリケーション高速化装置５０１とＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ、構内通信網）の接続口であり、アプリケーション高速化装置１（１０５）ではクライアント１０１と接続される。またアプリケーション高速化装置２（１０６）のＬＡＮ側ＮＩＦ５０２では、ファイルサーバ１０２と接続される。

またＬＡＮ側ＮＩＦ５０２はＬＡＮからの入力を一時的に蓄積するＬＡＮ側入力バッファ５２１と、ＬＡＮへの出力を一時的に蓄積するＬＡＮ側出力バッファ５２２を持つ。

ＷＡＮ側ＮＩＦ５０３はアプリケーション高速化装置５０１とＷＡＮの接続口であり、アプリケーション高速化装置１（１０５）ではＴＣＰ高速化装置１（１０３）と接続され、またアプリケーション高速化装置２（１０６）ではＴＣＰ高速化装置２（１０４）と接続される。またＷＡＮ側ＮＩＦ５０３はＷＡＮからの入力を一時的に蓄積するＷＡＮ側入力バッファ５３１と、ＷＡＮへの出力を一時的に蓄積するＷＡＮ側出力バッファ５３２を持つ。

入力処理部５０４はＬＡＮ側ＮＩＦ５０２およびＷＡＮ側ＮＩＦ５０３それぞれの入力バッファ５２１および５３１を監視し、メッセージを受信して処理を行う。入力処理部５０４の処理詳細は後述する。

出力処理部５０５は、最新ＴＩＤ管理テーブル８０１と更新前ＴＩＤ管理テーブル８０２とを有する最新ＴＩＤ管理テーブル８０１は、セッションＩＤごとの最新のＴＩＤを管理するためにセッションＩＤ列８１１とＴＩＤ列８１２を持つ。更新前ＴＩＤ管理テーブル８０２は、セッションＩＤごとの変更前ＴＩＤと変更後ＴＩＤの対応付けを管理するために、セッションＩＤ列８２１と変更前ＴＩＤ列８２２と変更後ＴＩＤ列８２３とを持つ。

そして、出力処理部５０５は、入力処理部５０４およびプリフェッチ処理部５０６からの出力要求を受け、それをＬＡＮ側ＮＩＦ５０２もしくはＷＡＮ側ＮＩＦ５０３の出力バッファ５２２および５３２に出力処理を転送する。また、出力処理部５０５は、ＬＡＮ側ＮＩＦバッファ５５１とＷＡＮ側ＮＩＦバッファ５５２を持ち、ＬＡＮ側ＮＩＦバッファ５５１に入ったメッセージをＬＡＮ側ＮＩＦ５０２の出力バッファ５２２に転送し、またＷＡＮ側ＮＩＦバッファ５５２に入ったメッセージをＷＡＮ側ＮＩＦ５０３の出力バッファ５３２に転送する。出力処理部５０５の処理詳細は後述する。 プリフェッチ処理部５０６は、プリフェッチバッファ５５０と、プリフェッチ要求管理テーブル５６０、プリフェッチデータ管理テーブル５７０、アクセスパタン管理テーブル５８０とを有する。

プリフェッチバッファ５５０は、ファイルサーバから取得した複数のファイルのデータを、ユーザ毎及びファイル毎に格納する。プリフェッチ要求管理テーブル５６０は、プリフェッチバッファに格納されているデータが、ファイルのどの部分に該当するのか、及び、そのデータがバッファのどこに格納されているかを管理する。プリフェッチ要求管理テーブル５７０は、プリフェッチデータとファイルとプリフェッチバッファにおける格納位置との対応付けを示すテーブルである。このテーブルはさらに、アクセスを出すクライアント１０１と対応付けされてもよい。

プリフェッチデータ管理テーブル５７０は、シーケンシャルかランダムかを判別するために、過去のリード要求を管理する。プリフェッチデータ管理テーブル５７０は、ファイルごとに開始オフセットと、終了オフセットと、プリフェッチバッファに格納されている当該ファイルの開始オフセットとの対応付けを示すテーブルである。

アクセスパタン管理テーブル５８０は、クライアントからのファイルに対するアクセスパタンの状態遷移を管理するテーブルである。
プリフェッチ処理部５０６は、上述の少なくとも一のテーブルで、プリフェッチデータのクライアントからのアクセス状況とクライアントのアクセスパターンにより、プリフェッチ処理を制御する。

プリフェッチ処理部５０６は、クライアント１０１からのファイルのオープン要求に従い、ファイル識別子をファイルサーバから取得する。

プリフェッチ処理部５０６は、ファイル識別子（FID）をクライアント１０１に通知する。プリフェッチ処理部５０６は、ファイル識別子の受領に応じてクライアント１０１から送信されるファイルサーバ宛のファイルの取得要求を受信する。また、ファイルのオープン要求受領後に、プリフェッチ処理部５０６は、ファイルサーバから該当ファイルの所定の範囲のデータを順次取得を開始する。

例えば、プリフェッチ処理部５０６は、プリフェッチ要求管理テーブル５６０とプリフェッチデータ管理テーブル５７０とを用いて、クライアントからファイルデータがプリフェッチバッファ５５０から読み出される状況を監視し、さらに、ファイルサーバ１０２あるいは、ＷＡＮ側のアプリケーション高速化装置１０６に対して、ファイル取得要求（プリフェッチ）をＷＡＮ側ＮＩＦを介して、発行するか決定する。その際用いる閾値もプリフェッチ処理部５０６のメモリ（図示せず）に保持される。より具体的には、サーバに格納される一ファイルの先読みするデータ量に制限を設け、サーバに対してファイルの所定量の先読みを行う。先読みしたデータへのユーザからのアクセス状況を監視し、監視結果、所定の量、先読みデータがユーザからリード要求された場合は、サーバに対してさらなる所定量の先読みを行う。

そして、プリフェッチ処理部５０６は、先読みデータを受領すると、クライアント１０１からのデータ取得要求に応じて、該当データをクライアントにＬＡＮ側ＮＩＦを介して、送る。該当データを送付後、プリフェッチバッファ５５０から消去あるいは上書き可能な状態にしてもよい。クライアント１０１への再送のために、ＬＡＮ側ＮＩＦ５０２の出力バッファ５２２が保持していてもよい。

また、プリフェッチ処理部５０６は、入力処理部５０４が処理したデータのうち、プリフェッチに関するメッセージを受け取り、処理結果を出力処理部５０５に転送する。プリフェッチ処理部５０６の処理詳細は後述する。

続いて図６を用いて入力処理部５０４の処理詳細を説明する。入力処理部５０４は処理開始６０１後、判断６０２から判断６０７までの一連の手順を繰り返し実行し、各判断にヒットする場合にそれぞれの処理を行う。なお、手順６０２、６０３、６０４にヒットするのはクライアント１０１側の高速化装置１（１０５）であり、また手順６０５，６０６、６０７にヒットするのはファイルサーバ１０２側の高速化装置２（１０６）である。したがって、クライアント１０１側の高速化装置１（１０５）は、手順６０２、６０３、６０４以外の手順６０５，６０６、６０７をスキップしてもよい。またファイルサーバ１０２側の高速化装置２（１０６）は、手順６０５，６０６、６０７以外の手順６０２、６０３、６０４をスキップ処理をしてもよい。 入力処理部５０４は、ＬＡＮ側ＮＩＦ５０２の入力バッファ５２１にリクエストが入ったと判断６０２した場合は、それがｃｌｏｓｅコマンドか否か判断し（６２１）、closeコマンドであればプリフェッチ処理部５０６のプリフェッチ処理Ｄ（図１２）に処理を引きつぐ（６２２）。プリフェッチ処理Ｄは、図４の手順４１３ないし４１５に対応する処理である。なお、手順６２１は、図４の手順４０４に対応する
一方、closeコマンドでなければ、入力処理部５０４は、ｒｅａｄコマンドか否か判断する（６２３）。ｒｅａｄコマンドであればプリフェッチ処理部５０６のプリフェッチ処理Ｂ（図１０）に処理を引き継ぐ（６２４）。プリフェッチ処理Ｂは、手順４０７ないし４１１に相当する処理で、追加の先読み要求をするべきか判断する処理を行う。またプリフェッチ処理Ｂは、readコマンドに内容に応じて、ランダムアクセスかシーケンシャルアクセスかを判別し、先読み先や先読み量の変更を行う。

一方、readコマンドでなければ、入力処理部５０４は、出力処理部のＷＡＮ側ＮＩＦバッファにメッセージを転送する（６２５）。（図４の手順４０６の一部に対応する。）
ＷＡＮ側ＮＩＦバッファにレスポンスが入ったと判断（６０３）した場合は、出力処理部５０５のＬＡＮ側ＮＩＦバッファ５５１にメッセージを転送する（６３１）。

ＷＡＮ側ＮＩＦバッファに管理コマンドのレスポンスが入ったと判断した場合は（６０４）、プリフェッチ処理部５０６のプリフェッチ処理Ｃ６４１（図１１）に処理を引き継ぐ。プリフェッチ処理Ｃは、管理要求コマンドに対するレスポンスに対して、データ部のみ切り離し、プリフェッチバッファに保持する処理を行う。

なお、管理コマンドとは、アプリケーション高速化装置１（１０５）および２（１０６）の間で情報のやり取りを行うためのコマンドであり、本実施例では管理要求コマンドと管理ｃｌｏｓｅコマンドの２つを用いる。またそれぞれリクエストとレスポンスがあり、フォーマットからリクエストに対するレスポンスが容易に判断でき、かつフォーマットからリクエストとレスポンスを容易に識別可能とする。

ＷＡＮ側ＮＩＦバッファにリクエストが入ったと判断した場合は（６０５）、出力処理部５０５のＬＡＮ側ＮＩＦバッファ５５１にメッセージを転送する（６５１）。

ＬＡＮ側ＮＩＦバッファにレスポンスが入ったと判断した場合６０６は、レスポンスがｃｌｏｓｅコマンドか否か判断６６１し、ｃｌｏｓｅコマンドであれば、そのレスポンスの処理をプリフェッチ処理部５０６のプリフェッチ処理Ｆ（図１４）に処理を引き継ぐ６６２。そうでない場合は続いてｏｐｅｎコマンドか否か判断６６３し、そうであればプリフェッチ処理部５０６のプリフェッチ処理Ｅに処理を引き継ぐ６６４。そうでない場合は続いてｒｅａｄコマンドか否か判断６６５し、そうである場合には管理レスポンスを作成６６６する。その後、出力処理部５０５のＷＡＮ側ＮＩＦバッファ５５２にメッセージを転送６６７する。

ＷＡＮ側ＮＩＦバッファに管理コマンドのリクエストが入ったと判断６０７した場合はプリフェッチ処理部５０６のプリフェッチ処理Ａ６７１にメッセージを転送する。

以上が入力処理部５０４の処理詳細である。 次に、図４の４０６，４０９のＴＩＤ付け替えの際に行う、ＴＩＤの管理処理について説明する。 図８は、図７の手順を実行するために出力処理部５０５が保持するテーブル（Ａ）（Ｂ）を示す。１つ目のテーブル（Ａ）は、最新ＴＩＤ管理テーブル８０１であり、セッションＩＤごとの最新のＴＩＤを管理するためにセッションＩＤ列８１１とＴＩＤ列８１２を持つ。２つ目のテーブル（Ｂ）は、更新前ＴＩＤ管理テーブル８０２であり、セッションＩＤごとの変更前ＴＩＤと変更後ＴＩＤの対応付けを管理するために、セッションＩＤ列８２１と変更前ＴＩＤ列８２２と変更後ＴＩＤ列８２３とを持つ。

図７は、出力処理部５０５の処理詳細を示す。図７の手順の詳細に合わせて、図８の２つのテーブルの更新方法を説明する。

出力処理部５０５は処理開始７０１後、判断７０２から判断７０５までの一連の手順を繰り返し実行し、各判断処理にヒットする場合にそれぞれの処理を行う。

なお、手順７０２、７０３にヒットするのは、クライアント１０１側の高速化装置１（１０５）であり、また手順７０４、７０５にヒットするのはファイルサーバ１０２側の高速化装置２（１０６）である。クライアント１０１側の高速化装置１（１０５）は、手順７０２、７０３以外の手順７０４、７０５はスキップしてもよい。また、ファイルサーバ１０２側の高速化装置２（１０６）は、手順７０４、７０５以外の手順７０２、７０３をスキップしてもよい。

ＷＡＮ側ＮＩＦバッファ５５２にリクエストが入ったと判断した場合（７０２）は、メッセージ中のセッションＩＤを用いて最新ＴＩＤ管理テーブル８０１から最新のＴＩＤの値（ａとする）を取得し、最新ＴＩＤ管理テーブル８０１のＴＩＤ列８１２をａ＋１に更新し（７２１）、更新前ＴＩＤ管理テーブル８０２にメッセージ中のセッションＩＤとメッセージ中のＴＩＤとａを用いてレコードを挿入し（７２２）、ＷＡＮ側ＮＩＦ５０３の出力バッファ５３２にメッセージを転送する（７２３）。手順７２１ないし７２３は、図４の手順４０６をより詳細にしたものに対応する。ＷＡＮ側ＮＩＦ５０３の出力バッファに５３２に保持されるメッセージは、ＴＣＰに従って、送信帯域制御を行い、ＷＡＮに送出される。

ＬＡＮ側ＮＩＦバッファ５５１にレスポンスが入ったと判断した場合は（７０３）、メッセージ中のセッションＩＤとＴＩＤ（これは更新後ＴＩＤ）を用いて更新前ＴＩＤ管理テーブル８０２からメッセージ中のセッションＩＤ及びＴＩＤに対応するレコードを探索し、更新前ＴＩＤ（ｂとする）を取得し、メッセージ中のＴＩＤをｂに更新する。その後、出力処理部５０５は、探索したレコードを削除する（７３１）。

ここで、プリフェッチ処理部５０６が出力したレスポンスの場合は、更新前ＴＩＤ管理テーブル８０２内にレコードがない場合がある。そこで手順７３１においてレコードが見つかったか否か判断し（７３２）、見つからなかった場合はメッセージ中のセッションＩＤを用いて最新ＴＩＤ管理テーブル８０１から最新のＴＩＤの値（ｃとする）を取得（８０１）し、のＴＩＤ列８１２をｃ＋１に更新しメッセージ中のＴＩＤをｃに更新する７３３。その後ＬＡＮ側ＮＩＦ５０２の出力バッファ５２２に、ＴＩＤがｃに更新されたメッセージを転送する（７３４）。ＬＡＮ側ＮＩＦ５０２は、出力バッファ５２２に格納されるメッセージをクライアント１０１に向かって順次転送する。手順７３１ないし７３４は、図６の手順６３１によりＬＡＮ側ＮＩＦに転送されるレスポンスに対して実行される。例えば、手順７３１から７３４は、図４の４０６に対応する。

ＷＡＮ側ＮＩＦバッファ５５２にレスポンスが入ったと判断した場合（７０４）は、メッセージ中のセッションＩＤとＴＩＤ（これは更新後ＴＩＤ）を用いて更新前ＴＩＤ管理表８０２からレコードを探索し更新前ＴＩＤ（ｄとする）を取得しメッセージ中のＴＩＤをｄに更新した後にレコードを削除７４１する。その後ＷＡＮ側ＮＩＦ５０３の出力バッファ５３２にメッセージを転送７４２する。

ＬＡＮ側ＮＩＦバッファ５５１にレスポンスが入ったと判断７０５した場合はメッセージ中のセッションＩＤを用いて最新ＴＩＤ管理テーブル８０１から最新のＴＩＤの値（ｅとする）を取得後８０１のＴＩＤ列８１２をｅ＋１に更新７５１し、更新前ＴＩＤ管理テーブル８０２にメッセージ中のセッションＩＤとメッセージ中のＴＩＤとｅを用いてレコードを挿入７５２し、ＬＡＮ側ＮＩＦ５０２の出力バッファ５２２にメッセージを転送７５３する。 以上が、出力処理部５０５が、クライアント側とのトランザクションと、サーバ側とのトランザクションを対応づけるために、ＴＩＤを管理する処理である。

続いて、図９から図１３、図２４から図２６を用いてプリフェッチ処理部５０６の処理詳細を説明する。 図２４は、プリフェッチ要求管理テーブル５６０を示す図である。プリフェッチ要求管理テーブル５６０は、ファイルごとのプリフェッチバッファサイズと次回プリフェッチする場所を管理するテーブルである。本テーブルの主キーはFID列２４１０である(FIDはシステムユニークな値のため、主キーになりうる)。また、FIDは、特定のユーザにより、オープンしたファイルオブジェクトを特定する識別子である。

プリフェッチオフセット列２４２０は現在どこまでプリフェッチできているかを表す。つまり、アプリケーション高速化装置のファイルの取得状況を示す。次回プリフェッチを行うときは、アプリケーション高速化装置１０５，１０６は、この列で示されたオフセット位置から読込むリクエスト発行する。
プリフェッチバッファサイズ列２４３０はFID列２４１０で表されるファイルオブジェクトに割り当てられたプリフェッチバッファのサイズを現す列である。つまり、プリフェッチバッファサイズ２４３０の値は、特定ユーザに対して該当ファイルのために割り当てられるバッファの上限値を示す。

本テーブルにはファイルオープンに伴いFIDが発行されたとき(すなわちopenのレスポンス受信時)にレコードが追加する。その際のプリフェッチオフセットは0、プリフェッチバッファサイズは初期値 (ここでは1MB) とする。
図２５は、プリフェッチデータ管理テーブル５７０を示す。プリフェッチデータ管理テーブル５７０は、ファイルごとのプリフェッチ済み箇所とプリフェッチバッファ内での場所を管理するテーブルである。本テーブルの主キーはFID列２５１０と開始オフセット列２５２０の組み合わせである。(本テーブルは同一FIDに対して複数のレコードが存在する (プリフェッチバッファ内でフラグメントするため)。)
開始オフセット列２５２０と終了オフセット列２５３０は、FIDで表されるファイルのどこからどこまでをプリフェッチしたかを表す。
プリフェッチバッファ内オフセット列２５４０は、プリフェッチバッファに格納される当該ファイルデータの、プリフェッチバッファにおける開始オフセットをあらわす。プリフェッチバッファ内での終了オフセットは、終了オフセット列２５３０とプリフェッチバッファ内開始オフセット２５４０との値から特定される。
図９は、プリフェッチ処理部５０６のプリフェッチ処理Ａの処理詳細である。

プリフェッチ処理Ａは,図６で、ＷＡＮ側ＮＩＦのバッファに管理コマンドリクエストが保持されている場合に実行される。

ここではまず処理開始後（９０１）、受け取ったメッセージが管理要求コマンド（例えば、追加先読み依頼）か否か判断（９０２）し、管理要求コマンドであればプリフェッチバッファ分のｒｅａｄコマンド（リクエスト）を作成し（９２１）、出力処理部５０５のＬＡＮ側ＮＩＦバッファ５５１に渡し９２２、処理を終える（９０３）。その後、図７の処理フローにて、出力処理部５０５は、ＬＡＮ側ＮＩＦバッファに格納されるメッセージの処理を行う。従って、サーバ側のアプリケーション装置２（１０６）は、手順９２１で作成されたreadコマンドによる先読み要求を行い、ファイルサーバ１０２に送信し、ファイルの部分データを取得する。

一方、管理要求コマンドではない場合（すなわち管理ｃｌｏｓｅコマンドである場合）は、プリフェッチ処理部５０６は、ｃｌｏｓｅコマンドを作成し（９３１）、出力処理部５０５のＬＡＮ側ＮＩＦバッファ５５２に渡し（９３２）、処理を終える（９０３）。その後、図７の処理フローにて、出力処理部５０５は、ＬＡＮ側ＮＩＦバッファに格納されるメッセージの処理を行う。従って、サーバ側のアプリケーション装置２（１０６）は、手順９３１で作成されたcloseコマンドを送信する処理を行う（図４の手順４１６の一部に対応する。）。

図１０は、プリフェッチ処理部５０６のプリフェッチ処理Ｂの処理詳細である。プリフェッチ処理Ｂは、クライアント側のアプリケーション高速化装置１（１０５）のＬＡＮ側ＮＩＦのバッファにreadコマンドを保持した場合に行う処理である。図４の手順４０７ないし４１１に対応する。ここではまず処理開始後（１００１）、プリフェッチ処理部５０６は、プリフェッチデータ管理テーブル５７０を参照し、受け取ったｒｅａｄコマンドの要求範囲が先読み済みか否か、要求範囲に該当するデータが、プリフェッチバッファ５５０に保持されているか判断する（１００２）。判断の結果、保持されていれば（先読み済みであれば）、プリフェッチ処理部５０６は、クライアント１０１から送信された過去のreadコマンドの要求範囲に基づいて、クライアントからのアクセスパターンがシーケンシャルか否か判断し（１０２１）、判断結果、シーケンシャルであれば、次回取得プリフェッチバッファサイズを増加させる（１０２２）。一方、該当データが保持されていない（先読み済みではない）場合は、プリフェッチ処理部５０６は、アクセスパターンがランダムか否か判断し（１００３）、ランダムであれば次回取得バッファサイズを減少させる（１０３１）。

バッファサイズを増減させる場合は、プリフェッチ処理部５０６は、手順１００２、１０２１，１０２２により、プリフェッチ処理部５０６は、クライアントからのアクセス履歴により、ランダムアクセスかシーケンシャルアクセスかを判別し、次回取得プリフェッチバッファサイズを更新する。なおアクセスパターンの判定処理の詳細とプリフェッチバッファサイズについては後述する。その後、プリフェッチ処理部５０６は、もっとも古いプリフェッチバッファを解放する（１００４）。

さらに、プリフェッチ処理部５０６は、新たにプリフェッチバッファを確保し（１００５）、管理要求コマンドを作成し、（１００６）。出力処理部５０５のＷＡＮ側ＮＩＦバッファに渡す（５５２）。管理要求コマンドに対する処理は、図７で前述のとおりである。

その後、プリフェッチ処理部５０６は、プリフェッチバッファにファイルの部分データが入ってきた後、プリフェッチバッファからファイルデータを含む、ｒｅａｄコマンドに対する応答を作成し（１００８）、出力処理部５０５のＬＡＮ側ＮＩＦバッファ５５１に渡す（１００９）。

次に、プリフェッチバッファ内データに対し閾値ｎ％を超えるアクセスがあったか否か判断し（１０１０）、閾値を超えた場合は古いプリフェッチバッファを解放１０１１し、新たにプリフェッチバッファを確保する（１０１２）。次のファイルデータを取得するための追加先読み依頼である管理要求コマンドを作成し（１０１３）、出力処理部５０５のＷＡＮ側ＮＩＦバッファに渡す（１０１４）。その後、処理を終える１０１５。以上、プリフェッチするデータ量の更新処理や、追加の先読み依頼を行う処理を含むプリフェッチ処理Ｂの詳細を説明した。なお、手順１０１０の、プリフェッチバッファ内データに対するアクセス状況を監視する処理は、図１０のタイミングに限らず、定期的に行ってもよい。

ここで、図１０のステップ１００３及び１０２１の判定処理に関する、アクセスパターンとプリフェッチバッファについて、図１５，図２６，図２７及び図２８を用いて説明する。本実施例では、プリフェッチ処理部５０６が、あるファイルに対するアクセスの履歴から、アクセスパターンが、シーケンシャルアクセス、ランダムアクセス、ニュートラルアクセスいずれかを判定し、判定結果に基づいて、プリフェッチの制御を変更する。

ここでシーケンシャルアクセスとは、クライアントからの複数のreadコマンドで要求されるアドレス範囲を比較すると、連続するアドレス範囲を指定されていると判定されるアクセスパターンをいう。またはシーケンシャルアクセスとは、複数のreadコマンドにより指定されるアドレス範囲が、プリフェッチバッファのｎ％以上のデータを読んだ場合の事とする。なお、ｎ％は、図１０の手順１０１０の閾値ｎ％よりも小さい。

またランダムアクセスとは、クライアントからの連続するreadコマンドによって、所定の回数連続してプリフェッチバッファのｎ％以上のデータを読まなかった場合の事とする。

また、ニュートラルアクセスとは、シーケンシャルアクセスでもランダムアクセスでもない場合の事とし、具体的にはプリフェッチバッファのｎ％以上のデータを読んだり読まなかったりした場合を指す。

図１０の手順１０２１で。ここであるファイルがシーケンシャルアクセスと判定されているのであれば、プリフェッチバッファのサイズを増やす（１０２２）ことでクライアントから見たアクセス速度をさらに速くできる。

一方であるファイルがランダムアクセスと判定されているのであれば、プリフェッチバッファのサイズを減らす事で、実際にクライアントからアクセスされないデータをＷＡＮに流れることをぼうしできる。さらに、シーケンシャルアクセスと判断し、プリフェッチバッファのサイズを増やした場合、新しいサイズにおいてもシーケンシャルアクセスを行う（すなわち連続して新しいサイズのプリフェッチバッファのｎ％以上のデータを読む）か否か分からないため、一旦ニュートラルアクセスとして扱い、あらたにアクセス種別の判断をおこなう。同様にシーケンシャルアクセスと判断し、プリフェッチバッファのサイズを増やした場合、新しいサイズにおいてもランダムアクセスを行う（すなわち連続して新しいサイズのプリフェッチバッファのｎ％以上のデータを読まない）か否か分からないため、一旦ランダムアクセスとして扱い、あらたにアクセス種別の判断をおこなう。

以上の説明をまとめた状態遷移図の例を図１５に示す。プリフェッチ処理部５０５が、図１０の手順１０２１，１００３で行う、シーケンシャルアクセスやランダムアクセスの判断基準を３回連続したｎ％以上（もしくは以下）のアクセスとした場合で、説明する。

ここではニュートラルアクセス状態を１５０１、シーケンシャルアクセス状態を１５０２、ランダムアクセス状態を１５０３とし、ニュートラル状態からプリフェッチバッファのｎ％読込むと状態１５２１へ進み、さらに次のプリフェッチバッファのｎ％読込むと状態１５２２へ進み、さらに次のプリフェッチバッファのｎ％読込むとシーケンシャルアクセス１５０２と判断され、次回取得バッファサイズを増やしニュートラルアクセス状態１５０１に戻る。同様にニュートラル状態からプリフェッチバッファのｎ％読込まないと状態１５３１へ進み、さらに次のプリフェッチバッファのｎ％読込まないと状態１５３２へ進み、さらに次のプリフェッチバッファのｎ％読込まないとシーケンシャルアクセス１５０３と判断され、次回取得バッファサイズを減らしニュートラルアクセス状態１５０１に戻る。なお、シーケンシャルアクセス状態への移行中状態１５２１および１５２２においてプリフェッチバッファのｎ％読込まないと状態１５３１に移行する。またランダムアクセス状態への移行中状態１５３１および１５３２においてプリフェッチバッファのｎ％読込むと状態１５３１に移行する。

図２６は、アクセスパタン管理テーブルを示す。
図15のアクセスパタンの状態遷移のルールに従って遷移されたアクセスパターンの状態を示す状態例２６２０と、クライアントからのアクセスが、連続した読み込みが発生したか、またはその回数を示す連続読み込み列２６３０と、をＦＩＤ列２６１０にて対応づけるテーブルである。FID列２６１０は、主キーであり、ファイルオブジェクトごとにアクセスパタンの状態とクライアントからの連続読み込み回数、つまりクライアントからのファイルの読み出し要求範囲を含むアクセス履歴を管理する。状態列２６２０は、図15の状態遷移図中のどの状態にいるかを表す。

なお、図２４のプリフェッチバッファサイズ２４３０の値の管理については、最大値と最小値をあらかじめ、プリフェッチ処理部５０６が認識していてもよい。例えば、プリフェッチ処理部５０６は、プリフェッチバッファを大きくしすぎるとクライアント１０１間のアクセス速度に偏りが生じるため、プリフェッチバッファサイズにはユーザ定義もしくはシステム定義の上限を持たせる。また、プリフェッチバッファを小さくしすぎるとｒｅａｄ一回分のデータすらバッファに乗らなくなるため、プリフェッチバッファサイズにはユーザ定義もしくはシステム定義の下限を持たせる。

一例として、プリフェッチバッファサイズ１５４１の上限を８ＭＢ（１５４２）、下限を１２８ＫＢ（１５４３）とし、また初期値を１ＭＢ（１５４４）とする。プリフェッチバッファサイズを増加させる時には上限（１５４２）に達するまで２倍（１５４５）し、またプリフェッチバッファサイズを減少させる時には下限（１５４３）に達するまで半分（１５４６）にする。

また、ファイルに対する開始オフセット、終了オフセットの組み合わせで示すクライアントからのアクセスが、以下のように、最初のアクセス（Read（１０１，１５０））のあと、２回がランダムに読んだ後、シーケンシャルアクセスが続いた場合であり、かつ現在のプリフェッチバッファのｎ％が２０００である場合の状態遷移を図２７に示す。
Read(101, 150)
Read(301, 400)
Read(5501, 6500)
Read(6501, 7500)
Read(7501, 8500)
Read(8501, 9500)
Read(9501, 10500)
Read(10501, 11500)
Read(11501, 12500)
Read(12501, 13500)
図２７は、それぞれの行で、初期状態２７１０から、入力（クライアントからのアクセス）２７２０が発生すると、状態が、図１５に従って遷移先２７３０に遷移し、その際アクセスパタン管理テーブル５８０の状態列２６２０の値は遷移先２７３０になり、またアクセスパタン管理テーブル５８０の連続読込み列２６３０の値は値２７４０になり、さらに次の入力に対しては一段下がった下の行で遷移することを示している。プリフェッチ処理部５０６は、その遷移後の状態とクライアントからのプリフェッチバッファに格納されているデータに対する連続読み込みがあったかを、図２６のアクセスパタン管理テーブル５８０を更新する。

以上が、図１０のステップ１００３及び１０２１の判定処理に関する、アクセスパターンとプリフェッチバッファについての説明である。

図１１は、プリフェッチ処理部５０６のプリフェッチ処理Ｃの処理詳細である。

プリフェッチ処理Ｃは、図６の手順６０４の処理結果に応じて行われる。

ここではまず処理開始１１０１後、受け取ったメッセージが管理要求コマンドのレスポンスか否か判断し（１１０２）、管理要求コマンド（例えば、追加先読み要求依頼）のレスポンスであればデータ部のみ切り離して新たに確保したプリフェッチバッファに、データ部に格納されているファイルの部分データを保存１１２１し、処理を終える（１１０３）。

図１２は、プリフェッチ処理部５０６のプリフェッチ処理Ｄの処理詳細である。図４の手順４１２ないし４１５に対応し、図６の手順６２１の判断結果に応じて行われる。まず、プリフェッチ処理部５０６は、プリフェッチバッファを解放１２０２し、ｏｐｅｎコマンド受付６６３以降に同一ＦＩＤのファイルに対してｗｒｉｔｅ系のコマンドがなかったか否か判断する（１２０３）。

ｗｒｉｔｅ系コマンドがなかった場合は（手順１２０３の判断結果でＹｅｓの場合）、ｃｌｏｓｅレスポンスを作りクライアントに返し（１２３１）、管理ｃｌｏｓｅコマンドを作成する（１２３２）。そして、プリフェッチ処理部５０６は、ｃｌｏｓｅしたファイルのＦＩＤをメモリに記録しておき（１２３３）、出力処理部５０５のＷＡＮ側ＮＩＦバッファ５５２に渡し１２０４、処理を終える。手順１２３３にて記録したＦＩＤはプリフェッチ処理部５０６プリフェッチ処理Ｆにて使用する。

一方ｗｒｉｔｅ系コマンドがあった場合は（手順１２０３の判断結果でＮｏの場合）、プリフェッチ処理部５０６は、クライアント１０１からのｃｌｏｓｅリクエストコマンドをそのまま出力処理部５０５のＷＡＮ側ＮＩＦバッファ５５２に渡し（１２０４）、処理を終える。Closeリクエストコマンドは、ＷＡＮを介してファイルサーバ１０２に転送される。以上が、図１２を用いてクライアント１０１からcloseコマンドを受領したときの、アプリケーション高速化装置１０５が行う処理フローを説明した。

図１３はプリフェッチ処理部５０６のプリフェッチ処理Ｅの処理詳細である。プリフェッチ処理Ｅは、ファイルサーバ側のアプリケーション装置２（１０６）が、openコマンドに対するレスポンスをファイルサーバから受領した場合に、そのレスポンスをＷＡＮを介してクライアントに転送する処理に対応して行う処理である。図４の手順４０３に対応する。

まず、プリフェッチ処理部５０６は、プリフェッチバッファ分のｒｅａｄコマンド（先読み要求）を作成し（１３０２）、出力処理部５０５のＬＡＮ側ＮＩＦバッファ５５１に渡し（１３０３）、処理を終える１３０４。

図１４は、プリフェッチ処理部５０６のプリフェッチ処理Ｆの処理詳細である。プリフェッチ処理Ｆは、ここではまず処理開始１４０１後、受け取ったｃｌｏｓｅレスポンスメッセージのＦＩＤが記録されているか判断１４０２し、記録されていた（すなわちプリフェッチ処理Ｄの手順１２３３で記録した）場合は何もしない（すなわちｃｌｏｓｅレスポンスメッセージをここで破棄する）で処理を終える。一方、記録されていなかった場合はｃｌｏｓｅレスポンスメッセージを出力処理部のＬＡＮ側ＮＩＦバッファに渡し１４０３、処理を終える１４０４。 実施例１は上記の方法を実装したアプリケーション高速化装置によって、図２に示す構成のシステムにおいて多くのユーザに対して平等にサービスを提供できるよう、一度に先読みするデータ量に制限を設ける。また既に先読みしたデータへのアクセス進捗状況を監視し、必要に応じて後続のデータを先読みする。また、全てのＣＩＦＳメッセージのＴＩＤをつけかえ、不整合が生じないようにする。

実施例１では、WANを介してクライアント側及びサーバ側の双方にアプリーケーション高速化装置を備え、先読み処理を両装置が協調して行う例説明した。

実施例２では、図１６に示すクライアント側のアプリケーション高速化装置１６０５が、フィルサーバに対して、他のアプリケーション高速化装置と協調せずに、先読み処理を行う例を説明する。本実施例によると、アプリケーション高速化装置１６０５をクライアント側への導入で済む。以下、実施例１との差分を強調して説明する。 図１７は実施例２のシーケンスである。実施例１の図１と比較して、ｏｐｅｎコマンドを受け取りプリフェッチを開始１７０１するのがアプリケーション高速化装置１６０５に変わっている。また、同様にプリフェッチが外れた場合もアプリケーション高速化装置１６０５がプリフェッチを開始する。

実施例１において図４で説明した処理の流れと図５で説明したアプリケーション高速化装置内の構成については、本実施例でも変更はない。ただし、アプリケーション高速化装置内の各処理部５０４、５０５、５０６の処理内容には若干の変更があるため、以下で説明する。

図１８は入力処理部５０４の処理詳細である。ここでは実施例１の入力処理部５０４の処理詳細（図６）と比較し、入力処理部が判断するのはＬＡＮ側ＮＩＦ５０２の入力バッファ５２１にリクエストが入った場合６０２とＷＡＮ側ＮＩＦ５０３の入力バッファ５３１にレスポンスが入った場合１８０６だけになる。また、手順１８０６にヒットした場合の処理のうち、そのレスポンスがｒｅａｄコマンドであった場合の処理がプリフェッチ処理部５０６のプリフェッチ処理Ｇへの引き継ぎ１８６６に変わる。

図１９は出力処理部５０５の処理詳細である。ここでは実施例１の出力処理部５０５の処理詳細（図７）と比較し、出力処理部が判断するのはＷＡＮ側ＮＩＦバッファ５５２にリクエストが入った場合７０２とＬＡＮ側ＮＩＦバッファ５５１にレスポンスが入った場合７０３だけになる。判断７０２および７０３にヒットした以降の処理に変わりはない。

図２０から図２３はプリフェッチ処理部５０６の処理詳細である。実施例１にあったプリフェッチ処理Ａおよびプリフェッチ処理Ｃは実施例２のプリフェッチ処理部５０６には不要である。また、新たにプリフェッチ処理Ｆを追加する。

図２０はプリフェッチ処理部５０６のプリフェッチ処理Ｂの処理詳細である。実施例１の場合（図１０）と比較し、管理要求コマンドを作成する手順１００６および手順１０１３が、プリフェッチバッファ分のｒｅａｄコマンド作成２００６および２０１３に変わる。

図２１はプリフェッチ処理部５０６のプリフェッチ処理Ｄの処理詳細である。実施例１の場合（図１２）と比較し、管理ｃｌｏｓｅコマンドの作成１２３２手順が不要となる。

図２２はプリフェッチ処理部５０６のプリフェッチ処理Ｅの処理詳細である。実施例１の場合（図１３）と比較し、ｒｅａｄコマンドの渡し先が出力処理部５０５のＷＡＮ側ＮＩＦバッファ５３２（２２０３）に変わる。

図２３はプリフェッチ処理部５０６のプリフェッチ処理Ｇの処理詳細である。ここではまず処理開始２３０１後、データ部のみ切り離して新たに確保したプリフェッチバッファに保存２３０２し、処理を終える２３０３。

実施例２は、上記の方法を実装したアプリケーション高速化装置１６０５によって、図１６に示す構成のシステムにおいて多くのクライアントに対して平等にサービスを提供できるよう、一度に先読みするデータ量に制限を設ける。また既に先読みしたデータへのアクセス進捗状況を監視し、必要に応じて後続のデータを先読みする。また、アプリケーション高速化装置は、クライアントからのCIFSメッセージに含まれるTIDを変換して、サーバ側に先読み要求を含むCIFSメッセージを送信し、サーバからのレスポンスについても同様にTIDを変換して、クライアントのアクセス要求に応答する。それにより、不整合が生じないようにする。 上述の実施例により、ファイルを利用する一ユーザによるバッファの占有を防ぎ、効率的な先読み処理が可能となり、多くのユーザに対しても平等にサービスを提供できる。 ファイルデータを少しずつ読み込むため、帯域も他の通信に解放することができる。一度に読み込まないので、ユーザが利用しないデータについての先読みのために、帯域を使う必要がなくなり、ネットワークの効率的な利用ができる。

なお、ＣＩＦＳプロトコルを例に説明したが、ＮＦＳ（ネットワークファイルシステム）プロトコルやＦＴＴP（ファイル転送プロトコル）に従う通信を行うクライアントとサーバ間を中継する通信装置でも上述の実施例と同様のプリフェッチ制御をおこなってもよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

アプリケーション高速化装置１０５、１０６、
TCP高速化装置１０３、１０４、
ファイルサーバ１０２

Claims (15)

1. 第一のネットワークを介してクライアントと、第二のネットワークを介してサーバとに接続される通信装置であって、
   前記サーバが提供するファイルのデータを保持可能なバッファと、
   前記バッファに対するデータの読み書き制御を行う、制御部と、を有し、
   前記制御部は、前記サーバが提供するファイルに対する前記クライアントからの少なくとも一以上のアクセスに基づいて、前記ファイルにおける所定の範囲について前記サーバに対して、先読みを実行するかを判別し、前記先読みを実行することにより、前記サーバから受信するファイルデータを前記バッファに保持する、ことを特徴とする通信装置。
2. 請求項1記載の通信装置であって、
   前記クライアントからのアクセスが、ファイルのオープンリクエストである場合、
   前記制御部は、前記オープンリクエストを前記サーバに転送し、前記サーバからファイル識別子を受信するのに応じて前記先読みを実行する、ことを特徴とする通信装置。
3. 請求項２記載の通信装置であって、
   前記先読みは、前記ファイルにおける所定の範囲について、前記ファイルの指定と範囲とを指定を含む複数回のリード要求に分けてファイルデータを取得する、ことを特徴とする通信装置。
4. 請求項３記載の通信装置であって、
   前記リード要求は、それぞれ識別可能な識別子を含む、ことを特徴とする通信装置。
5. 請求項２記載の通信装置であって、
   前記制御部は、前記クライアントへ前記ファイル識別子の送信後に、前記クライアントからのアクセスに対応するデータが、前記バッファにある場合、前記対応するデータを前記クライアントに送信する、ことを特徴とする通信装置。
6. 請求項5記載の通信装置であって、前記バッファに保持されるデータを前記クライアントに送信した量に基づいて、前記サーバに対して先読みを実行する、ことを特徴とする通信装置。
7. 請求項１ないし６いずれか記載の通信装置であって、
   前記制御部は、前記クライアントからのアクセスが、前記ファイルのデータの取得要求である場合、前記取得要求に対応するデータを前記クライアントに送信するために前記バッファから読み出し、前記バッファからの読み出し量に基づいて、前記サーバに対して先読みを実行する、ことを特徴とする通信装置。
8. 請求項７記載の通信装置であって、
   前記制御部は、前記読み出し量が所定の量を超えた場合、前記サーバに対して、前記ファイルにおける以前に先読みした範囲と連続する範囲を含むデータを先読みする、ことを特徴とする通信装置。
9. 請求項1ないし８いずれか記載の通信装置であって、
   前記クライアントからの複数のアクセスの履歴に基づいて
   前記ファイルにおける、先読みの対象を決定する、ことを特徴とする通信装置。
10. 請求項９記載の通信装置であって、
    前記複数のアクセスが、前記ファイルの連続する範囲を指定する場合、
    前記制御部は、前記先読み対象とする範囲を増加させる、ことを特徴とする通信装置。
11. 請求項１ないし１０記載の通信装置であって、
    前記第2のネットワークは、ＴＣＰに従うネットワークであり、
    前記サーバは、ファイル要求プロトコルに従ってファイルを前記クライアントに提供する、ことを特徴とする通信装置。
12. クライアントと、前記クライアントにファイルを提供するサーバとの通信を中継する通信システムであって、
    前記クライアントからのファイルに対するアクセスに応じて、バッファに格納されるデータのうち、前記ファイルに対応するデータを読み出して前記クライアントに送信し、
    前記クライアントからのアクセス状況に応じて、前記ファイルに対する先読みリクエストを発行するバッファ制御装置と、
    前記先読みリクエストに基づいてサーバから前記ファイルを取得する取得装置と、
    を有することを特徴とする通信システム。
13. 請求項１２記載の通信システムであって、
    前記バッファ制御装置と、前記取得装置とは、ネットワークを介して接続され、
    前記ファイル取得装置は、前記クライアントからの前記ファイルの指定に応じて、前記サーバのファイルデータに対して前記ファイルの所定の範囲のデータを取得し、
    前記クライアントからの前記ファイルに対する複数のリード要求により特定される先読み対象範囲に対応するデータを取得し、前記バッファ制御装置に送信し、
    前記バッファ制御装置は、前記ファイル取得装置から受信されるデータを前記バッファに格納し、前記複数のリード要求の後に前記クライアント装置から送信されるリード要求に対応するデータを前記バッファから読み出して前記クライアントに送信する、ことを特徴とする通信システム。
14. 請求項１２記載の通信システムであって、
    前記バッファ制御装置と前記取得装置とはＢＵＳを介して接続され、
    前記ファイル取得装置は、前記クライアントからの前記ファイルの指定に応じて、前記サーバのファイルデータに対して前記ファイルの所定の範囲のデータを取得し、
    前記クライアントからの前記ファイルに対する複数のリード要求により特定される先読み対象範囲に対応するデータを取得し、
    前記バッファ制御装置は、前記ファイル取得装置により取得されるデータを前記バッファに格納し、前記複数のリード要求の後に前記クライアント装置から送信されるリード要求に対応するデータを前記バッファから読み出して前記クライアントに送信する、ことを特徴とする通信システム。
15. クライアントとファイルサーバとがファイル共有プロトコルに従い、ファイルデータを通信する通信方法であって、
    前記クライアントからのファイルの指定に応じて、前記ファイルサーバからファイル識別子を取得し、
    前記ファイル識別子に対応するファイルのデータの所定の範囲について先読みリクエストを作成し、
    前記先読みリクエストをＴＣＰに従って前記サーバに送信し、
    前記先読みリクエストに対応するレスポンスに含まれるファイルデータをバッファに保持し、
    前記クライアントからの前記ファイルのリード要求に対する前記バッファからのデータの読み出し状況に基づいて、前記ファイルの先読み対象範囲を決定し、前記決定された先読み対象範囲についての先読みリクエストを前記サーバにＴＣＰに従って送信し、
    前記サーバから受信するデータを、前記クライアントからのさらなるリード要求のために前記バッファに格納する、ことを特徴とする通信方法。