(57)【要約】【課題】コネクション上に複数のストリームを確立して通信を行う通信システムにおいて、ストリームＩＤの増加に伴うコネクションの切断を発生しにくくする。【解決手段】通信装置２０は、通信装置３０との間に確立される１つの論理的な通信路（コネクション）上に、識別子が割り当てられた論理的な通信路であるストリームを複数確立可能である。通信装置２０は、すでに確立されたストリームの識別子を再利用するか否かを判断する判断手段と、判断手段によりストリームの識別子を再利用すると判断した場合に、通信装置３０に対して、ストリームの識別子の再利用を要求する要求手段と、を備える。さらに、通信装置２０は、判断手段によりストリームの識別子を再利用すると判断した場合に、識別子を再利用して、通信路上のストリームを通信装置３０との通信が可能な状態に設定する設定手段を備える。【選択図】      図３
2017011641.tif 000002
【特許請求の範囲】
【請求項１】
他の通信装置との間に確立される１つの論理的な通信路上に、識別子が割り当てられた論理的な通信路であるストリームを複数確立可能な通信装置であって、
すでに確立されたストリームの識別子を再利用するか否かを判断する判断手段と、
前記判断手段により前記ストリームの前記識別子を再利用すると判断した場合に、前記他の通信装置に対して、前記ストリームの前記識別子の再利用を要求する要求手段と、
前記判断手段により前記ストリームの前記識別子を再利用すると判断した場合に、前記識別子を再利用して、前記通信路上の前記ストリームを前記他の通信装置との通信が可能な状態に設定する設定手段と、を備えることを特徴とする通信装置。
【請求項２】
前記要求に対する前記他の通信装置からの応答を受信する受信手段をさらに備え、
前記設定手段は、
前記受信手段により前記他の通信装置が前記識別子の再利用を許可する応答を受信した場合に、前記識別子を再利用することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記設定手段は、
前記受信手段により前記応答として再利用を許可する前記識別子の情報を受信した場合に、再利用を許可された前記識別子を再利用することを特徴とする請求項２に記載の通信装置。
【請求項４】
前記判断手段により前記識別子を再利用しないと判断した場合に、すでに確立されたストリームの識別子よりも大きい値の識別子を用いて新しいストリームを確立する確立手段をさらに備え、
前記判断手段は、
前記確立手段が確立したストリームの前記識別子が、使用可能な最大値に到達したとき、すでに確立されたストリームの識別子を再利用すると判断することを特徴とする請求項１〜３のいずれか１項に記載の通信装置。
【請求項５】
前記判断手段により前記識別子を再利用しないと判断した場合に、すでに確立されたストリームの識別子よりも大きい値の識別子を用いて新しいストリームを確立する確立手段をさらに備え、
前記判断手段は、
前記確立手段が確立したストリームの前記識別子が、使用可能な最大値よりも小さい所定の閾値を超えたとき、すでに確立されたストリームの識別子を再利用すると判断することを特徴とする請求項１〜３のいずれか１項に記載の通信装置。
【請求項６】
前記判断手段は、前記他の通信装置から、すでに確立されたストリームの識別子の再利用が必要であることを示す通知を受信したとき、すでに確立されたストリームの識別子を再利用すると判断することを特徴とする請求項１〜３のいずれか１項に記載の通信装置。
【請求項７】
前記要求手段は、再利用を要求する前記識別子の情報を、前記他の通信装置へ送信することを特徴とする請求項１〜６のいずれか１項に記載の通信装置。
【請求項８】
前記要求手段は、再利用を要求する前記識別子の区間の最小値を、前記他の通信装置へ送信することを特徴とする請求項７に記載の通信装置。
【請求項９】
前記要求手段は、再利用を要求する複数の前記識別子の値を、前記他の通信装置へリストで送信することを特徴とする請求項７に記載の通信装置。
【請求項１０】
他の通信装置との間に確立される１つの論理的な通信路上に、識別子が割り当てられた論理的な通信路であるストリームを複数確立可能な通信装置であって、
前記他の通信装置が、すでに確立されたストリームの識別子を再利用するとの判断を受けて送信した、前記ストリームの前記識別子の再利用の要求を受信する第一の受信手段と、
前記第一の受信手段により前記要求を受信したとき、前記再利用を許可するか否かを判断する判断手段と、
前記判断手段により前記再利用を許可すると判断した場合に、前記識別子を再利用したストリームを介してデータを受信する第二の受信手段と、を備えることを特徴とする通信装置。
【請求項１１】
前記判断手段による判断結果を、前記要求への応答として前記他の通信装置へ送信する送信手段をさらに備えることを特徴とする請求項１０に記載の通信装置。
【請求項１２】
前記送信手段は、
前記判断手段により前記再利用を許可すると判断した場合に、前記応答として、自装置がデータを受信可能なストリームの識別子の情報を送信することを特徴とする請求項１１に記載の通信装置。
【請求項１３】
他の通信装置との間に確立される１つの論理的な通信路上に、識別子が割り当てられた論理的な通信路であるストリームを複数確立可能な通信装置であって、
すでに確立されたストリームの識別子の再利用が必要か否かを判断する判断手段と、
前記判断手段により前記ストリームの前記識別子の再利用が必要であると判断した場合に、前記他の通信装置に対して、前記ストリームの識別子の再利用が必要であることを通知する通知手段と、
前記判断手段により前記ストリームの前記識別子の再利用が必要であると判断した場合に、前記識別子を再利用した前記ストリームの処理を行う処理手段と、を備えることを特徴とする通信装置。
【請求項１４】
前記請求項１〜９のいずれか１項に記載の通信装置と、前記請求項１０〜１２のいずれか１項に記載の通信装置とが通信可能に接続された通信システム。
【請求項１５】
他の通信装置との間に確立される１つの論理的な通信路上に、識別子が割り当てられた論理的な通信路であるストリームを複数確立可能な通信制御方法であって、
すでに確立されたストリームの識別子を再利用するか否かを判断するステップと、
前記ストリームの前記識別子を再利用すると判断した場合に、前記他の通信装置に対して、前記ストリームの前記識別子の再利用を要求するステップと、
前記ストリームの前記識別子を再利用すると判断した場合に、前記識別子を再利用して、前記通信路上の前記ストリームを前記他の通信装置との通信が可能な状態に設定するステップと、を含むことを特徴とする通信制御方法。
【請求項１６】
他の通信装置との間に確立される１つの論理的な通信路上に、識別子が割り当てられた論理的な通信路であるストリームを複数確立可能な通信制御方法であって、
前記他の通信装置が、すでに確立されたストリームの識別子を再利用するとの判断を受けて送信した、前記ストリームの前記識別子の再利用の要求を受信するステップと、
前記要求を受信したとき、前記再利用を許可するか否かを判断するステップと、
前記再利用を許可すると判断した場合に、前記識別子を再利用したストリームを介してデータを受信するステップと、を含むことを特徴とする通信制御方法。
【請求項１７】
コンピュータを、前記請求項１〜１３のいずれか１項に記載の通信装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１つの論理的な通信路上に、識別子が割り当てられた複数の論理的な通信路であるストリームを確立して通信を行う通信装置、通信制御方法及び通信システムに関する。
【背景技術】
【０００２】
インターネット標準技術として一般に広く利用されているプロトコル（通信規約）の一つに、ＨＴＴＰ／１．１がある。また、インターネット標準化団体（ＩＥＴＦ：Internet Engineering Task Force）において、ＨＴＴＰプロトコルの新しいバージョンであるＨＴＴＰ／２が策定された。ＨＴＴＰ／２は、ＳＰＤＹ（登録商標）プロトコルをベースとして策定されたプロトコルである。ＨＴＴＰ／２やＳＰＤＹでは、クライアントとサーバとの間に１つのＴＣＰコネクション（通信路）を張り、１つのコネクション上で、複数のストリーム（論理的な通信路）を張ることで通信の効率化を行っている。特許文献１には、ＳＰＤＹプロトコルを用いて複数のストリームでデータ通信を行う情報処理システムが開示されている。なお、各ストリームは、ストリームＩＤ（ストリーム識別子）によって識別される。ストリームＩＤは、新しいストリームが確立されるごとに値が増加する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−２１７２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ＨＴＴＰ／２やＳＰＤＹ等の通信プロトコルにおいて、ストリームＩＤが上限に達すると、コネクションの切断が発生する可能性がある。しかしながら、コネクションの切断から新たなコネクションが確立されるまでの間、通信相手に通信データのリクエストを発行することができない。また、コネクションの切断と新しいコネクションの確立とには、処理負荷がかかる。
そこで、本発明は、コネクション上に複数のストリームを確立して通信を行う通信システムにおいて、ストリームＩＤの増加に伴うコネクションの切断を発生しにくくすることを目的としている。
【課題を解決するための手段】
【０００５】
上記課題を解決するために、本発明に係る通信装置の一態様は、他の通信装置との間に確立される１つの論理的な通信路上に、識別子が割り当てられた論理的な通信路であるストリームを複数確立可能な通信装置であって、すでに確立されたストリームの識別子を再利用するか否かを判断する判断手段と、前記判断手段により前記ストリームの前記識別子を再利用すると判断した場合に、前記他の通信装置に対して、前記ストリームの前記識別子の再利用を要求する要求手段と、前記判断手段により前記ストリームの前記識別子を再利用すると判断した場合に、前記識別子を再利用して、前記通信路上の前記ストリームを前記他の通信装置との通信が可能な状態に設定する設定手段と、を備える。
【発明の効果】
【０００６】
本発明によれば、コネクション上に複数のストリームを確立して通信を行う通信システムにおいて、ストリームＩＤの増加に伴うコネクションの切断が発生しにくくなる。
【図面の簡単な説明】
【０００７】
【図１】通信システムの一例を示す概略構成図である。
【図２】通信装置のハードウェア構成の一例である。
【図３】通信装置（再利用要求側）のモジュール構成を示す図である。
【図４】フレームのフォーマットを示す図である。
【図５】通信装置（再利用要求の受信側）のモジュール構成を示す図である。
【図６】通信装置（再利用要求側）の動作を示すフローチャートである。
【図７】ストリームＩＤの再利用要求を表すＰＩＮＧフレームである。
【図８】ストリームＩＤの再利用要求への応答を表すＰＩＮＧフレームである。
【図９】通信装置（再利用要求の受信側）の動作を示すフローチャートである。
【図１０】ストリームの状態の一例を示す図である。
【図１１】ストリームＩＤの再利用時のストリームの状態を示す図である。
【図１２】ストリームＩＤの再利用終了時のストリームの状態を示す図である。
【図１３】通信装置間のメッセージのやり取りを示すシーケンス図である。
【発明を実施するための形態】
【０００８】
以下、添付図面を参照して、本発明を実施するための形態について詳細に説明する。
なお、以下に説明する実施の形態は、本発明の実現手段としての一例であり、本発明が適用される装置の構成や各種条件によって適宜修正又は変更されるべきものであり、本発明は以下の実施の形態に限定されるものではない。
本実施形態における通信システムは、複数の通信装置間において双方向に通信が可能なシステムである。本実施形態では、通信プロトコルとして、ＨＴＴＰ／２（Hypertext Transfer Protocol version 2）を使用する。そして、通信装置間において確立した論理的な通信路（以下、「コネクション」という。）上に、双方向に通信可能な複数の論理的な通信路（以下、「ストリーム」という。）を確立し、データ（フレーム）の送受信を行う。
なお、コネクションとは、２つのエンドポイント間（クライアント・サーバ間）のトランスポート層（ＴＣＰレイヤ）での接続を意味する。また、ストリームとは、対象とする上位通信プロトコルにおける論理チャネルのことである。さらに、フレームとは、実際にデータを送信する際に、データを細切れにした最少単位のブロックのことである。
【０００９】
図１は、本実施形態における通信システム１０の一例を示す概略構成図である。本実施形態では、通信システム１０を店舗内の監視を行う監視カメラシステムに適用する例を説明する。
通信システム１０は、通信装置２０と通信装置３０とを備える。通信装置２０と通信装置３０とは、ネットワーク４０を介して接続されている。本実施形態において、通信装置２０は、店舗内に設置されたネットワークカメラ、通信装置３０は、パーソナルコンピュータ（ＰＣ）によって構成される管理端末とすることができる。通信装置２０は、店舗内を撮像し、撮像領域内に不審者が侵入するなどのイベントを検出したとき、検出したイベントを通信装置３０へ通知する。なお、本実施形態では、通信装置２０がＨＴＴＰ／２クライアント、通信装置３０がＨＴＴＰ／２サーバとして説明を行うが、逆の構成であってもよい。つまり、通信装置２０がＨＴＴＰ／２サーバ、通信装置３０がＨＴＴＰ／２クライアントであってもよい。また、本実施形態では、通信装置３０を１台のＰＣによって実現しているが、通信装置３０は、プロキシサーバを含めてもよいし、クラウド上で分散して配置されていてもよい。
【００１０】
ネットワーク４０は、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、若しくはこれらの複合により実現できる。なお、通信装置１０と通信装置２０とは、ネットワーク４０を介さずに、例えば、無線アドホックネットワークを用いて直接接続してもよい。
また、通信装置２０と通信装置３０とは、ネットワーク４０（通信路）を通じて、ＨＴＴＰ／２を使用して通信を行う。ＨＴＴＰ／２において、ストリームは、３１ビットの整数からなるストリーム識別子（ストリームＩＤ）によって識別される。本実施形態では、ストリームＩＤを再利用可能とし、ストリームＩＤを使い切ってしまった場合であっても、コネクションを接続しなおすことなく、すでに確立されたストリームを再利用して通信を行う。すなわち、通信装置２０は、通信装置３０（他の通信装置）との間に確立される１つの論理的なコネクション上（通信路上）に、識別子が割り当てられた論理的な通信路であるストリームを複数確立可能である。そして、通信装置２０は、以下で説明する所定の条件に基づいて、すでに確立済みのストリームに対応するストリームＩＤを再利用するための制御を実行する。
【００１１】
図２は、通信装置２０のハードウェア構成を示す図である。
通信装置２０は、ＣＰＵ２１と、ＲＯＭ２２と、ＲＡＭ２３と、外部メモリ２４と、撮像部２５と、表示部２６と、通信Ｉ／Ｆ２７と、システムバス２８とを備える。ＣＰＵ２１は、通信装置２０における動作を統括的に制御するものであり、システムバス２８を介して、各構成部（２２〜２７）を制御する。ＲＯＭ２２は、ＣＰＵ２１が処理を実行するために必要なプログラムを記憶する不揮発性メモリである。なお、当該プログラムは、外部メモリ２４や着脱可能な記憶媒体（不図示）に記憶されていてもよい。ＲＡＭ２３は、ＣＰＵ２１の主メモリ、ワークエリアとして機能する。すなわち、ＣＰＵ２１は、処理の実行に際してＲＯＭ２２から必要なプログラムをＲＡＭ２３にロードし、ロードしたプログラムを実行することで各種の機能動作を実現する。
【００１２】
外部メモリ２４は、例えば、ＣＰＵ２１がプログラムを用いた処理を行う際に必要な各種データや各種情報を記憶している。また、外部メモリ２４には、例えば、ＣＰＵ２１がプログラムを用いた処理を行うことにより得られた各種データや各種情報が記憶される。撮像部２５は、被写体の撮像を行うためのものであり、ＣＭＯＳ（Complementary Metal Oxide Semiconductor）、ＣＣＤ（Charge Coupled Device）等の撮像素子を含んで構成される。表示部２６は、液晶ディスプレイ（ＬＣＤ）等のモニタによって構成される。通信Ｉ／Ｆ２７は、通信相手である通信装置３０と通信するためのインターフェースである。
なお、通信装置２０が撮像機能を有していない場合には、撮像部２５は不要である。また、通信装置３０のハードウェア構成は、撮像部２５が不要であることを除いては、図２に示す通信装置２０のハードウェア構成と同様である。
【００１３】
以下、通信装置２０をストリームＩＤの再利用を要求する側、通信装置３０をストリームＩＤの再利用の要求を受信する側として説明する。
（通信装置２０の構成）
図３は、ストリームＩＤの再利用を要求する側である通信装置２０のモジュール構成を示す図である。通信装置２０は、通信制御部２０１と、表示制御部２０２と、接続確立部２０３と、フレーム作成部２０４と、フレーム受信部２０５と、フレーム解析部２０６と、フレーム送信部２０７と、を備える。さらに、通信装置２０は、再利用要求作成部２０８と、応答解析部２０９と、再利用可否判断部２１０と、ストリームＩＤ管理部２１１と、ストリーム処理部２１２と、再利用要否判断部２１３と、を備える。これらの各モジュール２０１〜２１３は、バス２００によって接続されている。
【００１４】
通信制御部２０１は、ＴＣＰ／ＩＰ処理、及びＴＬＳ（Transport Layer Security）処理を行う。表示制御部２０２は、ユーザが通信装置２０を操作するためのＧＵＩ（Graphical User Interface）を図２の表示部２６に表示する。接続確立部２０３は、通信装置２０と通信装置３０との間に、ＨＴＴＰ／２によるコネクション（接続）を確立する。コネクションの確立には、プロトコルアップグレードや、コネクションプリフェイスの送受信が含まれる。コネクションを確立すると、通信装置２０と通信装置３０との間でＨＴＴＰ／２通信が可能となる。
【００１５】
フレーム作成部２０４は、通信装置２０がＨＴＴＰ／２通信によって確立されたコネクションを介して送信するフレームを作成する。フレームは、図４に示すように、８オクテットのフレームヘッダ５１と、０から６５５３５オクテットのフレームペイロード５２とにより構成されている。フレームペイロード５２の構造及び内容は、フレームタイプ（Ｔｙｐｅ）に応じて異なる。フレーム作成部２０４は、ＨＥＡＤＥＲＳフレーム（Ｔｙｐｅ＝０ｘ１）、ＳＥＴＴＩＮＧフレーム（Ｔｙｐｅ＝０ｘ４）、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム（Ｔｙｐｅ＝０ｘ５）、ＰＩＮＧフレーム（Ｔｙｐｅ＝０ｘ６）等のフレームを作成可能である。また、フレーム作成部２０４は、独自に定義した拡張フレームも作成可能である。フレーム受信部２０５は、通信装置３０が送信したフレームを受信する。フレーム解析部２０６は、フレーム受信部２０５が受信したフレームの種類（Ｔｙｐｅ）を解析する。フレーム送信部２０７は、フレーム作成部２０４が作成したフレームを送信する。
【００１６】
再利用要求作成部２０８は、ストリームＩＤの再利用を要求するためのフレームを作成する。本実施形態では、通信相手から応答が得られる方法でストリームＩＤの再利用を要求する。具体的には、ＰＩＮＧフレームを用い、ストリームＩＤの再利用を要求するオプションをＰＩＮＧフレームに書き込むことで、ストリームＩＤの再利用を要求する。ストリームＩＤの再利用要求を表すＰＩＮＧフレームのフォーマットについては後述する。
応答解析部２０９は、ストリームＩＤの再利用の要求に対する通信装置３０からの応答を解析する。本実施形態では、ストリームＩＤの再利用要求に対する応答にもＰＩＮＧフレームが用いられる。したがって、応答解析部２０９は、フレーム受信部２０５が受信した通信装置３０からの応答であるＰＩＮＧフレームを解析し、ＰＩＮＧフレームに書き込まれたオプションを確認する。再利用可否判断部２１０は、応答解析部２０９による解析結果をもとに、ストリームＩＤの再利用可否を判断する。具体的には、再利用可否判断部２１０は、通信装置３０から再利用を許可する応答を受信したか否かを判断する。
【００１７】
ストリームＩＤ管理部２１１は、ストリームＩＤの管理を行う。ストリームＩＤ管理部２１１は、フレーム作成部２０４によって新しいストリームを確立（開始）する際に、使用可能であるストリームＩＤをフレーム作成部２０４へ提供する。ストリーム処理部２１２は、ストリームの状態を、ｉｄｌｅ、ｏｐｅｎ、ｃｌｏｓｅｄなどの状態に遷移させる処理を行う。また、ストリーム処理部２１２は、ストリームＩＤを再利用したストリームの処理として、ストリームＩＤを再利用したストリームを確立可能な状態にする。具体的には、ストリーム処理部２１２は、ストリームＩＤを再利用して、コネクション上のすでに確立されたストリームを通信装置３０との通信が可能な状態に設定する。再利用要否判断部２１３は、ストリームＩＤの再利用が必要であるか否か（再利用するか否か）を判断する。
図３に示す各要素の機能は、図２で示したＣＰＵ２１が所定のプログラムを読み出して実行することにより、実現される。ただし、図３に示す各要素のうち、少なくとも一部の機能が専用のハードウェアによって実現されるようにしてもよい。その場合、当該専用のハードウェアは、ＣＰＵ２１の制御に基づいて動作する。
【００１８】
（通信装置３０の構成）
図５は、ストリームＩＤの再利用要求を受信する側である通信装置３０のモジュール構成を示す図である。通信装置３０は、通信制御部３０１と、表示制御部３０２と、接続確立部３０３と、フレーム作成部３０４と、フレーム受信部３０５と、フレーム解析部３０６と、フレーム送信部３０７と、を備える。さらに、通信装置３０は、応答作成部３０８と、要求解析部３０９と、ストリームＩＤ管理部３１１と、ストリーム処理部３１２と、要求判断部３１３と、を備える。これらの各モジュール３０１〜３１３は、バス３００によって接続されている。
【００１９】
モジュール３０１〜３０７は、図３に示す通信装置２０を構成するモジュール２０１〜２０７と同様の構成を有する。応答作成部３０８は、通信装置２０から送信されたストリームＩＤの再利用要求への応答を作成する。要求解析部３０９は、ストリームＩＤの再利用要求を解析する。ストリームＩＤ管理部３１１は、図３のストリームＩＤ管理部２１１と同様の構成を有する。ストリーム処理部３１２は、ストリームの状態を、ｉｄｌｅ、ｏｐｅｎ、ｃｌｏｓｅｄなどの状態に遷移させる処理を行う。また、ストリーム処理部３１２は、ストリームＩＤを再利用したストリームの処理として、ストリームＩＤを再利用したストリームを介してデータ（フレーム）の受信を可能な状態とする。要求判断部３１３は、フレーム受信部３０４が通信装置２０から受信したフレームが、ストリームＩＤの再利用要求を表すＰＩＮＧフレームであるか否かを判断する。
【００２０】
（通信装置２０の動作）
次に、ストリームＩＤの再利用を要求する側である通信装置２０の動作について、図６を参照しながら詳細に説明する。通信装置２０は、ＣＰＵ２１が所定のプログラムを読み出して実行することにより、図３で示す各要素の処理、及び、図６で示す各処理を実現する。ただし、図３で示す各要素のうち少なくとも一部が専用のハードウェアとして動作するようにしても良い。この場合、当該専用のハードウェアは、ＣＰＵ２１の制御に基づいて動作する。  先ずＳ１において、接続確立部２０３は、通信装置２０と通信装置３０との間のＨＴＴＰ／２によるコネクションを確立する。コネクションの確立には、プロトコルアップグレードや、コネクションプリフェイスの送受信が含まれる。次にＳ２において、フレーム作成部２０４は、ＨＥＡＤＥＲＳフレームを作成し、通信装置３０へ送信する。ＨＴＴＰ／２では、ＨＥＡＤＥＲＳフレームを送信することで、新しいストリームを確立する（ストリームをｏｐｅｎ状態にする）。このＳ２においては、フレーム作成部２０４は、新しいストリームを確立するために、ストリームＩＤ管理部２１１からストリームＩＤを１個取得し、ＨＥＡＤＥＲＳフレームを作成する。なお、図６に示す例では、ＨＥＡＤＥＲＳフレームを例として挙げているが、これに限らず、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームのように、新しいストリームＩＤを必要とするフレームを作成する場合にも、同様の処理を行う。
【００２１】
Ｓ３では、再利用要否判断部２１３は、ストリームＩＤの再利用が必要か否かを判断する。このように、新しいストリームＩＤを必要とするフレームを作成し送信した直後に、ストリームＩＤの再利用が必要か否かを判断する。そして、再利用要否判断部２１３は、ストリームＩＤの再利用が必要であると判断すると、Ｓ２において作成したＨＥＡＤＥＲＳフレームを通信装置３０に送信してからＳ４に移行する。一方、再利用要否判断部２１３が、ストリームＩＤの再利用は必要ないと判断した場合には、Ｓ２において作成したＨＥＡＤＥＲＳフレームを通信装置３０に送信してからＳ２に戻る。
【００２２】
ストリームＩＤの再利用が必要か否かを判断する方法としては、Ｓ２において使用したストリームＩＤが、使用可能であるストリームＩＤの最大値か否かを確認する方法を用いることができる。ＨＴＴＰ／２に従った通信を行う場合、通信装置は、新しく確立するストリームのストリームＩＤを、過去に確立したストリームのストリームＩＤよりも大きい値としなければならない。また、ストリームＩＤは、３１ビットの符号無し整数で管理されているため、２１億４７４８万３６４７（２31−１）までの値となる。さらに、ＨＴＴＰ／２サーバとＨＴＴＰ／２クライアントとでは、ストリームを確立するときに使用できるストリームＩＤの値が異なる。クライアントがストリームを確立する場合は奇数、サーバがストリームを確立する場合は偶数のストリームＩＤを使用可能である。
【００２３】
したがって、クライアントが使用可能であるストリームＩＤの最大値は、２１億４７４８万３６４７（２31−１）となり、サーバが使用可能であるストリームＩＤの最大値は、２１億４７４８万３６４６（２31−２）となる。再利用要否判断部２１３は、Ｓ２において使用したストリームＩＤと、使用可能であるストリームＩＤの最大値（２31−１）とを比較することで、ストリームＩＤの再利用が必要かを判断する。
なお、ストリームＩＤの再利用の要否を判断する方法は、ストリームＩＤの最大値を使用する方法に限定されない。再利用要否判断部２１３は、上記の最大値よりも小さい所定の閾値（例えば、２31−１００）を設定し、新たに確立したストリームのストリームＩＤの値が上記の所定の閾値を超えた場合に、ストリームＩＤの再利用が必要であると判断してもよい。なお、上記所定の閾値は、事前に通信装置３０と通信を行って決定してもよいし、通信装置２０内部に値を保持していてもよい。また、再利用要否判断部２１３は、コネクションの確立からある一定時間（例えば、１年間）が経過した場合に、ストリームＩＤの再利用が必要と判断してもよい。
【００２４】
Ｓ４では、フレーム作成部２０４は、ストリームＩＤの再利用要求を表すＰＩＮＧフレームを作成する。ＰＩＮＧフレームは、図４で示すように、フレームヘッダ５１とフレームペイロード５２とから構成され、フレームペイロード５２は、８オクテットのデータ（Ｏｐａｑｕｅ  Ｄａｔａ）を含む。
図６に戻って、Ｓ５では、再利用要求作成部２０８は、Ｓ４において作成したＰＩＮＧフレームのフレームヘッダ５１の各フィールドに値を書き込む。このＳ５において、再利用要求作成部２０８は、フレームヘッダ５１のＦｌａｇｓフィールドに、ストリームの再利用を要求するオプションを表すフラグ（再利用要求フラグ）を書き込む。
【００２５】
図７は、ストリームＩＤの再利用要求を表すＰＩＮＧフレームの一例である。図７に示すように、Ｌｅｎｇｔｈフィールドには、フレームのペイロードの長さを書き込む。ＰＩＮＧフレームの場合、Ｌｅｎｇｔｈフィールドには０ｘ８を書き込む。Ｔｙｐｅフィールドには、フレームの種類が書き込まれる。ＰＩＮＧフレームの場合、Ｔｙｐｅフィールドには０ｘ６を書き込む。Ｆｌａｇフィールドには、フレームに設定するフラグが書き込まれる。本実施形態では、このＦｌａｇフィールドに、ストリームＩＤの再利用要求を表すオプション（再利用要求フラグ）として、０ｘ２を書き込む。Ｒフィールドは、１ビットの予約ビットである。Ｒフィールドには、０ｘ０を書き込む。Ｓｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒフィールドには、ストリームＩＤが書き込まれる。ＰＩＮＧフレームの場合、Ｓｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒフィールドには、０ｘ０を書き込む。
なお、図７に示す例では、再利用要求フラグを０ｘ２としているが、これに限定されるものではなく、再利用要求フラグの値は通信装置間で適宜設定可能である。
【００２６】
また、ＰＩＮＧフレームは、上述したように、８オクテットのＯｐａｑｕｅ  Ｄａｔａをフレームペイロード５２として使用することができる。そこで、本実施形態では、このＯｐａｑｕｅ  Ｄａｔａ領域を使用して、再利用を要求するストリームＩＤを書き込む。ストリームの状態がｃｌｏｓｅｄである場合、そのストリーム上でデータ（フレーム）を送信することはできない。したがって、通信装置２０は、ストリームの状態がｃｌｏｓｅｄであるストリームのストリームＩＤの再利用を要求する。なお、ストリームの状態がｉｄｌｅ状態であるストリームのストリームＩＤを再利用要求してもよい。
【００２７】
図６のＳ６では、再利用要求作成部２０８は、図７に示すように、Ｏｐａｑｕｅ  Ｄａｔａ領域（フレームペイロード５２）の最初の４オクテットに、再利用を開始するストリームＩＤを書き込む。図７に示す例では、Ｓｔｒｅａｍ  ＩＤフィールドに０ｘ３を書き込むことで、ストリームＩＤの再利用を３から始めるように要求している。つまり、再利用要求作成部２０８は、再利用を要求するストリームＩＤの区間の最小値を、通信装置３０へ送信する。なお、本実施形態では、フレームヘッダ５１のＦｌａｇｓフィールドと、Ｏｐｑａｕｅ  Ｄａｔａ領域とを利用してストリームＩＤの再利用要求を行っているが、Ｆｌａｇｓフィールドだけを利用して、ストリームＩＤの再利用要求を行ってもよい。
【００２８】
図６のＳ７では、フレーム送信部２０７は、Ｓ４〜Ｓ６において作成したＰＩＮＧフレームを通信装置３０に送信する。次に、Ｓ８では、フレーム受信部２０５は、送信したＰＩＮＧフレームに対する応答を受信する。Ｓ９では、応答解析部２０９は、Ｓ８において受信した応答のフレームヘッダ５１を解析する。本実施形態では、通信装置３０がストリームＩＤの再利用に対応している場合、図８に示すように、ＰＩＮＧフレームの応答のＦｌａｇフィールドに、ストリームＩＤの再利用に対応していることを示す値（０ｘ５）が書き込まれる。なお、通信装置３０がストリームＩＤの再利用に対応している状態とは、通信装置３０がストリームＩＤの再利用を許可している状態のことをいう。また、ストリームＩＤの再利用に対応していることを示す値は、０ｘ５に限定されるものではなく、通信装置間で適宜設定可能である。
【００２９】
Ｓ９では、応答解析部２０９は、Ｓ８において受信したＰＩＮＧフレームのフレームヘッダ５１におけるＦｌａｇｓフィールドの値を解析する。次にＳ１０では、再利用可否判断部２１０は、Ｓ９における解析結果をもとに、通信装置３０がストリームＩＤの再利用に対応しているか否かを判断する。ＰＩＮＧフレームのＦｌａｇフィールドに０ｘ５が書き込まれていた場合、再利用可否判断部２１０は、通信装置２０がストリームＩＤの再利用に対応していると判断し、Ｓ１１に移行する。一方、ＰＩＮＧフレームのＦｌａｇフィールドに０ｘ５と異なる値が書き込まれていた場合には、再利用可否判断部２１０は、通信装置３０がストリームＩＤの再利用には対応していないと判断してＳ１３に移行する。
【００３０】
Ｓ１１では、応答解析部２０９は、ＰＩＮＧフレームの応答のＯｐａｑｕｅ  Ｄａｔａ領域を解析する。本実施形態では、通信装置３０がストリームＩＤの再利用に対応している場合、Ｏｐａｑｕｅ  Ｄａｔａ領域の最初の４オクテットには、通信装置３０が再利用を受け付ける先頭のストリームＩＤが書き込まれる。図８は、通信装置３０がストリームＩＤ＝３を、再利用を受け付ける先頭のストリームＩＤとして指定した例である。Ｓ１１では、応答解析部２０９は、Ｏｐａｑｕｅ  Ｄａｔａ領域を解析し、再利用を行うストリームＩＤを確認する。
【００３１】
次にＳ１２では、フレーム作成部２０４は、ストリームＩＤ管理部２１１に対してＳ１１において確認した、再利用するストリームＩＤを要求する。すると、ストリームＩＤ管理部２１１は、フレーム作成部２０４に対して、再利用するストリームＩＤを提供する。また、ストリーム処理部２１２は、ストリームＩＤを再利用したストリームを確立可能な状態にする。
また、Ｓ１３では、ストリームＩＤの再利用要求が許可されなかったとして、エラー処理を行う。エラー処理としては、再利用要求を再度送信してもよいし、接続中のコネクションを切断して新たなコネクションを接続してもよい。
【００３２】
このように、通信装置２０は、自装置が使用するストリームＩＤをもとに、ストリームＩＤを再利用するか否かを判断し、再利用すると判断した場合、通信相手の通信装置３０に対して、ストリームＩＤの再利用を要求する。また、通信装置２０は、ストリームＩＤを再利用すると判断した場合、コネクション上のすでに確立されたストリームを通信装置３０との通信が可能な状態に設定することで、ストリームＩＤを再利用したストリームを確立する。
本実施形態では、通信装置２０は、ストリームＩＤの再利用が必要であると判断し、ストリームＩＤの再利用の要求を送信すると、その要求に対する通信装置３０からの応答を待つ。そして、通信装置２０は、通信相手の通信装置３０からストリームＩＤの再利用を許可する応答を受信したとき、ストリームＩＤを再利用してストリームを確立する。このように、通信装置２０は、通信相手の通信装置３０がストリームＩＤの再利用に対応していることを確認してから、再利用したストリームＩＤを用いてストリームを確立することができる。
【００３３】
また、通信装置２０は、通信装置３０からのストリームＩＤの再利用の要求に対する応答として、再利用を許可するストリームＩＤの情報を受信したとき、再利用を許可されたストリームＩＤを再利用してストリームを確立する。したがって、確実に再利用が可能なストリームＩＤを用いてストリームを確立することができる。
また、通信装置２０は、すでに開始または予約したストリームＩＤが、使用可能な最大値に到達したとき、ストリームを使い切ったとして、ストリームＩＤの再利用が必要であると判断する。これにより、適切にストリームＩＤの再利用が必要な状態を検出し、ストリームＩＤを再利用することができる。
さらに、通信装置２０は、通信装置３０へストリームＩＤの再利用の要求を送信する際、再利用を要求するストリームＩＤの区間の最小値を送信する。このように、通信装置２０は、再利用を要求するストリームＩＤの情報を通信装置３０へ送信する。このとき、通信装置２０は、フレームを送ることができない状態であるストリームのストリームＩＤについて、再利用を要求する。これにより、ストリームの再利用を適切に行うことができる。
【００３４】
（通信装置３０の動作）
次に、ストリームＩＤの再利用要求を受信する側である通信装置３０の動作について、図９を参照しながら説明する。通信装置３０は、ＣＰＵ２１が所定のプログラムを読み出して実行することにより、図５で示す各要素の処理、及び、図９で示す各処理を実現する。ただし、図５で示す各要素のうち少なくとも一部が専用のハードウェアとして動作するようにしても良い。この場合、当該専用のハードウェアは、ＣＰＵ２１の制御に基づいて動作する。
【００３５】
先ずＳ２１において、接続確立部３０３は、通信装置３０と通信装置２０との間のＨＴＴＰ／２によるコネクションを確立する。コネクションの確立には、プロトコルアップグレードや、コネクションプリフェイスの送受信が含まれる。次にＳ２２において、フレーム解析部３０６は、フレーム受信部３０５が通信装置２０から受信したフレームが、ＰＩＮＧフレームであるか否かを判定する。そして、ＰＩＮＧフレームを受信していない場合はＳ２２の判定を繰り返し、ＰＩＮＧフレームを受信するとＳ２３に移行する。Ｓ２３では、要求解析部３０９は、Ｓ２２において受信したＰＩＮＧフレームのフレームヘッダ５１のＦｌａｇフィールドを解析する。
【００３６】
上述したように、通信装置２０が送信したＰＩＮＧフレームがストリームＩＤの再利用要求である場合、図７に示すように、Ｆｌａｇフィールドには再利用要求フラグとして０ｘ２が書き込まれている。そこで、Ｓ２４では、要求判断部３１３は、ＰＩＮＧフレームに再利用要求フラグが記述されているか否かを判定し、再利用要求フラグが記述されている場合には、受信したＰＩＮＧフレームがストリームＩＤの再利用要求であると判断し、Ｓ２５に移行する。一方、ＰＩＮＧフレームに再利用要求フラグが記述されていない場合には、Ｓ２４において、要求判断部３１３は、受信したＰＩＮＧフレームはストリームＩＤの再利用要求ではないと判断し、Ｓ２２に戻る。
【００３７】
Ｓ２５では、要求解析部３０９は、ＰＩＮＧフレームのＯｐａｑｕｅ  Ｄａｔａ領域を解析する。上述したように、ＰＩＮＧフレームがストリームＩＤの再利用要求である場合、Ｏｐａｑｕｅ  Ｄａｔａ領域には再利用を開始するストリームＩＤが書き込まれている。そこで、Ｓ２５では、要求解析部３０９は、Ｏｐａｑｕｅ  Ｄａｔａ領域から、再利用を開始するストリームＩＤを確認する。
次にＳ２６では、フレーム作成部３０４は、ＰＩＮＧフレームへの応答を作成する。Ｓ２７では、応答作成部３０８は、Ｓ２６において作成したＰＩＮＧフレームのフレームヘッダ５１におけるＦｌａｇフィールドに、再利用要求への応答を書き込む。本実施形態では、ストリームＩＤの再利用要求を許可する場合、再利用要求への応答として、図８に示すように、Ｆｌａｇフィールドに０ｘ５を書き込む。一方、ストリームＩＤの再利用要求を許可しない場合には、再利用要求への応答として、Ｆｌａｇフィールドに０ｘ５以外の値を書き込む。
【００３８】
次にＳ２８では、応答作成部３０８は、ＰＩＮＧフレームのＯｐａｑｕｅ  Ｄａｔａ領域に、ストリームＩＤの再利用を許可する先頭の値を書き込む。このＳ２８では、応答作成部３０８は、ｃｌｏｓｅｄ状態であるストリームのストリームＩＤを、再利用が可能であるストリームＩＤとしてＯｐａｑｕｅ  Ｄａｔａ領域に書き込む。通信装置３０は、ストリームの状態がｃｌｏｓｅｄであるストリームのストリームＩＤを再利用可能であるとする。なお、ストリームの状態がｉｄｌｅ状態であるストリームのストリームＩＤを再利用可能であるとしてもよい。
【００３９】
図８に示す例では、使用を許可するストリームＩＤの先頭の値として０ｘ３を書き込んでいる。使用を許可するストリームＩＤは、通信装置２０が再利用を要求しているストリームＩＤを優先して決定する。ところで、通信装置２０が０ｘ３を再利用するストリームＩＤとして要求してきた場合、０ｘ３をストリームＩＤとして使用したストリームの確立は許可できないが、０ｘ５以上の値をストリームＩＤとして使用したストリームの確立は許可できる場合がある。そのような場合には、応答作成部３０８は、ＰＩＮＧフレームのＯｐａｑｕｅ  Ｄａｔａ領域に、使用を許可するストリームＩＤの先頭の値として０ｘ５を書き込んでもよい。
【００４０】
なお、ストリーム処理部３１２がストリームを閉じる処理を行っているときに、通信装置２０がストリームＩＤを再利用してストリームを開こうとしてくる場合がある。この場合には、待機通知を送信することで該当ストリームのストリームＩＤを利用できないことを通知し、該当ストリームを閉じてから該当ストリームの確立を許可する応答をしてもよい。また、該当ストリームの確立を許可しない応答をしてもよい。
Ｓ２９では、フレーム送信部３０７は、Ｓ２６〜Ｓ２８において作成したＰＩＮＧフレームを通信装置２０へ送信する。次にＳ３０では、ストリーム処理部３１２は、再利用したストリーム上でのフレームの受信を開始する。
【００４１】
このように、通信装置３０は、通信相手の通信装置２０からストリームＩＤを再利用する要求を受信したとき、再利用を許可するか否かを判断する。そして、通信装置３０は、ストリームＩＤの再利用を許可すると判断したとき、ストリームＩＤを再利用したストリームを受信する。
本実施形態では、通信装置３０は、ストリームＩＤの再利用を許可するか否かを判断した後、その判断結果をストリームＩＤの再利用要求への応答として、通信装置２０へ返送する。これにより、通信装置２０は、通信装置３０がストリームＩＤの再利用に対応しているか否かを把握することができる。
また、通信装置３０は、通信装置２０からのストリームＩＤの再利用要求に対する応答として、自装置が受信可能なストリームＩＤを送信する。また、通信装置２０が再利用を要求しているストリームＩＤが受信可能な場合には、通信装置３０は、通信装置２０が再利用を要求しているストリームＩＤを優先して再利用を許可するようにする。これにより、再利用したストリームＩＤを用いたストリームの処理を適切に行うことができる。
【００４２】
なお、本実施形態では、通信装置２０の再利用要否判断部２１３は、ＨＥＡＤＥＲＳフレームなどの新しいストリームＩＤを必要とするフレームを作成し、送信した後にストリームＩＤの再利用が必要かを判断している。しかしながら、ストリームＩＤの再利用の要否を判断するタイミングは、新しいストリームＩＤを必要とするフレームを送信した後に限定されない。例えば、新しいストリームＩＤを必要とするフレームを作成する前に判断してもよいし、新しいストリームＩＤを必要とするフレームを作成した後、そのフレームを送信する前に判断してもよい。
また、本実施形態では、通信装置２０の再利用要求作成部２０８は、ＰＩＮＧフレームを利用してストリームＩＤの再利用要求を行っている。しかしながら、ストリームＩＤの再利用を要求する方法はこれに限定されない。例えば、ＳＥＴＴＩＮＧＳフレームや、拡張フレームを定義して、ストリームＩＤの再利用を要求してもよい。また、ストリームを閉じるときにフラグを設定して、閉じたストリームのＩＤが再利用可能であることを通知してもよい。ストリームＩＤを閉じるときにフラグを設定することで、閉じたストリームのＩＤをすぐに再利用できるという効果がある。
【００４３】
さらに、本実施形態では、通信装置３０は、通信装置２０からのストリームＩＤの再利用要求の応答として、通信装置２０へストリームＩＤの再利用に対応しているか否かを通知している。しかしながら、通信装置３０は、ストリームＩＤの再利用に対応しているか否かを、事前に通信装置２０へ通知してもよい。通信装置２０に対してストリームＩＤの再利用に対応していることを通知する方法として、ＰＩＮＧフレームやＳＥＴＴＴＩＮＧＳフレームを利用する方法が考えられる。また、その他にも独自のフレームを使用する方法が考えられるが、これらに限定されない。事前に通知をするタイミングは、ＨＴＴＰ／２通信の開始時とすることができるが、これに限定されない。
通信装置２０において、通信装置３０がストリームＩＤの再利用に対応していることを事前に確認できる場合には、通信装置２０は、ストリームＩＤの再利用要求を行った後、通信装置３０からの応答を待たずにストリームＩＤの再利用を開始することができる。その結果、新しいストリームを確立するまでの期間を短縮することができる。
【００４４】
さらに、上記のように通信装置２０が、ストリームＩＤの再利用要求の送信後、ストリームＩＤの再利用要求への応答を待たずにストリームＩＤの再利用を開始する場合、通信装置３０は以下の処理が可能である。つまり、通信装置３０は、再利用要求がされたストリームが使用されていない状態であれば、そのストリームを受信してもよいし、ストリームＩＤの再利用を許可する応答を送信してから、そのストリームを受信してもよい。なお、ストリームが使用されていない状態として、ｃｌｏｓｅｄ状態が考えられるが、これに限定されない。
【００４５】
また、本実施形態では、通信装置２０がストリームＩＤの再利用を要求するとき、ストリームＩＤの再利用を開始する先頭のストリームＩＤを要求しているが、これに限定されない。例えば、再利用を要求するストリームＩＤ１つを要求してもよいし、ストリームＩＤを再利用する区間の最小値と最大値とを要求してもよい。さらに、再利用を要求する複数のストリームＩＤをリストで送信してもよい。
また、本実施形態では、通信装置３０がストリームＩＤの再利用を許可するとき、ストリームＩＤの再利用の開始を許可する先頭のストリームＩＤを送信しているが、これに限定されない。例えば、再利用を要求するストリームＩＤ１つを通知してもよいし、ストリームＩＤの再利用を許可する区間の最小値と最大値とを通知してもよい。さらに、再利用を許可する複数のストリームＩＤをリストで通知してもよい。また、再利用を許可しないストリームＩＤを通知してもよい。
【００４６】
図１０に示すように、ストリームＩＤ＝１，３，９がｏｐｅｎ状態、ストリームＩＤ＝５，７，１１，１３がｃｌｏｓｅｄ状態であるときに、通信装置２０が新たなストリームを確立するためにストリームＩＤの再利用が必要である場合を考える。この図１０に示す状態では、ストリームＩＤ＝５，７，１１，１３の再利用が可能である。そこで、通信装置２０がストリームＩＤの再利用を開始するＩＤとして５を要求し、通信装置３０が要求を許可すると、ストリームＩＤ＝５から再利用が開始される。しかしながら、この場合、ストリームＩＤ＝５，７を再利用した後にストリームＩＤ＝９を再利用しようとするとエラーになってしまう。一方、通信装置２０が再利用を開始するストリームＩＤとして１１を要求すると、エラーにはならないが、ストリームＩＤ＝５，７は再利用できなくなってしまう。
【００４７】
上記のような場合に、ストリームＩＤ１つを要求する方法を用いると、ストリームＩＤ＝５，７，１１，１３全てを再利用することができる。また、ストリームＩＤを再利用する区間の最小値と最大値を要求する方法を用いると、ストリームＩＤを１つずつ指定する方法よりも、通信装置間のやり取りの回数を削減することができる。
図１０に示す状態から、ストリームＩＤ＝５，７，１１，１３のストリームの再利用を開始すると、ストリームＩＤの状態は図１１に示すように全てｏｐｅｎ状態となる。そして、図１１に示す状態から、ストリームＩＤ＝５，７のストリームの再利用を終えると、ストリームＩＤ＝５，７の状態は、図１２に示すようにｃｌｏｓｅｄ状態となる。この場合、通信装置２０は、ストリームＩＤ＝５からストリームＩＤ＝７までの区間を再利用する要求を送信して、ストリームＩＤの再利用を繰り返すことができる。なお、図８〜図１０ではストリームＩＤ＝１３までを示しているが、ストリームＩＤ＝１５以降についても同様である。
【００４８】
さらに、本実施形態では、通信装置２０の再利用要否判断部２１３において、ストリームＩＤの再利用が必要かどうかを判断しているが、通信装置３０が、通信装置２０側のストリームＩＤの再利用が必要かどうかを判断してもよい。この場合、通信装置２０は、通信相手の通信装置３０から、ストリームＩＤの再利用が必要であることを示す通知を受信する。この通知を受信したとき、通信装置２０は、ストリームＩＤの再利用が必要であると判断し、通信装置３０に対してストリームＩＤを再利用することを示す応答を送信する。そして、通信装置２０は、応答を送信した後、ストリームＩＤの再利用を開始する。このように、通信装置２０と通信装置３０の両方により、ストリームＩＤの再利用が必要であるか否かを判断してもよい。
【００４９】
図１３は、通信装置２０がストリームＩＤの再利用を要求し、通信装置３０が再利用要求に対して応答する場合の、通信装置２０と通信装置３０との間のメッセージのやり取りを示すシーケンス図である。
先ずＳ１０１において、通信装置２０と通信装置３０との間のＨＴＴＰ／２によるコネクションが確立される。コネクションの確立には、プロトコルアップグレードや、コネクションプリフェイスの送受信が含まれる。Ｓ１０２では、通信装置２０と通信装置３０との間で、ＨＴＴＰ／２通信が行われる。本シーケンス図では、通信装置２０は、Ｓ１０２において２１億４７４８万３６４５（２31−３）までのストリームＩＤを使用したこととする。
【００５０】
次に、通信装置２０のフレーム作成部２０４は、新しいストリームを確立するために、ストリームＩＤ管理部２１１からストリームＩＤを１個取得し、Ｓ１０３においてＨＥＡＤＥＲＳフレームを作成する（図６のＳ２）。このＳ１０３において取得されるストリームＩＤは、２１億４７４８万３６４７（２31−１）である。次に、Ｓ１０４では、通信装置２０のフレーム送信部２０７が通信装置３０へＨＥＡＤＥＲＳフレームを送信する。また、このとき通信装置３０のフレーム受信部３０５は、通信装置２０から送信されたＨＥＡＤＥＲＳフレームを受信する。
ＨＥＡＤＥＲＳフレームの作成に使用したストリームＩＤは、通信装置２０において使用可能なストリームＩＤの最大値である。したがって、Ｓ１０５において、通信装置２０の再利用要否判断部２１３は、ストリームＩＤの再利用が必要であると判断する（図６のＳ３）。
【００５１】
すると、通信装置２０のフレーム作成部２０４は、Ｓ１０６において、ストリームＩＤの再利用を要求するためのＰＩＮＧフレームを作成する（図６のＳ４）。そして、再利用要求作成部２０８は、Ｓ１０７において、ＰＩＮＧフレームのフレームヘッダ５１におけるＦｌａｇｓフィールドに、再利用要求フラグとして０ｘ２を書き込む（図６のＳ５）。また、再利用要求作成部２０８は、Ｓ１０８において、ＰＩＮＧフレームのＯｐａｑｕｅ  Ｄａｔａ領域に、ストリームＩＤの再利用を開始するＩＤを書き込む（図６のＳ６）。再利用を開始するストリームＩＤとして３を要求する場合、Ｏｐａｑｕｅ  Ｄａｔａ領域には０ｘ３が書き込まれる。そして、フレーム送信部２０７は、Ｓ１０９において、ストリームＩＤの再利用要求が書き込まれたＰＩＮＧフレームを通信装置３０へ送信する（図６のＳ７）。このときフレーム受信部３０５は、ストリームＩＤの再利用要求が書き込まれたＰＩＮＧフレームを通信装置２０から受信する（図９のＳ２４でＹｅｓ）。
【００５２】
通信装置３０は、ＰＩＮＧフレームを受信すると、Ｓ１１０において、フレーム作成部３０４によってＰＩＮＧフレームへの応答を作成する（図９のＳ２６）。通信装置２０が再利用を要求しているストリームＩＤ＝３がｃｌｏｓｅｄ状態である場合、ストリームＩＤ＝３は再利用可能な状態である。そのため、この場合、応答作成部３０８は、Ｓ１１１において、ストリームＩＤの再利用要求を許可するオプションとして、０ｘ５をＰＩＮＧフレームのフレームヘッダ５１のＦｌａｇｓフィールドに書き込む。（図９のＳ２７）。また、応答作成部３０８は、Ｓ１１２において、ＰＩＮＧフレームのＯｐａｑｕｅ  Ｄａｔａ領域に、再利用を許可するストリームＩＤの先頭の値として０ｘ３を書き込む（図９のＳ２８）。そして、フレーム送信部３０７は、Ｓ１１３において、ストリームＩＤの再利用の許可を応答するＰＩＮＧフレームを通信装置２０へ送信する（図９のＳ２９）。また、ストリーム処理部３１２は、Ｓ１１４において、ストリームＩＤを再利用したストリーム上でのフレームの受信を開始する。一方、通信装置２０のフレーム受信部２０５は、通信装置３０から送信されたＰＩＮＧフレームの応答を受信する（図６のＳ８）。
【００５３】
通信装置２０は、通信装置３０からＰＩＮＧフレームの応答を受信すると、応答解析部２０９において、通信装置３０から受信したＰＩＮＧフレームを解析する（図６のＳ９）。通信装置３０が送信したＰＩＮＧフレームの応答におけるフレームヘッダ５１のＦｌａｇｓフィールドには、ストリームＩＤの再利用要求を許可する０ｘ５が書き込まれている。そのため、再利用可否判断部２１０は、Ｓ１１５において、ストリームＩＤの再利用が可能であると判断する（図６のＳ１０でＹｅｓ）。また、応答解析部２０９は、通信装置３０から受信したＰＩＮＧフレームのＯｐａｑｕｅ  Ｄａｔａ領域を解析し、再利用が許可されたストリームＩＤを確認する（図６のＳ１１）。
そして、フレーム作成部２０４は、Ｓ１１６において、ストリームＩＤを再利用してＨＥＡＤＥＲＳフレームを作成する（図６のＳ２）。このとき、ストリームＩＤ＝３を再利用する。次にＳ１１７では、通信装置２０のフレーム送信部２０７は、Ｓ１１６において作成したＨＥＡＤＥＲＳフレームを送信し、通信装置３０のフレーム受信部３０５は、ＨＥＡＤＥＲＳフレームを受信する。また、通信装置３０のストリーム処理部３１２は、Ｓ１１８において、ストリームＩＤを再利用したストリームを開く（ｏｐｅｎ状態にする）。
【００５４】
以上説明したように、本実施形態によれば、ストリームＩＤを再利用することができる。ストリームＩＤは、必ずしも連番で利用するわけではないため、実際に割り振られているストリームＩＤの個数よりも少ない数しか利用できず、使い切る可能性が高い。また、長時間の接続によってストリームＩＤの使用可能な範囲を超えてしまう場合もある。従来の通信システムにおいては、ストリームＩＤを使い切った場合、新しいストリームを確立するためには、一度コネクションを切断し、新しいコネクションを接続する必要があった。
これに対して、本実施形態では、ストリームＩＤを使い切った状態から新しいストリームを確立する場合には、通信相手に対してストリームＩＤの再利用要求を行う。そして、通信相手が再利用を許可した場合、ストリームＩＤを再利用してストリームを確立する。
【００５５】
ストリームＩＤの再利用を可能とすることで、コネクションの切断を行わずに通信相手と通信が可能な状態のストリームを確立することができる。その結果、コネクションの切断と新しいコネクションの接続にかかる時間を削減することができる。
このように、通信装置２０は、コネクションの切断を行わずに、通信可能状態であるストリームを確立することができる。そのため、通信装置２０が監視カメラである場合、コネクションの再接続の間に不審者が通過するというイベントが発生した場合には、即時に通信装置３０に対して不審者が通過したことを通知することができる。したがって、リクエストを発行できない期間を低減することができる。
また、コネクションの切断と新しいコネクションの接続には、ネットワークの処理負荷がかかるが、コネクションを接続しなおす必要がないため、上記のネットワークの処理負荷を軽減することができる。
【００５６】
（変形例）
上記実施形態においては、通信プロトコルとしてＨＴＴＰ／２を例に挙げて説明したが、これに限定されるものではなく、ＳＰＤＹ（スピーディー）、ＱＵＩＣ（Quick UDP Internet Connections）であってもよい。また、１つのコネクション上で複数のストリームを処理する他のプロトコルにも適用可能である。
また、上記実施形態においては、通信システム１０を監視カメラシステムに適用し、通信装置２０をカメラ、通信装置３０をＰＣとする場合について説明したが、これに限定されない。例えば、通信装置は、プリンタ、ＤＶＣ（Digital Video Cassette）、プロジェクタ、医療機器、映像事務機、ブラウザ、スマートデバイスのアプリ、クラウドサービスにも適用可能である。
【００５７】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００５８】
１０…通信システム、２０…通信装置、３０…通信装置、４０…ネットワーク、２０８…再利用要求作成部、２０９…応答解析部、２１０…再利用可否判断部、２１１…ストリームＩＤ管理部、２１２…ストリーム処理部、２１３…再利用要否判断部、３０８…応答作成部、３０９…解析部、３１１…ストリームＩＤ管理部、３１２…ストリーム処理部、３１３…判断部
【図１】
2017011641.tif 000003
【図２】
2017011641.tif 000004
【図３】
2017011641.tif 000005
【図４】
2017011641.tif 000006
【図５】
2017011641.tif 000007
【図６】
2017011641.tif 000008
【図７】
2017011641.tif 000009
【図８】
2017011641.tif 000010
【図９】
2017011641.tif 000011
【図１０】
2017011641.tif 000012
【図１１】
2017011641.tif 000013
【図１２】
2017011641.tif 000014
【図１３】
2017011641.tif 000015