(57)【要約】【課題】複数の通信に対してネットワーク帯域を適切に割り当てることのできる通信処理技術を提供する。【解決手段】ポリシーテーブル記憶部１４は、通信単位を識別する識別子と、当該通信単位に適用されるポリシーの識別子および優先度とを対応づけたポリシーテーブルを記憶する。ポリシー番号・優先度取得部２２ａ、２２ｂは、当該通信のプロトコル処理の際、前記ポリシーテーブルを参照して、当該通信の識別子に対応づけられたポリシーの識別子および優先度を取得する。ポリシー適用部２４ａ、２４ｂは、同一のポリシーの識別子に対応づけられた１以上の通信単位をグループ化して、グループ化された１以上の通信単位に対しては、同一のポリシーを適用する。帯域制御部２６ａ、２６ｂは、各通信単位に対して優先度にもとづいて帯域制御を行う。【選択図】図１
2014239308.tif 000002
【特許請求の範囲】
【請求項１】
通信単位を識別する識別子と、当該通信単位に適用されるポリシーの識別子および優先度とを対応づけたポリシーテーブルを記憶する記憶部と、
当該通信のプロトコル処理の際、前記ポリシーテーブルを参照して、当該通信の識別子に対応づけられたポリシーの識別子および優先度を取得する取得部と、
同一のポリシーの識別子に対応づけられた１以上の通信単位をグループ化して、グループ化された１以上の通信単位に対しては、同一のポリシーを適用するポリシー適用部と、
各通信単位に対して前記優先度にもとづいて帯域制御を行う帯域制御部とを含むことを特徴とする通信処理装置。
【請求項２】
前記ポリシーテーブルにおいて前記ポリシーの識別子にはネットワークの要求帯域が対応づけられており、
前記帯域制御部は、前記グループ化された１以上の通信単位に対して、前記同一のポリシーの識別子に対応づけられた要求帯域のもとで帯域制御を行うことを特徴とする請求項１に記載の通信処理装置。
【請求項３】
前記帯域制御部は、前記同一のポリシーの識別子に対応づけられた要求帯域を、前記グループ化された１以上の通信単位の間で共有するように帯域制御することを特徴とする請求項１または２に記載の通信処理装置。
【請求項４】
前記帯域制御部は、前記同一のポリシーの識別子に対応づけられた要求帯域を、前記グループ化された１以上の通信単位のそれぞれが使用するように帯域制御することを特徴とする請求項１または２に記載の通信処理装置。
【請求項５】
前記帯域制御部は、注目する優先度よりも高い優先度の通信単位の要求帯域と、前記注目する優先度の通信単位の消費帯域との合計が、ネットワークの最大帯域よりも大きい場合、前記注目する優先度の通信単位に対して帯域制御を行うことを特徴とする請求項１から４のいずれかに記載の通信処理装置。
【請求項６】
通信単位を識別する識別子と、当該通信単位の要求帯域および優先度とを対応づけたテーブルを参照して、注目する優先度よりも高い優先度の通信単位の要求帯域と、前記注目する優先度の通信単位の消費帯域との合計が、ネットワークの最大帯域よりも大きい場合、前記注目する優先度の通信単位に対して帯域制御を行う通信処理方法。
【請求項７】
通信単位を識別する識別子と、当該通信単位に適用されるポリシーの識別子および優先度とを対応づけたポリシーテーブルを参照して、当該通信のプロトコル処理の際、当該通信の識別子に対応づけられたポリシーの識別子および優先度を取得する機能と、
同一のポリシーの識別子に対応づけられた１以上の通信単位をグループ化して、グループ化された１以上の通信単位に対しては、同一のポリシーを適用する機能とをコンピュータに実現させることを特徴とするプログラム。
【請求項８】
通信単位を識別する識別子と、当該通信単位に適用されるポリシーの識別子および優先度とを対応づけたポリシーテーブルを参照して、当該通信のプロトコル処理の際、当該通信の識別子に対応づけられたポリシーの識別子および優先度を取得するステップと、
同一のポリシーの識別子に対応づけられた１以上の通信単位をグループ化して、グループ化された１以上の通信単位に対しては、同一のポリシーを適用するステップとを含むことを特徴とする通信処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信処理装置および通信処理方法に関する。
【背景技術】
【０００２】
ブロードバンドネットワークの普及によって、パーソナルコンピュータをネットワークに接続してビデオやオーディオのストリームを配信することが盛んになっている。さらに、テレビ受信装置、ビデオ録画機、ゲーム機、携帯電話などの各種機器が通信機能をもち、パーソナルコンピュータとともに家庭内ネットワークに接続されたり、ホームサーバやルータなどを経由して外部のネットワークに接続し、様々なネットワークアプリケーションを利用することも行われている。
【０００３】
特許文献１には、ソケット通信をグループ化して、グループ化されたソケット通信に対しては、同一のポリシーを適用することのできる通信処理技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−９７２７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
複数のアプリケーションが同時にネットワークを利用する環境において、特定のアプリケーションがネットワーク帯域を占有すると、他のアプリケーションにネットワーク帯域が十分に割り当てられないという問題がある。たとえば、ゲームアプリケーションとボイスチャットが同時に動作する場合や、ゲームアプリケーションとバックグラウンドダウンロードが同時に動作する場合などである。ここで、バックグラウンドダウンロードとは、ゲーム中にそのゲームとは独立した別のアプリケーションやデータをバックグラウンドでダウンロードすることである。
【０００６】
また、複数のアプリケーションが同時にネットワーク帯域を使えるだけ使おうとすると、アプリケーション間で帯域要求が競合し、個々のアプリケーションのサービス品質が維持できなくなる。
【０００７】
本発明はこうした課題に鑑みてなされたものであり、その目的は、複数の通信に対してネットワーク帯域を適切に割り当てることのできる通信処理技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明のある態様の通信処理装置は、通信単位を識別する識別子と、当該通信単位に適用されるポリシーの識別子および優先度とを対応づけたポリシーテーブルを記憶する記憶部と、当該通信のプロトコル処理の際、前記ポリシーテーブルを参照して、当該通信の識別子に対応づけられたポリシーの識別子および優先度を取得する取得部と、同一のポリシーの識別子に対応づけられた１以上の通信単位をグループ化して、グループ化された１以上の通信単位に対しては、同一のポリシーを適用するポリシー適用部と、各通信単位に対して前記優先度にもとづいて帯域制御を行う帯域制御部とを含む。
【０００９】
本発明の別の態様は、通信処理方法である。この方法は、通信単位を識別する識別子と、当該通信単位の要求帯域および優先度とを対応づけたテーブルを参照して、注目する優先度よりも高い優先度の通信単位の要求帯域と、前記注目する優先度の通信単位の消費帯域との合計が、ネットワークの最大帯域よりも大きい場合、前記注目する優先度の通信単位に対して帯域制御を行う。
【００１０】
本発明のさらに別の態様は、プログラムである。このプログラムは、通信単位を識別する識別子と、当該通信単位に適用されるポリシーの識別子および優先度とを対応づけたポリシーテーブルを参照して、当該通信のプロトコル処理の際、当該通信の識別子に対応づけられたポリシーの識別子および優先度を取得する機能と、同一のポリシーの識別子に対応づけられた１以上の通信単位をグループ化して、グループ化された１以上の通信単位に対しては、同一のポリシーを適用する機能とをコンピュータに実現させる。
【００１１】
このプログラムは、オペレーティングシステムに組み込まれる基本ソフトウエアもしくはライブラリの一部として提供されてもよい。このようなファームウエア、基本ソフトウエアまたはライブラリを提供するため、あるいはこれらの一部をアップデートするために、これらのプログラムを記録したコンピュータ読み取り可能な記録媒体が提供されてもよく、また、これらのプログラムが通信回線で伝送されてもよい。
【００１２】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラム、データ構造、記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１３】
本発明によれば、複数の通信に対してネットワーク帯域を適切に割り当てることができる。
【図面の簡単な説明】
【００１４】
【図１】実施の形態に係る通信処理装置の構成図である。
【図２】図２（ａ）、（ｂ）は、図１のポリシーテーブル記憶部に記憶されるテーブルを説明する図である。
【図３】ソケットＩＤ毎に設定されるポリシー番号および優先度と、ポリシー定義テーブルとの関係を説明する図である。
【図４】本実施の形態の帯域判定処理を説明するフローチャートである。
【図５】図５（ａ）は、受信側の帯域制御を説明するフローチャートであり、図５（ｂ）は、送信側の帯域制御を説明するフローチャートである。
【図６】図６（ａ）および図６（ｂ）は、帯域制御の例を説明する図である。
【図７】図７（ａ）および図７（ｂ）は、帯域制御の別の例を説明する図である。
【図８】図８（ａ）および図８（ｂ）は、帯域制御の別の例を説明する図である。
【図９】図９（ａ）および図９（ｂ）は、帯域制御の別の例を説明する図である。
【図１０】図１０（ａ）および図１０（ｂ）は、帯域制御の別の例を説明する図である。
【図１１】図１１（ａ）および図１１（ｂ）は、帯域制御の別の例を説明する図である。
【発明を実施するための形態】
【００１５】
図１は、実施の形態に係る通信処理装置１００の構成図である。ここでは、通信処理装置１００は、ネットワークに接続され、サーバやクライアントの機能の一部を構成する場合を説明するが、通信処理装置１００は、実際にインターネットなどの実ネットワークに接続しなくても、ローカルネットワーク上でネットワークの状態をエミュレートすることができるエミュレータとして機能させることもできる。その場合、通信処理装置１００は、たとえば、ゲームアプリケーションの開発者がネットワーク環境を想定してゲームプログラムの振る舞いや各種パラメータを調整するために用いられる。
【００１６】
ソケット生成部１０は、アプリケーションからのソケット生成コマンドを受けて、ソケット通信のためのソケットを生成する。このときソケットをユニークに識別するためのソケットＩＤが設定される。このソケットＩＤは、ソケット通信においてソケット生成時に任意に割り当てられるソケットの識別番号であり、具体的にはＢＳＤソケットにおいてソケット作成の成功時に返されるソケットディスクリプタである。
【００１７】
ポリシー番号・優先度設定部１２は、当該ソケット通信に対して適用すべきポリシーをユニークに識別するためのポリシー番号と当該ソケット通信の優先度を設定し、当該ソケット通信のソケットＩＤとポリシー番号と優先度を対応づけたソケット−ポリシー対応テーブルをポリシーテーブル記憶部１４に記憶する。ポリシー番号はソケットのデータ構造の一部に設定されており、アプリケーションはsetsockopt()のようなソケットのパラメータを設定する関数によってソケットのポリシー番号を設定したり、getsockopt()のようなソケットのパラメータを取得する関数によってソケットのポリシー番号を取得することができる。
【００１８】
図２（ａ）、（ｂ）は、ポリシーテーブル記憶部１４に記憶されるテーブルを説明する図である。
【００１９】
図２（ａ）は、ソケット−ポリシー対応テーブルを示す。ソケット−ポリシー対応テーブルには、ソケット生成部１０によって生成されたソケットのＩＤと、ポリシー番号・優先度設定部１２によって設定された、当該ソケットに適用されるポリシーの番号および優先度とが対応づけられて格納される。この例では、ソケットＩＤ“３”、ソケットＩＤ“８”、およびソケットＩＤ“１５”にはポリシー番号“０”、ソケットＩＤ“１０”にはポリシー番号“２”、ソケットＩＤ“１１”にはポリシー番号“３”がそれぞれ設定されている。ソケットＩＤ“３”の通信はＵＤＰであり、それ以外のソケットＩＤの通信はＴＣＰである。
【００２０】
さらに、ソケットＩＤ“３”、“８”、“１０”、“１１”、“１５”には優先度“３１”、“３”、“１０”、“１２”、“２”がそれぞれ設定されている。優先度は、一例として、１から３１の値を取り、値が小さい方が優先度が高い。
【００２１】
ソケットＩＤはＭ個存在し、ポリシー番号は０〜Ｎまでの値を取る。一般に生成可能なソケットの最大数よりも、設定可能なポリシーの最大数の方が小さいため、ソケットＩＤとポリシー番号の対応は多対１になる。このようにソケットＩＤとポリシー番号を対応づけることにより、適用されるポリシーによってソケット通信をグループ化することができる。
【００２２】
図２（ａ）の例では、ソケットＩＤ“３”、“８”、“１５”の３つが同一のポリシー番号０に対応づけられており、これらのソケットＩＤで特定される３つのソケット通信は、一つのポリシーグループに属することになる。
【００２３】
たとえば、ポリシー番号“０”はシステムの通信、ポリシー番号“２”はゲームの通信のように区別すると、ポリシー番号“０”に属するソケット通信と、ポリシー番号“２”に属するソケット通信とを区別して、別個のポリシーのもとで通信を制御することができる。
【００２４】
図２（ｂ）は、ポリシー定義テーブルを示す。ポリシー定義テーブルには、ポリシー番号に対応づけて、制限帯域、ポリシーパターン、ポリシーフラグなどのポリシーのパラメータが格納される。
【００２５】
図２（ｂ）に示すように、ポリシー定義テーブルには、ポリシー番号に対応づけて上限帯域（Ｍｂｐｓ）および下限帯域（Ｍｂｐｓ）が格納される。送信側と受信側で制限帯域を区別する場合は、送信上限帯域、送信下限帯域、受信上限帯域、および受信下限帯域が設定される。
【００２６】
図２（ｂ）の例では、ポリシー番号“０”には上限帯域５０Ｍｂｐｓおよび下限帯域４０Ｍｂｐｓが設定され、ポリシー番号“１”には上限帯域５０Ｍｂｐｓおよび下限帯域１０Ｍｂｐｓが設定され、ポリシー番号“２”には上限帯域４０Ｍｂｐｓおよび下限帯域１０Ｍｂｐｓが設定され、ポリシー番号“３”には上限帯域２０Ｍｂｐｓおよび下限帯域１０Ｍｂｐｓが設定される。
【００２７】
このようにソケット毎に優先度と要求するネットワーク帯域を設定することができる。優先度の高いソケットから指定された帯域を消費するよう動作する。同一優先度のソケットが複数ある場合は、帯域使用は同一優先度のソケット間で均等に消費される。指定するネットワーク帯域には上限と下限がある。上限ネットワーク帯域は、「このソケットにはこれだけ割り当てられれば十分」、「これを超える分については他のソケットに融通してもよい」という要求を示す。下限ネットワーク帯域は、「このソケットには（優先度や実際の帯域にもよるが）最低限これだけは割り当ててほしい」という要求を示す。ただし、通信が発生していないソケットについてはその時点では下限ネットワーク帯域をゼロとして扱う。上限ネットワーク帯域は下限ネットワーク帯域を下回ることはないように設定されるが、下限ネットワーク帯域と同じ値を設定することはできる。
【００２８】
本実施の形態では、上限ネットワーク帯域と下限ネットワーク帯域では、実際に使用する帯域がこれを上回るような場合の動作が異なる。たとえば、上限ネットワーク帯域が５Ｍｂｐｓ、下限ネットワーク帯域が２Ｍｂｐｓに設定された通信において、実際に当該通信が使用している帯域が３Ｍｂｐｓであったとする。このような場合、使用帯域は上限ネットワーク帯域の５Ｍｂｐｓを下回り、下限ネットワーク帯域の２Ｍｂｐｓを上回るため、当該通信の帯域制御は行われない。このため、上限ネットワーク帯域に満たない余りの帯域分２Ｍｂｐｓは、他の通信に自然に譲られ、通信が平均化する。一方、当該通信が使用している帯域が上限ネットワーク帯域の５Ｍｂｐｓを上回りそうなとき、当該通信の帯域制御が行われ、優先度の低いソケットに積極的に帯域が融通される。さらに、実際に当該通信が使用している帯域が１Ｍｂｐｓであったとする。このとき使用帯域は下限ネットワーク帯域の２Ｍｂｐｓを下回り、下限ネットワーク帯域まで１Ｍｂｐｓが余っているが、この余った帯域分は優先度の低いソケットに融通されることはない。下限ネットワーク帯域は当該通信に対して最低限確保されていなければならないからである。
【００２９】
本実施の形態では、優先度と下限ネットワーク帯域を用いて帯域制御を行う。上限ネットワーク帯域については、ソケットの通信量がその上限値に達すれば帯域制御されるが、そうでない限りは帯域制御されることはない。
【００３０】
ネットワーク帯域を指定するには、ｂｐｓまたは全体の使用可能帯域からの割合（パーセンテージ）のどちらかを用いる。
【００３１】
ポリシー定義テーブルには、これ以外にポリシー番号に対応づけてポリシーパターンやポリシーフラグが設定されてもよい。
【００３２】
ポリシーパターンは、当該ポリシーをアクティブ（ＯＮ）とするか、非アクティブ（ＯＦＦ）とするかを指定するパラメータである。ポリシーがアクティブの場合、当該ポリシーが適用されるソケット通信のグループに対して、後述の帯域制御が適用される。ポリシーが非アクティブの場合、当該ポリシーが適用されるソケット通信のグループに対して、後述の帯域制御は適用されない。
【００３３】
ポリシーフラグは、当該ポリシーが適用されるソケットのタイプを指定するパラメータである。たとえば、ポリシーフラグがＴＣＰを示す値の場合、ＴＣＰで生成されたソケットに対して当該ポリシーが適用される。ポリシーフラグがＵＤＰを示す値の場合、ＵＤＰで生成されたソケットに対して当該ポリシーが適用される。
【００３４】
図１に戻る。送信バッファ２０ａ、ポリシー番号・優先度取得部２２ａ、ポリシー適用部２４ａ、帯域制御部２６ａ、およびパケット送信部２８ａは、アプリケーションがソケットを用いてデータを送信するときに用いられる構成である。一方、受信バッファ２０ｂ、ポリシー番号・優先度取得部２２ｂ、ポリシー適用部２４ｂ、帯域制御部２６ｂは、アプリケーションがソケットを用いてデータを受信するときに用いられる構成である。これらの構成は、ソケット通信のためのプロトコルスタックに実装される。
【００３５】
まず、ソケットでデータを送信する場合の構成を説明する。送信バッファ２０ａにはアプリケーションがソケット通信で送信するデータがバッファされる。ポリシー番号・優先度取得部２２ａは、ポリシーテーブル記憶部１４に記憶されたソケット−ポリシー対応テーブルを参照し、アプリケーションが使用するソケットのＩＤに対応づけられたポリシー番号および優先度を取得する。ポリシー番号・優先度取得部２２ａは、取得したポリシー番号および優先度をポリシー適用部２４ａに与える。
【００３６】
ポリシー適用部２４ａは、ポリシーテーブル記憶部１４に記憶されたポリシー定義テーブルを参照して、ポリシー番号に属するソケット通信のグループに対してポリシーを適用するかどうかを決める。ポリシー定義テーブルにおいて、ポリシーパターンが非アクティブ（ＯＦＦ）であれば、当該ポリシーはソケット通信に適用されない。ポリシーパターンがアクティブ（ＯＮ）であっても、ポリシー番号に属するソケット通信の内、ポリシーフラグが指定するソケットのタイプを使っていないソケット通信にはポリシーは適用されない。ポリシー適用部２４ａは、ソケット通信に対するポリシーの適用の有無とポリシー番号に対応する制限帯域と優先度を帯域制御部２６ａに通知する。
【００３７】
帯域制御部２６ａは、ソケット通信にポリシーが適用される場合に、ポリシー番号に対応する制限帯域と優先度にもとづいてソケット通信に帯域制御を適用する。帯域制御により、送信されるべきパケットは遅延する。
【００３８】
帯域制御部２６ａは、ポリシーが適用されるソケット通信に対して帯域制御を適用した結果のパケットをパケット送信部２８ａに供給する。パケット送信部２８ａはパケットをデバイスドライバ３０に与える。デバイスドライバ３０はパケットをネットワークに送信する。
【００３９】
次に、ソケットでデータを受信する場合の構成を説明する。デバイスドライバ３０はネットワークからパケットを受信し、パケット受信部２８ｂに供給する。パケット受信部２８ｂは、デバイスドライバ３０からパケットを受け取る。この際、パケットがどのソケット宛であるかを、パケットの送信先アドレスやポート番号から判定する。
【００４０】
ポリシー番号・優先度取得部２２ｂは、ポリシーテーブル記憶部１４に記憶されたソケット−ポリシー対応テーブルを参照し、当該通信で使用されているソケットのＩＤに対応づけられたポリシー番号および優先度を取得し、ポリシー適用部２４ａに通知する。
【００４１】
ポリシー適用部２４ｂは、ポリシーテーブル記憶部１４に記憶されたポリシー定義テーブルを参照して、ポリシー番号に属するソケット通信のグループに対してポリシーを適用するかどうかを決める。送信の場合と同様である。
【００４２】
帯域制御部２６ｂは、ポリシー番号に対応する制限帯域と優先度にもとづいて、ポリシーの適用を受けるソケット通信に帯域制御を適用する。帯域制御により、受信されたパケットは破棄される。
【００４３】
帯域制御部２６ｂによって帯域制御の適用を受けたパケットは受信バッファ２０ｂにバッファされる。アプリケーションは受信バッファ２０ｂからデータを読み出す。
【００４４】
図３は、ソケットＩＤ毎に設定されるポリシー番号および優先度と、ポリシー定義テーブルとの関係を説明する図である。
【００４５】
ソケットＩＤ“５”にはポリシー番号“１”と優先度“３”が対応づけられ、ソケットＩＤ“６”にはポリシー番号“２”と優先度“３”が対応づけられている。ソケットＩＤ“５”および“６”のネットワークインタフェースは有線ＬＡＮインタフェースｅｔｈ０であり、ｅｔｈ０には送信最大帯域推定値、受信最大帯域推定値が対応づけられている。ネットワークインタフェースにはこれ以外に無線ＬＡＮインタフェースｗｌａｎ０などがある。
【００４６】
ポリシー定義テーブルは、ポリシー番号０〜１５に対応づけて送信上限帯域、送信下限帯域、受信上限帯域、および受信下限帯域を格納したテーブルであり、ポリシー番号０に対しては送信上限帯域０（制限なし）、送信下限帯域０（制限なし）、受信上限帯域５０Ｍｂｐｓ、および受信下限帯域４０Ｍｂｐｓが格納されている。
【００４７】
ソケットＩＤ“５”で識別されるソケット通信は、ポリシー番号“１”のポリシーテーブルに格納された制限帯域のもとで帯域制御され、ソケットＩＤ“６”で識別されるソケット通信は、ポリシー番号“２”のポリシーテーブルに格納された制限帯域のもとで帯域制御される。
【００４８】
各ソケットは任意のポリシー番号のポリシーテーブルを選択できる。ソケットＡとソケットＢがともに同じポリシー番号のポリシーテーブルを選択してもよい。たとえば、ソケットＡとソケットＢがともにポリシー番号“１”のポリシーテーブルを選択し、ポリシー番号“１”のポリシーテーブルには下限帯域３Ｍｂｐｓが設定されていたとする。このとき、ソケットＡ、ソケットＢをそれぞれ下限帯域３Ｍｂｐｓのもとで帯域制御してもよい。この場合は、ソケットＡ、ソケットＢがそれぞれ３Ｍｂｐｓの帯域を使い、合計で６Ｍｂｐｓの帯域を使うことになる。あるいは別の実装例として、同じポリシー番号が設定されたソケットＡとソケットＢの間で帯域を共有してもよい。この場合は、ソケットＡとソケットＢが合計で３Ｍｂｐｓの帯域を使うことになり、３Ｍｂｐｓの帯域が二つのソケットの間で共有される。
【００４９】
図４は、本実施の形態の帯域判定処理を説明するフローチャートである。これは、送信側では帯域制御部２６ａが、受信側では帯域制御部２６ｂが行う判定処理である。
【００５０】
ソケットＩＤで識別されるソケットの一つを注目ソケットとして選択する（Ｓ１０）。
【００５１】
各優先度ｎに対して要求される下限ネットワーク帯域lower_bps[n]を算出する（Ｓ１２）。優先度ｎに対して２つ以上のソケットがある場合、優先度ｎの各ソケットが要求する下限ネットワーク帯域の合計を優先度ｎに対して要求される下限ネットワーク帯域lower_bps[n]とする。ただし、通信が発生していないソケットについては要求される下限ネットワーク帯域を０とする。
【００５２】
各優先度ｎに対する現在の消費帯域current_bps[n]を算出する（Ｓ１４）。この場合も、優先度ｎに対して２つ以上のソケットがある場合、優先度ｎの各ソケットの現在の消費帯域の合計を優先度ｎに対する現在の消費帯域current_bps[n]とする。ここで、注目ソケットのみの消費帯域ではなく、注目ソケットと同一優先度の他のソケットの消費帯域も合計することでソケットに対する優先度制御が有効に働くことに留意する。
【００５３】
注目ソケットの優先度ｍより高い優先度に対して、下限ネットワーク帯域lower_bpsと現在の消費帯域current_bpsを算出する（Ｓ１６）。これは以下の計算式により算出できる。
lower_bps = Σlower_bps[n(<m)]
current_bps = Σcurrent_bps[n(<m)]
ここでΣはｍよりも小さいｎについて和を取る。
【００５４】
注目ソケットの優先度ｍに対する現在の消費帯域current_priority_bpsを算出する（Ｓ１８）。これは次式により得られる。
current_priority_bps = current_bps[m]
【００５５】
ソケット通信で使用されるネットワークインタフェースの最大帯域推定値estimated_bpsを補正する（Ｓ２０）。
【００５６】
ここで、最大帯域推定値を求める方法として、実際の送受信量で算出する方法を用いる。これは、実際の送受信データ量をもとに最大帯域を測定する点、特開２０１１−２５４４３３号公報に記載の最大スループット推定方法など一般的に知られているスループット推定に関する技術とは異なるものである。本実施の形態の最大帯域推定方法では、実際の送受信量が増加傾向にあるときはその値も加味して最大帯域を推定する。たとえば、増加傾向を現在の最大帯域に乗算した値を推定値とする。また、いったん最大値が求まった後も推定値の調整処理が入り、ピーク値が常に最大帯域推定値になることが避けられる。たとえば、異なる回線につなぎかえる場合は改めて最大帯域の推定を始める。また、使用中に最大帯域が変動することが考えられるので、そこで、最大帯域推定値の補正を行い、動的に推定値を更新することが望ましい。
【００５７】
最大帯域推定値estimated_bpsの補正は、以下のように行う。実際の送受信帯域が増加傾向にあるかどうかを調べ、増加傾向であれば最大帯域推定値estimated_bpsは無限大と解釈する。その結果、帯域制御の適用が遅延される。実際の送信／受信帯域が安定して計算できる状態になった場合、下記の計算を適用する。
offset = lower_bps - current_bps
このオフセット値offsetは、要求している下限ネットワーク帯域lower_bpsに対して、現在の消費帯域current_bpsが達していない程度を示している。オフセット値offsetが０以上であれば、実際の送信／受信最大帯域が送受信端末とは別のところで動的に変わっていることも含め、推定帯域が実際の最大帯域と離れている可能性があると推測する。そして、そのパケットに対して一時的に最大帯域推定値estimated_bps＝現在の最大帯域−offsetとすることにより、送信側／受信側それぞれで最大帯域推定値を補正する。
【００５８】
次に、必要帯域neededを計算する（Ｓ２２）。必要帯域neededは、注目ソケットの優先度ｍより高い優先度に対する下限ネットワーク帯域lower_bpsと、注目ソケットの優先度ｍに対する現在の消費帯域current_priority_bpsの和として、以下の計算式により算出される。
needed = lower_bps + current_priority_bps
【００５９】
最大帯域推定値と必要帯域を比較して不足帯域shortageを計算する（Ｓ２４）。不足帯域shortageは、必要帯域neededと最大帯域推定値estimated_bpsの差として、以下の計算式により算出される。
shortage = needed - estimated_bps
【００６０】
不足帯域shortageが正であるかどうか、すなわち帯域が不足しているかどうかを調べる（Ｓ２６）。不足帯域shortage＞０である場合（Ｓ２６のＹ）、帯域不足であると判定する（Ｓ２８）。帯域不足であると判定した後、ステップＳ１０に戻る。
【００６１】
不足帯域shortage≦０である場合（Ｓ２６のＮ）、帯域不足であると判定することなく、ステップＳ１０に戻る。
【００６２】
ステップ１０において、次の処理すべき注目ソケットがあれば（Ｓ１０のＹ）、その注目ソケットに対して、ステップＳ１２以降の処理を行い、すべてのソケットの処理が終了すれば（Ｓ１０のＮ）、各ソケットに対する一通りの帯域判定を終了する。
【００６３】
上記の説明では、注目ソケットの優先度ｍより高い優先度に対する下限ネットワーク帯域lower_bpsを、優先度ｎ（＜ｍ）に対して要求される下限ネットワーク帯域lower_bps[n]を加算することにより計算したが、lower_bpsの計算方法にはバリエーションがあり、ここでは２つの変形例を説明する。
【００６４】
（lower_bpsの計算方法のバリエーション１）
注目ソケットの優先度ｍより高い優先度に対する下限ネットワーク帯域lower_bpsを求める際、優先度ｎ（＜ｍ）に対して要求される下限ネットワーク帯域lower_bps[n]を常に加算するのではなく、代わりに現状の通信量を加味し、ｍｉｎ（現在の通信量×２、指定された下限ネットワーク帯域lower_bps[n]）を加算する。ここで、ｍｉｎはどちらか小さい方の値を取る演算である。たとえば、ソケットＡの優先度が１６で下限帯域が１Ｇｂｐｓであり、ソケットＢの優先度が２０であるとする。ソケットＢが大きな帯域を使って通信中にソケットＡにほんの少しの量の通信が発生したとき、このlower_bpsの計算方法であれば、ソケットＢの通信を完全に停止することを避けることができる。
【００６５】
（lower_bpsの計算方法のバリエーション２）
前述のlower_bpsの計算方法のバリエーション１において、注目ソケットの優先度ｍよりも低い優先度のソケットの全体の通信量を考慮に入れる。バリエーション１では、注目ソケットの優先度ｍより高い優先度に対する下限ネットワーク帯域lower_bpsを求める際、優先度ｎ（＜ｍ）に対して、ｍｉｎ（現在の通信量×２、lower_bps[n]）を加算したが、注目ソケットの優先度ｍよりも低い優先度のソケットの全体の通信量がネットワーク帯域の所定の使用率、たとえば９０％を超えた場合は、ｍｉｎ（現在の通信量×２、lower_bps[n]）を加算するのではなく、指定された下限ネットワーク帯域lower_bps[n]を常に加算する。これにより、下限ネットワーク帯域が指定されず、優先度だけが指定されたソケットにも帯域制御を適用することができる。
【００６６】
図５（ａ）は、通信処理装置１００による受信側の帯域制御を説明するフローチャートであり、図５（ｂ）は、通信処理装置１００による送信側の帯域制御を説明するフローチャートである。
【００６７】
図５（ａ）を参照して、受信時の帯域制御を説明する。パケット受信部２８ｂはネットワークからパケットを受信する（Ｓ３０）。受信されたパケットは各プロトコルレイヤでプロトコル処理される（Ｓ３２）。帯域制御部２６ｂは、各ソケットに設定された制限帯域と優先度のもとで帯域が不足しているかどうかを判定する（Ｓ３４）。この帯域判定処理の詳細は、図４で説明した通りである。
【００６８】
ステップＳ３４の帯域判定処理の結果、帯域が不足していると判定された場合（Ｓ３６のＹ）、受信されたパケットは破棄される（Ｓ４０）。帯域が不足していると判定されなかった場合（Ｓ３６のＮ）、受信されたパケットのデータは上位ソケットに格納される（Ｓ３８）。ステップＳ３０に戻り、次のパケットを受信し、以降の受信側の帯域制御を繰り返す。
【００６９】
パケットを受信後、デバイスレイヤではどのソケットのパケットか判別できないため、各プロトコルレイヤのプロトコル処理を継続することで、どのソケットのパケットかを判断する。各ソケットの現在の通信速度がわかっているので、帯域判定で帯域を超えればパケットを破棄するという判断ができる。このとき、パケットを破棄することでＴＣＰではフロー制御されるので、結果的に、そのソケットの帯域が自動的に絞られることになる。ＵＤＰでもパケットが破棄されると、送信側は送信速度を調整することになる。受信パケットを破棄する代わりに遅延させることも可能だが、実装上は破棄する方が簡単である。
【００７０】
図５（ｂ）を参照して、送信時の帯域制御を説明する。ソケットを使って送信されたデータは各プロトコルレイヤでプロトコル処理される（Ｓ５０）。パケット送信部２８ａはプロトコル処理されたデータをもとに送信すべきパケットを生成する（Ｓ５２）。帯域制御部２６ａは、各ソケットに設定された制限帯域と優先度のもとで帯域が不足しているかどうかを判定する（Ｓ５４）。この帯域判定処理の詳細は、図４で説明した通りである。
【００７１】
ステップＳ５４の帯域判定処理の結果、帯域が不足していると判定された場合（Ｓ５６のＹ）、送信すべきパケットは遅延される（Ｓ６０）。なお、遅延させたパケットを記憶するメモリが足りなくなった場合は、パケットを破棄する。帯域が不足していると判定されなかった場合（Ｓ５６のＮ）、送信すべきパケットは物理デバイスに送信される（Ｓ５８）。ステップＳ５０に戻り、次の送信パケットのプロトコル処理を行い、以降の送信側の帯域制御を繰り返す。
【００７２】
このように、送信側では、帯域不足と判定された場合、帯域制御部２６ａはパケットの送信を遅延させることで帯域制御を行う。受信側では、帯域不足と判定された場合、帯域制御部２６ｂは受信されたパケットを破棄することで帯域制御を行う。この帯域判定は各パケットごとに行われる。
【００７３】
本実施の形態の帯域制御によれば、帯域制御されたソケットに対して課された帯域制御値すなわち仮想ネットワーク帯域を上位層にあるアプリケーションに知らせることができる。これにより、アプリケーションに帯域配分のヒントを提供することができる。たとえば、アプリケーションとしては６０Ｍｂｐｓで通信していると想定していたが、実際にはソケットが２０Ｍｂｐｓに制限されているとわかった場合、アプリケーションはビデオのレートを落とすなどして、帯域不足分を調整することができる。
【００７４】
要求帯域を最大帯域に対する割合（パーセンテージ）で指定する場合、対象のネットワークインターフェースの最大帯域がわからなければ、帯域の制限値を求めることができない。しかし、通信の初期段階で最大帯域を測定できない状態では、指定された割合（パーセンテージ）がどれくらいの帯域に相当するかわからず、帯域制御アルゴリズムが適切に動作しない。そこで、本実施の形態では、実際の送受信帯域が増加傾向にあるかどうかを調べ、増加傾向であれば、帯域制御を遅延させる。このようにして、通信の初期段階では指定された割合（パーセンテージ）による帯域制御を行わないようにすることで問題を回避する。なお、最大帯域やソケットの通信帯域は実際に通信するネットワークインターフェース（物理デバイス）ごとにもってもよい。
【００７５】
以降、図６〜図１１を参照して、具体的な例を用いて、本実施の形態の帯域制御を説明する。これらの例では、制限帯域がＭｂｐｓで指定された場合を示すが、最大帯域推定値に対する割合で制限帯域が指定された場合も同様の帯域制御が適用可能である。これらの図において、ソケットを○で示し、○の下に、実際の帯域（Ｍｂｐｓ）／指定された下限帯域（Ｍｂｐｓ）／指定された上限帯域（Ｍｂｐｓ）の形式で、各ソケットの実際の帯域と制限帯域を示す。以下の例では、最大帯域推定値は６０Ｍｂｐｓであるとする。
【００７６】
図６（ａ）および図６（ｂ）において、ソケットＡおよびソケットＢの優先度は３１で、ソケットＣの優先度は３である。図６（ａ）の状態では、ソケットＡの実際の帯域と制限帯域は６０／０／０であり、ソケットＢの実際の帯域と制限帯域は０／０／０であり、ソケットＣの実際の帯域と制限帯域は０／４０／５０である。この状態でソケットＣが通信を開始したとする。
【００７７】
図６（ａ）において、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは０Ｍｂｐｓであり（通信が発生していないソケットＣについては下限ネットワーク帯域は０とされる）、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは６０Ｍｂｐｓであるから、必要帯域neededは０Ｍｂｐｓ＋６０Ｍｂｐｓ＝６０Ｍｂｐｓである。不足帯域shortageは６０Ｍｂｐｓ−６０Ｍｂｐｓ＝０Ｍｂｐｓであり、この時点では帯域は足りていると判定される。
【００７８】
ソケットＣの実際の帯域が１Ｍｂｐｓになると、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは４０Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは６０Ｍｂｐｓであるから、必要帯域neededは４０Ｍｂｐｓ＋６０Ｍｂｐｓ＝１００Ｍｂｐｓである。不足帯域shortageは１００Ｍｂｐｓ−６０Ｍｂｐｓ＝−４０Ｍｂｐｓであり、帯域不足と判定される。帯域不足のため、ソケットＡは帯域制御を受ける。その結果、図６（ｂ）に示すように、ソケットＡの実際の帯域は徐々に減少し、２０Ｍｂｐｓになる一方、ソケットＣの実際の帯域は徐々に増加し、４０Ｍｂｐｓにまで達する。
【００７９】
ソケットＡの実際の帯域が２０Ｍｂｐｓに達した時点で注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは４０Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは２０Ｍｂｐｓであるから、必要帯域neededは４０Ｍｂｐｓ＋２０Ｍｂｐｓ＝６０Ｍｂｐｓになる。不足帯域shortageは６０Ｍｂｐｓ−６０Ｍｂｐｓ＝０Ｍｂｐｓであるから、帯域不足は解消され、これ以降は、ソケットＡは帯域制御を受けない。これ以降、ソケットＣの実際の帯域が４０Ｍｂｐｓを超えることがあっても、ソケットＡは帯域制御を受けないことから、通信の平均化により、ソケットＣの通信量が自然に下がり、ソケットＣの実際の帯域は４０Ｍｂｐｓに収束する。
【００８０】
このように帯域制御と通信の平均化の結果、図６（ａ）の状態から図６（ｂ）の状態に遷移する。すなわち、ソケットＣの実際の帯域が指定された下限帯域の４０Ｍｂｐｓにまで達し、その分、ソケットＡの実際の帯域は６０Ｍｂｐｓから２０Ｍｂｐｓにまで減少することで安定する。
【００８１】
図７（ａ）および図７（ｂ）において、ソケットＡおよびソケットＢの優先度は３１で、ソケットＣの優先度は３である。図７（ａ）の状態では、ソケットＡの実際の帯域と制限帯域は３０／０／０であり、ソケットＢの実際の帯域と制限帯域は３０／０／０であり、ソケットＣの実際の帯域と制限帯域は０／４０／５０である。この状態でソケットＣが通信を開始したとする。
【００８２】
図７（ａ）において、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは０Ｍｂｐｓであり（通信が発生していないソケットＣについては下限ネットワーク帯域は０とされる）、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは３０Ｍｂｐｓ＋３０Ｍｂｐｓ＝６０Ｍｂｐｓであるから、必要帯域neededは０Ｍｂｐｓ＋６０Ｍｂｐｓ＝６０Ｍｂｐｓである。不足帯域shortageは６０Ｍｂｐｓ−６０Ｍｂｐｓ＝０Ｍｂｐｓであり、この時点では帯域は足りていると判定される。
【００８３】
ソケットＣの実際の帯域が１Ｍｂｐｓになると、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは４０Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは３０Ｍｂｐｓ＋３０Ｍｂｐｓ＝６０Ｍｂｐｓであるから、必要帯域neededは４０Ｍｂｐｓ＋６０Ｍｂｐｓ＝１００Ｍｂｐｓである。不足帯域shortageは１００Ｍｂｐｓ−６０Ｍｂｐｓ＝４０Ｍｂｐｓであり、帯域不足と判定される。帯域不足のため、同じ優先度３１のソケットＡおよびソケットＢは平等に帯域制御を受ける。その結果、図７（ｂ）に示すように、ソケットＡおよびソケットＢの実際の帯域は徐々に減少し、それぞれ１０Ｍｂｐｓになる一方、ソケットＣの実際の帯域は徐々に増加し、４０Ｍｂｐｓにまで達する。
【００８４】
ソケットＡおよびソケットＢの実際の帯域がそれぞれ１０Ｍｂｐｓに達した時点で注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは４０Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは１０Ｍｂｐｓ＋１０Ｍｂｐｓ＝２０Ｍｂｐｓであるから、必要帯域neededは４０Ｍｂｐｓ＋２０Ｍｂｐｓ＝６０Ｍｂｐｓになる。不足帯域shortageは６０Ｍｂｐｓ−６０Ｍｂｐｓ＝０Ｍｂｐｓであるから、帯域不足は解消され、これ以降は、ソケットＡおよびソケットＢは帯域制御を受けない。これ以降、ソケットＣの実際の帯域が４０Ｍｂｐｓを超えることがあっても、ソケットＡおよびソケットＢは帯域制御を受けないことから、通信の平均化により、ソケットＣの通信量が自然に下がり、ソケットＣの実際の帯域は４０Ｍｂｐｓに収束する。
【００８５】
このように帯域制御と通信の平均化の結果、図７（ａ）の状態から図７（ｂ）の状態に遷移する。すなわち、ソケットＣの実際の帯域が指定された下限帯域の４０Ｍｂｐｓにまで達し、その分、ソケットＡおよびソケットＢの実際の帯域はそれぞれ３０Ｍｂｐｓから１０Ｍｂｐｓにまで減少することで安定する。
【００８６】
図８（ａ）および図８（ｂ）において、ソケットＡおよびソケットＢの優先度は３１で、ソケットＣの優先度は３である。図８（ａ）の状態では、ソケットＡの実際の帯域と制限帯域は０／０／０であり、ソケットＢの実際の帯域と制限帯域は０／０／０であり、ソケットＣの実際の帯域と制限帯域は５０／４０／５０である。この状態でソケットＡが通信を開始したとする。ソケットＡおよびソケットＣはともに帯域を使えるだけ使う通信を行うとする。
【００８７】
図８（ａ）において、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは４０Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは０Ｍｂｐｓであるから、必要帯域neededは４０Ｍｂｐｓ＋０Ｍｂｐｓ＝４０Ｍｂｐｓである。不足帯域shortageは４０Ｍｂｐｓ−６０Ｍｂｐｓ＝−２０Ｍｂｐｓであり、帯域は足りていると判定される。帯域が足りているため、ソケットＡは帯域制御を受けない。その結果、図８（ｂ）に示すように、ソケットＡの実際の帯域は徐々に増加し、１０Ｍｂｐｓに達する一方、ソケットＣも帯域制御を受けないため、ソケットＣの実際の帯域は上限帯域の５０Ｍｂｐｓのまま維持される。
【００８８】
図８（ｂ）の状態からさらにソケットＡが通信量を増やした場合の状態遷移を図９（ａ）および図９（ｂ）に示す。図９（ａ）は図８（ｂ）と同じ状態である。
【００８９】
図９（ａ）において、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは４０Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは１０Ｍｂｐｓ＋０Ｍｂｐｓ＝１０Ｍｂｐｓであるから、必要帯域neededは４０Ｍｂｐｓ＋１０Ｍｂｐｓ＝５０Ｍｂｐｓである。不足帯域shortageは５０Ｍｂｐｓ−６０Ｍｂｐｓ＝−１０Ｍｂｐｓであり、帯域は足りていると判定される。帯域が足りているため、ソケットＡは帯域制御を受けない。その結果、図９（ｂ）に示すように、ソケットＡの実際の帯域は１０Ｍｂｐｓから１１Ｍｂｐｓ、１２Ｍｂｐｓ、…と徐々に増加し、２０Ｍｂｐｓに達する一方、ソケットＣも帯域制御を受けないが、通信の平均化により、ソケットＣの実際の帯域は、５０Ｍｂｐｓから４９Ｍｂｐｓ、４８Ｍｂｐｓ、…と徐々に減少し、下限帯域の４０Ｍｂｐｓに達する。これは帯域制御によるものではなく、通信の平均化によるものであることに留意する。
【００９０】
ソケットＡの実際の帯域が２０Ｍｂｐｓに達した時点で注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは４０Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは２０Ｍｂｐｓ＋０Ｍｂｐｓ＝２０Ｍｂｐｓであるから、必要帯域neededは４０Ｍｂｐｓ＋２０Ｍｂｐｓ＝６０Ｍｂｐｓになる。不足帯域shortageは６０Ｍｂｐｓ−６０Ｍｂｐｓ＝０Ｍｂｐｓであるから、帯域はちょうど足りた状態になる。これ以降、ソケットＡの実際の帯域が２０Ｍｂｐｓを超えると、不足帯域shortageが正になり、ソケットＡは帯域制御を受けるため、ソケットＡの実際の帯域は２０Ｍｂｐｓに収束する。また、ソケットＣも４０Ｍｂｐｓを下回ることがない。ソケットＣが４０Ｍｂｐｓから下がる方向に進もうとすると、ソケットＣより低い優先度のソケットから見ると、優先度の高いソケットＣの帯域がlower_bpsを満たしていないと判断し、帯域を空けようとする帯域制御の動作に入るため、ソケットＣの通信量は下がらなくなる。
【００９１】
このように通信の平均化と帯域制御の結果、図９（ａ）の状態から図９（ｂ）の状態に遷移し、図９（ｂ）の状態で安定する。すなわち、ソケットＣの実際の帯域が５０Ｍｂｐｓから指定された下限帯域の４０Ｍｂｐｓにまで減少し、その分、ソケットＡの実際の帯域は１０Ｍｂｐｓから２０Ｍｂｐｓにまで増加することで安定する。仮に、ソケットＡとソケットＣが同一の優先度であるなど帯域制御が働かない状態や、帯域制御の仕組みが実装されていないシステムの場合は、ソケットＡおよびソケットＣの通信は平均化されどちらも３０Ｍｂｐｓ程度になることと比較すれば、本実施の形態の帯域制御の効果は明確である。なお、ここで、「通信の平均化」とはソフトウェアの実装上、平均的に処理が割り当てられることや、物理的な帯域に通信速度が律せられることであり、特に何も制御しなくても通信帯域が平均的に振り分けられることを指す。
【００９２】
図１０（ａ）および図１０（ｂ）において、ソケットＡの優先度は３１で、ソケットＢの優先度は３で、ソケットＣの優先度は２である。図１０（ａ）の状態では、ソケットＡの実際の帯域と制限帯域は２０／０／０であり、ソケットＢの実際の帯域と制限帯域は４０／４０／５０であり、ソケットＣの実際の帯域と制限帯域は０／１０／４０である。この状態でソケットＡ、ソケットＢ、ソケットＣがそれぞれ帯域を使えるだけ使う通信を行ったとする。
【００９３】
図１０（ａ）において、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは０Ｍｂｐｓ＋４０Ｍｂｐｓ＝４０Ｍｂｐｓであり（通信が発生していないソケットＣについては下限ネットワーク帯域は０とされる）、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは２０Ｍｂｐｓであるから、必要帯域neededは４０Ｍｂｐｓ＋２０Ｍｂｐｓ＝６０Ｍｂｐｓである。不足帯域shortageは６０Ｍｂｐｓ−６０Ｍｂｐｓ＝０Ｍｂｐｓであり、帯域は足りていると判定される。
【００９４】
注目ソケットＢの優先度３よりも高い優先度に対する下限ネットワーク帯域lower_bpsは０Ｍｂｐｓであり、注目ソケットＢの優先度３に対する現在の消費帯域current_priority_bpsは４０Ｍｂｐｓであるから、必要帯域neededは０Ｍｂｐｓ＋４０Ｍｂｐｓ＝４０Ｍｂｐｓである。不足帯域shortageは４０Ｍｂｐｓ−６０Ｍｂｐｓ＝−２０Ｍｂｐｓであり、帯域は足りていると判定される。
【００９５】
注目ソケットＣの優先度２よりも高い優先度に対する下限ネットワーク帯域lower_bpsは０Ｍｂｐｓであり、注目ソケットＣの優先度２に対する現在の消費帯域current_priority_bpsは０Ｍｂｐｓであるから、必要帯域neededは０Ｍｂｐｓ＋０Ｍｂｐｓ＝０Ｍｂｐｓである。不足帯域shortageは０Ｍｂｐｓ−６０Ｍｂｐｓ＝−６０Ｍｂｐｓであり、帯域は足りていると判定される。
【００９６】
この状態からソケットＣが１Ｍｂｐｓの通信を行ったとする。このとき、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは１０Ｍｂｐｓ＋４０Ｍｂｐｓ＝５０Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは２０Ｍｂｐｓであるから、必要帯域neededは５０Ｍｂｐｓ＋２０Ｍｂｐｓ＝７０Ｍｂｐｓである。不足帯域shortageは７０Ｍｂｐｓ−６０Ｍｂｐｓ＝１０Ｍｂｐｓであり、帯域不足と判定される。帯域不足のため、ソケットＡは帯域制御を受け、ソケットＡの実際の帯域は減少し始める。
【００９７】
注目ソケットＢの優先度３よりも高い優先度に対する下限ネットワーク帯域lower_bpsは１０Ｍｂｐｓであり、注目ソケットＢの優先度３に対する現在の消費帯域current_priority_bpsは４０Ｍｂｐｓであるから、必要帯域neededは１０Ｍｂｐｓ＋４０Ｍｂｐｓ＝５０Ｍｂｐｓである。不足帯域shortageは５０Ｍｂｐｓ−６０Ｍｂｐｓ＝−１０Ｍｂｐｓであり、帯域は足りていると判定される。
【００９８】
注目ソケットＣの優先度２よりも高い優先度に対する下限ネットワーク帯域lower_bpsは０Ｍｂｐｓであり、注目ソケットＣの優先度２に対する現在の消費帯域current_priority_bpsは１Ｍｂｐｓであるから、必要帯域neededは０Ｍｂｐｓ＋１Ｍｂｐｓ＝１Ｍｂｐｓである。不足帯域shortageは１Ｍｂｐｓ−６０Ｍｂｐｓ＝−５９Ｍｂｐｓであり、帯域は足りていると判定される。
【００９９】
ソケットＡが帯域制御を受ける一方で、ソケットＣがさらに通信量を増加させ、ソケットＣの実際の帯域が１０Ｍｂｐｓに達したとする。このとき、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは１０Ｍｂｐｓ＋４０Ｍｂｐｓ＝５０Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは１０Ｍｂｐｓであるから、必要帯域neededは５０Ｍｂｐｓ＋１０Ｍｂｐｓ＝６０Ｍｂｐｓである。不足帯域shortageは６０Ｍｂｐｓ−６０Ｍｂｐｓ＝０Ｍｂｐｓであり、ちょうど帯域が足りている状態になる。帯域不足は解消され、これ以降は、ソケットＡは帯域制御を受けない。
【０１００】
注目ソケットＢの優先度３よりも高い優先度に対する下限ネットワーク帯域lower_bpsは１０Ｍｂｐｓであり、注目ソケットＢの優先度３に対する現在の消費帯域current_priority_bpsは４０Ｍｂｐｓであるから、必要帯域neededは１０Ｍｂｐｓ＋４０Ｍｂｐｓ＝５０Ｍｂｐｓである。不足帯域shortageは５０Ｍｂｐｓ−６０Ｍｂｐｓ＝−１０Ｍｂｐｓであり、帯域は足りていると判定される。
【０１０１】
注目ソケットＣの優先度２よりも高い優先度に対する下限ネットワーク帯域lower_bpsは０Ｍｂｐｓであり、注目ソケットＣの優先度２に対する現在の消費帯域current_priority_bpsは１０Ｍｂｐｓであるから、必要帯域neededは０Ｍｂｐｓ＋１０Ｍｂｐｓ＝１０Ｍｂｐｓである。不足帯域shortageは１０Ｍｂｐｓ−６０Ｍｂｐｓ＝−５０Ｍｂｐｓであり、帯域は足りていると判定される。
【０１０２】
この先、ソケットＣの通信量がさらに１１Ｍｂｐｓに増えることがあったとしても、ソケットＡおよびソケットＢは帯域制御を受けないことから、通信の平均化により、相対的にソケットＡやソケットＢに通信の機会が割り当てられ、結果的にソケットＣの通信量が自然に下がり、ソケットＣの実際の帯域は１０Ｍｂｐｓで安定する。これは帯域制御によるのではなく、通信の平均化による効果であることに留意する。
【０１０３】
このように帯域制御と通信の平均化の結果、図１０（ａ）の状態から図１０（ｂ）の状態に遷移する。すなわち、ソケットＣの実際の帯域が指定された下限帯域の１０Ｍｂｐｓにまで達し、その分、ソケットＡの実際の帯域は２０Ｍｂｐｓから１０Ｍｂｐｓにまで減少することで安定する。
【０１０４】
まとめれば、ソケットＡは、優先度の高いソケットＣの通信が開始されたことにより、帯域制御に従って実際の帯域を２０Ｍｂｐｓから絞る方向に進む。ソケットＢは、ソケットＡよりも優先度が高いため、帯域判定の計算の結果、この場合は、実際の帯域を絞ることはない。ソケットＣは、通信の平均化により０Ｍｂｐｓから１、２、…、１０Ｍｂｐｓと進み、１０Ｍｂｐｓを超えると、他のソケットから見るとソケットＣは下限帯域を満たし、これ以上の帯域制御をしなくてもよいと判断される。その結果、ソケットＣ以外のソケットにも帯域が割り当てられることで、ソケットＣの実際の帯域は自然と１０Ｍｂｐｓに収束する。
【０１０５】
図１１（ａ）および図１１（ｂ）において、ソケットＡの優先度は３１で、ソケットＢの優先度は３で、ソケットＣの優先度は２である。図１１（ａ）の状態では、ソケットＡの実際の帯域と制限帯域は２０／０／０であり、ソケットＢの実際の帯域と制限帯域は４０／４０／５０であり、ソケットＣの実際の帯域と制限帯域は０／２５／４０である。この状態でソケットＡ、ソケットＢ、ソケットＣがそれぞれ帯域を使えるだけ使う通信を行ったとする。
【０１０６】
図１０（ａ）の状態と同様、図１１（ａ）の状態では、ソケットＡ、ソケットＢ、ソケットＣについて不足帯域shortageは０以下であり、帯域は足りていると判定される。
【０１０７】
この状態からソケットＣが１Ｍｂｐｓの通信を行ったとする。このとき、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは２５Ｍｂｐｓ＋４０Ｍｂｐｓ＝６５Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは２０Ｍｂｐｓであるから、必要帯域neededは６５Ｍｂｐｓ＋２０Ｍｂｐｓ＝８５Ｍｂｐｓである。不足帯域shortageは８５Ｍｂｐｓ−６０Ｍｂｐｓ＝２５Ｍｂｐｓであり、帯域不足と判定される。帯域不足のため、ソケットＡは帯域制御を受け、ソケットＡの実際の帯域は減少し始める。
【０１０８】
注目ソケットＢの優先度３よりも高い優先度に対する下限ネットワーク帯域lower_bpsは２５Ｍｂｐｓであり、注目ソケットＢの優先度３に対する現在の消費帯域current_priority_bpsは４０Ｍｂｐｓであるから、必要帯域neededは２５Ｍｂｐｓ＋４０Ｍｂｐｓ＝６５Ｍｂｐｓである。不足帯域shortageは６５Ｍｂｐｓ−６０Ｍｂｐｓ＝５Ｍｂｐｓであり、帯域不足と判定される。帯域不足のため、ソケットＢは帯域制御を受け、ソケットＢの実際の帯域は減少し始める。
【０１０９】
注目ソケットＣの優先度２よりも高い優先度に対する下限ネットワーク帯域lower_bpsは０Ｍｂｐｓであり、注目ソケットＣの優先度２に対する現在の消費帯域current_priority_bpsは１Ｍｂｐｓであるから、必要帯域neededは０Ｍｂｐｓ＋１Ｍｂｐｓ＝１Ｍｂｐｓである。不足帯域shortageは１Ｍｂｐｓ−６０Ｍｂｐｓ＝−５９Ｍｂｐｓであり、帯域は足りていると判定される。
【０１１０】
ソケットＡおよびソケットＢがともに帯域制御を受けるが、ソケットＡはソケットＢよりも優先度が低いので、より多く帯域が制御される。一方、ソケットＣは帯域制御を受けないため、さらに通信量を増加させる。ソケットＣの実際の帯域が２５Ｍｂｐｓに達し、ソケットＢの実際の帯域が３５Ｍｂｐｓに、ソケットＡの実際の帯域が０Ｍｂｐｓにまで減少したとする。このとき、注目ソケットＡの優先度３１よりも高い優先度に対する下限ネットワーク帯域lower_bpsは２５Ｍｂｐｓ＋４０Ｍｂｐｓ＝６５Ｍｂｐｓであり、注目ソケットＡの優先度３１に対する現在の消費帯域current_priority_bpsは０Ｍｂｐｓであるから、必要帯域neededは６５Ｍｂｐｓ＋０Ｍｂｐｓ＝６５Ｍｂｐｓである。不足帯域shortageは６５Ｍｂｐｓ−６０Ｍｂｐｓ＝５Ｍｂｐｓであり、帯域不足と判定されるが、ソケットＡは既に実際の帯域が０Ｍｂｐｓであるから、これ以上は帯域は減少しない。
【０１１１】
注目ソケットＢの優先度３よりも高い優先度に対する下限ネットワーク帯域lower_bpsは２５Ｍｂｐｓであり、注目ソケットＢの優先度３に対する現在の消費帯域current_priority_bpsは３５Ｍｂｐｓであるから、必要帯域neededは２５Ｍｂｐｓ＋３５Ｍｂｐｓ＝６０Ｍｂｐｓである。不足帯域shortageは６０Ｍｂｐｓ−６０Ｍｂｐｓ＝０Ｍｂｐｓであり、ちょうど帯域は足りており、これ以降はソケットＢは帯域制御を受けない。
【０１１２】
注目ソケットＣの優先度２よりも高い優先度に対する下限ネットワーク帯域lower_bpsは０Ｍｂｐｓであり、注目ソケットＣの優先度２に対する現在の消費帯域current_priority_bpsは２５Ｍｂｐｓであるから、必要帯域neededは０Ｍｂｐｓ＋２５Ｍｂｐｓ＝２５Ｍｂｐｓである。不足帯域shortageは２５Ｍｂｐｓ−６０Ｍｂｐｓ＝−３５Ｍｂｐｓであり、帯域は足りていると判定される。
【０１１３】
この先、ソケットＣの通信量が２５Ｍｂｐｓからさらに増えることがあったとしても、ソケットＢは帯域制御を受けず、ソケットＡの実際の帯域は既に０Ｍｂｐｓであるため、通信の平均化により、相対的にソケットＢに通信の機会が割り当てられ、結果的にソケットＣの通信量が自然に下がり、ソケットＣの実際の帯域は２５Ｍｂｐｓで安定する。これは帯域制御によるのではなく、通信の平均化による効果であることに留意する。
【０１１４】
このように帯域制御と通信の平均化の結果、図１１（ａ）の状態から図１１（ｂ）の状態に遷移する。すなわち、ソケットＣの実際の帯域が指定された下限帯域の２５Ｍｂｐｓにまで達し、その分、ソケットＡの実際の帯域は２０Ｍｂｐｓから０Ｍｂｐｓにまで減少し、ソケットＢの実際の帯域は４０Ｍｂｐｓから３５Ｍｂｐｓにまで減少することで安定する。
【０１１５】
まとめれば、ソケットＡは、優先度の高いソケットＣの通信が開始されたことにより、帯域制御に従って実際の帯域を２０Ｍｂｐｓから０Ｍｂｐｓまで絞る方向に進む。ソケットＢも帯域制御に従って実際の帯域を４０Ｍｂｐｓから絞る方向に進むが、ソケットＡよりも優先度が高いため、５Ｍｂｐｓだけ減少させるにとどまる。ソケットＣは、通信の平均化により０Ｍｂｐｓから１、２、…、２５Ｍｂｐｓと進み、２５Ｍｂｐｓを超えると、他のソケットから見るとソケットＣは下限帯域を満たし、これ以上の帯域制御をしなくてもよいと判断される。その結果、ソケットＣ以外のソケットにも帯域が割り当てられることで、ソケットＣの実際の帯域は自然と２５Ｍｂｐｓに収束する。
【０１１６】
上記の実施の形態では、ソケット通信を前提としてソケットをユニークに識別するためのソケットＩＤを例に取って説明したが、通信単位をユニークに識別することのできる他の識別情報を用いてもよい。ソケットＩＤはアプリケーションから見た低レベルのＩＤであるが、ＨＴＴＰ  ＩＤのような上位レベルのＩＤを通信単位の識別情報として用いてもよい。ここで、ＨＴＴＰ  ＩＤとは、サーバのホスト名やポート番号などの接続先の設定情報、getメソッドやpostメソッドなどのメソッドの種別情報、ＨＴＴＰ  ＵＲＩ（Uniform Resource Identifier）のパス情報などを組にした識別子である。ソケットＩＤの場合、本実施の形態の帯域制御をカーネルに実装することが必要になるが、ＨＴＴＰレベルであれば、本実施の形態の帯域制御をユーザ空間に実装することが可能になり、カーネルの変更をしなくてよい。ＨＴＴＰレベルの実装の場合、ネットワークインターフェースの最大帯域の代わりに、ＨＴＴＰライブラリやプロセスでの通信量が分かればその値も使うことができる。
【０１１７】
以上述べたように、本実施の形態によれば、通信単位ごとに優先度と要求帯域を設けて、複数の通信に対してネットワーク帯域を適切に割り当てることができる。ゲームアプリケーションやシステムソフトウェアなどの特定の通信によりネットワーク帯域が占有されて、他の通信にネットワーク帯域が十分に割り当てられない状況を回避することができる。
【０１１８】
また、本実施の形態では、特定の通信にネットワーク帯域を保証するために、実際にはネットワーク帯域を使用していないにもかかわらず、常に一定帯域を確保するようなことはしない。使用していないネットワーク帯域は他の通信に融通される。また、ネットワーク帯域を使用していない通信単位が帯域を使い始めたときは、他の通信単位の使用帯域を絞ることで動的にネットワーク帯域を配分することができる。
【０１１９】
また、本実施の形態では、ネットワークの最大帯域を実際の送受信量から推定するため、各家庭のネットワーク環境のように、ＷＡＮ側のネットワーク帯域が異なっていても、同一の帯域制御を適用することができる。
【０１２０】
また、本実施の形態によれば、適用されるポリシーによってソケット通信をグループ化して、ソケット通信のグループ毎に異なるポリシーを適用することができる。アプリケーション側でソケットを生成する際に、ポリシー番号を設定して、そのソケット通信に適用するポリシーを決めることができる。ソケットＩＤはアプリケーションの起動の度にオペレーティングシステムが任意に割り当てるが、アプリケーションソフトウエアにおいてsetsockopt()関数などを用いて、ソケットのポリシー番号を設定するようにしておけば、システムで任意のソケットＩＤが割り当てられたとしても、そのソケット通信に対しては同じポリシー番号のポリシーを適用することができる。なお、ポリシー番号で識別されるポリシーの内容は、後から、アプリケーションとは独立して別途、設定すればよい。つまり、アプリケーションの開発者は自身が決めたり、知りうるポリシー番号に対して通信をエミュレートするといった扱い方ができるようになる。
【０１２１】
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１２２】
上記の実施の形態では、帯域制御を例に取って説明したが、適用されるポリシーの違いでグループ化されたソケットに対して、帯域制御以外の制御を適用してもよい。たとえば、ソケット通信のポリシーグループに対して、アクセス制御やサービス品質の制御を行ってもよい。あるポリシーグループのソケット通信に対しては、インターネットや外部サーバに対するアクセスを制限し、ローカルエリアネットワーク内の通信だけを許可するようにアクセス制御してもよい。
【符号の説明】
【０１２３】
１０  ソケット生成部、  １２  ポリシー番号・優先度設定部、  １４  ポリシーテーブル記憶部、  ２０ａ  送信バッファ、  ２０ｂ  受信バッファ、  ２２ａ、２２ｂ  ポリシー番号・優先度取得部、  ２４ａ、２４ｂ  ポリシー適用部、  ２６ａ、２６ｂ  帯域制御部、  ２８ａ  パケット送信部、  ２８ｂ  パケット受信部、  ３０  デバイスドライバ、  １００  通信処理装置。
【図１】
2014239308.tif 000003
【図２】
2014239308.tif 000004
【図３】
2014239308.tif 000005
【図４】
2014239308.tif 000006
【図５】
2014239308.tif 000007
【図６】
2014239308.tif 000008
【図７】
2014239308.tif 000009
【図８】
2014239308.tif 000010
【図９】
2014239308.tif 000011
【図１０】
2014239308.tif 000012
【図１１】
2014239308.tif 000013