図面 (/)

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

出願人 キヤノン株式会社
発明者 谷口和矢安間健介沼上幸夫國松亮酒井智哉
出願日 2015年5月25日 (5年2ヶ月経過) 出願番号 2015-105820
公開日 2016年12月22日 (3年7ヶ月経過) 公開番号 2016-218923
状態 特許登録済
技術分野 広域データ交換 計算機・データ通信
主要キーワード 不通状態 ファイヤウオール 維持処理 ステータスアイコン 接続維持 ストリームテーブル ヒューマンインターフェイス サーバプッシュ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年12月22日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題

コネクション上で少なくとも2つのストリーム確立するプロトコル通信において、不要な接続維持処理が行われる問題があった。

解決手段

コネクション上で少なくとも2つのストリームを確立するプロトコルの通信において、新たなストリームの予約通知され、既に予約されたストリームがない場合には、所定時間を超える無通信状態を防止する処理を開始して少なくとの所定時間おきフレーム送信を行い、既に予約されたストリームがある場合には、当該処理を開始することなく処理を終える。

概要

背景

インターネット標準技術として一般に広く利用されているプロトコル(通信規約)の1つに、HTTP(Hyper Text Transfer Protocol)がある。現在、インターネット標準化団体(IETF:Internet Engineering Task Force)において、HTTPの新しいバージョン(HTTP/2)が策定された。HTTP/2は、既存の技術であるHTTP1.1に互換性を有した上で、新たな機能が追加されている。たとえば、HTTP/2では、1つのコネクション内部に、仮想チャンネルを通る双方向のフレームの流れであるストリームを複数もたせることができる。HTTPリクエストレスポンスは単一のストリームに割り当てられ、ひとつのストリームは他のストリームとは独立しているため、リクエストブロックや停止が、他のリクエストの進捗を妨げることはない。

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

概要

コネクション上で少なくとも2つのストリームを確立するプロトコルの通信において、不要な接続維持処理が行われる問題があった。コネクション上で少なくとも2つのストリームを確立するプロトコルの通信において、新たなストリームの予約通知され、既に予約されたストリームがない場合には、所定時間を超える無通信状態を防止する処理を開始して少なくとの所定時間おきフレーム送信を行い、既に予約されたストリームがある場合には、当該処理を開始することなく処理を終える。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

他の通信装置との間に設定したコネクション内の仮想的な通信路であるストリームを介して通信する通信装置であって、コネクション内の新たなストリームの予約通知された場合、前記コネクションの維持のための処理が既に開始されているか否かを判定する判定手段と、前記判定手段により前記処理が開始されていないと判定された場合、前記コネクションの監視を開始して無通信状態が所定時間を超えた場合には前記他の通信装置に対してフレームを送信する処理を行う接続維持手段とを有することを特徴とする通信装置。

請求項2

前記判定手段により前記処理が開始されていると判定された場合には、前記接続維持手段による前記処理を開始しないことを特徴とする請求項1に記載の通信装置。

請求項3

前記判定手段は、前記コネクションの維持のための処理が既に開始されていることを示す情報を参照して、前記コネクションの維持のための処理が既に開始されているか否かを判定することを特徴とする請求項1又は2に記載の通信装置。

請求項4

前記通信装置及び前記他の通信装置はHTTP/2に対応する通信装置であり、前記情報は、前記コネクション内に含まれる、サーバプッシュのための予約済みストリームのIDを含むことを特徴とする請求項3に記載の通信装置。

請求項5

前記通信装置及び前記他の通信装置はHTTP/2に対応する通信装置であり、前記情報は、前記コネクション内に、サーバプッシュのための予約済みストリームが少なくとも1つ含まれることを示すことを特徴とする請求項3に記載の通信装置。

請求項6

前記通信装置及び前記他の通信装置はHTTP/2に対応する通信装置であり、前記情報は、前記コネクション内に含まれた、予約済みストリームであることを示すストリームの状態であることを示すことを特徴とする請求項3に記載の通信装置。

請求項7

前記コネクションから前記予約済みストリームがなくなった場合には、前記接続維持手段による前記処理を停止することを特徴とする請求項4乃至6のいずれか一項に記載の通信装置。

請求項8

前記他の通信装置は、PUSH_PROMISEフレームを前記通信装置に送信することで前記ストリームの予約を通知し、前記判定手段は、前記PUSH_PROMISEフレームを受信した場合に、前記コネクション内の新たなストリームの予約が通知されたと判断することを特徴とする請求項4乃至6のいずれか一項に記載の通信装置。

請求項9

前記判定手段は、前記他の通信装置に対するリクエストに応じて該他の装置から受信したデータに含まれた、サーバプッシュを行うことを示す情報に基づいて、前記コネクション内の新たなストリームの予約が通知されたと判断することを特徴とする請求項4乃至6のいずれか一項に記載の通信装置。

請求項10

前記通信装置はHTTP/2のクライアントであり、前記他の通信装置はHTTP/2のサーバであることを特徴とする請求項4乃至9のいずれか一項に記載の通信装置。

請求項11

前記通信装置は、PUSH_PROMISEフレームを前記他の通信装置に送信することで前記ストリームの予約を通知し、前記判定手段は、前記PUSH_PROMISEフレームの送信の要求を受信した場合に、前記コネクション内の新たなストリームの予約が通知されたと判断することを特徴とする請求項4乃至6のいずれか一項に記載の通信装置。

請求項12

前記他の通信装置はHTTP/2のクライアントであり、前記通信装置はHTTP/2のサーバであることを特徴とする請求項4乃至6又は請求項11のいずれか一項に記載の通信装置。

請求項13

他の通信装置との間に設定したコネクション内を介して通信する通信装置であって、前記他の通信装置からのデータの非同期の送信の予約が通知された場合、前記予約に係るコネクションの維持のための処理が既に開始されているか否かを判定する判定手段と、前記判定手段により前記処理が開始されていないと判定された場合、前記コネクションの監視を開始して無通信状態が所定時間を超えた場合には前記他の通信装置に対してフレームを送信する処理を行う接続維持手段とを有することを特徴とする通信装置。

請求項14

請求項1乃至13のいずれか一項に記載の通信装置と他の通信装置とを通信で接続したことを特徴とする通信システム

請求項15

請求項1乃至13のいずれか一項に記載の通信装置としてコンピュータを機能させるためのプログラム

請求項16

他の通信装置との間に設定したコネクション内の仮想的な通信路であるストリームを介して通信する通信装置の制御方法であって、コネクション内の新たなストリームの予約が通知された場合、前記コネクションの維持のための処理が既に開始されているか否かを判定する判定工程と、前記判定工程により前記処理が開始されていないと判定された場合、前記コネクションの監視を開始して無通信状態が所定時間を超えた場合には前記他の通信装置に対してフレームを送信する処理を行う接続維持工程とを有することを特徴とする通信装置の制御方法。

請求項17

他の通信装置との間に設定したコネクション内の仮想的な通信路であるストリームを介して通信する通信装置の制御方法であって、前記他の通信装置からのデータの非同期の送信の予約が通知された場合、前記予約に係るコネクションの維持のための処理が既に開始されているか否かを判定する判定工程と、前記判定工程により前記処理が開始されていないと判定された場合、前記コネクションの監視を開始して無通信状態が所定時間を超えた場合には前記他の通信装置に対してフレームを送信する処理を行う接続維持工程とを有することを特徴とする通信装置の制御方法。

技術分野

0001

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

背景技術

0002

インターネット標準技術として一般に広く利用されているプロトコル(通信規約)の1つに、HTTP(Hyper Text Transfer Protocol)がある。現在、インターネット標準化団体(IETF:Internet Engineering Task Force)において、HTTPの新しいバージョン(HTTP/2)が策定された。HTTP/2は、既存の技術であるHTTP1.1に互換性を有した上で、新たな機能が追加されている。たとえば、HTTP/2では、1つのコネクション内部に、仮想チャンネルを通る双方向のフレームの流れであるストリームを複数もたせることができる。HTTPリクエストレスポンスは単一のストリームに割り当てられ、ひとつのストリームは他のストリームとは独立しているため、リクエストブロックや停止が、他のリクエストの進捗を妨げることはない。

0003

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

先行技術

0004

特開2014−199998号公報

発明が解決しようとする課題

0005

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

0006

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

課題を解決するための手段

0007

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

0008

本発明の第1の側面によれば、他の通信装置との間に設定したコネクション内の仮想的な通信路であるストリームを介して通信する通信装置であって、
コネクション内の新たなストリームの予約通知された場合、前記コネクションの維持のための処理が既に開始されているか否かを判定する判定手段と、
前記判定手段により前記処理が開始されていないと判定された場合、前記コネクションの監視を開始して無通信状態が所定時間を超えた場合には前記他の通信装置に対してフレームを送信する処理を行う接続維持手段とを有する。

発明の効果

0009

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

図面の簡単な説明

0010

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

実施例

0011

[実施形態1]
以下、本発明の実施の形態について、図面を参照して説明する。図1は実施形態1に係る通信システムのシステム構成図である。通信装置101とサーバ102とはネットワーク100を介して接続されている。本実施形態におけるネットワーク100は、インターネット、WAN(Wide Area Network)、LAN(Local Area Network)、等の複合であっても実現できる。通信装置101とサーバ102は、例えば、無線アドホックネットワークを用いて接続しても良い。

0012

通信装置101はネットワーク100に接続する通信装置である。通信装置102はネットワーク100に接続し通信装置101からの通信を受け付けるサーバである。本実施形態では、サーバ102は1台のPCで実現しているが、サーバ102は、プロキシサーバを含めても良いし、クラウド上で分散して配置されていても良い。通信装置101はネットワーク100を通じて、サーバ102とHTTP/2を使用して通信を行う。すなわち、通信装置101,102とも、TCP/IPのプロトコルスタックを有している。通信装置101はHTTP/2に対応したクライアントであり、通信装置102は同じくサーバである。

0013

各通信装置はいずれも、図1の通信装置101に示したように、通信機能を提供する通信部1013を有した、ネットワーク100に接続可能なコンピュータにより実現することができる。このコンピュータは汎用コンピュータの構成を有していればよく、通信部1013に加えて、たとえばプロセッサ(CPU)1011、メモリ1012、ファイルストレージ1014、入力部と出力部(表示部)とを含むヒューマンインターフェイスデバイス1015などを有する。通信に関する機能は、たとえば、物理層データリンク層の一部はハードウェアにより実現され、残りの一部やその上位層、たとえばTCP/IPプロトコルスタックは通常、そのためのプログラムをプロセッサにより実行させることで実現される。またそのプログラムは後述するHTTP/2に対応したウェブブラウザ(あるいはサーバ)を含み、その処理手順の一部が図3図6図7に示した手順である。

0014

<通信装置101のモジュール構成>
図2は、通信装置101のモジュール構成を示す図である。200は、各モジュールが接続するバスである。201は、TCP/IP処理、及びTLS(Transport Layer Security)処理を行う通信部である。

0015

202は、サーバ102からのHTTP/2通信を受信する受信部である。203は、待機部204にて、不要なメッセージ処理を低減する為の待機をおこなうか否かを判断する待機判断部である。204は、維持判断部206による判断の基準となる時間間隔を制御するために待機する待機部である。205は、維持判断部206及び、接続維持部207の処理を終了するか判断する終了判断部である。206は、接続維持部207にて接続維持をするか否かを判断する維持判断部である。207は、接続を維持するために、サーバ102と通信を行う接続維持部である。

0016

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

0017

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

0018

209は、ストリームごとにサーバ102にフレームを送信するストリーム制御部である。なお、本例では、ストリーム制御部209は4つのストリームを処理するが、これに限るものではなく、プロトコルで規定するストリームの最大数まで処理を行っても良い。210は、ユーザが入力したURLを取得するURL取得部である。211は、サーバ102からWebページを取得するWebページ取得部である。212は、WebページをWebブラウザ上に表示するWebページ表示部である。213は、Webページにづいたコンテンツデータを取得するコンテンツ取得部である。214は、コンテンツデータをWebブラウザ上に表示するコンテンツ表示部である。215は、Webページ情報から、サーバプッシュをするか判断するサーバプッシュ判断部である。

0019

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

0020

ブラウザ画面例>
図5は実施形態1に係わるウェブブラウザ画面を示した図である。URL表示欄501は、ウェブブラウザページのURLを表示する欄である。Webページ画面502は、本実施形態におけるWebページを表示するウィンドウ画面である。Webページ画面502は、Webページ表示部212により、HTML形式記述されたWebデータに基づいて構成され、表示される。ステータスアイコン503は、Webページ画面502内に表示するアイコンである。ここでは、ステータスアイコン503はプリンタの状態を示す。なお、ステータスアイコン503はアイコン以外にも、画像やテキストといったコンテンツデータや、スタイルシートであっても良い。また例えば、ステータスアイコン503は、LEDや音などで示すこともできる。コンテンツ画面504は、Webページ画面502に紐づいたコンテンツデータである。

0021

図5の例では、例えばサーバ102は多機能複写機等のプリンタデバイスに組み込まれたサーバであり、クライアント101はコンピュータである。そしてクライアント端末101は、サーバ102に対してURLを指定して情報、たとえばサーバ102を搭載したプリンタデバイスのデバイス情報をコンテンツとして要求する。クライアント端末101のWebページ表示部212は、サーバ102からの応答として受信したデバイス情報をコンテンツ画面504に配置し、ステータス情報をステータスアイコン503に配置してWebページを構成し、Webページ画面502に表示している。このように、HTTPクライアントである通信装置101、特にそこで実行されるWebブラウザは、サーバ102からHTTP/2を通してデータを取得し、Webページを構成して表示することができる。

0022

<Webページの表示>
図6はHTTP/2を使用した通信において、通信装置101がWebブラウザ上でWebページを表示するためのフローチャートである。

0023

URL取得部210は、ユーザが入力したURL表示欄501からURLを取得する(S601)。Webページ取得部211は、S601で取得したURLを指定してサーバ102にHTTPリクエストを送信し、そのレスポンスとしてサーバ102からインデックスページを示すHTMLファイルindex.html(これをインデックスファイルとも呼ぶ。)を取得する(S602)。このときクライアントとサーバとの間にコネクションが設定され、更にそこにストリームが設けられ、1つのストリームでHTTPリクエストとレスポンスが交換される。なおコネクションは新たに設定されるとは限らず、既に完了したリクエストーレスポンスのために設定されたコネクションを再利用することもできる。

0024

サーバプッシュ判断部215は、S602で取得したデータ(たとえばインデックスファイルindex.html)から、インデックスファイルindex.htmlに関連付けられたサーバプッシュがあるか(あるいは予約されたか)否か判断する(S603)。本例では、サーバ102は、サーバプッシュがあることをインデックスファイルindex.htmlの中に記録し、クライアントである通信装置101に通知する。S603ではこの通知に基づいて判断を行う。これは一例であって、サーバ102から通信装置101に対して通知方法取り決めておけば、どのような方法であってもよい。たとえば受信部202にてPUSH_PROMISEフレームを受信した否かでサーバプッシュの有無を判断することもできる。この場合、PUSH_PROMISEフレームを受信していれば、サーバプッシュがあるものと判定する。またサーバプッシュ用の独自タグを定義し、そのタグがあるか判断しても良い。

0025

テップS603においてサーバプッシュがあると判断した場合はS604に進む。サーバプッシュがない場合はS605に進む。サーバプッシュがあると判断した場合、サーバプッシュ判断部215は、図3の接続維持のための処理をおこなう為のサーバプッシュフラグを立てる或いはセットする(S604)。ここではサーバプッシュフラグを立てているが、フラグを立てずに図3で後述する接続維持フローをおこなうといった方法でもよい。なお、サーバプッシュに用いられるストリームの予約はPUSH_PROMISEフレームにより通知されることから、サーバプッシュフラグは対応するストリームに関連づけてセットされてもよい。

0026

Webページ表示部212は、受信したインデックスファイルindex.htmlをWebページ画面502に表示する(S605)。コンテンツ取得部213は、インデックスファイルindex.htmlに紐づいたコンテンツデータを取得する(S606)。本実施形態では、インデックスファイル名をindex.htmlとしているが、他のhtmlファイル名であってもよいし、他形式ファイルであっても良い。コンテンツ表示部214は、コンテンツ取得部213にて取得したコンテンツデータをコンテンツ画面504に表示する(S605)。本実施形態では、コンテンツ取得部213とコンテンツ表示部214におけるコンテンツデータを1つとしているが、2つや3つでも良い。また、コンテンツデータの形式は画像やテキストやスタイルシートでも良い。本実施形態では、Webブラウザ上でのフローチャートについて記述したが、カメラやプリンタの画面表示であってもよい。

0027

図7は、HTTP/2を使用した通信において、通信装置101が、図6のフローチャートにてWebページを表示中、もしくは表示後、サーバ102からサーバプッシュを受信し、アイコンを表示する場合のフローチャートである。メッセージ受信部208は、サーバ102から、サーバプッシュを受信する(S701)。コンテンツ表示部214は、メッセージ受信部208にて受信したコンテンツデータをステータスアイコン503に表示する(S702)。図7の手順は、サーバプッシュを受信する都度実行される。画面表示中にステータスが変化すると、サーバ102がステータスをプッシュし、通信装置101は受信したステータス情報に応じてステータスアイコンを更新する。このためステータスアイコンはほぼ実時間でステータスの変化を反映できる。

0028

コネクション維持処理
図3はHTTP/2を使用した通信において、通信装置101が通信判断を行い、サーバ102とのコネクションを維持するための接続維持を行うためのフローチャートである。本フローは、S604にてセットされるサーバプッシュフラグを監視し、それが立てられた時に実行開始される。図示していないが、実行を開始するとサーバプッシュフラグをリセットする。なお、上記タイミング以外にも、通信装置101がPUSH_PROMISEフレームによるサーバプッシュの予約要求を受信した時であってもよい。PUSH_PROMISEフレームはサーバプッシュのために用いるストリームの予約を通信装置101に通知するフレームでもある。

0029

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

0030

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

0031

待機判断部203はステップS302では、上述のように予約済みストリームテーブルに登録されたストリームの有無から判断しても良いし、ストリームの状態がreserved(remote)もしくは、half closed(local)状態であるストリームがあるか否かで判断しても良い。該当するストリームがあれば、ステップS302では既にサーバプッシュ予約済のストリームがあると判定される。HTTP/2によれば、PUSH_PROMISEフレームのストリームは、サーバ上では"half closed(remote)"状態に、クライアント上では"half closed(local)"状態にされる。また、異なるストリームにおけるPUSH_PROMISEフレームの受信により、今後使用するストリームが予約されると、予約済みストリームの状態は"reserved(remote)"に遷移する。このためこれらの状態を持つストリームが、S603で新たに通知されたサーバプッシュに係るストリーム以外にもあれば、ステップS302でサーバプッシュ予約済みのストリームがあると判定することが行うことができる。新たに予約されたストリームIDはPUSH_PROMISEフレームにより通知され、ストリームの同一性はたとえばストリームIDにより判定できる。

0032

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

0033

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

0034

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

0035

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

0036

ステップS306では、接続維持部207は、PINGフレームを送受信しS303に進む。なお、ここでのPINGフレームはHEADERSフレームなど、ストリームで通信を行うフレームタイプであってもよい。また、サーバプッシュのストリームを利用したDATAフレームであってもよい。

0037

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

0038

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

0039

<コネクション維持のシーケンス>
図4はHTTP/2を使用した通信において、通信装置101がサーバ102に接続維持を行うためのシーケンス図である。

0040

M401において、通信部201は、サーバ102とHTTP/2通信を開始し、コネクション1を生成する。

0041

M402において、ストリーム制御部209は、ペイロードにEND_STREAMフラグを指定したHEADERSフレームを、コネクション1に含まれるストリーム1でサーバ102に送信する。HEADERSフレームはストリームの開始に使用される。なおM405までの通信はストリーム1を介して行われる。M403において、受信部202は、サーバ102からPUSH_PROMISEフレームを受信する。PUSH_PROMISEフレームは、送信者(サーバ102)が、開始する予定のストリームを事前にピアエンドポイント(この場合には通信装置101)に通知するために使用するフレームであり、予約するストリームの識別子を含む。なお、M403はM404の後に行っても良い。M404において、受信部202は、サーバ102から、M402で送信したHEADERSフレームに対するHEADERSフレームレスポンスを受信する。M405において、ストリーム制御部209は、サーバ102から、ペイロードにEND_STREAMフラグを指定したDATAフレームを受信する。

0042

DATAフレームは、HTTPリクエストまたはレスポンスのペイロードを伝えるフレームである。またEND_STREAMは、特定のストリームに送信する最後のフレームであることを示すフラグである。END_STREAMフラグが設定されたフレームをサーバ102が送信、またはクライアント101が受信したときにストリームがクローズされる。このフラグを設定することで、ストリームは"half closed"状態または"closed"状態に遷移する。

0043

なお、M404〜M405において、HEADERSフレーム受信、DATAフレーム(END_STREAM)受信のシーケンスとしているが、HEADERSフレーム受信、DATAフレーム受信、DATAフレーム(END_STREAM)受信や、HEADERSフレーム(END_STREAM)受信というシーケンスでもよい。

0044

M406において、待機判断部203はこの時点ではサーバプッシュ予約済のストリームが他にないと判断し(S302でNo)、待機部204にて待機時間待機する(S303)。この後、たとえばストリーム2がサーバプッシュ予約済みストリームとしてテーブルに登録される。またストリーム2がサーバプッシュのために予約され、通信装置101から見たその状態は例えば"reserved(remote)"である。

0045

M407,M408では、通信装置101は、予約されたストリーム2を通したプッシュレスポンスをサーバ102から受信する。M407において、メッセージ受信部208は、サーバ102からHEADERSフレームを受信する。M407からサーバ102によるプッシュレスポンスが始まる。プッシュレスポンスとは、予約されたサーバプッシュに係るレスポンスの送信である。M409まで、及びM419〜M421の通信はプッシュレスポンスであり、ストリーム2を介して行われる。M408において、メッセージ受信部208は、サーバ102から、DATAフレームを受信する。このDATAフレームのペイロードは、たとえばサーバ102が組み込まれたプリンタのステータス情報である。M409において、ストリーム制御部209は、M407、M408に対するHEADERSフレームレスポンスをサーバ102に送信する。サーバ102はこの時点でストリーム2をクローズさせておらず、ストリーム2は存続するということである。

0046

M410において、終了判断部205は、M406にて所定時間待機後、サーバプッシュ予約中のストリーム(この例ではストリーム2)があると判断し(S304でYes)、維持判断部206は、待機中に通信があったと判断し(S305でYes)、待機部204にて待機時間待機する(S303)。待機中に通信があったことの判定は、たとえばM409で送信したフレームの送信時刻から判定される。

0047

M411において、ストリーム制御部209は、HEADERSフレームをサーバ102に送信する。M412において、ストリーム制御部209は、コンテンツ取得のために、ペイロードにEND_STREAMフラグを指定したDATAフレームをサーバ102に送信する。M413において、受信部202は、サーバ102から、M411、M412に対する、ペイロードにEND_STREAMフラグを指定したHEADERSフレームレスポンスを受信する。ストリーム3はここでクローズする。

0048

M414において、終了判断部205は、M410にて待機後、サーバプッシュ予約中のストリームがあると判断し(S304でYes)、維持判断部206は、待機中に通信があったと判断し(S305でYes)、待機部204にて待機時間待機する(S303)。

0049

M415において、終了判断部205は、M414にて所定時間待機後、サーバプッシュ予約中のストリーム(ストリーム2)があると判断し(S304でYes)、維持判断部206は、待機中にストリーム2を含む監視対象のコネクション上で通信がなかったと判断し(S305でNo)、接続維持部207にてPINGフレームをサーバ102と送受信する(S306)。M415の時点において監視対象のコネクションにおける最後の通信は、M413でサーバ102からストリーム3において受信したレスポンスであり、M414で待機を開始する前のものである。したがって待機中にストリーム2を含む監視対象のコネクション上で通信がなかったと判断されている。なお、ここでのPINGフレームはHEADERSフレームなど、通信を行うフレームタイプであってもよい。後述のM416とM417は、M415のPINGフレーム送受信シーケンスに対応する。

0050

M416において、ストリーム制御部209は、PINGフレームをサーバ102に送信する。PINGフレームは、本来アイドル中のコネクションがまだ機能しているかどうかを確認するために使用されるフレームであるが、本実施形態では、コネクションを維持するために使用される。M417において、受信部202は、サーバ102から、M416に対する、ペイロードにACKフラグを指定したPINGフレームを受信する。このPINGフレームの送受信により、コネクション中に介在する例えばファイヤウオールやPPoE、NAT等のタイムアウトを事前に防止し、コネクションを維持することができる。なおコネクション維持のためには少なくともフレームを送信すればよいので、サーバ102からのレスポンスはオプションとしても良い。

0051

M418において、待機部204にて待機時間待機する(S303)。M419において、メッセージ受信部208は、サーバ102から、サーバプッシュのために予約されたストリーム2を通してHEADERSフレームを受信する。M420において、メッセージ受信部208は、サーバ102から、ペイロードにEND_STREAMフラグを指定したDATAフレームを受信する。このペイロードがサーバプッシュにより受信されるデータである。M421において、ストリーム制御部209は、M419、M420に対する、ペイロードにEND_STREAMフラグを指定したHEADERSフレームレスポンスをサーバ102に送信する。M418にて待機後、サーバプッシュ予約中のストリームがないと判断し(S304でNo)、処理を終了する。ここでストリーム2がクローズし、予約済みストリームテーブルからストリーム2が削除される。

0052

本実施形態では、htmlでの例について記述したが、これに限らず、SOAPやRESTといったコマンド実行などにも適用できる。

0053

以上、本実施形態において、通信装置101は、サーバ102から、サーバプッシュを行う旨の通知を受信したとき(たとえばPUSH_PROMISEフレームを受信したとき)に、サーバプッシュ予約中のストリームが他にないか判定する。他になければ、当該ストリームを含むコネクションを監視対象コネクションとして無通信時間を監視する。そのコネクション上での無通信時間が所定時間に達したなら何らかのフレーム、例えばPINGフレームを送受信する。

0054

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

0055

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

0056

なお、通信装置100から見てサーバ102を他の通信装置と呼ぶ場合もある。逆に通信装置100をサーバ102から見て他の通信装置と呼ぶ場合もある。また、TTP/2コネクションを単にコネクションと、HTTP/2ストリームを単にストリームと呼ぶことがある。PUSH_PROMISEフレームは予約要求のために使用されることから単に予約要求と呼び、PUSH_PROMISEを受信するストリームとサーバプッシュを受信するストリームとをそれぞれ第1及び第2のストリームと呼ぶことがある。さらに、PINGフレームの送受信によりコネクションを維持することを、接続維持と呼ぶことがある。また、予約済みストリームテーブルについては、コネクションの維持のための処理が既に開始されていることを示す情報と呼ぶこともできる。この場合、S302は、コネクションの維持のための処理が既に開始されているか否かを判定する工程に相当することになる。

0057

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

0058

図8はサーバ102のモジュール構成を示す図である。800は、各モジュールが接続するバスである。801は、TCP/IP処理、及びTLS(Transport Layer Security)処理を行う通信部である。802は、通信装置101からのHTTP/2通信を受信する受信部である。803は、待機部804にて待機するか否かを判断する待機判断部である。804は、維持判断部806を行う間隔を制御するために待機する待機部である。805は、維持判断部806及び、接続維持部807の処理を終了するか判断する終了判定部である。806は、接続維持部807にて接続維持をするか否かを判断する維持判断部である。807は、接続を維持するために、通信装置101と通信を行う接続維持部である。808は、ストリームがサーバ102にフレームを送信するストリーム制御部である。なお、ストリーム制御部808は4つのストリームを処理したが、これに限るものではなく、プロトコルで規定するストリームの最大数まで処理を行っても良い。

0059

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

0060

待機判断部803は、待機部804にて待機するか否かを判断する(S302)。待機判断部803は、すでにサーバプッシュ予約済のストリームがある場合は処理を終了する。すでにサーバプッシュ予約済のストリームがない場合はS303に進む。待機判断部803は、サーバプッシュ予約済のストリーム一覧を保存した予約済みストリームテーブルに登録された予約済みストリームの有無から判断しても良いし、ストリームの状態が、reserved(local)もしくは、halfclosed(remote)であるストリームがあるか否かで判断しても良い。

0061

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

0062

終了判断部805は、維持判断部806及び、接続維持部807の処理を終了するか判断するために、サーバプッシュ予約済のストリームが残っているか否かを確認する(S304)。サーバプッシュ予約済のストリームが残っている場合はS305に進む。サーバプッシュ予約済のストリームが残っていない場合は処理を終了する。

0063

維持判断部806は、接続維持部807が接続維持を行うかを判断し、待機部804が待機中にコネクション上で通信があった場合は、S303に進み、待機中にコネクション上で通信がなかった場合はS306に進む。
接続維持部807は、PINGフレームを送受信しS303に進む。なお、ここでのPINGフレームはHEADERSフレームなど、通信を行うフレームタイプであってもよい。また、サーバプッシュのストリームを利用したDATAフレームであってもよい。

0064

図9はHTTP/2を使用した通信において、サーバ102が通信判断を行い、通信装置101に接続維持を行うためのシーケンス図である。

0065

M901において、通信部801は、通信装置101とHTTP/2通信を開始し、コネクション1を生成する。

0066

M902において、受信部802は、通信装置101から、ペイロードにEND_STREAMフラグを指定したHEADERSフレームを受信する。M903において、ストリーム制御部808は、PUSH_PROMISEフレームを送信する。なお、M903はM904の後に行っても良い。M904において、待機判断部803はサーバプッシュ予約中のストリームが他にないと判断し(S302でNo)、待機部804にて待機時間待機する(S303)。M905において、ストリーム制御部808は、M902に対する、HEADERSフレームレスポンスを通信装置101に送信する。M906において、受信部802は、通信装置101から、ペイロードにEND_STREAMフラグを指定したDATAフレームを受信する。なお、M905〜M906において、HEADERSフレーム送信、DATAフレーム(END_STREAM)送信としているが、HEADERSフレーム送信、DATAフレーム送信、DATAフレーム(END_STREAM) 送信や、HEADERSフレーム(END_STREAM)送信でもよい。

0067

M907において、ストリーム制御部808は、HEADERSフレームを通信装置101に送信する。M908において、ストリーム制御部808は、DATAフレームを通信装置101に送信する。M909において、受信部802は、通信装置101から、M907、M908に対するHEADERSフレームレスポンスを受信する。

0068

M910において、終了判断部805は、M904にて待機後、サーバプッシュ予約中のストリームがあると判断し(S304でYes)、維持判断部806は、待機中に通信があったと判断し(S305でYes)、待機部804にて待機時間待機する(S303)。

0069

M911において、受信部802は、通信装置101から、HEADERSフレームを受信する。M912において、受信部802は、通信装置101から、ペイロードにEND_STREAMフラグを指定したDATAフレームを受信する。M913において、ストリーム制御部808は、M911、M912に対する、ペイロードにEND_STREAMフラグを指定したHEADERSフレームレスポンスを通信装置101に送信する。なお、M910〜M912において、HEADERSフレーム受信、DATAフレーム受信、HEADERSフレーム送信としているが、PINGフレームやSETTINGSフレームの送受信であってもよい。

0070

M914において、終了判断部805は、M910にて待機後、サーバプッシュ予約中のストリームがあると判断し(S304でYes)、維持判断部806は、待機中に通信があったと判断し(S305でYes)、待機部804にて待機時間待機する(S303)。

0071

M915において、終了判断部805は、M914にて待機後、サーバプッシュ予約中のストリームがあると判断し(S304でYes)、維持判断部806は、待機中にコネクション上で通信がなかったと判断し(S305でNo)、接続維持部807にてPINGフレームを通信装置101と送受信する(S306)。なお、ここでのPINGフレームはHEADERSフレームなど、通信を行うフレームタイプであってもよい。後述のM916とM917は、M915のPINGフレーム送受信シーケンスに対応する。

0072

M916において、ストリーム制御部808は、PINGフレームを通信装置101に送信する。M917において、受信部802は、通信装置101から、M916に対する、ペイロードにACKフラグを指定したPINGフレームを受信する。

0073

M918において、待機部804にて待機時間待機する(S303)。

0074

M919において、ストリーム制御部808は、HEADERSフレームを通信装置101に送信する。M920において、ストリーム制御部808は、ペイロードにEND_STREAMフラグを指定したDATAフレームを通信装置101に送信する。M921において、受信部802は、通信装置101から、M919、M920に対する、ペイロードにEND_STREAMフラグを指定したHEADERSフレームレスポンスを受信する。M913にて待機後、サーバプッシュ予約中のストリームがないと判断し(S304でNo)、処理を終了する。

0075

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

0076

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

0077

101通信装置、102サーバ、201通信部、202 受信部、206 維持判断部、207接続維持部、208メッセージ受信部、209ストリーム制御部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 日本電信電話株式会社の「 復旧支援装置、復旧支援方法及びプログラム」が 公開されました。( 2020/06/04)

    【課題】復旧作業手順の安定性及び安全性を提供すること。【解決手段】復旧支援装置は、通信ネットワークを構成する機器群で発生した異常から復旧するための作業手順を示す復旧作業列に基づいて、前記復旧作業列に対... 詳細

  • 株式会社ことはの「 セッション用システム及びセッション方法」が 公開されました。( 2020/06/04)

    【課題】セッションに対する生産性の向上が可能なセッション用システム及びセッション方法を提供する。【解決手段】無線によりネットワークに接続するセッション用端末10及びサーバ20とを備えるセッション用シス... 詳細

  • キヤノン株式会社の「 ネットワーククライアント及びその制御方法」が 公開されました。( 2020/06/04)

    【課題】管理サーバなどの外部システム側から収集するイベント情報のログの収集種別を、機器内で動作するモジュール毎に動作するイベント収集モジュールとは異なる単位で切り替えることが可能となるネットワーククラ... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ