JP2014057149A - 通信装置、中継装置および通信方法 - Google Patents

Abstract

【課題】高速かつ低消費電力かつ多大なリソースを必要とせずに効率的に通信を行う。
【解決手段】通信装置２は、他の通信装置との間で通信を行う通信部９と、他の通信装置３に対する情報の要求を発生する情報要求部５と、情報要求部５が発生した情報の要求にメタ情報を付加した情報取得要求を生成する情報取得要求生成部６と、他の通信装置３に対して情報取得要求を送信する際に用いるプロトコルよりも下位のプロトコルで規定される情報区切りを超えない範囲内で、情報取得要求を可能な限り多く連結したパイプラインリクエストを生成して通信部９に伝送する情報要求処理部７と、を備える。
【選択図】図１

Description

本発明の実施形態は、他の通信装置に対して情報を要求する通信装置、中継装置および通信方法に関する。

ＴＣＰでは、クライアント装置とサーバ装置間でデータの送受信を繰り返す中でＴＣＰウィンドウを広げていく「スロースタート」と呼ばれる輻輳回避アルゴリズムを用いる。そのため、ＴＣＰ/ＩＰを利用してファイル取得を開始する場合、必ずスロースタートによる影響を受ける。例えば、ネットワーク帯域が広く、高速に通信が可能なネットワークであっても、往復遅延時間が長い場合には、通信開始時のスループットが低くなることから、スループットが高くなるまでに時間を要する。インターネットでは、クライアント装置とサーバ装置が物理的に離れた場所に存在することが多いため、データのロード時間を縮小することは困難である。

データのロード時間の問題を軽減する別の手法として、ＨＴＴＰパイプライニングと呼ばれる手法がある。ＨＴＴＰ／１．１では、１回のＴＣＰ接続で複数のＨＴＴＰリクエスト／リプライを可能にする持続的コネクションがサポートされており、ＨＴＴＰパイプライニングにより、サーバ装置からのレスポンスを待たずに、連続してリクエストをサーバ装置に送ることができるようになった。これによってリクエストおよびレスポンスの往復回数を削減できた。

しかし、実際には、ＨＴＴＰリクエストを複数連続してサーバ装置に送信したとしても、ＴＣＰのスロースタートの影響を受けるため、往復遅延時間が長いと通信開始時のスループットが低くなることから、スループットが高くなるまでに時間を要するという問題自体は解決できない。

そこで、最近のブラウザは、多数のコネクション数を同時に確立することでデータの取得を高速化している。しかしながら、ＴＣＰコネクションを多数同時に確立する手法は、往復遅延時間の問題を軽減するが、その一方でサーバ装置とクライアント装置の双方のメモリやＣＰＵのリソースを余分に消費する。

クライアント装置がＨＴＴＰパイプライニングでリクエストを送信する際、連結後のデータ長が、ＨＴＴＰで正しく扱えるデータ長に収まっていても、ＩＰパケットのパケット長以上になってしまう場合には、ＨＴＴＰリクエストが複数のパケットにまたがる。リクエストの先頭のパケットを受け取ったサーバ装置は、新たなインスタンスを立ち上げて処理を開始するが、後続のパケットが到着するまでリソースを解放できない。このため、クライアント装置からのパイプラインリクエストが複数のパケットにまたがると、最後のリクエストが届くまで、サーバ装置はリソースを解放できず、多大なリソースを消費することになり、サーバ装置でレスポンスを生成するのにも時間を要してしまう。

クライアント装置が単一のパケットでリクエストする場合、サーバ装置でレスポンスデータを即時に用意できれば、TCP ACKをレスポンスデータに載せて送られる。一方、クライアント装置が複数のパケットにまたがってリクエストする場合、サーバ装置からのレスポンスデータとは別にTCP ACKを単体でクライアント装置に送信することになり、ＮＩＣの受信時間が増加し、消費電力が増加する。

したがって、クライアント装置がサーバ装置にリクエストを送信する際には、複数パケットにまたがらないように送信することが重要である。

また、サーバ装置からクライアント装置へ送信するデータに関しても、パイプラインを利用して、レスポンスの回数をできるだけ削減するのが望ましい。

特表2010-537337号公報

本発明は、高速かつ低消費電力かつ多大なリソースを必要とせずに効率的に通信を行うことが可能な通信装置、情報提供装置および情報処理方法を提供するものである。

本発明の一態様では、他の通信装置との間で通信を行う通信部と、前記他の通信装置に対する情報の要求を発生する情報要求部と、前記情報要求部が発生した情報の要求にメタ情報を付加した情報取得要求を生成する情報取得要求生成部と、前記他の通信装置に対して前記情報取得要求を送信する際に用いるプロトコルよりも下位のプロトコルで規定される情報区切りを超えない範囲内で、前記情報取得要求を可能な限り多く連結したパイプラインリクエストを生成して前記通信部を介して前記他の通信装置に伝送する情報要求処理部と、を備えることを特徴とする通信装置が提供される。

第１の実施形態による情報処理システム１の概略構成を示すブロック図。 第１の実施形態によるクライアント装置２の処理動作の一例を示すシーケンス図。 第１の実施形態による情報要求処理部７の処理手順の一例を示すフローチャート。 情報取得要求の詰め方の一例を示す図。 第２の実施形態に係る情報処理システム１の概略構成を示すブロック図。 第２の実施形態によるクライアント装置２の処理手順の一例を示すシーケンス図。 第１の実施形態による情報要求処理部７の処理手順を示すフローチャート。 第２の実施形態におけるパイプラインリクエストの生成手法の一例を模式的に示す図。 第３の実施形態による情報要求処理部７の処理手順を示すフローチャート。 第４の実施形態によるサーバ装置３を備えた情報処理システム１のブロック図。 図１０の情報応答処理部２５の処理手順の一例を示すフローチャート。 第５の実施形態による情報処理システム１のブロック図。

以下、図面を参照しながら、本発明の実施形態を説明する。

（第１の実施形態）
図１は第１の実施形態による情報処理システム１の概略構成を示すブロック図である。図１の情報処理システム１は、クライアント装置２とサーバ装置３を備えている。クライアント装置２とサーバ装置３は、ネットワーク４を介して通信を行う。ネットワーク４の具体的な形態は問わない。例えば、インターネット等の公衆通信回線でもよいし、専用通信回線でもよい。また、ネットワーク４は、イーサネット（登録商標）等の有線でもよいし、無線ＬＡＮ等の無線でもよい。クライアント装置２とサーバ装置３がネットワーク４を介して通信を行う際に用いるプロトコルの種類も問わない。

クライアント装置２は、情報要求部５と、情報取得要求生成部６と、情報要求処理部７と、通信パラメータ保持部８と、通信部９とを有する。

情報要求部５は、何らかの入力をトリガーとして、サーバ装置３に対して何らかの情報の要求を発生する。トリガーとなる入力は、例えば、ユーザからの入力や、タイマ計測による定期的な入力などである。

情報取得要求生成部６は、情報要求部５が発生した情報の要求にメタ情報を付加した情報取得要求を生成する。メタ情報とは、情報のファイル種別等を記述したヘッダ情報である。情報取得要求生成部６が生成した情報取得要求は、情報要求処理部７に送信される。

情報要求処理部７は、複数のコネクションを駆使して、情報取得要求生成部６が生成した情報取得要求を、通信部９を介してサーバ装置３に送信する制御を行う。より具体的には、情報要求処理部７は、情報取得要求生成部６が生成した情報取得要求を複数のコネクションに割り振って、各コネクションごとに可能な限り多くの情報取得要求を連結させたパイプラインリクエストを生成する。用いるプロトコルはデータの到達性を保証するプロトコルであれば具体的な形態は問わない。例えば、ＨＴＴＰや、ＨＴＴＰＳ、ＴＣＰ／ＩＰなどである。このとき、情報要求処理部７は、情報取得要求を送信するのに用いるプロトコルよりも下位のプロトコルで規定される情報区切りであるＰＤＵ（Protocol Data Unit）を超えない範囲内で、情報取得要求を可能な限り多く連結したパイプラインリクエストを生成して通信部９に伝送する。通信部９は、情報要求処理部７が生成したパイプラインリクエストをサーバ装置３に送信する。

通信パラメータ保持部８は、サーバ装置３に情報取得要求を送信する際に利用する通信プロトコルに関する種々の通信パラメータを保持する。代表的な通信パラメータとしては、スループット、遅延時間、これらの変動の大小、ＴＣＰコネクションごとのＴＣＰの輻輳ウィンドウ、ＭＳＳ( Maximum Segment Size )、ＴＣＰの最大パケットサイズ、ＩＰのＭＴＵ（Maximum Transmission Unit）、物理層のフレームの長さなどである。

このように、情報要求処理部７は、サーバ装置３との間の通信経路で情報のフラグメントが起きないように、情報取得要求を可能な限り多く連結したパイプラインリクエストを生成する。例えば、情報要求処理部７は、輻輳ウィンドウのサイズの範囲内で情報取得要求を可能な限り多く連結したパイプラインリクエストを生成する。

図２は第１の実施形態によるクライアント装置２の処理動作の一例を示すシーケンス図である。情報要求部５が発生した情報の要求は、情報要求処理部７を介して情報取得要求生成部６に伝送される（ステップＳ１）。

情報要求処理部７は、情報取得要求をサーバ装置３に送信する際に用いるプロトコルに関する通信パラメータを通信パラメータ保持部から取得する（ステップＳ２）。

情報取得要求生成部６は、情報要求部５が発生した情報の要求にメタ情報を付加した情報取得要求を生成する（ステップＳ３）。

情報要求処理部７は、情報取得要求生成部６が生成した情報取得要求を複数のコネクションに割り振って、各コネクションごとにパイプラインリクエストを生成し、通信部９に伝送する（ステップＳ４）。また、情報要求処理部７は、情報取得要求の伝送が完了したことを情報要求部５に通知する（ステップＳ５）。

図３は第１の実施形態による情報要求処理部７の処理手順の一例を示すフローチャートである。まず、ＨＴＴＰのＧＥＴリクエストを生成する（ステップＳ１１）。次に、このＧＥＴリクエストが、ＨＴＴＰの下位プロトコルであるＴＣＰのＭＳＳサイズを超えるか否かを判定する（ステップＳ１２）。超えていない場合は、次のＧＥＴリクエストを連結してパイプラインリクエストを生成し（ステップＳ１３）、ステップＳ１２に戻る。

ステップＳ１２で超えたと判定されると、生成したＧＥＴリクエストを、通信部９を介してサーバ装置３に送信する（ステップＳ１４）。

クライアント装置２とサーバ装置３との間に複数のコネクションがある場合、一つのサーバ装置３に対して使用してよいコネクションの数には上限がある。例えば、ＨＴＴＰ／１．０では４つのコネクション（セッション）まで、ＨＴＴＰ／１．１では２つのコネクション（セッション）までしか使わないことを推奨している。

各コネクションの最初のパケットにできるだけ多くのリクエストを含めることで、応答遅延を最小化できる。例えば、コネクションが４つある場合、分割されずに送信されるデータ長Ｌのパケットが４つあることになる。本実施形態では、これら４つのパケットに、できる多くの情報取得要求を詰めることを特徴とする。

情報取得要求の詰め方の一例は、図４に示すように、一つのパケットに、先頭の情報取得要求から順に詰めることである。図４の例では、先頭の情報取得要求から３つ分をコネクションＡ用のパケットに詰め込み、このパケットがＭＴＵサイズを超えると、次の２つ分の情報取得要求をコネクションＢ用のパケットに詰め込み、このパケットがＭＴＵサイズを超えると、次の３つ分の情報取得要求をコネクションＣ用のパケットに詰め込み、このパケットがＭＴＵサイズを超えると、最後の２つ分の情報取得要求をコネクションＤ用のパケットに詰め込んでいる。

なお、複数のコネクションに複数の情報取得要求を割り振る具体的な手順は、図３や図４に示したものに限定されず、他のアルゴリズム（例えば、線形計画法など）を採用してもよい。

このように、第１の実施形態では、複数の情報取得要求をできるだけ一つのパケットにまとめたパイプラインリクエストを生成してサーバ装置３に送信するようにし、まとめた情報取得要求が下位のプロトコルで規定される情報区切りを超えないようにしたため、サーバ装置３の待ち受け時間を短縮でき、サーバ装置３が迅速にレスポンスを返すことができるようになり、またレスポンスの回数も減らすことができる。これにより、クライアント装置２とサーバ装置３の双方とも、待ち受け時間が短くなり、消費電力を削減できる。

（第２の実施形態）
以下に説明する第２の実施形態は、サーバ装置３に対する情報取得要求に優先順位を付けるものである。

図５は第２の実施形態に係る情報処理システム１の概略構成を示すブロック図である。図５では、図１と共通する構成部分には同一符号を付しており、以下では相違点を中心に説明する。

図５のクライアント装置２は、図１の構成に加えて、優先順位決定部１１を有する。優先順位決定部１１は、情報要求部５が発生させた個々の情報取得要求の優先順位を決定する。優先順位は、要求した情報のファイル種別、要求した情報が表示画面内に表示されるか否か、要求した情報がファイルキャッシュに保持されているか否かなどで決定する。なお、優先順位を決定するための具体的な手法は、特に問わない。

図６は第２の実施形態によるクライアント装置２の処理手順の一例を示すシーケンス図である。図６のステップＳ２１は図２のステップＳ１と同様であり、ステップＳ２１で情報要求部５からの情報取得要求が情報要求処理部７に伝送されると、情報要求処理部７は、その情報取得要求の優先順位を優先順位決定部１１に問い合わせる（ステップＳ２２）。その後は、図２のステップＳ２〜Ｓ５と同様の処理が行われる（ステップＳ２３〜Ｓ２６）。

図７は第１の実施形態による情報要求処理部７の処理手順を示すフローチャートである。まず、情報要求部５が要求した情報の優先順位を優先順位決定部１１に問い合わせて、優先順位の順に情報取得要求を並び替える（ステップＳ３１）。

次に、通信状態がよいＴＣＰコネクションを選択する（ステップＳ３２）。コネクションの通信状態の判断に用いるパラメータは、スループット、遅延時間、エラー率、輻輳ウィンドウの大小や、これらのいずれか、もしくはこれらの組み合わせの変動の大小などである。次に、選択したＴＣＰコネクションに対して、優先順位の高い順に情報取得要求を連結してパイプラインリクエストを生成する（ステップＳ３３）。このとき、優先順位の高い情報取得要求をパイプラインリクエストの先頭側に配置するようにしてもよい。このようにすれば、優先順位の高い情報取得要求から先にサーバ装置３に届き、サーバ装置３からのレスポンスも先に得られる可能性が高いためである。また、輻輳ウィンドウが大きいコネクションは、高スループットが期待できるため、優先順位の高い情報取得要求に優先的に使用してもよい。

次に、パイプラインリクエストの情報長がＴＣＰの下位プロトコルであるＩＰのＭＴＵサイズを超えるか否かを判定する（ステップＳ３４）。超えていない場合はステップＳ３３の情報取得要求の連結処理を継続し、超えた場合は、連結し終わったパイプラインリクエストを、ステップＳ３２で選択したＴＣＰコネクションを用いて、通信部９を介してサーバ装置３に送信する（ステップＳ３５）。

次に、未送信の情報取得要求があるか否かを判定し、未送信の情報取得要求があれば、ステップＳ３２に戻り、未送信の情報取得要求がなければ、処理を終了する。

図８は第２の実施形態におけるパイプラインリクエストの生成手法の一例を模式的に示す図である。図８の例では、４つのコネクションＡ〜Ｄがあり、優先順位の高い順に情報取得要求に１〜１０の番号を付している。また、コネクションＡ〜Ｄは、輻輳ウィンドウが大きくなる順に並んでおり、コネクションＤの輻輳ウィンドウが最大である。

図８の例では、優先順位の高い情報取得要求を、各コネクションごとにパケットの先頭側に配置し、かつ優先順位の高い情報取得要求ほど、輻輳ウィンドウが大きいコネクションで送信するようにしている。

このように、第２の実施形態は、情報取得要求ごとに優先順位を付けて、優先順位の高い順に情報取得要求をパケットの先頭側に配置するため、優先順位の高い情報取得要求に対応するレスポンスが先に到着することが保障される。また、輻輳ウィンドウが広がっているコネクションを積極的に利用して優先順位の高い情報取得要求を送信することで、高いスループットを期待できる。特に、優先順位の高い情報取得要求に対するレスポンスを迅速に取得できるようになる。

（第３の実施形態）
以下に説明する第３の実施形態は、冗長なヘッダのメタ情報を削除、圧縮または置換するものである。第３の実施形態による情報処理システム１のブロック構成は、図１または図５に示したものと同様であるため、その説明を省略する。

本実施形態は、情報要求処理部７が生成するパイプラインリクエストのヘッダに含まれる、重複していて、かつ必須でない冗長なメタ情報を削除、圧縮または置換することを特徴とする。削除、圧縮または置換するメタ情報は、例えば、ＨＴＴＰパイプライニングを利用中に変化することがないブラウザのユーザエージェント情報や、対応している文字コード情報や圧縮方式など、同一パイプラインリクエストに含まれる、内容が同一で、重複しておりかつ必須でない冗長なメタ情報であれば、どれでもよい。

図９は第３の実施形態による情報要求処理部７の処理手順を示すフローチャートである。

まず、メタ情報の類似度の高い情報取得要求をグループ化する（ステップＳ４１）。次に、グループ化した情報取得要求の並び順を決定する（ステップＳ４２）。

次に、ステップＳ４２で決定した並び順に従って、メタ情報を含む個々の情報取得要求を順に連結させてパイプラインリクエストを生成する（ステップＳ４３）。

次に、このパイプラインリクエストに、メタ情報を含む新たな情報取得要求を連結したときに、下位のプロトコルで規定される情報区切り（例えば、ＴＣＰのウィンドウサイズや、ＩＰのＭＴＵサイズ、物理層のフレーム長など）を超えるか否かを判定する（ステップＳ４４）。まだ超えない場合は、生成したパイプラインリクエストに含まれる冗長なメタ情報を削除、圧縮または置換した上で、新たな情報取得要求と対応するメタ情報を連結して（ステップＳ４５）、ステップＳ４４に戻る。

ステップＳ４４で下位のプロトコルで規定される情報区切りを超えたと判定されると、生成したパイプラインリクエストを通信部９を介してサーバ装置３に送信する（ステップＳ４６）。

次に、まだ未送信の情報取得要求があるか否かを判定し（ステップＳ４７）、あればステップＳ４３に戻り、なければ処理を終了する。

このように、第３の実施形態では、複数の情報取得要求を順に連結したパイプラインリクエストに含まれるメタ情報のうち、冗長なメタ情報を削除、圧縮または置換するようにしたため、パイプラインリクエストのデータ長を削減でき、その分、より多くの情報取得要求を連結することができ、より高速な通信と消費電力の低減が図れる。

（第４の実施形態）
以下に説明する第４の実施形態は、第１〜第３の実施形態によるクライアント装置２からのパイプラインリクエストに対してレスポンスを返すサーバ装置３の構成および処理動作を説明するものである。

図１０は第４の実施形態によるサーバ装置３を備えた情報処理システム１のブロック図である。図１０に示すクライアント装置２は、第１〜第３の実施形態のいずれかのクライアント装置２である。

図１０のサーバ装置３は、レスポンス記憶部２１と、パイプライン解析部２２と、応答生成部２３と、通信パラメータ保持部２４と、情報応答処理部２５と、通信部２６とを有する。

パイプライン解析部２２は、クライアント装置２からのパイプラインリクエストを解析して、情報取得要求を抽出する。

通信パラメータ保持部２４は、クライアント装置２とサーバ装置３との間の通信で用いられる通信プロトコルの通信パラメータを保持する。この通信パラメータは、例えば、スループット、遅延、これらの変動の大小、ＴＣＰの輻輳ウィンドウ、最大セグメント長、最大パケット長、ＩＰのＭＴＵ、物理層のフレーム長などである。

応答生成部２３は、パイプラインリクエストに含まれる情報取得要求に応じたレスポンスを生成する。このレスポンスには、通信パラメータに基づくメタ情報が付加された状態で、レスポンス記憶部２１に保存される。

情報応答処理部２５は、通信部２６を介してクライアント装置２から送信されたパイプラインリクエストを受信して、パイプライン解析部２２に伝送するとともに、レスポンス記憶部２１に保存したレスポンスをパイプライン化したパイプラインレスポンスを生成して、通信部２６を介してクライアント装置２に伝送する。

図１１は図１０の情報応答処理部２５の処理手順の一例を示すフローチャートである。このフローチャートを開始するに当たって、情報応答処理部２５は、クライアント装置２が送信したパイプラインリクエストを通信部２６を介して受信して、パイプライン解析部２２に伝送する。パイプライン解析部２２は、パイプラインリクエストに含まれる個々の情報取得要求を抽出し、各情報取得要求に応じたレスポンスをレスポンス記憶部２１に保存する。

そして、情報応答処理部２５は、ＨＴＴＰのＧＥＴレスポンスを生成する（ステップＳ５１）。次に、レスポンスあるいはパイプラインレスポンスが下位のプロトコルで規定される情報区切りを超えるか否かを判定する（ステップＳ５２）。ここでは、例えば、ＩＰのＭＴＵサイズを超えるか否かを判定し、超えない場合に、次のレスポンスを連結して（ステップＳ５３）、ステップＳ５２に戻る。

ステップＳ５２で超えると判定された場合は、レスポンスを通信部２６を介してクライアント装置２に伝送する（ステップＳ５４）。

このように、第４の実施形態では、クライアント装置２からのパイプラインリクエストを受信したサーバ装置３は、パイプラインリクエストに含まれる各情報取得要求に応じたレスポンスを連結したパイプラインレスポンスが下位のプロトコルで規定される情報区切りを超えるか否かを判定し、超えない範囲で連結したパイプラインレスポンスを通信部２６を介してクライアント装置２に返すため、レスポンスの回数を最小限に留めることができ、クライアント装置２へのレスポンスを迅速に行うことができ、消費電力も削減できる。

（第５の実施形態）
以下に説明する第５の実施形態は、クライアント装置２とサーバ装置３との間の通信を中継するプロキシ装置（中継装置）を、クライアント装置２とサーバ装置３の間に設けるものである。

図１２は第５の実施形態による情報処理システム１のブロック図である。図１２の情報処理システム１は、ネットワーク４に接続されたプロキシ装置３０を備えている。

例えば、プロキシ装置３０は、クライアント装置２が送信したパイプラインリクエストやリクエストを受信して、受信したパイプラインリクエストやリクエストを再構成するなどして生成した新たなパイプラインリクエストやリクエストをサーバ装置３に送信する。

また、プロキシ装置３０は、サーバ装置３が送信したパイプラインレスポンスやレスポンスを受信して、受信したパイプラインレスポンスやレスポンスを再構成するなどして生成した新たなパイプラインレスポンスやレスポンスをクライアント装置２に送信する。

図１２のプロキシ装置３０は、パイプラインリクエスト記憶部３１と、情報記憶部３２と、第１通信パラメータ保持部３３と、第２通信パラメータ保持部３４と、要求処理部３５と、第１通信部３６と、第２通信部３７とを有する。

リクエスト記憶部３１は、クライアント装置２から届いたリクエストやパイプラインリクエストを一時的に保存する。情報記憶部３２は、サーバ装置３から受信したレスポンスまたはパイプラインレスポンスを一時的に保存する。

第１通信パラメータ保持部３３は、クライアント装置２との間で通信を行う際に用いる通信プロトコルに関する通信パラメータを保持する。第２通信パラメータ保持部３４は、サーバ装置３との間で通信を行う際に用いる通信プロトコルに関する通信プロトコルを保持する。

第１および第２通信パラメータ保持部３３，３４が保持する通信パラメータは、第１〜第４の実施形態で説明した通信パラメータと同様に、スループット、遅延、エラー率、これらの変動の大小、ＴＣＰの輻輳ウィンドウ、最大セグメント長、最大パケット長、ＩＰのＭＴＵ、物理層のフレーム長などである。

要求処理部３５は、クライアント装置２から送信されたパイプラインリクエストを再構成して、新たなパイプラインリクエストやパイプライン化されていないリクエストを生成する。なお、クライアント装置２から送信されたパイプラインリクエストをそのままサーバ装置３に送信してもよい。

また、要求処理部３５は、サーバ装置３から送信されたパイプラインレスポンスを再構成して、新たなパイプラインレスポンスやレスポンスを生成したり、サーバ装置３から送信されたパイプラインレスポンスをそのままサーバ装置３に送信する。

第１通信部３６は、ネットワーク４を介してクライアント装置２と通信を行う。第２通信部３７は、ネットワーク４を介してサーバ装置３と通信を行う。

図１２のクライアント装置２、もしくはサーバ装置３のいずれか一つ以上は、第１〜第３の実施形態のいずれかで説明したクライアント装置２もしくは、第４の実施形態で説明したサーバ装置３である。

クライアント装置２からプロキシ装置３０にパイプラインリクエストを送信する場合の処理手順として、以下の３通りが考えられる。

１．クライアント装置２は、プロキシ装置３０に対し、パイプラインリクエストを送信する。プロキシ装置３０は第１通信部３６を使い、パイプラインリクエストを受信する。プロキシ装置３０はそのパイプラインリクエストをパイプライン化されていないリクエストに変換し、第２通信部３７から多数のコネクションを使ってサーバ装置３に送信する。

２．クライアント装置２は、プロキシ装置３０に対し、パイプライン化されていないリクエストを送信する。プロキシ装置３０は第１通信部３６を使い、パイプライン化されていないリクエストを受信する。プロキシ装置３０はリクエストをパイプライン化し、第２通信部３７を使ってパイプラインリクエストをサーバ装置３に送信する。

３．クライアント装置２は、プロキシ装置３０に対し、パイプラインリクエストを送信する。プロキシ装置３０は第１通信部３６を使い、パイプラインリクエストを受信する。プロキシ装置３０は第２通信部３７を使ってパイプラインリクエストをサーバ装置３に送信する。

また、サーバ装置３からプロキシ装置３０にパイプラインレスポンスを送信する場合の処理手順として、以下の３通りが考えられる。

４．サーバ装置３は、パイプラインレスポンスをプロキシ装置３０へ送信する。プロキシ装置３０は、第２通信部３７を使いパイプラインレスポンスを受信する。プロキシ装置３０はパイプラインレスポンスを解析し、第１通信部３６を使い、パイプライン化されていないレスポンスをクライアント装置２に送信する。

５．サーバ装置３は、パイプライン化されていないレスポンスをプロキシ装置３０へ送信する。プロキシ装置３０は、第２通信部３７を使いパイプライン化されていないレスポンスを受信する。プロキシ装置３０はリクエスト記憶部３１にあるクライアント装置２からのリクエストの順序のパイプラインレスポンスを生成し、第１通信部３６を使いパイプラインレスポンスをクライアント装置２に送信する。

６．サーバ装置３は、パイプラインレスポンスをプロキシ装置３０へ送信する。プロキシ装置３０は、第２通信部３７を使いパイプラインレスポンスを受信する。プロキシ装置３０は第１通信部３６を使い、クライアント装置２にパイプラインレスポンスを送信する。

パイプラインリクエストが第２の実施形態で説明したように、情報取得要求の優先順位に基づいて生成されている場合は、以下の手順で、情報取得要求がサーバ装置３に送信される。

まず、プロキシ装置３０内の要求処理部３５は、クライアント装置２から受信したパイプラインリクエストを一定期間、パイプラインリクエスト記憶部３１に保存する。そして、要求処理部３５は、パイプラインリクエスト記憶部３１に保存されたパイプラインリクエストに含まれる複数の情報取得要求の中で、優先順位の高い情報取得要求から順に選択して、優先順位の高い情報取得要求を先頭側に配置したパイプラインリクエストを生成する。優先順位は、第２の実施形態と同様に、ファイル種別等で判断する。

次に、要求処理部３５は、生成したパイプラインリクエストをサーバ装置３に送信する。

要求処理部３５は、パイプラインリクエストに応じて、サーバから順次送信されたレスポンスを情報記憶部３２に保存するとともに、パイプラインリクエスト記憶部３１に保存していた元の情報取得要求と対応づけて、送信順序を間違わないように、可能な限り複数のレスポンスを連結したパイプラインレスポンスを生成して、クライアント装置２に送信する。

このように、第５の実施形態では、クライアント装置２から送信されたパイプラインリクエストをサーバ装置３の代わりにプロキシ装置３０で受信して、必要に応じてパイプラインリクエストを再構成してサーバ装置３に送信する。あるいは、サーバ装置３から送信されたパイプラインレスポンスをクライアント装置２の代わりにプロキシ装置３０で受信して、必要に応じてパイプラインレスポンスを再構成してクライアント装置２に送信する。いずれの場合であっても、クライアント装置２またはサーバ装置３は、リクエストまたはレスポンスの送信回数を減らすことができ、低消費電力化を図ることができる。

上述した実施形態で説明したクライアント装置２、サーバ装置３およびプロキシ装置３０の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、クライアント装置２、サーバ装置３およびプロキシ装置３０の少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。

また、クライアント装置２、サーバ装置３およびプロキシ装置３０の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。

本発明の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到しうる種々の変形も含むものであり、本発明の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

１ 情報処理システム、２ クライアント装置、３ サーバ装置、４ ネットワーク、５ 情報要求部、６ 情報取得要求生成部、７ 情報要求処理部、８ 通信パラメータ保持部、９ 通信部、１１ 優先順位決定部、２１ レスポンス記憶部、２２ パイプライン解析部、２３ 応答生成部、２４ 通信パラメータ保持部、２５ 情報応答処理部、２６ 通信部、３１ パイプラインリクエスト記憶部、３２ 情報記憶部、３３ 第１通信パラメータ保持部、３４ 第２通信パラメータ保持部、３５ 要求処理部、３６ 第１通信部、３７ 第２通信部

Claims (14)

1. 他の通信装置との間で通信を行う通信部と、
   前記他の通信装置に対する情報の要求を発生する情報要求部と、
   前記情報要求部が発生した情報の要求にメタ情報を付加した情報取得要求を生成する情報取得要求生成部と、
   前記他の通信装置に対して前記情報取得要求を送信する際に用いるプロトコルよりも下位のプロトコルで規定される情報区切りを超えない範囲内で、前記情報取得要求を可能な限り多く連結したパイプラインリクエストを生成して前記通信部を介して前記他の通信装置に伝送する情報要求処理部と、を備えることを特徴とする通信装置。
2. 前記情報要求処理部は、前記他の通信装置との間の通信経路で情報のフラグメントが起きないように、前記情報取得要求を可能な限り多く連結した前記パイプラインリクエストを生成することを特徴とする請求項１に記載の通信装置。
3. 前記情報要求処理部は、前記下位のプロトコルで規定される一度に送信できる最大のデータ長の範囲内で、前記情報取得要求を可能な限り多く連結した前記パイプラインリクエストを生成することを特徴とする請求項１に記載の通信装置。
4. 前記情報要求処理部は、前記パイプラインリクエストに含まれる冗長な前記メタ情報を削除、圧縮または置換することを特徴とする請求項１乃至３のいずれかに記載の通信装置。
5. 前記情報要求部が発生した情報の要求のそれぞれについての優先順位を決定する優先順位決定部を備え、
   前記情報要求処理部は、前記優先順位決定部が決定した優先順位が高い順に前記情報取得要求を並べた前記パイプラインリクエストを生成することを特徴とする請求項１乃至４のいずれかに記載の通信装置。
6. 前記情報要求処理部は、優先順位が高い前記情報取得要求を前記パイプラインリクエストの先頭側に配置することを特徴とする請求項５に記載の通信装置。
7. 前記情報要求処理部は、優先順位が高い前記情報取得要求を含む前記パイプラインリクエストを、輻輳ウィンドウが広いコネクションで送信することを特徴とする請求項５または６に記載の通信装置。
8. 前記優先順位決定部は、前記他の通信装置に要求する情報のファイル種別と、該情報が表示画面内に表示されるか否かと、該情報の表示位置と表示中の情報からの画面上の距離と、該情報をファイルキャッシュとして所持しているか否かと、該情報が画面レイアウトを決定する情報であるか否かと、の少なくとも一つに基づいて優先順位を決定することを特徴とする請求項５乃至７のいずれかに記載の通信装置。
9. 他の通信装置との間で通信を行う通信部と、
   前記他の通信装置から送信され複数の情報取得要求が連結されたパイプラインリクエストに含まれる前記複数の情報取得要求を解析するパイプライン解析部と、
   前記パイプラインリクエストに含まれる前記情報取得要求に応じたレスポンスを生成する応答生成部と、
   前記情報取得要求に応じたレスポンスを返すのに用いるプロトコルよりも下位のプロトコルで規定される情報区切りを超えない範囲内で、可能な限り多くの前記レスポンスを連結したパイプラインレスポンスを生成して前記通信部を介して前記他の通信装置に伝送する情報応答処理部と、を特徴とする通信装置。
10. 請求項１乃至９のいずれかに記載の通信装置と、前記他の通信装置との間の通信を中継する中継装置であって、
    前記通信装置との間に設定され、前記通信装置から送信されたリクエストまたは前記パイプラインリクエストを受信するための第１通信部と、
    前記他の通信装置との間に設定され、前記通信装置から送信されたリクエストまたは前記パイプラインリクエストを再構成した新たなリクエストまたはパイプラインリクエストを前記他の通信装置に送信するための第２通信部と、を備えることを特徴とする中継装置。
11. 必要最小限のコネクションを使って前記通信装置から前記パイプラインリクエストを前記第１通信部で受信し、前記パイプラインリクエストを複数のリクエストに変換し、多数のコネクションを使ってリクエストを前記第２通信部で送信することを特徴とする請求項１０に記載の中継装置。
12. 複数のコネクションを使って前記通信装置から複数のリクエストを前記第１通信部で受信し、複数のリクエストからパイプラインリクエストを生成し、必要最小限のコネクションを使ってパイプラインリクエストを前記第２通信部で前記他の通信装置に送信することを特徴とする請求項１０に記載の中継装置。
13. 通信装置から他の通信装置に対する情報の要求を発生するステップと、
    前記発生した情報の要求にメタ情報を付加した情報取得要求を生成するステップと、
    前記他の通信装置に対して前記情報取得要求を送信する際に用いるプロトコルよりも下位のプロトコルで規定される情報区切りを超えない範囲内で、前記情報取得要求を可能な限り多く連結したパイプラインリクエストを生成して前記通信部を介して前記他の通信装置に伝送するステップと、を備えることを特徴とする通信方法。
14. 前記通信装置から送信され複数の情報取得要求が連結されたパイプラインリクエストに含まれる前記複数の情報取得要求を解析するステップと、
    前記パイプラインリクエストに含まれる前記情報取得要求に応じたレスポンスを生成するステップと、
    前記情報取得要求に応じたレスポンスを返すのに用いるプロトコルよりも下位のプロトコルで規定される情報区切りを超えない範囲内で、可能な限り多くの前記レスポンスを連結したパイプラインレスポンスを生成して前記通信部を介して前記通信装置に伝送するステップと、を特徴とする請求項１３に記載の通信方法。

Images