JP6576099B2

JP6576099B2 - 通信装置、通信装置の制御方法、プログラム、および、通信システム

Info

Publication number: JP6576099B2
Application number: JP2015105820A
Authority: JP
Inventors: 和矢谷口; 健介安間; 幸夫沼上; 國松　亮; 亮國松; 智哉酒井
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2015-05-25
Filing date: 2015-05-25
Publication date: 2019-09-18
Anticipated expiration: 2035-05-25
Also published as: JP2016218923A; US20160353513A1; US10219314B2

Description

本発明は、通信装置、通信装置の制御方法、通信プログラム、および、通信システムに関する。

インターネット標準技術として一般に広く利用されているプロトコル(通信規約)の１つに、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）がある。現在、インターネット標準化団体(ＩＥＴＦ：ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ)において、ＨＴＴＰの新しいバージョン(ＨＴＴＰ／２)が策定された。ＨＴＴＰ／２は、既存の技術であるＨＴＴＰ１．１に互換性を有した上で、新たな機能が追加されている。たとえば、ＨＴＴＰ／２では、１つのコネクション内部に、仮想チャンネルを通る双方向のフレームの流れであるストリームを複数もたせることができる。ＨＴＴＰリクエスト−レスポンスは単一のストリームに割り当てられ、ひとつのストリームは他のストリームとは独立しているため、リクエストのブロックや停止が、他のリクエストの進捗を妨げることはない。

また、ネットワークに含まれるファイヤウオールやＰＰＰｏＥ、ＮＡＴ等のタイムアウト、すなわち設定時間を超えた無通信状態の継続に起因するコネクションの消滅に対処するために、コネクションにおける無通信状態が所定時間に達するとコネクションを維持するためのパケットをサーバ装置へ送信し、またパケット不通状態を検知した際に、その所定時間を短くする技術が提案されている（特許文献１）。

特開２０１４−１９９９９８号公報

特許文献１記載の先行技術では、コネクション上で少なくとも２つのストリームを確立する通信においてのコネクション維持制御の考慮がされていなかった。上述したように１つのコネクション内のストリームは互いに独立しており、或るコネクション上でひとつのストリームが通信していた場合でも、別のストリームではコネクションを維持するための不要な通信を発生させてしまうことがあるという課題があった。

本発明は上記従来例に鑑みて成されたもので、不要な通信を抑制しつつコネクション維持を実現する通信装置、通信装置の制御方法、通信プログラム、および、通信システムを提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

本発明の第１の側面によれば、通信装置であって、
他の通信装置との間で設定されるコネクションに属する１以上の論理的な通信路としての１以上のストリームを介して前記他の通信装置と通信する通信手段と、
前記コネクションに属するストリームの予約のための通知を受信する受信手段と、
前記受信手段により前記ストリームの予約のための通知が受信された後に、前記通信手段により前記他の通信装置との間で前記コネクションに属する１以上のストリームの何れを介した通信もなされていない無通信時間が所定時間に達した場合に、前記他の通信装置に対して前記コネクションを維持するためのメッセージを送信する処理を行う接続維持手段とを有することを特徴とする通信装置が提供される。
また本発明の第２の側面によれば、通信装置であって、
他の通信装置との間で設定されるコネクションに属する複数の論理的な通信路としての複数のストリームを介して前記他の通信装置と通信する通信手段と、
前記通信手段により、前記コネクションに属する複数のストリームである第１ストリームと第２ストリームとのうち、前記第１ストリームを介した通信が所定時間以上なされていない場合であり且つ前記第２ストリームを介した通信も前記所定時間以上なされていない場合には、前記他の通信装置に対して前記コネクションを維持するためのメッセージを送信し、前記第１ストリームを介した通信が前記所定時間以上なされていない場合であり且つ前記第２ストリームを介した通信がなされていない無通信時間が前記所定時間未満である場合には、前記他の通信装置に対して前記メッセージを送信しない接続制御手段とを有することを特徴とする通信装置が提供される。

本発明によれば、不要な通信を抑制しつつコネクション維持を実現することができる。

実施形態１に係る通信装置１０１のシステム構成図である通信装置１０１のモジュール構成を示す図である。通信装置１０１がＨＴＴＰ／２を使用してサーバ１０２とサーバプッシュの維持処理を行う際のフローチャートであるＨＴＴＰ／２を使用した通信において、通信装置１０１が通信判断を行い、サーバ１０２に接続維持を行う際のシーケンス図である実施形態１に係わるウェブブラウザ画面を示した図である。ＨＴＴＰ／２を使用した通信において、通信装置１０１がＷｅｂブラウザ上でＷｅｂページを表示する際のフローチャートである。ＨＴＴＰ／２を使用した通信において、通信装置１０１が、図６のフローチャートにてＷｅｂページを表示中または表示後サーバ１０２からサーバプッシュを受信し、アイコンを表示する場合のフローチャートである。実施形態２に係るサーバ１０２のシステム構成図であるＨＴＴＰ／２を使用した通信において、サーバ１０２が通信判断を行い、通信装置１０１に接続維持を行う際のシーケンス図である

［実施形態１］
以下、本発明の実施の形態について、図面を参照して説明する。図１は実施形態１に係る通信システムのシステム構成図である。通信装置１０１とサーバ１０２とはネットワーク１００を介して接続されている。本実施形態におけるネットワーク１００は、インターネット、ＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）、等の複合であっても実現できる。通信装置１０１とサーバ１０２は、例えば、無線アドホックネットワークを用いて接続しても良い。

通信装置１０１はネットワーク１００に接続する通信装置である。通信装置１０２はネットワーク１００に接続し通信装置１０１からの通信を受け付けるサーバである。本実施形態では、サーバ１０２は１台のＰＣで実現しているが、サーバ１０２は、プロキシサーバを含めても良いし、クラウド上で分散して配置されていても良い。通信装置１０１はネットワーク１００を通じて、サーバ１０２とＨＴＴＰ／２を使用して通信を行う。すなわち、通信装置１０１，１０２とも、ＴＣＰ／ＩＰのプロトコルスタックを有している。通信装置１０１はＨＴＴＰ／２に対応したクライアントであり、通信装置１０２は同じくサーバである。

各通信装置はいずれも、図１の通信装置１０１に示したように、通信機能を提供する通信部１０１３を有した、ネットワーク１００に接続可能なコンピュータにより実現することができる。このコンピュータは汎用コンピュータの構成を有していればよく、通信部１０１３に加えて、たとえばプロセッサ（ＣＰＵ）１０１１、メモリ１０１２、ファイルストレージ１０１４、入力部と出力部（表示部）とを含むヒューマンインターフェイスデバイス１０１５などを有する。通信に関する機能は、たとえば、物理層やデータリンク層の一部はハードウェアにより実現され、残りの一部やその上位層、たとえばＴＣＰ／ＩＰプロトコルスタックは通常、そのためのプログラムをプロセッサにより実行させることで実現される。またそのプログラムは後述するＨＴＴＰ／２に対応したウェブブラウザ（あるいはサーバ）を含み、その処理手順の一部が図３、図６、図７に示した手順である。

＜通信装置１０１のモジュール構成＞
図２は、通信装置１０１のモジュール構成を示す図である。２００は、各モジュールが接続するバスである。２０１は、ＴＣＰ／ＩＰ処理、及びＴＬＳ（ＴｒａｎｓｐｏｒｔＬａｙｅｒＳｅｃｕｒｉｔｙ）処理を行う通信部である。

２０２は、サーバ１０２からのＨＴＴＰ／２通信を受信する受信部である。２０３は、待機部２０４にて、不要なメッセージ処理を低減する為の待機をおこなうか否かを判断する待機判断部である。２０４は、維持判断部２０６による判断の基準となる時間間隔を制御するために待機する待機部である。２０５は、維持判断部２０６及び、接続維持部２０７の処理を終了するか判断する終了判断部である。２０６は、接続維持部２０７にて接続維持をするか否かを判断する維持判断部である。２０７は、接続を維持するために、サーバ１０２と通信を行う接続維持部である。

ここでいう接続とは、２つのエンドポイント（本例では通信装置１０１，１０２）の間のトランスポート層のコネクションであり、ＨＴＴＰ／２では、１コネクションに複数のストリームを含めることができる。コネクションはたとえば送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号、プロトコルＩＤといういわゆる５タプルで定められる。ストリームとは、１つのコネクション内部の仮想チャンネルを通る双方向のフレームの流れであり、論理的な（あるいは仮想的な）通信路を構成しており、少なくともコネクション内において固有のＩＤが割り当てられる。１対のＨＴＴＰリクエスト−レスポンスは単一のストリームに割り当てられ、ひとつのストリームは他のストリームとは独立している。そのため、或るストリームにおけるリクエストのブロックや停止が、他のストリームにおけるリクエストの進捗を妨げることはない。

２０８は、サーバ１０２からサーバプッシュされたメッセージを受信するメッセージ受信部である。サーバプッシュとはＨＴＴＰ／２の機能のひとつであり、クライアントが事前に開始したリクエストに関連するレスポンスを、そのレスポンスのためのリクエストがなくとも、サーバがクライアントに送信(または「プッシュ」)する機能である。サーバプッシュとはサーバによるデータ或いはフレームの非同期の送信ともいえる。

２０９は、ストリームごとにサーバ１０２にフレームを送信するストリーム制御部である。なお、本例では、ストリーム制御部２０９は４つのストリームを処理するが、これに限るものではなく、プロトコルで規定するストリームの最大数まで処理を行っても良い。２１０は、ユーザが入力したＵＲＬを取得するＵＲＬ取得部である。２１１は、サーバ１０２からＷｅｂページを取得するＷｅｂページ取得部である。２１２は、ＷｅｂページをＷｅｂブラウザ上に表示するＷｅｂページ表示部である。２１３は、Ｗｅｂページに紐づいたコンテンツデータを取得するコンテンツ取得部である。２１４は、コンテンツデータをＷｅｂブラウザ上に表示するコンテンツ表示部である。２１５は、Ｗｅｂページ情報から、サーバプッシュをするか判断するサーバプッシュ判断部である。

なお、図２においては、たとえば、通信部２０１の一部または全部はＨＴＴＰ／２の下位レイヤに属し、受信部２０２〜サーバプッシュ判断部２１５はＨＴＴＰ／２に属するものとして構成される。これらＨＴＴＰ／２の機能は、たとえばウェブブラウザのプログラムを、プロセッサにより実行して実現できる。

＜ブラウザ画面例＞
図５は実施形態１に係わるウェブブラウザ画面を示した図である。ＵＲＬ表示欄５０１は、ウェブブラウザページのＵＲＬを表示する欄である。Ｗｅｂページ画面５０２は、本実施形態におけるＷｅｂページを表示するウィンドウ画面である。Ｗｅｂページ画面５０２は、Ｗｅｂページ表示部２１２により、ＨＴＭＬ形式で記述されたＷｅｂデータに基づいて構成され、表示される。ステータスアイコン５０３は、Ｗｅｂページ画面５０２内に表示するアイコンである。ここでは、ステータスアイコン５０３はプリンタの状態を示す。なお、ステータスアイコン５０３はアイコン以外にも、画像やテキストといったコンテンツデータや、スタイルシートであっても良い。また例えば、ステータスアイコン５０３は、ＬＥＤや音などで示すこともできる。コンテンツ画面５０４は、Ｗｅｂページ画面５０２に紐づいたコンテンツデータである。

図５の例では、例えばサーバ１０２は多機能複写機等のプリンタデバイスに組み込まれたサーバであり、クライアント１０１はコンピュータである。そしてクライアント端末１０１は、サーバ１０２に対してＵＲＬを指定して情報、たとえばサーバ１０２を搭載したプリンタデバイスのデバイス情報をコンテンツとして要求する。クライアント端末１０１のＷｅｂページ表示部２１２は、サーバ１０２からの応答として受信したデバイス情報をコンテンツ画面５０４に配置し、ステータス情報をステータスアイコン５０３に配置してＷｅｂページを構成し、Ｗｅｂページ画面５０２に表示している。このように、ＨＴＴＰクライアントである通信装置１０１、特にそこで実行されるＷｅｂブラウザは、サーバ１０２からＨＴＴＰ／２を通してデータを取得し、Ｗｅｂページを構成して表示することができる。

＜Ｗｅｂページの表示＞
図６はＨＴＴＰ／２を使用した通信において、通信装置１０１がＷｅｂブラウザ上でＷｅｂページを表示するためのフローチャートである。

ＵＲＬ取得部２１０は、ユーザが入力したＵＲＬ表示欄５０１からＵＲＬを取得する（Ｓ６０１）。Ｗｅｂページ取得部２１１は、Ｓ６０１で取得したＵＲＬを指定してサーバ１０２にＨＴＴＰリクエストを送信し、そのレスポンスとしてサーバ１０２からインデックスページを示すＨＴＭＬファイルｉｎｄｅｘ．ｈｔｍｌ（これをインデックスファイルとも呼ぶ。）を取得する（Ｓ６０２）。このときクライアントとサーバとの間にコネクションが設定され、更にそこにストリームが設けられ、１つのストリームでＨＴＴＰリクエストとレスポンスが交換される。なおコネクションは新たに設定されるとは限らず、既に完了したリクエストーレスポンスのために設定されたコネクションを再利用することもできる。

サーバプッシュ判断部２１５は、Ｓ６０２で取得したデータ（たとえばインデックスファイルｉｎｄｅｘ．ｈｔｍｌ）から、インデックスファイルｉｎｄｅｘ．ｈｔｍｌに関連付けられたサーバプッシュがあるか（あるいは予約されたか）否か判断する（Ｓ６０３）。本例では、サーバ１０２は、サーバプッシュがあることをインデックスファイルｉｎｄｅｘ．ｈｔｍｌの中に記録し、クライアントである通信装置１０１に通知する。Ｓ６０３ではこの通知に基づいて判断を行う。これは一例であって、サーバ１０２から通信装置１０１に対して通知方法を取り決めておけば、どのような方法であってもよい。たとえば受信部２０２にてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを受信した否かでサーバプッシュの有無を判断することもできる。この場合、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを受信していれば、サーバプッシュがあるものと判定する。またサーバプッシュ用の独自タグを定義し、そのタグがあるか判断しても良い。

ステップＳ６０３においてサーバプッシュがあると判断した場合はＳ６０４に進む。サーバプッシュがない場合はＳ６０５に進む。サーバプッシュがあると判断した場合、サーバプッシュ判断部２１５は、図３の接続維持のための処理をおこなう為のサーバプッシュフラグを立てる或いはセットする（Ｓ６０４）。ここではサーバプッシュフラグを立てているが、フラグを立てずに図３で後述する接続維持フローをおこなうといった方法でもよい。なお、サーバプッシュに用いられるストリームの予約はＰＵＳＨ＿ＰＲＯＭＩＳＥフレームにより通知されることから、サーバプッシュフラグは対応するストリームに関連づけてセットされてもよい。

Ｗｅｂページ表示部２１２は、受信したインデックスファイルｉｎｄｅｘ．ｈｔｍｌをＷｅｂページ画面５０２に表示する（Ｓ６０５）。コンテンツ取得部２１３は、インデックスファイルｉｎｄｅｘ．ｈｔｍｌに紐づいたコンテンツデータを取得する（Ｓ６０６）。本実施形態では、インデックスファイル名をｉｎｄｅｘ．ｈｔｍｌとしているが、他のｈｔｍｌファイル名であってもよいし、他形式のファイルであっても良い。コンテンツ表示部２１４は、コンテンツ取得部２１３にて取得したコンテンツデータをコンテンツ画面５０４に表示する（Ｓ６０５）。本実施形態では、コンテンツ取得部２１３とコンテンツ表示部２１４におけるコンテンツデータを１つとしているが、２つや３つでも良い。また、コンテンツデータの形式は画像やテキストやスタイルシートでも良い。本実施形態では、Ｗｅｂブラウザ上でのフローチャートについて記述したが、カメラやプリンタの画面表示であってもよい。

図７は、ＨＴＴＰ／２を使用した通信において、通信装置１０１が、図６のフローチャートにてＷｅｂページを表示中、もしくは表示後、サーバ１０２からサーバプッシュを受信し、アイコンを表示する場合のフローチャートである。メッセージ受信部２０８は、サーバ１０２から、サーバプッシュを受信する（Ｓ７０１）。コンテンツ表示部２１４は、メッセージ受信部２０８にて受信したコンテンツデータをステータスアイコン５０３に表示する（Ｓ７０２）。図７の手順は、サーバプッシュを受信する都度実行される。画面表示中にステータスが変化すると、サーバ１０２がステータスをプッシュし、通信装置１０１は受信したステータス情報に応じてステータスアイコンを更新する。このためステータスアイコンはほぼ実時間でステータスの変化を反映できる。

＜コネクション維持処理＞
図３はＨＴＴＰ／２を使用した通信において、通信装置１０１が通信判断を行い、サーバ１０２とのコネクションを維持するための接続維持を行うためのフローチャートである。本フローは、Ｓ６０４にてセットされるサーバプッシュフラグを監視し、それが立てられた時に実行開始される。図示していないが、実行を開始するとサーバプッシュフラグをリセットする。なお、上記タイミング以外にも、通信装置１０１がＰＵＳＨ＿ＰＲＯＭＩＳＥフレームによるサーバプッシュの予約要求を受信した時であってもよい。ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームはサーバプッシュのために用いるストリームの予約を通信装置１０１に通知するフレームでもある。

待機判断部２０３は、待機部２０４にて待機するか否かを判断する（Ｓ３０２）。待機判断部２０３は、すでにサーバプッシュ予約済のストリームがある場合は処理を終了する。すでにサーバプッシュ予約済のストリームがない場合はＳ３０３に進む。待機判断部２０３は、たとえばサーバプッシュ予約済のストリーム一覧を登録したテーブル（予約済みストリームテーブルとも呼ぶ）中の予約済みのストリームの有無からステップＳ３０２の判断をすることができる。予約済みストリームテーブルはコネクションごと保持される。ＰＩＮＧフレームによる接続維持処理は、１つのコネクション上では１つのストリームについて行えば十分である。サーバプッシュ予約済のストリームが既にあれば、そのストリームについてコネクション維持が行われるため、同じコネクション中のその他のストリームについては、コネクション維持は不要である。そのためステップＳ３０２ではサーバプッシュ予約済の既存のストリームの存在を判定し、存在すればコネクション維持のための手順をスキップすることで、不要な接続維持処理を省くことができる。このようにステップＳ３０２では、予約済みストリームが有無により、既にコネクション維持のための処理が既に実行されているかどうかを判定している。

なお、ステップＳ３０２の直後には、その判定結果がＹＥＳであれＮＯであれ、ステップＳ６０３で判定されたサーバプッシュのために予約されるストリームを、新規の予約済みストリームとして予約済みストリームテーブルに登録する。登録される情報はストリームＩＤでよい。予約済みストリームテーブルは、関連するコネクションに含まれているサーバプッシュにより予約済みのストリームを示す。予約済みストリームがクローズする都度、当該ストリームが予約済みストリームテーブルから削除される。

待機判断部２０３はステップＳ３０２では、上述のように予約済みストリームテーブルに登録されたストリームの有無から判断しても良いし、ストリームの状態がｒｅｓｅｒｖｅｄ（ｒｅｍｏｔｅ）もしくは、ｈａｌｆｃｌｏｓｅｄ（ｌｏｃａｌ）状態であるストリームがあるか否かで判断しても良い。該当するストリームがあれば、ステップＳ３０２では既にサーバプッシュ予約済のストリームがあると判定される。ＨＴＴＰ／２によれば、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームのストリームは、サーバ上では"ｈａｌｆｃｌｏｓｅｄ（ｒｅｍｏｔｅ）"状態に、クライアント上では"ｈａｌｆｃｌｏｓｅｄ（ｌｏｃａｌ）"状態にされる。また、異なるストリームにおけるＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの受信により、今後使用するストリームが予約されると、予約済みストリームの状態は"ｒｅｓｅｒｖｅｄ（ｒｅｍｏｔｅ）"に遷移する。このためこれらの状態を持つストリームが、Ｓ６０３で新たに通知されたサーバプッシュに係るストリーム以外にもあれば、ステップＳ３０２でサーバプッシュ予約済みのストリームがあると判定することが行うことができる。新たに予約されたストリームＩＤはＰＵＳＨ＿ＰＲＯＭＩＳＥフレームにより通知され、ストリームの同一性はたとえばストリームＩＤにより判定できる。

また、予約済みストリームテーブルは、予約済みストリームごとにエントリを登録し、また削除できるが、コネクション単位で管理するのであれば、予約済みストリームテーブルは、少なくとも１つの予約済みストリームが監視対象のコネクションに含まれていることを示す情報であれば十分である。ただしこの情報はコネクション単位で設定されるため、この情報のセットはサーバプッシュのストリームの新たに予約の都度行えばよいが、リセットは、予約済みストリームがクローズされたなら、コネクション内の予約済みストリームが他にないことを判定し、他にない場合に限って行うように構成する必要がある。

さてステップＳ３０２において、既存のサーバプッシュ予約済みのストリームがないと判定された場合、ステップＳ３０３以降で、コネクション維持処理の実行が開始される。待機部２０４は、所定の待機時間、待機する（Ｓ３０３）。ここでの待機時間とは、通信装置１０１が保持する待機時間でも良いし、サーバ１０２が保持する待機時間でも良い。例えば、通信装置１０１とサーバ１０２の間でコネクションを維持できる時間を測定し、その値よりも小さい値であってもよい。また、待機時間はそれらの時間の一部を用いて計算されたランダムな時間であってもよい。

終了判断部２０５は、維持判断部２０６及び、接続維持部２０７の処理を終了するか判断するために、例えば予約済みストリームテーブルあるいはストリームの状態を参照して、関連するコネクションにサーバプッシュ予約済のストリームが残っているか否かを判定する（Ｓ３０４）。サーバプッシュ予約済のストリームが残っている場合はＳ３０５に進む。サーバプッシュ予約済のストリームが残っていない場合はサーバプッシュのためにコネクションを維持する必要はもはや無いので処理を終了する。なお、あるコネクション内の予約済みストリームがクローズされると、予約済みストリームテーブルから該当するストリームが消去される。

維持判断部２０６は、接続維持部２０７が接続維持を行うかを判断する（Ｓ３０５）。待機部２０４が待機中に、維持すべきコネクション上で通信があった場合は、接続維持（コネクション維持）は不要と判断してＳ３０３に進み、待機中にコネクション上で通信がなかった場合は必要と判断してＳ３０６に進む。なおステップＳ３０５の判定は、たとえば維持すべきコネクション上で行われるフレームの送信および受信の時刻を記録しておき、その時刻が、待機中に送受信があったことを判定できる。またステップＳ３０５からステップＳ３０３に分岐する場合には、ステップＳ３０３においては、最後の通信時刻から現在時刻までの時間を所定の待機時間から差し引き、その時間の満了を待機する。このようにすることで、最後の通信の時刻を起点として所定時間待機できる。

ステップＳ３０６では、接続維持部２０７は、ＰＩＮＧフレームを送受信しＳ３０３に進む。なお、ここでのＰＩＮＧフレームはＨＥＡＤＥＲＳフレームなど、ストリームで通信を行うフレームタイプであってもよい。また、サーバプッシュのストリームを利用したＤＡＴＡフレームであってもよい。

以上の手順により、無通信状態の時間は最大でもステップＳ３０３で待機する待機時間（厳密には処理遅延が含まれる）となり、無通信時間に起因した、サーバプッシュに利用されるはずのコネクションの消滅を防止できる。

なお、ステップＳ３０３における待機に代えて、監視対象のコネクションでフレームの送信または受信があればその都度そのタイマを所定時間に設定し直すことで無通信状態の時間の監視を実現することもできる。このように構成すれば、所定時間にわたり通信がない場合に限ってタイマが満了するので、ステップＳ３０４でＹＥＳと判定されたなら、Ｓ３０５を行うことなくステップＳ３０６でＰＩＮＧフレームの送受信を行ってよい。

＜コネクション維持のシーケンス＞
図４はＨＴＴＰ／２を使用した通信において、通信装置１０１がサーバ１０２に接続維持を行うためのシーケンス図である。

Ｍ４０１において、通信部２０１は、サーバ１０２とＨＴＴＰ／２通信を開始し、コネクション１を生成する。

Ｍ４０２において、ストリーム制御部２０９は、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＨＥＡＤＥＲＳフレームを、コネクション１に含まれるストリーム１でサーバ１０２に送信する。ＨＥＡＤＥＲＳフレームはストリームの開始に使用される。なおＭ４０５までの通信はストリーム１を介して行われる。Ｍ４０３において、受信部２０２は、サーバ１０２からＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを受信する。ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、送信者（サーバ１０２）が、開始する予定のストリームを事前にピアエンドポイント（この場合には通信装置１０１）に通知するために使用するフレームであり、予約するストリームの識別子を含む。なお、Ｍ４０３はＭ４０４の後に行っても良い。Ｍ４０４において、受信部２０２は、サーバ１０２から、Ｍ４０２で送信したＨＥＡＤＥＲＳフレームに対するＨＥＡＤＥＲＳフレームレスポンスを受信する。Ｍ４０５において、ストリーム制御部２０９は、サーバ１０２から、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＤＡＴＡフレームを受信する。

ＤＡＴＡフレームは、ＨＴＴＰリクエストまたはレスポンスのペイロードを伝えるフレームである。またＥＮＤ＿ＳＴＲＥＡＭは、特定のストリームに送信する最後のフレームであることを示すフラグである。ＥＮＤ＿ＳＴＲＥＡＭフラグが設定されたフレームをサーバ１０２が送信、またはクライアント１０１が受信したときにストリームがクローズされる。このフラグを設定することで、ストリームは"ｈａｌｆｃｌｏｓｅｄ"状態または"ｃｌｏｓｅｄ"状態に遷移する。

なお、Ｍ４０４〜Ｍ４０５において、ＨＥＡＤＥＲＳフレーム受信、ＤＡＴＡフレーム(ＥＮＤ＿ＳＴＲＥＡＭ)受信のシーケンスとしているが、ＨＥＡＤＥＲＳフレーム受信、ＤＡＴＡフレーム受信、ＤＡＴＡフレーム(ＥＮＤ＿ＳＴＲＥＡＭ)受信や、ＨＥＡＤＥＲＳフレーム(ＥＮＤ＿ＳＴＲＥＡＭ)受信というシーケンスでもよい。

Ｍ４０６において、待機判断部２０３はこの時点ではサーバプッシュ予約済のストリームが他にないと判断し（Ｓ３０２でＮｏ）、待機部２０４にて待機時間待機する（Ｓ３０３）。この後、たとえばストリーム２がサーバプッシュ予約済みストリームとしてテーブルに登録される。またストリーム２がサーバプッシュのために予約され、通信装置１０１から見たその状態は例えば"ｒｅｓｅｒｖｅｄ（ｒｅｍｏｔｅ）"である。

Ｍ４０７，Ｍ４０８では、通信装置１０１は、予約されたストリーム２を通したプッシュレスポンスをサーバ１０２から受信する。Ｍ４０７において、メッセージ受信部２０８は、サーバ１０２からＨＥＡＤＥＲＳフレームを受信する。Ｍ４０７からサーバ１０２によるプッシュレスポンスが始まる。プッシュレスポンスとは、予約されたサーバプッシュに係るレスポンスの送信である。Ｍ４０９まで、及びＭ４１９〜Ｍ４２１の通信はプッシュレスポンスであり、ストリーム２を介して行われる。Ｍ４０８において、メッセージ受信部２０８は、サーバ１０２から、ＤＡＴＡフレームを受信する。このＤＡＴＡフレームのペイロードは、たとえばサーバ１０２が組み込まれたプリンタのステータス情報である。Ｍ４０９において、ストリーム制御部２０９は、Ｍ４０７、Ｍ４０８に対するＨＥＡＤＥＲＳフレームレスポンスをサーバ１０２に送信する。サーバ１０２はこの時点でストリーム２をクローズさせておらず、ストリーム２は存続するということである。

Ｍ４１０において、終了判断部２０５は、Ｍ４０６にて所定時間待機後、サーバプッシュ予約中のストリーム（この例ではストリーム２）があると判断し（Ｓ３０４でＹｅｓ）、維持判断部２０６は、待機中に通信があったと判断し（Ｓ３０５でＹｅｓ）、待機部２０４にて待機時間待機する（Ｓ３０３）。待機中に通信があったことの判定は、たとえばＭ４０９で送信したフレームの送信時刻から判定される。

Ｍ４１１において、ストリーム制御部２０９は、ＨＥＡＤＥＲＳフレームをサーバ１０２に送信する。Ｍ４１２において、ストリーム制御部２０９は、コンテンツ取得のために、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＤＡＴＡフレームをサーバ１０２に送信する。Ｍ４１３において、受信部２０２は、サーバ１０２から、Ｍ４１１、Ｍ４１２に対する、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＨＥＡＤＥＲＳフレームレスポンスを受信する。ストリーム３はここでクローズする。

Ｍ４１４において、終了判断部２０５は、Ｍ４１０にて待機後、サーバプッシュ予約中のストリームがあると判断し（Ｓ３０４でＹｅｓ）、維持判断部２０６は、待機中に通信があったと判断し（Ｓ３０５でＹｅｓ）、待機部２０４にて待機時間待機する（Ｓ３０３）。

Ｍ４１５において、終了判断部２０５は、Ｍ４１４にて所定時間待機後、サーバプッシュ予約中のストリーム（ストリーム２）があると判断し（Ｓ３０４でＹｅｓ）、維持判断部２０６は、待機中にストリーム２を含む監視対象のコネクション上で通信がなかったと判断し（Ｓ３０５でＮｏ）、接続維持部２０７にてＰＩＮＧフレームをサーバ１０２と送受信する（Ｓ３０６）。Ｍ４１５の時点において監視対象のコネクションにおける最後の通信は、Ｍ４１３でサーバ１０２からストリーム３において受信したレスポンスであり、Ｍ４１４で待機を開始する前のものである。したがって待機中にストリーム２を含む監視対象のコネクション上で通信がなかったと判断されている。なお、ここでのＰＩＮＧフレームはＨＥＡＤＥＲＳフレームなど、通信を行うフレームタイプであってもよい。後述のＭ４１６とＭ４１７は、Ｍ４１５のＰＩＮＧフレーム送受信シーケンスに対応する。

Ｍ４１６において、ストリーム制御部２０９は、ＰＩＮＧフレームをサーバ１０２に送信する。ＰＩＮＧフレームは、本来アイドル中のコネクションがまだ機能しているかどうかを確認するために使用されるフレームであるが、本実施形態では、コネクションを維持するために使用される。Ｍ４１７において、受信部２０２は、サーバ１０２から、Ｍ４１６に対する、ペイロードにＡＣＫフラグを指定したＰＩＮＧフレームを受信する。このＰＩＮＧフレームの送受信により、コネクション中に介在する例えばファイヤウオールやＰＰｏＥ、ＮＡＴ等のタイムアウトを事前に防止し、コネクションを維持することができる。なおコネクション維持のためには少なくともフレームを送信すればよいので、サーバ１０２からのレスポンスはオプションとしても良い。

Ｍ４１８において、待機部２０４にて待機時間待機する（Ｓ３０３）。Ｍ４１９において、メッセージ受信部２０８は、サーバ１０２から、サーバプッシュのために予約されたストリーム２を通してＨＥＡＤＥＲＳフレームを受信する。Ｍ４２０において、メッセージ受信部２０８は、サーバ１０２から、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＤＡＴＡフレームを受信する。このペイロードがサーバプッシュにより受信されるデータである。Ｍ４２１において、ストリーム制御部２０９は、Ｍ４１９、Ｍ４２０に対する、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＨＥＡＤＥＲＳフレームレスポンスをサーバ１０２に送信する。Ｍ４１８にて待機後、サーバプッシュ予約中のストリームがないと判断し（Ｓ３０４でＮｏ）、処理を終了する。ここでストリーム２がクローズし、予約済みストリームテーブルからストリーム２が削除される。

本実施形態では、ｈｔｍｌでの例について記述したが、これに限らず、ＳＯＡＰやＲＥＳＴといったコマンド実行などにも適用できる。

以上、本実施形態において、通信装置１０１は、サーバ１０２から、サーバプッシュを行う旨の通知を受信したとき（たとえばＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを受信したとき）に、サーバプッシュ予約中のストリームが他にないか判定する。他になければ、当該ストリームを含むコネクションを監視対象コネクションとして無通信時間を監視する。そのコネクション上での無通信時間が所定時間に達したなら何らかのフレーム、例えばＰＩＮＧフレームを送受信する。

一方、通信装置１０１は、サーバ１０２から、サーバプッシュを行う旨の通知を受信したときに、サーバプッシュ予約済のストリームが他にあった場合は、そのストリームが予約されたときにコネクションの監視は開始されているため処理を終了する。これにより、複数サーバプッシュ予約時の不要な接続維持処理を省くことが可能となる。

また通信装置１０１は、サーバプッシュ予約済のストリームがなくなった場合は、そのストリームを含んでいたコネクションの維持処理を終了する。これにより、サーバプッシュサーバ終了後の不要な接続維持を省くことが可能となる。

なお、通信装置１００から見てサーバ１０２を他の通信装置と呼ぶ場合もある。逆に通信装置１００をサーバ１０２から見て他の通信装置と呼ぶ場合もある。また、ＴＴＰ／２コネクションを単にコネクションと、ＨＴＴＰ／２ストリームを単にストリームと呼ぶことがある。ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは予約要求のために使用されることから単に予約要求と呼び、ＰＵＳＨ＿ＰＲＯＭＩＳＥを受信するストリームとサーバプッシュを受信するストリームとをそれぞれ第１及び第２のストリームと呼ぶことがある。さらに、ＰＩＮＧフレームの送受信によりコネクションを維持することを、接続維持と呼ぶことがある。また、予約済みストリームテーブルについては、コネクションの維持のための処理が既に開始されていることを示す情報と呼ぶこともできる。この場合、Ｓ３０２は、コネクションの維持のための処理が既に開始されているか否かを判定する工程に相当することになる。

［実施形態２］
実施形態２における図、および図中と同じ要素に関しては説明を省略する。以下、本発明の実施の形態について、図面を参照して説明する。

図８はサーバ１０２のモジュール構成を示す図である。８００は、各モジュールが接続するバスである。８０１は、ＴＣＰ／ＩＰ処理、及びＴＬＳ（ＴｒａｎｓｐｏｒｔＬａｙｅｒＳｅｃｕｒｉｔｙ）処理を行う通信部である。８０２は、通信装置１０１からのＨＴＴＰ／２通信を受信する受信部である。８０３は、待機部８０４にて待機するか否かを判断する待機判断部である。８０４は、維持判断部８０６を行う間隔を制御するために待機する待機部である。８０５は、維持判断部８０６及び、接続維持部８０７の処理を終了するか判断する終了判定部である。８０６は、接続維持部８０７にて接続維持をするか否かを判断する維持判断部である。８０７は、接続を維持するために、通信装置１０１と通信を行う接続維持部である。８０８は、ストリームがサーバ１０２にフレームを送信するストリーム制御部である。なお、ストリーム制御部８０８は４つのストリームを処理したが、これに限るものではなく、プロトコルで規定するストリームの最大数まで処理を行っても良い。

図３はＨＴＴＰ／２を使用した通信において、サーバ１０２が通信判断を行い、通信装置１０１に接続維持を行うためのフローチャート図である。図３は、実施形態１と共通であるが、実施形態１においては、クライアントである通信装置１０１が実行主体となるが、本実施形態では、サーバ１０２が実行主体となる。その実行主体の相違およぎそれに起因する装置を除けば、本実施形態おいても図３の手順でコネクション維持処理を実行する。以下の説明は実施形態１における図３の説明を若干簡略化しているが、サーバとクライアントとが入れ替わっている点を除いて実施形態１とほぼ同様である。本フローの開始タイミングすなわちトリガは、実施形態１と相違し、通信装置１０１がＰＵＳＨ＿ＰＲＯＭＩＳＥフレームによるサーバプッシュ（あるいはそれに用いるストリーム）の予約要求をサーバ１０２送信した時である。予約要求は、たとえば通信装置１０１からサーバ１０２に送信するインデックスファイルのリクエスト（例えば図９のＭ９０２）中に予約要求を示す情報として含ませておけばよい。あるいは、図３の手順のきっかけは、サーバ１０２が通信装置１０１にＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの送信であってもよい。

待機判断部８０３は、待機部８０４にて待機するか否かを判断する（Ｓ３０２）。待機判断部８０３は、すでにサーバプッシュ予約済のストリームがある場合は処理を終了する。すでにサーバプッシュ予約済のストリームがない場合はＳ３０３に進む。待機判断部８０３は、サーバプッシュ予約済のストリーム一覧を保存した予約済みストリームテーブルに登録された予約済みストリームの有無から判断しても良いし、ストリームの状態が、ｒｅｓｅｒｖｅｄ（ｌｏｃａｌ）もしくは、ｈａｌｆｃｌｏｓｅｄ（ｒｅｍｏｔｅ）であるストリームがあるか否かで判断しても良い。

待機部８０４は、待機時間待機する（Ｓ３０３）。ここでの待機時間とは、サーバ１０２が保持する待機時間でも良いし、通信装置１０１が保持する待機時間でも良い。例えば、通信装置１０１とサーバ１０２の間でコネクションを維持できる時間を測定し、その値よりも小さい値であってもよい。また、待機時間はそれらの時間の一部を用いて計算されたランダムな時間であってもよい。

終了判断部８０５は、維持判断部８０６及び、接続維持部８０７の処理を終了するか判断するために、サーバプッシュ予約済のストリームが残っているか否かを確認する（Ｓ３０４）。サーバプッシュ予約済のストリームが残っている場合はＳ３０５に進む。サーバプッシュ予約済のストリームが残っていない場合は処理を終了する。

維持判断部８０６は、接続維持部８０７が接続維持を行うかを判断し、待機部８０４が待機中にコネクション上で通信があった場合は、Ｓ３０３に進み、待機中にコネクション上で通信がなかった場合はＳ３０６に進む。
接続維持部８０７は、ＰＩＮＧフレームを送受信しＳ３０３に進む。なお、ここでのＰＩＮＧフレームはＨＥＡＤＥＲＳフレームなど、通信を行うフレームタイプであってもよい。また、サーバプッシュのストリームを利用したＤＡＴＡフレームであってもよい。

図９はＨＴＴＰ／２を使用した通信において、サーバ１０２が通信判断を行い、通信装置１０１に接続維持を行うためのシーケンス図である。

Ｍ９０１において、通信部８０１は、通信装置１０１とＨＴＴＰ／２通信を開始し、コネクション１を生成する。

Ｍ９０２において、受信部８０２は、通信装置１０１から、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＨＥＡＤＥＲＳフレームを受信する。Ｍ９０３において、ストリーム制御部８０８は、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信する。なお、Ｍ９０３はＭ９０４の後に行っても良い。Ｍ９０４において、待機判断部８０３はサーバプッシュ予約中のストリームが他にないと判断し（Ｓ３０２でＮｏ）、待機部８０４にて待機時間待機する（Ｓ３０３）。Ｍ９０５において、ストリーム制御部８０８は、Ｍ９０２に対する、ＨＥＡＤＥＲＳフレームレスポンスを通信装置１０１に送信する。Ｍ９０６において、受信部８０２は、通信装置１０１から、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＤＡＴＡフレームを受信する。なお、Ｍ９０５〜Ｍ９０６において、ＨＥＡＤＥＲＳフレーム送信、ＤＡＴＡフレーム(ＥＮＤ＿ＳＴＲＥＡＭ)送信としているが、ＨＥＡＤＥＲＳフレーム送信、ＤＡＴＡフレーム送信、ＤＡＴＡフレーム(ＥＮＤ＿ＳＴＲＥＡＭ) 送信や、ＨＥＡＤＥＲＳフレーム(ＥＮＤ＿ＳＴＲＥＡＭ)送信でもよい。

Ｍ９０７において、ストリーム制御部８０８は、ＨＥＡＤＥＲＳフレームを通信装置１０１に送信する。Ｍ９０８において、ストリーム制御部８０８は、ＤＡＴＡフレームを通信装置１０１に送信する。Ｍ９０９において、受信部８０２は、通信装置１０１から、Ｍ９０７、Ｍ９０８に対するＨＥＡＤＥＲＳフレームレスポンスを受信する。

Ｍ９１０において、終了判断部８０５は、Ｍ９０４にて待機後、サーバプッシュ予約中のストリームがあると判断し（Ｓ３０４でＹｅｓ）、維持判断部８０６は、待機中に通信があったと判断し（Ｓ３０５でＹｅｓ）、待機部８０４にて待機時間待機する（Ｓ３０３）。

Ｍ９１１において、受信部８０２は、通信装置１０１から、ＨＥＡＤＥＲＳフレームを受信する。Ｍ９１２において、受信部８０２は、通信装置１０１から、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＤＡＴＡフレームを受信する。Ｍ９１３において、ストリーム制御部８０８は、Ｍ９１１、Ｍ９１２に対する、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＨＥＡＤＥＲＳフレームレスポンスを通信装置１０１に送信する。なお、Ｍ９１０〜Ｍ９１２において、ＨＥＡＤＥＲＳフレーム受信、ＤＡＴＡフレーム受信、ＨＥＡＤＥＲＳフレーム送信としているが、ＰＩＮＧフレームやＳＥＴＴＩＮＧＳフレームの送受信であってもよい。

Ｍ９１４において、終了判断部８０５は、Ｍ９１０にて待機後、サーバプッシュ予約中のストリームがあると判断し（Ｓ３０４でＹｅｓ）、維持判断部８０６は、待機中に通信があったと判断し（Ｓ３０５でＹｅｓ）、待機部８０４にて待機時間待機する（Ｓ３０３）。

Ｍ９１５において、終了判断部８０５は、Ｍ９１４にて待機後、サーバプッシュ予約中のストリームがあると判断し（Ｓ３０４でＹｅｓ）、維持判断部８０６は、待機中にコネクション上で通信がなかったと判断し（Ｓ３０５でＮｏ）、接続維持部８０７にてＰＩＮＧフレームを通信装置１０１と送受信する（Ｓ３０６）。なお、ここでのＰＩＮＧフレームはＨＥＡＤＥＲＳフレームなど、通信を行うフレームタイプであってもよい。後述のＭ９１６とＭ９１７は、Ｍ９１５のＰＩＮＧフレーム送受信シーケンスに対応する。

Ｍ９１６において、ストリーム制御部８０８は、ＰＩＮＧフレームを通信装置１０１に送信する。Ｍ９１７において、受信部８０２は、通信装置１０１から、Ｍ９１６に対する、ペイロードにＡＣＫフラグを指定したＰＩＮＧフレームを受信する。

Ｍ９１８において、待機部８０４にて待機時間待機する（Ｓ３０３）。

Ｍ９１９において、ストリーム制御部８０８は、ＨＥＡＤＥＲＳフレームを通信装置１０１に送信する。Ｍ９２０において、ストリーム制御部８０８は、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＤＡＴＡフレームを通信装置１０１に送信する。Ｍ９２１において、受信部８０２は、通信装置１０１から、Ｍ９１９、Ｍ９２０に対する、ペイロードにＥＮＤ＿ＳＴＲＥＡＭフラグを指定したＨＥＡＤＥＲＳフレームレスポンスを受信する。Ｍ９１３にて待機後、サーバプッシュ予約中のストリームがないと判断し（Ｓ３０４でＮｏ）、処理を終了する。

以上説明したように本実施形態において、サーバ１０２は、サーバプッシュを行う際に、サーバプッシュに用いるコネクションの無通信時間を監視し、所定時間を超えて無通信であれば、何らかのフレームたとえばＰＩＮＧを送信する。一方、所定時間以内に通信があればフレーム、例えばＰＩＮＧフレームを送受信しない。これにより、接続維持のための不要なフレームの送受信を省くことが可能となる。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１通信装置、１０２サーバ、２０１通信部、２０２受信部、２０６維持判断部、２０７接続維持部、２０８メッセージ受信部、２０９ストリーム制御部

Claims

通信装置であって、
他の通信装置との間で設定されるコネクションに属する１以上の論理的な通信路としての１以上のストリームを介して前記他の通信装置と通信する通信手段と、
前記コネクションに属するストリームの予約のための通知を受信する受信手段と、
前記受信手段により前記ストリームの予約のための通知が受信された後に、前記通信手段により前記他の通信装置との間で前記コネクションに属する１以上のストリームの何れを介した通信もなされていない無通信時間が所定時間に達した場合に、前記他の通信装置に対して前記コネクションを維持するためのメッセージを送信する処理を行う接続維持手段とを有することを特徴とする通信装置。
前記無通信時間が前記所定時間に達したかを判定する判定手段を更に有し、
前記接続維持手段は、前記受信手段により前記ストリームの予約のための通知が受信された後に前記無通信時間が前記所定時間に達したと前記判定手段により判定された場合に、前記メッセージを送信する処理を行うことを特徴とする請求項１に記載の通信装置。
前記受信手段により受信される通知は、前記コネクションに属するストリームであって未だ確立されていない新たなストリームの予約のための通知であることを特徴とする請求項２に記載の通信装置。
前記判定手段は、前記受信手段により前記ストリームの予約のための通知が受信されたことに応じて、前記コネクションの維持のための処理が開始されているか否かを判定し、前記コネクション維持のための処理が開始されていないと判定された場合に、前記無通信時間の測定を開始することを特徴とする請求項２又は３に記載の通信装置。
前記判定手段は、前記コネクションの維持のための処理が開始されていることを示す参照情報を参照して、前記コネクションの維持のための処理が開始されているか否かを判定することを特徴とする請求項４に記載の通信装置。
前記通信装置及び前記他の通信装置はＨＴＴＰ／２に対応する通信装置であり、
前記参照情報は、サーバプッシュのための前記コネクションに属する予約済みストリームのＩＤを含むことを特徴とする請求項５に記載の通信装置。
前記通信装置及び前記他の通信装置はＨＴＴＰ／２に対応する通信装置であり、
前記参照情報は、サーバプッシュのための前記コネクションに属する予約済みストリームが少なくとも１つ含まれることを示すことを特徴とする請求項５に記載の通信装置。
前記通信装置及び前記他の通信装置はＨＴＴＰ／２に対応する通信装置であり、
前記参照情報は、前記コネクションに属するストリームの状態が予約済み状態であることを示すことを特徴とする請求項５に記載の通信装置。
前記コネクションに属する予約済みストリームがなくなった場合に、前記接続維持手段による前記コネクションを維持するための処理を終了することを特徴とする請求項６乃至８のいずれか一項に記載の通信装置。
前記受信手段は、前記ストリームの予約のための通知として、ＨＴＴＰ／２において規定されるＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを前記他の通信装置から受信することを特徴とする請求項１乃至９のいずれか一項に記載の通信装置。
前記受信手段は、前記ストリームの予約のための通知として、当該ストリームを用いてサーバプッシュを行うことを示す情報を前記他の通信装置から受信することを特徴とする請求項１乃至９のいずれか一項に記載の通信装置。
前記通信装置はＨＴＴＰ／２のクライアントであり、前記他の通信装置はＨＴＴＰ／２のサーバであることを特徴とする請求項１乃至１１のいずれか一項に記載の通信装置。
前記受信手段は、前記ストリームの予約のための通知として、ＨＴＴＰ／２において規定されるＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの送信要求を前記他の通信装置から受信することを特徴とする請求項１乃至９のいずれか一項に記載の通信装置。
前記他の通信装置はＨＴＴＰ／２のクライアントであり、前記通信装置はＨＴＴＰ／２のサーバであることを特徴とする請求項１乃至９又は請求項１３のいずれか一項に記載の通信装置。
通信装置であって、
他の通信装置との間で設定されるコネクションに属する複数の論理的な通信路としての複数のストリームを介して前記他の通信装置と通信する通信手段と、
前記通信手段により、前記コネクションに属する複数のストリームである第１ストリームと第２ストリームとのうち、前記第１ストリームを介した通信が所定時間以上なされていない場合であり且つ前記第２ストリームを介した通信も前記所定時間以上なされていない場合には、前記他の通信装置に対して前記コネクションを維持するためのメッセージを送信し、前記第１ストリームを介した通信が前記所定時間以上なされていない場合であり且つ前記第２ストリームを介した通信がなされていない無通信時間が前記所定時間未満である場合には、前記他の通信装置に対して前記メッセージを送信しない接続制御手段とを有することを特徴とする通信装置。
請求項１乃至１５のいずれか一項に記載の通信装置と前記他の通信装置と有することを特徴とする通信システム。
請求項１乃至１５のいずれか一項に記載の通信装置の各手段としてコンピュータを機能させるためのプログラム。
通信装置と他の通信装置との間で設定されるコネクションに属する１以上の論理的な通信路としての１以上のストリームを介して通信する通信工程と、
前記コネクションに属するストリームの予約のための通知を前記他の通信装置から前記通信装置へ送信する送信工程と、
前記送信工程において前記ストリームの予約のための通知が送信された後に、前記通信工程において前記通信装置と前記他の通信装置との間で前記コネクションに属する１以上のストリームの何れを介した通信もなされていない無通信時間が所定時間に達した場合に、前記通信装置と前記他の通信装置との間で前記コネクションを維持するためのメッセージを伝送する処理を行う接続維持工程とを有することを特徴とする通信制御方法。
前記無通信時間が前記所定時間に達したかを判定する判定工程を有し、前記接続維持工程は、前記送信工程により前記ストリームの予約のための通知が送信された後に前記無通信時間が前記所定時間に達したと前記判定工程により判定された場合に、前記メッセージを送信する処理を行うことを特徴とする請求項１８に記載の通信制御方法。
通信装置と他の通信装置との間で設定されるコネクションに属する複数の論理的な通信路としての複数のストリームを介して通信する通信工程と、
前記通信工程において、前記コネクションに属する複数のストリームである第１ストリームと第２ストリームとのうち、前記第１ストリームを介した通信が所定時間以上なされていない場合であり且つ前記第２ストリームを介した通信も前記所定時間以上なされていない場合には、前記通信装置と前記他の通信装置との間で前記コネクションを維持するためのメッセージを伝送し、前記第１ストリームを介した通信が前記所定時間以上なされていない場合であり且つ前記第２ストリームを介した通信がなされていない無通信時間が前記所定時間未満である場合には、前記通信装置と前記他の通信装置との間で前記メッセージを伝送しない接続制御工程とを有することを特徴とする通信制御方法。