JP2014052868A - 情報処理装置、プログラム及び制御方法 - Google Patents

Abstract

【課題】 １つのリクエストで複数のファイルを受信するＰｕｓｈ受信方法を想定した場合には、Ｐｕｓｈ受信方法で受信して保存したファイルが、１つのリクエストで１つのファイルを受信するＧｅｔ受信方法で受信して保存するファイルを圧迫する虞がある。
【解決手段】 条件に従ってＰｕｓｈ受信方法で受信して保存したファイルを、Ｇｅｔ受信方法で受信して保存したファイルよりも優先して削除する。
【選択図】 図９

Description

本発明は受信して保存したファイルを削除する技術に関する。

一度取得したファイルを再度利用することに備えてキャッシュして保持しておく技術が存在する。特許文献１は、サーバ側が動的に生成するオブジェクトをクライアントが記憶し、動的なオブジェクトを静的なオブジェクトと区別して扱うことが可能である。

特表２００８−５２９１２７

ここで１つのリクエストで１つのファイルを受信するＧｅｔ受信方法と、１つのリクエストで複数のファイルを受信するＰｕｓｈ受信方法でファイルを受信することができる環境を想定したとする。

一方で、特許文献１はＰｕｓｈ受信方法については開示がない。よって、前述した環境を想定した場合にはＰｕｓｈ受信方法で受信して保存したファイルがＧｅｔ受信方法で受信して保存するファイルを圧迫する虞がある。

よって、本発明は条件に従ってＰｕｓｈ受信方法で受信して保存したファイルを、Ｇｅｔ受信方法で受信して保存したファイルよりも優先して削除することにより、キャッシュを有効に管理する技術を提供することを目的とする。

上記の目的を達成するための本発明に係る情報処理装置は、
１つのリクエストで１つのファイルを受信するＧｅｔ受信方法により受信するファイルを保存するＧｅｔ保存手段と、
前記Ｇｅｔ保存手段が保存したファイルを含む受信ファイルの合計が所定の容量を超えてかつ新たにファイルを受信したと判断した場合に前記Ｇｅｔ保存手段が保存したファイルを削除するＧｅｔ削除手段と、
１つのリクエストで複数のファイルを受信する、前記Ｇｅｔ受信方法とは異なる受信方法であるＰｕｓｈ受信方法により受信するファイルを保存するＰｕｓｈ保存手段と、
前記Ｐｕｓｈ保存手段が保存したファイルを含む受信ファイルの合計が所定の容量を超えてかつ新たにファイルを受信したと判断した場合に前記Ｐｕｓｈ保存手段が保存したファイルを前記Ｇｅｔ削除手段の前記Ｇｅｔ保存手段が保存したファイルの削除よりも優先して削除するＰｕｓｈ削除手段と、を有する。

本発明によれば、条件に従ってＰｕｓｈ受信方法で受信して保存したファイルを、Ｇｅｔ受信方法で受信して保存したファイルよりも優先して削除することによりキャッシュを有効に管理することができる。

コンピュータを含むネットワーク構成図 コンピュータを含むシステムの構成図 対象プロトコルの構成図 対象プロトコルデータ構造図 ソフトウェア構成図 データの送受信の制御を行う処理のフローチャート データの受信部分を示すフローチャート キャッシュテーブルの構造例 キャッシュテーブル内に登録されたデータの削除を行う処理のフローチャート 他のキャッシュと関連付いたキャッシュデータを削除する処理を示したフローチャート 削除優先順位の決定にストリームの優先度情報を使用した処理のフローチャート

実施形態を説明する前に、説明に用いる用語および、本明細書が対象とする通信プロトコルについて定義する。

ソケットとは、ＴＣＰレイヤにおいて、通信を識別、分類するための表記である。多くの場合ＩＰプロトコルを下位レイヤとして用いるのが一般的であり、この場合、ＩＰアドレスとポート番号の組のことである。

ＴＣＰコネクションとはＴＣＰレイヤにおけるひとつの通信路を意味する。具体的には受信側ソケットと送信側ソケットの組のことである。

受信ウィンドウサイズとは、受信側の空きバッファの容量のことである。ＴＣＰプロトコルもウィンドウサイズを用いた処理を行うが、以降ウィンドウサイズと書く場合、対象とする上位通信プロトコルで用いるウィンドウサイズを意味する。

ストリームとは対象とする上位通信プロトコルにおける論理チャネルのことである。

フレーム３０１とは、実際にデータを送信する際に、データを細切れにした最小単位のブロックのことである。ただし、ここでのフレーム３０１は、ＩＳＯによって提唱されているＯＳＩ７階層モデルで用いるデータリンク層のフレームと関係は無く、対象とする通信プロトコルにおける最小のデータ単位を指す。

ここで、本明細書が対象とする通信プロトコルについて説明する。以降対象プロトコルと記述する。対象プロトコルはＴＣＰプロトコルを利用する。ただし、ＴＣＰプロトコルとの透過性を維持する中間プロトコル（ＴＬＣ、ＳＳＬ等）が存在しても良い。対象プロトコルはＴＣＰコネクション３００上をフレーム３０１と呼ばれるデータを送受信することで通信を行う（図３）。フレーム３０１はヘッダにフレームサイズを持つ。

ここで、対象プロトコルのデータ構造図を図４に示す。対象プロトコルは該当するひとつのＴＣＰコネクション３００上におけるセッション４００として管理する。また、ひとつのセッション４００上にはひとつのコントロールフレーム４０１があり、セッション４００に関する通信は、このコントロールフレーム４０１を用いて行われる。対象プロトコルは、コントロールフレーム４０１以外に、任意の数のデータストリーム４０２を保持しても良い。

なお本明細書においては、データストリームとストリームは同義である。

実際の上位アプリケーションおよび上位プロトコルのデータ通信は、このデータストリーム４０２を用いて行われる。このデータストリーム４０２はそれぞれ優先順位を設定できる。優先順位の数は説明のために、最も高い０から最も低い７の８段階とするが、実際の運用では、この８段階でなく、任意の優先順位数でも良い。

さらに、データストリームはそれぞれを特定できるストリームＩＤを持つ。

また、データストリーム４０２は依存関係を持たせることができる。データストリーム４０２は親がいれば、その親ストリームのストリームＩＤを持つことによって依存関係を表現できる。この際、もし依存関係がなく親ストリームを持たない場合は、０またはｎｕｌｌ等ブランクを表すデータを持つか、あるいはストリームＩＤの格納領域そのものを持たないことで表現できる。

この対象プロトコルはサーバ、クライアントの主従関係は無く、対等に通信を行う。この際、本明細書ではクライアントがＨＴＴＰプロトコルのＧＥＴコマンドを用いて、ファイル取得要求を出すことをＧｅｔ要求、または単にＧｅｔと呼称し、Ｇｅｔ要求で得られたファイルをＧｅｔファイル又はＧｅｔデータと呼称する。Ｇｅｔではクライアントは１つのリクエストで１つのファイルを受信する（Ｇｅｔ受信方法）。また、サーバ側がクライアントに対してファイルの転送要求を出すことをＰｕｓｈ要求、または単にＰｕｓｈと呼称し、Ｐｕｓｈ要求で得られたファイルをＰｕｓｈファイル又はＰｕｓｈデータと呼称する。Ｐｕｓｈではクライアントは１つのリクエストで１つ以上のファイルを受信する（Ｐｕｓｈ受信方法）。このようにＧｅｔとＰｕｓｈでは受信方法が異なる。
以上で、対象プロトコルデータ構造の説明を終了する。

次に、対象プロトコルの簡単な通信手順について説明する。ここでは、通信開始から、何らかのデータ通信を行い、通信が終了するまでの手順を説明する。

まず、ＴＣＰコネクションが確立されたとする。この時点でサーバとクライアントは双方向の通信チャネルを保持している。次にコントロールフレーム４０１を用いてデータストリーム４０２の作成を行う。サーバ側でもクライアント側からでもデータストリーム４０２を作成することができる。ここでは、Ｗｅｂのコンテンツ取得を例として挙げる。

Ｗｅｂのコンテンツを取得するためにクライアントはサーバに対してＧｅｔ要求を行う必要がある。そのため、クライアントはコンテンツストリームを用いてデータストリーム４０２の作成要求を行う。この際、クライアントは作成したいデータストリームの優先順位と依存関係も設定する。サーバが作成要求を受け入れる場合はコントロールフレーム４０１を通して受け入れ許可を返信する。この際、サーバ側はデータストリーム４０２の作成を拒否することもできる。データストリーム４０２作成後、サーバとクライアントは作成したデータストリーム４０２を利用してＧｅｔ要求、またその返信を行うことができる。ここでは、全てのデータがデータストリーム４０２を介して送受信される。クライアントがサーバから必要データの受信を終えた場合、ストリームを閉じる必要がある。ストリームの終了要求は、クライアント側、サーバ側のいずれからでも行うことができる。ストリームの終了要求を受けた側は、送信するデータが無くなり次第、ストリームの終了要求を出し、ストリームを終了する。この際、意図的に片側が終了要求を出さないことで片方向通信を行うこともできる。

また、サーバ側からデータストリーム４０２を作成する例としてクライアント側からＧｅｔ要求に対して、動的にコンテンツをクライアントにＰｕｓｈするために新たなデータストリーム４０２を作成することが考えられる。ここで、対象プロトコルの通信において、ストリームの数は時間に応じて動的に変動する。

本明細書の情報処理装置の一実施形態としてのコンピュータについて説明する。図２は本実施形態のコンピュータの構成を説明するブロック図である。なお、特に断らない限り、本明細書に記載の機能が実行されるのであれば、単体の機器であっても、複数の機器から成るシステムであっても、本明細書の技術を利用できることは言うまでもない。また、特に断らない限り、本明細書に記載の機能が実行されるのであれば、ＬＡＮ、ＷＡＮ、インターネット等のネットワークを介して接続が為され、処理が行われるシステムであっても本明細書に記載の技術を適用できることは言うまでもない。

図２はコンピュータ２００の構成を示し、クライアントコンピュータ１０３の構成及び、サーバコンピュータ１０２の構成はコンピュータ２００の構成と同一である。コンピュータ２００はＲＯＭ２０２のプログラム用ＲＯＭあるいは外部記憶装置２０５に記憶された文書処理プログラムに基づいて、図形、イメージ文字、表（表計算等を含む）等が混在した処理を実行するＣＰＵ２０１を備える。さらに、システムバス２０４に接続される各デバイスをＣＰＵ２０１が統括的に制御する。また、これら以外に入出力装置を備えていても良い。

また、このＲＯＭ２０２のプログラム用ＲＯＭあるいは外部記憶装置２０５には、ＣＰＵ２０１の制御プログラムであるオペレーションシステム等を記憶する。また、ＲＯＭ２０２のデータ用ＲＯＭあるいは外部記憶装置２０５には各種データを記憶する。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能し、ネットワークＩ／Ｆ制御部２０６は、ＬＡＮ２０７とのデータの送受信を制御する。

図１において、ＬＡＮ２０７は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１により、サーバコンピュータ１０２とクライアントコンピュータ１０３が属するＬＡＮ２０７とは、ファイアウォールを越えて通信が可能である。ＬＡＮ２０７、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。図１において、サーバコンピュータ１０２は、１台のサーバとして示されているが複数台のサーバコンピュータで構成されていても構わない。また、仮想ＰＣとして構成されていても構わない。

加えて、ＣＰＵ２０１が外部記憶装置２０５に記憶されているプログラムに基づき処理を実行することによって、後述するフローチャートの各ステップの処理が実行される。

なお、以降の説明でコンピュータ２００はクライアントコンピュータ１０３を例として記述するが、プリント機能等を持つデバイス１０４やモバイル端末１０５、携帯電話１０６を始め、通信機能とデータをやり取りする端末であれば基本的に何でも構わない。また、仮想ＰＣとして構成されていても同じであるものとする。ここで、本明細書ではデータの取得要求を行う側をクライアント、データの提供を行う側をサーバと、役割で呼称している。このため、サーバ用途のコンピュータがクライアントとしてデータの取得要求を行い、クライアントコンピュータがサーバとしてデータ提供を行っても良いものとする。

この際、コンピュータ２００におけるソフトウェア構成は図５の構成から成る。まず、ネットワークＩ／Ｆ ５０１はＬＡＮ２０７から外部ネットワークと直接通信を行う部分でありネットワークＩ／Ｆ制御部２０６のソフトウェア処理部を示す。通信を行う際のデータの送受信キューはＴＣＰレイヤが管理しており、データの送受信キューにデータパケットが積まれた段階で、ＴＣＰ管理処理部５０２が必要に応じて通信を行う。ＳＳＬ／ＴＬＳ管理処理部５０３はＳＳＬ、ＴＬＳレイヤを管理する処理部である。本対象プロトコルにおいて、ＳＳＬ、ＴＬＳを利用することは必須ではないが、現実的にはセキュリティやファイアウォールの問題からＳＳＬ、ＴＬＳを利用する場合が多いため記述した。

ＳＳＬ／ＴＬＳ管理処理部５０３は、規格（ＲＦＣ２２４６、ＲＦＣ４３４６）に準拠した実施になっていれば、どのような実施方法でも構わない。また、この処理部がＳＳＬ、ＴＬＳ以外の中間プロトコルであっても構わない。データ送受信部制御部５０４はデータ送受信の際の待ち合わせや同期、通信ストリームの開始や終了処理を行う。キャッシュ管理部５０５は受信したデータのキャッシュテーブルへの登録や更新、削除、問い合わせ処理を行う。ここで取り扱うデータは物理ファイルのデータでも構わないし、機器のアドレス・状態・設定や属性等の一時的に用いるデータでも構わないものとする。キャッシュ格納部５０６はキャッシュ管理部５０５で扱うデータを実際に格納しておく領域であり、プログラム等の処理部ではない。本実施例では、外部記憶装置２０５を例として挙げるが、ＣＰＵ２０１のプロセッサ内のレジスタやＲＡＭ２０３、あるいはネットワークＩ／Ｆ制御部で用いるＡＲＰキャッシュも対象として含まれる。

図６はデータの送受信の制御を行うクライアント側の処理のフローである。Ｓ６０１ではサーバ側にデータのリクエスト、すなわちＧｅｔ要求を出す。ここでは、コントロールフレーム４０１を用いてストリームの生成を行う。この際の、コントロールフレームにはデータの識別名やデータ長を始めとする通信に必要な情報の他に、ストリームのＩＤと関連するストリームのＩＤやストリームの優先度情報が含まれる。Ｇｅｔ要求を出した後、実際にデータを受信するまで待ち合わせを行う（Ｓ６０２）。データの受信ステップＳ６０３では、データの受信と、受信データ（受信ファイル）を解析、キャッシュ領域にデータの格納を行う。ステップＳ６０４ではストリームが終了条件を満たしているかどうかの判定を行う。本明細書で対象プロトコルにおいてはサーバとクライアントが共にストリームの終了要求を行えば対象ストリームが終了するものとする。しかし、この他にもストリームの受付拒否やプロトコル違反等でのエラーでも通信を終了する。この場合についてもストリームが終了したものとみなす。

図７はデータの受信部分のクライアント側の処理を表すフローである。ここで、図８をデータ格納の際のキャッシュテーブルの一例として用いる。まず、ステップＳ７０１では受信データのヘッダ部分の解析を行う。ここでは、データの送受信に必要な情報はもちろんであるが、受信データをキャッシュ領域に格納するためのストリームのＩＤや関連するストリームのＩＤ、ストリームの優先度情報の抽出がこれに相当する。ステップＳ７０２ではサーバからの転送データがどうかの判別を行う。すなわち、受け取ったデータがＰｕｓｈされてきたものかどうかの判定を行う。本明細書では受け取ったデータを今までＧｅｔしていないデータであるか判定し、受け取ったデータがＧｅｔしていないデータである場合にＰｕｓｈされたデータであると判定する。受け取ったデータが今までＧｅｔしていないデータであるか判定は、Ｇｅｔしたデータの一覧を保持しておくことにより実現できる。判定の結果、サーバからの転送データとされた場合はステップＳ７０３でＰｕｓｈされてきたデータであることを示すフラグを設定し、ＲＡＭ２０３に格納する。ユーザが要求を出して取得したデータであるとされた場合はステップＳ７０４でＧｅｔしたデータであることを示すフラグを設定し、ＲＡＭ２０３に格納する。こうしたフラグの設定はプッシュされてきたデータかどうかを示すＰｕｓｈフラグ情報８０３としてキャッシュテーブルに登録することで実現される。ここでは、Ｇｅｔしたデータは０、Ｐｕｓｈされてきたデータは１として登録している。ステップＳ７０５ではストリームの優先順位情報８０４を登録する。ここでの優先順位とは通信の際にストリームに設定されている値を指すが、クライアントアプリケーション側であらかじめ優先順位の段階が指定されている場合、例えば低・中・高の３段階が指定されている場合は、その値に丸めて登録を行っても良い。ステップＳ７０６ではストリームのグループ情報、つまり該当するストリームと該当するストリームに関連するストリームの情報の登録を行う。関連するストリームＩＤ８０６の情報はサーバがクライアントに送信する情報である。よって、クライアントは取得した関連するストリームＩＤ８０６を図８のキャッシュテーブルにそのまま登録する。ステップＳ７０７では、キャッシュテーブルに受信したデータが登録済みかどうかの判定を行う。登録されていない新規データであった場合はステップＳ７０８に移行し、キャッシュテーブルに受信データ情報の行を追加する。登録済みのデータであった場合はステップＳ７０９に移行し差分データの更新を行う。この際、データとしての変更が無くともＰｕｓｈフラグ情報がＰｕｓｈからＧｅｔに移行する場合に関してはＰｕｓｈフラグ情報をＧｅｔしてきたもの（０）として更新を行う。

ステップＳ７１０ではＰｕｓｈ又はＧｅｔにより受信したデータの保存（Ｐｕｓｈ保存又はＧｅｔ保存）を行う。この際、ＰｕｓｈとＧｅｔは別のディレクトリに保存しても構わないし、あるいはＰｕｓｈとＧｅｔを保存するステップをそれぞれ１つずつ設けることで実現しても構わない。ステップＳ７１０の処理が終了することにより図７の処理が終了する。

図９はキャッシュテーブル内に登録されたデータの削除を行う処理のフローである。この処理はキャッシュ容量がユーザ、ないしアプリケーションで設定されている既定の容量を超えた場合に呼び出される。例えばデータの受信の際のデータ解析Ｓ７０１を行った直後に呼び出される。キャッシュの削除処理が呼び出されると、まずステップＳ９０１でキャッシュへの追加対象データ、つまり受信したデータの情報解析を行う。ここで行うのはステップＳ７０２のＧｅｔデータかＰｕｓｈデータかの判別と同じ処理である。既に判定できている場合は、既存の判定結果を用いても良い。

ステップＳ９０２はキャッシュを削除する必要があるかどうかの判定を行う。

キャッシュを削除する必要があるかどうかの判定は例えば、キャッシュの空き領域が受信中のファイルサイズ以下であった場合、物理的にキャッシュにファイルを格納することができないため、キャッシュを削除する必要がある判定となる。これは追加対象データ（新たに受信したデータ）とキャッシュの合計容量が所定の容量を超えたかどうかを判断するのと同じである。この時に合計容量はＧｅｔデータとＰｕｓｈデータの合計であっても良い。

あるいは合計容量をＧｅｔデータとＰｕｓｈデータで別々に計算しても良い。このように構成した際は、追加対象データがＧｅｔである場合にはＧｅｔの合計容量が所定の容量を超えたかどうか判断し、追加対象データがＰｕｓｈである場合にはＰｕｓｈの合計容量が所定の容量を超えたかどうか判断してもよい。ＧｅｔデータとＰｕｓｈデータで別々に計算するように構成することでＧｅｔデータとＰｕｓｈデータをバランス良く削除することが出来る。

その他にもユーザないしシステムが予め指定した空き容量になるまでキャッシュを削除する判定としても良い。

ステップＳ９０３は、ステップＳ９０１での結果に基づき、受信したデータがＧｅｔで得たものかＰｕｓｈで得たものかを判断する。受信データがＰｕｓｈされてきた場合はステップＳ９０４に移行し、キャッシュテーブル内のＰｕｓｈフラグが有効な（値が１となっている）ものの中で最も削除優先順位が高いものを削除する。図８を例とし、まず通常のキャッシュ削除に関して説明する。単に有効期限情報８０１のみに基づきデータを削除する判断を行うと、有効期限８１２が最も古く設定されているため、通常の削除対象はキャッシュデータ８１０となる。それに対し、ステップＳ９０４の処理で削除対象となるのは、Ｐｕｓｈフラグ情報８０３が有効な（値が１となっている）中で最も有効期限８１２が古く設定されているキャッシュデータ８０８となる。受信データがＧｅｔして得たものだった場合はステップＳ９０５に移行し、Ｐｕｓｈフラグ情報８０３が無効な（値が０となっている）中で削除優先順位が最も古いデータを削除する。図８の例ではキャッシュデータ８１０が削除対象となる。

なお、Ｓ９０５は設けないように構成しても構わない。このように構成した場合はＧｅｔデータをＰｕｓｈデータとは異なる条件（例えばＧｅｔデータを取得後の経過時間）で削除する方法が考えられる。Ｓ９０５を設けないことでＰｕｓｈデータのみを優先的に削除する構成にすることが可能となる。

さらにはＳ９０３とＳ９０４とＳ９０５の各ステップをＳ９０４のステップに置き換える構成としてもよい。このように構成した場合は特に追加対象データがＧｅｔデータであるかＰｕｓｈデータであるかの判定は行われない。その代わりにＳ９０２でキャッシュを削除する必要があると判断された場合にはＳ９０４でＰｕｓｈデータのキャッシュを削除する。これにより前述の構成と同じくＰｕｓｈデータのみを優先的に削除する構成にすることが可能となる。

以上の処理を行うことで、キャッシュ領域中のＧｅｔデータとＰｕｓｈデータを互いに干渉しないよう別々に管理することができる。なお、図８の例では削除優先順位の決定に有効期限情報８０１を用いて説明を行ったが、実際にはデータのサイズ、参照回数、最後に参照されてからの期間、データの取得日時等のパラメータを基に削除優先順位を決めても良い。また、それら各パラメータに重みを付け、組み合わせて削除優先順位を決めても良いものとする。

実施例１におけるキャッシュ管理方法では、キャッシュ領域内のデータから最も使用する可能性の低いものを選定し、削除を行っていた。しかし対象プロトコルの通信方法におけるＰｕｓｈデータは本来ユーザが取得要求を出したものではなく、関連したデータのやり取りが無くなった場合、即不要となる可能性が高い。本実施例では、例えば図４のセッション４００が終了（例えばＧｅｔデータの取得のキャンセルを含む）した場合、終了したセッション内のストリーム１からストリームｎにおいて取得したデータを一括して削除する方法について記載する。

図１０は他のキャッシュと関連付いたキャッシュデータを削除する処理を示したフローである。この時の関連付けとは通信時にストリーム同士につけられた関連を指す。また、図８を例として説明を行う。

このフローで表された処理は、通信セッションが終了してユーザが取得要求を出したデータが不要になった際に呼び出される。ユーザが取得要求を出したデータが、例えばキャッシュデータ８１０であった場合、キャッシュデータ８１０をキャッシュデータＡとして図１０のフローを呼び出す。

ステップＳ１００１では、指定されたキャッシュデータＡに関連するキャッシュデータが存在するかどうかを判定する。図８では例えば、キャッシュデータ８１０のストリームＩＤ８１４が関連するストリームＩＤ８１６として登録されているキャッシュデータ８１１が存在するためステップＳ１００２の処理に移行する。ステップＳ１００２では未処理の関連キャッシュデータを取得する。図８の例では、キャッシュデータ８１１が取得される。

取得したキャッシュデータに対し、ステップＳ１００３では再帰的に図１０のフローを呼び出し、処理をさせている。こうすることでキャッシュデータ８１１が、さらに関連キャッシュを持つ多階層構造であったとしても再帰的に処理を呼び出し、キャッシュを削除することが可能となる。図８の例では、キャッシュデータ８１１と、それに関連したキャッシュデータがこの処理で削除される。ステップＳ１００１で未処理のキャッシュデータが存在しなくなった段階でステップＳ１００４に移行する図１０のフローに渡されたキャッシュデータが削除される。図８の例では、キャッシュデータ８１０が削除される。

なお、Ｓ１００３ではＰｕｓｈデータのみを削除するか、Ｇｅｔデータのみを削除するか、あるいは両方を削除するかのどのように構成しても構わない。

以上の処理を行うことで、関連したデータのやり取りが無くなった場合に関連するストリームのキャッシュデータを削除することができる。

対象プロトコルでは通信の際、ストリームに優先度を設定することが可能である。よって、本実施例ではストリームの優先度を、キャッシュデータを保存する優先順位とみなして処理を行う例について説明する。図１１に削除優先順位の計算にストリームの優先度情報を利用したフローを示す。

なお、図１１のフローに基づいて処理をせずとも図９のＳ９０４とＳ９０５の削除優先順位をストリームの優先順位を用いて決定しても構わない。

図８ではキャッシュデータの有効期限情報８０１が最も古い有効期限８１２を持つキャッシュデータ８１０が削除対象として選択されることを説明した。ここで本実施例では、さらに優先順位情報８０４を用いて判断を行い、最も低い優先度８１３を持つキャッシュデータ８０９が削除対象として選択される。

ステップＳ１１０１ではキャッシュを削除する必要があるかどうかの判定を行う。この判定は図９のステップＳ９０２の処理と同様であるため詳細は省略する。ステップＳ１１０２ではキャッシュテーブルの先頭データを削除対象として選択する。図８の例ではキャッシュデータ８０７が、まず削除対象として選択される。ステップＳ１１０３ではキャッシュテーブル内に未参照のデータが存在しているかどうかを判定し、全データが参照されるまでステップＳ１１０４からＳ１１０７までの処理を繰り返す。ここで未参照のデータＳ１１０４でまだ取得されていないデータを意味する。

ステップＳ１１０４ではキャッシュテーブルから現在参照中のデータの次のデータを取得する。図８の例では現在、キャッシュデータ８０７が参照されているためキャッシュデータ８０８が取得される。ステップＳ１１０５では取得データの優先順位情報８０４と現在削除対象のデータの優先度を比較している。図８の例では、取得したキャッシュデータ８０８の優先度は３であり、現在削除対象として選択されているキャッシュデータ８０７の優先度０よりも低い。このため、ステップＳ１１０７では選択されたキャッシュデータ８０８を新たな削除対象データとして設定する。また、取得したデータの優先度と削除対象データとして選択されているデータの優先度が同じ場合は、さらにステップＳ１１０６の判定で、削除優先順位がより高いものが削除対象として選択される。これらの処理を繰り返し、最終的に最も優先度が低く、削除優先順位の高いデータがステップＳ１１０８の処理で削除される。

これによりキャッシュデータを保存する優先順位としてストリームの優先度を用いた通信を行った際に適切な処理を行うことができる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。

即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (12)

1. １つのリクエストで１つのファイルを受信するＧｅｔ受信方法により受信するファイルを保存するＧｅｔ保存手段と、
   前記Ｇｅｔ保存手段が保存したファイルを含む受信ファイルの合計が所定の容量を超えてかつ新たにファイルを受信したと判断した場合に前記Ｇｅｔ保存手段が保存したファイルを削除するＧｅｔ削除手段と、
   １つのリクエストで複数のファイルを受信する、前記Ｇｅｔ受信方法とは異なる受信方法であるＰｕｓｈ受信方法により受信するファイルを保存するＰｕｓｈ保存手段と、
   前記Ｐｕｓｈ保存手段が保存したファイルを含む受信ファイルの合計が所定の容量を超えてかつ新たにファイルを受信したと判断した場合に前記Ｐｕｓｈ保存手段が保存したファイルを前記Ｇｅｔ削除手段の前記Ｇｅｔ保存手段が保存したファイルの削除よりも優先して削除するＰｕｓｈ削除手段と、を有することを特徴とする情報処理装置。
2. 前記Ｐｕｓｈ削除手段及び前記Ｇｅｔ削除手段は、受信するファイルの、有効期限情報又はファイルのサイズ、参照回数、最後に参照されてからの期間、取得日時、ストリームの優先順位の少なくとも１つに基づいて前記Ｐｕｓｈ保存手段又は前記Ｇｅｔ保存手段が保存したファイルを削除することを特徴とする請求項１に記載の情報処理装置。
3. 前記Ｐｕｓｈ削除手段及び前記Ｇｅｔ削除手段の受信ファイルの合計は前記Ｐｕｓｈ受信方法により受信するファイルと前記Ｇｅｔ受信方法により受信するファイルの合計であることを特徴とする請求項１又は請求項２に記載の情報処理装置。
4. 前記Ｐｕｓｈ削除手段は、前記Ｇｅｔ受信方法によるファイルの取得をキャンセルした場合に前記キャンセルしたファイルのセッション内で前記Ｐｕｓｈ受信方法により受信したファイルを削除することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. コンピュータを、
   １つのリクエストで１つのファイルを受信するＧｅｔ受信方法により受信するファイルを保存するＧｅｔ保存手段、
   前記Ｇｅｔ保存手段が保存したファイルを含む受信ファイルの合計が所定の容量を超えてかつ新たにファイルを受信したと判断した場合に前記Ｇｅｔ保存手段が保存したファイルを削除するＧｅｔ削除手段、
   １つのリクエストで複数のファイルを受信する、前記Ｇｅｔ受信方法とは異なる受信方法であるＰｕｓｈ受信方法により受信するファイルを保存するＰｕｓｈ保存手段、
   前記Ｐｕｓｈ保存手段が保存したファイルを含む受信ファイルの合計が所定の容量を超えてかつ新たにファイルを受信したと判断した場合に前記Ｐｕｓｈ保存手段が保存したファイルを前記Ｇｅｔ削除手段の前記Ｇｅｔ保存手段が保存したファイルの削除よりも優先して削除するＰｕｓｈ削除手段、として機能させることを特徴とするプログラム。
6. 前記Ｐｕｓｈ削除手段及び前記Ｇｅｔ削除手段は、受信するファイルの、有効期限情報又はファイルのサイズ、参照回数、最後に参照されてからの期間、取得日時、ストリームの優先順位の少なくとも１つに基づいて前記Ｐｕｓｈ保存手段又は前記Ｇｅｔ保存手段が保存したファイルを削除することを特徴とする請求項５に記載のプログラム。
7. 前記Ｐｕｓｈ削除手段及び前記Ｇｅｔ削除手段の受信ファイルの合計は前記Ｐｕｓｈ受信方法により受信するファイルと前記Ｇｅｔ受信方法により受信するファイルの合計であることを特徴とする請求項５又は請求項６に記載のプログラム。
8. 前記Ｐｕｓｈ削除手段は、前記Ｇｅｔ受信方法によるファイルの取得をキャンセルした場合に前記キャンセルしたファイルのセッション内で前記Ｐｕｓｈ受信方法により受信したファイルを削除することを特徴とする請求項５乃至７のいずれか１項に記載のプログラム。
9. １つのリクエストで１つのファイルを受信するＧｅｔ受信方法により受信するファイルを保存するＧｅｔ保存工程と、
   前記Ｇｅｔ保存工程が保存したファイルを含む受信ファイルの合計が所定の容量を超えてかつ新たにファイルを受信したと判断した場合に前記Ｇｅｔ保存工程が保存したファイルを削除するＧｅｔ削除工程と、
   １つのリクエストで複数のファイルを受信する、前記Ｇｅｔ受信方法とは異なる受信方法であるＰｕｓｈ受信方法により受信するファイルを保存するＰｕｓｈ保存工程と、
   前記Ｐｕｓｈ保存工程が保存したファイルを含む受信ファイルの合計が所定の容量を超えてかつ新たにファイルを受信したと判断した場合に前記Ｐｕｓｈ保存工程が保存したファイルを前記Ｇｅｔ削除工程の前記Ｇｅｔ保存工程が保存したファイルの削除よりも優先して削除するＰｕｓｈ削除工程と、を有することを特徴とする制御方法。
10. 前記Ｐｕｓｈ削除工程及び前記Ｇｅｔ削除工程は、受信するファイルの、有効期限情報又はファイルのサイズ、参照回数、最後に参照されてからの期間、取得日時、ストリームの優先順位の少なくとも１つに基づいて前記Ｐｕｓｈ保存工程又は前記Ｇｅｔ保存工程が保存したファイルを削除することを特徴とする請求項９に記載の制御方法。
11. 前記Ｐｕｓｈ削除工程及び前記Ｇｅｔ削除工程の受信ファイルの合計は前記Ｐｕｓｈ受信方法により受信するファイルと前記Ｇｅｔ受信方法により受信するファイルの合計であることを特徴とする請求項９又は請求項１０に記載の制御方法。
12. 前記Ｐｕｓｈ削除工程は、前記Ｇｅｔ受信方法によるファイルの取得をキャンセルした場合に前記キャンセルしたファイルのセッション内で前記Ｐｕｓｈ受信方法により受信したファイルを削除することを特徴とする請求項９乃至１１のいずれか１項に記載の制御方法。

Images