JP3571902B2

JP3571902B2 - 配送システム、クライアント、方法および媒体

Info

Publication number: JP3571902B2
Application number: JP35730297A
Authority: JP
Inventors: 寿彦深澤; 憲司守田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1997-12-25
Filing date: 1997-12-25
Publication date: 2004-09-29
Anticipated expiration: 2017-12-25
Also published as: JPH11191883A; US6377989B1

Description

【０００１】
【発明の属する技術分野】
本発明は、例えばストリーム系データをネットワークに配送する配送システム、クライアントとその方法に関するものである。
【０００２】
【従来の技術】
近年、インターネットやイントラネットなどのコンピュータネットワーク環境の普及および高性能化に伴い映像や音声などのストリーム系のマルチメディアデータをコンピュータ・ネットワークを介して複数のクライアントに配送サービスする映像配送システムが開発され実用に供されるようになってきている。
【０００３】
従来、このような映像配送システムにおける映像データ配送方式として、図２に示す様な方式が提案されている。図２において、映像クライアント（２０１）は利用者が映像を視聴するために起動するプログラムである。映像クライアント（２０１）は利用者の要求に従って適当な映像サーバ（２０２）に接続する。
【０００４】
この方式では、まず映像クライアント（２０１）がリクエスト（映像取得要求、２０３）を映像サーバ（２０２）に送信する。映像サーバ（２０２）はリクエスト（２０３）に対するリプライとして１〜数フレーム分の映像データ（２０４）を返送する。映像クライアントは（２０１）は映像データ（２０４）をディスプレイ等に表示し、表示処理がおわると再びリクエスト（２０３）を映像サーバ（２０２）に送信する。このようにクライアントとサーバ間でリクエストとリプライを繰り返すことで映像配送を行う（以降、この方式のことを「リクエスト＆リプライ方式」と呼ぶことにする）。
【０００５】
リクエスト＆リプライ方式の特徴は映像データ量やフレームレートが映像クライアントの表示速度やネットワークの状況に応じて自動的に調節されるという点である。
【０００６】
映像クライアントのＣＰＵ負荷の増大やネットワークの状況が悪化するとリクエストの到達に時間がかかる。すると、リクエストが映像サーバに到達する間隔が長くなるので、時間あたりにネットワークに流れる映像データの量が減少することになる。その結果、ネットワークやクライアントの負荷が軽減される。逆に、クライアントやネットワークに余裕がある場合は、リクエストの間隔が短くなるのでより高フレームレートで映像データを送ることになる。
【０００７】
さらにリクエストがなければリプライも行われないので、映像クライアントやネットワーク側のトラブルで映像データを受信できない状況にもかかわらず、映像サーバが映像データを送ってしまう心配もない。リクエスト＆リプライ方式以外の方式では、映像サーバが一方的にクライアントに映像データを送り続ける方式（たれ流し方式）などが提案されている。しかし、リクエスト＆リプライ方式はたれ流し方式等の他の方式に比べ、フレームレートやデータ量の制御が簡単かつネットワークやクライアントに余り負担をかけずにすむので、ネットワーク状況の変動が大きくかつ複数のサービスが共存するインターネット環境での利用に適している。
【０００８】
【発明が解決しようとする課題】
しかしながらリクエスト＆リプライ方式ではクライアントが１つのリクエストを送信してからサーバからのリプライが届くまでの待ち時間（以降この時間を「ネットワーク遅延時間」と呼ぶ）が無駄になる。図３ａに示される様に、リクエスト２はリクエスト１のネットワーク遅延時間と表示時間が終了してから送信されるので、（ネットワーク遅延時間＋表示時間）＝Ｔ秒とするとフレームレートは１／Ｔｆｐｓになってしまう。
【０００９】
この無駄な時間の解消方法として、図３ｂに示す様にネットワーク遅延時間を見越して前もってリクエストを映像サーバに送っておくことで、見かけ上無駄時間を解消することが考えられる。（この方式を「ずらし送り方式」と呼ぶ。）図３ｂにおいてずらし送り方式では、リクエスト１の表示が終了した時にちょうどリクエスト２のリプライが到着する様にリクエストを送信しておく。このようにすることで、フレームレートを１／（表示時間）ｆｐｓに改善することが可能になる。
【００１０】
しかしながら、実際のネットワーク環境では、ネットワーク遅延時間は回線状況やデータ量などにより激しく変動する。場合によってはリプライがクライアントに届く順番が逆転する可能性もある。このような環境でずらし送り方式を実現するためには、前のリクエストの終了時間を予測して次のリクエストの送信のタイミングを決定しなければならない。しかし、不意のネットワーク遅延時間の変動を予測することは非常に困難である。
【００１１】
そこで本発明は配送効果を従来よりも向上させた配送システム、その方法および媒体を提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明は上記の課題を鑑みて提案されたものであり、その一形態は、クライアントにおいてサーバに対して映像データを取得するためのリクエストを発生する配送システムであって、ネットワークの遅延時間Ｎを予測する予測手段と、データ配送の最初において、前記サーバから映像データを取得するために、前記サーバの送信フレームレートＦ×前記予測手段によって予測された遅延時間Ｎで示される予測先送り数のリクエストを前記クライアント側において発生する第１のリクエスト手段と、前記第１のリクエスト手段によるリクエストが配送された後、前記サーバから映像データのリプライに応じて、前記サーバからの映像データを取得するためにリクエストを前記クライアント側において発生する第２のリクエスト手段と、前記第１，第２のリクエスト手段によって発生したリクエストのうち、映像データのリプライがない未処理リクエストの数を前記クライアント側において判別する判別手段と、前記判別手段によって判別された未処理リクエスト数が、第１の所定値（前記所定値は前記予測先送り数以上の整数値）より多い場合、前記クライアント側における前記第２のリクエスト手段によるリクエストの発生を行わないように制御し、前記判別手段によって判別された未処理リクエスト数が、第２の所定値（前記所定値は前記予測先送り数以下の整数値）より少ない場合、前記予測先送り数−未処理リクエスト数で求められるリクエスト数を前記第２のリクエスト手段によってリクエストを発生させ、前記判別手段によって判別された未処理リクエスト数が、前記第１の所定値より少なく、かつ前記第２の所定値より多い場合、１つのリクエストを前記第２のリクエスト手段によって発生させる制御手段と、
を有することを特徴とする配送システム。
【００１３】
【発明の実施の形態】
ここでは、第１の実施例として本発明の一実施例の映像配送システムについて説明する。この映像配送システムは、ビデオ映像を送信する映像サーバと、利用者が映像を鑑賞するための映像クライアントで構成されている。各映像サーバと映像クライアントは適当なコンピュータ上で動作するプログラムである。１つの映像サーバで複数の映像クライアントに映像データを送信することができる。この映像配送システムは、リクエスト＆リプライ方式を拡張することにより、映像データの制御をおこなっている。本実施例ではリクエストのことをＡｃｋｎｏｗｌｅｄｇｅメッセージと呼ぶ（以降、ＡｃｋないしＡｃｋメッセージと略す）。Ａｃｋメッセージの内容は映像クライアントと映像サーバ間のコネクションを識別するためのセッションＩＤのみである。セッションＩＤには０以上の整数として表現される。セッションＩＤは映像サーバと映像クライアント間のコネクションが形成された時にサーバによって割り当てられ、クライアントに通知される。また、本実施例でのリプライはＪＰＥＧ形式で圧縮された１フレーム分の映像データである。映像サーバがＡｃｋメッセージを受信するとＪＰＥＧ映像データを送り元の映像クライアントに送信される。もちろん、リプライの内容がＪＰＥＧ形式以外のＭＰＥＧ等の圧縮形式や、１フレームではなく複数フレーム分の映像データであっても本発明の適用に差し支えはない。また、映像データ以外の音声データや文字データを扱う場合にも適用可能である。
【００１４】
本映像配送システムにおける映像データの制御方式では、ずらし送り方式の様に１つずつリクエストをリプライに先行させて送るのではなく、最初に一定数のリクエストを映像サーバに送信してしまう。この方式を先送り方式と呼ぶ。
【００１５】
この方式は、サーバの送信フレームレートの最大値をＦｓフレーム／秒（ｆｐｓ）としたとき、リクエストを複数同時に送信しても１／Ｆｓ秒ごとに１つずつしか処理できないことを利用している。リクエストを同時に送信しても、１／Ｆｓ秒ずつずらし送りしたのと同じことになる。
【００１６】
本実施例では、最初に送信されるべきリクエストの数（リクエストの先送り数）を以下の様にして制御する。まず、ネットワーク遅延時間の平均値の予測を行う。この値をＮ秒とする。この場合には、１つのリクエストのネットワーク遅延時間Ｎの間に、最大フレームレートＦｓｆｐｓの映像サーバは、Ｎ×Ｆｓ個のリプライを映像クライアントに送信することができる。したがって、Ｎ×Ｆｓ個のリクエストを先送りしておけばよい。実際には、フレームレートＦｓも映像サーバの環境に依存するので予測値Ｆを決め、Ｎ×Ｆをリクエストの「予測先送り数」として使用する。
【００１７】
実際には、ネットワークの遅延時間が予想値Ｎからはずれていたりネットワークやクライアントの動作環境などの影響によりネットワーク遅延時間が変動することがある。本実施例では、ネットワークの遅延時間の変動に対処するために以下の制御を行う。まず、ある時点（たとえばリプライを一定個受け取ったとき）までに映像クライアントから送信されたリクエストの個数と、その時点で映像クライアントが受信したリプライの個数を調べ、（リクエスト数−リプライ数）の値を計算する。この値を「未処理リクエスト数」と呼ぶ。ネットワーク遅延時間が予測値Ｎと一致しているときは、リプライがくるごとにリクエストが１つ送信されるので「未処理リクエスト」は「予測先送り数」とほぼ等しくなる。
【００１８】
ネットワーク状況が悪化し伝送速度等の性能が低下すると、未処理リクエスト数が予測先送り数より多くなる。そこで、
未処理リクエスト数＞予測先送り数＊ａ
（ａは１以上の整数）
となったとき、過剰分のリクエスト（＝未処理リクエスト数 − 予測先送り数）が映像サーバによって消費されるまで、映像クライアントはリプライを受け取ってもリクエストの送信を行わない様にする。また、この時点でネットワーク遅延時間を以下の式で計算し、
計測ネットワーク遅延時間＝未処理リクエスト数／フレームレート
予想ネットワーク遅延時間と以下の関係が成り立つ時は、
計測ネットワーク遅延時間＞ａ＊予想ネットワーク遅延時間
フレームレートや予想遅延時間を修正する（本実施例ではａの値を２として制御する。）。
【００１９】
一方、ネットワークの状況が改善され性能が上昇した場合は未処理リクエスト数が予測先送り数より少なくなる。
【００２０】
未処理リクエスト数＜予測先送り数／ｂ
（ｂは１以上の整数）
となった場合は、不足分のリクエスト（＝予測先送り数 − 未処理リクエスト数）個をまとめて映像サーバに送信する。また、この時点で、
計測ネットワーク遅延時間＜予想ネットワーク遅延時間／ｂであれば
フレームレートや予想遅延時間を修正する（本実施例ではｂの値を２として制御する。）。
【００２１】
具体的にはフレームレートを上げる又は予熱遅延時間を短くする。では、次に図１を用いて本実施例の構成要素について説明する。図において（１０１）は映像クライアントである。映像クライアントは、実際にはＰＣ等のコンピュータの主メモリ上におかれＣＰＵによって実行されるプログラムである。映像クライアントはコンピュータネットワーク（１０２）を介して映像サーバ（１０３）と通信をおこなう。
【００２２】
映像クライアント（１０１）の内部モジュールはＡｃｋ処理モジュール群（１０４）とその他のモジュール群（１０５）に分類できる。Ａｃｋ処理モジュール群（１０４）は、映像サーバ（１０３）にＡｃｋメッセージを送って映像データを取得する機能を提供する。その他のモジュール群（１０５）には、ユーザインタフェースや動画表示などをおこなうソフトウェアモジュールが含まれており、表示する映像データを取得するためにＡｃｋ処理モジュール群（１０４）を利用する。
【００２３】
Ａｃｋ処理モジュール（１０４）には以下のソフトウェア・モジュールが属している。・Ａｃｋ処理制御部（１０６）
映像サーバ（１０３）へのＡｃｋメッセージ送信を制御するモジュールである。また、他のモジュール群（１０５）がＡｃｋ処理モジュール群（１０４）の機能を利用するためのインタフェースを提供する。他のモジュール群（１０５）が映像を取得するためには、このＡｃｋ処理制御部（１０６）に映像取得指示を発行すればよい。
（以下、モジュールやサブ・モジュール間のコミュニケーションは、”指示”をやり取りするものとして説明する。”指示”の具体的な実現形態としてはオブジェクト志向言語の”メッセージ”や通常のプログラム言語の手続き呼び出しなどが可能である。）
【００２４】
・Ａｃｋ処理関連パラメータ設定部（１０７）
Ａｃｋの送信制御に必要なフレームレートとネットワーク遅延時間の予測値を管理するモジュールである。図４に示す様なパネル（４０１）を表示する機能をもち、ユーザはこのパネルを利用してに適当なフレームレートとネットワーク遅延時間の予測値を設定するための入力フィールド（４０２、４０３）が提供される。また、その時点での推奨値（４０４、４０５）が表示される。（推奨値の計算方法については後述する。）
【００２５】
・Ａｃｋ処理状況監視部（１０８）
映像サーバに送信されたＡｃｋメッセージの個数と、映像サーバから得られた映像データの個数を監視するモジュールである。Ａｃｋメッセージの個数から映像データの個数を引けば、未処理のＡｃｋメッセージの個数が計算できる。また、受信した映像データの個数と経過時間から実測フレームレートを計算するためにも使用される。
【００２６】
・Ａｃｋ送信部（１０９）
Ａｃｋメッセージを映像サーバに送信するモジュールである。ｓｏｃｋｅｔ等のプロセス間通信の機構を用いて実現される。
【００２７】
・映像データ受信部（１１０）
映像サーバから送られてきた映像データを受信するモジュールである。Ａｃｋ送信部（１０９）と同じく、プロセス間通信の機構を用いて実現される。また、他のモジュール群（１０５）がＡｃｋ処理モジュール群（１０４）の機能を利用するためのインタフェースを提供する。映像データ受信部（１１０）を呼び出すことで最新の映像データを取得することができる。
【００２８】
では、図５とフローチャート図６を用いて本実施例の処理の流れを説明する。映像クライアント（５０１）が利用者によって起動され、映像サーバ（５０３）との通信が可能になると、Ａｃｋ処理制御モジュール（５０６）はＡｃｋ処理関連パラメータ設定部（５０８）を呼び出し、あらかじめ設定されているフレームレートとネットワーク遅延時間の予測値を取り出す（Ｓ６ａ０１）。かかる設定はデフォルトとして設定されているフレームレートネットワーク遅延時間であってもよいし、又映像サーバーの種類又は映像サーバに至る通信路の種類に従って決められた値であってもよい。次にＡｃｋ処理制御モジュール（５０６）は取り出したパラメータの値から予測先送り数＝予測フレームレート×予測ネットワーク遅延時間を計算する。Ａｃｋ処理制御モジュール（５０６）はＡｃｋ送信部（５０９）に予測先送り数を通知して予測先送り数のＡｃｋメッセージを映像サーバ（５０３）に送信させる（Ｓ６ａ０３）。
【００２９】
以上の様にしてＡｃｋの先送りが行われると、以降は以下の手順でＡｃｋ送信制御処理が行われる。まず、他のモジュール（５０５）から映像取得指示を受け取ると（Ｓ６ｂ０１）、Ａｃｋ処理制御部（５０６）はＡｃｋ処理状況監視部（５０８）から、映像サーバに送信されたＡｃｋメッセージの総数と映像サーバから得られた映像データの総数を取り出して未処理Ａｃｋメッセージ数を計算する（Ｓ６ｂ０２）。
【００３０】
ここで、Ａｃｋ送信部（５０９）がＡｃｋメッセージを送信すると、送信した個数をＡｃｋ送信通知（５１５）に付加してＡｃｋ処理状況監視部（５０８）に通知する。また、映像データ受信部（５１０）が映像データを受信したときは、映像受信通知（５１６）をＡｃｋ処理状況監視部（５０８）に通知する。Ａｃｋ処理状況監視部（５０８）は上記の通知（５１５、５１６）によって送信されたＡｃｋメッセージの総数と得られた映像データの総数を監視する。
【００３１】
未処理Ａｃｋメッセージ数が予測先送り数／２以下の場合は（Ｓ６ｂ０３）、Ａｃｋ処理制御部（５０６）はＡｃｋ送信部（５０９）を使用して（予測先送り数 − 未処理Ａｃｋメッセージ数）個分のＡｃｋメッセージを映像サーバ（５０３）に送信する（Ｓ６ｂ０４）。
【００３２】
さらに、
実測フレームレート＝受信映像データ総数／受信開始からの経過時間
計測ネットワーク遅延時間＝未処理Ａｃｋメッセージ数／実測フレームレート
も従って計測ネットワーク遅延時間を計算し、その値が予測ネットワーク遅延時間の半分以下ならば（Ｓ６ｂ０５）、Ａｃｋ処理状況監視部（５０８）に指示をおくって図４ｂの警告パネル（４０６）を表示させ、ユーザにフレームレートとネットワーク遅延時間の予測値の変更を示唆する（Ｓ６ｂ０６）。このとき、警告パネルには、上記の過程で計算した実測フレームレートと実測ネットワーク遅延時間を推奨値（４０７、４０８）として表示させる。また、未処理Ａｃｋメッセージ数が予測先送り数×２以上であった場合は（Ｓ６ｂ０７）、Ａｃｋメッセージの送信はおこなわない。かわりに、実測フレームレートと計測ネットワーク遅延時間を計算し、計測ネットワーク遅延時間が予測ネットワーク遅延時間の２倍以上ならば（Ｓ６ｂ０８）、Ａｃｋ処理状況監視部（５０８）に指示をおくって警告パネル（４０６）を表示させ、ユーザにフレームレートとネットワーク遅延時間の変更を示唆する（Ｓ６ｂ０９）。
【００３３】
未処理Ａｃｋメッセージ数が、予測先送り数／２より大きくかつ予測先送り数×２より小さい場合即ちネットワークの遅延が所定範囲内の場合は、単に１個のＡｃｋメッセージを送信させる（Ｓ６ｂ１０）。
【００３４】
以上説明した構成および処理により、ネットワーク状況の変動に適応可能かつネットワーク遅延時間を無駄にすることなく動画像を処理することが可能になる。また、本実施例ではパラメータの設定をユーザに行わせることによりより複雑な事態にも対応することが可能となっている。
【００５０】
以上述べた様に、本実施例では
・リクエストの送信手段と、
・ネットワーク遅延時間およびフレームレートの予測値の獲得手段と、
・サーバによって未だ処理されていない未処理リクエスト数の獲得手段
・上記ネットワーク遅延時間およびフレームレートの予測値と未処理リクエスト数に基づいてリクエストの送信を制御するリクエスト送信制御手段
を提供することにより、
不意のネットワーク遅延時間の変動に対応可能でかつ、ネットワーク遅延時間の無駄を解消することが可能な動画像配送システムを実現するものである。
【００５１】
なお、本発明は、複数の機器から構成されるシステムに適用しても、一つの機器からなる装置に適用してもよい。
【００５２】
特に本発明はクライアントのみに実施してもよい。例えばサーバー側の機能拡張が必要ない場合にはクライアント側の制御及びそのための方法を格納した媒体は本発明を実施したものに相当する。
【００５３】
また、本実施形態で説明したカメラサーバ装置及びクライアント装置は、多少のハードウェアの違いはあっても、パーソナルコンピュータやワークステーションで実現できる。従って、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００５４】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００５５】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【００５６】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００５７】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００５８】
本実施例においては動画像データを用いて説明したが本発明はオーディオデータ等のストリーム系のデータであれば同様に実施することができる。
【００５９】
【発明の効果】
以上の様に本発明によれば、従来の様な単に複数のリクエストをサーバに要求するデータ配送システムに比べて、ネットワークの状況や、クライアントのネットワーク環境に柔軟に適応したリクエストの先送りシステムを提供することが可能になる。
【図面の簡単な説明】
【図１】本発明の第１の実施例である映像配送システムの構成図、
【図２】映像配送システムにおけるリクエスト＆リプライ方式の概念図、
【図３】リクエスト＆リプライ方式の特性を表す図、
【図４】映像配送システムのパラメータ設定用ユーザインタフェースを示す図、
【図５】映像配送システムの動作の流れを説明するための図、
【図６】図５で示した処理のフローチャートである。

Claims

クライアントにおいてサーバに対して映像データを取得するためのリクエストを発生する配送システムであって、
ネットワークの遅延時間Ｎを予測する予測手段と、
データ配送の最初において、前記サーバから映像データを取得するために、前記サーバの送信フレームレートＦ×前記予測手段によって予測された遅延時間Ｎで示される予測先送り数のリクエストを前記クライアント側において発生する第１のリクエスト手段と、
前記第１のリクエスト手段によるリクエストが配送された後、前記サーバから映像データのリプライに応じて、前記サーバからの映像データを取得するためにリクエストを前記クライアント側において発生する第２のリクエスト手段と、
前記第１，第２のリクエスト手段によって発生したリクエストのうち、映像データのリプライがない未処理リクエストの数を前記クライアント側において判別する判別手段と、
前記判別手段によって判別された未処理リクエスト数が、第１の所定値（前記所定値は前記予測先送り数以上の整数値）より多い場合、前記クライアント側における前記第２のリクエスト手段によるリクエストの発生を行わないように制御し、
前記判別手段によって判別された未処理リクエスト数が、第２の所定値（前記所定値は前記予測先送り数以下の整数値）より少ない場合、前記予測先送り数−未処理リクエスト数で求められるリクエスト数を前記第２のリクエスト手段によってリクエストを発生させ、
前記判別手段によって判別された未処理リクエスト数が、前記第１の所定値より少なく、かつ前記第２の所定値より多い場合、１つのリクエストを前記第２のリクエスト手段によって発生させる制御手段と、
を有することを特徴とする配送システム。
クライアントにおいてサーバに対して映像データを取得するためのリクエストを発生する配送方法であって、
ネットワークの遅延時間Ｎを予測する予測ステップと、
データ配送の最初において、前記サーバから映像データを取得するために、前記サーバの送信フレームレートＦ×前記予測された遅延時間Ｎで示される予測先送り数のリクエストを前記クライアント側において発生する第１のリクエストステップと、
前記第１のリクエストステップにおいてリクエストが配送された後、前記サーバからの映像データのリプライに応じて、前記サーバからの映像データを取得するためにリクエストを前記クライアント側において発生する第２のリクエストステップと、
前記第１，第２のリクエストステップにおいて発生したリクエストのうち、映像データのリプライがない未処理リクエストの数を前記クライアント側において判別する判別ステップと、
前記判別ステップにおいて判別された未処理リクエスト数が、第１の所定値（前記所定値は前記予測先送り数以上の整数値）より多い場合、前記クライアント側における前記第２のリクエストステップにおけるリクエストの発生を行わないように制御し、
前記判別ステップにおいて判別された未処理リクエスト数が、第２の所定値（前記所定値は前記予測先送り数以下の整数値）より少ない場合、前記予測先送り数−未処理リクエスト数で求められるリクエスト数を前記第２のリクエストおいてリクエストを発生させ、
前記判別ステップ判別された未処理リクエスト数が、前記第１の所定値より少なく、かつ前記第２の所定値より多い場合、１つのリクエストを前記第２のリクエストステップにおいて発生させる制御手段と、
を有することを特徴とする配送方法。
請求項２に記載の配送方法を実現するプログラムをコンピュータにより実行可能に格納した記憶媒体。