(57)【要約】【課題】ＨＴＴＰ処理が強制終了されることに起因するリソースの無駄を低減する。【解決手段】通信装置は、他の通信装置からリクエストを受信し、当該他の通信装置にリクエストに対するレスポンスを送信する、ＨＴＴＰによるデータ通信を行う。通信装置は、データ通信中に、当該データ通信のキャンセル要求を受けた場合、データ通信に関する所定の条件を満たしている場合には、データ通信が完了した後にデータ通信を終了させる終了処理を実行し、所定の条件を満たしていない場合には、データ通信が完了する前に終了処理を実行する。【選択図】      図９
2020102089.tif 000002
【特許請求の範囲】
【請求項１】
通信装置であって、
他の通信装置からリクエストを受信し、当該他の通信装置に前記リクエストに対するレスポンスを送信する、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）によるデータ通信を行う通信手段と、
前記通信手段によるデータ通信を終了させる終了処理を実行可能な終了手段と、
前記通信手段によるデータ通信中に、当該データ通信のキャンセル要求を受けた場合、前記データ通信に関する所定の条件を満たしている場合には、前記通信手段による前記データ通信が完了した後に前記終了手段に終了処理を実行させ、前記所定の条件を満たしていない場合には、前記通信手段による前記データ通信が完了する前に前記終了手段に終了処理を実行させる制御手段と、を備えることを特徴とする通信装置。
【請求項２】
前記通信手段は、前記レスポンスの送信を分割して行うことが可能であり、
前記所定の条件は、
前記キャンセル要求を受けた際に前記通信手段によって送信中のレスポンスに続く分割されたレスポンスが存在しないことを含むことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記通信手段は、前記リクエストの受信を分割して行うことが可能であり、
前記所定の条件は、
前記キャンセル要求を受けた際に前記通信手段によって受信中のリクエストに続く分割されたリクエストが存在しないことを含むことを特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記所定の条件は、
前記通信手段による前記レスポンスの送信中に前記キャンセル要求を受けた場合、送信済みのレスポンスのサイズの合計が閾値以上であることを含むことを特徴とする請求項１から３のいずれか１項に記載の通信装置。
【請求項５】
前記所定の条件は、
前記通信手段による前記リクエストの受信中に前記キャンセル要求を受けた場合、受信済みのリクエストのサイズの合計が閾値以上であることを含むことを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
前記所定の条件は、
前記通信手段による前記レスポンスの送信中に前記キャンセル要求を受けた場合、前記レスポンスの送信を開始してからの経過時間が閾値以上であることを含むことを特徴とする請求項１から５のいずれか１項に記載の通信装置。
【請求項７】
前記所定の条件は、
前記通信手段による前記リクエストの受信中に前記キャンセル要求を受けた場合、前記リクエストの受信を開始してからの経過時間が閾値以上であることを含むことを特徴とする請求項１から６のいずれか１項に記載の通信装置。
【請求項８】
前記所定の条件は、
前記通信手段による前記レスポンスの送信中に前記キャンセル要求を受けた場合、当該キャンセル要求を受けてから送信済みのレスポンスのサイズの合計が閾値以上であることを含むことを特徴とする請求項１から７のいずれか１項に記載の通信装置。
【請求項９】
前記所定の条件は、
前記通信手段による前記リクエストの受信中に前記キャンセル要求を受けた場合、当該キャンセル要求を受けてから受信済みのリクエストのサイズの合計が閾値以上であることを含むことを特徴とする請求項１から８のいずれか１項に記載の通信装置。
【請求項１０】
前記所定の条件は、
前記キャンセル要求を受けてからの経過時間が閾値以上であること含むことを特徴とする請求項１から９のいずれか１項に記載の通信装置。
【請求項１１】
前記所定の条件は、
前記通信手段によるデータの再送待ちでないことを含むことを特徴とする請求項１から１０のいずれか１項に記載の通信装置。
【請求項１２】
前記所定の条件は、
前記通信手段により受信された前記リクエストの種類を含むことを特徴とする請求項１から１１のいずれか１項に記載の通信装置。
【請求項１３】
第一の通信装置と第二の通信装置とを備える通信システムであって、
前記第一の通信装置は、
前記第二の通信装置からリクエストを受信し、前記第二の通信装置に前記リクエストに対するレスポンスを送信する、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）によるデータ通信を行う第一の通信手段と、
前記第一の通信手段によるデータ通信を終了させる終了処理を実行可能な終了手段と、
前記第一の通信手段によるデータ通信中に、当該データ通信のキャンセル要求を受けた場合、前記データ通信に関する所定の条件を満たしている場合には、前記第一の通信手段による前記データ通信が完了した後に前記終了手段に終了処理を実行させ、前記所定の条件を満たしていない場合には、前記第一の通信手段による前記データ通信が完了する前に前記終了手段に終了処理を実行させる第一の制御手段と、を備え、
前記第二の通信装置は、
前記第一の通信装置にリクエストを送信し、前記第一の通信装置から前記リクエストに対するレスポンスを受信する、ＨＴＴＰによるデータ通信を行う第二の通信手段を備え、
前記第一の通信装置および前記第二の通信装置の少なくとも一方は、
前記第一の制御手段が前記第一の通信手段による前記データ通信が完了する前に前記終了手段に終了処理を実行させた場合、終了された前記データ通信の内容を記憶する記憶手段と、
前記記憶手段により記憶された内容に基づいて、前記終了された前記データ通信の続きから前記データ通信を行わせる第二の制御手段と、をさらに備えることを特徴とする通信システム。
【請求項１４】
通信装置の制御方法であって、
他の通信装置からリクエストを受信し、当該他の通信装置に前記リクエストに対するレスポンスを送信する、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）によるデータ通信を行うステップと、
前記データ通信中に、当該データ通信のキャンセル要求を受けた場合、前記データ通信に関する所定の条件を満たしている場合には、前記データ通信が完了した後に前記データ通信を終了させる終了処理を実行し、前記所定の条件を満たしていない場合には、前記データ通信が完了する前に終了処理を実行するステップと、を含むことを特徴とする制御方法。
【請求項１５】
コンピュータを、請求項１から１２のいずれか１項に記載された通信装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＨＴＴＰによるデータ通信を行う通信装置、通信装置の制御方法およびプログラムに関する。
【背景技術】
【０００２】
近年、ウェブの発展により、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いた技術がしばしば利用されるようになっている。また、ＲＥＳＴ（ＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）の原則に則って構築されたＷｅｂシステムのＨＴＴＰでの呼び出しインタフェースである、ＲＥＳＴｆｕｌ  ＡＰＩという概念が知られている。ＲＥＳＴｆｕｌ  ＡＰＩを利用することで、ネットワークに接続されたサーバに対して、ＨＴＴＰによってコンテンツ取得などの遠隔操作を行うことができる。
ところで、通信装置には、通信機能と機器機能とを有する通信装置がある。特許文献１には、無線通信機能と、無線通信機能とは異なる機器機能とを有する通信装置において、現在行っている通信制御機能よりも機器機能を優先させて動作させると判定した場合、通信制御機能を終了させる技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−１２４３０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、ＨＴＴＰではキャンセル機能がない。そのため、ＨＴＴＰによる通信機能と機器機能とを有するサーバが、リクエストの受信やレスポンスの送信といったＨＴＴＰ処理中に当該ＨＴＴＰ処理をキャンセルして機器機能を動作させる場合、ＨＴＴＰ処理を強制的に終了させることになる。つまり、サーバがＨＴＴＰ処理中に、ＨＴＴＰ処理よりも優先度の高い処理を要求された場合、ＨＴＴＰ処理が完了直前の場合であっても、ＨＴＴＰ処理が強制終了されてしまう。したがって、ＨＴＴＰ処理を再開した場合には、再度、ＨＴＴＰ処理を初めからやり直す必要があり、リソースを無駄にしてしまう。
そこで、本発明は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）処理が強制終了されることに起因するリソースの無駄を低減することを目的としている。
【課題を解決するための手段】
【０００５】
上記課題を解決するために、本発明に係る通信装置の一態様は、通信装置であって、他の通信装置からリクエストを受信し、前記他の通信装置に前記リクエストに対するレスポンスを送信する、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）によるデータ通信を行う通信手段と、前記通信手段によるデータ通信を終了させる終了処理を実行可能な終了手段と、前記通信手段によるデータ通信中に、当該データ通信のキャンセル要求を受けた場合、前記データ通信に関する所定の条件を満たしている場合には、前記通信手段による前記データ通信が完了した後に前記終了手段に終了処理を実行させ、前記所定の条件を満たしていない場合には、前記通信手段による前記データ通信が完了する前に前記終了手段に終了処理を実行させる制御手段と、を備える。
【発明の効果】
【０００６】
本発明によれば、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）処理が強制終了されることに起因するリソースの無駄を低減することができる。
【図面の簡単な説明】
【０００７】
【図１】本実施形態に係る通信システムの構成図の一例である。
【図２】クライアント装置のハードウェア構成の一例である。
【図３】サーバ装置のハードウェア構成の一例である。
【図４】クライアント装置が実行するリクエスト処理のフローチャートである。
【図５】サーバ装置が実行する初期化処理のフローチャートである。
【図６】サーバ装置が実行する接続監視処理のフローチャートである。
【図７】サーバ装置が実行する受信監視処理のフローチャートである。
【図８】サーバ装置が実行する送信監視処理のフローチャートである。
【図９】サーバ装置が実行するイベント監視処理のフローチャートである。
【図１０】ソケットリストの一例を示す図である。
【図１１】装置間における通信シーケンスの一例である。
【図１２】装置間における通信シーケンスの一例である。
【図１３】装置間における通信シーケンスの一例である。
【図１４】装置間における通信シーケンスの一例である。
【発明を実施するための形態】
【０００８】
以下、添付図面を参照して、本発明を実施するための形態について詳細に説明する。なお、以下に説明する実施の形態は、本発明の実現手段としての一例であり、本発明が適用される装置の構成や各種条件によって適宜修正または変更されるべきものであり、本発明は以下の実施の形態に限定されるものではない。
【０００９】
（通信システムの構成）
図１は、本実施形態に係る通信装置を備える通信システム１０００の構成例を示す図である。通信システム１０００は、ネットワーク１００に接続されたクライアント装置２００とサーバ装置３００とを備える。
クライアント装置２００は通信装置であり、ネットワーク１００を介してサーバ装置３００との間でＨＴＴＰによるデータ通信が可能である。具体的には、クライアント装置２００は、サーバ装置３００に対するＨＴＴＰリクエスト（以下、単に「リクエスト」ともいう。）の送信、およびサーバ装置３００からのＨＴＴＰレスポンス（以下、単に「レスポンス」ともいう。）の受信が可能である。同様に、サーバ装置３００は通信装置であり、ネットワーク１００を介してクライアント装置２００との間でＨＴＴＰによるデータ通信が可能である。具体的には、サーバ装置３００は、クライアント装置２００からのリクエストの受信、およびクライアント装置２００に対するレスポンスの送信が可能である。
【００１０】
ネットワーク１００は、インターネットやＷＡＮ（Wide Area Network）、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ（Wireless LAN）、若しくはこれらの複合により実現することができる。なお、クライアント装置２００とサーバ装置３００とは、ネットワーク１００を介さずに、直接接続されていてもよい。例えば、クライアント装置２００とサーバ装置３００とは、無線アドホックネットワークを用いて接続可能である。
クライアント装置２００は、例えばスマートフォンとし、サーバ装置３００は、例えばデジタルカメラとすることができる。
【００１１】
（装置の構成）
図２は、クライアント装置２００のハードウェア構成の一例である。
クライアント装置２００は、リクエスト送信部２０１と、レスポンス受信部２０２と、レスポンス判定部２０３と、表示部２０４と、を備える。クライアント装置２００を構成する各部２０１〜２０４は、バス２０５に接続されている。
リクエスト送信部２０１は、ＨＴＴＰリクエストをサーバ装置３００に送信する。
レスポンス受信部２０２は、サーバ装置３００からのＨＴＴＰレスポンスを受信する。
レスポンス判定部２０３は、レスポンス受信部２０２により受信されたレスポンスの内容を解析し、リクエスト完了のレスポンスか、リクエストエラーのレスポンスかを判定する。
表示部２０４は、レスポンス判定部２０３の判定結果を表示する。具体的には、表示部２０４は、レスポンス判定部２０３によってリクエストエラーのレスポンスであると判定された場合、サーバ装置３００からエラーレスポンスを受信したことを示す情報を表示する。
【００１２】
図３は、サーバ装置３００のハードウェア構成の一例である。
サーバ装置３００は、リクエスト受信部３０１と、生成部３０２と、レスポンス生成部３０３と、レスポンス送信部３０４と、接続監視部３０５と、操作部３０６と、管理部３０７と、を備える。また、サーバ装置３００は、受信監視部３０８と、送信監視部３０９と、イベント監視部３１０と、ＡＰＩ部３１１と、記憶部３１２と、メッセージ生成部３１３と、メッセージ削除部３１４と、を備える。サーバ装置３００を構成する各部３０１〜３１４は、バス３１５に接続されている。
【００１３】
リクエスト受信部３０１は、クライアント装置２００からＨＴＴＰリクエストを受信する。
生成部３０２は、接続監視部３０５にてクライアント装置２００の接続を検知した際にソケットを生成し、生成したソケットを管理部３０７が管理する後述するソケットリストに登録する。
レスポンス生成部３０３は、ＨＴＴＰリクエストに対するレスポンスのヘッダを生成する。
レスポンス送信部３０４は、レスポンス生成部３０３により生成されたヘッダ、および記憶部３１２から取得したデータをクライアント装置２００に送信する。
接続監視部３０５は、クライアント装置２００の接続検知を行う。
操作部３０６は、記憶部３１２に記憶されているアプリケーションに要求を送信する。
管理部３０７は、ソケットリスト、イベントタスク、送信リストの管理を行う。また、管理部３０７は、ソケットに紐づけられたデータの管理も行う。
【００１４】
受信監視部３０８は、管理部３０７が管理するソケットリストの監視を行う。
送信監視部３０９は、管理部３０７が管理する送信リストの監視を行う。
イベント監視部３１０は、管理部３０７が管理するイベントタスクの監視を行う。
ＡＰＩ部３１１は、受信監視部３０８、送信監視部３０９、イベント監視部３１０および記憶部３１２との間で処理のやり取りを行う。
記憶部３１２は、アプリケーションを記憶し、アプリケーション処理を行う。また、記憶部３１２は、データの記憶も行う。
メッセージ生成部３１３は、送信監視部３０９、イベント監視部３１０、ＡＰＩ部３１１および記憶部３１２との間で、データのやり取りを行うためのメッセージを生成する。
メッセージ削除部３１４は、メッセージ生成部３１３により生成されたメッセージの削除を行う。
【００１５】
本実施形態では、サーバ装置３００は、クライアント装置２００からリクエストを受信し、クライアント装置２００にリクエストに対するレスポンスを送信する、ＨＴＴＰによるデータ通信を行う。また、サーバ装置２００は、上記のＨＴＴＰによるデータ通信を終了させる終了処理を実行可能である。サーバ装置３００は、データ通信中に、当該データ通信のキャンセル要求を受けた場合、データ通信に関する所定の条件を満たしているか否かを判定する。そして、サーバ装置３００は、所定の条件を満たしている場合には、データ通信が完了した後に終了処理を実行し、所定の条件を満たしていない場合には、データ通信が完了する前に終了処理を実行する。
ここで、上記キャンセル要求は、ＨＴＴＰによるデータ通信を行うＨＴＴＰ処理よりも優先度の高い処理を動作させる要求である。ＨＴＴＰ処理よりも優先度の高い処理としては、デジタルカメラの撮像モードに切り替える処理や電源を切る処理、大量のメモリを消費する処理が挙げられる。また、上記所定の条件は、キャンセル要求を受けた際に実行中のデータ通信が完了直前、もしくは完了に近いことを含むことができる。
【００１６】
なお、図２に示す各要素の一部または全部の機能は、ソフトウェアにより実現されるようにしてもよい。同様に、図３に示す各要素の一部または全部の機能は、ソフトウェアにより実現されるようにしてもよい。
ソフトウェアにより実現される機能については、ＣＰＵがＲＡＭにプログラムを読み出して実行することにより実現される。一方、ハードウェアにより実現される機能については、例えば、所定のコンパイラを用いることで、各機能を実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。ＦＰＧＡとは、Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙの略である。また、ＦＰＧＡと同様にしてＧａｔｅ  Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣ（Application Specific Integrated Circuit）により実現するようにしてもよい。
【００１７】
以下、本実施形態における各通信装置の動作について説明する。
（リクエスト処理）
図４は、クライアント装置２００が実行するリクエスト処理のフローチャートである。この図４に示すリクエスト処理は、ＨＴＴＰを使用した通信において、クライアント装置２００がサーバ装置３００にリクエストを送信する際の処理であり、クライアント装置２００のユーザ操作に従って実行される。ただし、図４の処理の開始タイミングは、上記のタイミングに限らない。
クライアント装置２００は、図２に示す各要素がそれぞれ別個のハードウェアとして動作することで、図４に示す処理を実行することができる。ただし、クライアント装置２００のＣＰＵが必要なプログラムを読み出して実行することにより、図４に示す処理が実現されてもよい。以降、アルファベットＳはフローチャートにおけるステップを意味するものとする。
【００１８】
まずＳ１において、リクエスト送信部２０１は、サーバ装置３００にリクエストを送信する。このとき、リクエスト内容を分割して、複数回に分けて送信してもよい。リクエストを複数回に分けて送信する場合、リクエスト送信部２０１は、サーバ装置３００がリクエストを受信して受信データの解析を行った後に、次のリクエストを送信する。
Ｓ２では、レスポンス受信部２０２は、サーバ装置３００からのレスポンスを受信する。次にＳ３において、レスポンス判定部２０３は、Ｓ２において受信されたレスポンスの内容がエラーであるか否かを判定する。そして、レスポンス内容がエラーであると判定した場合にはＳ４に移行し、エラーではないと判定した場合には図４の処理を終了する。
Ｓ４では、表示部２０４は、レスポンス判定部２０３の判定結果を表示し、図４の処理を終了する。
【００１９】
（初期化処理）
図５は、サーバ装置３００が実行する初期化処理のフローチャートである。この図５に示す処理は、サーバ装置３００が起動されたタイミングで実行される。ただし、図５の処理の開始タイミングは、上記のタイミングに限らない。処理の開始タイミングは、例えば操作部３０６が操作されたタイミングであってもよいし、サーバ装置３００とネットワーク１００を介して、もしくは直接接続されている機器から初期化処理要求を受けたタイミングであってもよい。
サーバ装置３００は、図３に示す各要素がそれぞれ別個のハードウェアとして動作することで、図５に示す処理を実行することができる。ただし、サーバ装置３００のＣＰＵが必要なプログラムを読み出して実行することにより、図５に示す処理が実現されてもよい。後述する図６〜図９に示すフローチャートについても、同様である。
【００２０】
まずＳ１１において、接続監視部３０５は、図６に示す接続監視処理を開始する。
Ｓ１２では、受信監視部３０８は、図７に示す受信監視処理を開始する。
Ｓ１３では、送信監視部３０９は、図８に示す送信監視処理を開始する。
Ｓ１４では、イベント監視部３１０は、図９に示すイベント監視処理を開始する。
Ｓ１５では、管理部３０７は、ソケットリストの初期化を行う。このとき、図１０に示すように、ソケットリスト３２０は状態Ａとなる。
【００２１】
図１０は、管理部３０７が管理するソケットリスト３２０を表す図である。この図１０では、１つのソケットの状態をＡ〜Ｕまでで表している。
ソケットリスト３２０では、ソケットＩＤ、ソケット状態、データ、メッセージ、およびメッセージ状態を管理する。ソケットＩＤは、ソケットを識別するためのＩＤであり、ソケット状態は、ソケットの現在の状態、データは、ソケットに登録されたデータが存在するか否かを表す。また、メッセージは、ソケットに紐づけられたメッセージが存在するか否かを表し、メッセージ状態は、ソケットに紐づけられたメッセージの現在の状態を表す。
ここで、ソケットリスト３２０のデータが有の場合、データの本体は、管理部３０７がソケットＩＤと紐づけて記憶している。また、状態Ｌのソケットは、接続監視部３０５がソケットリスト３２０から削除するものとする。
なお、本実施形態では、１つのソケットのみを管理する場合について説明するが、複数のソケットを管理することも可能である。
【００２２】
（接続監視処理）
図６は、サーバ装置３００が図５のＳ１１において開始する接続監視処理のフローチャートである。
サーバ装置３００の接続監視部３０５は、まずＳ１１ａにおいて、終了フラグを検知したか否かを判定する。接続監視部３０５は、終了フラグを検知したと判定した場合、図６の接続監視処理を終了し、終了フラグを検知していないと判定した場合、Ｓ１１ｂに移行する。
Ｓ１１ｂでは、接続監視部３０５は、クライアント装置２００からリクエストを受信したか否かを判定する。リクエストの受信には、リクエストボディの受信も含まれる。接続監視部３０５は、リクエストを受信したと判定した場合、Ｓ１１ｃに移行し、リクエストを受信していないと判定した場合、Ｓ１１ａに戻る。
【００２３】
Ｓ１１ｃでは、接続監視部３０５は、新たな接続を検知したか否かを判定する。そして、接続監視部３０５は、新たな接続を検知したと判定した場合にはＳ１１ｄに移行し、新たな接続を検知していないと判定した場合にはＳ１１ｅに移行する。
Ｓ１１ｄでは、生成部３０２は、ソケットを生成し、生成したソケットを管理部３０７が管理するソケットリスト３２０に登録する。このとき、ソケットリスト３２０は、図１０の状態Ｂとする。
Ｓ１１ｅでは、接続監視部３０５は、リクエストのデータを受信し、受信したデータをソケットに紐づけて管理部３０７が管理するソケットリスト３２０に登録する。このとき、ソケットリスト３２０のデータが有に更新される。
【００２４】
（受信監視処理）
図７は、サーバ装置３００が図５のＳ１２において開始する受信監視処理のフローチャートである。
サーバ装置３００の受信監視部３０８は、まずＳ１２ａにおいて、終了フラグを検知したか否かを判定する。受信監視部３０８は、終了フラグを検知したと判定した場合、図７の受信監視処理を終了し、終了フラグを検知していないと判定した場合、Ｓ１２ｂに移行する。
Ｓ１２ｂでは、受信監視部３０８は、受信条件に合致するソケットが存在するか否かを判定する。本実施形態において、受信条件とは、ソケットリスト３２０に登録されたソケットの状態が準備状態またはキャンセル状態で、且つデータが有の状態を指す。受信監視部３０８は、受信条件に合致するソケットが存在すると判定した場合、Ｓ１２ｃに移行し、受信条件に合致するソケットが存在しないと判定した場合、Ｓ１２ａに戻る。
【００２５】
Ｓ１２ｃでは、受信監視部３０８は、ソケットリスト３２０のソケット状態を準備状態またはキャンセル状態から受信状態に更新し、Ｓ１２ｄに移行する。Ｓ１２ｄでは、受信監視部３０８は、受信イベントを、管理部３０７が管理するイベントタスクに登録し、図７の受信監視処理を終了する。受信イベントには、Ｓ１２ｂにおいて受信条件に合致したソケットのソケットＩＤが与えられる。
【００２６】
（送信監視処理）
図８は、サーバ装置３００が図５のＳ１３において開始する送信監視処理のフローチャートである。
サーバ装置３００の送信監視部３０９は、まずＳ１３ａにおいて、終了フラグを検知したか否かを判定する。送信監視部３０９は、終了フラグを検知したと判定した場合、図８の送信監視処理を終了し、終了フラグを検知していないと判定した場合、Ｓ１３ｂに移行する。
Ｓ１３ｂでは、送信監視部３０９は、管理部３０７が管理する送信リストの先頭を取得する。
Ｓ１３ｃでは、送信監視部３０９は取得したメッセージの状態を確認する。送信監視部３０９は、メッセージの状態がリクエスト完了状態、レスポンス中状態、またはレスポンスキャンセル待ち状態である場合、メッセージ状態が「送信」の状態であると判定し、Ｓ１３ｄに移行する。一方、送信監視部３０９は、メッセージの状態がキャンセル準備状態である場合、メッセージ状態が「キャンセル準備」の状態であると判定し、Ｓ１３ｋに移行する。また、送信監視部３０９は、メッセージの状態がキャンセル状態など、上記以外である場合には、メッセージ状態が「キャンセル」の状態であると判定し、Ｓ１３ｂに戻る。
【００２７】
Ｓ１３ｄでは、送信監視部３０９は、ソケット状態を送信状態に更新する。また、送信監視部３０９は、メッセージ状態がレスポンスキャンセル待ち状態でない場合、メッセージ状態をレスポンス中状態に更新し、メッセージ状態がレスポンスキャンセル待ち状態の場合はメッセージ状態の更新をしない。
Ｓ１３ｅでは、レスポンス送信部３０４は、レスポンス生成部３０３により生成されたレスポンスのヘッダを送信する。ヘッダを送信済みの場合、送信監視部３０９は、ＡＰＩ部３１１にボディデータを要求する。ＡＰＩ部３１１は、記憶部３１２からボディデータを取得し、送信監視部３０９にボディデータを送信する。そして、送信監視部３０９がボディデータを取得後、レスポンス送信部３０４はボディデータを送信する。なお、一度の取得で全てのデータを取得しきれない場合、データを分割して取得、送信を行ってもよい。
【００２８】
Ｓ１３ｆでは、送信監視部３０９は、Ｓ１３ｅにおいて送信されたデータの続きがあるか否かを判定する。そして、送信監視部３０９は、データに続きが存在しないと判定した場合にはＳ１３ｇに移行し、データに続きが存在すると判定した場合にはＳ１３ｉに移行する。
Ｓ１３ｇでは、送信監視部３０９は、ソケット状態を終了状態に更新し、Ｓ１３ｈに移行する。Ｓ１３ｈでは、メッセージ削除部３１０は、メッセージの削除を行う。このとき、送信リストからソケットＩＤに紐づくメッセージを全て削除する。また、ソケットとメッセージの紐付を解除するため、ソケットリスト３２０のメッセージとメッセージ状態とは初期化され、無に更新される。
【００２９】
Ｓ１３ｉでは、送信監視部３０９は、取得されたメッセージ状態を確認する。送信監視部３０９は、メッセージの状態がレスポンス中状態またはキャンセル準備状態である場合、メッセージ状態が「送信」の状態であると判定し、Ｓ１３ｊに移行する。一方、送信監視部３０９は、メッセージの状態がレスポンスキャンセル待ち状態である場合、メッセージの状態が「キャンセル待ち」の状態であると判定し、Ｓ１３ｋに移行する。
Ｓ１３ｊでは、送信監視部３０９は、ＡＰＩ部３１１にデータ要求通知を送信する。このとき、当該通知を受信したＡＰＩ部３１１は、記憶部３１２にデータ要求通知を送信する。当該通知を受信した記憶部３１２は、分割したレスポンスの続きのデータをＡＰＩ部３１１に送信する。その後、ＡＰＩ部３１１は、受信したデータを、ソケットＩＤに紐づくメッセージに登録し、送信イベントを管理部３０７が管理するイベントタスクに登録する。送信イベントには、ソケットＩＤが与えられる。
【００３０】
Ｓ１３ｋでは、送信監視部３０９は、キャンセル待ち条件を満たすか否かを判定する。本実施形態では、キャンセル待ち条件は、「分割したレスポンスのうち、９０％以上送信済みか？」とするが、これに限るものではない。
キャンセル待ち条件は、「サーバ装置３００がキャンセル要求を受けてからの経過時間が閾値以上であるか？」であってもよい。また、キャンセル待ち条件は、「サーバ装置３００がキャンセル要求を受けてから送信したレスポンスのサイズの合計が閾値以上であるか？」であってもよい。さらに、キャンセル待ち条件は、「レスポンスを送信開始してからの経過時間が閾値以上であるか？」であってもよいし、「レスポンスを送信開始してから送信したレスポンスのサイズの合計が閾値以上であるか？」であってもよい。ここで、上記閾値は、レスポンスの送信が完了直前、もしくは完了に近いと判断することができる値に設定する。
【００３１】
送信監視部３０９は、Ｓ１３ｋにおいてキャンセル待ち条件を満たすと判定した場合、Ｓ１３ｌに移行し、キャンセル待ち条件を満たさないと判定した場合、Ｓ１３ｎに移行する。
なお、本実施形態では、キャンセル待ち条件を設定しない場合であっても、分割された最後のデータを送信中にキャンセル準備要求がイベントタスクに積まれた場合には、Ｓ１３ｅが完了するまで待った後、終了処理を行うことができる。このように、キャンセル要求を受けた際に送信中のレスポンスが分割された最後のレスポンスである場合には、送信完了まで待つことができ、リソースの無駄を低減できる。
【００３２】
Ｓ１３ｌでは、送信監視部３０９は、取得されたメッセージの状態を確認する。送信監視部３０９は、メッセージの状態がレスポンスキャンセル待ち状態である場合、メッセージ状態が「キャンセル待ち」の状態であると判定してＳ１３ｊ移行する。一方、送信監視部３０９は、メッセージの状態がキャンセル準備状態である場合、メッセージ状態が「キャンセル準備」の状態であると判定し、Ｓ１３ｍに移行する。Ｓ１３ｍでは、送信監視部３０９は、メッセージ状態をレスポンスキャンセル待ち状態に更新し、Ｓ１３ａに戻る。
Ｓ１３ｎでは、送信監視部３０９は、メッセージ状態をキャンセル状態に更新し、Ｓ１３ｏに移行する。Ｓ１３ｏでは、送信監視部３０９は、キャンセルイベントを管理部３０７が管理するイベントタスクの先頭に登録する。キャンセルイベントには、ソケットＩＤが与えられる。
【００３３】
（イベント監視処理）
図９は、サーバ装置３００が図５のＳ１４において開始するイベント監視処理のフローチャートである。
サーバ装置３００のイベント監視部３１０は、まずＳ１４ａにおいて、終了フラグを検知したか否かを判定する。イベント監視部３１０は、終了フラグを検知したと判定した場合、図９のイベント監視処理を終了し、終了フラグを検知していないと判定した場合、Ｓ１４ｂに移行する。
Ｓ１４ｂでは、イベント監視部３１０は、管理部３０７が管理するイベントタスクの先頭の内容を確認する。イベント監視部３１０は、先頭の内容が送信イベントであると判定した場合にはＳ１４ｃに移行し、先頭の内容が受信イベントであると判定した場合にはＳ１４ｄに移行する。また、イベント監視部３１０は、先頭の内容がキャンセル準備イベントであると判定した場合にはＳ１４ｏに移行し、先頭の内容がキャンセルイベントであると判定した場合にはＳ１４ｕに移行する。
なお、キャンセル準備イベントは、サーバ装置３００がキャンセル要求を受信した際に、ＡＰＩ部３１１によって管理部３０７が管理するイベントタスクに登録される。
【００３４】
Ｓ１４ｃでは、イベント監視部３１０は、管理部３０７が管理する送信リストにメッセージを登録する。ここで登録するメッセージは、送信イベントに与えられたソケットＩＤに紐づけられたメッセージである。
Ｓ１４ｄでは、イベント監視部３１０は、ソケットに紐づくメッセージが存在するか否かを判定する。そして、イベント監視部３１０は、ソケットに紐づくメッセージが存在しないと判定した場合、Ｓ１４ｅに移行し、ソケットに紐づくメッセージが存在すると判定した場合、Ｓ１４ｆに移行する。
Ｓ１４ｅでは、メッセージ生成部３１３は、メッセージの生成を行う。ここで生成されたメッセージは、ソケットに紐づけられ、ソケットリスト３２０に登録される。このとき、メッセージ状態は準備状態に更新される。
【００３５】
Ｓ１４ｆでは、イベント監視部３１０は、取得されたメッセージの状態を確認する。イベント監視部３１０は、メッセージの状態が準備状態またはリクエスト中状態である場合、メッセージ状態が「受信」の状態であると判定してＳ１４ｇに移行する。一方、イベント監視部３１０は、メッセージの状態がリクエストキャンセル待ち状態である場合、メッセージ状態が「キャンセル待ち」の状態であると判定してＳ１４ｈに移行する。
Ｓ１４ｇでは、イベント監視部３１０は、メッセージ状態をリクエスト中状態に更新してＳ１４ｉに移行する。
【００３６】
Ｓ１４ｈでは、イベント監視部３１０は、キャンセル待ち条件を満たすか否かを判定する。本実施形態では、キャンセル待ち条件は、「分割したリクエストのうち、９０％以上受信済みか？」とするが、これに限るものではない。
キャンセル待ち条件は、「サーバ装置３００がキャンセル要求を受けてからの経過時間が閾値以上であるか？」であってもよい。また、キャンセル待ち条件は、「サーバ装置３００がキャンセル要求を受けてから受信したリクエストのサイズの合計が閾値以上であるか？」であってもよい。さらに、キャンセル待ち条件は、「リクエストを受信開始してからの経過時間が閾値以上であるか？」であってもよいし、「リクエストを受信開始してから受信したリクエストのサイズの合計が閾値以上であるか？」であってもよい。ここで、上記閾値は、リクエストの受信が完了直前、もしくは完了に近いと判断することができる値に設定する。
イベント監視部３１０は、Ｓ１４ｈにおいてキャンセル待ち条件を満たすと判定した場合、Ｓ１４ｉに移行し、キャンセル待ち条件を満たさないと判定した場合、Ｓ１４ｍに移行する。
【００３７】
Ｓ１４ｉでは、イベント監視部３１０は、ソケットに紐づけられたデータをソケットに紐づけられたメッセージに移動し、ＡＰＩ部３１１にメッセージを送信する。その後、ＡＰＩ部３１１は記憶部３１２にメッセージを送信し、記憶部３１２はデータの解析を行う。また、データをメッセージに移動した際に、ソケットリスト３２０のデータを無に更新する。
Ｓ１４ｊでは、イベント監視部３１０は、Ｓ１４ｉにおいて解析されたデータに続きが存在するか否かを判定する。イベント監視部３１０は、データに続きが存在すると判定した場合、Ｓ１４ｋに移行し、データに続きが存在しないと判定した場合、Ｓ１４ｌに移行する。Ｓ１４ｋでは、イベント監視部３１０は、ソケット状態を準備状態に更新し、Ｓ１４ａに戻る。Ｓ１４ｌでは、イベント監視部３１０は、ソケット状態を準備状態に更新するとともに、メッセージ状態をリクエスト完了状態に更新し、Ｓ１４ａに戻る。
Ｓ１４ｍでは、イベント監視部３１０は、メッセージ状態をキャンセル状態に更新し、Ｓ１４ｎに移行する。Ｓ１４ｎでは、イベント監視部３１０は、キャンセルイベントを管理部３０７が管理するイベントタスクの先頭に登録し、Ｓ１４ａに戻る。
【００３８】
Ｓ１４ｏでは、イベント監視部３１０は、ソケットに紐づくメッセージが存在するか否かを判定する。そして、イベント監視部３１０は、ソケットに紐づくメッセージが存在すると判定した場合、Ｓ１４ｐに移行し、ソケットに紐づくメッセージが存在しないと判定した場合、Ｓ１４ａに戻る。
Ｓ１４ｐでは、イベント監視部３１０は、ソケット状態を確認する。イベント監視部３１０は、ソケット状態が送信状態であると判定した場合にはＳ１４ｑに移行し、ソケット状態が受信状態であると判定した場合にはＳ１４ｓに移行し、ソケット状態が準備状態であると判定した場合にはＳ１４ｔに移行する。
【００３９】
Ｓ１４ｑでは、イベント監視部３１０は、ソケット状態をキャンセル状態に更新するとともに、メッセージ状態をキャンセル準備状態に更新し、Ｓ１４ｒに移行する。Ｓ１４ｒでは、イベント監視部３１０は、管理部３０７が管理する送信リストの先頭にメッセージを登録し、Ｓ１４ａに戻る。
Ｓ１４ｓでは、イベント監視部３１０は、メッセージ状態をリクエストキャンセル待ち状態に更新し、Ｓ１４ａに戻る。Ｓ１４ｔでは、イベント監視部３１０は、ソケット状態をキャンセル状態に更新するとともに、メッセージ状態をリクエストキャンセル待ち状態に更新し、Ｓ１４ａに戻る。
【００４０】
Ｓ１４ｕでは、イベント監視部３１０は、ソケットに紐づくメッセージが存在するか否かを判定する。そして、イベント監視部３１０は、ソケットに紐づくメッセージが存在すると判定した場合、Ｓ１４ｖに移行し、ソケットに紐づくメッセージが存在しないと判定した場合、Ｓ１４ａに戻る。
Ｓ１４ｖでは、イベント監視部３１０は、ソケット状態を終了状態に更新し、Ｓ１４ｗに移行する。Ｓ１４ｗでは、メッセージ削除部３１０は、メッセージの削除を行い、Ｓ１４ａに戻る。Ｓ１４ｗでは、メッセージ削除部３１０は、送信リストからソケットに紐づくメッセージを全て削除する。また、ソケットとメッセージの紐付を解除するため、ソケットリスト３２０のメッセージとメッセージ状態とは無に更新される。
【００４１】
（動作）
図１１は、サーバ装置３００によって初期化処理が実行された後、クライアント装置２００がサーバ装置３００にＧＥＴリクエストを行い、サーバ装置３００がクライアント装置２００からのリクエストを受信完了するまでのシーケンスである。
まずＭ１において、記憶部３１２は、ＡＰＩ部３１１に初期化処理要求を送信する。記憶部３１２が初期化処理要求を送信する契機は、サーバ装置３００が起動した場合でもよいし、操作部３０６が操作された場合でもよい。また、サーバ装置３００とネットワーク１００を介して接続している機器から初期化処理要求を受けた場合でもよい。
ＡＰＩ部３１１が記憶部３１２から初期化処理要求を受信すると、Ｍ２において、サーバ装置３００は、図５の初期化処理を行う。
【００４２】
Ｍ３において、クライアント装置２００は、サーバ装置３００にリクエスト送信を行う（図４のＳ１）。ここで送信されるリクエストはＧＥＴリクエストであるため、リクエストのボディデータの長さは０である。
Ｍ４において、サーバ装置３００の接続監視部３０５は、クライアント装置２００からリクエストを受信し（図６のＳ１１ｂでＹｅｓ）、さらに新たな接続を検知（Ｓ１１ｃでＹｅｓ）するため、ソケット生成を行う（Ｓ１１ｄ）。このとき、ソケットリスト３２０は状態Ａから状態Ｂとなる。
また、Ｍ５において、接続監視部３０５は、リクエストのデータを受信し、受信したデータをソケットに紐づけて管理部３０７が管理するソケットリスト３２０に登録する（Ｓ１１ｅ）。このとき、ソケットリスト３２０のデータが有に更新されるため、ソケットリスト３２０は状態Ｂから状態Ｃとなる。
【００４３】
Ｍ６においては、受信監視部３０８は、ソケットリスト３２０のソケットＩＤ＝１のソケットが受信条件に合致するソケットであると判定する（図７のＳ１２ｂでＹｅｓ）。そのため、受信監視部３０８は、ソケット状態を準備状態から受信状態に更新する（Ｓ１２ｃ）。このとき、ソケットリスト３２０は状態Ｃから状態Ｄとなる。
次にＭ７において、受信監視部３０８は、受信イベントを管理部３０７が管理するイベントタスクに登録する（Ｓ１２ｄ）。
【００４４】
Ｍ８においては、イベント監視部３１０は、受信イベントを受信し、イベントタスクの先頭の内容が受信イベントであると判定する（図９のＳ１４ｂで「受信」と判定）。その後、イベント監視部３１０は、受信イベントのソケットＩＤを参照し、該当するソケットのメッセージが存在しないことを確認するため（Ｓ１４ｄでＮｏ）、メッセージ生成部３１３は、メッセージの生成を行う（Ｓ１４ｅ）。このとき、ソケットリスト３２０のメッセージが有に更新され、メッセージ状態が準備状態に更新されるため、ソケットリスト３２０は状態Ｄから状態Ｅとなる。
【００４５】
次にＭ９において、イベント監視部３１０は、メッセージの状態が準備状態であることを確認し（Ｓ１４ｆで「受信」と判定）、イベント監視部３１０は、メッセージ状態をリクエスト中状態に更新する（Ｓ１４ｇ）。このとき、ソケットリスト３２０は状態Ｅから状態Ｆとなる。
次にＭ１０において、イベント監視部３１０は、受信データの解析を行う（Ｓ１４ｉ）。このとき、イベント監視部３１０は、ソケットのデータをメッセージに移動させるので、ソケットリスト３２０のデータは無に更新され、ソケットリスト３２０は状態Ｆから状態Ｇとなる。なお、本実施形態では、Ｍ３の処理開始からＭ１０の処理終了までの期間をリクエスト受信中としている。
次にＭ１１において、イベント監視部３１０は、Ｍ１０において解析したデータの続きがないと判定する（Ｓ１４ｊでＮｏ）。そのため、イベント監視部３１０は、ソケット状態を準備状態に更新し、メッセージ状態をリクエスト完了状態に更新する（Ｓ１４ｌ）。このとき、ソケットリスト３２０は状態Ｇから状態Ｈとなる。
【００４６】
図１２は、サーバ装置３００がクライアント装置２００からのリクエストを受信完了後、クライアント装置２００にレスポンスデータを分割して送信し、最後の分割を送信中に、ＨＴＴＰ処理よりも優先度の高い処理を要求された場合のシーケンスである。
Ｍ２１において、記憶部３１２は、ＡＰＩ部３１１にレスポンスを送信する。記憶部３１２がレスポンスを送信する契機は、図９のＳ１４ｌの後である。つまり、図１１においては、Ｍ１１の後である。
Ｍ２２においては、ＡＰＩ部３１１は、記憶部３１２から受信したデータを、ソケットＩＤに紐づくメッセージに登録し、送信イベントを管理部３０７が管理するイベントタスクに登録する。送信イベントには、ソケットＩＤが与えられる。
【００４７】
Ｍ２３では、イベント監視部３１０は、送信イベントを受信し（Ｓ１４ｂで「送信」と判定）、管理部３０７が管理する送信リストにメッセージを登録する（Ｓ１４ｃ）。
すると、Ｍ２４において、送信監視部３０９は、管理部３０７が管理する送信リストの先頭を取得し（図８のＳ１３ｂ）、リクエスト完了状態のメッセージを取得する（Ｓ１３ｃで「送信」と判定）。そのため、送信監視部３０９は、ソケット状態を送信状態に更新し、メッセージ状態をレスポンス中状態に更新する（Ｓ１３ｄ）。このとき、ソケットリスト３２０は状態Ｈから状態Ｉとなる。
そして、Ｍ２５において、レスポンス送信部３０４は、データ送信を行う（Ｓ１３ｅ）。データ送信後、Ｍ２６において、送信監視部３０９は、データの続きがあると判定し（Ｓ１３ｆでＹｅｓ）、メッセージの状態がレスポンス中状態であると判定し（Ｓ１３ｉで「送信」と判定）、送信イベントの登録を行う（Ｓ１３ｊ）。
【００４８】
すると、Ｍ２７において、イベント監視部３１０は、送信イベントを受信し（図９のＳ１４ｂで「送信」と判定）、Ｍ２３と同様に、管理部３０７が管理する送信リストにメッセージを登録する（Ｓ１４ｃ）。
そして、Ｍ２８において、送信監視部３０９は、管理部３０７が管理する送信リストの先頭を取得し（図８のＳ１３ｂ）、レスポンス中状態のメッセージを取得する（Ｓ１３ｃで「送信」と判定）。そのため、送信監視部３０９は、ソケット状態を送信状態に更新し、メッセージ状態をレスポンス中状態に更新する（Ｓ１３ｄ）。このとき、ソケットリスト３２０は状態Ｉのまま変化しない。
【００４９】
そして、Ｍ２９において、レスポンス送信部３０４は、データ送信を行う（Ｓ１３ｅ）。図１２の例では、このＭ２９において送信するデータは、分割されたレスポンスの最後の分割であるものとする。また、Ｍ２９の処理が終了するのは、後述するＭ３３の処理の後であるものとする。
この分割されたレスポンスの最後の分割を送信中に、サーバ装置３００がＨＴＴＰ処理よりも優先度の高い処理を要求された場合、Ｍ３０において、記憶部３１２はＡＰＩ部３１１に優先度高の処理要求を送信する。ここで、優先度高の処理要求は、ＨＴＴＰ処理よりも優先度の高い処理の要求であり、サーバ装置３００にＨＴＴＰ処理をキャンセルさせるためのキャンセル要求である。記憶部３１２が優先度高の処理要求を送信する契機は、操作部３０６が操作された場合や、サーバ装置３００とネットワーク１００を介して接続している機器から優先度高の処理要求を受けた場合とすることができる。
【００５０】
ＡＰＩ部３１１は、優先度高の処理要求を受信すると、Ｍ３１において、キャンセル準備イベントを管理部３０７が管理するイベントタスクに登録する。キャンセル準備イベントには、キャンセル対象のソケットＩＤが与えられる。なお、キャンセル対象が複数の場合、複数のキャンセル準備イベントを登録してもよい。これにより、サーバ装置３００が複数のクライアント装置とＨＴＴＰ通信を行う場合に対応することができる。
Ｍ３２においては、イベント監視部３１０は、キャンセル準備イベントを受信する（Ｓ１４ｂで「キャンセル準備」と判定）。また、イベント監視部３１０は、ソケットに紐づくメッセージが存在することを確認し（Ｓ１４ｏでＹｅｓ）、ソケット状態が送信状態であることを確認する（Ｓ１４ｐで「送信」と判定）。そのため、イベント監視部３１０は、ソケット状態をキャンセル状態に更新し、メッセージ状態をキャンセル準備状態に更新する（Ｓ１４ｑ）。このとき、ソケットリスト３２０は状態Ｉから状態Ｊとなる。
次にＭ３３において、イベント監視部３１０は、管理部３０７が管理する送信リストの先頭にメッセージを登録する（Ｓ１４ｒ）。
【００５１】
その後、Ｍ２９におけるデータ送信の処理が終了すると、Ｍ３４において、送信監視部３０９はデータの続きがないと判定し（Ｓ１３ｆでＮｏ）、ソケット状態を終了状態に更新する（Ｓ１３ｇ）。このとき、ソケットリスト３２０は状態Ｊから状態Ｋとなる。
次にＭ３５において、メッセージ削除部３１０は、メッセージの削除を行う（Ｓ１３ｈ）。このとき、ソケットリスト３２０は状態Ｋから状態Ｌとなる。
ソケットが状態Ｌとなったため、ソケットは接続監視部３０５によりソケットリスト３２０から削除され、処理は終了する。この後、ＨＴＴＰ処理より優先度の高い処理に切り替わる。
【００５２】
このように、本実施形態では、サーバ装置３００が分割したレスポンスデータの最後の分割を送信中に、サーバ装置３００がＨＴＴＰ処理よりも優先度の高い処理を要求された場合には、レスポンスの送信を終了せずに完了させることができる。つまり、サーバ装置３００がキャンセル要求を受けた際に送信中のレスポンスに続く分割されたレスポンスが存在しない場合には、レスポンスの送信が完了した後に終了処理を実行させることができる。これにより、クライアント装置２００は、リクエスト処理を初めからやり直す必要がなくなり、完了直前にＨＴＴＰ処理が強制終了されることに起因するリソースの無駄を低減することができる。
【００５３】
図１３は、サーバ装置３００がクライアント装置２００からのリクエストを受信完了後、クライアント装置２００にレスポンスデータを分割して送信している際に、ＨＴＴＰ処理よりも優先度の高い処理を要求された場合のシーケンスである。ここでは、優先度高の処理要求を受けた際にキャンセル待ち条件を満たしている場合について説明する。
Ｍ４１〜Ｍ４８は、図１２のＭ２１〜Ｍ２８と同様の処理であるため、説明は省略する。
Ｍ４９においては、レスポンス送信部３０４は、データ送信を行う（図８のＳ１３ｅ）。図１３の例では、このＭ４９において送信するデータは、例えば１０個に分割されたレスポンスの９個目の分割であるものとする。また、Ｍ４９の処理が終了するのは、後述するＭ５３の処理の後であるものとする。
そして、サーバ装置３００がこの９個目の分割を送信中に、ＨＴＴＰ処理よりも優先度の高い処理を要求されたものとする。
【００５４】
Ｍ５０〜Ｍ５３は、図１２のＭ３０〜Ｍ３３と同様の処理であるため、説明は省略する。
Ｍ４９におけるデータ送信の処理が終了すると、Ｍ５４において、送信監視部３０９はデータの続きがあると判定し（Ｓ１３ｆでＹｅｓ）、メッセージ状態がキャンセル準備状態であると判定する（Ｓ１３ｉで「送信」と判定）。そのため、送信イベント登録が行われる（Ｓ１３ｊ）。
すると、Ｍ５５において、イベント監視部３１０は、送信イベントを受信し（図９のＳ１４ｂで「送信」と判定）、管理部３０７が管理する送信リストにメッセージを登録する（Ｓ１４ｃ）。
【００５５】
そして、Ｍ５６において、送信監視部３０９は、管理部３０７が管理する送信リストの先頭を取得し（図８のＳ１３ｂ）、メッセージ状態がキャンセル準備状態であると判定する（Ｓ１３ｃで「キャンセル準備」と判定）。そして、送信監視部３０９はキャンセル待ち条件を満たすか否かを判定する。本実施形態において、キャンセル待ち条件は、「分割したレスポンスのうち、９０％以上送信済みか？」である。
この時点において、１０個に分割されたレスポンスのうち９個目の分割の送信を完了しているため、送信監視部３０９は、キャンセル待ち条件を満たしていると判定する（Ｓ１３ｋでＹｅｓ）。また、送信監視部３０９は、メッセージ状態がキャンセル準備状態であること確認する（Ｓ１３ｌで「キャンセル準備」と判定）。そのため、送信監視部３０９は、メッセージ状態をレスポンスキャンセル待ち状態に更新する（Ｓ１３ｍ）。このとき、ソケットリスト３２０は状態Ｊから状態Ｍとなる。
【００５６】
Ｍ５７においては、送信監視部３０９は、メッセージ状態がレスポンスキャンセル待ち状態であると判定する（Ｓ１３ｃで「送信」と判定）。そのため、送信監視部３０９は、ソケット状態を送信状態に更新する（Ｓ１３ｄ）。このとき、メッセージ状態はレスポンスキャンセル待ち状態のままとする。したがって、ソケットリスト３２０は状態Ｍから状態Ｎとなる。
そして、Ｍ５８において、レスポンス送信部３０４は、データ送信を行う（Ｓ１３ｅ）。このＭ５８において送信するデータは、１０個に分割されたレスポンスの１０個目の分割である。
【００５７】
その後、Ｍ５８におけるデータ送信の処理が終了すると、Ｍ５９において、送信監視部３０９はデータの続きがないと判定し（Ｓ１３ｆでＮｏ）、ソケット状態を終了状態に更新する（Ｓ１３ｇ）。このとき、ソケットリスト３２０は状態Ｎから状態Ｏとなる。
次にＭ６０において、メッセージ削除部３１０は、メッセージの削除を行う（Ｓ１３ｈ）。このとき、ソケットリスト３２０は状態Ｏから状態Ｌとなる。
ソケットが状態Ｌとなったため、ソケットは接続監視部３０５によりソケットリスト３２０から削除され、処理は終了する。この後、ＨＴＴＰ処理より優先度の高い処理に切り替わる。
【００５８】
このように、本実施形態では、サーバ装置３００が、分割したレスポンスデータを送信中に、ＨＴＴＰ処理よりも優先度の高い処理を要求された場合、キャンセル待ち条件を満たす場合には、レスポンスの送信を終了せずに完了させることができる。このため、クライアント装置は、リクエスト処理を初めからやり直す必要がなくなり、リソースの無駄を低減できる。
【００５９】
なお、図１３のＭ４９において送信するデータが、例えば１０個に分割されたレスポンスの８個目以前の分割である場合には、Ｍ５６において、送信監視部３０９は、キャンセル待ち条件を満たしていないと判定する（Ｓ１３ｋでＮｏ）。この場合、送信監視部３０９は、メッセージ状態をキャンセル状態に更新し（Ｓ１３ｎ）、キャンセルイベントを管理部３０７が管理するイベントタスクの先頭に登録する（Ｓ１３ｏ）。すると、イベント監視部３１０は、キャンセルイベントを受信し（Ｓ１４ｂで「キャンセル」と判定）、ソケット状態を終了状態に更新し（Ｓ１４ｖ）、メッセージの削除を行う（Ｓ１４ｗ）。このとき、ソケットリスト３２０は状態Ｌとなり、ソケットは接続監視部３０５によりソケットリスト３２０から削除され、処理は終了する。この後、ＨＴＴＰ処理より優先度の高い処理に切り替わる。
このように、本実施形態では、サーバ装置３００が、分割したレスポンスデータを送信中に、ＨＴＴＰ処理よりも優先度の高い処理を要求された場合、キャンセル待ち条件を満たさない場合には、レスポンスの送信を終了させることができる。そのため、速やかにＨＴＴＰ処理よりも優先度の高い処理に切り替えることができる。
【００６０】
図１４は、サーバ装置３００が初期化処理を実行した後、クライアント装置２００がＰＯＳＴリクエストのデータを分割して送信している際に、サーバ装置３００がＨＴＴＰ処理よりも優先度の高い処理を要求された場合のシーケンスである。ここでは、優先度高の処理要求を受けた際にキャンセル待ち条件を満たしている場合について説明する。
なお、図１４において、Ｍ７１の処理開始からＭ８０の処理終了までの期間、Ｍ８２の処理開始からＭ８９の処理終了まで期間、およびＭ９２の処理開始からＭ９６の処理終了までの期間を、リクエスト受信中としている。
【００６１】
Ｍ７１〜Ｍ８０は、図１１のＭ１〜Ｍ１０と同様の処理であるため、説明は省略する。ただし、Ｍ７３において送信されるリクエストはＰＯＳＴリクエストであるため、リクエストボディのデータが存在する。
Ｍ８１において、イベント監視部３１０は、図９のＳ１４ｉにおいて解析したデータの続きがあると判定する（Ｓ１４ｊでＹｅｓ）。そのため、イベント監視部３１０は、ソケット状態を準備状態に更新する（Ｓ１４ｋ）。このとき、ソケットリスト３２０は状態Ｇから状態Ｐとなる。
【００６２】
Ｍ８２において、クライアント装置２００は、サーバ装置３００にリクエスト送信を行う（図４のＳ１）。このＭ８２において送信するデータは、例えば１０個に分割されたリクエストの９個目の分割であるものとする。
Ｍ８３において、接続監視部３０５は、クライアント装置２００からリクエストのデータを受信し、データをソケットに紐づけて管理部３０７が管理するソケットリスト３２０に登録する（図６のＳ１１ｅ）。このとき、ソケットリスト３２０は状態Ｐから状態Ｑとなる。
Ｍ８４においては、受信監視部３０８は、ソケットリスト３２０のソケットＩＤ＝１のソケットを受信条件に合致するソケットと判定する（図７のＳ１２ｂでＹｅｓ）。そのため、受信監視部３０８は、ソケット状態を準備状態から受信状態に更新する（Ｓ１２ｃ）。このとき、ソケットリスト３２０は状態Ｑから状態Ｆの状態になる。
そして、Ｍ８５において、受信監視部３０８は、受信イベントを管理部３０７が管理するイベントタスクに登録する（Ｓ１２ｄ）。
【００６３】
Ｍ８６においては、イベント監視部３１０は、受信イベントを受信し、イベントタスクの先頭の内容が受信イベントであると判定する（図９のＳ１４ｂで「受信」と判定）。その後、イベント監視部３１０は、受信イベントのソケットＩＤを参照し、該当するソケットのメッセージが存在することを確認する（Ｓ１４ｄでＹｅｓ）。また、イベント監視部３１０は、メッセージ状態がリクエスト中状態であることを確認する（Ｓ１４ｆで「受信」と判定）。そのため、イベント監視部３１０は、メッセージ状態をリクエスト中状態に更新する（Ｓ１４ｇ）。このとき、ソケットリスト３２０は状態Ｆのままである。
そして、サーバ装置３００がこの９個目の分割を受信中に、ＨＴＴＰ処理よりも優先度の高い処理を要求されたものとする。
【００６４】
Ｍ８７およびＭ８８は、図１２のＭ３０およびＭ３１と同様の処理であるため、説明は省略する。
Ｍ８９において、イベント監視部３１０は、受信データの解析を行う（Ｓ１４ｉ）。このとき、イベント監視部３１０は、ソケットのデータをメッセージに移動させるので、ソケットリスト３２０のデータは無に更新され、ソケットリスト３２０は状態Ｆから状態Ｇとなる。
次にＭ９０において、イベント監視部３１０は、Ｍ８９において解析したデータの続きがあると判定する（Ｓ１４ｊでＹｅｓ）。そのため、イベント監視部３１０は、ソケット状態を準備状態に更新する（Ｓ１４ｋ）。このとき、ソケットリスト３２０は状態Ｇから状態Ｐとなる。
【００６５】
Ｍ９１においては、イベント監視部３１０は、キャンセル準備イベントを受信する（Ｓ１４ｂで「キャンセル準備」と判定）。また、イベント監視部３１０は、ソケットに紐づくメッセージが存在することを確認し（Ｓ１４ｏでＹｅｓ）、ソケット状態が準備状態であることを確認する（Ｓ１４ｐで「準備」と判定）。そのため、イベント監視部３１０は、ソケット状態をキャンセル状態に更新し、メッセージ状態をリクエストキャンセル待ち状態に更新する（Ｓ１４ｔ）。このとき、ソケットリスト３２０は状態Ｐから状態Ｒとなる。
【００６６】
Ｍ９２において、クライアント装置２００は、サーバ装置３００にリクエスト送信を行う（図４のＳ１）。このＭ９２において送信するデータは、１０個に分割されたリクエストの１０個目の分割である。
Ｍ９３において、接続監視部３０５は、クライアント装置２００からリクエストのデータを受信し、データをソケットに紐づけて管理部３０７が管理するソケットリスト３２０に登録する（図６のＳ１１ｅ）。このとき、ソケットリスト３２０は状態Ｒから状態Ｓとなる。
Ｍ９４においては、受信監視部３０８は、ソケットリスト３２０のソケットＩＤ＝１のソケットを受信条件に合致するソケットと判定する（図７のＳ１２ｂでＹｅｓ）。そのため、受信監視部３０８は、ソケット状態をキャンセル状態から受信状態に更新する（Ｓ１２ｃ）。このとき、ソケットリスト３２０は状態Ｓから状態Ｔの状態になる。
そして、Ｍ９５において、受信監視部３０８は、受信イベントを管理部３０７が管理するイベントタスクに登録する（Ｓ１２ｄ）。
【００６７】
Ｍ９６においては、イベント監視部３１０は、受信イベントを受信し、イベントタスクの先頭の内容が受信イベントであると判定する（図９のＳ１４ｂで「受信」と判定）。その後、イベント監視部３１０は、受信イベントのソケットＩＤを参照し、該当するソケットのメッセージが存在することを確認する（Ｓ１４ｄでＹｅｓ）。また、イベント監視部３１０は、メッセージ状態がリクエストキャンセル待ち状態であることを確認する（Ｓ１４ｆで「キャンセル待ち」と判定）。そのため、イベント監視部３１０は、キャンセル待ち条件を満たすか否かを判定する。本実施形態において、キャンセル待ち条件は、「分割したリクエストのうち、９０％以上受信済みか？」である。
この時点において、１０個に分割されたリクエストのうち９個目の分割の受信を完了しているため、イベント監視部３１０は、キャンセル待ち条件を満たしていると判定する（Ｓ１４ｈでＹｅｓ）。そのため、イベント監視部３１０は、このＭ９６において、受信データの解析を行う（Ｓ１４ｉ）。このとき、ソケットのデータをメッセージに移動させるので、ソケットリスト３２０は状態Ｔから状態Ｕとなる。
【００６８】
次にＭ９７において、イベント監視部３１０は、Ｍ９６において解析したデータの続きがないと判定する（Ｓ１４ｊでＮｏ）。そのため、イベント監視部３１０は、ソケット状態を準備状態に更新し、メッセージ状態をリクエスト完了状態に更新する（Ｓ１４ｌ）。このとき、ソケットリスト３２０は状態Ｕから状態Ｈとなる。
そして、Ｍ９８において、記憶部３１２は、ＡＰＩ部３１１にレスポンスを送信する。
Ｍ９９においては、ＡＰＩ部３１１は、記憶部３１２から受信したデータを、ソケットＩＤに紐づくメッセージに登録し、送信イベントを管理部３０７が管理するイベントタスクに登録する。送信イベントには、ソケットＩＤが与えられる。
【００６９】
Ｍ１００では、イベント監視部３１０は、送信イベントを受信し（Ｓ１４ｂで「送信」と判定）、管理部３０７が管理する送信リストにメッセージを登録する（Ｓ１４ｃ）。
すると、Ｍ１０１において、送信監視部３０９は、管理部３０７が管理する送信リストの先頭を取得し（図８のＳ１３ｂ）、リクエスト完了状態のメッセージを取得する（Ｓ１３ｃで「送信」と判定）。そのため、送信監視部３０９は、ソケット状態を送信状態に更新し、メッセージ状態をレスポンス中状態に更新する（Ｓ１３ｄ）。このとき、ソケットリスト３２０は状態Ｈから状態Ｉとなる。
【００７０】
そして、Ｍ１０２において、レスポンス送信部３０４は、データ送信を行う（Ｓ１３ｅ）。Ｍ１０２におけるデータ送信の処理が終了すると、Ｍ１０３において、送信監視部３０９は、データの続きがないと判定し（Ｓ１３ｆでＮｏ）、ソケット状態を終了状態に更新する（Ｓ１３ｇ）。
また、Ｍ１０４において、メッセージ削除部３１０は、メッセージの削除を行う（Ｓ１３ｈ）。このとき、ソケットリスト３２０は状態Ｌとなる。
ソケットが状態Ｌとなったため、ソケットは接続監視部３０５によりソケットリスト３２０から削除され、処理は終了する。この後、ＨＴＴＰ処理より優先度の高い処理に切り替わる。
【００７１】
このように、本実施形態では、サーバ装置３００が、分割されたリクエストデータを受信中に、ＨＴＴＰ処理よりも優先度の高い処理を要求された場合、キャンセル待ち条件を満たす場合には、リクエストの受信を終了せずに完了させることができる。このため、クライアント装置は、リクエスト処理を初めからやり直す必要がなくなり、リソースの無駄を低減できる。
【００７２】
なお、図１４のＭ８２において受信するデータが、例えば１０個に分割されたリクエストの８個目以前の分割である場合には、Ｍ９６においては、イベント監視部３１０は、キャンセル待ち条件を満たしていないと判定する（Ｓ１４ｈでＮｏ）。この場合、イベント監視部３１０は、メッセージ状態をキャンセル状態に更新し（Ｓ１４ｍ）、キャンセルイベントを管理部３０７が管理するイベントタスクの先頭に登録する（Ｓ１４ｎ）。すると、イベント監視部３１０は、ソケット状態を終了状態に更新し（Ｓ１４ｖ）、メッセージの削除を行う（Ｓ１４ｗ）。このとき、ソケットリスト３２０は状態Ｌとなり、ソケットは接続監視部３０５によりソケットリスト３２０から削除され、処理は終了する。この後、ＨＴＴＰ処理より優先度の高い処理に切り替わる。
このように、本実施形態では、サーバ装置３００が、分割されたリクエストデータを受信中に、ＨＴＴＰ処理よりも優先度の高い処理を要求された場合、キャンセル待ち条件を満たさない場合には、リクエストの受信を終了させることができる。そのため、速やかにＨＴＴＰ処理よりも優先度の高い処理に切り替えることができる。
【００７３】
また、図１４のＭ８２において受信するデータが、例えば１０個に分割されたリクエストの最後の分割である場合には、Ｍ８９における受信データ解析の後、イベント監視部３１０は、データの続きがないと判定する（Ｓ１４ｊでＮｏ）。そのため、イベント監視部３１０は、ソケット状態を準備状態に更新し、メッセージ状態をリクエスト完了状態に更新する（Ｓ１４ｌ）。このとき、ソケットリスト３２０は状態Ｇから状態Ｈとなる。そして、その後は、Ｍ９８以降の処理が実行される。
このように、サーバ装置３００が分割されたリクエストデータの最後の分割を受信中に、サーバ装置３００がＨＴＴＰ処理よりも優先度の高い処理を要求された場合には、リクエストの受信を終了せずに完了させることができる。つまり、サーバ装置３００がキャンセル要求を受けた際に受信中のリクエストに続く分割されたリクエストが存在しない場合には、リクエストの受信が完了した後に終了処理を実行させることができる。これにより、クライアント装置２００は、リクエスト処理を初めからやり直す必要がなくなり、完了直前にＨＴＴＰ処理が強制終了されることに起因するリソースの無駄を低減することができる。
【００７４】
以上説明したように、本実施形態におけるサーバ装置３００は、クライアント装置２００からリクエストを受信し、当該リクエストに対するレスポンスを送信する、ＨＴＴＰによるデータ通信を行う通信装置である。サーバ装置３００は、データ通信を終了させる終了処理を実行可能であり、データ通信中に、当該データ通信のキャンセル要求を受けた場合、データ通信に関する所定の条件を満たしているか否かを判定し、判定結果に基づいて終了処理を実行する。具体的には、サーバ装置３００は、データ通信のキャンセル要求を受けた際に、上記の所定の条件を満たしていると判定された場合、データ通信が完了した後に終了処理を実行させるよう制御する。一方、サーバ装置３００は、データ通信のキャンセル要求を受けた際に、上記の所定の条件を満たしていないと判定された場合、データ通信が完了する前に終了処理を実行させるよう制御する。
【００７５】
このように、クライアント装置２００からリクエストを受信したサーバ装置３００がレスポンスを送信中にＨＴＴＰ処理のキャンセル要求を受けた場合、サーバ装置３００は、所定の条件を満たすか否かを判定する。そして、サーバ装置３００は、所定の条件を満たしている場合、レスポンスの送信を完了させてからレスポンスの送信をキャンセルし、所定の条件を満たしていない場合、レスポンスの送信をキャンセルする。
同様に、クライアント装置２００からリクエストを受信しているサーバ装置３００がリクエストを受信中にＨＴＴＰ処理のキャンセル要求を受けた場合、サーバ装置３００は、所定の条件を満たすか否かを判定する。そして、サーバ装置３００は、所定の条件を満たしている場合、リクエストの受信を完了させてからリクエストの受信をキャンセルし、所定の条件を満たしていない場合、リクエストの受信をキャンセルする。
したがって、レスポンスの送信やリクエストの受信といったＨＴＴＰ処理が強制終了されることに起因するリソースが無駄を低減することができる。
【００７６】
ここで、サーバ装置３００は、リクエストの受信およびレスポンスの送信の少なくとも一方を分割して行うことができ、上記所定の条件は、キャンセル要求を受けた際にデータ通信中であるデータに続く分割されたデータが存在しないことを含むことができる。
つまり、サーバ装置３００は、レスポンスの送信を分割して行っているときにキャンセル要求を受けた場合、送信中のレスポンスが分割された最後のレスポンスである場合には、レスポンスの送信が完了した後に終了処理を実行させることができる。また、サーバ装置３００は、リクエストの受信を分割して行っているときにキャンセル要求を受けた場合、受信中のリクエストが分割された最後のリクエストである場合には、リクエストの受信が完了した後に終了処理を実行させることができる。また、リクエストの受信およびレスポンスの送信を分割して行っていない場合にも、送信中のレスポンスや受信中のリクエストに続くデータが存在しないため、レスポンスの送信やリクエストの受信が完了した後に終了処理を実行させることができる。
このように、ＨＴＴＰ処理が完了直前である場合に、サーバ装置３００がキャンセル要求を受けた場合には、ＨＴＴＰ処理を完了させ、強制終了されることを回避することができる。したがって、リソースが無駄を適切に低減することができる。
【００７７】
また、上記所定の条件は、キャンセル要求を受けた際に実行中のデータ通信において通信済みのデータのサイズの合計が閾値以上であることを含んでもよい。この場合、サーバ装置３００は、レスポンスの送信を行っているときにキャンセル要求を受けた場合、それまでに送信した送信済みのレスポンスのサイズの合計が閾値以上である場合には、レスポンスの送信が完了した後に終了処理を実行させることができる。また、サーバ装置３００は、リクエストの受信を行っているときにキャンセル要求を受けた場合、それまでに受信した受信済みのリクエストのサイズの合計が閾値以上である場合には、リクエストの受信が完了した後に終了処理を実行させることができる。
【００７８】
さらに、上記所定の条件は、レスポンスの送信中にキャンセル要求を受けた場合、レスポンスの送信を開始してからの経過時間が閾値以上であることを含んでもよい。また、上記所定の条件は、リクエストの受信中にキャンセル要求を受けた場合、リクエストの受信を開始してからの経過時間が閾値以上であることを含んでもよい。
また、上記所定の条件は、レスポンスの送信中にキャンセル要求を受けた場合、当該キャンセル要求を受けてから送信済みのレスポンスのサイズの合計が閾値以上であることを含んでもよい。さらに、上記所定の条件は、リクエストの受信中にキャンセル要求を受けた場合、当該キャンセル要求を受けてから受信済みのリクエストのサイズの合計が閾値以上であることを含んでもよい。
また、上記所定の条件は、キャンセル要求を受けてからの経過時間が閾値以上であること含んでもよい。
このように、ＨＴＴＰ処理が完了に近い場合に、サーバ装置３００がキャンセル要求を受けた場合には、ＨＴＴＰ処理を完了させ、強制終了されることを回避することができる。したがって、リソースが無駄を適切に低減することができる。
【００７９】
（変形例）
以上が本発明の代表的な実施形態の一例であるが、本発明は、明細書及び図面に示す実施形態の範囲に限定されることなく、その要旨を変更しない範囲内で変形して実施できるものである。
上記実施形態において、リクエストの受信時やレスポンスの送信時に、ネットワーク１００、クライアント装置２００およびサーバ装置３００の異常等により再送待ちが発生することがある。そのため、キャンセル待ち条件に、「再送待ち状態でない」を指定してもよい。これにより、サーバ装置３００が再送待ち状態であるときにＨＴＴＰ処理よりも優先度の高い処理を要求された場合、ただちにＨＴＴＰ処理を終了することができる。したがって、再送待ち状態が、ＨＴＴＰ処理よりも優先度の高い処理への切り替えを阻害することを防ぐことができる。
【００８０】
また、上記実施形態において、キャンセル待ち条件にリクエストの種類を指定することで、特定のリクエストに対してのみ、キャンセル待ちを行うようにしてもよい。これにより、サーバ装置３００が複数の種類のリクエストを受けている際に、ＨＴＴＰ処理よりも優先度の高い処理を要求された場合、キャンセル待ち条件に指定したリクエストのみをキャンセル待ちにすることができる。そのため、優先すべきでないリクエスト処理の完了を待つことに起因して、ＨＴＴＰ処理より優先度の高い処理の開始が遅れることを抑制できる。
【００８１】
さらに、上記実施形態において、クライアント装置２００からの分割されたリクエストデータの受信が完了する前にＨＴＴＰ処理が終了された場合、サーバ装置３００は受信したリクエストの内容を記憶部３１２で記憶したままにしておいてもよい。この場合、記憶するリクエストの内容は、通信相手の情報やリクエストの種類、リクエストをどこまで受信したかの情報を含むことができる。そして、サーバ装置３００は、分割されたリクエストデータのどの分割までを受信したかの情報をクライアント装置２００に送信する。送信する情報は、レスポンスに含めてもよいし、ネットワーク１００を介した他の通信方法で送信してもよい。これにより、再度、クライアント装置２００が同一のリクエストをサーバ装置３００に送信する場合、前回送信したリクエストデータの途中から送信するよう制御することができ、リソースの無駄を低減できる。
なお、リクエストデータの受信が完了する前にＨＴＴＰ処理が終了された場合、クライアント装置２００がリクエストの内容を記憶したままにしておいてもよい。この場合、記憶するリクエストの内容は、通信相手の情報やリクエストの種類、リクエストをどこまで送信したかの情報を含むことができる。この場合にも、上記と同様の制御が可能となり、リソースの無駄を低減できる。
【００８２】
同様に、上記実施形態において、サーバ装置３００による分割されたレスポンスデータの送信が完了する前にＨＴＴＰ処理が終了された場合、クライアント装置２００は受信したレスポンスの内容をレスポンス受信部２０２で記憶したままにしておいてもよい。この場合、記憶するレスポンスの内容は、通信相手の情報やリクエストの種類、レスポンスをどこまで受信したかの情報を含むことができる。そして、クライアント装置２００は、分割されたレスポンスデータのどの分割までを受信したかの情報をサーバ装置３００に送信する。送信する情報は、リクエストに含めてもよいし、ネットワーク１００を介した他の通信方法で送信してもよい。これにより、再度、クライアント装置２００が同一のリクエストをサーバ装置３００に送信する場合、前回受信したレスポンスデータの途中から受信することができ、リソースの無駄を低減できる。
なお、レスポンスデータの送信が完了する前にＨＴＴＰ処理が終了された場合、サーバ装置３００がレスポンスの内容を記憶したままにしておいてもよい。この場合、記憶するレスポンスの内容は、通信相手の情報やリクエストの種類、レスポンスをどこまで送信したかの情報を含むことができる。この場合にも、上記と同様の制御が可能となり、リソースの無駄を低減できる。
以上のように、クライアント装置２００およびサーバ装置３００の少なくとも一方は、サーバ装置３００においてデータ通信が完了する前に終了処理が実行された場合、終了されたデータ通信の内容を記憶しておいてもよい。そして、記憶された内容に基づいて、終了されたデータ通信の続きからデータ通信を行わせるように制御してもよい。
【００８３】
また、上記実施形態では、クライアント装置２００をスマートフォン、サーバ装置３００をデジタルカメラとする場合について説明したが、上記に限定されるものではなく、ＨＴＴＰによるデータ通信を実行可能なあらゆる通信装置に適用可能である。
【００８４】
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記録媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００８５】
１００…ネットワーク、２００…クライアント装置、３００…サーバ装置、３０１…リクエスト受信部、３０２…生成部、３０３…レスポンス生成部、３０４…レスポンス送信部、３０５…接続監視部、３０６…操作部、３０７…管理部、３０８…受信監視部、３０９…送信監視部、３１０…イベント監視部、３１１…ＡＰＩ部、３１２…記憶部、３１３…メッセージ生成部、３１４…メッセージ削除部、１０００…通信システム
【図１】
2020102089.tif 000003
【図２】
2020102089.tif 000004
【図３】
2020102089.tif 000005
【図４】
2020102089.tif 000006
【図５】
2020102089.tif 000007
【図６】
2020102089.tif 000008
【図７】
2020102089.tif 000009
【図８】
2020102089.tif 000010
【図９】
2020102089.tif 000011
【図１０】
2020102089.tif 000012
【図１１】
2020102089.tif 000013
【図１２】
2020102089.tif 000014
【図１３】
2020102089.tif 000015
【図１４】
2020102089.tif 000016