JP2015125657A - 情報処理装置、その制御方法およびコンピュータプログラム - Google Patents

Abstract

【課題】複数の通信コネクションを利用し、コンテンツ取得用の通信コネクションを維持することによりサーバ装置とのデータ通信の高速化を実現する情報処理装置を提供すること。【解決手段】情報処理装置１０３は、サーバ装置１０１との第１の通信コネクションを確立して、コンテンツを動的に生成するサーバ装置１０１から該コンテンツが生成されたか否かを示す情報を取得し、サーバ装置１０２との第２の通信コネクションを確立して、生成されたコンテンツを取得する。情報処理装置１０３は、コンテンツの取得が完了するまで第２の通信コネクションを維持する。【選択図】 図４

Description

本発明は、動的に生成されるコンテンツの取得を高速化する技術に関する。

ユーザからのコンテンツ取得要求に応じて動的にコンテンツを生成するＷｅｂサービスが提案されている。例えば、電子メールを利用した印刷サービス、クラウドシステムを利用したデータフォーマット変換サービス等が挙げられる。Ｗｅｂサービスはインターネットを利用して提供されるため、既存の仕組みに比べると、通信品質が一定ではない。そのため、通信中に通信が切断されてしまう場合もある。このような場合に備え、途中で通信が切断された場合でも効率的に処理を再開する方法が提案されている（特許文献１）。

特開２０１３−４９２０４号公報

しかし、動的にコンテンツを生成するＷｅｂサービスの場合、クライアントコンピュータがコンテンツを取得するためにサーバコンピュータとの通信を確立した時点で、コンテンツが用意されていない場合がある。

コンテンツが用意されていないにも関わらず取得を試みた場合、サーバコンピュータから通信を切断される可能性がある。特にＷｅｂサーバがクライアントコンピュータに対してエラーを返信する場合、一般的に接続はＷｅｂサーバ側から切断される。この場合、クライアントコンピュータはＷｅｂサーバに対して再接続が必要となるが、ＴＣＰにおいては、再接続すると輻輳回避アルゴリズムの影響で通信速度が低下する。特にモバイル通信や大陸間通信などの長距離環境では、その影響が顕著に発生する。

本発明は、複数の通信コネクションを利用し、コンテンツ取得用の通信コネクションを維持することによりサーバ装置とのデータ通信の高速化を実現する情報処理装置を提供することを目的とする。

本発明の一実施形態の情報処理装置は、サーバ装置との第１の通信コネクションを確立して、コンテンツを動的に生成する前記サーバ装置から前記コンテンツが生成されたか否かを示す情報を取得する第１の通信手段と、前記サーバ装置との第２の通信コネクションを確立して、生成された前記コンテンツを取得する第２の通信手段とを備える。前記第２の通信手段は、前記コンテンツの取得が完了するまで前記第２の通信コネクションを維持する。

本発明の情報処理装置によれば、複数の通信コネクションを利用し、コンテンツ取得用の通信コネクションを維持することによりＷｅｂサーバとのデータ通信の高速化を実現することが可能となる。

本発明の一実施形態のネットワーク構成例を示す図である。 本発明のサーバまたは情報処理装置のハードウェア構成例を示す図である。 本発明のサーバまたは情報処理装置のソフトウェア構成例を示す図である。 データ取得処理部によるダウンロード処理のフローチャートである。 データ取得処理部によるファイル取得処理のフローチャートである。 本発明の効果を示す、時間に対する輻輳ウィンドウサイズのグラフである。 実施例２における情報処理装置のソフトウェア構成例を示す図である。 マルチＴＣＰコネクションによるデータ取得処理のフローチャートである。 ダウンロード負担量算出処理のフローチャートである。

まず、本明細書で用いる用語について定義する。ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）とは、ファイルの送受信などの信頼性を要求する通信に一般的に利用されるプロトコルである。ＴＣＰの詳細はｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７９３を参照されたい。

ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）とは、ＷｅｂクライアントとＷｅｂサーバの間で各種コンテンツの送受信に用いられるプロトコルである。ＨＴＴＰの詳細はｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ２６１６を参照されたい。Ｗｅｂサービスでは、このＨＴＴＰを使用して通信を行う。

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

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

受信ウィンドウサイズとは、ＴＣＰプロトコルにおける、受信用のバッファ領域のサイズである。

送信ウィンドウサイズとは、ＴＣＰプロトコルにおける、送信用のバッファ領域のサイズである。

ＴＣＰは、残り受信ウィンドウサイズを送信側に通知することにより、バッファ溢れを防ぐことが出来る。また、ＴＣＰは送信ウィンドウサイズを徐々に大きくすることにより、通信速度の向上を試みる。一方で、送信ウィンドウサイズを単に大きくすると、通信路の輻輳に繋がるため、これらウィンドウサイズの制御を行う輻輳回避アルゴリズムが必要である。広く知られている輻輳回避アルゴリズムには、Ｔａｈｏｅ、Ｒｅｎｏ等がある。

本明細書において、セッションとは１本以上のＴＣＰコネクションを束ねたものを意味する。前記セッションは、ファイルを分割して送受信する際に使われる複数のＴＣＰコネクションを束ねたものである。

（実施例１）
図１は、本発明の一実施形態のシステム構成例を示す。図１に示すシステムは、クライアントコンピュータ１０３、画像処理装置１０４、サーバコンピュータ１０１から構成される。また、クライアントコンピュータ１０３と画像処理装置１０４は、無線ルータ１０２とインターネット１００を介してサーバコンピュータ１０１と接続可能である。インターネット１００は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１００は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網である。図１では、サーバコンピュータ１０１は、１台のサーバコンピュータ１０１として示されているが複数台のサーバコンピュータ群で構成されていても構わない。また、仮想ＰＣとして構成されていても構わない。

無線ルータ１０２は、インターネット１００と接続されている。無線ルータ１０２は、クライアントコンピュータ１０３と無線通信が可能であり、画像処理装置１０４とも有線、または無線で通信可能である。また、クライアントコンピュータ１０３と画像処理装置１０４は、無線ルータ１０２を経由して互いに通信可能である。

図２は、図１に示す情報処理装置として機能するクライアントコンピュータ１０３またはサーバ装置として機能するサーバコンピュータ１０１のハードウェア構成例を説明するブロック図である。なお、特に断らない限り、本発明の機能が実行されるのであれば、単体の機器であっても、複数の機器から成るシステムであっても、本発明を適用できることは言うまでもない。また、特に断らない限り、本発明の機能が実行されるのであれば、ＬＡＮ、ＷＡＮ、ＷＷＡＮ、インターネット等のネットワークを介して接続が為され処理が行われるシステムであっても本発明を適用できることは言うまでもない。なお、ＬＡ、ＷＡＮ、ＷＷＡＮはそれぞれ、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ、Ｗｉｒｅｌｅｓｓ Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋの略称である。

クライアントコンピュータ１０３またはサーバコンピュータ１０１のコンピュータ２００は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、外部記憶装置２０５、ネットワークＩ／Ｆ制御部２０６を備える。各処理部は、システムバス２０４を介して相互にデータを送受信する。ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。また、ＣＰＵ２０１は、ＲＯＭ２０２のプログラム用ＲＯＭまたは外部記憶装置２０５に記憶された文書処理プログラム等に基づいて、図形、イメージ、文字、表（表計算等を含む）等、様々な処理を実行する。コンピュータ２００の構成は上述の処理部に限定されず、他の入出力装置を備えていても良い。また、クライアントコンピュータ１０３またはサーバコンピュータ１０１は、無線通信によって接続が確立されていても良い。なお、ＣＰＵ、ＲＯＭ、ＲＡＭはそれぞれ、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略称である。

本発明を実現するためのプログラムは、ＲＯＭ２０２、ＲＡＭ２０３または外部記憶装置２０５に格納されており、ＣＰＵ２０１が実行することにより各処理が実現される。また、このＲＯＭ２０２のプログラム用ＲＯＭまたは外部記憶装置２０５は、ＣＰＵ２０１の制御プログラムであるオペレーションシステム等を記憶する。また、ＲＯＭ２０２のデータ用ＲＯＭまたは外部記憶装置２０５は、本発明を実現するためのプログラムを含む各種データを記憶する。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能し、ネットワークＩ／Ｆ制御部２０６は、ＬＡＮ２０７とのデータの送受信を制御する。

図３は、コンピュータ２００のソフトウェア構成例を示す。図３に示すコンピュータは、上位レイヤアプリケーション３０１乃至ネットワークＩ／Ｆ３０８を備える。ＴＣＰレイヤまでの管理機構はＲＦＣ７９３によって定義される伝送制御プロトコルを満たし、利用可能なＡＰＩが提供されていればどのような実施方法でも構わない。すなわち、ＴＣＰ管理処理部３０６および下位レイヤ管理処理部３０７が適切なＡＰＩを提供していれば、その実装は問わない。このＴＣＰ管理処理部３０６および下位レイヤ管理処理部３０７は、多くの場合、オペレーティングシステムが提供することが一般的であるが、本発明が必要とする管理機構が直接実装していても構わない。その実施方法は一般的に広く知られているため、詳細に記述しない。

ダウンロード管理処理部３０３は、複数のＴＣＰコネクションを用いた受信処理を管理し、上位レイヤアプリケーション３０１へのインタフェースを提供する。また下位レイヤに対してデータの送受信も管理する。ダウンロード管理処理部３０３は全ての処理を行わず、データ取得処理部３０４にＴＣＰコネクションの処理を委譲する。

本実施例では、このダウンロード管理処理部３０３およびデータ取得処理部３０４を１つのソフトウェアライブラリの形で記述する。しかし、オペレーティングシステムそのものに本機能を実施したり、外部ネットワークとのインタフェースであるネットワークＩ／Ｆ３０８のハードウェアに実装しても構わない。すなわち、同等の機能及びインタフェースが上位レイヤアプリケーション３０１に提供できれば、実施箇所は問わない。

データ取得処理部３０４は、ＴＣＰコネクションを管理する。具体的には、ＴＣＰコネクションの接続、データの送受信等を管理し、その結果を上位レイヤアプリケーション３０１に通知する。また、データ取得処理部３０４は、サーバコンピュータ１０１から受信したデータを転送データ記憶部３０２に記憶させる。

ここで、クライアントコンピュータ１０３をモバイル端末とし、モバイル端末から画像処理装置１０４へ印刷をする際、サーバコンピュータ１０１がモバイル端末から受け取った画像を画像処理装置が理解できる画像へと変換するサービスを考える。このモバイル端末が、本発明を実現する情報処理装置として機能する。なお、本実施例では、使用する通信プロトコルとしてＨＴＴＰを用いる。もちろん、他のプロトコルや独自のものを用いても良い。

本発明の特徴を示すため、クライアントコンピュータ１０３の実施について詳細に説明する。なお、サーバコンピュータ１０１は一般的なＨＴＴＰサーバの機能を満たし、ＨＴＴＰ１．１におけるＫｅｅｐ−Ａｌｉｖｅ機能および、ＧＥＴコマンドとＨＥＡＤコマンドが使用可能とする。

次に、本発明を用いたデータの送受信について説明する。図４は、通信開始時の処理のフローを示す。まず、ダウンロード管理処理部３０３は、上位レイヤアプリケーション３０１から通信開始の要求を受け取る。次に、ダウンロード管理処理部３０３は、データ取得処理部３０４に上位レイヤアプリケーション３０１から得た情報を渡し、コンテンツのダウンロードを依頼する。データ取得処理部３０４は、ダウンロードしたいＵＲＩを元にＴＣＰマルチコネクション処理（４００）を行う。

Ｓ４０１にて、データ取得処理部３０４は、サーバコンピュータ１０１に対してファイルサイズ取得用のＴＣＰコネクションの接続を確立する。ここでサイズとは、ＨＴＴＰにおける、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダを指す。すなわち、ダウンロードしたいファイルのサイズを取得するためだけの専用のＴＣＰコネクションの接続を行う。このサイズ取得コネクションは、ダウンロードしたいファイルのサイズを取得する以外に、サーバコンピュータ１０１が該当ファイルの生成が完了したかどうかの確認をするために使用される。

Ｓ４０２では、データ取得処理部３０４は、ＵＲＬリストをサーバコンピュータ１０１から取得する。ここでＵＲＬリストとは、サーバコンピュータ１０１が生成する予定のファイルのＵＲＬのリストを指す。ＵＲＬリストには、クライアントコンピュータ１０３が取得すべきファイルのＵＲＬが記述されているが、この時点でファイルが完成している保証は無い。もし完成していないファイルを取得しようとした場合、サーバコンピュータ１０１からエラーのＨＴＴＰレスポンスが返される。

Ｓ４０３にて、データ取得処理部３０４は、ファイル取得スレッドの初期化、およびスレッドの開始を行う。ファイル取得スレッドは、ＨＴＴＰレスポンスにおけるヘッダ以外の部分、すなわちボディ部を指し、画像処理装置が印刷できるデータの一部分を含む。また、この時点で、ＨＴＴＰのボディ部取得のための専用スレッドが開始される。なお、ファイル取得スレッドの開始（Ｓ４０３）で使用するスレッドはＯＳのネイティブスレッドで無くとも良いし、複数のＴＣＰコネクションを扱えれば、ひとつのスレッドで実施してもよい。

Ｓ４０４において、ダウンロードが未完了のファイルが存在した場合、データ取得処理部３０４は残りのダウンロード処理を行うため、Ｓ４０５に遷移する。一方で全てのダウンロードが完了した場合、処理はＳ４１０に遷移する。

Ｓ４０５にて、データ取得処理部３０４は、ＵＲＬリストからファイルサイズが取得できていない次のファイルを選択し、サーバコンピュータ１０１から該当ファイルのファイルサイズを取得する。データ取得処理部３０４は、ＨＴＴＰのＨＥＡＤコマンドを用いることでファイルサイズ部を含むヘッダのみのレスポンスを得ることが出来る。本実施例ではＨＴＴＰが用いられるが、ファイルサイズを取得できるプロトコルや、コンテンツ生成を確認出来る方法があれば、どのようなプロトコルであっても良い。

Ｓ４０６にて、データ取得処理部３０４は、正常にファイルサイズがサーバコンピュータ１０１から取得出来た場合、Ｓ４０７にてファイル取得スレッドに該当ファイルのダウンロードを指示する。一方で正常にファイルサイズが取得できなかった場合、Ｓ４０８に遷移する。なお、Ｓ４０５で得たＨＴＴＰレスポンスの内容から、致命的なエラーであると判断した場合、即座に異常系の処理を行う。つまり、Ｓ４０８への処理の遷移は、ファイルが未完成の場合など、ファイル取得が期待出来る場合に限られる。

Ｓ４０８において、データ取得処理部３０４は一定時間待機する。Ｓ４０８における待機はサーバコンピュータ１０１のファイル生成を待つものであり、待機時間は一定時間やサーバコンピュータ１０１から何らかのヒントを得て、動的に変える手法であっても良い。

データ取得処理部３０４は、Ｓ４０８にて待機後、Ｓ４０９にてファイルサイズ取得用ＴＣＰコネクションの再接続を行う。その後、処理はＳ４０５に遷移し、データ取得処理部３０４はサーバコンピュータ１０１からファイルサイズの取得を試みる。

Ｓ４１０にて、データ取得処理部３０４はファイルサイズ取得用コネクションを切断する。その後、Ｓ４１１においてファイル取得スレッドに終了を通知し、Ｓ４１２にてファイル取得スレッドの処理が終了するまで待機する。全ての処理が終了後、Ｓ４１３にて、データ取得処理部３０４は上位レイヤアプリケーション３０１にダウンロードの完了を通知する。

次に、ファイル取得スレッドの処理を表すファイル取得処理（５００）について、図５を用いて説明する。Ｓ５０１にて、データ取得処理部３０４はメインスレッドから指示があるかどうかを確認する。ここでメインスレッドとは、ダウンロード処理（４００）の処理を指す。ここでの指示とはＳ４０７、Ｓ４１１で行われる通知のことを指す。

メインスレッドから指示が無いと判断した場合、Ｓ５０２にて、データ取得処理部３０４は指示が来るまで待機する。

Ｓ５０１でメインスレッドからのダウンロード指示があると判断した場合、処理はＳ５０３に遷移する。Ｓ５０３にて、データ取得処理部３０４は、メインスレッドから指示されたダウンロードサイズ分の領域を転送データ記憶部３０２に確保する。

Ｓ５０４において、データ取得処理部３０４は、ファイル取得用ＴＣＰコネクションがサーバコンピュータ１０１と接続済みであるかどうかを確認する。もし、接続されていなかった場合、Ｓ５０５にてサーバコンピュータ１０１に対してＴＣＰコネクションを確立する。

Ｓ５０６にて、データ取得処理部３０４は、メインスレッドから指示されたファイルのダウンロードを開始する。正常にダウンロードが完了後、Ｓ５０７にて取得ファイルを上位レイヤアプリケーション３０１に譲渡する。なお、本実施例ではダウンロード完了後に上位レイヤアプリケーション３０１に取得データを譲渡しているが、サーバコンピュータ１０１からの取得途中に逐一譲渡しても良い。また、本実施例では上位レイヤアプリケーション３０１は画像処理装置への印刷を行うため、Ｓ５０７にて譲渡される度に上位レイヤアプリケーション３０１は画像処理装置へ印刷データを送信する。この、ファイルのダウンロード処理と画像処理装置への印刷処理は並列に行っても良い。

Ｓ５０１にてデータ取得処理部３０４がメインスレッドから終了指示を受け取った場合、処理はＳ５０８に遷移する。Ｓ５０８では、データ取得処理部３０４は、ファイル取得用コネクションを切断し、Ｓ５０９にてメインスレッドに終了を通知する。ここでＳ５０９の通知は、メインスレッドの処理であるＳ４１２に該当する。

なお、ファイル取得スレッドが使用するファイル取得用ＴＣＰコネクションは無通信時間が存在する可能性があるため、キープアライブと呼ばれる接続確認のための通信を定期的に行っても良い。

図６を用いて、本実施例によるＴＣＰ通信の挙動の変化について説明する。図６のグラフの横軸は時間であり、縦軸は輻輳ウィンドウサイズを表す。輻輳ウィンドウサイズは、ＴＣＰ通信において通信路に大量のパケットが流れることによる輻輳が発生しないように、一度に送信するデータ量を制限するために用いられる。ＴＣＰにおける輻輳回避アルゴリズムは様々なものがあるが、小さな輻輳ウィンドウサイズから徐々に増加させ、パケット損失や応答の遅延などの検出により、輻輳ウィンドウサイズを再び小さくする手法が一般的である。輻輳ウィンドウサイズは、応答無しに一度に送信できるパケットの量であるから、図６における縦軸は転送速度であると捉えても良い。

図６（Ａ）は既存の手法で転送した場合、図６（Ｂ）は本実施例を適用した場合を示している。図６に示す例では、クライアントコンピュータ１０３がサーバコンピュータ１０１から２つのページをダウンロードする際の輻輳ウィンドウサイズの変化が示されている。図６（Ａ）では、１ページ目のダウンロード後にサーバコンピュータ１０１からコネクションが切断されている。コネクションが切断される理由としては、サーバコンピュータ１０１による２ページ目の生成が完成しないうちに、クライアントコンピュータ１０３が２ページ目の要求を行うことが挙げられる。この場合、１ページ目のダウンロード後にＴＣＰコネクションの再接続が必要となり、ＴＣＰコネクションの再接続は輻輳ウィンドウサイズの調整が再び必要となるため、帯域幅を十分に生かせない結果となる。

図６（Ｂ）では、２ページ目の生成前に取得を要求したとしても、切断されるのはファイルサイズ取得用コネクションであり、実際にダウンロードを行うファイル取得用コネクションは切断されない。その結果、一時的にダウンロードが中断したとしてもファイル取得用コネクションの接続は維持されるため、輻輳ウィンドウサイズは維持される。よって、再接続による、速度低下を回避出来るため、２ページ以降に対して帯域幅を有効に活用できる。

以上、本発明の情報処理装置によれば、複数の通信コネクションを利用し、Ｗｅｂサーバからコンテンツを取得するまで通信コネクションを維持することによりデータ通信の高速化を実現することが可能となる。取得用ＴＣＰコネクションの切断、再接続を回避することができるため、ＴＣＰ輻輳回避アルゴリズムのスロースタートの弊害を回避出来る。そのため、サーバコンピュータとクライアントコンピュータはより高速に通信を行うことが出来る。特に長距離広帯域環境で高速に通信できるようになる。

（実施例２）
実施例１におけるダウンロード管理処理部３０３では、サイズ取得用コネクションとファイル取得用コネクションを使い分けることにより、サーバコンピュータ１０１からの切断に足して、輻輳ウィンドウサイズを維持する方法を示した。本実施例では、実施例１に加えサーバコンピュータ１０１からのファイルのダウンロードをマルチＴＣＰコネクション化する手法を示す。

なお、サーバコンピュータ１０１は実施例１の要件に加え、分割ダウンロードに必要なＲａｎｇｅヘッダを使用可能とする。また、ダウンロード管理処理部３０３およびデータ取得処理部３０４が行う、マルチＴＣＰコネクションを用いた分割受信という手法は、一般的に広く知られているため、その基本的な動作は記述しない。

ここで、マルチＴＣＰコネクションを用いた分割受信とは、何らかのファイルをサーバコンピュータ１０１からダウンロードしたい場合、そのファイルを分割し、複数のＴＣＰコネクションを用いて並列にダウンロードする手法である。この手法を用いることで、ＴＣＰの持つ、遅延の大きい環境における速度の低下を軽減することが出来る。

例えば、固定ＴＣＰコネクション数でファイルサイズを基に等分で分割する手法であっても良いし、通信状況に応じてＴＣＰコネクション数を動的に増減させる手法、または、ユーザにＴＣＰコネクション数を問い合わせる手法などであっても良い。本実施例では、上位レイヤアプリケーション３０１からダウンロード管理処理部３０３に対して、ＴＣＰコネクション数が渡されるものとする。

図７を用いて、本実施例のソフトウェア構成の説明を行う。転送速度記憶部７０１を除き、実施例１と同じ構成であり、共通部分の説明は省く。転送速度記憶部７０１は、各ＴＣＰコネクションの転送速度を記憶しておく領域であり、次に取得すべきファイルの分担量の割り当ての際に用いる。転送速度記憶部７０１はＲＡＭ２０３や、外部記憶装置２０５などに確保される。また、必要であればコンピュータ外部に確保されていても良い。

次に、図８を用いて、マルチＴＣＰコネクション通信を行うデータ取得処理部３０４の動作を説明する。図８は、実施例１で説明したファイル取得処理（５００）と重複部分がある。重複部分は実施例１で説明済みのため、ここでは説明しない。

Ｓ８０１にて、データ取得処理部３０４は、上位レイヤアプリケーション３０１から分割数を取得する。この分割数は上位レイヤアプリケーション３０１の都合に応じて指定される。例えば、サーバコンピュータ１０１に負荷をかけたくない場合は少なく、より高速化を望む場合は多く指定される。

Ｓ８０２にて、データ取得処理部３０４は、サーバコンピュータ１０１に対しＳ８０１で取得した分割数分、ＴＣＰコネクションの接続を確立する。次にデータ取得処理部３０４は、ダウンロード負担量算出処理（９００）を行う。このダウンロード負担量算出処理（９００）は、各ＴＣＰコネクションに最適な負担量を算出処理である。データ取得処理部３０４は、Ｓ９００にて算出した負担量を基にダウンロードを開始すると共に、それまでの各ＴＣＰコネクションの転送速度をＳ８０３にて転送速度記憶部７０１に格納する。メインスレッドから終了通知が来た場合、データ取得処理部３０４はＳ８０４にて接続していた各ＴＣＰコネクションを全て切断する。

続いて、図９を用いてダウンロード負担量算出処理（９００）について詳細に説明する。Ｓ９０１にて、データ取得処理部３０４は、初期ファイル、つまり最初のファイルのダウンロード要求であるかどうかを確認する。もし最初のファイルであればＳ９０２に遷移し、各ＴＣＰコネクションに均等となるよう取得負担量を算出する。一方で最初のファイルのダウンロード要求で無かった場合、Ｓ９０３に遷移する。

Ｓ９０３にて、データ取得処理部３０４は、転送完了済みＴＣＰコネクションがあるどうかを確認する。１つも転送完了済みＴＣＰコネクションが無かった場合、Ｓ９０４に遷移し、１つ以上のＴＣＰコネクションが転送完了するまで待機する。転送が完了しているＴＣＰコネクションがあった場合、Ｓ９０５に遷移する。

Ｓ９０５にて、データ取得処理部３０４は、転送速度記憶部７０１から各ＴＣＰコネクションの転送速度を取得する。次にＳ９０６にて、データ取得処理部３０４は、転送が未完了のＴＣＰコネクションのダウンロード残量も取得する。ダウンロード残量は次のファイルのダウンロード負担量算出のため必要となる。

Ｓ９０７にて、データ取得処理部３０４は、各ＴＣＰコネクションの分担量を算出する。このダウンロード分担量は、ダウンロード要求のあった次のファイルのダウンロード時間が最短となるよう算出する。ダウンロード時間を短縮できるような手法であれば、どのような算出方法であってもよい。本実施例ではダウンロード要求のあった次に取得すべきファイルのサイズと、Ｓ９０５で取得した転送速度、およびＳ９０６で取得したダウンロード残量から算出する。換言すれば、データ取得処理部３０４は、ファイルが初期ファイルでなければ、各ＴＣＰコネクションの通信速度に応じて、取得すべきファイル毎に各ＴＣＰコネクションに振り分ける負担量を変更する。

具体的な算出法は、まず転送速度とダウンロード残量から残りのダウンロードが完了するまでの時間を算出する。データ取得処理部３０４は、ダウンロード未完了のＴＣＰコネクションの中で、最も残りのダウンロードが完了するまでの時間がかかるものを選択する。選択したＴＣＰコネクションのダウンロード時間分をダウンロードが完了しているＴＣＰコネクションの転送速度から推定ダウンロード量として加算する。データ取得処理部３０４は、推定ダウンロード量がダウンロード要求のあったファイルのサイズを上回るか、ダウンロード未完了のＴＣＰコネクションが全て計算済みになるまで、この処理を繰り返す。最終的に推定ダウンロード量がダウンロード要求のあったファイルのサイズを下回った場合、データ取得処理部３０４は、各ＴＣＰコネクションの転送速度に比例して残りのサイズの分担を決定する。

最後に、データ取得処理部３０４はＳ９０８にて算出した分担量を返却し処理から戻る。以上、説明した本実施例によれば、個々のＴＣＰコネクションの転送速度が異なる環境化においても、各ファイルのダウンロード完了時間をより短縮することが出来る。

（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良い。また仮想化ＯＳなどで構成される場合も含めて一つの機器からなる装置に適用しても良い。さらに、情報処理装置がインターネットを経由したクラウドコンピューティングで構成されるシステムに適用しても良い。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。

また、プログラムの実行環境は、パーソナルコンピュータやパーソナルコンピュータでのオペレーションシステムを仮想化した仮想ＰＣやリモートＰＣを含む。さらには、画像処理装置、プリンタやＭＦＰ（マルチファンクションペリフェラル）等の組み込みコンピュータで実行される場合も含まれる。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、様々なものが使用できる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどである。

その他、プログラムの供給方法としては、クライアントコンピュータ１０３のブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＤＶＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。

Claims (8)

1. サーバ装置との第１の通信コネクションを確立して、コンテンツを動的に生成する前記サーバ装置から前記コンテンツが生成されたか否かを示す情報を取得する第１の通信手段と、
   前記サーバ装置との第２の通信コネクションを確立して、生成された前記コンテンツを取得する第２の通信手段とを備え、
   前記第２の通信手段は、前記コンテンツの取得が完了するまで前記第２の通信コネクションを維持する
   ことを特徴とする情報処理装置。
2. 前記第１の通信手段は、前記コンテンツの各ファイルサイズを取得し、
   前記第２の通信手段は、前記ファイルサイズが取得されたファイルをダウンロードする
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記第２の通信手段は、複数の前記第２の通信コネクションを確立し、前記ファイルサイズが取得されたファイルを分割して並列にダウンロードする
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記第２の通信手段は、前記ファイルが初期ファイルであれば、前記ファイルの取得負担量を前記各第２の通信コネクションに均等に振り分ける
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記第２の通信手段は、前記ファイルが前記初期ファイルでなければ、前記各第２の通信コネクションの転送速度に応じて、取得すべきファイル毎に前記各第２の通信コネクションに振り分ける負担量を変更する
   ことを特徴とする請求項４に記載の情報処理装置。
6. 前記第２の通信手段は、前記ファイルのダウンロードが完了した前記第２の通信コネクションが存在する場合、次に取得すべきファイルのサイズ、前記各第２の通信コネクションの転送速度、および前記ダウンロードが未完了の第２の通信コネクションのダウンロード残量に基づいて前記次に取得すべきファイルの分担量を算出し、前記各第２の通信コネクションに振り分ける
   ことを特徴とする請求項２乃至４のいずれか一項に記載の情報処理装置。
7. サーバ装置との第１の通信コネクションを確立して、コンテンツを動的に生成する前記サーバ装置から該コンテンツが生成されたか否かを示す情報を取得する第１の通信工程と、
   前記サーバ装置との第２の通信コネクションを確立して、生成された前記コンテンツを取得する第２の通信工程とを備え、
   前記第２の通信工程では、前記コンテンツの取得が完了するまで前記第２の通信コネクションが維持される
   ことを特徴とする情報処理装置の制御方法。
8. 請求項７に記載の制御方法をコンピュータにより実行させることを特徴とするコンピュータプログラム。

Images