JP5963540B2 - 情報処理装置、プログラム及び制御方法 - Google Patents

Description

本発明は論理チャネルの優先順位を決定する技術に関する。

特許文献１は優先パケットと非優先パケットの両パケット間でＣＰＵが割り当てるクロック数を異ならせる技術を開示している。

特開２００９−６０６６０号広報

ここで仮に複数のストリームがある環境を想定し、さらに複数のストリーム間で依存関係を持つことができる環境を想定したとする。

特許文献１はこのような環境を想定していないため、依存関係のあるストリーム間の優先順位を適切に決定することができない。具体的には以下の問題が生じる。

ストリームＡと、ストリームＡより優先順位の低いストリームＢがある場合に、ストリームＢはストリームＢに依存する子ストリームを有しておらず、ストリームＡは子ストリームを複数有するものとする。ここでストリームＡの子ストリームの優先順位をストリームＡと同一のものに設定してしまうと、ストリームＡの子ストリームとストリームＡを含むグループよりも相対的にストリームＢの優先順位が低下する。

よって、ストリームＢで本来届けられるべきデータが遅延しすぎる問題が生じる可能性がある。

上記の目的を達成するための本発明に係る情報処理装置は、
通信プロトコルの論理チャネルである第２のストリームの最大フレームサイズを、前記第２のストリームの親ストリームでありかつ前記通信プロトコルの前記論理チャネルである第１のストリームの最大フレームサイズよりも小さく設定する設定手段と、
前記第１のストリームのフレームと前記第２のストリームのフレームを送信する送信手段と、
前記第１のストリームの優先順位が第１の優先順位でかつ前記第１のストリームの優先順位より高い優先順位であるストリームが存在しない場合に前記第１のストリームの優先順位を前記第１の優先順位より高い第２の優先順位に変更する変更手段と、を有することを特徴とする。

依存関係のあるストリーム間の優先順位を適切に決定することができる。

本発明の一実施形態としてのコンピュータを含むネットワーク構成図 本発明の一実施形態としてのコンピュータを含むシステムを構成するブロック図 本発明の一実施形態としての対象プロトコル構成図 本発明の一実施形態としての対象プロトコルデータ構造図 本発明の一実施形態としてのソフトウェア構成図 プロトコル管理処理部のフローチャート プロトコル管理処理部におけるセッション作成処理のフローチャート プロトコル管理処理部におけるストリーム作成処理のフローチャート 仮想的な、優先順位とストリームの関係表の説明図 依存深度を用いた仮想的な優先順位変動の説明図 セッション管理処理部におけるセッション定期処理のフローチャート セッション管理処理部におけるデータ受信処理のフローチャート セッション管理処理部におけるデータ送信処理のフローチャート 最大フレームサイズ決定処理部におけるフローチャート 最大フレームサイズ決定方法の説明図

実施形態を説明する前に、説明に用いる用語および、本発明が対象とする通信プロトコルについて定義する。

ソケットとは、ＴＣＰレイヤにおいて、通信を識別、分類するための表記である。多くの場合ＩＰプロトコルを下位レイヤとして用いるのが一般的であり、この場合、ＩＰアドレスとポート番号の組のことである。

ＴＣＰコネクションとはＴＣＰレイヤにおけるひとつの通信路を意味する。具体的には受信側ソケットと送信側ソケットの組のことである。

受信ウィンドウサイズとは、受信側の空きバッファの容量のことである。ＴＣＰプロトコルもウィンドウサイズを用いた処理を行うが、以降ウィンドウサイズと書く場合、対象とする上位通信プロトコルで用いるウィンドウサイズを意味する。

ストリームとは、対象とする上位通信プロトコルにおける論理チャネルのことである。

フレーム３０１とは、実際にデータを送信する際に、データを細切れにした最少単位のブロックのことである。ただし、フレーム３０１は、ＩＳＯによって提唱されているＯＳＩ７階層モデルで用いるデータリンク層のフレームと関係は無く、対象とする通信プロトコルにおける最小のデータ単位を指す。

ハッシュテーブルとは、１つの文字列に対して、１つの文字列を結びつける表のことである。

ここで本発明が対象とする通信プロトコルについて説明する。以降対象プロトコルと記述する。対象プロトコルはＴＣＰプロトコルを利用する。ただし、ＴＣＰプロトコルとの透過性を維持する中間プロトコル（ＴＬＳ、ＳＳＬ等）が存在してもよい。対象プロトコルはＴＣＰコネクション３００上をフレーム３０１と呼ばれるデータを送受信することで通信を行う（図３）。フレーム３０１はヘッダにフレームサイズを持つ。ここで対象プロトコルのデータ構造図を図４に示す。対象プロトコルは該当するひとつのＴＣＰコネクション３００上における通信をセッション４００として管理する。また、ひとつのセッション４００上にはひとつのコントロールフレーム４０１があり、セッション４００に関する通信は、このコントロールフレーム４０１を用いて行われる。対象プロトコルは、コントロールフレーム４０１以外に、任意の数のデータストリーム４０２を保持しても良い。

なお、本明細書においてデータストリームとストリームは同義である。

実際の上位アプリケーションおよび上位プロトコルのデータ通信はこのデータストリーム４０２を用いて行われる。このデータストリーム４０２はそれぞれ優先順位を設定できる。優先順位の数は説明のために、最も高い０から最も低い７の８段階とするが、実際にはこの８段階でなく、任意の優先順位数でも良い。

さらに、データストリームはそれぞれを特定できるストリームＩＤを持つ。

また、データストリーム４０２は依存関係を持たせることができる。データストリーム４０２は親がいれば、その親ストリームのストリームＩＤを持つことによって、もしいなければ０番または依存するストリームＩＤを持たないことによって表現できる。

この対象プロトコルはサーバ、クライアントの主従関係は無く、対等に通信を行う。

対象プロトコルのデータ構造の説明は以上である。

次に対象プロトコルの簡単な通信手順について説明する。ここでは通信開始から、何らかのデータ通信を行い、通信終了を行うまでの手順を説明する。

まず、ＴＣＰコネクションが確立されたとする。この時点でサーバとクライアントは双方向の通信チャネルを保持している。次にコントロールフレーム４０１を用いてデータストリーム４０２の作成を行う。サーバ側からでもクライアント側からでもデータストリーム４０２を作成することができる。ここではＷｅｂのコンテンツを取得することを例とする。Ｗｅｂのコンテンツを取得するためにクライアントはサーバに対してＨＴＴＰプロトコルのＧＥＴコマンドを送る必要がある。そのためクライアントはコンテンツストリームを用いてデータストリーム４０２の作成要求を行う。要求を受けたサーバ側はこの要求を受け入れる。この際、クライアントは作成したいデータストリームの優先順位と依存関係も設定する。サーバが作成要求を受け入れる場合はコントロールフレーム４０１を通して受け入れ許可を返信する。また、ここでサーバはデータストリーム４０２作成を拒否することもできる。データストリーム４０２作成後、サーバとクライアントは作成したデータストリーム４０２を利用してＨＴＴＰプロトコルのＧＥＴ要求、またその返信を行うことができる。ここでは全てのデータを、データストリーム４０２を介して送受信を行っている。クライアント側が必要なデータをサーバから受信後、ストリームを閉じる必要がある。この時、クライアント側からでもサーバ側からでも、どちらからでもストリームを閉じることができる。その後、ストリームの終了要求を受けた側は送信するデータがなくなり次第、ストリームの終了要求を出し、ストリームを終了する。また、意図的に片側が終了要求を出さないことで片方向通信を行うこともできる。

また、サーバ側からデータストリーム４０２を作成する例としてクライアント側からＧＥＴ要求に対して、動的にコンテンツをクライアントにプッシュするために新たなデータストリーム４０２を作成することが考えられる。この例から分かるように、対象プロトコルの通信において、ストリームの数は時間に応じて動的に変動する。

本発明に係る情報処理装置の一実施形態としてのコンピュータについて説明する。図２は本実施形態のコンピュータの構成を説明するブロック図である。なお、特に断らない限り、本発明の機能が実行されるのであれば、単体の機器であっても、複数の機器から成るシステムであっても、本発明を適用できることは言うまでもない。また、特に断らない限り、本発明の機能が実行されるのであれば、ＬＡＮ、ＷＡＮ、インターネット等のネットワークを介して接続が為され処理が行われるシステムであっても本発明を適用できることは言うまでもない。

図２はコンピュータ２００の構成を示し、クライアントコンピュータ１０３の構成及びサーバコンピュータ１０２の構成はコンピュータ２００の構成と同一である。

コンピュータ２００はＲＯＭ２０２のプログラム用ＲＯＭあるいは外部記憶装置２０５に記憶された文書処理プログラム等に基づいて図形、イメージ、文字、表（表計算等を含む）等が混在した処理を実行するＣＰＵ２０１を備える。さらに、システムバス２０４に接続される各デバイスをＣＰＵ２０１が統括的に制御する。また、これら以外に入出力装置を備えていても良い。

また、このＲＯＭ２０２のプログラム用ＲＯＭあるいは外部記憶装置２０５には、ＣＰＵ２０１の制御プログラムであるオペレーションシステム等を記憶する。また、ＲＯＭ２０２のデータ用ＲＯＭあるいは外部記憶装置２０５には各種データを記憶する。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能し、ネットワークＩ／Ｆ制御部２０６は、ＬＡＮ２０７とのデータの送受信を制御する。

図１において、ＬＡＮ２０７は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１により、サーバコンピュータ１０２とクライアントコンピュータ１０３が属するＬＡＮ２０７とは、ファイアウォールを越えて通信が可能である。ＬＡＮ２０７、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。図１において、サーバコンピュータ１０２は、１台のサーバとして示されているが複数台のサーバコンピュータで構成されていても構わない。また、仮想ＰＣとして構成されていても構わない。

加えて、ＣＰＵ２０１が外部記憶装置２０５に記憶されているプログラムに基づき処理を実行することによって、図５に示されるようなコンピュータ２００のソフトウェア構成及び後述するフローチャートの各ステップの処理が実現される。なお、以降の説明でコンピュータ２００はクライアントコンピュータ１０３又はサーバコンピュータ１０２であっても同じである。

本発明を実施するにあたって、クライアントおよびサーバは対象プロトコルを管理する機構を備える必要がある。本明細書はサーバおよびクライアント両方で実施する例を示す。しかし、本発明はサーバ又はクライアントの片方だけで実施しても効果を得ることができる。

コンピュータ２００のソフトウェア構成を図５に示す。ここでクライアントコンピュータ１０３のソフトウェア構成及びサーバコンピュータ１０２のソフトウェア構成はコンピュータ２００のソフトウェア構成と同一である。

ＴＣＰレイヤまでの管理機構はＲＦＣ７９３（ＴＲＡＮＳＭＩＳＳＩＯＮ ＣＯＮＴＲＯＬ ＰＲＯＴＯＣＯＬ）を満たし、利用可能なＡＰＩが提供されていればどのような実施方法でも構わない。多くの場合、オペレーティングシステムがＴＣＰレイヤを操作するためのＡＰＩを提供することが一般的である。また、対象プロトコルはＴＣＰを利用するため、ＴＣＰ以上の性能を出すことは出来ない。

５０４はＳＳＬ、ＴＬＳレイヤを管理する処理部である。本対象プロトコルはＳＳＬ、ＴＬＳを利用する必要はないが、現実的にはセキュリティやファイアウォールの問題からＳＳＬ、ＴＬＳを利用する場合が多いため記述した。ＳＳＬ、ＴＬＳ管理処理部５０４は、規格（ＲＦＣ２２４６、ＲＦＣ４３４６）に準拠した実施になっていれば、どのような実施方法でも構わない。また、この処理部がＳＳＬ、ＴＬＳ以外の中間プロトコルであっても構わない。

プロトコル管理処理部５０１は対象プロトコルのセッションを管理する処理部である。プロトコル管理処理部５０１は上位レイヤアプリケーション５００へのインターフェースの提供、また下位レイヤに対してデータの送受信も管理する。プロトコル管理処理部５０１は全ての対象プロトコルの処理を行わず、セッション管理処理部５０２に実際の処理を委譲する。

セッション管理処理部５０２は対象セッションのストリームを管理する。各ストリームはストリームバッファ５０７とストリーム状態ストア５０８を持つ。ストリーム状態ストア５０８はストリームがどのような状態かを保存しておく記憶領域である。ストリームバッファ５０７はひとつのストリームに対して２つのバッファを持つ。送信用バッファと受信用バッファである。

ここで図５において、ストリームバッファ５０７、ストリーム状態ストア５０８については格納場所を示しており、両者はプログラムではない。

ここで本発明の実施において、送信用バッファは必ずしも必須ではないが、一般的にネットワークの送受信に関してバッファを持つことでパフォーマンスを向上させることが多い。そのため、送信用のバッファを使用した実施とする。ストリームバッファ５０７はストリーム作成時にデフォルトサイズに基づき送受信用の２つのバッファを持つ。この前記デフォルトサイズは予め対象プロトコルで定められているとする。

ここで送信バッファの前記デフォルトサイズに関しては対象プロトコルに定められたデフォルトサイズを利用することは必須ではない。

またセッション管理処理部５０２は最大フレームサイズを決定する際に最大フレームサイズ決定処理部を使用する。最大フレームサイズ決定処理部５０３はストリームが使用できる最大フレームサイズを算出する処理部である。最大フレームサイズ決定処理部５０３は必要なタイミングで呼び出され、全てのストリームの最大ウィンドウサイズと優先度から最適な最大フレームサイズを決定する。

次に対象プロトコルを用いたデータの送受信の流れについて説明する。ただし、ＳＳＬ、ＴＬＳ管理処理部５０４、ＴＣＰ管理処理部５０５、下位レイヤ管理処理部５０６及び送信バッファと受信バッファにおける詳細な処理の流れについては記述しない。これらの具体的な処理方法は本発明の処理方法とは直接関係なく、これらの実施方法が広く一般的に知られているためである。またネットワークＩ／Ｆ５０９はネットワークＩ／Ｆ制御部２０６のソフトウェア処理部を示す。

プロトコル管理処理部５０１の処理の流れについて、図６に示す。ここでストリーム作成処理（Ｓ６０３）、データ送信要求処理（Ｓ６０７）、データ受信要求処理（Ｓ６０９）、セッション定期処理（Ｓ６１２）については、セッション管理処理部５０２によって処理が行われる。まず初期状態の場合、ひとつもセッションが作成されていないので、プロトコル管理処理部５０１は上位アプリケーションからリクエスト受付（Ｓ６００）にて、セッション作成のリクエストを待つこととなる。もし、何もリクエストが無い場合は、未処理セッションがあるかどうかの判定（Ｓ６０１）を通ることとなるが、現段階ではセッションがひとつも無いので上位アプリケーションからリクエスト受付（Ｓ６００）へ戻る。セッション作成のリクエスト（Ｓ６０２）があった場合、セッション作成処理（Ｓ６０３）を呼ぶ。

セッション作成処理の流れについて図７に示す。

プロトコル管理処理部５０１は接続形態に応じてサーバ側として動作を行うかクライアント側として動作を行うか判定（Ｓ７００）を行う。すなわち、上位レイヤアプリケーション５００がブラウザであるかＷｅｂサーバソフトウェアであるかによって、プロトコル管理処理部５０１の処理が決まる。上位レイヤアプリケーションがブラウザの場合はクライアント側として動作して、Ｗｅｂサーバソフトウェアの場合はサーバ側として動作する。サーバとして動作を行うと判定した場合、接続受付処理（Ｓ７０１）を行う。この処理はクライアントがＴＣＰ接続を要求してくるのを待機する処理である。クライアントから要求があった場合、処理を抜ける。一方でクライアントとして動作を行うと判定した場合、接続処理（Ｓ７０２）を行う。接続処理はＴＣＰ接続をサーバに対して要求するものである。成功した場合この処理を抜ける。それぞれの形態で接続に関する処理が終了後、ＴＣＰコネクション確立（Ｓ７０３）にて、ＴＣＰレイヤのデータ送受信が可能な状態にする。

もしＳＳＬ／ＴＬＳ処理も行う場合は、ＴＣＰコネクション確立処理の内部にて隠蔽されて処理が行われる。すなわち、ＳＳＬ／ＴＬＳで処理を行う場合はＴＣＰレイヤにデータが渡る前にＳＳＬ／ＴＬＳ処理が行われる。

ＴＣＰコネクション確立（Ｓ７０３）後、セッション作成処理（Ｓ６０３）を抜ける。

図７のように一つのモジュールでサーバとクライアントの処理を行うメリットとして、複数のプログラム間でモジュールを共通化できるメリットがある。

図６にてセッション作成処理（Ｓ６０３）終了後、後述するＳ６１１と必要に応じてＳ６１２を経て上位アプリケーションからのリクエスト受付（Ｓ６００）のループに戻る。

次に、ストリーム作成リクエスト（Ｓ６０４）があった場合、セッション管理処理部５０２によってストリーム作成処理（Ｓ６０５）が行われる。

また、データ送信リクエスト（Ｓ６０６）があった場合、セッション管理処理部５０２によってデータ送信要求処理（Ｓ６０７）が行われる。

同様に、データ受信リクエスト（Ｓ６０８）があった場合、セッション管理処理部５０２によってデータ受信要求処理（Ｓ６０９）が行われる。

また、これらのリクエスト以外にも対象プロトコルがリクエストの種類を増やしても良い。そのため、その他処理（Ｓ６１０）にて、その他のリクエストに関する対応処理を行う。

最後に、未処理セッションの有無判定（Ｓ６１１）にて、未処理セッションがあった場合、セッション管理処理部５０２によってセッション定期処理（Ｓ６１２）が行われる。このセッション定期処理（Ｓ６１２）は利用中のセッションの数だけ呼ばれる。全てのセッションを管理する、プロトコル管理処理部５０１の処理の流れの説明は以上である。

次にセッション管理処理部５０２について処理の流れを説明する。セッション管理処理部５０２は前述したようにプロトコル管理処理部５０１によって呼び出される。また、セッション管理処理部５０２は各ストリームに対応するバッファであるストリームバッファ５０７の作成、サイズ変更、追加、取得、および削除を行う。

ストリーム作成処理（Ｓ６０５）の流れについて図８を用いて説明する。まずストリームＩＤの決定（Ｓ８０１）にてストリームＩＤを決定する。この処理は１つのセッションの中でストリームに付けるＩＤを一意にするために行う。ここでサーバ側から作成したストリームと、クライアント側から作成したストリームでストリームＩＤが重複しないようにする必要がある。そのためにストリームＩＤの決定にて重複チェックを行っても良いし、対象プロトコルにクライアント側作成した場合は偶数、サーバ側から作成した場合は奇数といった制約をかけても良い。ストリームＩＤが決定した後、対応するコントロールフレーム４０１の作成を行う。この処理では対象プロトコルの仕様に従い、ストリーム作成用のコントロールフレームを作成（Ｓ８０２）する。次に送信キューにコントロールフレーム４０１のプッシュ処理（Ｓ８０３）を行う。送信キューはＴＣＰレイヤが管理しており、送信キューにプッシュした時点でＴＣＰ管理処理部５０５が、必要に応じて送信を行う。最後にストリーム状態ストアに該当ストリームＩＤを追加（Ｓ８０４）することで、作成要求を送信したことをストリーム状態ストア５０８に記録する。しかし、まだ、ストリーム作成要求が受け入れられていないので、状態を受け入れ待ちとする。

次にデータ送信要求処理（Ｓ６０７）について説明する。この処理は上位アプリケーションが、とあるストリームを用いてデータを送信したい場合に、プロトコル管理処理部５０１を通して呼び出される。まず上位アプリケーションが送信したいデータのサイズを取得する。そして、取得したデータを送信バッファの空きサイズに収まる分だけ格納する。これにより、送信バッファがデータ溢れを起こすのを防ぐ。なお、データは送信バッファに格納しておくだけであり、実際に送信が行われるのはセッション定期処理（Ｓ６１２）内である。

同様にデータ受信要求処理（Ｓ６０９）について説明する。この処理もデータ送信要求処理（Ｓ６０７）と同様に、あるストリームから受信したデータを取得したい場合に、プロトコル管理処理部５０１を通して呼び出される。セッション管理処理部５０２はプロトコル管理処理部５０１から処理を委託された後、受信バッファからデータを読み出す。

セッション管理処理部５０２の残りの処理であるセッション定期処理（Ｓ６１２）について図１１を用いて説明する。この処理は各セッションに対して定期的にプロトコル管理処理部５０１から呼び出され、有効な各セッションに対して１回ずつ呼び出される。セッション管理処理部５０２はまず、データ受信処理（Ｓ１１００）にてＴＣＰレイヤから通信データの受信、および解析を行う。また、データ受信処理の後、データ送信処理（Ｓ１１０１）にて、各ストリームの送信バッファに溜まっているデータの送信を行う。これらデータ受信処理（Ｓ１１００）、およびデータ送信処理（Ｓ１１０１）については、セッション定期処理（Ｓ６１２）の説明後、詳細に説明する。次にセッション管理処理部５０２は未処理ストリームがあるかを確認する（Ｓ１１０２）。もし未処理ストリームがある場合、状態読み出し（Ｓ１１０３）にて、ストリーム状態ストア５０８から、該当するストリームの状態を読み出す。

ストリームの状態が作成要求中だった場合（Ｓ１１０４）、続いて受け入れ側が作成承認を行ったかどうかの判定を行う（Ｓ１１０５）。ここで作成承認が行われていた場合、ストリームの状態を通信状態に変更（Ｓ１１０６）し、次の未処理ストリームの確認（Ｓ１１０２）に戻る。ストリームの状態が作成要求中または作成承認を受信した状態のいずれでもない場合は、なにも処理を行わずに、未処理ストリームの確認（Ｓ１１０２）に戻る。

Ｓ１１０２で未処理ストリームがない場合は処理を終了する。

セッション定期処理（Ｓ６１２）の大まかな処理の流れは以上となる。

続いてデータ受信処理の詳細な処理の流れについて図１２を用いて説明する。セッション管理処理部５０２は、まずＴＣＰレイヤから未受信データがあるか確認を行う（Ｓ１２００）。ここでもし未受信データがあった場合、ヘッダ部分の読み出し（Ｓ１２０１）を行う。フレーム３０１にはフレームに格納することのできるデータのサイズを示すフレームサイズがある。Ｓ１２０２ではフレーム３０１のフレームサイズを取得する。フレームサイズを取得することでボディ部の位置を把握することができる。次にフレーム３０１のボディ部の読み込みを行う（Ｓ１２０３）。

ここでは、セッション管理処理部５０２は全てのボディ部の受信が終わるまで、処理をブロックしても良いし、次回以降のセッション定期処理（Ｓ６１２）で処理するとして、後回しにしても良い。すなわち、一般的に通信ライブラリは非同期であることが多いが、本明細書では同期である例を記載している。しかし、本発明を実施するにあたり一般的な通信ライブラリと同様に非同期で処理を行なっても構わない。

ボディ部の読み込みが成功した後、セッション管理処理部５０２はフレーム３０１の種類によって処理を分岐させる（Ｓ１２０４）。フレーム３０１の種類がコントロールフレームだった場合、内容がストリーム作成承認であるかどうかを判定する（Ｓ１２０５）。ストリーム作成承認だった場合、ストリーム状態ストア５０８に格納されている、該当するストリームの状態を通信状態に変更する（Ｓ１２０７）。もし、ストリーム作成承認以外のコントロールフレームであった場合、種類にあった処理を、その他コントロールフレーム処理（Ｓ１２０６）にて行う。その他コントロールフレームとは、例えばストリーム作成の承認拒否や通信速度の通知といった、対象プロトコルにて独自に定めたものである。本実施例において、直接関わりの無いコントロールフレームの処理については記述しない。コントロールフレームを受信した際の処理は以上である。次にフレーム３０１の種類の判定において、データフレームだった際の説明を行う。セッション管理処理部５０２は受信したフレーム３０１がデータフレームであると判定した場合、データストリーム４０２のストリームＩＤをフレームヘッダから取得する（Ｓ１２０８）。その後、対象ストリームの受信バッファにデータフレームのボディ部を追加する（Ｓ１２０９）。

ここで対象プロトコルが双方向通信を行ってかつ受信ウィンドウサイズの通知が間に合わない場合に、相手先の対象ストリームの受信バッファが溢れてしまう恐れがある。このような問題を防ぐ仕組みがＴＣＰでは実現されているが、本明細書では対象プロトコルでも受信バッファが溢れる問題に対する対処が二重でなされているものとする。

本明細書では対象プロトコルのウィンドウサイズとバッファ溢れの詳細な制御については記述しないが、方法としては、バッファから溢れた分のサイズを、コントロールフレームを利用して通知する等がある。ボディ部に追加後、上位アプリケーションは該当ストリームが受信したデータを取得できるようになる。該当ストリームの受信バッファにデータ追加後、再び未受信データの確認（Ｓ１２００）へ戻る。もし、未受信データの確認で、ＴＣＰレイヤにおいて受信データが無い場合、このデータ受信処理を抜ける。

次に、データ送信処理の詳細な処理の流れについて図１３を用いて説明する。まず、セッション管理処理部５０２は各ストリームの送信バッファを確認し、未送信データがあるかどうか判定する（Ｓ１３００）。この判定の際、全ての未送信データを送らなければこの処理を抜けられないことから、無限ループに陥る可能性を回避するために、実行回数に制限を設けても良い。もし未送信データがある場合、未送信データのあるストリームのうち、どのストリームのデータを送信するかを送信ストリームバッファ選択にて決定する（Ｓ１３０１）。この処理はストリームの優先順位によって決まり、優先順位の高いものは送信ストリームバッファを選択する頻度を多く、逆に優先順位の低いものは送信ストリームバッファを選択する頻度を少なくする。

送信ストリームバッファを選択後、最大フレームサイズを決定する（Ｓ１３０２）。この最大フレームサイズの決定は最大フレームサイズ決定処理部５０３にて行われ、ストリームに対して最適な最大フレームサイズを算出する。最大フレームサイズ決定（Ｓ１３０２）の詳細な処理の流れは後述する。

最大フレームサイズを決定後、セッション管理処理部５０２は受信側ウィンドウサイズと最大フレームサイズを比較する（Ｓ１３０３）。もし、受信側ウィンドウサイズの方が、最大フレームサイズよりも大きければ、最大フレームサイズ分をストリームバッファ５０７から取得する（Ｓ１３０４）。一方で最大フレームサイズの方が受信側ウィンドウサイズよりも大きければ、受信側ウィンドウサイズ分をストリームバッファ５０７から取得する（Ｓ１３０５）。特に図に明記されていないが、送信ストリームバッファにこれらのサイズ未満のデータしかない場合には、全てのデータを取得することとなる。送信するデータを取得後、セッション管理処理部５０２は取得したデータを用いてデータフレームを作成する（Ｓ１３０６）。最後にＴＣＰレイヤの送信キューに作成したデータフレームを追加する（Ｓ１３０７）。ここでＴＣＰレイヤの送信キューが溢れていて追加できない場合は、別途待ち合わせや非同期処理といった回避策を取る必要がある。データフレームを送信キューに追加後、残りの未送信データがあるどうかの判定（Ｓ１３００）に戻る。もし未送信データが無い場合、データ送信処理を抜ける。

データ送信処理内で呼ばれる、最大フレームサイズ決定処理の流れについて図１４を用いて詳細に説明する。最大フレームサイズ決定処理部５０３は、まず最も小さい最大ウィンドウサイズを算出する（Ｓ１４００）。最も小さい最大ウィンドウサイズとは、各ストリームの最大受信ウィンドウサイズのうち最も小さいもののことである。これは、受信ウィンドウサイズが動的に変更されることを考慮するために算出される。

ここでは処理を簡単にするために、最も小さい最大ウィンドウサイズを選択するが、各ストリームの最大ウィンドウサイズの平均等を用いても良い。ただし、ここで算出する値が該当ストリームの受信ウィンドウサイズを上回る場合、受信ウィンドウサイズに制限する必要がある。次に、最大フレームサイズを決定する（Ｓ１４０１）。

ここで本発明では、最大フレームサイズは優先順位の高いストリーム程大きく、逆に優先順位の低いストリーム程小さくなるように構成する。例として、最大フレームサイズ＝最小の最大ウィンドウサイズ／（優先順位＋１）、といった式で決定できる（図１５）。

この例以外にも等差的に最大フレームサイズを制限するなどの算出方法でも良い。すなわち、優先順位が下がるごとに一定間隔でフレームサイズを小さくしても構わない。

最大フレームサイズ決定処理部５０３は、最大フレームサイズを決定後、処理を抜ける。

これにより高い優先順位のストリームの割り込みに素早く応答出来るようになる。よって、Ｗｅｂアプリケーション等からの優先順位の高い要求に対して、応答速度を速くすることができる。

次にストリームの依存関係を用いて優先順位を決定する例について説明する。

対象プロトコルのデータ構造の説明にて、各ストリームは依存関係を持っても良いことを示した。もし別のストリームに依存していれば、そのストリームＩＤを持つことで親子関係を表しても良い。また、対象プロトコルは複数のストリームを同時並列に送受信することが出来る。そのため、対象プロトコルの上位レイヤには、様々なプロトコルやアプリケーションが同時に混在する場合がある。その時、あるプロトコル、またはアプリケーションが、あるストリームに対して更にストリームを作りたい場合、元となるストリームを親として依存関係を持たせることができる。

しかし、ストリームの優先順位をクライアント、サーバが自由に決定できる対象プロトコルの場合、一部のプロトコル、またはアプリケーションが高優先度のストリームを大量に作れる。例えば、図１０（ａ）のストリームグループａ１７００は５つの子ストリームを含み、一方でストリームグループｂ１７０１は３つの子ストリームを含んでいる。ここで、ストリームグループａ１７００がすべてのストリームを高優先度として作成した場合、ストリームグループｂ１７０１は帯域を圧迫され帯域を公平に利用できなくなる恐れがある。

なお、このように複数のストリームグループが同一のセッションで作成される例として、ＨＴＴＰとＷｅｂＳｏｃｋｅｔを用いて通信する例が挙げられる。すなわち、ストリームグループａはＨＴＴＰで通信し、ストリームグループｂはＷｅｂＳｏｃｋｅｔで通信する。

そこで、最大フレームサイズ決定（Ｓ１４０１）処理において、依存関係の深さに応じて優先順位を下げて最大フレームサイズを決定する。

図１０（ａ）においてどのストリームにも依存しない、すなわち親ストリームがある。ここでは、ストリームＡとストリームＢである。この２つは依存関係が最も浅いので優先順位は変化させない。また、これらのストリームを親とするストリームＡＡ，ＡＢ，ＢＡは依存関係が１つ深い。そのためセッション管理処理部５０２が、依存関係を考慮し、優先順位を１つ低くする。以下同様に、依存関係の深いストリーム程、優先順位を下げる処理を行う。

ただし、優先順位が対象プロトコルで設定可能な優先順位の範囲を超える場合、優先順位の範囲に収める処理が必要となる。具体的には対象プロトコルの最も低い優先順位が７であってかつ優先順位を下げる対象ストリームの優先順位が既に７である場合には対象ストリームの優先順位を７のままにする。

次に図１０（ａ）を用いて説明した方法で具体的に効果が生じる例について、図１０（ｂ）及び図１０（ｃ）の事例を比較して説明を行う。

これから説明する事例では図１０（ａ）を用いて説明した方法で決定した優先順位をコンピュータ２００のＣＰＵが割り当てる時間に活用する事例である。実際にはＣＰＵがストリームの処理に秒単位で時間を割り当てることは現実的ではないが、ここでは簡単のため秒を単位として事例を説明する。具体的には優先順位が０であるストリームの処理に３秒を割り当て、優先順位が１であるストリームの処理に２秒を割り当て、優先順位が２であるストリームの処理に１秒を割り当てる。

図１０（ｂ）及び図１０（ｃ）ではストリームＡは優先順位が０であり、ストリームＢは優先順位が２である。そしてストリームＡは子ストリームを２つ有し、ストリームＢは親ストリームである。

ここで図１０（ｂ）は依存度に基づいて子ストリームの優先順位を変更しない事例である。その結果、ストリームグループａの処理には合計で９秒を要し、ストリームグループｂの処理には１秒を要する。

これに対して図１０（ｃ）は依存度に基づいて子ストリームの優先順位を変更する事例である。その結果、ストリームＡの子ストリームに要する処理時間が短くなるため、ストリームグループａの処理には合計で７秒を要し、ストリームグループｂの処理には同じく１秒を要する。

よって、図１０（ｂ）ではストリームグループａとストリームグループｂの処理時間の比が９：１となるのに対し、図１０（ｃ）では７：１となる。これにより図１０（ｃ）は図１０（ｂ）と比べれば、ストリームグループ間で不公平である環境が若干是正される。

なお、ここで説明した処理時間の例は優先順位を用いて処理する方法の一例である。他に優先順位を用いた処理としてはＣＰＵが処理する割合を変える方法や、ストリームを送信する順番を変える方法が考えられる。また、優先順位はコンピュータ２００内で処理するためだけに活かしても構わないし、あるいは決定した優先順位をストリームのフレームを含むＩＰパケットのヘッダに入力してその優先順位が入力されたＩＰパケットを送信しても構わない。後述したＩＰパケットのヘッダに入力する方法では、そのＩＰパケットを受け取ったルーターやコンピュータが優先順位を活用することもできる。

依存関係の深いストリームの優先順位を下げることにより、一部のストリームグループが大量に子ストリームを作成した場合でも、他のストリームグループと共に公平に通信帯域を分け合うことが出来る。

なお、子ストリームの優先順位を決定後にその子ストリームのフレームサイズを変更するかどうかは任意である。子ストリームのフレームサイズを変更せずに、優先順位のみを親ストリームよりも低い優先順位に決定しても構わない。このように構成することでもストリームグループａとストリームグループｂ間の公平性を高めることができる。

実施例１における最大フレームサイズ決定処理（Ｓ１４０１）では、各ストリームの最大ウィンドウサイズと優先順位によって最適な最大フレームサイズを決定する手法を示した。本実施例では、常にストリームの数と優先順位が変動するモデルに対して、より動的に対応できる実施例を示す。

図９を用いて、本実施例による最適な最大フレームサイズの決定法について説明する。図９は、ある時間において、各優先順位の属するストリームの数を表している。（ａ）は実施例１と同様の処理を行う際の各ストリームと優先順位の状態である１６００。ここで優先順位を最も高いものが０、最も低いものを３である対象プロトコルであるとする。もちろん、実際にはプロトコル規定の優先順位数はいくつであっても良い。（ａ）には優先順位の最も低い３のストリーム２つ。また、優先順位のやや低い２のストリームが１つ、計３つのストリームが存在する。これらの３つのストリームよりも高い優先順位を持つストリームは存在していない。優先順位の高い（優先順位が０及び１である）ストリームが存在しない状態であるが、対象プロトコルは優先順位を自由に決められるため、このような状態も有りうる。また、優先順位の高いストリームが通信を終了した直後などでも、このような状態になる可能性がある。この状態で実施例１にあるような最大フレームサイズの決定法を用いると、実質的には優先順位が２又は３であるストリームに対して、過度にフレームサイズの制限を強制することになる。そのためフレームヘッダのオーバヘッドが生じ、通信速度が遅くなる可能性がある。

この問題のために、図９の（ｂ）で示されるように、本来プロトコルの優先順位数は４つであるが、使われていない優先順位に既に使われている優先順位のストリームを詰めて設定する。ここで、１６０１が実際の優先順位とストリームの関係表である。また、１６０２は詰めて設定した優先順位とストリームの関係表である。この実施によって（ｂ）では、実質的には優先順位の種類が２つのプロトコルとして扱うことができる。よって実施例１で説明した優先順位による最大フレームサイズの決定を行った際に、（ａ）と比べて、相対的にフレームサイズを大きくすることできる。

以上、説明した本実施例によれば、一時的に優先順位の高いストリームが存在しない場合に、仮想的に全体の優先順位数を状況に合わせて変動させるため、フレームヘッダ分のオーバヘッドを減らし、通信速度を向上出来る。

［他の実施形態］
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良い。

また仮想化ＯＳなどで構成される場合も含めて一つの機器からなる装置に適用しても良い。さらに、情報処理装置がインターネットを経由したクラウドコンピューティングで構成されるシステムに適用しても良い。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。

また、プログラムの実行環境は、パーソナルコンピュータやパーソナルコンピュータでのオペレーションシステムを仮想化した仮想ＰＣやリモートＰＣを含む。

さらには、画像形成装置、プリンタやＭＦＰ（マルチファンクションペリフェラル）等の組み込みコンピュータで実行される場合も含まれる。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、様々なものが使用できる。

例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどである。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＤＶＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。

Claims (11)

1. 通信プロトコルの論理チャネルである第２のストリームの最大フレームサイズを、前記第２のストリームの親ストリームでありかつ前記通信プロトコルの前記論理チャネルである第１のストリームの最大フレームサイズよりも小さく設定する設定手段と、
   前記第１のストリームのフレームと前記第２のストリームのフレームを送信する送信手段と、
   前記第１のストリームの優先順位が第１の優先順位でかつ前記第１のストリームの優先順位より高い優先順位であるストリームが存在しない場合に前記第１のストリームの優先順位を前記第１の優先順位より高い第２の優先順位に変更する変更手段と、を有することを特徴とする情報処理装置。
2. 前記第１のストリームの処理時間を前記第２のストリームの処理時間よりも長くなるように制御する調整手段を有することを特徴とする請求項１に記載の情報処理装置。
3. ＴＣＰ接続の要求を待機する処理とＴＣＰ接続を要求する処理を一つのモジュールにより行うことを特徴とする請求項１又は請求項２に記載の情報処理装置。
4. 前記設定手段は前記第１のストリームの優先順位が前記通信プロトコルの優先順位の範囲で最も低い場合に前記第２のストリームの優先順位を前記第１のストリームの優先順位と同一に設定することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記第１のストリームの優先順位を前記第１のストリームのフレームを含むＩＰパケットのヘッダに入力して、前記第２のストリームの優先順位を前記第２のストリームのフレームを含むＩＰパケットのヘッダに入力する入力手段を有することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. コンピュータに、
   通信プロトコルの論理チャネルである第２のストリームの最大フレームサイズを、前記第２のストリームの親ストリームでありかつ前記通信プロトコルの前記論理チャネルである第１のストリームの最大フレームサイズよりも小さく設定する設定工程と、
   前記第１のストリームのフレームと前記第２のストリームのフレームを送信する送信工程と、
   前記第１のストリームの優先順位が第１の優先順位でかつ前記第１のストリームの優先順位より高い優先順位であるストリームが存在しない場合に前記第１のストリームの優先順位を前記第１の優先順位より高い第２の優先順位に変更する変更工程と、を実行させることを特徴とするプログラム。
7. 前記コンピュータに、
   前記第１のストリームの処理時間を前記第２のストリームの処理時間よりも長くなるように制御する調整工程を実行させることを特徴とする請求項６に記載のプログラム。
8. ＴＣＰ接続の要求を待機する処理とＴＣＰ接続を要求する処理を一つのモジュールにより行うことを特徴とする請求項６又は請求項７に記載のプログラム。
9. 前記設定工程は前記第１のストリームの優先順位が前記通信プロトコルの優先順位の範囲で最も低い場合に前記第２のストリームの優先順位を前記第１のストリームの優先順位と同一に設定することを特徴とする請求項６乃至８のいずれか１項に記載のプログラム。
10. 前記コンピュータに、
    前記第１のストリームの優先順位を前記第１のストリームのフレームを含むＩＰパケットのヘッダに入力して、前記第２のストリームの優先順位を前記第２のストリームのフレームを含むＩＰパケットのヘッダに入力する入力工程を実行させることを特徴とする請求項６乃至９のいずれか１項に記載のプログラム。
11. 通信プロトコルの論理チャネルである第２のストリームの最大フレームサイズを、前記第２のストリームの親ストリームでありかつ前記通信プロトコルの前記論理チャネルである第１のストリームの最大フレームサイズよりも小さく設定する設定工程と、
    前記第１のストリームのフレームと前記第２のストリームのフレームを送信する送信工程と、
    前記第１のストリームの優先順位が第１の優先順位でかつ前記第１のストリームの優先順位より高い優先順位であるストリームが存在しない場合に前記第１のストリームの優先順位を前記第１の優先順位より高い第２の優先順位に変更する変更工程と、を有することを特徴とする制御方法。
    

Images