JPH0970018A - ファイルサーバ - Google Patents

Abstract

(57)【要約】 【構成】ファイルサーバと複数の端末がネットワークを
介して接続されるネットワークファイルシステムで、フ
ァイルサーバ１０１はネットワークとのやりとりを司る
ネットワークインタフェース１２１と、デジタルデータ
を一時的に蓄え、端末への配送を司る端末対応バッファ
処理部１１１と、ファイルサーバ１０１に接続している
端末からのコマンドを各端末対応バッファ処理部１１１
に分配する端末コマンド分配部１３１と、端末対応バッ
ファ処理部１１１からのディスクリード要求を一括的に
処理するディスクスケジューラ部１４１と、デジタル映
像データを蓄積する磁気ディスク装置１５１とからな
る。 【効果】格納した映像データをより多くの端末へ早いレ
スポンスで送ることが可能になり、接続している端末の
数が多くても、端末で質の高い映像再生ができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はデジタルデータを蓄積，
配送するファイルサーバに関する。

【０００２】

【従来の技術】従来、複数の端末が一台の計算機のディ
スク上のデータを共有するためのシステムは、ＳＵＮ
MicroSystem社が提案するネットワークファイルシステ
ム(NFS)がある。これは、蓄積装置の中にあるデータを
提供するファイルサーバと、データを利用する複数の利
用者端末と、それらを結び付ける通信手順からなる。現
在のところ、ファイルサーバにおけるデータ蓄積の手段
は、磁気ディスクあるいは光磁気ディスクがコストの面
で適当である。このシステムを用いると、複数の計算機
が、ファイルサーバの磁気ディスク上のテキストデータ
や実行バイナリを利用することができる。

【０００３】サーバは各利用者端末からディスク上のデ
ータのファイル名とオフセットとサイズを指定して要求
してくる。ファイルサーバはそのリード要求を受け取る
と、ディスクから該当するデータを読み出し、ネットワ
ークを介して利用者端末に送る。ネットワークファイル
システムでは、伝送効率を最適なものにするために、利
用者端末の上のアプリケーションが大量のデータをファ
イルサーバから読み込もうとしても、端末からファイル
サーバへのリード要求は細かく分割され、繰り返し出さ
れる。端末上のアプリケーションが大量のデータをサー
バに要求する時は、端末はファイルサーバに対して複数
回にわたって繰り返し要求する。ファイルサーバでは、
細かく分けられたリード要求に対して、特にディスク上
のキャッシュがヒットしない限り、毎回ディスクリード
を行う。

【０００４】端末側では、ファイルサーバのデータを自
分のディスクのデータと同じインタフェースで端末上の
アプリケーションに提供することにより、利用者端末は
あたかも自分のディスクにアクセスしているように、フ
ァイルサーバのデータをアクセスすることを可能として
いる。

【０００５】ファイルサーバに接続することができる端
末の数は、あらかじめ設定しておくことによって決ま
る。構造的には制限はないが、つながっている端末の数
が多くなるほど、各端末へのレスポンスは悪くなる。

【０００６】

【発明が解決しようとする課題】ＣＤ−ＲＯＭ上のデジ
タル映像を読み込むことによって動作するアプリケーシ
ョンは数多く存在する。このＣＤ−ＲＯＭ上のデジタル
映像データを一台のファイルサーバに貯えて共有する
と、大量の映像データを各端末で持つ必要がなくなり、
蓄積コストを下げることにつながる。しかし、ネットワ
ークファイルシステムは従来、テキストデータやバイナ
リデータの共有を前提にしているので、一般に映像デー
タの規模が大きいことと、映像データはデータ転送の際
に時間軸の制限を持つため、映像データの共有には、い
くつかの問題を生じる。

【０００７】映像データのような大量のデータを端末が
要求すると、ファイルサーバ内では繰り返しディスクリ
ードを発行することになる。そのため、複数の利用者端
末に対してファイルサーバが映像データの配送を行う
と、ディスクリードに時間を多く費やしてしまい、ディ
スクリードがボトルネックになってしまう。よって、映
像サーバとしてのファイルサーバに同時に接続すること
ができる端末の数が少なくなる。

【０００８】一般に、映像の再生を行っている端末は、
要求したデータを限られた時間内に得られないと、正し
い映像の再生が行えない。従来のファイルサーバは映像
データの配送を前提にしていないため、ファイルサーバ
に接続している端末の数が多くなって、ディスクへのア
クセスが多くなると、各端末からの要求に対するレスポ
ンスが悪くなり、その結果端末で表示する映像データが
乱れる。

【０００９】従来のファイルサーバは、接続できる端末
の数を前もって決めておかなければならない。しかし、
動画の配送の場合、ディスクリードに余裕があるかどう
かで、配送可能な端末の数が決まってくる。あらかじめ
決めてしまうと、ディスクに余裕があるのに、端末の接
続を拒否したり、逆にディスクに余裕がないのに端末の
接続をしてしまい、他の端末への配送の邪魔をしてしま
う可能性がある。

【００１０】

【課題を解決するための手段】端末が映像の表示を目的
としてサーバのデータを要求する時は、ファイルサーバ
に端末からの一回目のリード要求の後、周期的に繰り返
しかつ連続した要求がやって来ることが予測できる。そ
こでファイルサーバでは、端末から要求された量より多
くディスクリードを行い、大容量のバッファに蓄えてお
く。以降のディスクリードに対して、要求されたデータ
がバッファの中から取り出して利用者端末に送る。これ
によって、磁気ディスクのアクセス頻度を押さえ、読み
出し効率を上げることができる。

【００１１】また、バッファ上のデータを順に取り出し
てそのデータを送りつくした場合、再びディスクリード
を行うが、ディスクリードを行っている間も送り続けな
ければいけないので、バッファを二つに分けて用い、交
互に使用する。片面のデータを使い果たした場合、その
面のディスクリードを行っている間に、もう一面のバッ
ファからデータをネットワークに送り出す。これによっ
て、常に端末への配送は高速な記憶領域上のバッファか
ら行うことができ、早いレスポンスを保証することがで
きる。

【００１２】利用者端末からの映像データリード要求が
連続してやってくる場合、ファイルサーバは大容量バッ
ファに周期的に映像データを補給しなければならない。
補給のためのディスクリードは、他方の一面が使われて
いる間、それが枯渇するまでに行わなければならない。
つまり、異なる配送処理ごとにディスクリードのデッド
ラインが毎回設定される。これは端末ごとにデータが異
なるので、ビットレートが異なり、その結果、毎回のデ
ッドラインまでの時間も、配送処理によって異なる。複
数の配送部が動いている時、このディスクリードは全て
の端末への配送のデッドラインが守られるような順番で
行われるように、スケジューラ装置がディスクリードの
順番を管理する。この結果、バッファ部上へのデータが
配送が始まるまでにディスクリードが必ず完了させるこ
とができる。

【００１３】ただし、端末側ではバッファリングをし、
ある程度まとめてリードを行ってくる可能性がある。そ
の時はファイルサーバ内のバッファが早く枯渇すること
になるので、ディスクリードのデッドラインまでの時間
を、何％か短くすることによって対処する。

【００１４】また、端末側は映像データを表示以外の目
的で要求してくる場合も有り得る。その場合、データの
ビットレートを無視し、高いビットレートで要求してく
る。これに対して、ファイルサーバの配送処理部は、例
えバッファ部のデータが早く枯渇しても、そのバッファ
部を使い始めた時刻から、データのビットレートから決
まるディスクリード間隔にある割合をかけた時間がたっ
て初めてディスクリードを行う。これによって、一端末
のために集中的にディスクリードを行って、他の端末へ
の配送の邪魔をすることを防ぐことができる。

【００１５】ファイルサーバではディスクリードが限界
に達した時、配送能力が限界に達する。単位時間あたり
のディスクリードの量は、ファイルサーバの合計の配送
ビットレートから決まる。そこで、ファイルサーバ内で
は最大配送ビットレートをあらかじめ求めておき、新た
に端末から要求が来た時に、現在の合計ビットレート
に、新たに要求してきたデータのビットレートを加え
て、配送可能かどうかを調べることができる。不可能だ
と判断した場合は、利用者端末のリード要求は拒否され
る。可能であると判断できた場合は配送装置は実際にデ
ィスクリードを行い、利用者端末に配送する。この処理
によって、新たな端末への配送が加わったことによって
ディスクリードの能力の限界を越え、既に接続している
端末への配送を邪魔することを避けることができる。

【００１６】

【作用】ファイルサーバで、映像データの配送の際、磁
気ディスクのアクセス頻度を押さえ、読み出し効率を上
げることができる。また、常に端末への配送は高速な主
記憶上のバッファ部から行うことができる。その結果、
端末からの要求に対して、早いレスポンスを保証するこ
とができる。

【００１７】

【実施例】図４は本発明が適用されるネットワーク環境
の例である。ネットワーク４０１は多くの場合、ローカ
ルエリアネットワーク（ＬＡＮ）であり、利用者端末装
置４２１，４２２，４２３．．．はネットワークファイ
ルシステムをサポートするものとする。この環境に本発
明のファイルサーバ１０１を適用することが可能であ
る。

【００１８】図３は本発明のファイルサーバのブロック
図である。映像データは磁気ディスク装置１５１に蓄え
られているものとする。この構成で、ディスクからデー
タを読み出して主記憶装置３２１に格納している間も、
主記憶装置内の別の部分から読み出しを行い、バスを介
してネットワーク装置へ送り出すことが可能である。

【００１９】図１は本発明のファイルサーバの機能ブロ
ック図である。ファイルサーバ101は、磁気ディスク装
置１５１，ディスクスケジューラ部１４１，端末コマン
ド分配部１３１，ネットワークインタフェース１２１、
及び端末対応バッファ処理部１１１，１１２，１１３，
１１４．．．からなる。ファイルサーバは、接続してい
る利用者端末の数だけ端末対応バッファ処理部を持つ。

【００２０】図２は端末対応バッファ処理部のブロック
図である。これは第一バッファ部２２１，第二バッファ
部２２２，配送処理部２０１，ディスクリード要求発行
部２１１からなる。

【００２１】初めて利用者端末からリード要求が来た
時、配送処理部は蓄積装置からディスクリードをａバイ
ト行い、読み出したデータを一旦主記憶内のバッファ部
に蓄える。端末が要求してきたデータが映像データであ
る場合は、リード要求は以後連続的に繰り返し行われる
可能性が高い。そこで、ａは利用者からリード要求のあ
ったバイト数よりも大きな値に定める。以降利用者端末
からリード要求があった時は、バッファから取り出して
送ることによって大幅にディスクリードの回数を減ら
し、ディスクリードによるオーバーヘッドを減らすこと
ができる。

【００２２】配送処理部が、利用者端末からのリード要
求で指定されたデータをバッファ内から配送しようとし
ても、必要なデータがバッファ内に存在しない場合が、
最初のリード要求時以外に２通り有り得る。一つは、バ
ッファを連続的に消費し、使い切った場合である。この
時、補充をしなければならないので、補充の間も送り続
けられるようにバッファをもう一面用意しておく。最初
のリードの時は２枚分のリードを行い、それ以降１枚を
使い終えるたびにディスクリードを行い、その間に他方
から端末への配送を行う。リード要求に対して、指定さ
れたデータがバッファ内に存在しない場合のもう一つ
は、利用者からのリード要求が前回の要求とは連続しな
いために二つのバッファの中に存在しない場合である。
この時は、最初の２枚のバッファのリードからやり直
す。

【００２３】図５は、利用者端末からデータリード要求
が来てから、配送処理部が２枚のバッファを交互に使用
して利用者にデータを送る手続きを表している。これは
端末からの一回目のリード要求がきっかけとなって始ま
る。端末からあるファイルに対してオフセットｘ，サイ
ズｓのリード命令が来たとする。これに対して、配送処
理部はサイズａのディスクリード要求をディスクスケジ
ューラに２度出す。ａは、ｓより大きい値に設定する。
このようにして先読みすることによって、ディスクリー
ドのオーバーヘッドを少なくすることができる。

【００２４】処理には四つの場合が有り得る。第一の場
合は、読み取るデータがすべてバッファＸの中にある場
合である。流れ図の５０９はこの時の処理を示してい
る。第二の場合は読むべきデータの前半がバッファＸの
中で、後半がバッファＹの中にある場合である。その時
は流れ図の中の５１１〜５１５のようになる。第三の場
合は、読み出すデータが全くバッファＸの中に存在せ
ず、すべてバッファＹの中に存在する場合である。その
時は流れ図の５１６〜５１９のようになる。

【００２５】図６〜図８は上記三つのそれぞれの場合の
バッファを示している。第四の場合は、読み出そうとす
るデータが全くバッファＸまたはＹに存在しない場合で
ある。その時は矢印５１６または５１７の分岐で最初に
戻る。

【００２６】図９は、二つのバッファから端末へデータ
を配送しながら、ディスクリードによって補充していく
様子を示している。図の斜線部分はデータが入っている
ことを表わす。上で述べたように、一つのバッファを使
い果たすと、もう一つのバッファから配送を行い、その
間データの補充を行う。ディスクスケジューラ部は全て
の映像データのビットレートを管理しており、リード要
求発行部はディスクスケジューラ部に問い合わせること
により、現在配送しているデータのビットレートを知
る。これに基づき、補充を完了させなければならないデ
ッドライン時刻を求め、ディスクリードの要求を出す時
に、デッドライン時刻も与える。ファイルサーバ内のバ
ッファサイズをａ、映像データのビットレートをｒとす
ると、ビットレート通りのリード要求が端末から来た場
合、一つのバッファを使い果たすのにかかる時間はａ／
ｒである。ディスクリード要求を出した後、ａ／ｒ後の
時刻がデッドライン時刻となる。

【００２７】ディスクスケジューラはデッドラインを守
ってディスクリードを行うことにより、ファイルサーバ
は端末へ早いレスポンスを保証することができる。

【００２８】しかし、通常、端末上のアプリケーション
も何バイト分かをバッファリングすると考えられる。そ
のため、ファイルサーバに対するリード要求はバッファ
リングの時に局所的にビットレートが上がる。その時、
上で述べたデッドラインぎりぎりにディスクリードを完
了した場合、使われ始める時刻に間に合わないことが有
り得る。そのため、デッドライン時刻にはマージンを設
定し、余裕を持ってディスクリードを完了させる必要が
ある。配送処理部はデッドラインとしてαａ／ｒ（ただ
し、０≦α≦１）後の時刻を設定する。これによって、
一時的に高いビットレートで要求が来ても、バッファか
らの配送を行うことができる。

【００２９】αの求め方は、以下の通りである。端末側
でｕバイトのバッファを持っており、ファイルサーバ側
でａバイトのバッファを持つとすると、サーバ側でバッ
ファからデータを配送している間に多くてｕバイトのゆ
らぎがあることになるので、ａ／ｕの割合だけデッドラ
インが早くなる可能性がある。そこで、α＝ａ／ｕとす
ればよい。

【００３０】端末では、ファイルサーバに対して、映像
データを映像再生の目的でなく、単に端末へ取り出すこ
とを目的として要求する可能性もある。もし単に取り出
すだけならば、映像データのビットレートよりも高いビ
ットレートで要求をしてくることが考えられる。その場
合、高いビットレートの要求に従って配送を行ってしま
うと、ファイルサーバでＣＰＵの能力を一つの端末にだ
けにつぎ込んでしまい、他の端末への配送がおろそかに
なってしまう可能性がある。

【００３１】そこで、ファイルサーバでは、ディスクリ
ードは必ず一定時間をあけて行うようにする。図９では
Ａバッファが枯渇した後に直ちに補充しているのに対し
て、図１０に示すように、端末からの高いビットレート
での要求によってＡが早く枯渇しても、リード要求発行
部はＢのディスクリードを要求した時刻からαａ／ｒた
って初めてＡのディスクリード要求をスケジューラに出
す。この時、Ａが満たされるまでにＢが枯渇してしまう
可能性があり、端末の要求に対して直ちに配送を行えな
い状態が発生する。この場合、スケジューラがＡのディ
スクリードを完了させた後に、Ａのバッファからデータ
の配送を再開することができる。この処理によって、一
つの配送だけで、ＣＰＵの能力を費やしてしまうことを
避けることができる。

【００３２】次に複数の配送処理部から受け取るディス
クスケジューリング部について述べる。図１２及び図１
３に示すように、配送処理部から出されたディスクリー
ド要求は、ディスクスケジューリング部内の待ち列にた
められる。

【００３３】配送処理部がスケジューラにディスクリー
ドの要求を出すきっかけは３通りある。一つは端末がデ
ータのビットレートに従って、一つのデータを連続的に
リードした結果、バッファ部内のデータを使い果たした
ために必要となるディスクリードである。二つめは、端
末で例えば早送りなどの特殊再生のためにデータを要求
してきた結果、バッファ部内のデータが不必要となり、
新たにデータを必要とするために起こるディスクリード
である。三つめは、新たに端末がリード要求を始めた時
の最初のディスクリードである。以上の三つのディスク
リードにモードを定め、それぞれモード０，モード１，
モード２とする。

【００３４】モード０の場合、すなわち通常の連続ディ
スクリードの場合は、ディスクリードにデッドライン時
刻が存在する。バッファの大きさをａ、ビットレートを
ｒとすると、ディスクリード要求を受けてからａ／ｒ秒
後がデッドライン時刻となる。それに対して、モード１
やモード２の場合、デッドライン時刻は存在しない。

【００３５】図１２に示すように、配送処理部がリード
要求を行う際には、読み込むバッファの識別子，ファイ
ルの識別子，読み込むデータのオフセット，サイズ，読
み込みのデッドライン時刻、及び上で述べたモードを与
える。

【００３６】図１３に、要求待ち列挿入部のブロック図
を示す。読み込むバッファの識別子をｂ、ファイルの識
別子をｆ、読み込むデータのオフセットをｅ、サイズを
ｓ、読み込みのデッドライン時刻をｄ、及び上で述べた
モードをｐとする。待ち列にはこれらの情報が格納され
ている。待ち列に挿入するアルゴリズムを図１４に示
す。このアルゴリズムでは、モード０のリード要求に関
しては、デッドラインが常に早い順にソートされるよう
に挿入する。挿入されると、予定リード時刻ｔが計算さ
れる。これは、その直前の要求の予定リード時刻に、そ
の要求によって行われるディスクリードの時間をたすこ
とによって決まる。

【００３７】予定リード時刻がデッドラインより後にな
る場合、この要求のデッドラインは満たされないことに
なる。しかし、その要求より先に順序されている要求の
中に、映像データ以外のデータのリード要求や、モード
２，モード１の要求が存在すれば、これらの要求を後に
まわすことによって、新規要求を前倒しする。これによ
って、ディスクリードのデッドラインを満たすようにす
る、あるいはデッドラインに対する遅れを最小限に押さ
えることができる。

【００３８】図１１はある周期Ｔの間に複数の配送処理
部が一定時間間隔で順番にディスクリードを行っている
様子を示している。

【００３９】ある時間周期Ｔで、同時にｎ個の端末に配
送を行っているとする。端末要求分配装置は、現在接続
中の端末が要求している映像データのビットレートを知
っており、それぞれｒ１〜ｒｎとする。９０１〜９１２
に示されるｚは一回のディスクリードにかかる時間を表
わし、バッファの大きさをａとすると、端末ｒｉのディ
スクリードの間隔はａ／ｒｉ、ディスクリード間隔にマ
ージンを考慮するとαａ／ｒｉ（ただし、０≦α≦１）
となり、時間Ｔ内のディスクリード回数はＴ／（αａ／
ｒｉ）だから、全ての端末に対するディスクリードの時
間は、ｚＴ／（αａ／ｒ１）＋ｚＴ／(αａ／ｒ２)＋…
＋ｚＴ／(αａ／ｒ１)＝ｚＴ（ｒ１＋…＋ｒｎ）／αａ
となる。すべてのディスクリードが可能となるために
は、これがＴ以下になる必要があり、ｚＴ(ｒ１＋…＋
ｒｎ)／αａ＜Ｔすなわち、ｚ（ｒ１＋…＋ｒｎ）／α
ａ＜１という不等式が成り立つ。新たに端末が加わる時
に、この不等式が成立するならば、端末要求分配装置は
その端末の接続を許可する。しかし、成り立たない場合
は、その端末への配送を拒否する。この処理により、端
末要求に対して高レスポンスで配送できる範囲で、ディ
スクリードの能力の限界まで端末の数を増やすことがで
きる。

【００４０】

【発明の効果】本発明のファイルサーバによれば、格納
した映像データをより多くの端末へ早いレスポンスで送
ることが可能になり、その結果接続している端末の数が
多くなっても、端末で質の高い映像再生が可能になる。

【図面の簡単な説明】

【図１】本発明の実施例を表わすブロック図。

【図２】端末対応バッファ処理部のブロック図。

【図３】本発明のファイルサーバの説明図。

【図４】本発明が適用されるネットワーク環境の説明
図。

【図５】利用者端末からデータリード要求が来てから、
配送処理部が利用者端末にデータを配送するアルゴリズ
ムを表わすフローチャート。

【図６】図５におけるバッファの状態を表わす説明図。

【図７】図５におけるバッファの状態を表わす説明図。

【図８】図５におけるバッファの状態を表わす説明図。

【図９】二つのバッファ部から端末へデータを配送しな
がら、配送処理部がディスクリードによってバッファ部
を補充していく様子を示す説明図。

【図１０】図７で、端末がコピーなどを目的として高い
ビットレートで要求した時のバッファ部の補充を示す説
明図。

【図１１】ある周期Ｔの間に複数の配送処理部が一定時
間間隔で順番にディスクリードを行っている様子を示す
説明図。

【図１２】本発明のディスクスケジューラ部のブロック
図。

【図１３】本発明の要求待ち列挿入部のブロック図。

【図１４】要求待ち列挿入部が、新しいディスクリード
要求を待ち列に挿入するアルゴリズムを示すフローチャ
ート。

【符号の説明】

１０１…映像用ファイルサーバ、１１１…端末対応バッ
ファ処理部、１２１…ネットワークインタフェース、１
３１…端末コマンド分配部、１４１…ディスクスケジュ
ーラ部、１５１…磁気ディスク装置。

フロントページの続き (72)発明者 滝安 美弘 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所情報通信開発本部内

Claims (4)

【特許請求の範囲】
1. 【請求項１】デジタル映像データを蓄積する蓄積部を有
   し、利用者端末から送られる上記蓄積部内のデジタルデ
   ータのリード要求に応じて上記デジタルデータを端末に
   配送するファイルサーバにおいて、 データを一時的に格納するための読み出し速度が上記蓄
   積部より速いバッファ部と、利用者端末から送られてき
   た一回目のリード要求が映像データの要求であるかどう
   かを判断する要求判定部と、要求されたデータが上記映
   像データである場合は要求された量よりも多くデジタル
   データを第一の蓄積部から取り出し、上記バッファ部に
   格納するデータ読み出し部と、端末から要求された量だ
   け上記バッファ部から取り出して利用者端末へ送り出す
   手段を有することを特徴とするファイルサーバ。
2. 【請求項２】請求項１に記載のバッファ部内残データ量
   と伝送ビットレートから、バッファ部内データがアンダ
   フローする時刻（以下デッドライン時刻と称す）を定め
   る手段と、上記デッドライン時刻の到達前にあらかじめ
   決められた量を前記蓄積部から読み出すよう制御するデ
   ータ読み出し部を有するファイルサーバ。
3. 【請求項３】請求項１に記載のバッファ部内に端末が要
   求したデータが存在するか否かによって、上記データ読
   み出し部が次回行うバッファ部への補充が、上記バッフ
   ァ部内の現在配送を行っている部分のデータに連続する
   データの補充のための周期的リード要求であるか、端末
   が要求したデータがバッファ部内に存在しない場合のデ
   ータ補充のための非周期的リード要求であるかを判定す
   る手段を有し、端末に対応した複数の上記データ読み出
   し部から出される蓄積部へのリード要求と、そのデッド
   ライン時刻と、非周期的リードか周期的リードの区別を
   受け取り、蓄積部へのリード要求の待ち列を生成し、そ
   の待ち列で周期的リード要求に関してデッドラインが早
   い順になるようにソートし、待ち列内の全てのリード要
   求のリード予定終了時刻を計算し、その予定終了時刻が
   デッドライン時刻より遅くなるものが存在する場合は、
   待ち列でそれより前に登録されている非周期的リード要
   求を後ろへ繰り下げる処理を行う手段を有するファイル
   サーバ。
4. 【請求項４】請求項１に記載の蓄積部にデータを格納す
   る時に、そのデータが映像データであるか否かをデータ
   とともに登録しておき、データ読み出しの時にその登録
   内容を参照することによって、読み出すデータが映像デ
   ータかどうかを判定する要求判定部を備えたファイルサ
   ーバ。