JP6129526B2 - 通信装置、通信方法およびプログラム - Google Patents

Description

本発明の実施形態は、通信装置、通信方法およびプログラムに関する。

ネットワークを介して接続されたサーバ装置とクライアント装置との間でデータの送受信を行う情報通信システムにおいて、サーバ装置とクライアント装置は例えばコネクション型の伝送方式を用いて情報の送受信を行う。

コネクション型の伝送方式として代表的なものにＴＣＰ／ＩＰがある。ＴＣＰ／ＩＰを用いる場合、送信側は受信側との間でＴＣＰコネクションを確立し、シーケンス番号やウィンドウサイズ等を含むＴＣＰヘッダをデータに付加し、パケット化して受信側に送出する。受信側からは、データを受信できたことを示す確認応答（ＡＣＫ）が送出される。これにより、データ到着の信頼性と順序性が保証された転送が可能となる。またＴＣＰは、ネットワークが輻輳状態に陥るのを防止するため、ネットワークに送出するデータレートを制御する輻輳制御の機構を備える。

ＴＣＰでは、輻輳制御を実現するために、送信側が内部的に輻輳ウィンドウというパラメータを使用する。輻輳ウィンドウとは、送信側が受信側からの確認応答無しで連続送信できる最大のパケットの個数を表す。ＴＣＰコネクションの作成直後は初期値として輻輳ウィンドウの値を小さくすることで、送信するデータを少なくする。その後、確認応答が到着するごとに輻輳ウィンドウの値を大きくしてデータを大量に送り、ネットワークの帯域幅を有効に利用する。この動作はスロースタートとして知られている。

特開２０１１−２３３９７９号公報 特開２００５−１１２６７号公報 特開２０００−５７０９５号公報

同一のサーバ装置とクライアント装置の間でＴＣＰによるデータ通信を繰り返し行う場合において、ＴＣＰコネクションの開始や終了の処理負荷や遅延時間を削減し、ネットワークの帯域幅の利用効率を向上することを課題とする。

実施形態によれば、コネクション型のデータ通信を行う通信装置であって、コネクションを利用してデータを供給または要求するアプリケーションと、前記データ通信の終了要求を受け取り、前記コネクションを終了することなく前記アプリケーションに対して前記コネクションの終了を通知する終了部と、を具備する通信装置が提供される。

実施形態に係る映像配信システムを示す図 サーバ装置の起動と接続待受を示すフローチャート データの種別に応じたヘッダの例を示す図 動画ファイルのプレイリストの例を示す図 ＴＣＰコネクションの開始（１回目）のサーバ装置における処理を示すフローチャート ＴＣＰコネクションの開始（１回目）のクライアント装置における処理を示すフローチャート ＴＣＰコネクションの終了（再利用を待機）のサーバ装置の処理を示すフローチャート ＴＣＰコネクションの終了（再利用を待機）のクライアント装置の処理を示すフローチャート クライアント装置の記憶部に記憶される情報の例を示す図 サーバ装置の記憶部に記憶される情報の例を示す図 ＴＣＰコネクションの開始（２回目）のサーバ装置の処理を示すフローチャート ＴＣＰコネクションの開始（２回目）のクライアント装置の処理を示すフローチャート 第２の実施形態の構成を示す図 ＨＴＴＰによる情報表示の例を示す図

以下、実施の形態について、図面を参照して説明する。

（第１の実施形態）
図１は、実施形態に係る映像配信システムの構成を示す。ＨＴＴＰサーバとして機能する情報処理端末（サーバ装置１）と、ＨＴＴＰクライアントとして機能する情報処理端末（クライアント装置２）とが、ネットワーク３を介して接続されている。サーバ装置１はチャンクによる映像アダプティブストリーミングを提供する。

（サーバ装置の構成）
サーバ装置１は、ＨＴＴＰサーバアプリケーション１０１と、開始部１０２と、記憶部１０３と、終了部１０４と、通信部１０５とを含む。

ＨＴＴＰサーバアプリケーション１０１は、クライアント装置２からのＨＴＴＰリクエストを受信し、要求された動画ファイル（チャンク）をＨＴＴＰレスポンスとして送出する。

開始部１０２は、ＨＴＴＰサーバアプリケーション１０１からの接続待受要求を受けて、クライアント装置２からのＴＣＰの接続要求を待機する。また、ＴＣＰコネクションの再利用指示を受けた場合、利用可能なものが存在する場合には、当該ＴＣＰコネクションの識別子をＨＴＴＰサーバアプリケーション１０１に通知する。

記憶部１０３は、再利用待機中のＴＣＰコネクションに関する情報を記憶する。

終了部１０４は、クライアント装置２からのＴＣＰコネクションの終了を待機する。また、使用中のＴＣＰコネクションの再利用待機がクライアント装置２から指示された場合には、当該ＴＣＰコネクションの識別子をＨＴＴＰサーバアプリケーション１０１に通知する。

通信部１０５は、クライアント装置２との間でＴＣＰコネクションの開始と終了を行う。また、クライアント装置２からのＨＴＴＰリクエストをＨＴＴＰサーバアプリケーション１０１に通知し、返答されたＨＴＴＰレスポンスをクライアント装置２に送出する。クライアント装置２からＴＣＰコネクションの再利用指示または再利用待機指示があった場合には、それぞれ開始部１０２または終了部１０４に通知する。

（クライアント装置の構成）
クライアント装置２は、ＨＴＴＰクライアントアプリケーション２０１と、開始部２０２と、記憶部２０３と、終了部２０４と、通信部２０５とを含む。

ＨＴＴＰクライアントアプリケーション２０１は、サーバ装置１に対してＨＴＴＰリクエストを送出することにより動画ファイル（チャンク）を要求し、ＨＴＴＰレスポンスにより受信したチャンクを再生する。

開始部２０２は、ＨＴＴＰクライアントアプリケーション２０１からの接続要求を受けて、サーバ装置１に対するＴＣＰの接続要求を送出する。また、サーバ装置１との間でＴＣＰコネクションの再利用が可能である場合には、当該ＴＣＰコネクションの再利用指示をサーバ装置１に送出する。

記憶部２０３は、再利用待機中のＴＣＰコネクションに関する情報を記憶する。

終了部２０４は、ＨＴＴＰクライアントアプリケーション２０１からのＴＣＰコネクションの終了要求を受けて、当該使用中のＴＣＰコネクションを終了しない当該ＴＣＰコネクションの再利用待機指示をサーバ装置１に送出する。また、ＴＣＰコネクションの再利用を行わない／行なえない場合には、サーバ装置１にＴＣＰコネクションの終了を送出する。

通信部２０５は、サーバ装置１との間でＴＣＰコネクションの開始と終了を行う。また、開始部２０２または終了部２０４からのＴＣＰコネクションの再利用指示または再利用待機指示をサーバ装置１に通知する。

（処理の流れ）
次に、本実施形態に係る情報通信システムにより行われる処理の流れについて、図面を適宜参照しながら説明する。

［サーバ起動と接続待受］
図２は、サーバ装置１の起動と接続待受を示すフローチャートである。

始めに、サーバ装置１においてＨＴＴＰサーバアプリケーション１０１が起動される。ＨＴＴＰサーバアプリケーション１０１は開始部１０２、記憶部１０３、終了部１０４、通信部１０５をロードする。起動後、ＨＴＴＰサーバアプリケーション１０１は、開始部１０２に接続待受要求を出す。なお本実施形態では、開始部１０２はＨＴＴＰサーバアプリケーション１０１に対し、標準ソケットライブラリの接続待受用のＡＰＩ（アプリケーション・プログラミング・インターフェース）であるａｃｃｅｐｔ関数と互換性のあるＡＰＩを提供するものとする。以下の説明では、区別のため、標準ソケットライブラリにおける接続待受用の関数をａｃｃｅｐｔと呼び、開始部１０２が提供する互換ＡＰＩをａｃｃｅｐｔ＿ｎｅｗと呼ぶことにする。また、標準ソケットライブラリのＡＰＩは通信部１０５において提供されるものとする。ＨＴＴＰサーバアプリケーション１０１はこのａｃｃｅｐｔ＿ｎｅｗ関数をコールすることにより開始部１０２に接続待受を指示する。ａｃｃｅｐｔ＿ｎｅｗの呼び出しの引数には、ＨＴＴＰサーバアプリケーション１０１が使用するポート番号（例えば８０）が指定される。

次に開始部１０２は、ａｃｃｅｐｔ＿ｎｅｗにおいて、通信部１０５に接続の待受要求を出し、通知を受けるまで待機する。これを受けて通信部１０５は、ソケットライブラリのａｃｃｅｐｔ関数をコールし、クライアント装置２からのＴＣＰの接続要求（ＳＹＮ）の待受を行う。このときａｃｃｅｐｔの引数には、ａｃｃｅｐｔ＿ｎｅｗで渡されたポート番号を用いる。また、通信部１０５は、これと並行して、クライアント装置２の開始部２０２との通信用のポート番号（例えば９００１）および終了部２０４との通信用のポート番号（例えば９００２）についてａｃｃｅｐｔ関数をコールし、ＴＣＰの接続要求の待受を行う。通信部１０５は、アプリケーションのポート番号（８０）または開始部２０２との通信用のポート番号（９００１）または終了部２０４との通信用のポート番号（９００２）のいずれかにＴＣＰの接続要求が来るまで待機する。

なお、本実施形態では、開始部１０２と開始部２０２の間の通信と、終了部１０４と終了部２０４の間の通信に、専用のポート番号によるＴＣＰを利用するものとするが、必ずしもこれに限らなくともよい。例えばＵＤＰなど任意の伝送プロトコルを用いてもよい。あるいは、ＨＴＴＰサーバアプリケーション１０１とＨＴＴＰクライアントアプリケーション２０１が使用するＴＣＰコネクションに、開始部１０２と開始部２０２の間の通信および終了部１０４と終了部２０４の間の通信を多重化してもよい。ただしこの場合、ＨＴＴＰで使用するデータと、開始部（１０２，２０２）および終了部（１０４，２０４）で使用するデータが一つのストリームに混在することになるため、通信部１０５および通信部２０５において、データの種別に応じたヘッダを付与する必要がある。付与するヘッダの例を図３に示す。この例では、データ長とデータ種別を表す情報がヘッダとして付与されている。

［クライアント起動と接続要求］
次に、クライアント装置２においてＨＴＴＰクライアントアプリケーション２０１が起動される。ＨＴＴＰクライアントアプリケーション２０１は開始部２０２、記憶部２０３、終了部２０４、通信部２０５をロードする。ＨＴＴＰクライアントアプリケーション２０１は例えば動画プレイヤーである。ＨＴＴＰクライアントアプリケーション２０１は、図４に示すような動画ファイルのプレイリストを予め保持しているものとする。プレイリストには、１０秒のチャンクに分割されたファイルの再生時間とそのＵＲＬの組が羅列されている。ＨＴＴＰクライアントアプリケーション２０１は、起動後、例えばユーザからの再生開始等の操作を契機として、リストに記載のファイルを上から順に取得し、再生を行う。

ＨＴＴＰクライアントアプリケーション２０１は開始部２０２に対し、データ通信を開始するために接続要求を出す。なお本実施形態では、開始部２０２は標準ソケットライブラリの接続要求用のＡＰＩであるｃｏｎｎｅｃｔ関数と互換性のあるＡＰＩを提供するものとする。以下の説明では、区別のため、標準ソケットライブラリにおける接続要求用の関数をｃｏｎｎｅｃｔと呼び、開始部２０２が提供する互換ＡＰＩをｃｏｎｎｅｃｔ＿ｎｅｗと呼ぶことにする。また、標準ソケットライブラリのＡＰＩは通信部２０５において提供されるものとする。ＨＴＴＰクライアントアプリケーション２０１はこのｃｏｎｎｅｃｔ＿ｎｅｗ関数をコールすることにより開始部２０２に接続要求を指示する。ｃｏｎｎｅｃｔ＿ｎｅｗの呼び出しの引数には、サーバ装置１のＩＰアドレスと、ＨＴＴＰクライアントアプリケーション２０１のポート番号（８０）が指定される。

次に、開始部２０２は、ｃｏｎｎｅｃｔ＿ｎｅｗにおいて、引数として渡されたＩＰアドレスとポート番号の組に一致するエントリが記憶部２０３に存在するか否かを判定する。ＨＴＴＰクライアントアプリケーション２０１の起動直後は記憶部２０３にエントリが存在しないため、判定の結果はＮＯである。ＹＥＳの場合の処理は後述する。ＮＯの場合、開始部２０２は通信部２０５に接続要求を指示し、通知を受けるまで待機する。これを受けて通信部２０５は、ソケットライブラリのｃｏｎｎｅｃｔ関数をコールし、サーバ装置１にＴＣＰの接続要求（ＳＹＮ）の送出を行う。このときｃｏｎｎｅｃｔの引数には、ｃｏｎｎｅｃｔ＿ｎｅｗで渡されたサーバ装置１のＩＰアドレスと、ＨＴＴＰクライアントアプリケーション２０１のポート番号（８０）を用いる。

［ＴＣＰコネクションの開始（１回目）］
図５は、ＴＣＰコネクションの開始（１回目）のサーバ装置１における処理、図６は、クライアント装置２の処理を示すフローチャートである。

サーバ装置１の通信部１０５は、アプリケーションのポート番号（８０）へのＴＣＰの接続要求（ＳＹＮ）が到着すると、クライアント装置２の通信部２０５にＳＹＮとＡＣＫを送出する。さらに通信部２０５は通信部１０５にＡＣＫを送出する。これにより３ウェイハンドシェイクが完了し、通信部１０５と通信部２０５でＴＣＰコネクションが確立された状態となる（Ｓ１０１）。

通信部１０５は、ＴＣＰコネクションの確立が完了すると、開始部１０２に確立完了を通知する。これを受けて開始部１０２はＨＴＴＰサーバアプリケーション１０１に確立完了を通知する。このときＨＴＴＰサーバアプリケーション１０１には、確立されたＴＣＰコネクションの識別子（ソケットディスクリプタなど）が渡される。次にＨＴＴＰサーバアプリケーション１０１は通信部１０５が提供するデータ受信のためのＡＰＩであるｒｅｃｖ関数をコールする。引数には先ほど受け取ったＴＣＰコネクションの識別子を渡す。これによりクライアント装置２からのＨＴＴＰリクエストの到着を待機する（Ｓ１０２）。あわせてＨＴＴＰサーバアプリケーション１０１は、再び開始部１０２に待受要求を出す。これ以降の処理の流れは前述したものと同一である。

なお、本実施形態ではｃｏｎｎｅｃｔ＿ｎｅｗの完了の通知とともにＴＣＰコネクションの識別子を渡すものとしたが、必ずしもこれに限らなくともよい。ソケットを作成するためのＡＰＩとしてｓｏｃｋｅｔ関数を通信部１０５がＨＴＴＰサーバアプリケーション１０１に提供し、この関数をコールすることでＴＣＰコネクションの識別子が得られ、これをｃｏｎｎｅｃｔ＿ｎｅｗへの引数として渡す、といったＡＰＩの仕様に対しても適用可能である。

一方、クライアント装置２の通信部２０５は、ＴＣＰコネクションの確立（Ｃ２０１）が完了すると、開始部２０２に確立完了を通知する。これを受けて開始部２０２はＨＴＴＰクライアントアプリケーション２０１に確立完了を通知する。このときＨＴＴＰクライアントアプリケーション２０１には、確立されたＴＣＰコネクションの識別子が渡される。次にＨＴＴＰクライアントアプリケーション２０１は、通信部２０５が提供するデータ送信のためのＡＰＩであるｓｅｎｄ関数をコールする。引数としては、先ほど受け取ったＴＣＰコネクションの識別子を渡すほか、取得したいファイルのＵＲＬを含むＨＴＴＰリクエストを作成し、これを渡す。このＨＴＴＰリクエストは、作成されたＴＣＰコネクションを通じてサーバ装置１に送出され（Ｃ２０２）、さらにＨＴＴＰサーバアプリケーション１０１に渡される。

ＨＴＴＰサーバアプリケーション１０１は、ＨＴＴＰリクエストを受け取ると、自身が保持する動画ファイルをＨＴＴＰレスポンスとしてクライアント装置２に送出する（Ｓ１０３）。送出にはｓｅｎｄ関数を用いる。以後、ＨＴＴＰクライアントアプリケーション２０１は繰り返しｒｅｃｖ関数をコールすることで動画ファイルの受信を行う（Ｃ２０３）。

［ＴＣＰコネクションの終了（再利用を待機）］
図７は、ＴＣＰコネクションの終了（再利用を待機）のサーバ装置１の処理、図８は、クライアント装置２の処理を示すフローチャートである。

サーバ装置１に対するＨＴＴＰリクエストの送出により、クライアント装置２のＨＴＴＰクライアントアプリケーション２０１は動画ファイル（チャンク）の受信を開始する。動画ファイルの受信が完了すれば、動画の再生を開始し、あわせて次の時間のチャンクの取得を行う。しかし、ネットワークの帯域幅が十分でない状況においては、動画ファイルの受信がすみやかに完了しないことがある。この場合、受信が完了するまで動画の再生を待機するという方法が一つの対処だが、そうすると、受信完了までユーザを長く待たせてしまうことになる。あるいは、２個目以降のチャンクの受信においては、チャンクごとに動画の再生がストップしてしまうことになり、ユーザの視聴の快適さが損なわれる。そこで、予め定められた再生時刻までに動画ファイルの受信が完了しなかった場合、その時点でファイルの受信を中断し、より低ビットレートのチャンクの取得に切り替える。ここでは、動画の受信を開始してから規定時間（１０秒）後を予定の再生時刻とする。クライアント装置２は、規定時間（５秒など）後の時刻において、それまでに受信できたをデータサイズと経過時間から帯域幅を予想し、この帯域幅の大きさが今後も継続すると仮定した場合に残りのデータの受信が再生予定時刻までに間に合いそうか否かを判断する。間に合いそうにないと判断した場合、これまでの受信をキャンセルし、より低ビットレートのチャンクの取得に切り替えるものとする。

ＨＴＴＰの仕様では、受信が完了していないデータの伝送を途中でキャンセルする機能は提供されていない。そこで、データ通信を終了するために、クライアント側からＴＣＰコネクションを終了するという動作を行う。ＨＴＴＰクライアントアプリケーション２０１は、終了部２０４に終了要求を出す。なお本実施形態では、終了部２０４はＨＴＴＰクライアントアプリケーション２０１に対し、標準ソケットライブラリにおける接続終了用のＡＰＩであるｃｌｏｓｅ関数と互換性のあるＡＰＩを提供するものとする。以下の説明では、区別のため、標準ソケットライブラリにおける接続終了用の関数をｃｌｏｓｅと呼び、終了部２０４が提供する互換ＡＰＩをｃｌｏｓｅ＿ｎｅｗと呼ぶことにする。ＨＴＴＰクライアントアプリケーション２０１はこのｃｌｏｓｅ＿ｎｅｗ関数をコールすることにより終了部２０４に接続終了を指示する。ｃｌｏｓｅ＿ｎｅｗの呼び出しの引数には、動画ファイルの受信に使用したＴＣＰコネクションの識別子が渡される。

次に終了部２０４は、ｃｌｏｓｅ＿ｎｅｗにおいて、渡されたＴＣＰコネクションの識別子と、サーバ装置１のＩＰアドレスとポート番号の情報を記憶部２０３に記憶する（図８のＣ４０１）。記憶部２０３に記憶される情報の例を図９に示す。同図では、上述の情報と、記憶時の時刻（クライアント装置２の起動時からの経過時間：ミリ秒）が記されている。また、これと並行して、サーバ装置１の終了部１０４との通信用のポート番号（９００２）に対してｃｏｎｎｅｃｔ関数をコールし、ＴＣＰの接続要求を行う。このポート番号に関して通信用のＴＣＰコネクションの確立が完了すると（Ｓ３０１，Ｃ４０２）、終了部２０４は終了部１０４に対し待機指示を送出する（Ｃ４０３）。ここでいう「待機」の指示とは、後述する処理により終了しないＴＣＰコネクションの再利用に向けた待機の指示を意味する。終了部１０４は、この待機指示を受け取ると（Ｓ３０２）、当該通信用のＴＣＰコネクションを終了したのち（Ｓ３０３）、渡されたＴＣＰコネクションの識別子とクライアント装置２のＩＰアドレスとポート番号の情報を記憶部１０３に記憶する（Ｓ３０４）。

記憶部１０３に記憶される情報の例を図１０に示す。同図では、上述の情報と、記憶時の時刻（サーバ装置１の起動時からの経過時間：ミリ秒）が記されている。さらに、終了部１０４はＨＴＴＰサーバアプリケーション１０１に対し接続の終了を通知する（Ｓ３０５）。実際には、ＴＣＰコネクションは終了していない状態で存在する。

ＨＴＴＰサーバアプリケーション１０１は、接続終了通知を受けてデータの送出を終了する。

なお、終了部１０４からＨＴＴＰサーバアプリケーション１０１への接続終了の通知のやり方は任意である。ＨＴＴＰサーバアプリケーション１０１の指定されたコールバック関数を呼び出すというやり方であってもよいし、ＨＴＴＰサーバアプリケーション１０１が行うｓｅｎｄやｒｅｃｖ等のＡＰＩの呼び出しに対し規定のエラーコードを返すというやり方であってもよい。

終了部２０４は、待機指示の送出が完了すると、通信用のＴＣＰコネクションの終了を行う（Ｃ４０４）。終了部２０４は、以上の処理が完了すると、ＨＴＴＰクライアントアプリケーション２０１に対し、接続終了が完了したことを通知する（Ｃ４０５）。実際には、ＴＣＰコネクションは終了していない状態で存在する。

［ＴＣＰコネクションの開始（２回目）］
図１１は、ＴＣＰコネクションの開始（２回目）のサーバ装置１の処理、図１２は、クライアント装置２の処理を示すフローチャートである。

ＨＴＴＰクライアントアプリケーション２０１は、ｃｌｏｓｅ＿ｎｅｗ関数の呼び出しが終了すると、次の時間のチャンクを取得するために、再びｃｏｎｎｅｃｔ＿ｎｅｗをコールして開始部２０２に対し接続要求を出すことによりデータ通信を開始する。ｃｏｎｎｅｃｔ＿ｎｅｗ関数の呼び出しの引数は１回目のときと同一である。

次に開始部２０２は、ｃｏｎｎｅｃｔ＿ｎｅｗにおいて、引数として渡されたＩＰアドレスとポート番号の組に一致するエントリが記憶部２０３に存在するか否かを判定する。今回は、図９に示したように、対応するエントリが存在するため、判定の結果はＹＥＳである（なおＮＯの場合の処理は既に述べた）。ＹＥＳの場合、開始部２０２はこのＩＰアドレスに対するＴＣＰコネクションが接続終了されていない状態で存在しており、再利用可能であることを知る（Ｃ６０１）。ＮＯの場合、ＨＴＴＰサーバアプリケーション１０１のポートでＴＣＰコネクションを確立する（Ｃ６０２）。これは、ＴＣＰコネクションの再利用には相当しない。

上記ＴＣＰコネクションを再利用可能である場合、記憶部２０３から当該エントリを削除する（Ｃ６０３）。さらに、サーバ装置１の開始部１０２との通信用のポート番号（９００１）に対してｃｏｎｎｅｃｔ関数をコールし、ＴＣＰの接続要求を行う。このポート番号に関して通信用ＴＣＰコネクションの確立が完了すると（Ｓ５０１，Ｃ６０４）、開始部２０２は開始部１０２に対し再利用指示を送出する（Ｃ６０５）。再利用指示には、ｃｏｎｎｅｃｔ＿ｎｅｗの呼び出しにおいて渡されたＩＰアドレス（クライアント装置２自身のＩＰアドレス）とポート番号（８０）が付加されている。開始部１０２は、再利用指示を受信すると（Ｓ５０２）、通信用ＴＣＰコネクションを終了したのち（Ｓ５０３）、再利用指示に付加されたＩＰアドレスとポート番号の組が記憶部１０３に存在するか否かを判定する。すなわち、ＴＣＰコネクションを再利用可能であるか否かを判定する（Ｓ５０４）。今回は、図１０に示したように、対応するエントリが存在するため、判定の結果はＹＥＳである。ＹＥＳの場合、記憶部１０３から当該エントリを削除（Ｓ５０５）した上で、開始部１０２はＨＴＴＰサーバアプリケーション１０１に接続開始を通知する（Ｓ５０６）。このときＨＴＴＰサーバアプリケーション１０１には、当該エントリに記された、ＴＣＰコネクションの識別子が渡される。

開始部２０２は、再利用指示の送出が完了すると、通信用のＴＣＰコネクションの終了を行う（Ｃ６０６）。開始部２０２は、以上の処理が完了すると、ＨＴＴＰクライアントアプリケーション２０１に対し、接続要求が完了したことを通知する（Ｃ６０７）。通知の際には、記憶部２０３に記憶されていたＴＣＰストリームの識別子を合わせて通知する。以後の処理は、１回目と同様である。すなわち、ＨＴＴＰクライアントアプリケーション２０１はＨＴＴＰサーバアプリケーション１０１に対し、再利用したＴＣＰコネクションを用いてＨＴＴＰリクエストの送出を行い（Ｃ６０８）、ＨＴＴＰレスポンスで動画ファイルの受信を開始する（Ｃ６０９）。

以上のように本実施の形態によれば、同一のサーバ装置とクライアント装置の間でＴＣＰによるデータ通信を繰り返し行う場合において、一方のアプリケーションからの接続終了の指示に対し、ＴＣＰコネクションの接続を持続したまま待機させ、サーバ・クライアント双方のアプリケーションに対しては接続終了が完了した旨の通知を行う。さらに再度接続開始の指示に対しては、待機させたＴＣＰコネクションを再利用してサーバ・クライアント双方のアプリケーションに対し接続開始が完了した旨の通知を行う。こうした動作により、ＴＣＰコネクションの開始や終了の処理負荷や遅延時間を削減し、またネットワークの帯域幅の利用効率を向上することが可能となる。特に、遅延時間が大きいネットワークや、接続の開始と終了が頻繁に発生するようなアプリケーションにおいて、本実施形態による効果は顕著である。

なお、本実施形態では、開始部１０２、終了部１０４、開始部２０２、終了部２０４は、標準ソケットライブラリと互換性のあるＡＰＩを提供するものとしている。これにより、既存のＨＴＴＰサーバアプリケーション１０１やＨＴＴＰクライアントアプリケーション２０１に改変を行うことなく、本実施形態の効果を得ることが可能となる。その場合、サーバ装置１においてＨＴＴＰサーバアプリケーション１０１以外の構成要素（開始部１０２、記憶部１０３、終了部１０４、通信部１０５）を標準ソケットライブラリと互換性のあるライブラリとして構成し、ＨＴＴＰサーバアプリケーション１０１がロードする標準ソケットライブラリの代替として本ライブラリを利用するという構成を用いることも可能である。クライアント装置２においても同様に、ＨＴＴＰクライアントアプリケーション２０１以外の構成要素（開始部２０２、記憶部２０３、終了部２０４、通信部２０５）を標準ソケットライブラリと互換性のあるライブラリとして構成することができる。もちろんこれらの構成は必須ではない。ＨＴＴＰサーバアプリケーション１０１と開始部１０２、終了部１０４の間のインターフェース、および、ＨＴＴＰクライアントアプリケーション２０１と開始部２０２、終了部２０４の間のインターフェースは任意の形式で定義することが可能である。

また、本実施形態では、サーバ装置１およびクライアント装置２において、接続を持続したまま待機させるＴＣＰコネクションの個数に特に上限を設けなかったが、任意の上限を設けてよい。この場合例えば、記憶部１０３および記憶部２０３は記憶するエントリの個数に上限値を設け、新規のエントリ追加の要求が来た場合に、もしエントリの個数が上限値を超えるようであれば、エントリのうち待機時刻の値が最も古いものを削除することで、エントリの個数を上限値以下に保つことが可能となる。この場合、削除したエントリに対応するＴＣＰコネクションは、ＦＩＮ／ＡＣＫの交換により終了の手続きを行う。あるいは、記憶部２０３に追加されてからの経過時間が規定の閾値を超えたエントリを削除するという方法をとっても良い。この場合、終了部１０４および終了部２０４において、定期的なタイミングで現在時刻と、記憶部１０３および記憶部２０３に記憶された待機時刻との差を調べ、既定値を上回っていた場合には上記と同様にエントリの削除とＴＣＰコネクションの終了を行う。このように古くなったＴＣＰコネクションを自動で終了させることにより、サーバ装置１およびクライアント装置２のリソース消費量を削減することが可能となる。また、ＩＰアドレスが同一のエントリが記憶部１０３および記憶部２０３に複数個存在する場合にそれらから優先的に削除する処理を追加してもよい。これによりサービス提供の公平性を実現することが可能となる。

（第２の実施形態）
第２の実施形態の基本的な構成は、第１の実施形態と同様であり、ＨＴＴＰサーバとして機能する情報処理端末（サーバ装置１）と、ＨＴＴＰクライアントとして機能する情報処理端末（クライアント装置２）とが、ネットワーク３を介して接続されている。

サーバ装置１のＨＴＴＰサーバアプリケーション１０１はウェブページの提供を行う。クライアント装置２のＨＴＴＰクライアントアプリケーション２０１は例えばブラウザ等のアプリケーションである。第２の実施形態の構成を図１３に示す。

ＨＴＴＰサーバアプリケーション１０１が提供するウェブページはＨＴＭＬで記述されている。このＨＴＭＬファイルにはｉｍｇタグで画像ファイルの読み込みが指定されている。ＨＴＴＰクライアントアプリケーション２０１はＨＴＴＰリクエストを用いてＨＴＭＬファイルのダウンロードを行い、次に２回目のＨＴＴＰリクエストにより、ＨＴＭＬファイルに記載されている画像ファイルの取得を行い、得られた両方の情報を表示する。表示される情報の例を図１４に示す。表示される情報はテキスト１００１と画像１００２とリンク１００３から構成される。クライアント装置２において、ユーザがリンク１００３の文字列のクリックを行うことにより、別のファイルの表示を指示することができる。この場合、ユーザのクリック操作に伴い、新規のＨＴＴＰリクエストが作成され、上記と同様にしてＨＴＭＬファイルのダウンロードが実行される。

ネットワークの帯域幅が十分でない場合、画像１００２のようにサイズの大きなデータのダウンロードに時間を要する場合がある。その場合のクライアント装置２のＨＴＴＰクライアントアプリケーション２０１の表示には様々な方法がある。全てのデータのダウンロードが完了してから表示を行う方法のほか、画像１００２がダウンロードされるに従って上から段階的に表示を行っていく方法がある。このほか、当初はぼんやりした画像が表れ、ダウンロードが進むと次第に画像が鮮明になってくるという方法がある。

いずれの場合も、画像１００２のダウンロードを実行している最中に、ユーザによりリンク１００３のクリックが行われる状況が想定される。クライアント装置２のＨＴＴＰクライアントアプリケーション２０１は、ユーザにすみやかに遷移先のページを提示するために、クリックが行われた時点ですみやかに新たなＨＴＴＰリクエストを作成してサーバ装置１に送出する必要がある。このとき、ダウンロードの最中である画像１００２のダウンロードはもはや不要である。古いデータのダウンロードに伴う帯域幅の消費が新しいデータのダウンロードに影響を及ぼさないよう、古いデータのダウンロードを中断する必要がある。

以下の説明では、図１４に示したような、画像を含むウェブページの取得を行っている最中にリンクのクリックが行われ、（同一サーバが提供する）別のウェブページに遷移するという状況でのサーバ装置１およびクライアント装置２の処理の流れを述べる。

（ＨＴＭＬファイルと画像ファイルの取得）
クライアント装置２のＨＴＴＰクライアントアプリケーション２０１（ブラウザアプリケーション）では、ユーザのＵＲＬ入力などの操作を契機として、サーバ装置１のＨＴＴＰサーバアプリケーション１０１に向けてＨＴＭＬファイルの取得を行う。ここではサイト名ｅｘａｍｐｌｅ．ｃｏｍからＨＴＭＬファイルｇａｌｌｅｒｙ．ｈｔｍｌを取得すると仮定する。始めにＨＴＴＰクライアントアプリケーション２０１は開始部２０２に対し、ＨＴＴＰリクエストの送出のために必要なＴＣＰコネクションの取得要求を行う。開始部２０２はさらに内部に直近にファイル取得を行ったサイト名と、ファイル取得に用いたＴＣＰコネクションの識別子とを記憶するための記憶領域（記憶部２０３）を有する。初回は直近のファイル取得は存在しないため、いずれもｎｕｌｌで初期化されている。

開始部２０２は、記憶領域に記憶されたサイトと、これから取得を行うサイトが一致するか否かを判定する。ここでの判定結果はＮＯである（ｎｕｌｌ≠ｅｘａｍｐｌｅ．ｃｏｍ）。このとき、開始部２０２は、通信部２０５に対し、当該サイトとの間でのＴＣＰコネクション作成を依頼する。通信部２０５はサーバ装置１の通信部１０５との間でＴＣＰの３ウェイハンドシェイクを行ってＴＣＰコネクションを作成し、その識別子を開始部２０２に返す。この識別子はＨＴＴＰクライアントアプリケーション２０１に渡される。ＨＴＴＰクライアントアプリケーション２０１はこのＴＣＰコネクションを利用して、ＨＴＭＬファイルｇａｌｌｅｒｙ０１．ｈｔｍｌを要求するＨＴＴＰリクエストを作成し通信部２０５へ送信依頼する。このＨＴＴＰリクエストは開始部１０２を介してＨＴＴＰサーバアプリケーション１０１へと送信される。これを受けてＨＴＴＰサーバアプリケーション１０１は、自身が保持するＨＴＭＬファイルをＨＴＴＰレスポンスとしてＨＴＴＰクライアントアプリケーション２０１へ送信する。

次にＨＴＴＰクライアントアプリケーション２０１は、受け取ったＨＴＭＬファイルを解析し、当該ページに画像１００２（ｉｍａｇｅ．ｊｐｇ）およびリンク１００３（ｇａｌｌｅｒｙ０１．ｈｔｍｌ）が含まれていることを知る。そこで画像１００２を要求するＨＴＴＰリクエストを作成し、通信部２０５を介してＨＴＴＰサーバアプリケーション１０１へ送信する。同時に、ページのレンダリングを行い表示する。ユーザには、画像１００２が空白の状態のページが提示される。ＨＴＴＰサーバアプリケーション１０１は画像１００２へのＨＴＴＰリクエストに対し、ＨＴＴＰレスポンスとして画像ファイルｉｍａｇｅ．ｊｐｇを送信する。なお、画像１００２の取得の際にはＨＴＴＰパーシステントコネクションが利用可能であり、ｇａｌｌｅｒｙ０１．ｈｔｍｌとｉｍａｇｅ．ｊｐｇの取得の間にはＴＣＰコネクションの終了は行われていない。

（画像ファイルの取得の中断）
さて、画像１００２の受信の最中に、ユーザの操作によって、ページに含まれるリンク１００３のクリックがなされ、別のページｇａｌｌｅｒｙ０２．ｈｔｍｌへの遷移が発生したとする。このとき、ＨＴＴＰクライアントアプリケーション２０１は、受信中の画像１００２の中断を行うと判断する。終了部２０４に対し、中断の指示を出す。終了部２０４は、通信部２０５を通じて、サーバ装置１の終了部１０４に対し、中断の指示を通知する。第１の実施形態で述べた通り、通知の方法は、通知用のポート番号を利用したＴＣＰコネクションを作成する方法のほか、ＵＤＰを利用する方法など、任意であってよい。ＨＴＴＰサーバアプリケーション１０１は、中断の指示を受けると、送信中の画像１００２の送信を中断する。

ＨＴＴＰクライアントアプリケーション２０１は、中断の指示を出した後で、自身が記憶する、直近にファイル取得を行ったサイト名と、ファイル取得に用いたＴＣＰコネクションの識別子の情報を更新する。直近にファイル取得を行ったサイト名の情報はｅｘａｍｐｌｅ．ｃｏｍで更新され、ＴＣＰコネクションの識別子の情報は、画像１００２の取得に用いたＴＣＰコネクションの識別子で更新される。

次にＨＴＴＰクライアントアプリケーション２０１は、遷移先のページ（ｇａｌｌｅｒｙ０２．ｈｔｍｌ）の取得を行う。１回目の取得と同じように、ＨＴＴＰクライアントアプリケーション２０１は開始部２０２に対し、ＨＴＴＰリクエストの送出のために必要なＴＣＰコネクションの取得要求を行う。開始部２０２は、記憶領域に記憶されたサイトと、これから取得を行うサイトが一致するか否かを判定する。ここでの判定結果はＹＥＳである（いずれもｅｘａｍｐｌｅ．ｃｏｍ）。このとき開始部２０２は記憶部２０３に記憶されたＴＣＰコネクションの識別子をＨＴＴＰクライアントアプリケーション２０１に渡す。ＨＴＴＰクライアントアプリケーション２０１はこのＴＣＰコネクションを利用して、ＨＴＭＬファイルｇａｌｌｅｒｙ０２．ｈｔｍｌを要求するＨＴＴＰリクエストを作成し通信部２０５へ送信依頼する。このＨＴＴＰリクエストは開始部１０２を介してＨＴＴＰサーバアプリケーション１０１へと送信される。これを受けてＨＴＴＰサーバアプリケーション１０１は、自身が保持するＨＴＭＬファイルをＨＴＴＰレスポンスとしてＨＴＴＰクライアントアプリケーション２０１へ送信する。

以上のように本実施の形態により、第１の実施形態と同様の効果を得ることが可能となる。

なお、第１の実施形態および第２の実施形態では、伝送するデータの種類を映像データおよび画像データであるとしたが、必ずしもそれらに限る必要はなく、任意の種類のデータを使用することが可能である。また、サーバ装置１とクライアント装置２はアプリケーションとしてＨＴＴＰを使用するとしたが、必ずしもこれに限る必要はなく、任意のアプリケーションを使用することが可能である。特に、ＨＴＴＰのように、ＴＣＰコネクションを終了することなく実行中のデータ送信を途中でキャンセルするという機能が存在しないようなアプリケーションにおいて、キャンセルの機能を実現することが可能となる。

また、第１の実施形態および第２の実施形態では、いずれもデータ通信の開始と終了をクライアントの側から行うものとしたが、必ずしもそれに限る必要はない。一般に、ＴＣＰによるデータ通信において、いったんＴＣＰコネクションの確立が完了した後はサーバとクライアントの間の区別はなされない。このため、サーバの側からデータ通信の開始と終了を行う場合についても適用可能である。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…サーバ装置
２…クライアント装置
３…ネットワーク
１０１…サーバアプリケーション
１０２，２０２…開始部
１０３…記憶部
１０４，２０４…終了部
１０５…通信部
２０１…クライアントアプリケーション
２０２…開始部
２０３…記憶部
２０４…終了部
２０５…通信部
１００１…テキスト
１００２…画像
１００３…リンク

Claims (16)

1. コネクション型のデータ通信を行う通信装置であって、
   コネクションを利用してデータを供給または要求するアプリケーションと、
   前記データ通信の終了要求を受け取り、前記コネクションを終了することなく前記アプリケーションに対して前記コネクションの終了を通知する終了部と、
   前記データ通信の相手の識別子と前記コネクションの識別子とを関連付けて記憶する記憶部と、
   前記データ通信の開始要求を受け取り、前記開始要求に応じて再利用可能なコネクションが前記記憶部に存在するか否かを判定し、再利用可能と判定されたコネクションの識別子を前記アプリケーションに通知する開始部と、を具備し、
   前記開始部は、前記コネクションの再利用への待機を前記データ通信の相手に報せる通知信号を送出する通信装置。
2. コネクション型のデータ通信を行う通信装置であって、
   コネクションを利用してデータを供給または要求するアプリケーションと、
   前記データ通信の終了要求を受け取り、前記コネクションを終了することなく前記アプリケーションに対して前記コネクションの終了を通知する終了部と、
   前記データ通信の相手の識別子と前記コネクションの識別子とを関連付けて記憶する記憶部と、
   前記データ通信の開始要求を受け取り、前記開始要求に応じて再利用可能なコネクションが前記記憶部に存在するか否かを判定し、再利用可能と判定されたコネクションの識別子を前記アプリケーションに通知する開始部と、を具備し、
   前記記憶部は、前記コネクションの識別子を記憶した時刻をさらに記憶し、
   前記終了要求に対して終了しなかった複数のコネクションのうち、前記記憶した時刻から規定時間が経過したコネクションを終了する通信部をさらに具備する通信装置。
3. 前記開始部は、前記コネクションの再利用を前記データ通信の相手に報せる通知信号を送出する請求項２記載の装置。
4. 前記開始部は、前記コネクションの再利用への待機を前記データ通信の相手に報せる通知信号を送出する請求項２記載の装置。
5. 前記開始部は、前記開始要求とともに指定された前記データ通信の相手の識別子を前記記憶部から探し、該識別子が存在していれば前記コネクションの識別子を前記アプリケーションに返し、該識別子が存在しなければ新規に確立したコネクションの識別子を前記アプリケーションに返す請求項２記載の装置。
6. 前記データ通信の相手の識別子は、少なくともＩＰアドレスを含む請求項２記載の装置。
7. 前記データ通信の相手の識別子は、少なくともアプリケーションのポート番号を含む請求項２記載の装置。
8. 前記終了要求に対して終了しなかった複数のコネクションのうち、規定個数を上回ったコネクションを終了する通信部をさらに具備する請求項１乃至７のいずれかに記載の装置。
9. 前記通信部は、同一のデータ通信の相手とのコネクションの個数が多いコネクションを優先的に終了する請求項２または８に記載の装置。
10. 前記アプリケーションは、ＨＴＴＰによるデータ通信を行う請求項１乃至９のいずれかに記載の装置。
11. 前記終了部は、前記アプリケーションが使用する、データ通信のためのアプリケーション・プログラミング・インターフェース（ＡＰＩ）と互換性のあるＡＰＩを提供する請求項１乃至１０のいずれかに記載の装置。
12. 前記開始部は、前記アプリケーションが使用する、データ通信のためのアプリケーション・プログラミング・インターフェース（ＡＰＩ）と互換性のあるＡＰＩを提供する請求項１乃至１０のいずれかに記載の装置。
13. コネクション型のデータ通信を行う通信方法であって、
    アプリケーションが、コネクションを利用してデータを供給または要求し、
    終了部が、前記データ通信の終了要求を受け取り、前記コネクションを終了することなく前記アプリケーションに対して前記コネクションの終了を通知し、
    記憶部が、前記データ通信の相手の識別子と前記コネクションの識別子とを関連付けて記憶し、
    開始部が、前記データ通信の開始要求を受け取り、前記開始要求に応じて再利用可能なコネクションが前記記憶部に存在するか否かを判定し、再利用可能と判定されたコネクションの識別子を前記アプリケーションに通知すること、を具備し、
    前記開始部は、前記コネクションの再利用への待機を前記データ通信の相手に報せる通知信号を送出する、通信方法。
14. コネクション型のデータ通信を行う通信方法であって、
    アプリケーションが、コネクションを利用してデータを供給または要求し、
    終了部が、前記データ通信の終了要求を受け取り、前記コネクションを終了することなく前記アプリケーションに対して前記コネクションの終了を通知し、
    記憶部が、前記データ通信の相手の識別子と前記コネクションの識別子とを関連付けて記憶し、
    開始部が、前記データ通信の開始要求を受け取り、前記開始要求に応じて再利用可能なコネクションが前記記憶部に存在するか否かを判定し、再利用可能と判定されたコネクションの識別子を前記アプリケーションに通知すること、を具備し、
    前記記憶部は、前記コネクションの識別子を記憶した時刻をさらに記憶し、
    前記終了要求に対して終了しなかった複数のコネクションのうち、前記記憶した時刻から規定時間が経過したコネクションを終了することをさらに具備する通信方法。
15. コンピュータに、コネクション型のデータ通信を行わせるためのプログラムであって、
    アプリケーションが、コネクションを利用してデータを供給または要求する手順と、
    終了部が、前記データ通信の終了要求を受け取り、前記コネクションを終了することなく前記アプリケーションに対して前記コネクションの終了を通知する手順と、
    記憶部が、前記データ通信の相手の識別子と前記コネクションの識別子とを関連付けて記憶する手順と、
    開始部が、前記データ通信の開始要求を受け取り、前記開始要求に応じて再利用可能なコネクションが前記記憶部に存在するか否かを判定し、再利用可能と判定されたコネクションの識別子を前記アプリケーションに通知する手順と、を実行するためのプログラムであり、
    前記開始部は、前記コネクションの再利用への待機を前記データ通信の相手に報せる通知信号を送出するプログラム。
16. コンピュータに、コネクション型のデータ通信を行わせるためのプログラムであって、
    アプリケーションが、コネクションを利用してデータを供給または要求する手順と、
    終了部が、前記データ通信の終了要求を受け取り、前記コネクションを終了することなく前記アプリケーションに対して前記コネクションの終了を通知する手順と、
    記憶部が、前記データ通信の相手の識別子と前記コネクションの識別子とを関連付けて記憶する手順と、
    開始部が、前記データ通信の開始要求を受け取り、前記開始要求に応じて再利用可能なコネクションが前記記憶部に存在するか否かを判定し、再利用可能と判定されたコネクションの識別子を前記アプリケーションに通知する手順と、を実行するためのプログラムであり、
    前記記憶部は、前記コネクションの識別子を記憶した時刻をさらに記憶し、
    前記終了要求に対して終了しなかった複数のコネクションのうち、前記記憶した時刻から規定時間が経過したコネクションを終了する手順をさらに実行するためのプログラム。

Images