(57)【要約】【課題】  通信装置と他の通信装置との間の論理的な接続が切断する場合に、一方の通信装置からの要求に応じた処理が他方の通信装置により完了されたか否かを、当該一方の通信装置が判断できるようになる。【解決手段】  通信装置１は、通信装置２との間のコネクションを介して、通信装置２からの要求を受信する。また通信装置１は、受信された要求に応じた処理が完了していない状態においてコネクションを切断することを決定した後に、要求に応じた処理を継続して実行する。そして通信装置１は、要求に応じた処理を完了させる場合に、当該処理の完了を示す情報を通信装置２へ送信する。さらに通信装置１は、当該情報が通信装置２へ送信された後に、コネクションの切断処理を実行する。【選択図】  図６
2019068244.tif 000002
【特許請求の範囲】
【請求項１】
通信装置であって、
前記通信装置と他の通信装置との間の論理的な接続を介して、前記他の通信装置からの要求を受信する受信手段と、
前記論理的な接続を切断することを決定する決定手段と、
前記受信手段により受信された要求に応じた処理が完了していない状態において前記決定手段により前記論理的な接続を切断することが決定された後に、前記要求に応じた処理を継続して実行する実行手段と、
前記実行手段により前記要求に応じた処理が完了される場合に、当該処理の完了を示す情報を前記他の通信装置へ送信する送信手段と、
前記送信手段により前記情報が前記他の通信装置へ送信された後に、前記論理的な接続の切断処理を実行する切断手段とを有することを特徴とする通信装置。
【請求項２】
前記受信手段により受信された要求に応じた処理が完了していない状態において前記決定手段により前記論理的な接続を切断することが決定された場合に、前記要求に応じた処理を中断するか継続するかを判断する判断手段を有し、
前記実行手段は、前記要求に応じた処理を継続することが前記判断手段により判断された場合に、前記要求に応じた処理を継続して実行することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記送信手段は、前記判断手段により前記要求に応じた処理を中断すると判断された場合と、前記実行手段により前記要求に応じた処理が完了される場合とで、異なる情報を前記他の通信装置へ送信することを特徴とする請求項２に記載の通信装置。
【請求項４】
前記受信手段は、前記論理的な接続としての第１接続に基づいて複数確立可能な論理的な接続である第２接続を使用して、前記他の通信装置からの要求を受信することを特徴とする請求項１乃至３の何れか１項に記載の通信装置。
【請求項５】
前記受信手段は、前記論理的な接続としての第１接続に基づいて複数確立可能な論理的な接続である第２接続を使用して、前記他の通信装置からの要求を受信し、
前記送信手段は、前記判断手段により前記要求に応じた処理を中断すると判断された場合に、前記受信手段により前記要求の受信に使用される第２接続のエラーを示す情報を送信することを特徴とする請求項３に記載の通信装置。
【請求項６】
前記受信手段は、前記論理的な接続としての第１接続に基づいて複数確立可能な論理的な接続である第２接続を使用して、前記他の通信装置からの要求を受信し、
前記送信手段は、前記実行手段により前記要求に応じた処理が完了される場合に、当該処理の完了を示す情報として、前記受信手段により第２接続を使用して受信された前記要求に応じて前記通信装置から前記他の通信装置へ送信されるデータであって当該第２接続において送信される最後のデータを表す情報を送信することを特徴とする請求項１乃至３の何れか１項に記載の通信装置。
【請求項７】
前記判断手段は、前記受信手段により受信された要求の種別に基づいて、前記要求に応じた処理を中断するか継続するかを判断することを特徴とする請求項２又は３に記載の通信装置。
【請求項８】
前記判断手段は、前記受信手段により受信された要求が前記通信装置の状態の変化を伴う処理に関する要求であるか否かに基づいて、前記要求に応じた処理を中断するか継続するかを判断することを特徴とする請求項２又は３に記載の通信装置。
【請求項９】
前記判断手段は、前記受信手段により受信された要求に応じた処理が完了していない状態において前記決定手段により前記論理的な接続を切断することが決定された場合に、前記要求が冪等であれば前記要求を中断すると判断し、前記要求が冪等でなければ、前記論理的な接続を継続可能な期間の長さに基づいて、前記要求を中断するか継続するかを判断することを特徴とする請求項２又は３に記載の通信装置。
【請求項１０】
前記判断手段は、前記受信手段による前記他の通信装置からの要求の受信に使用される第２接続に設定された優先度に基づいて、前記要求に応じた処理を中断するか継続するかを判断することを特徴とする請求項２又は３に記載の通信装置。
【請求項１１】
前記判断手段は、前記受信手段により受信された要求に応じた処理の完了までに要する時間の長さに基づいて、前記要求に応じた処理を中断するか継続するかを判断することを特徴とする請求項２又は３に記載の通信装置。
【請求項１２】
前記第１接続及び前記第２接続は、それぞれＨＴＴＰ／２において規定されるコネクション及びストリームであることを特徴とする請求項４乃至６の何れか１項に記載の通信装置。
【請求項１３】
前記送信手段は、前記判断手段により前記要求に応じた処理を中断すると判断された場合には、ＨＴＴＰ／２において規定されるＲＳＴ＿ＳＴＲＥＡＭフレームを送信し、前記判断手段により前記要求に応じた処理を継続すると判断された場合には、ＨＴＴＰ／２において規定されるＥＮＤ＿ＳＴＲＥＡＭフラグが設定されたフレームを送信し、
前記切断手段により実行される前記切断処理は、ＨＴＴＰ／２において規定されるＧＯＡＷＡＹフレームの送信を含むことを特徴とする請求項３に記載の通信装置。
【請求項１４】
第１通信装置と第２通信装置とを有する通信システムにより実行される通信方法であって、
前記第１通信装置と前記第２通信装置との間の論理的な接続を介して、前記第１通信装置が前記第２通信装置からの要求を受信する受信工程と、
前記論理的な接続を切断することを決定する決定工程と、
前記受信工程において受信された要求に応じた処理が完了していない状態において前記決定工程において前記論理的な接続を切断することが決定された後に、前記要求に応じた処理を継続して実行する実行工程と、
前記実行工程において前記要求に応じた処理が完了される場合に、当該処理の完了を示す情報を、前記第１通信装置から前記第２通信装置へ送信する送信工程と、
前記送信工程において前記情報が前記第２通信装置へ送信された後に、前記論理的な接続の切断処理を実行する切断工程とを有することを特徴とする通信方法。
【請求項１５】
前記受信工程においては、前記論理的な接続としての第１接続に基づいて複数確立可能な論理的な接続である第２接続を使用して、前記第１通信装置が前記第２通信装置からの要求を受信することを特徴とする請求項１４に記載の通信方法。
【請求項１６】
前記受信工程において受信された要求に応じた処理が完了していない状態において前記決定工程において前記論理的な接続を切断することが決定された場合に、前記要求に応じた処理を中断するか継続するかを判断する判断工程を有し、
前記実行工程においては、前記要求に応じた処理を継続することが前記判断工程において判断された場合に、前記要求に応じた処理が継続して実行され、
前記送信工程においては、前記判断工程において前記要求に応じた処理を中断すると判断された場合と、前記実行工程において前記要求に応じた処理が完了される場合とで異なる情報が、前記第１通信装置から前記第２通信装置へ送信されることを特徴とする請求項１４又は１５に記載の通信方法。
【請求項１７】
コンピュータを、請求項１乃至１３の何れか１項に記載の通信装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、論理的な接続を介して通信を行うための技術に関する。
【背景技術】
【０００２】
ネットワーク上でのサービス提供形態の一つとして、サーバーが論理的な接続であるコネクションを介してクライアントから送信された要求を受け付け、要求に応じたサービスを提供するものがある。このようなサービス提供形態においては、サーバーが要求に応じたサービスの提供を完了した場合にコネクションが切断される。一方、例えばサーバーやネットワークの負荷が増大した場合などには、サービスの提供が完了していなくてもコネクションが切断されることがある。
【０００３】
特許文献１には、サーバーからコンテンツを受信している機器がネットワークから切断された場合に、切断直前までのサービス利用により発生する課金情報を処理するために、課金処理を行う機器と中継装置との間の接続を継続させることが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第３８９５７２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来技術では、通信装置と他の通信装置との間の論理的な接続が切断された場合に、一方の通信装置からの要求に応じた処理が他方の通信装置により完了されたか否かを、当該一方の通信装置が判断できない場合がある。例えば、サーバーで行われるべき処理の要求がクライアントから送信された直後に、サーバーの都合により前触れなく接続が切断された場合、サーバーが要求に対する処理を継続して完了させたか中断したかを、クライアントは知ることができない。
【０００６】
本発明は上記課題に鑑み、通信装置と他の通信装置との間の論理的な接続が切断される場合に、一方の通信装置からの要求に応じた処理が他方の通信装置により完了されたか否かを、当該一方の通信装置が判断できるようにすることを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決するため、本発明に係る通信装置は、前記通信装置と他の通信装置との間の論理的な接続を介して、前記他の通信装置からの要求を受信する受信手段と、前記論理的な接続を切断することを決定する決定手段と、前記受信手段により受信された要求に応じた処理が完了していない状態において前記決定手段により前記論理的な接続を切断することが決定された後に、前記要求に応じた処理を継続して実行する実行手段と、前記実行手段により前記要求に応じた処理が完了される場合に、当該処理の完了を示す情報を前記他の通信装置へ送信する送信手段と、前記送信手段により前記情報が前記他の通信装置へ送信された後に、前記論理的な接続の切断処理を実行する切断手段とを有する。
【発明の効果】
【０００８】
本発明によれば、通信装置と他の通信装置との間の論理的な接続が切断される場合に、一方の通信装置からの要求に応じた処理が他方の通信装置により完了されたか否かを、当該一方の装置が判断できるようになる。
【図面の簡単な説明】
【０００９】
【図１】通信システム１０の構成例を示す図である。
【図２】通信装置１のハードウェア構成例を示す図である。
【図３】通信装置１のプログラムモジュール構成例を示す図である。
【図４】ＨＴＴＰ／２に従う通信の基本動作を説明するためのシーケンス図である。
【図５】実施形態に係るトランザクションの経過について説明するための図である。
【図６】通信装置１と通信装置２の動作について説明するためのシーケンス図である。
【図７】通信装置１によるリクエスト解析処理について説明するためのフローチャートである。
【図８】実施形態に係るリクエストメッセージについて説明するための図である。
【図９】実施形態に係るストリーム情報について説明するための図である。
【図１０】通信装置１によるコネクション制御処理について説明するためのフローチャートである。
【図１１】通信装置１によるストリーム制御処理について説明するためのフローチャートである。
【図１２】通信装置１によるストリーム制御処理について説明するためのフローチャートである。
【発明を実施するための形態】
【００１０】
＜システム構成＞
本実施形態における通信装置１及び通信装置２を含む通信システム１０の構成を図１に示す。図１において、通信装置１はネットワーク３を介して通信装置２と接続している。本実施形態では、通信装置２が通信装置１にサービスの要求を行い、通信装置１が通信装置２にサービスを提供する。すなわち、通信装置１はサーバーとして機能し、通信装置２はクライアントとして機能する。なお、通信装置１は複数のクライアントと接続され、それぞれのクライアントに対してサービスを提供してもよい。以下では、サービスを提供する機器（本実施形態では通信装置１）をサーバーと呼び、サービスを利用する機器（本実施形態では通信装置２）をクライアントと呼ぶ。
【００１１】
本実施形態では、通信装置１及び通信装置２がスマートフォンであるものとして説明するが、通信装置１や通信装置２の機能を実装する機器の形態はこれに限らない。例えば、通信装置１及び通信装置２は、ＰＣ、携帯電話、デジタルカメラ、デジタルビデオカメラ、プリンター、ネットワークストレージ、及びルーター等のネットワーク接続機器であってもよい。通信装置１と通信装置２とが異なる形態の機器に実装されていてもよい。
【００１２】
ネットワーク３は、有線の通信路、無線の通信路、又はその組み合わせにより構成される。具体的には、ＩＥＥＥ８０２．１１に則った無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）や、有線ＬＡＮ、インターネット、及び電話用の公衆回線などにより構成される。ネットワーク３内には、ネットワークスイッチやルーターなどの中継装置が含まれていてもよい。
【００１３】
＜通信装置の構成＞
次に、本実施形態における通信装置１（サーバー）のハードウェア構成例を図２に示す。なお、通信装置２（クライアント）のハードウェア構成も通信装置１と同様である。通信装置１は、ＣＰＵ２０１、メモリ２０２、操作部２０３、及び通信インターフェース２０４を有し、これらの構成要素がバス２０５を介して接続されている。
【００１４】
ＣＰＵ２０１は演算装置であり、メモリ２０２に格納されている後述のプログラムモジュールを読みだして実行することで、通信装置１の全体を制御する。なお、通信装置１がＣＰＵ２０１とは異なる専用の１又は複数のハードウェアやＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）を有し、ＣＰＵ２０１による処理の少なくとも一部をＧＰＵや専用のハードウェアが行ってもよい。専用のハードウェアの例としては、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）、及びＤＳＰ（デジタルシグナルプロセッサ）などがある。
【００１５】
メモリ２０２は、プログラムやパラメータを記憶するＲＯＭやＲＡＭ、画像や音声データなどのコンテンツデータを記憶する補助記憶装置などから構成される。操作部２０３は、ユーザーが通信装置１を操作するためのインターフェースである。操作部２０３は例えば、タッチパネルやディスプレイ、キーボード、及びマウスなどにより構成される。通信インターフェース２０４は、ネットワーク３と接続してクライアントとの通信を可能とする。通信装置１が無線で通信を行う場合には、通信インターフェース２０４はアンテナなどを備え、通信装置１が有線で通信を行う場合には、通信インターフェース２０４はケーブルを接続するポートなどを備える。
【００１６】
次に、通信装置１のメモリ２０２に記憶されるプログラムのモジュール構成を図３に示す。通信装置１は、プログラムモジュールとして、プロトコル処理モジュール３０１、サービスモジュール３０２、ストリーム制御モジュール３０３、及びリクエスト完了判定モジュール３０４を有する。これらのプログラムモジュールが読みだされてＣＰＵ２０１により実行されることで、後述の各フローチャートに従った機能が実現される。なお、ＣＰＵ２０１を用いたソフトウェア処理の代替としてハードウェアによる処理を行う場合には、通信装置１はここで説明する各モジュールに対応する演算部や回路を備えていればよい。また、通信装置１が上記のモジュールすべてを備えることは必須でない。
【００１７】
プロトコル処理モジュール３０１は、ネットワーク３を介してサービスを提供するための通信機能を実現するプログラムモジュールである。本実施形態におけるプロトコル処理モジュール３０１は、ＩＥＴＦ（Ｉｎｅｔｎｅｔ  Ｅｎｇｅｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）によって規格が定義されている通信技術であるＨＴＴＰ／２（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ２）に則ってクライアントと通信を行う機能を実現する。ただし、プロトコル処理モジュール３０１は、例えばＨＴＴＰ１．１やＳＰＤＹ等、ＨＴＴＰ／２以外の方式に則った通信を行う機能を実現するモジュールであってもよい。
【００１８】
サービスモジュール３０２は、プロトコル処理モジュール３０１の機能を利用して、サービスを提供する機能を実現するプログラムモジュールである。サービスモジュール３０２には、クライアントからの要求に応じて以下の動作を実現する機能が含まれる。その動作とは、例えば、メモリ２０２に格納したデータをクライアントに提供する動作、クライアントから指定されたデータをメモリ２０２から削除する動作、および、クライアントからデータを受信しメモリ２０２に格納する動作である。ストリーム制御モジュール３０３は、プロトコル処理モジュール３０１の動作を制御する機能を実現するプログラムモジュールである。ストリーム制御モジュール３０３の詳細は後述する。リクエスト完了判定モジュール３０４は、クライアントからのサービス要求に応じた処理が完了しているか否かを判定する機能を実現するプログラムモジュールである。
【００１９】
通信装置２のメモリ２０２に記憶されるプログラムモジュール構成は、ストリーム制御モジュール３０３が含まれないこと、および、サービスモジュール３０２が有する機能が一部異なることを除いて、通信装置１と同様である。なお、通信装置１と通信装置２は、本実施形態で示す通信装置１の機能と通信装置２の機能の両方を備えていてもよい。すなわち、通信装置１と通信装置２はサーバーとクライアントの何れとして機能することもできる構成であってもよい。
【００２０】
通信装置２のサービスモジュール３０２は、通信装置２のプロトコル処理モジュール３０１の機能を利用して、通信装置１により提供されるサービスを利用する機能を実現するプログラムモジュールである。通信装置２のサービスモジュール３０２には、ユーザーによる操作に応じて、サーバーにサービスを要求する動作を実現する機能が含まれる。サービスを要求する動作とは、例えば、通信装置２のメモリ２０２に格納済みのデータをサーバーに格納させる動作、サーバーに格納されているデータの削除を要求する動作、サーバーからデータを受信して通信装置２のメモリ２０２に格納する動作などである。また、サービスモジュール３０２には、上記の動作をユーザーが指示するためのユーザーインターフェースを提供する機能も含まれる。
【００２１】
＜ＨＴＴＰ／２の基本動作＞
本実施形態の通信システム１０は、サーバーとクライアントとの間で、サービスを要求する通信と、要求に対する応答を返すための通信を、先述のＨＴＴＰ／２の規格に則り実行する。本実施形態では、その機能を、通信装置１と通信装置２それぞれのプロトコル処理モジュール３０１が実現する。
【００２２】
本実施形態のサーバー（通信装置１）に対して、本実施形態のクライアント（通信装置２）がサービスを要求し利用する動作の例を、図４に示すシーケンス図を用いて説明する。まずＭ４０１において、サーバーとクライアントは、クライアントからの要求を契機に、ＨＴＴＰ／２の規定に則ったコネクション確立処理を実行する。サーバーとクライアントとの間で確立されるコネクションは、サーバーとクライアントが通信を行うための論理的な接続であり、トランスポート層におけるプロトコルに応じた制御により実現される。トランスポート層におけるプロトコルとしては、本実施形態ではＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）が用いられるものとする。ただしこれに限らず、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）などが用いられてもよい。
【００２３】
ＨＴＴＰ／２のコネクションを確立したのちに、Ｍ４０２においてクライアントは、サービスの要求をＨＴＴＰ／２リクエスト（以降、「リクエスト」と呼ぶ）としてサーバーに送信する。Ｍ４０２におけるリクエストを受信したサーバーは、Ｍ４０３において、そのリクエストに対する応答をＨＴＴＰ／２レスポンス（以降「レスポンス」と呼ぶ）としてクライアントへ送信する。
【００２４】
クライアントからの要求およびそれに対するサーバーからの応答の通信が完了すると、Ｍ４０４においてサーバーおよびクライアントは、Ｍ４０１で確立したコネクションを切断する処理を実行する。ここで、リクエストとレスポンスの組であるトランザクション（図４の例では、Ｍ４０２とＭ４０３との組であるトランザクション４０５）は、Ｍ４０１で確立したサーバーとクライアントのコネクションの中で複数行うことができる。その場合、コネクションにおけるすべてのトランザクション（要求および応答）が完了したのちに、Ｍ４０４におけるコネクションの切断処理が実行される。
【００２５】
＜ＨＴＴＰ／２のストリーム＞
ＨＴＴＰ／２の通信においては、１つのコネクションに基づいて論理的な接続であるストリームを複数確立可能であり、それぞれのストリームにおいて独立したシーケンスで通信が行われる。例えば、１つのトランザクションに１つのストリームが関連付けられる。サーバーとクライアントは、通信されるデータに付与される識別子を用いて、そのデータの通信に用いられるストリームを識別できる。なお、サーバーとクライアントとの間で複数のコネクションを確立し、コネクションごとに複数のストリームを確立することもできる。
【００２６】
各ストリームの状態には、次のものがある。利用開始前（確立前）を意味する「ｉｄｌｅ」状態。利用中（確立済み）を意味する「ｏｐｅｎ」状態。サーバーおよびクライアントの双方からの通信が終了したことを意味する「ｃｌｏｓｅｄ」状態。サーバーもしくはクライアントのどちらか一方からの通信が終了したことを意味する「ｈａｌｆ  ｃｌｏｓｅｄ」状態。これらの状態は、ストリームに関連付けられているトランザクションにおける通信の進行状態に応じて発生する。
【００２７】
＜ＨＴＴＰ／２コネクションの切断＞
ＨＴＴＰ／２では、コネクションの切断処理として、ＧＯＡＷＡＹフレームの送信が行われる。ＧＯＡＷＡＹフレームは、サーバー又はクライアントが、ＧＯＡＷＡＹフレームの送信に使用した対象のコネクションに基づく新たなストリームを確立しないことを示す情報である。ＧＯＡＷＡＹフレームには、対象のコネクションにおいて最後に確立された（ＩＤＬＥ状態から他の状態に遷移させた）ストリームの識別子情報が含まれる。
【００２８】
＜通信システム１０の動作例＞
本実施形態に係る通信システム１０におけるトランザクションの経過の例を、図５を用いて説明する。図５は、トランザクションの開始タイミング及び生存期間を図示したものである。図５において、横軸５９は時間経過を示す。横軸５９の右側に行くほど時間が経過することを示している。時刻ｔｐ５１から時刻ｔｐ５５は、後述する各イベントが発生するタイミングを示している。
【００２９】
時刻ｔｐ５１では、通信装置２から通信装置１に対して、データの送信を要求する第１のリクエスト（ＧＥＴリクエスト）が送信され、通信装置１から通信装置２に対してデータの送信が開始される。時刻ｔｐ５２では、通信装置２から通信装置１に対して、別のデータの送信を要求する第２のリクエスト（ＧＥＴリクエスト）が送信され、通信装置１から通信装置２に対してデータの送信が開始される。時刻ｔｐ５３では、時刻ｔｐ５１で送信された第１のリクエストに対する応答としてのデータ送信が終わり、レスポンスが完了する。時刻ｔｐ５４では、通信装置２から通信装置１に対して、通信装置２から送信されるデータを通信装置１に格納させる第３のリクエスト（ＰＯＳＴリクエスト）が送信され、通信装置２から通信装置１に対してデータの送信が開始される。
【００３０】
時刻ｔｐ５５では、通信装置１において、通信装置２との間のコネクションを切断すべき事象が発生する。この事象は、例えば、通信装置１が接続するネットワークの切り替えが必要になるという事象や、通信装置１が通信装置２に提供するサービスよりも優先度の高い他の処理を開始したという事象、及び通信装置１のバッテリーが低下したという事象などである。また例えば、通信装置１は、コネクションを切断させるための操作をユーザーから受け付けたことに応じて、通信装置２との間のコネクションを切断することを決定してもよい。
【００３１】
線分５６は、第１のリクエストを含むトランザクションの生存期間を示す。トランザクションの生存期間は、リクエストの送信からレスポンスの完了までの期間であり、通信に使用されるストリームの確立から切断までの期間に対応する。線分５７は、第２のリクエストを含むトランザクションの生存期間を示す。線分５８は、第３のリクエストを含むトランザクションの生存期間を示す。
【００３２】
第２のリクエストおよび第３のリクエストを含むトランザクションは、時刻ｔｐ５５の時点では完了していない。ここで、仮に時刻ｔｐ５５において通信装置１から一方的にコネクションが切断されてしまった場合、通信装置２は、リクエストに応じた処理が通信装置１により完了されたか否かを判断することができない。具体的には、第３のリクエストに応じて通信装置２から通信装置１へデータが送信されているが、送信されたデータの通信装置１への格納が完了したことを示すレスポンスが行われる前にコネクションが切断されてしまう。そのため、通信装置２は送信したデータが通信装置１に正しく格納されたか否かを判断できない。そこで、本実施形態における通信装置１は、コネクションを切断する際に後述のストリーム制御を行う。この制御により、通信装置２は、通信装置２からの要求に応じた処理が通信装置１により完了されたか否かを判断できるようになる。
【００３３】
図５に示したトランザクションに対応する、通信装置１と通信装置２との間で送信されるメッセージのシーケンスを、図６のシーケンス図に示す。以降、図６等を参照しながら、通信装置２からの要求に応じた通信装置１の処理が完結したか否かを通信装置２が判断できるようにするための通信システム１０の動作について説明する。図６に示す処理は、通信装置１との接続を開始するためのユーザーによる操作を通信装置２が受け付けたタイミングで開始される。ただし、図６の処理の開始タイミングは上記タイミングに限定されない。
【００３４】
まずＭ６０１において、通信装置１および通信装置２がＨＴＴＰ／２のコネクションを確立する。次にＭ６０２（図５の時刻ｔｐ５１に対応）において、通信装置２から通信装置１に対して、通信装置１が保持しているデータの提供の要求がＨＴＴＰ／２のＧＥＴリクエストとして送信される。具体的には、通信装置２のサービスモジュール３０２が、データ要求を行うためのユーザーインターフェースを操作部２０３のディスプレイによりユーザー（通信装置２の利用者）に提示する。ユーザーは、操作部２０３のキーボードを用いてサービスを提供する機器である通信装置１の識別情報、および、要求するデータの識別情報を入力する。操作部２０３がユーザーから受け付けた入力に基づいて取得される情報を用いて、プロトコル処理モジュール３０１が、ＨＴＴＰ／２リクエストを通信装置１に送信する。通信装置２がＭ６０２で送信するデータには、データ送信の要求であることを示す情報、および、要求するデータの識別情報が含まれる。ＨＴＴＰ／２のリクエストおよびレスポンスのデータ形式は先述のＨＴＴＰ／２の規格に従う。
【００３５】
通信装置１は、Ｍ６０２において、通信装置２との間のコネクションを介して、通信装置２からのリクエストを受信する。そして通信装置１は、プロトコル処理モジュール３０１によりＨＴＴＰ／２の規格に従ったリクエスト処理を実行するほか、受信したリクエストメッセージをストリーム制御モジュール３０３に渡す。リクエストメッセージを受け取った通信装置１のストリーム制御モジュール３０３は、図７のフローチャートに示すリクエスト解析処理を実行する。ここで図７のフローチャートについて説明する。
【００３６】
まずＳ７１において、通信装置１は、通信装置２から受信したリクエストメッセージから、リクエストメソッドを特定する。ここでリクエストメソッドとは、データの送信要求やデータの削除要求などの、クライアントからの要求の種別を示す情報である。Ｍ６０２において通信装置１が受信するリクエストメッセージの一部の例を図８に示す。メッセージ８１はリクエスト識別部８３を含み、リクエスト識別部８３には、リクエストメソッドを示す文字列８２が含まれる。Ｓ７１の処理は、図８の例においてはメッセージ８１から文字列８２を抽出する処理である。Ｍ６０２において通信装置１が受信する第１のリクエストのリクエストメソッドは「ＧＥＴ」であり、先述のとおり、通信装置２が通信装置１に対して、データの提供を要求するものである。
【００３７】
次にＳ７２では、通信装置１が、Ｓ７１で特定したリクエストメソッドと、Ｍ６０２で使用されたストリームの識別子、ストリーム状態の情報、および、リクエストの処理状況の情報とを関連付けたストリーム情報を、メモリ２０２に記憶する。Ｓ７２において記憶されたストリーム情報の例を図９（ａ）に示す。
【００３８】
テーブル９０１において、行９０６は、Ｍ６０２で受信されるリクエストに関連する一連のストリーム情報である。列９０２には、リクエストに関連付けられるストリームの識別子が格納される。列９０３には、ストリーム状態の情報が格納される。列９０４には、Ｓ７１で抽出されたリクエストメソッドの情報が格納される。列９０５には、リクエストの処理状況の情報が格納される。リクエストの処理状況は、次のふたつの状態のいずれかである。第１の状態は「完了」状態である。完了状態は、リクエストに応じた処理が完了しており、もはやそのリクエストについての通信が発生しないことを意味する状態である。第２の状態は「処理中」状態である。これは、リクエストに応じた処理が完了しておらず、まだそのリクエストに関する通信が発生しうること、すなわち通信が完了していないことを意味する状態である。
【００３９】
個別のストリーム情報（テーブル９０１の各行の情報）は、対応するストリームがｃｌｏｓｅｄ状態に遷移してから所定の時間経過の後に、ストリーム制御モジュール３０３により削除される。また、ストリーム制御モジュール３０３は、ストリーム状態、および、リクエストの処理状況を監視し、変化があった場合には、ストリーム情報を更新する。なお、列９０２に格納されるストリームの識別子は、ＨＴＴＰ／２の規格に従ってプロトコル処理モジュール３０１が割り当てる数値である。
【００４０】
図６の説明に戻る。通信装置１は、Ｍ６０２におけるリクエストの受信後、通信装置２宛てに第１のリクエストメッセージで指定されたデータの送信を開始する。次に、Ｍ６０３（図５の時刻ｔｐ５２に対応）で、通信装置２から通信装置１に対して、第２のリクエストが送信される。Ｍ６０３において第２のリクエストを受信した通信装置１のストリーム制御モジュール３０３は、Ｍ６０２における第１のリクエストの受信時と同様のリクエスト解析処理を実行する。第２のリクエストのリクエストメソッドは「ＧＥＴ」であり、先述のとおり、通信装置２が通信装置１に対して、データの提供を要求するものである。通信装置１は、Ｍ６０３におけるリクエストの受信後、通信装置２宛てに第２のリクエストメッセージで指定されたデータの送信を開始する。
【００４１】
次に、Ｍ６０４（図５の時刻ｔｐ５３に対応）では、第１のリクエストに応じた処理としての、通信装置１から通信装置２に向けたデータの送信が終了する。Ｍ６０４において送信されるデータには、第１のリクエストに対する通信装置１からのデータ送信を終了することを示す情報が含まれる。データ送信を終了することを示すメッセージとは、具体的には、「ＥＮＤ＿ＳＴＲＥＡＭ」フラグを立てたＤＡＴＡフレームのことである。フラグの意味およびデータ形式等の通信仕様はＨＴＴＰ／２の規定に従う。
【００４２】
次に、Ｍ６０５（図５の時刻ｔｐ５４に対応）で、通信装置２から通信装置１に対して、通信装置２から送信するデータを通信装置１に格納させる第３のリクエストが送信される。Ｍ６０４において第３のリクエストを受信した通信装置１のストリーム制御モジュール３０３は、Ｍ６０２における第１のリクエストの受信時と同様のリクエスト解析処理を実行する。第３のリクエストのリクエストメソッドは「ＰＯＳＴ」であり、先述のとおり、通信装置２から通信装置１へデータを送信（アップロード）するものである。通信装置２は、Ｍ６０５においてリクエストを送信したのちに、通信装置１宛てに通信装置２のメモリ２０２に記憶しているデータの送信を開始する。
【００４３】
なお、通信装置１はＭ６０２、Ｍ６０３及びＭ６０５において通信装置２からの要求を受信するが、これらの要求はそれぞれ異なるストリームを使用して受信される。また、Ｍ６０２における通信とＭ６０４における通信のような、リクエストの送信とそれに対する応答の送信には、同じストリームが使用される。
【００４４】
Ｍ６０５における処理が行われた時点における、通信装置１が管理するストリーム情報を図９（ｂ）のテーブル９０７に示す。行９１２は第１のリクエストに関する情報である。行９１３は第２のリクエストに関する情報である。行９１４は第３のリクエストに関する情報である。
【００４５】
次に、Ｍ６０６（図５の時刻ｔｐ５５に対応）では、通信装置１がコネクションを切断すべき事象の発生を検出し、通信装置２との間のコネクションを切断することを決定する。そしてＭ６０７において、通信装置１のストリーム制御モジュール３０３は、実行すべきコネクション制御処理の内容を決定する。そして通信装置１は、決定した内容に応じて、Ｍ６０８からＭ６１１においてコネクション制御処理を実行する。コネクション制御処理の内容の決定及びその実行の詳細を、図１０のフローチャートを用いて説明する。
【００４６】
図１０のフローチャートは、通信装置１がＭ６０６においてコネクションを切断することを決定したタイミングで開始される。まずＳ１００１において、通信装置１は、メモリ２０２に格納しているストリーム情報におけるリクエストの処理状況（図９（ａ）の列９０５）を参照する。そしてＳ１００２において、通信装置１は、処理中のリクエストに関連付けられたストリームがあるか否かを判定する。
【００４７】
リクエスト処理中のストリームがある場合（Ｓ１００２でＹＥＳの場合）は、Ｓ１００３においてストリーム制御処理を実行する。ストリーム制御処理の詳細は後述する。Ｓ１００３の処理が完了すると、通信装置１は、最後に確立したストリームの識別子情報を含むＧＯＡＷＡＹフレームを送信する。一方、リクエスト処理中のストリームがない場合（Ｓ１００２でＮＯの場合）は、ストリーム制御を行わずに、Ｓ１００４においてＧＯＡＷＡＹフレームの送信を実行する。図１０の処理が終了すると、通信装置１は通信装置２との間のコネクションを切断する。
【００４８】
ここで、Ｓ１００３におけるストリーム制御処理の詳細を、図１１のフローチャートを用いて説明する。図１１の処理は、リクエスト処理中のストリームが複数ある場合には、それらのストリームのそれぞれについて実行される。まずＳ１１０１において、通信装置１は、格納されているストリーム情報を参照し、処理中ストリームのリクエストメソッドを特定する。次にＳ１１０２において、通信装置１は、リクエストメソッドが冪等でないかを判定する。本実施形態において、冪等でないリクエストメソッドとは、そのリクエストを処理したことによりサーバー側の状態（サーバーが保有するデータの内容など）が変化するものを言う。具体的には、「ＰＵＴ」、「ＰＯＳＴ」、および、「ＤＥＬＥＴＥ」のいずれかに該当するリクエストメソッドが、冪等でないと判断される。一方、「ＧＥＴ」のリクエストメソッドは、冪等であると判断される。
【００４９】
リクエストメソッドが冪等でない場合（Ｓ１１０２でＹＥＳの場合）は、Ｓ１１０３において通信装置１は、そのリクエストに応じた処理の実行を継続する。次に、Ｓ１１０４において通信装置１は、Ｓ１１０３で実行した処理が正常に完了したか否かを判定する。なお、Ｓ１１０４の処理は、Ｍ６０７におけるコネクション切断の決定から所定期間が経過した時点で行われてもよい。すなわち、Ｓ１１０４において通信装置１は、所定期間が経過した時点においてリクエストに応じた処理が完了しているか否かを判定してもよい。この場合の所定期間は、予め固定的に設定されていてもよいし、例えば、コネクション切断の決定の要因となった事象の種別や、リクエストの種別、及び設定されたストリームの優先度などに基づいて決定されてもよい。
【００５０】
リクエストに応じた処理が正常に完了した場合（Ｓ１１０４でＹＥＳの場合）は、通信装置１はＳ１１０５において、「ＥＮＤ＿ＳＴＲＥＡＭ」フラグが設定されたフレームを送信する。一方、リクエストに応じた処理が正常に完了しなかった場合（Ｓ１１０４でＮＯの場合）は、通信装置１はリクエストに応じた処理を中断し、Ｓ１１０６において「ＲＳＴ＿ＳＴＲＥＡＭ」フレームを送信する。また、Ｓ１１０２においてリクエストメソッドが冪等である場合（Ｓ１１０２でＮＯの場合）も同様に、Ｓ１１０６において「ＲＳＴ＿ＳＴＲＥＡＭ」フレームを送信する。
【００５１】
ここで、「ＥＮＤ＿ＳＴＲＥＡＭ」フラグが設定されたフレームは、リクエストに対する応答として送信されるデータの一部であって、当該フレームの送信に使用されるストリームにおいて通信装置１が送信する最後のデータであることを表す。すなわちこのフレームは、リクエストに応じた処理が正常に終了したことをクライアントに通知する意味を持つ。また、「ＲＳＴ＿ＳＴＲＥＡＭ」フレームは、当該フレームの送信に使用されるストリームがエラー終了することをクライアントに通知する意味を持つ。すなわちこのフレームは、通信装置１が要求の受信に使用したストリームのエラーを示す情報であり、言い換えると、通信装置１が受信した要求に関連付けられるエラー通知である。
【００５２】
以上で説明したストリーム制御処理をまとめると、以下のような動作となる。すなわち、通信装置１は、通信装置２から受信したリクエストに応じた処理が完了していない状態においてコネクションを切断することを決定した場合に、リクエストに応じた処理を中断するか完了させるかを判断する。そして通信装置１は、リクエストに応じた処理を中断すると判断した場合には、ＲＳＴ＿ＳＴＲＥＡＭフレームを通信装置２へ送信する。一方、リクエストに応じた処理を完了させると判断した場合には、処理を継続してＥＮＤ＿ＳＴＲＥＡＭフラグが設定されたフレームを送信する。このように、通信装置１から送信されるＲＳＴ＿ＳＴＲＥＡＭフレーム及びＥＮＤ＿ＳＴＲＥＡＭフラグが設定されたフレームは、リクエストに応じた処理を中断するか完了させるかについての通信装置１による判断の結果に応じた情報である。
【００５３】
なお、上記の説明では、通信装置１は受信したリクエストが冪等であるか否かに基づいて、リクエストに応じた処理を中断するか完了させるかを判断するものとした。通信装置１は、リクエストが冪等であればリクエストに応じた処理を中断してストリームをエラー終了させることで、リクエストをすべて完了させる場合よりも早くコネクションを切断させることができる。一方、リクエストが冪等でない場合には、リクエストに応じた処理を進める間に通信装置１の状態が変化し、処理を中断した場合に通信装置２が通信装置１の状態を判断しづらくなるため、リクエストが冪等である場合よりも処理の中断を避ける必要性が高い。そこで通信装置１は、リクエストが冪等でなければ処理を完了させてから通信装置２に通知を行うことで、通信装置２が通信装置１の状態を判断できるようにすることができる。
【００５４】
図１１で説明したストリーム制御処理及び図１０で説明したコネクション制御処理の流れを図６に沿って説明すると、以下のようになる。まず、Ｍ６０６（図５の時刻ｔｐ５５に対応）の時点で通信装置１に格納されているストリーム情報は図９（ｂ）のテーブル９０７の状態であり、列９１１の行９１３および行９１４に示されているように、リクエスト処理中のストリームが存在する。そこで通信装置１は、これらのストリームについてストリーム制御処理を実行する。
【００５５】
行９１３に対応する第２のリクエストについては、リクエストメソッドが「ＧＥＴ」であるため、冪等であると判断され、Ｍ６０８において通信装置１は「ＲＳＴ＿ＳＴＲＥＡＭ」フレームを送信する。一方、行９１４に対応する第３のリクエストについては、リクエストメソッドが「ＰＯＳＴ」であるため、冪等でないと判断され、Ｍ６０９において通信装置１は「ＥＮＤ＿ＳＴＲＥＡＭ」フラグが設定されたフレームを送信する。
【００５６】
そして通信装置１は、確立済みの各ストリームにおいてＲＳＴ＿ＳＴＲＥＡＭフレーム又はＥＮＤ＿ＳＴＲＥＡＭフラグが設定されたフレームが通信装置２へ送信された後に、Ｍ６１０においてコネクションの切断処理としてＧＯＡＷＡＹフレームの送信を行う。これに応じて、Ｍ６１１において通信装置２もＧＯＡＷＡＹフレームを送信する。ＧＯＡＷＡＹフレームが通信装置１と通信装置２の双方から送信されたのち、Ｍ６１２において、ＴＣＰにおけるコネクション切断処理が実行される。これにより、図６に示す通信装置１と通信装置２との通信が終了する。
【００５７】
なお、図１１を用いて上述したストリーム制御処理においては、リクエストに応じた処理を完了させるか中断するかが、リクエストメソッドが冪等であるか否かに基づいて判断されるものとした。ただし、リクエストに応じた処理を完了させるか中断するかの判断基準は、これに限らない。例えば通信装置１は、リクエストの種別に基づく判断を、上記の冪等性とは異なる基準で行ってもよい。具体的には、通信装置１は、「ＧＥＴ」、「ＰＵＴ」、及び「ＤＥＬＥＴＥ」のリクエストに応じた処理は中断し、「ＰＯＳＴ」リクエストに応じた処理は完了させるようにしてもよい。また例えば、通信装置１は、リクエストの受信に使用したストリームに設定された優先度に基づいて、当該リクエストに応じた処理を完了させるか中断するかを判断してもよい。また例えば、通信装置１は、リクエストに応じた処理の完了までに要する時間を推定し、推定された残りの処理時間が閾値以上であるか否かに基づいて、当該リクエストに応じた処理を完了させるか中断するかを判断してもよい。この方法によれば、コネクションを切断することが決定されてから実際にコネクションが切断されるまでの時間が長くなりすぎることを抑制できる。
【００５８】
さらに、通信装置１は、コネクションを切断することを決定した際、コネクションを継続可能な期間の長さに基づいて、リクエストに応じた処理を中断するかを判断してもよい。以下ではこの場合の処理について説明する。
【００５９】
図１０のＳ１００３におけるストリーム制御処理において、図１２のフローチャートに示す処理が実行される。Ｓ１２０１において、通信装置１は、コネクションの切断をただちに行う必要があるか否かを判定する。コネクションをただちに切断する必要がある場合とは、コネクションを継続可能な期間が閾値未満である場合であり、例えば、通信装置１に異常が発生した場合や、ただちに通信を切断することがユーザー操作により指示された場合などである。一方、通信装置１のバッテリー残量が閾値以下になった場合や、通信装置１の負荷が所定値以上となった場合などには、コネクションをただちに切断する必要がないと判定されてもよい。
【００６０】
コネクションをただちに切断する必要がある場合（Ｓ１２０１でＹＥＳの場合）、Ｓ１２０２において通信装置１は、リクエスト処理中のストリームすべてにおいて「ＲＳＴ＿ＳＴＲＥＡＭ」フレームを送信する。一方、コネクションをただちに切断する必要がない場合（Ｓ１２０１でＮＯの場合）は、通信装置１はＳ１２０３において個別ストリーム対応処理を実行する。ここで行われる個別ストリーム処理の内容は、図１１のフローチャートに示す処理であり、すでに説明したものと同様である。以上のように、通信装置１がコネクションを継続可能な期間の長さに基づく判断を行うことで、状況に応じて、通信装置１における処理の完了についての通信装置２による正確な判断よりも、コネクションの切断を優先させることができる。
【００６１】
以上説明したように、本実施形態における通信装置１は、通信装置２との間のコネクションを介して、通信装置２からの要求を受信する。また通信装置１は、受信された要求に応じた処理が完了していない状態においてコネクションを切断することを決定した場合に、要求に応じた処理を中断するか完了させるかを判断する。そして通信装置１は、要求に応じた処理を中断すると判断した場合と、要求に応じた処理を完了させると判断した場合とで、異なる情報を通信装置２へ送信する。さらに通信装置１は、当該情報が通信装置２へ送信された後に、コネクションの切断処理を実行する。
【００６２】
上記のような構成によれば、通信装置２と通信装置１との間のコネクションが切断される場合に、通信装置２からの要求に応じた処理が通信装置１により完了されたか否かを、通信装置２が判断できるようになる。
【００６３】
なお、本実施形態においては、サーバーがコネクションを切断することをサーバー側の要因に基づいて決定するものとしたが、これに限らない。例えば、クライアントがコネクションの切断要求をサーバーに送信し、切断要求を受け取ったサーバーがコネクションを切断することを決定して、必要に応じて上述したストリーム制御処理を行ってもよい。
【００６４】
また本実施形態では、通信装置１が、通信装置２からの要求に応じた処理を中断する場合と完了させる場合の両方において、通信装置２に対して通知を行うものとした。ただしこれに限らず、通信装置１は、要求に応じた処理を中断すると判断した場合と、要求に応じた処理を完了させると判断した場合との、何れか一方において、通信装置２への通知を行ってもよい。例えば、通信装置１は、要求に応じた処理を中断する場合には通信装置２に対して通知を行い、要求に応じた処理を完了させる場合には通信装置２に対する通知を行わずに、コネクションを切断してもよい。また逆に、通信装置１は、要求に応じた処理を中断する場合には通信装置２に対して通知を行わず、要求に応じた処理を完了させる場合には通信装置２に対する通知を行って、コネクションを切断してもよい。これらの方法によっても、通信装置２と通信装置１との間のコネクションが切断される場合に、通信装置２からの要求に応じた処理が通信装置１により完了されたか否かを通信装置２が判断することができる。ただし、通信装置１からの通知がネットワークの問題などにより通信装置２へ届かないことがある場合などにおいては、通信装置１が要求に応じた処理を中断する場合と完了させる場合の両方において通知を行う方が、通信装置２はより正確な判断を行える。
【００６５】
また本実施形態では、通信装置１が、リクエストに応じた処理を中断するか完了させるかの判断や、判断に応じた通信装置２に対する通知の送信処理を、ストリーム単位で行う場合について説明した。これにより、通信装置２は、どのストリームにおける要求に応じた処理が完了されて、どのストリームにおける要求に応じた処理が完了されていないかを、詳細に判断することができるようになる。ただしこれに限らず、通信装置１は、リクエストに応じた処理を中断するか完了させるかの判断や、判断に応じた通信装置２に対する通知の送信処理を、コネクション単位で行ってもよい。この方法によれば、通信装置１と通信装置２との間の通信量を削減することができる。また通信装置１は、例えば通信装置１の処理負荷や通信相手の機器に応じて、上記の判断及び通知をストリーム単位で行うかコネクション単位で行うかを切り替え可能であってもよい。
【００６６】
また、本実施形態ではＨＴＴＰ／２に従う通信が行われる場合を中心に説明したが、通信の方式はこれに限らない。上述の説明において通信装置１が送信するものとしたＲＳＴ＿ＳＴＲＥＡＭフレームやＥＮＤ＿ＳＴＲＥＡＭフラグが設定されたフレーム、及びＧＯＡＷＡＹフレームなども、同様の機能を実現可能な別のデータで代替可能である。
【００６７】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ等）によっても実現可能である。また、そのプログラムをコンピュータにより読み取り可能な記録媒体に記録して提供してもよい。
【符号の説明】
【００６８】
１  通信装置
２  通信装置
３  ネットワーク
１０  通信システム
【図１】
2019068244.tif 000003
【図２】
2019068244.tif 000004
【図３】
2019068244.tif 000005
【図４】
2019068244.tif 000006
【図５】
2019068244.tif 000007
【図６】
2019068244.tif 000008
【図７】
2019068244.tif 000009
【図８】
2019068244.tif 000010
【図９】
2019068244.tif 000011
【図１０】
2019068244.tif 000012
【図１１】
2019068244.tif 000013
【図１２】
2019068244.tif 000014