(57)【特許請求の範囲】
【請求項１】
通信装置であって、
前記通信装置と他の通信装置との間の論理的な第１接続に基づいて複数確立可能な論理的な第２接続を使用して、前記他の通信装置と通信を行う通信手段と、
前記通信手段により使用される第２接続におけるエラーを検知する検知手段と、
前記検知手段により第２接続におけるエラーが検知された場合に、前記通信装置と前記他の通信装置との通信状況に基づいて前記第１接続の終了処理を実行する終了手段とを有することを特徴とする通信装置。
【請求項２】
前記通信装置と前記他の通信装置との通信状況は、前記検知手段により検知されたエラーの回数、前記第１接続に基づく第２接続の数、及び前記通信手段が第２接続を使用して通信しているデータの内容のうち少なくとも何れかを含むことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記終了手段により前記第１接続の終了処理が実行された後に前記通信装置が前記他の通信装置から新たな第１接続を要求された場合に、当該要求を拒絶する拒絶手段を有することを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記終了手段は、前記第１接続に基づく第２接続の数に関するエラーが前記検知手段により所定の回数以上検知された場合に、前記第１接続の終了処理を実行することを特徴とする請求項１乃至３のうち何れか１項に記載の通信装置。
【請求項５】
前記終了手段は、前記第１接続に基づく第２接続におけるエラーが前記検知手段により所定期間内に所定の回数以上検知された場合に、前記第１接続の終了処理を実行することを特徴とする請求項１乃至３のうち何れか１項に記載の通信装置。
【請求項６】
前記第１接続に基づく第２接続の数に関するエラーは、前記通信装置が第１所定数を超える数の第２接続の確立を前記他の通信装置から要求されたことによって発生することを特徴とする請求項４に記載の通信装置。
【請求項７】
前記第１接続に基づく第２接続の数に関するエラーは、前記通信装置が第２所定数を超える数の第２接続の予約を前記他の通信装置から要求されたことによって発生することを特徴とする請求項４に記載の通信装置。
【請求項８】
前記終了手段は、前記検知手段により第２接続におけるエラーが検知された場合に、前記第１接続に基づいて確立されている第２接続の数が所定数未満であれば、前記検知手段により検知されたエラーの回数及び前記通信手段が第２接続を使用して通信しているデータの内容のうち少なくとも何れかに基づいて前記第１接続の終了処理を実行し、前記第１接続に基づいて確立されている第２接続の数が所定数以上であれば、前記第１接続の終了処理を実行しないことを特徴とする請求項１乃至３のうち何れか１項に記載の通信装置。
【請求項９】
前記終了手段は、前記検知手段により第２接続におけるエラーが検知された場合に、当該エラーに対応する第２接続が前記通信手段により所定の表示サイズ以上の動画又は静止画の通信に使用される第２接続であれば、前記検知手段により検知されたエラーの回数及び前記第１接続に基づく第２接続の数のうち少なくとも何れかに基づいて前記第１接続の終了処理を実行し、前記エラーに対応する第２接続が前記通信手段により前記所定の表示サイズ未満の動画又は静止画の通信に使用される第２接続であれば、前記第１接続の終了処理を実行しないことを特徴とする請求項１乃至３のうち何れか１項に記載の通信装置。
【請求項１０】
前記拒絶手段は、前記新たな第１接続を要求した他の通信装置に対してエラーを通知するか、又は前記要求に対する応答を行わないことで、前記要求を拒絶することを特徴とする請求項３に記載の通信装置。
【請求項１１】
前記第１接続及び前記第２接続は、それぞれＨＴＴＰ／２において規定されるコネクション及びストリームであることを特徴とする請求項１乃至１０のうち何れか１項に記載の通信装置。
【請求項１２】
前記終了手段は、ＨＴＴＰ／２において規定されるＧＯＡＷＡＹフレームの前記他の通信装置への送信及び前記第１接続の切断のうち少なくとも何れかを行うことで、前記第１接続の終了処理を実行することを特徴とする請求項１乃至１１のうち何れか１項に記載の通信装置。
【請求項１３】
複数の通信装置の間の論理的な第１接続に基づいて複数確立可能な論理的な第２接続を使用して通信を行う通信工程と、
前記通信工程において使用される第２接続におけるエラーを検知する検知工程と、
前記検知工程においてエラーが検知された場合に、前記複数の通信装置の通信状況に基づいて前記第１接続の終了処理を実行する終了工程とを有することを特徴とする通信方法。
【請求項１４】
前記複数の通信装置の通信状況は、前記検知工程において検知されたエラーの回数、前記第１接続に基づく第２接続の数、及び前記通信工程において第２接続を使用して通信されているデータの内容のうち少なくとも何れかを含むことを特徴とする請求項１３に記載の通信方法。
【請求項１５】
前記終了工程において前記第１接続の終了処理が実行された後に前記複数の通信装置の間の新たな第１接続が要求された場合に、当該要求を拒絶する拒絶工程を有することを特徴とする請求項１３又は１４に記載の通信方法。
【請求項１６】
前記終了工程は、前記第１接続に基づく第２接続の数に関するエラーが前記検知工程において所定期間内に所定の回数以上検知された場合に、前記第１接続の終了処理を実行することを特徴とする請求項１３乃至１５のうち何れか１項に記載の通信方法。
【請求項１７】
コンピュータを、請求項１乃至１２のうち何れか１項に記載の通信装置として動作させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、論理的な接続を使用して通信を行うための通信方法に関する。
【背景技術】
【０００２】
インターネット標準技術として広く利用されているプロトコル（通信規約）の一つに、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）がある。ＨＴＴＰの新しいバージョンとして、インターネット標準化団体（ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）においてＨＴＴＰ／２の標準策定が行われた。ＨＴＴＰ／２方式の通信においては、ストリームと呼ばれる論理的な接続が使用される。ＨＴＴＰ／２方式の通信を行う通信装置は、通信装置間のコネクション（論理的な第１接続）に基づいてストリーム（論理的な第２接続）を複数確立可能であり、それぞれのストリームにおいて独立したシーケンスで通信を行う。
【０００３】
特許文献１には、コネクションにおいて発生したエラーの発生履歴に応じて、通信装置がコネクションの確立から切断までに送信するデータ量を決定することで、コネクションの途中切断に起因するデータ転送の効率低下を防止することが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第５４５２６０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来技術では、論理的な第１接続に基づいて確立された論理的な第２接続におけるエラーの発生状況によっては、通信装置のエラー処理に係る処理負荷が大きくなってしまうという課題がある。例えばＨＴＴＰ／２での通信において、同一のコネクションに基づく複数のストリームでエラーが発生する場合、通信装置がコネクションを維持したままそれぞれのストリームにおいてエラー通知などの処理を行うと、通信装置の処理負荷が大きくなる。
【０００６】
本発明は上記課題に鑑み、論理的な第１接続に基づいて確立される論理的な第２接続におけるエラー処理に係る、通信装置の処理負荷の増大を抑制するための技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決するため、本発明に係る通信装置は、例えば以下の構成を有する。すなわち、前記通信装置と他の通信装置との間の論理的な第１接続に基づいて複数確立可能な論理的な第２接続を使用して、前記他の通信装置と通信を行う通信手段と、前記通信手段により使用される第２接続におけるエラーを検知する検知手段と、前記検知手段により第２接続におけるエラーが検知された場合、前記通信装置と前記他の通信装置との通信状況に基づいて前記第１接続の終了処理を実行する終了手段とを有する。
【発明の効果】
【０００８】
本発明によれば、論理的な第２接続において検知されたエラーの発生状況に基づいて論理的な第１接続の終了処理を実行することで、前記第１接続に基づいて確立される第２接続におけるエラー処理に係る、通信装置の処理負荷の増大を抑制することができる。
【図面の簡単な説明】
【０００９】
【図１】実施形態に係る通信システムの構成例を示す図である。
【図２】実施形態に係る第２の通信装置２０のハードウェア構成例を示す図である。
【図３】実施形態に係る第２の通信装置２０の機能モジュール構成例を示すブロック図である。
【図４】第１実施形態に係る、第１の通信装置１０と第２の通信装置２０とのＨＴＴＰ通信の開始から終了までの動作を説明するためのシーケンス図である。
【図５】実施形態に係る、第１の通信装置１０と第２の通信装置２０とのＨＴＴＰ通信接続に関する動作を説明するためのシーケンス図である。
【図６】実施形態に係る、第２の通信装置２０によるコネクションエラー判断に関する動作を説明するためのフローチャートである。
【図７】実施形態に係る、第２の通信装置２０によるストリームエラーの要因の判断に関する動作を説明するためのフローチャートである。
【図８】実施形態に係る、第２の通信装置２０によるコネクション上の実行中ストリームの存在判断に関する動作を説明するためのフローチャートである。
【図９】第２実施形態に係る、第１の通信装置１０と第２の通信装置２０とのＨＴＴＰ通信の開始から終了までの動作を説明するためのシーケンス図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施形態は特許請求の範囲に係る本発明を限定するものではなく、また、以下の実施形態で説明する特徴の組み合わせの全てが本発明に必須のものとは限らない。
【００１１】
＜第１実施形態＞
［システム構成］
図１は、通信システムの構成例を示す図である。通信システムは第１の通信装置１０（以下、通信装置１０）と第２の通信装置２０（以下、通信装置２０）とを備え、これらがＩＥＥＥ８０２．１１に則った無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）により接続されている。
【００１２】
通信装置１０はクライアントとしての通信装置であり、通信装置２０はサーバとしての通信装置である。通信装置１０及び通信装置２０の具体例としては、デジタルカメラ、デジタルビデオカメラ、ネットワークカメラ、プリンタ、デジタル複合機、デジタルテレビ、プロジェクタ、携帯電話、スマートフォン、ＰＣ、及びサーバ装置などがある。例えば、通信装置１０がＰＣであり通信装置２０がネットワークカメラである場合、ユーザはＰＣを操作してネットワークカメラに撮像画像の送信を要求する。要求を受けたネットワークカメラは撮像した画像をＰＣに送信し、ＰＣは受信した画像をディスプレイに表示する。
【００１３】
なお、本実施形態では通信装置１０と通信装置２０とが直接無線ＬＡＮ接続を行う例を示すが、これに限らず、無線アクセスポイントを経由して接続しても良い。また、無線ＬＡＮ通信機能に限らず、例えばＢｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、及びＲＦＩＤなどの他の無線通信機能を利用しても良い。また、例えばＥｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮ通信機能、または無線ＬＡＮ通信機能と有線ＬＡＮ通信機能の組合せを利用しても良い。有線ＬＡＮ接続の場合は、例えばネットワークスイッチやルータなどの中継装置を経由して接続してもよい。さらに、本実施形態では通信装置１０と通信装置２０は同一ＬＡＮ上で接続しているが、これに限らず、例えばＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネット、及び電話用の公衆回線などを経由して接続してもよい。
【００１４】
次に、通信装置の構成要素を詳細に説明する。図２は、通信装置２０（サーバ）のハードウェア構成例を示すブロック図である。なお、通信装置１０（クライアント）も通信装置２０と同じ構成である。通信装置２０は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、補助記憶装置２０４、表示部２０５、操作部２０６、無線通信部２０７、及びアンテナ２０８を備える。
【００１５】
ＣＰＵ２０１は、第２の通信装置２０の全体を制御する。ＲＯＭ２０２は、変更を必要としないプログラムやパラメータを格納する。ＲＡＭ２０３は、補助記憶装置２０４などから供給されるプログラムやデータを一時記憶する。補助記憶装置２０４は、静止画や動画などのコンテンツデータを記憶する。表示部２０５は、ユーザが通信装置２０を操作するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を表示する。操作部２０６は、ユーザが通信装置２０を操作するための入力インタフェースである。無線通信部２０７は、アンテナ２０８を制御し、通信装置１０との無線ＬＡＮ通信を行う。通信装置１０と通信装置２０とが外部の無線アクセスポイントを経由して接続する場合は、無線通信部２０７はアンテナ２０８を制御して無線アクセスポイント（不図示）との無線ＬＡＮ通信を行う。なお、本実施形態では表示部２０５と操作部２０６は通信装置２０の内部に存在するが、表示部２０５及び操作部２０６の少なくとも一方が通信装置２０の外部に別の装置として存在していてもよい。
【００１６】
［機能モジュール構成］
図３は、通信装置２０（サーバ）の機能モジュール構成例を示すブロック図である。なお、通信装置１０（クライアント）も通信装置２０と同じ構成である。通信装置２０は、制御部３０１、無線ＬＡＮ通信制御部３０２（以下、無線制御部３０２）、表示制御部３０３、操作制御部３０４、及び記憶制御部３０５を備える。通信装置２０はまた、ＴＣＰ／ＩＰ通信制御部３０６（以下、ＴＣＰ制御部３０６）及びＨＴＴＰ通信制御部３０７（以下、ＨＴＴＰ制御部３０７）を備える。通信装置２０はさらに、コネクションエラー判断部３０８（以下、コネクション判断部３０８）、ストリームエラー判断部３０９（以下、ストリーム判断部３０９）、及び通信状況判断部３１０（以下、通信判断部３１０）を備える。各モジュールは、ＣＰＵ２０１がＲＯＭ２０２に格納されたプログラムをＲＡＭ２０３に展開して後述する各フローチャートに従った処理を実行することで実現されている。また例えば、ＣＰＵ２０１を用いたソフトウェア処理の代替としてハードウェアによる処理を行う場合には、ここで説明する各モジュールの処理に対応させた演算部や回路を構成すればよい。なお、通信装置２０が上記のモジュール全てを備えることは必須でない。
【００１７】
制御部３０１は、通信装置２０が備える個々の機能モジュールを制御する。無線制御部３０２は無線通信部２０７を制御し、通信装置１０との無線ＬＡＮ通信の制御を行う。通信装置１０と通信装置２０とが外部の無線アクセスポイントを経由して接続する場合は、無線制御部３０２は無線通信部２０７を制御して無線アクセスポイント（不図示）との無線ＬＡＮ通信の制御を行う。表示制御部３０３は表示部２０５を制御し、通信装置２０におけるＧＵＩの表示制御を行う。操作制御部３０４は操作部２０６を制御し、通信装置２０に対するユーザからの操作入力の制御を行う。記憶制御部３０５はＲＡＭ２０３および補助記憶装置２０４を制御し、処理データや静止画、動画などのコンテンツデータを記憶または削除する。
【００１８】
ＴＣＰ制御部３０６は、無線制御部３０２を利用して、通信装置１０との間でＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）方式の通信制御を行う。なお、本実施形態ではＴＣＰ／ＩＰ通信を利用する例を示すが、これに限らず、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）など他のプロトコルに基づく通信をしても良い。ＨＴＴＰ制御部３０７は、ＴＣＰ制御部３０６を利用して、通信装置１０との間でＨＴＴＰ／２方式の通信制御を行う。また、ＨＴＴＰ制御部３０７は、通信装置１０との間でＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）を利用したＨＴＴＰＳ（ＨＴＴＰ  Ｓｅｃｕｒｉｔｙ）方式の通信制御も行う。ただし、ＨＴＴＰ制御部３０７はこれら以外の方式（例えばＳＰＤＹ等）に基づく通信制御を行ってもよい。
【００１９】
ＨＴＴＰ／２方式の通信においては、ストリームと呼ばれる論理的な接続が使用される。ＨＴＴＰ／２方式の通信を行う通信装置は、通信装置間のトランスポート層におけるコネクション（論理的な第１接続）に基づいてストリーム（論理的な第２接続）を複数確立可能であり、それぞれのストリームにおいて独立したシーケンスで通信を行う。また、通信装置はコネクションを複数確立し、コネクションごとに複数のストリームを確立することもできる。
【００２０】
コネクション判断部３０８は、ストリーム判断部３０９および通信判断部３１０を利用して、ストリーム（第２接続）におけるエラーが発生した場合にコネクションエラーが発生したものとして処理するか否かを判断する。コネクションエラーとは、コネクションの接続状態に関するエラーであり、そのコネクションに基づくストリームを使用した通信全てがその影響を受ける。一方ストリームエラーは、他のストリームの処理には影響しない、特定のストリームに関連するエラーである。コネクションエラーが発生すると、ＨＴＴＰ制御部３０７が、ＨＴＴＰ／２において規定されるＧＯＡＷＡＹフレームを通信装置１０に送信した後にコネクションを切断することで、コネクション（第１接続）の終了処理を実行する。ＨＴＴＰ／２において規定されるＧＯＡＷＡＹフレームは、通信装置がＧＯＡＷＡＹフレームの送信に使用したコネクションに基づく新たなストリームを確立しないことを示す情報である。
【００２１】
コネクションエラーの判断は、ストリームエラーが発生するときの通信装置２０と通信装置１０との通信状況等に基づいて行われる。コネクションエラーの判断基準として、通信装置２０と通信装置１０との通信状況は例えば以下のものを含む。すなわち、ストリーム判断部３０９により検知されたエラーの回数、対象のコネクション（第１接続）に基づくストリーム（第２接続）の数、及びＨＴＴＰ制御部３０７がストリームを使用して通信しているデータの内容のうち少なくとも何れかが判断基準となる。また、それら全てが判断基準となってもよいし、他の情報が判断基準となってもよい。本実施形態において、検知されたエラーの回数とは、例えば同一のコネクションにおいて検知されたストリームエラーの回数や、同一のストリームにおいて検知されたエラーの回数、所定期間内に検知されたストリームエラーの回数などである。また、対象のコネクションに基づくストリームの数とは、コネクションエラーの判断対象であるコネクションに基づいて確立又は予約されているストリームの数などである。データの内容とは、例えばそのデータが構成するコンテンツの種別やデータ量、コンテンツが静止画又は動画である場合の表示サイズなどである。なお、コネクション判断部３０８は、上記の判断基準全てに関する判断を行うことができるものに限らず、上記の判断基準のうち少なくとも何れかに関する判断を行うことができればよい。
【００２２】
ストリーム判断部３０９は、ＨＴＴＰ制御部３０７を利用して、通信装置１０とのＨＴＴＰ通信に使用されるストリーム（第２接続）において発生したエラーを検知する。また、ストリーム判断部３０９は、ストリームエラーの要因に応じてストリームエラーの検知回数のカウントも行う。本実施形態において、ストリーム判断部３０９はストリームエラーの要因毎に検知回数をカウントするが、これに限らず、エラーの要因を分類して分類単位で検知回数をカウントしてもよい。また、ストリーム判断部３０９は、特定の要因のエラーだけをカウントしてもよいし、要因に関わらず全てのストリームエラーの検知回数の合計をカウントしてもよい。そしてストリーム判断部３０９は、コネクション終了後に検知回数のカウントを初期化する。通信判断部３１０は、ＨＴＴＰ制御部３０７を利用して、通信装置１０とのＨＴＴＰ通信の通信状況を判断する。本実施形態において、通信判断部３１０は、通信装置１０とのＨＴＴＰ通信中の複数ストリームの実行状況を確認する。
【００２３】
［通信シーケンス］
以下、本実施形態における通信装置１０と通信装置２０との間における通信シーケンスについて、詳細に説明する。図４は、本実施形態に係る、通信装置１０と通信装置２０とのＨＴＴＰ通信の開始から終了までの動作を説明するためのシーケンス図である。図４の処理は、通信装置２０からコンテンツを取得するためのユーザ操作が通信装置１０に入力されたタイミングで開始される。ただし、図４の処理の開始タイミングは上記タイミングに限定されない。
【００２４】
Ｍ４０１において、通信装置１０が、通信装置２０との間でコネクションを確立してＨＴＴＰ通信接続を行う。この通信接続の詳細なシーケンスについては、図５を用いて後述する。Ｍ４０２において、通信装置１０が通信装置２０に対してＨＴＴＰリクエストヘッダ情報が記述されたＨＥＡＤＥＲＳフレームを送信する。本シーケンスにおいて、当該ＨＴＴＰリクエストはＧＥＴメソッドを使用する。このＨＥＡＤＥＲＳフレームの送信によって、通信装置１０はストリームＩＤを１とする新規ストリームの確立を通信装置２０に要求する。本実施形態では、通信装置１０から通信装置２０へのリクエストとして、上述のようにＧＥＴメソッドを指定したＨＥＡＤＥＲＳフレームを用いる。しかしこれに限らず、例えばＰＯＳＴやＰＵＴなどの他のＨＴＴＰリクエストメソッドや、ＰＵＳＨ＿ＰＲＯＭＩＳＥなどの他のフレームを利用してもよい。
【００２５】
Ｍ４０３において、通信装置２０のＨＴＴＰ制御部３０７がＭ４０２で受信したＨＥＡＤＥＲＳフレームに対する応答をＴＣＰ  ＡＣＫとして送信する。これにより、通信装置１０と通信装置２０との間のコネクションに基づいたストリームＩＤが１のストリームが確立され、以降ＨＴＴＰ制御部３０７がこのストリームを使用した通信を行う。
【００２６】
Ｍ４０４において、Ｍ４０２と同様に、通信装置１０が通信装置２０に対してＨＴＴＰ  ＧＥＴメソッドを指定したＨＥＡＤＥＲＳフレームを送信する。このとき要求される新規ストリームのＩＤは３とする。Ｍ４０５において、通信装置２０のＨＴＴＰ制御部３０７がＭ４０４で受信したＨＥＡＤＥＲＳフレームに対する応答をＴＣＰ  ＡＣＫとして送信する。これにより、ストリームＩＤが３のストリームが確立される。Ｍ４０６において、Ｍ４０２と同様に、通信装置１０が、通信装置２０に対してＨＴＴＰ  ＧＥＴメソッドを指定したＨＥＡＤＥＲＳフレームを送信する。このとき要求される新規ストリームのＩＤは５とする。
【００２７】
Ｍ４０７において、通信装置２０がメモリリソース不足等の要因により新規ストリーム確立の要求を受け入れられず、ストリームエラーが発生する。このとき、通信装置２０のストリーム判断部３０９は、ストリームにおけるエラーを検知して検知回数をインクリメントする（カウント：１）。なお本実施形態において、コネクション判断部３０８は、ストリーム判断部３０９が同じ要因のストリームエラーを３回以上検知し、且つ他の実行中ストリームが存在しない場合に、コネクションエラーが発生したものとして処理する判断を下す。本実施形態における他の実行中ストリームとは、エラーが発生したストリーム以外で通信装置１０と通信装置２０との間に確立されているストリームを指す。ただしこれに限らず、ＰＵＳＨ＿ＰＲＯＭＩＳＥによる予約済みストリームを実行中ストリームに含めてもよく、コネクションエラー判断の基準は上記に限らない。
【００２８】
Ｍ４０８において、通信装置２０のＨＴＴＰ制御部３０７が通信装置１０に対して、ストリームエラー通知を示すＲＳＴ＿ＳＴＲＥＡＭフレームを送信する。また、本実施形態においては、ＲＳＴ＿ＳＴＲＥＡＭフレーム中のエラーコードとしてＲＥＦＵＳＥＤ＿ＳＴＲＥＡＭが指定されるが、これに限らず、他のエラーコードが指定されてもよい。ＨＴＴＰ／２において、ＲＳＴ＿ＳＴＲＥＡＭフレームの送信に使用されたストリームは接続を終了し、通信装置１０及び通信装置２０はそれ以降そのストリームを使用した通信を行うことができなくなる。
【００２９】
Ｍ４０９において、Ｍ４０２と同様に、通信装置１０が通信装置２０に対してＨＴＴＰ  ＧＥＴメソッドを指定したＨＥＡＤＥＲＳフレームを送信する。このとき要求される新規ストリームのＩＤは７とする。Ｍ４１０において、Ｍ４０７と同様の理由でストリームエラーが発生する。このとき、通信装置２０のストリーム判断部３０９は、Ｍ４０７と同様に、ストリームエラーを検知して検知回数をインクリメントする（カウント：２）。Ｍ４１１において、Ｍ４０８と同様に、通信装置２０のＨＴＴＰ制御部３０７が通信装置１０に対してＲＳＴ＿ＳＴＲＥＡＭフレームを送信する。Ｍ４１２において、Ｍ４０２と同様に、通信装置１０が通信装置２０に対してＨＴＴＰ  ＧＥＴメソッドを指定したＨＥＡＤＥＲＳフレームを送信する。このとき要求される新規ストリームのＩＤは９とする。
【００３０】
Ｍ４１３において、Ｍ４０７と同様の理由でストリームエラーが発生する。このとき、通信装置２０のストリーム判断部３０９は、Ｍ４０７と同様に、ストリームエラーを検知して検知回数をインクリメントする（カウント：３）。Ｍ４１４において、同じ要因のストリームエラーの検知回数が３になったが他に実行中のストリームが存在するため、通信装置２０のコネクション判断部３０８がコネクションエラーとして処理しない判断を下す。Ｍ４１４における他に実行中のストリームとは、Ｍ４０３及びＭ４０５で新規に確立したストリーム（ストリームＩＤ：１及び３）である。なお、本実施形態におけるコネクション判断部３０８は、他に実行中のストリームが存在する場合にはコネクションエラーとして処理しないが、これに限らない。例えばコネクション判断部３０８は、ストリームエラーが所定回数以上検知されると、他のストリームが実行中であってもコネクションエラーとして扱ってもよい。Ｍ４１５において、Ｍ４０８と同様に、通信装置２０のＨＴＴＰ制御部３０７が通信装置１０に対してＲＳＴ＿ＳＴＲＥＡＭフレームを送信する。
【００３１】
Ｍ４１６において、通信装置２０のＨＴＴＰ制御部３０７が、Ｍ４０２のリクエスト対するＨＴＴＰレスポンスであるＨＥＡＤＥＲＳフレームおよびＤＡＴＡフレームを送信する。本実施形態では、ＤＡＴＡフレームにはＥＮＤ＿ＳＴＲＥＡＭフラグが設定されており、当該ＤＡＴＡフレームの通信の終了に応じてストリームＩＤ：１のストリームは終了する。Ｍ４１７において、通信装置２０のＨＴＴＰ制御部３０７が、Ｍ４０４のリクエストに対するＨＴＴＰレスポンスであるＨＥＡＤＥＲＳフレームおよびＤＡＴＡフレームを送信する。本実施形態では、ＤＡＴＡフレームにはＥＮＤ＿ＳＴＲＥＡＭフラグが設定されており、当該ＤＡＴＡフレームの通信の終了に応じてストリームＩＤ：３のストリームは終了する。
【００３２】
Ｍ４１８において、Ｍ４０２と同様に、通信装置１０が通信装置２０に対してＨＴＴＰ  ＧＥＴメソッドを指定したＨＥＡＤＥＲＳフレームを送信する。このとき要求される新規ストリームのＩＤは１１とする。Ｍ４１９において、Ｍ４０７と同様の理由でストリームエラーが発生する。このとき、通信装置２０のストリーム判断部３０９は、Ｍ４０７と同様に、ストリームエラーを検知して検知回数をインクリメントする（カウント：４）。
【００３３】
Ｍ４２０において、同じ要因のストリームエラーの検知回数が４になり、さらに他に実行中のストリームが存在しないため、通信装置２０のコネクション判断部３０８がコネクションエラーとして処理する判断を下す。Ｍ４２１において、通信装置２０のＨＴＴＰ制御部３０７が通信装置１０に対してコネクションエラー通知を示すＧＯＡＷＡＹフレームを送信する。Ｍ４２２において、通信装置１０と通信装置２０がＨＴＴＰ通信接続を終了する。具体的には、ＴＣＰコネクションを切断する。Ｍ４２３において、通信装置２０のストリーム判断部３０９がストリームエラーの検知回数を初期化する（カウント：０）。
【００３４】
［ＨＴＴＰ通信接続シーケンス］
図５は、通信装置１０と通信装置２０とのＨＴＴＰ通信接続に関する動作を説明するためのシーケンス図であり、図４のＭ４０１の詳細を示すものである。
【００３５】
Ｍ５０１において、通信装置１０が通信装置２０との間でＴＣＰコネクションを確立する。ＨＴＴＰＳ通信を行う場合、Ｍ５０２において、通信装置１０が通信装置２０とＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）通信接続を行う。ＴＬＳ通信接続の際に、ＡＬＰＮ（Ａｐｐｌｉｃａｔｉｏｎ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ  Ｎｅｇｏｔｉａｔｉｏｎ）によりＨＴＴＰ／２通信のネゴシエーションも行われる。一方、ＨＴＴＰＳ通信を行わない場合、Ｍ５０３において、通信装置１０が通信装置２０に対してＨＴＴＰ／２アップグレード要求を送信する。これを受けて、Ｍ５０４において、通信装置２０のＨＴＴＰ制御部３０７が通信装置１０に対してＨＴＴＰ／２アップグレード応答を送信する。Ｍ５０２またはＭ５０４以降、通信装置１０と通信装置２０の間でＨＴＴＰ／２通信が行われる。
【００３６】
Ｍ５０５において、通信装置１０が通信装置２０に対してクライアントコネクションプリフェイスを送信する。このコネクションプリフェイスはＳＥＴＴＩＮＧＳフレームを含み、ＰＲＩメソッドを使用する。Ｍ５０６において、通信装置２０のＨＴＴＰ制御部３０７が通信装置１０に対してサーバコネクションプリフェイスを送信する。これは空の可能性があるＳＥＴＴＩＮＧＳフレームだけで構成される。
【００３７】
［コネクションエラーの判断フロー］
図６は、通信装置２０によるコネクションエラー判断に関する動作を説明するためのフローチャートである。図６の処理は、通信装置２０が、通信装置１０からＨＥＡＤＥＲＳフレームを受信するか又は通信装置１０にＨＥＡＤＥＲＳフレームを送信したタイミングで開始され、ＩＤの異なる各ストリームに対して実行される。ただし、図６の処理の開始タイミングは上記タイミングに限定されない。
【００３８】
Ｓ６０１において、ストリーム判断部３０９が、通信装置１０とのＨＴＴＰ通信中に発生したストリームエラーを検知する。ストリームエラーが検知された場合（Ｓ６０１；Ｙｅｓ）はＳ６０２に進むが、ストリームエラーが検知されなかった場合（Ｓ６０１；Ｎｏ）は処理を終了する。本実施形態において、ストリームエラーが発生するのは次の場合である。まず、ＨＴＴＰ／２の仕様に準拠しない通信が行われた場合がある。例えば、通信装置２０が所定の数（第１所定数）を超えるストリーム確立の要求（ＨＥＡＤＥＲＳフレーム）を受信した場合に発生するストリームエラーがある。第１所定数は、例えば、通信装置２０がＳＥＴＴＩＮＧＳフレームの送信によって通信装置１０に通知した確立可能なストリームの数などである。次に、通信装置１０から送信された制御フレームまたはデータフレームの内容が、ＨＴＴＰ／２の仕様に準拠はするが、通信装置２０に許容されない場合がある。例えば、通信装置２０が、高負荷の処理を実行中のため一時的に装置内部のリソースが逼迫しており、新規ストリームの受け入れをできない場合は、ストリームエラーとなる。または、通信装置２０が、フロー制御ウィンドウのサイズを減少させるために初期ウィンドウサイズのＳＥＴＴＩＮＧＳフレームを送信した後に、初期ウィンドウサイズを超えるデータ量のＤＡＴＡフレームを受信した場合もストリームエラーとなる。
【００３９】
Ｓ６０２において、ストリーム判断部３０９が、Ｓ６０１において検知したストリームエラーの要因がコネクションエラー判断の対象か否かを判断する。この処理の詳細については図７を用いて後述する。エラー要因がコネクションエラー判断の対象であると判断された場合（Ｓ６０２；Ｙｅｓ）はＳ６０３に進むが、コネクションエラー判断の対象でないと判断された場合（Ｓ６０２；Ｎｏ）はＳ６０９に進む。なお、本実施形態ではストリームエラーの要因によってストリーム判断部３０９がエラー回数をカウントするか否かを判断するが、これに限らず、ストリーム判断部３０９は検知した全てのストリームエラーの回数をカウントしてもよい。
【００４０】
Ｓ６０３において、ストリーム判断部３０９が、検知したストリームエラーの要因に応じて検知回数をインクリメントする。本実施形態において、ストリーム判断部３０９は、コネクション（論理的な第１接続）に基づくストリーム（論理的な第２接続）におけるエラーの検知回数を要因ごとにカウントするが、これに限らない。ストリーム判断部３０９は、エラーの要因を分類して分類単位で検知回数をカウントしてもよい。また、ストリーム判断部３０９は、特定の要因のエラーだけをカウントしてもよいし、要因に関わらず全てのストリームエラーの検知回数の合計をカウントしてもよい。Ｓ６０４において、コネクション判断部３０８が、ストリーム判断部３０９がカウントしている（コネクションエラー判断の対象の）ストリームエラーが所定回数以上に達したか否かを判断する。ストリームエラーが所定回数以上に達したと判断された場合（Ｓ６０４；Ｙｅｓ）はＳ６０５に進むが、所定回数以上に達していないと判断された場合（Ｓ６０４；Ｎｏ）はＳ６０９に進む。
【００４１】
Ｓ６０５において、通信判断部３１０が、通信装置１０とのＨＴＴＰ通信において、Ｓ６０１でストリームエラーが検知されたストリーム以外に実行中の有効なストリームが存在するか否かを判断する。この処理の詳細については図８を用いて後述する。他に実行中の有効なストリームが存在しないと判断された場合（Ｓ６０５；Ｎｏ）はＳ６０６に進むが、他に実行中の有効なストリームが存在すると判断された場合（Ｓ６０５；Ｙｅｓ）はＳ６０９に進む。
【００４２】
Ｓ６０６において、コネクション判断部３０８がコネクションエラーとして処理する判断を下し、Ｓ６０７で通信装置１０に送信されるＧＯＡＷＡＹフレームに含めるエラーコードを決定する。本実施形態においてコネクション判断部３０８は、ＧＯＡＷＡＹフレーム中のエラーコードとして不特定のエラーを示すＰＲＯＴＯＣＯＬ＿ＥＲＲＯＲを利用するが、これに限らず、他のエラーコードを用いてもよい。また、ＧＯＡＷＡＹフレーム中の追加デバッグ情報に、ストリームエラーをコネクションエラーとして処理する旨とその理由・根拠を示すデバッグ情報を記載してもよい。
【００４３】
Ｓ６０７において、ＨＴＴＰ制御部３０７が、Ｓ６０６で決定されたエラーコードおよび追加デバッグ情報を含めたＧＯＡＷＡＹフレームを通信装置１０に送信してコネクションを切断することで、コネクション（第１接続）の終了処理を実行する。ただしＨＴＴＰ制御部３０７は、ＧＯＡＷＡＹフレームを送信せずにコネクションを切断してもよく、これら以外の方法でコネクションの終了処理を実行してもよい。またＨＴＴＰ制御部３０７は、ＧＯＡＷＡＹフレームを送信した後に通信を続けることもできる。Ｓ６０８において、ストリーム判断部３０９がストリームエラーの検知回数のカウントを初期化し、処理を終了する。
【００４４】
Ｓ６０９において、コネクション判断部３０８がコネクションエラーとして処理しない判断を下す。そしてコネクション判断部３０８は、Ｓ６１０で通信装置１０に送信されるＲＳＴ＿ＳＴＲＥＡＭフレームに含めるエラーコードを、ストリーム判断部３０９が判断したエラー要因に基づいて決定する。Ｓ６１０において、ＨＴＴＰ制御部３０７が通信装置１０に対して、Ｓ６０９で決定されたエラーコードを含めたＲＳＴ＿ＳＴＲＥＡＭフレームを送信し、処理を終了する。
【００４５】
［ストリームエラー要因の判断フロー］
図７は、通信装置２０によるストリームエラーの要因の判断に関する動作を説明するためのフローチャートであり、図６のＳ６０２の詳細を示すものである。
【００４６】
Ｓ７０１において、ストリーム判断部３０９が、Ｓ６０１において検知したストリームエラーの要因を確認する。具体的には、検知したエラーに応じて通信装置２０が送信すべきＲＳＴ＿ＳＴＲＥＡＭフレームまたは通信装置２０が通信装置１０から受信したＲＳＴ＿ＳＴＲＥＡＭフレームに含まれるエラーコードを参照する。Ｓ７０２において、ストリーム判断部３０９が、Ｓ７０１で参照したエラーコードがＲＥＦＵＳＥＤ＿ＳＴＲＥＡＭであるか否かを判断する。エラーコードがＲＥＦＵＳＥＤ＿ＳＴＲＥＡＭであると判断された場合（Ｓ７０２；Ｙｅｓ）はＳ７０３に進むが、ＲＥＦＵＳＥＤ＿ＳＴＲＥＡＭでないと判断された場合（Ｓ７０２；Ｎｏ）はＳ７０４に進む。なお、本実施形態ではエラーコードがＲＥＦＵＳＥＤ＿ＳＴＲＥＡＭであるエラーのみをコネクションエラー判断の対象とするが、これに限らない。例えば、エラーコードがＮＯ＿ＥＲＲＯＲでなく且つＣＡＮＣＥＬでないストリームエラー全てをコネクションエラー判断の対象としてもよい。また例えば、エラーコードがＩＮＴＥＲＮＡＬ＿ＥＲＲＯＲであるエラーとＰＲＯＴＯＣＯＬ＿ＥＲＲＯＲであるエラーを合わせて第１分類とし、ＲＥＦＵＳＥＤ＿ＳＴＲＥＡＭのエラーを第２分類とし、各分類のエラー回数をカウントしてもよい。
【００４７】
Ｓ７０３において、ストリーム判断部３０９が、ストリームエラーの要因がコネクションエラー判断の対象であると判断し、図７の処理を終了して図６のＳ６０３に進む。Ｓ７０４において、ストリーム判断部３０９が、ストリームエラーの要因がコネクションエラー判断の対象でないと判断し、図７の処理を終了して図６のＳ６０９に進む。
【００４８】
本実施形態では、ストリームエラーがコネクションエラー判断の対象となるか否かを、コネクション判断部３０８がエラーコードに基づいて判断する方法を用いたが、これに限らない。例えば、コネクション判断部３０８は、ストリームエラーの原因となった通信装置１０により送信されたフレームの内容に基づいて判断してもよい。また、要因に関わらず全てのストリームエラーをコネクションエラー判断の対象としてもよい。
【００４９】
［実行中ストリームの存在判断フロー］
図８は、通信装置２０によるコネクション上の実行中ストリームの存在判断に関する動作を説明するためのフローチャートであり、図６のＳ６０５の詳細を示すものである。なお、本実施形態における実行中ストリームとは、通信装置１０と通信装置２０との間に確立されているストリームを指す。
【００５０】
Ｓ８０１において、通信判断部３１０は、ＨＴＴＰ制御部３０７が管理している確立済み又は予約済みストリームのストリームＩＤの中で最も値が大きいＩＤ（最終ストリームＩＤ）を取得する。Ｓ８０２において、通信判断部３１０は、ＨＴＴＰ制御部３０７が管理している確立済み又は予約済みストリームをＩＤ：１のストリームから順番に判断対象のストリームとし、そのストリームの情報を取得する。Ｓ８０３において、通信判断部３１０はＳ８０２で取得したストリームの情報を参照し、対象ストリームがストリームエラーの検知されたストリームか否かを判断する。対象ストリームがストリームエラーの検知されたストリームだった場合（Ｓ８０３；Ｙｅｓ）はＳ８０２に戻り、次のＩＤのストリームを対象ストリームとして情報を取得する。一方、対象ストリームがストリームエラーの検知されたストリームでない場合（Ｓ８０３；Ｎｏ）はＳ８０４に進む。
【００５１】
Ｓ８０４において、通信判断部３１０は、対象ストリームの状態がｏｐｅｎまたはｈａｌｆ  ｃｌｏｓｅｄであるか否かを判断する。対象ストリームの状態がｏｐｅｎまたはｈａｌｆ  ｃｌｏｓｅｄであると判断された場合（Ｓ８０４；Ｙｅｓ）はＳ８０５に進むが、ｏｐｅｎでもｈａｌｆ  ｃｌｏｓｅｄでもないと判断された場合（Ｓ８０５；Ｎｏ）はＳ８０６に進む。ＨＴＴＰ／２において、通信装置間のストリームの状態がｏｐｅｎまたはｈａｌｆ  ｃｌｏｓｅｄである場合、そのストリームは確立済みであり、少なくとも一方の通信装置がデータを送信中又は送信できる状態である。
【００５２】
Ｓ８０５において、通信判断部３１０は、ストリームエラーが検知されたストリームの他に実行中で有効なストリームが存在すると判断し、図８の処理を終了して図６のＳ６０９に進む。Ｓ８０６において、通信判断部３１０は対象ストリームのストリームＩＤが最終ストリームＩＤと一致するか否かを判断する。対象ストリームＩＤが最終ストリームＩＤと一致した場合（Ｓ８０６；Ｙｅｓ）はＳ８０７に進むが、対象ストリームＩＤが最終ストリームＩＤと一致しない場合（Ｓ８０６；Ｎｏ）はＳ８０２に戻り、次のＩＤのストリームを判断対象として情報を取得する。Ｓ８０７において、通信判断部３１０は、ストリームエラーが検知されたストリームの他に実行中で有効なストリームが存在しないと判断し、図８の処理を終了して図６のＳ６０６に進む。
【００５３】
以上説明したように、本実施形態における通信装置２０は、通信装置１０との通信においてストリームエラーを検知した場合、エラーの要因および検知回数に基づいてストリームエラーをコネクションエラーとして処理し、コネクションを終了する。これによって通信装置２０は、ストリームエラー処理に係る処理負荷の増大を抑制することができる。
【００５４】
例えば、通信装置２０において通信資源（リソース）不足が継続的に続いて新規ストリームを受け入れることができない場合を想定する。本実施形態の技術を適用しない場合、通信装置２０は、通信装置１０からの新規ストリーム確立要求（ＨＥＡＤＥＲＳフレーム）に対して繰り返し発生するストリームエラーを、コネクションを維持したまま処理してリソースを消費し続ける。これに対して本実施形態の技術を適用すれば、通信装置２０がコネクションを終了することで、繰り返し発生するストリームエラーを処理することによる無駄なリソースの消費を低減することができる。さらに、同時に確立できるコネクション数の不足により対応できていなかった別のリクエストがある場合には、通信装置２０がコネクションを終了することで、そのリクエストへのレスポンスのためのコネクションを新たに確立することもできる。また、通信装置２０は、ストリームエラーを検知してコネクションを終了する場合、同様のストリームエラーを引き起こすような通信パラメータを使用しないように通信装置１０に指示してもよい。
【００５５】
また、もし全てのストリームエラーがコネクションエラーとして扱われた場合、頻繁にコネクションを終了する可能性が高くなり、ＨＴＴＰ通信の再接続に係るオーバーヘッドが大きくなって、システム全体の性能が低下してしまう。これに対し本実施形態の技術では、エラーの要因および検知回数に基づいてコネクションエラーの判断を下すため、ＨＴＴＰ通信の再接続に係るオーバーヘッドが大きくなりすぎるのを防ぐことができる。
【００５６】
また、本実施形態における通信装置２０は、ストリームエラーが発生するときの通信状況に基づいて、コネクションエラーが発生したものとして処理するか否かを判断する。例えば、コネクション判断部３０８は、コネクションエラーとして処理するか否かを判断する際に、エラーが検知されたストリームの他に実行中の有効なストリームが存在するか否かを判断する。このとき、他に実行中の有効なストリームが存在する場合はコネクションエラーとして処理しないため、コネクションの終了によって他の実行中ストリームでの通信を中断させてしまう問題を回避することができる。これによって、システム全体の性能が向上する。
【００５７】
なお、他の実行中ストリームでの通信を中断させてでも、一旦コネクションを終了して新たなコネクションで通信を再開した方がシステム全体の性能が向上する場合もある。そのためコネクション判断部３０８は、コネクションエラー判断の際に、エラーが検知されたストリームの他に実行中のストリームが所定数未満であるか否かを判断してもよい。具体的には、ストリーム判断部３０９によりストリームにおけるエラーが検知された場合、コネクション判断部３０８はコネクションに基づいて確立されているストリームの数が所定数未満であるか否かを判断する。ストリームの数が所定数未満である場合、コネクション判断部３０８は、ストリーム判断部３０９が検知したエラーの回数や、ＨＴＴＰ制御部３０７が通信しているデータの内容等に基づいて、コネクションエラーとして処理するかどうか判断する。一方ストリームの数が所定数以上である場合、コネクション判断部３０８は、コネクションエラーとして処理しない判断を下す。
【００５８】
また、コネクション判断部３０８は、ＨＴＴＰ制御部３０７がストリームを使用して通信しているデータの内容に基づいて、コネクションエラーが発生したものとして処理するか否か判断してもよい。具体的には、ストリーム判断部３０９によりストリームエラーが検知された場合、コネクション判断部３０８は、エラーに対応するストリームがＨＴＴＰ制御部３０７により所定の表示サイズ以上の動画又は静止画の通信に使用されるか否か判断する。所定の表示サイズ以上の動画又は静止画の通信に使用されるストリームである場合、コネクション判断部３０８は、検知されたエラーの回数やコネクションに基づくストリームの数等に基づいて、コネクションエラーとして処理するかどうか判断する。例えば、所定の表示サイズ以上の動画又は静止画の通信に使用されるストリームにおけるエラーが検知された場合に、ストリーム判断部３０９がカウントしているエラーの回数が閾値以上であれば、コネクション判断部３０８はコネクションエラーとして処理する。一方、エラーに対応するストリームが所定の表示サイズ未満の動画又は静止画の通信に使用されるストリームである場合、コネクション判断部３０８は、コネクションエラーとして処理しない判断を下す。これにより、通信装置２０が、表示サイズの小さい補助的なコンテンツの送信に伴うストリームエラーを検知してコネクションを終了することで、表示サイズが大きいメインのコンテンツの送信を中断させてしまう問題を回避することができる。
【００５９】
また、本実施形態における通信装置２０は、複数確立可能なコネクションのうち同一のコネクション（論理的な第１接続）に基づくストリーム（論理的な第２接続）におけるエラーが所定の回数以上検知された場合に、コネクションの終了処理を実行した。しかしながら、ストリーム判断部３０９がカウントするエラーは、同一のコネクションにおいて検知されるストリームエラーに限らない。例えば、通信装置２０と通信装置１０との間に複数のコネクションが確立されている場合、通信装置２０は、それらのコネクションにおけるストリームエラーの検知回数の合計が所定の回数以上となった場合に、それらのコネクションの終了処理を実行してもよい。
また例えば、通信装置２０は、コネクションに基づくストリームの数に関するエラーが所定期間内に所定の回数以上検知された場合に、コネクションの終了処理を実行してもよい。ここで、コネクションに基づくストリームの数に関するエラーとは、例えば通信装置２０が許容できない多数のストリームの確立や予約を通信装置１０が要求したことにより発生するストリームエラーなどである。これにより、ストリームエラーの検知回数の累計は閾値に到達しないが、ある期間にのみ集中してストリームエラーが発生する場合に、ＨＴＴＰ制御部３０７がコネクションを終了することで無駄なリソース消費を低く抑えることができる。
【００６０】
また、コネクション判断部３０８は、ストリーム判断部３０９により検知されたエラーの要因に応じて、コネクションエラー判断のためのストリームエラー検知回数の閾値を変更してもよい。例えば、コネクション判断部３０８は、ＨＥＡＤＥＲＳフレームまたはＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの受け入れ失敗など、高頻度に発生する可能性が高いエラー要因に対応する検知回数の閾値を大きくする。一方、コネクション判断部３０８は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの受け入れ失敗など、低頻度だが通信への影響が大きいストリームエラーの要因に対応する検知回数の閾値を小さくする。これにより、通信継続に伴うリソース消費と、ＨＴＴＰ通信の再接続に係るオーバーヘッドのトレードオフをより詳細に制御することができ、システム全体の性能をさらに向上することができる。
【００６１】
上記と同様に、コネクション判断部３０８は、通信装置２０のリソース状況に応じて検知回数の閾値を変更してもよい。例えば、コネクション判断部３０８は、通信装置２０のリソースの一つであるメモリの空き容量が所定値以上である場合は検知回数の閾値を大きくし、メモリの空き容量が所定値未満である場合は検知回数の閾値を小さくする。これは、メモリの空き容量が小さい場合、通信を継続してもストリームエラーが発生し続ける可能性が高く、コネクションを終了した方が効率的だと判断できるためである。これにより、上述したトレードオフをさらに詳細に制御することができ、システム全体の性能をさらに向上することができる。
【００６２】
また、本実施形態におけるストリーム判断部３０９は、ストリームエラーの要因に応じて検知回数をカウントするが、これに限らず、通信装置２０が受信したリクエストの内容に応じて検知回数をカウントしてもよい。これによって、通信装置２０が提供するサービスの内容に応じてコネクションエラーの判断を下すことができ、システム全体の性能をさらに向上することができる。
【００６３】
また、本実施形態におけるストリーム判断部３０９は、ＨＴＴＰ通信切断後にストリームエラーの検知回数のカウントを初期化していたが、これに限らず、ＨＴＴＰ通信を切断してから所定時間はカウントを初期化しなくてもよい。この場合、通信装置１０が新たに開始したＨＴＴＰ通信において上記の所定期間内に最初のストリームエラーが発生すると、そのＨＴＴＰ通信は切断される。これによって、例えば、通信装置１０が再度ＨＴＴＰ通信を開始し、切断前と同じ要因のストリームエラーを発生させて同じ状況を繰り返してしまうことを回避できる。
【００６４】
また、ＨＴＴＰ制御部３０７が通信装置１０との間のコネクション（論理的な第１接続）の終了処理を実行した後に、通信装置１０から新たなコネクションの開始を要求された場合、ＴＣＰ制御部３０６がそのコネクション要求を拒絶してもよい。ＴＣＰ制御部３０６は、コネクションを要求した通信装置１０に対してコネクションエラーを通知することによって要求を拒絶してもよいし、要求に対して応答を行わず無視することで拒絶してもよく、これら以外の方法で拒絶してもよい。これによって、コネクションを再び開始してからコネクションエラー判断を下して終了処理を行う場合よりも無駄な処理を減らすことができる。また、実装によっては、コネクション要求の拒絶はハードウェアの処理により実行することができる。この実装によれば、通信装置１０がコネクション要求を繰り返す場合、コネクションを維持してストリーム要求を拒絶し続けるよりも、コネクション要求を拒絶した方がリソース消費量を低く抑えることができる。
【００６５】
また、ストリーム判断部３０９は、ストリームエラーを引き起こすリクエストを受信した場合にストリームエラーの検知回数をカウントし、ストリームエラーを引き起こさない正常なリクエストを受信した場合に検知回数を初期化してもよい。この方法によって、例えば、意図的にストリームエラーを発生させる攻撃を仕掛けてきた悪意ある通信装置と善意の通信装置とを区別して対応することができ、システム全体の性能とセキュリティのトレードオフを制御することができる。また、ストリーム判断部３０９は、ストリームエラーを引き起こさない正常なリクエストを受信した所定時間後に、ストリームエラーの検知回数を初期化してもよい。これにより、定期的に正常なリクエストを送信する悪意の通信装置にも対応できる。
【００６６】
さらに、ストリーム判断部３０９は、悪意ある他の通信装置から攻撃を受けたと判断した場合は、悪意ある他の通信装置のＩＰアドレスなどの情報をブラックリストに登録して、その通信装置に対応するストリームエラーの検知回数を初期化しなくてもよい。
【００６７】
また、コネクション判断部３０８は、図６のＳ６０６でのコネクションエラー判断の前に、通信装置２０のユーザにコネクションエラーとして処理しても良いか否かを確認しても良い。例えば、コネクション判断部３０８はコネクションエラー判断の前に、表示制御部３０３を利用して、コネクションエラーとして処理しても良いかどうかを確認するメッセージを表示する。そして、コネクション判断部３０８は操作制御部３０４を用いて、通信装置２０のユーザから上記の確認に対する選択の入力を取得する。もしユーザがコネクションエラーとして処理すると選択した場合、コネクション判断部３０８はＳ６０６においてコネクションエラーとして処理する判断を下す。一方、ユーザがコネクションエラーとして処理しないと選択した場合、コネクション判断部３０８はＳ６０９においてコネクションエラーとして処理しない判断を下す。これによってユーザの意図に反するコネクションエラーを回避することができ、利便性が向上する。
【００６８】
＜第２実施形態＞
以下、本発明に係る第２実施形態について説明する。第２実施形態における通信システム構成、機能モジュール構成、シーケンス、及びフローチャートについて、上述した第１実施形態と同じ部分については説明を省略する。なお本実施形態では、通信装置１０が、図３に示す機能モジュールを備え、図６に示すフローに従ってコネクションエラーの判断を下す。
【００６９】
図９は、本実施形態に係る、通信装置１０と通信装置２０とのＨＴＴＰ通信の開始から終了までの動作を説明するためのシーケンス図である。図９の処理は、通信装置２０からコンテンツを取得するためのユーザ操作が通信装置１０に入力されたタイミングで開始される。ただし、図９の処理の開始タイミングは上記タイミングに限定されない。図９において、図４と同様の部分に関しては説明を省略する。
【００７０】
Ｍ９０１において、通信装置１０が通信装置２０との間でコネクションを確立してＨＴＴＰ通信接続を行う。Ｍ９０２において、通信装置１０が通信装置２０に対してＨＴＴＰリクエストヘッダ情報が記述されたＨＥＡＤＥＲＳフレームを送信する。このＨＥＡＤＥＲＳフレームの送信によって、通信装置１０はストリームＩＤを１とする新規ストリームの確立を通信装置２０に要求する。
【００７１】
Ｍ９０３において、通信装置２０がＭ９０２で受信したＨＥＡＤＥＲＳフレームに応じてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信し、サーバプッシュのためのストリーム予約を通信装置１０に要求する。このとき要求される予約ストリームのＩＤは２とする。Ｍ９０４において、通信装置１０がＭ９０３で受信したＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに対する応答をＴＣＰ  ＡＣＫとして送信する。
【００７２】
Ｍ９０５において、Ｍ９０３と同様に、通信装置２０がＭ９０２で受信したＨＥＡＤＥＲＳフレームに応じてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信する。このとき要求される予約ストリームのＩＤは４とする。Ｍ９０６において、Ｍ９０４と同様に、通信装置１０がＭ９０５で受信したＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに対する応答をＴＣＰ  ＡＣＫとして送信する。Ｍ９０７において、Ｍ９０３と同様に、通信装置２０がＭ９０２で受信したＨＥＡＤＥＲＳフレームに応じてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信する。このとき要求される予約ストリームのＩＤは６とする。
【００７３】
Ｍ９０８において、通信装置１０がメモリリソース不足等の要因により新規ストリーム予約の要求を受け入れられず、ストリームエラーが発生する。このとき、通信装置１０のストリーム判断部３０９は、ストリームエラーを検知して検知回数をインクリメントする（カウント：１）。なお、本実施形態において、通信装置１０のコネクション判断部３０８は、ストリーム判断部３０９が同じ要因のストリームエラーを３回以上検知した場合、コネクションエラーとして処理する判断を下す。Ｍ９０９において、通信装置１０のＨＴＴＰ制御部３０７が通信装置２０に対してストリームエラー通知を示すＲＳＴ＿ＳＴＲＥＡＭフレームを送信する。
【００７４】
Ｍ９１０において、Ｍ９０３と同様に、通信装置２０がＭ９０２で受信したＨＥＡＤＥＲＳフレームに応じてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信する。このとき要求される予約ストリームのＩＤは８とする。Ｍ９１１において、Ｍ９０８と同様の理由でストリームエラーが発生する。このとき、通信装置１０のストリーム判断部３０９は、Ｍ９０８と同様に、ストリームエラーを検知して検知回数をインクリメントする（カウント：２）。Ｍ９１２において、Ｍ９０９と同様に、通信装置１０のＨＴＴＰ制御部３０７が通信装置２０に対してＲＳＴ＿ＳＴＲＥＡＭフレームを送信する。Ｍ９１３において、Ｍ９０３と同様に、通信装置２０がＭ９０２で受信したＨＥＡＤＥＲＳフレームに応じてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信する。このとき要求される予約ストリームのＩＤは１０とする。
【００７５】
Ｍ９１４において、Ｍ９０８と同様の理由でストリームエラーが発生する。このとき、通信装置１０のストリーム判断部３０９は、Ｍ９０８と同様に、ストリームエラーを検知して検知回数をインクリメントする（カウント：３）。Ｍ９１５において、同じ要因のストリームエラーの検知回数が３になり、さらに他に実行中のストリームが存在しないため、通信装置１０のコネクション判断部３０８がコネクションエラーとして処理する判断を下す。Ｍ９１６において、通信装置１０のＨＴＴＰ制御部３０７が通信装置２０に対してコネクションエラー通知を示すＧＯＡＷＡＹフレームを送信する。Ｍ９１７において、通信装置１０と通信装置２０がＨＴＴＰ通信接続を終了する。Ｍ９１８において、通信装置１０のストリーム判断部３０９がストリームエラーの検知回数を初期化する（カウント：０）。
【００７６】
以上説明したように、本実施形態における通信装置１０は、通信装置２０からのストリーム予約の要求に対して、ストリームエラーの要因および発生回数に基づいて、コネクションエラーが発生したものとして処理し、コネクションを終了する。これにより、通信装置１０が許容できない多数のストリーム予約の要求に個別に対応する必要がなくなり、無駄なリソースの消費を低減することができる。
なお、本実施形態では通信装置１０がメモリリソースの不足等によりストリーム予約を受け入れられずストリームエラーが発生する場合について説明した。しかしながら、通信装置１０が所定の数（第２所定数）を超えるストリーム予約を要求された場合に発生するストリームエラーは、これに限らない。例えば、通信装置１０は受け入れ可能なストリーム予約数を予め設定しておいてもよく、その場合、予め設定された予約数が第２所定数となる。
【００７７】
なお、第１実施形態においては、通信装置２０がストリームエラーの検知やカウント、コネクションエラーの判断、コネクション終了処理などを実行する機能を有し、第２実施形態においては、通信装置１０が同様の機能を有していた。しかしこれに限らず、通信装置１０と通信装置２０との間の通信を中継するプロキシサーバ等が上述の機能を有していても同じ効果が得られる。
【００７８】
＜その他の実施形態＞
上述した各実施形態は、その複数を組み合わせて実施することもできる。
【００７９】
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ等）によっても実現可能である。また、そのプログラムをコンピュータにより読み取り可能な記録媒体に記録して提供してもよい。
【符号の説明】
【００８０】
１０  第１の通信装置
２０  第２の通信装置
３０７  ＨＴＴＰ通信制御部
３０８  コネクションエラー判断部
３０９  ストリームエラー判断部
３１０  通信状況判断部
【図１】
0006436853.tif 000002
【図２】
0006436853.tif 000003
【図３】
0006436853.tif 000004
【図４】
0006436853.tif 000005
【図５】
0006436853.tif 000006
【図６】
0006436853.tif 000007
【図７】
0006436853.tif 000008
【図８】
0006436853.tif 000009
【図９】
0006436853.tif 000010