(57)【要約】【課題】通信速度の低下を抑制することができる通信装置を提供すること。【解決手段】受信したデータにプロトコル処理を実行する第１の処理手段と、前記第１の処理手段からデータをコピーし、アプリケーション処理を実行する第２の処理手段と、前記第１の処理手段に格納されたデータの量に基づいて、前記アプリケーション処理と前記プロトコル処理とのいずれを優先させるかを制御する制御手段と、を備える。【選択図】図４
2018093330.tif 000002
【特許請求の範囲】
【請求項１】
外部装置からデータを受信する通信装置であって、
受信したデータにプロトコル処理を実行する第１の処理手段と、
前記第１の処理手段からデータをコピーし、アプリケーション処理を実行する第２の処理手段と、
前記第１の処理手段に格納されたデータの量に基づいて、前記アプリケーション処理と前記プロトコル処理とのいずれを優先させるかを制御する制御手段と、
を備えることを特徴とする通信装置。
【請求項２】
前記制御手段は、前記第１の処理手段に格納されたデータの量が閾値よりも大きい場合、前記アプリケーション処理を前記プロトコル処理よりも優先することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記第１の処理手段は、前記プロトコル処理を実行して得られたデータを格納する格納部を有し、
前記制御手段は、前記格納部に格納可能な最大データ量を用いて前記閾値を決定することを特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記制御手段は、前記データの受信速度を用いて前記閾値を決定することを特徴とする請求項１、２または３に記載の通信装置。
【請求項５】
前記制御手段は、前記外部装置との間で送受信するパケットのＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）を用いて、前記閾値を決定することを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
前記制御手段は、前記第２の処理手段が前記第１の処理手段からデータをコピーするのに要する時間を用いて、前記閾値を決定することを特徴とする請求項１から５のいずれか１項に記載の通信装置。
【請求項７】
前記第２の処理手段が前記閾値を決定することを特徴とする請求項１または２に記載の通信装置。
【請求項８】
前記制御手段は、前記アプリケーション処理を前記プロトコル処理よりも優先した後、前記アプリケーション処理が終了したならば、前記プロトコル処理を前記アプリケーション処理より優先させることを特徴とする請求項１から７のいずれか１項に記載の通信装置。
【請求項９】
前記制御手段は、前記アプリケーション処理を前記プロトコル処理よりも優先した後、前記第１の処理手段のデータ格納容量が増大したならば、当該データ格納容量の増大を前記外部装置に通知することを特徴とする請求項１から８のいずれか１項に記載の通信装置。
【請求項１０】
前記制御手段は、前記第１の処理手段に格納されたデータの量が閾値よりも大きい場合であっても、前記アプリケーション処理の内容に基づいて、前記アプリケーション処理を前記プロトコル処理よりも優先させないことを特徴とする請求項１から９のいずれか１項に記載の通信装置。
【請求項１１】
前記外部装置との通信は、ＴＣＰ／ＩＰプロトコルを利用して行うことを特徴とする請求項１から１０のいずれか１項に記載の通信装置。
【請求項１２】
外部装置からデータを受信する通信装置の制御方法であって、
受信したデータにプロトコル処理を実行し、処理後のデータを格納するステップと、
格納した前記データをコピーし、当該データにアプリケーション処理を実行するステップと、
格納された前記データの量に基づいて、前記アプリケーション処理と前記プロトコル処理とのいずれを優先させるかを制御するステップと、
を有することを特徴とする通信装置の制御方法。
【請求項１３】
コンピュータを、請求項１から１１のいずれか１項に記載の通信装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信装置および通信装置の制御方法に関する。  
【背景技術】
【０００２】
現在インターネット上で広く採用されているＴＣＰ／ＩＰプロトコルスタックは、複数の通信プロトコルを階層的に並べた構造になっており、レイヤごとに実行する処理が定められている。ＴＣＰ／ＩＰはＴｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌの略である。
パケットの送信を行う際には、レイヤごとにプロトコルの制御情報が記載されたヘッダを送信データに付加して、下位レイヤのプロトコルに渡す処理を実行する。パケットの受信を行う際には、レイヤごとに受信パケットのヘッダを解析し、上位レイヤのプロトコルに当該レイヤのヘッダを取り除いたデータを渡す処理を実行する。
【０００３】
近年、高速なデータ通信が求められるようになっており、効率的にＴＣＰ／ＩＰプロトコル処理を実行する必要がある。これを実現するための構成として、例えば、ネットワークレイヤとトランスポートレイヤの処理を１つのタスクで行い、アプリケーションレイヤの処理を１つのタスクで実行するような構成が考えられる。この構成では、トランスポートレイヤまでの階層で処理されて得られたデータは、プロトコルスタックが各ソケットに割り当てたデータ格納部であるデータバッファ（以下、「ソケットバッファ」と称する）に格納される。そして、上位層のアプリケーションレイヤでは、ソケットバッファからアプリケーションの用意したデータバッファ（以下、「アプリケーションバッファ」と称する）にデータをコピーし、当該コピーしたデータに対して処理を実行していく。
【０００４】
連続的にパケットを受信するような通信ホストが上記のようなタスク構成を用いる場合を考える。ここで、ネットワークレイヤとトランスポートレイヤの処理を実行するタスクを「プロトコルスタックタスク」と称し、アプリケーションレイヤの処理を実行するタスクを「アプリケーションタスク」と称することにする。連続的にパケットを受信する通信ホストがプロトコルスタックタスクの処理優先度をアプリケーションタスクよりも高く設定すると、ネットワークレイヤとトランスポートレイヤの処理をアプリケーションレイヤよりも優先して実行することが可能となる。その結果、複数の受信パケットに対してネットワークレイヤとトランスポートレイヤの処理を連続して実行することができるようになる（特許文献１）。
【０００５】
ＴＣＰでは信頼性のあるデータ送信を実現するために、ソケットバッファの空き容量を受信側ホストから送信側ホストに通知する機能を持っている。このソケットバッファの空き容量の通知は、受信側ホストがパケットを受信し、プロトコルスタックタスクがＴＣＰ処理を実行することで返送される確認応答（ＡＣＫ）パケットの広告ウィンドウフィールドを用いて行われる。通知される広告ウィンドウサイズは、プロトコルスタックタスクがソケットバッファに受信データを格納することで徐々に縮小していき、アプリケーションタスクがソケットバッファからアプリケーションバッファに受信データをコピーすることで拡大される。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１０−１５５０１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１のようなタスク構成を用いてＴＣＰ通信を行うと、かえって通信速度を低下させてしまう可能性がある。
例えば、送信側ホストのデータ送信速度が、受信側ホストのデータ受信速度よりも高速である状況を想定する。プロトコルスタックタスクは、アプリケーションタスクよりも優先してプロトコル処理を実行し、ソケットバッファに受信データを格納していく。このとき、送信側ホストのデータの送信速度が受信側ホストのデータ受信速度よりも高速であるため、受信側ホストが持つネットワークインタフェースに処理すべきパケットが絶え間なく存在している状態になる。その結果、スタックが持つソケットバッファに受信データが格納できなくなるまで、優先度の高いプロトコルスタックタスクが継続して受信処理を実行してしまう。これにより、アプリケーションタスクはアプリケーション処理を開始することができず、ソケットバッファが満たされるまでアプリケーションバッファにデータをコピーすることができなくなってしまう。
【０００８】
このときのＴＣＰの動作を考えると、プロトコルスタックタスクが継続的に処理を実行するため、受信側ホストはソケットバッファに空きがないことを通知するための確認応答を送信側ホストに送信することになる。一方、通知を受けた送信側ホストは、所定の期間、データの送信を行うことができなくなる。つまり、送信側ホストは、受信側ホストのソケットバッファ内のデータがアプリケーションタスクによりコピーされ、広告ウィンドウサイズが拡張された事を通知する確認応答を受信するまで、データの送信を行うことができなくなる。これにより、送信側ホストから受信側ホストへのデータ送信の停滞が発生し、通信速度の低下をもたらしてしまう。
本発明は、上記した従来技術の課題に鑑み、通信速度の低下を抑制することができる通信装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の１つの態様による通信装置は、外部装置からデータを受信する通信装置であって、受信したデータにプロトコル処理を実行する第１の処理手段と、前記第１の処理手段からデータをコピーし、アプリケーション処理を実行する第２の処理手段と、前記第１の処理手段に格納されたデータの量に基づいて、前記アプリケーション処理と前記プロトコル処理とのいずれを優先させるかを制御する制御手段と、を備える。
【発明の効果】
【００１０】
本発明によれば、通信速度の低下を抑制することができる。
【図面の簡単な説明】
【００１１】
【図１】通信システムの全体構成を示す図である。
【図２】実施形態１の受信側ホストのタスク構成を示す図である。
【図３】実施形態１の受信側ホストのブロック図である。
【図４】実施形態１のプロトコルスタックタスクのフローチャートである。
【図５】実施形態１のアプリケーションタスクのフローチャートである。
【図６】実施形態２のアプリケーションタスクのフローチャートである。
【図７】実施形態２のプロトコルスタックタスクのフローチャートである。
【図８】受信側ホストのハードウェア構成図である。
【発明を実施するための形態】
【００１２】
以下、添付図面を参照して、本発明を実施するための実施形態を詳細に説明する。以下に説明する実施形態は、本発明の実現手段としての一例であり、本発明が適用される装置やシステムの構成や各種条件によって適宜修正または変更されるべきものであり、本発明は以下の実施形態に限定されるものではない。
実施形態１
実施形態１では、外部装置からデータ（パケット）を受信する通信装置を説明する。
（通信システムの全体構成）
図１はデータ通信を行う通信システム１０の全体構成図である。図１の通信システム１０は、送信側ホスト１１と受信側ホスト１２がネットワーク１３を介して通信可能な状況を表している。受信側ホスト１２が送信側ホスト１１からデータ（パケット）を受信する。本実施形態では、送信側ホスト１１と受信側ホスト１２の通信は、ＴＣＰ／ＩＰプロトコルを利用して行う。
【００１３】
（タスク構成）
図２は受信側ホスト１２で動作するＴＣＰ／ＩＰプロトコルスタックの処理を実行するためのタスク構成の例を示したものである。このタスク構成は、プロトコルスタックタスク２１と、アプリケーションタスク２２とを含む。
（プロトコルスタックタスク）
プロトコルスタックタスク２１は、ＴＣＰ／ＩＰプロトコルスタックの処理の内、ソフトウェアで実行可能なリンクレイヤの処理から、トランスポートレイヤの処理までを実行するタスクである。プロトコルスタックタスク２１は、リンクレイヤプロトコル処理２１ａと、ネットワークレイヤプロトコル処理２１ｂと、トランスポートレイヤプロトコル処理２１ｃとを有する。なお、以下の記載および図２において、「リンクレイヤプロトコル処理２１ａ」は「リンクレイヤ処理２１ａ」と表記し、「ネットワークレイヤプロトコル処理２１ｂ」は「ネットワークレイヤ処理２１ｂ」と表記する。また、「トランスポートレイヤプロトコル処理２１ｃ」は「トランスポートレイヤ処理２１ｃ」と表記する。図２から、受信側ホスト１２のプロトコルスタックタスク２１には、３つのレイヤ（トランスポートレイヤ、ネットワークレイヤおよびリンクレイヤ）が含まれていることが分かる。
【００１４】
リンクレイヤ処理２１ａはリンクレイヤの処理の内、ＡＲＰなどのようにソフトウェアで実行可能なプロトコル処理を実行する。ネットワークレイヤ処理２１ｂはＩＰやＩＣＭＰなどのプロトコル処理を実行する。トランスポートレイヤ処理２１ｃはＴＣＰやＵＤＰなどのプロトコル処理を実行する。ＡＲＰは、Ａｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌの略である。ＩＣＭＰは、Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌの略である。ＵＤＰは、Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌの略である。
各レイヤのプロトコル処理を実行することで得られるデータは、受信側ホスト１２の持つ各ソケットに割り当てられたソケットバッファ部（図３）に格納される。ソケットバッファ部は、データを格納する格納部である。本実施形態では、ネットワークレイヤプロトコル処理としてＩＰを使用し、トランスポートレイヤプロトコル処理としてＴＣＰを使用する例について説明する。
【００１５】
（アプリケーションタスク）
アプリケーションタスク２２は、ソケットバッファからアプリケーションの用意したデータバッファにデータをコピーし、各アプリケーションが実行するデータ処理（アプリケーション処理）を実行するタスクである。アプリケーションタスク２２は、データコピー処理２２ａと、データ処理２２ｂとを含む。
データコピー処理２２ａはプロトコルスタックタスク２１によって取得したデータを、ソケットバッファから、アプリケーションが用意したアプリケーションバッファにコピーする処理である。データ処理２２ｂは、アプリケーションバッファにコピーしたデータに、アプリケーションの特性に従って加工や解析などを施す処理である。
【００１６】
アプリケーションタスク２２は動作するアプリケーションの数と同じ数だけ存在してよい。その場合、各々のアプリケーションタスク２２が独立してコネクション（通信経路）を確立し、異なる送信側ホストと通信することができる。
本実施形態ではプロトコルスタックタスク２１は、上位層で動作する複数のアプリケーションタスク２２よりも高い応答性が求められるとする。そのため、デフォルトの処理優先度は、プロトコルスタックタスク２１の方が、いずれのアプリケーションタスク２２よりも高いものとする。
【００１７】
（受信側ホスト１２の機能ブロック図）
図３は、図２で説明したタスク構成でデータの受信処理を実行する受信側ホスト１２の機能ブロック図である。受信側ホスト１２は、ネットワークインタフェース部３１と、プロトコルスタック処理部３２と、アプリケーション処理部３３とを有する。
ネットワークインタフェース部３１は、受信パケット受信部３１ａを有する。ネットワークインタフェース部３１は、ネットワーク１３（図１）と接続しており、送信側ホスト１１から送信されたパケット（図３の白矢印）を受信する。受信したパケット（以下、「受信パケット」と称する）は受信パケット受信部３１ａに格納される。
【００１８】
プロトコルスタック処理部３２は、パケットバッファ部３４と、リンクレイヤプロトコル処理部３５と、ネットワークレイヤプロトコル処理部３６と、トランスポートレイヤプロトコル処理部３７とを有する。プロトコルスタック処理部３２は図２で説明したプロトコルスタックタスク２１の処理を実行する。なお、以下の記載および図３において「リンクレイヤプロトコル処理部３５」は「リンクレイヤ処理部３５」と表記し、「ネットワークレイヤプロトコル処理部３６」は「ネットワークレイヤ処理部３６」と表記する。また、「トランスポートレイヤプロトコル処理部３７」は「トランスポートレイヤ処理部３７」と表記する。
【００１９】
パケットバッファ部３４は、受信パケットバッファ部３４ａとソケットバッファ部３４ｂとを備えている。受信パケットバッファ部３４ａは、受信パケット受信部３１ａからコピーした受信パケットを各レイヤでプロトコル処理するためにバッファする（格納する）。ソケットバッファ部３４ｂは、各レイヤのプロトコル処理を実行して取得したデータを、上位レイヤのアプリケーションに渡すためのバッファ部である。ソケットバッファ部３４ｂは、ソケットごと（アプリケーションごと）に設けられる。
リンクレイヤ処理部３５は、図２のリンクレイヤ処理２１ａを実行する。ネットワークレイヤ処理部３６は、図２のネットワークレイヤ処理２１ｂを実行する。
トランスポートレイヤプロトコル処理部３７は、図２のトランスポートレイヤ処理２１ｃを実行する。本実施形態では、トランスポートレイヤプロトコル処理部３７は、ＲＴＴを計測する為のＲＴＴ計測部３７ａと、データの受信速度を計測するデータ受信速度計測部３７ｂとを有する。ＲＴＴは、送信側ホスト１１と受信側ホスト１２との間で送受信するパケットのＲｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅである。
【００２０】
アプリケーション処理部３３は、データコピー処理部３３ａと、アプリケーションバッファ部３３ｂと、データ処理部３３ｃとを有する。アプリケーション処理部３３は、図２で説明したアプリケーションタスク２２の処理を実行する。アプリケーション処理部３３は、アプリケーションタスク２２と同じ数だけ設けられている。
データコピー処理部３３ａは、アプリケーションが使用するソケットの情報を基に、ソケットバッファ部３４ｂからアプリケーションバッファ部３３ｂへデータをコピーする。アプリケーションバッファ部３３ｂに格納されたデータは、アプリケーションの内容に応じて、データ処理部３３ｃにより解析や加工などの処理がなされる。
【００２１】
（プロトコルスタックタスク処理）
次に、図４のフローチャートを用いて、プロトコルスタック処理部３２の動作（プロトコルスタックタスク処理）を説明する。以下の説明では、１つのアプリケーションタスクが処理され、１つのソケットバッファ部３４ｂと１つのアプリケーション処理部３３が使用されるとする。
Ｓ４０１において、プロトコルスタック処理部３２は、まずネットワークインタフェース部３１の受信パケット受信部３１ａに、未処理の受信パケットが格納されているかを判定（確認）する。受信パケット受信部３１ａに未処理の受信パケットが格納されている場合、Ｓ４０２に進む。
Ｓ４０２において、プロトコルスタック処理部３２は、受信パケット受信部３１ａから、プロトコルスタック処理部３２内のパケットバッファ部３４（受信パケットバッファ部３４ａ）に受信パケットをコピーする。
【００２２】
パケットバッファ部３４にコピーされた受信パケットには、Ｓ４０３において、各レイヤのプロトコル処理部（３５、３６、３７）により、ヘッダの解析やペイロードの抽出などのプロトコル処理が施される。当該プロトコル処理により得られたデータは、ソケットバッファ部３４ｂに格納される。ここでトランスポートレイヤプロトコル処理部３７では、トランスポートレイヤのプロトコルとしてＴＣＰの処理を実行しているため、ネットワークインタフェース部３１から送信側ホスト１１に確認応答（ＡＣＫ）の送信するための処理を実行する。このとき、トランスポートレイヤプロトコル処理部３７は、ソケットバッファ部３４ｂに格納可能なデータ量（データ格納容量）を計算し、確認応答の広告ウィンドウフィールドを用いて、当該計算したデータ格納容量を送信側ホスト１１に通知する。
【００２３】
その後、Ｓ４０４において、プロトコルスタック処理部３２は、ソケットバッファ部３４ｂに格納されているデータの量が、閾値よりも大きいか否かを判定する。当該データの量が閾値よりも大きくない場合（Ｓ４０４：Ｎ）、Ｓ４０６に進む。閾値の設定については後述する。Ｓ４０４は、ソケットバッファ部３４ｂが、あとどれくらいのデータを格納できるかを判定しているので、データ格納余裕度を判定していると言うこともできる。
Ｓ４０４において当該データの量が閾値よりも大きいと判定されると、Ｓ４０５に進む。当該データの量が閾値よりも大きい場合に、継続して受信パケット受信部３１ａの未処理パケットにプロトコル処理を実行すると、ソケットバッファ部３４ｂの空き容量（データ格納余裕度）が無くなる。ソケットバッファ部３４ｂのデータ格納余裕度が無くなると、受信側ホスト１２は、ソケットバッファ部３４ｂに空き容量が無いことを送信側ホスト１１に通知する。この通知を受けた送信側ホスト１１は、受信側ホスト１２から広告ウィンドウサイズ拡張の通知が来るまで、受信側ホスト１２へのデータ送信を停止する。よって、送信側ホスト１１からのパケット送信の停滞が発生してしまう。これは、プロトコルスタックタスク２１の処理優先度がアプリケーションタスク２２の処理優先度より高く設定されているからである。
【００２４】
このようなパケット送信の停滞を回避するために、本実施形態では、Ｓ４０４の判定がイエス（Ｙ）の場合、ソケットバッファ部３４ｂに格納されているデータをアプリケーションバッファ３３ｂに強制的にコピーする。強制的なコピーを行うために、Ｓ４０５において、プロトコルスタック処理部３２は、アプリケーションタスク２２の処理優先度を、プロトコルスタックタスク２１の処理優先度より高くする（処理優先度の変更）。Ｓ４０５の処理は、例えば、アプリケーションタスク２２の処理優先度を高くすることで実現する（プロトコルスタックタスク２１の処理優先度は不変）。あるいは、Ｓ４０５の処理は、プロトコルスタックタスク２１の処理優先度を低くすることで実現してもよい（アプリケーションタスク２２の処理優先度は不変）。Ｓ４０５の後、Ｓ４０６に進む。
【００２５】
Ｓ４０６において、アプリケーションタスク２２の処理優先度がプロトコルスタックタスク２１の処理優先度よりも高くなっているかを判定する。アプリケーションタスク２２の処理優先度がプロトコルスタックタスク２１の処理優先度よりも高くなっていれば、Ｓ４０７に進む。Ｓ４０７において、プロトコルスタック処理部３２は、プロトコルスタックタスク２１の処理を中断し、アプリケーションタスク２２にタスクスイッチする。
アプリケーションタスク２２の処理優先度がプロトコルスタックタスク２１の処理優先度よりも高くなっていなければ、Ｓ４０１に戻る。この場合は、継続してプロトコルスタック処理部３２が処理を実行するため、Ｓ４０１からの処理を繰り返して実行する。
【００２６】
Ｓ４０１において受信パケット受信部３１ａに未処理の受信パケットが格納されていないと判定された場合（存在していないと判定された場合）、Ｓ４０８に進む。
Ｓ４０８において、プロトコルスタック処理部３２は、ソケットバッファ部３４ｂにデータが格納されているか否かを判定する。いずれかのソケットバッファ部３４ｂにデータが格納されていれば（Ｓ４０８：Ｙ）、Ｓ４０７に進む。Ｓ４０７において、当該ソケットバッファ部３４ｂからデータを取得するアプリケーションタスク２２に、タスクスイッチする。いずれのソケットバッファ部３４ｂにもデータが格納されていない場合、プロトコルスタックタスク２１の処理を終了する。
なお、アプリケーションタスク２２にスイッチすると、図５のフローチャート（アプリケーションタスク処理）に移る。後述するように、図５においてアプリケーションタスクからプロトコルスタックタスクにスイッチする場合があるので、図４において、Ｓ４０７から上に延びる矢印はＳ４０１に到達するように描かれている。
【００２７】
（閾値の設定方法）
ここで、Ｓ４０４で使用される閾値の設定方法について説明する。この閾値は、プロトコルスタック処理部３２が決定する値を使用してもよいし、アプリケーション処理部３３からの閾値の指定がある場合には、指定された値を使用してもよい。
プロトコルスタック処理部３２が閾値を決定する場合、例えばソケットバッファ部３４ｂに格納可能な最大データ量の７０％の値を閾値として設定する。
閾値の設定方法は、上記した方法に限定されない。例えば、プロトコルスタック処理部３２が広告ウィンドウサイズに加えて、データ受信速度計測部３７ｂからデータ受信速度を取得できれば、ソケットバッファ部３４ｂが受信データで満たされるまでのおおよその時間を式（１）により算出できる。 
バッファが満たされるまでの時間  ＝ バッファの空き容量÷データ受信速度    （１） 
例えばこの時間が１０ミリ秒（１０ｍｓｅｃ）になったらアプリケーションタスク２２の優先度が高くなるように閾値の設定をしたい場合は、「１０ｍｓｅｃ×データ受信速度」で得られるソケットバッファの空き容量を閾値として使用することが考えられる。
【００２８】
さらに、プロトコルスタック処理部３２がＲＴＴ計測部３７ａ、データ受信速度計測部３７ｂおよびデータコピー処理部３３ａから、それぞれ閾値関連情報を取得できる場合を考える。ＲＴＴ計測部３７ａから取得できる閾値関連情報は、ＲＴＴである。データ受信速度計測部３７ｂから取得できる閾値関連情報は、データ受信速度である。データコピー処理部３３ａから取得できる閾値関連情報は、ソケットバッファ部３４ｂからアプリケーションバッファ部３３ｂにデータをコピーするのに要する時間である。これら閾値関連情報を使用すると、より正確にプロトコルスタックタスク２１からアプリケーションタスク２２にタスクスイッチすべきタイミングを導出することができる。つまり、上述の閾値関連情報から送信側ホスト１１がパケットの送信を停止するまでの時間を予測（算出）し、継続してパケット送信できるように、受信側ホスト１２が広告ウィンドウの拡大を通知できるように閾値を算出（決定）する。これを実現するために、例えば、以下の式（２）が成立するタイミングで、プロトコルスタックタスク２１からアプリケーションタスク２２にタスクスイッチをすると良い。
【００２９】
バッファの空き容量÷データ受信速度  ＝  ＲＴＴ＋データコピー時間      （２）
式（２）の左辺は、ソケットバッファ部３４ｂがデータで満たされるまでの時間を表している。式（２）の右辺は、タスクスイッチをしてから、データのコピーが完了して広告ウィンドウの拡大を通知し、新規のパケットを受信するまでの時間を表している。これらの時間が一致するタイミングでタスクスイッチを実行することで、受信側ホスト１２は送信側ホスト１１から絶え間なくパケットを受信することが可能になる。そのため、式（２）が成り立つ時間をｔとしたときに、「ｔ×データ受信速度」で得られるソケットバッファの空き容量を閾値として使用すればよい。
なお、ネットワーク１３の混雑状況やアプリケーション処理に要する時間などによって、式（２）は必ずしも正確にタスクスイッチの最適なタイミングとはならない。そのため、定数項をαとしたとき、「（ｔ＋α）×データ受信速度」で得られる値を閾値として使用してもよい。これによって、プロトコルスタックタスク２１が連続して受信処理を実行しつつ、適切なタイミングでアプリケーションタスク２２にタスクスイッチすることを可能にすることができる。
【００３０】
（アプリケーション処理）
次に図５のフローチャート図を用いて、アプリケーション処理部３３の動作（アプリケーション処理）を説明する。
まずＳ５０１において、アプリケーション処理部３３は、データコピー処理部３３ａを用いて、ソケットバッファ部３４ｂからアプリケーションバッファ部３３ｂにデータをコピーする。
その後、Ｓ５０２において、アプリケーション処理部３３は、データ処理部３３ｃを用いて、必要に応じてデータにアプリケーション処理を実行する。つまり、各アプリケーションが、Ｓ５０１でコピーしたデータに対してアプリケーション処理を実行する。
【００３１】
そして、Ｓ５０３において、アプリケーション処理部３３は、アプリケーションが継続して送信側ホスト１１からデータを受信するかどうかの判定を行う。ここで継続して受信するデータが無ければ（Ｓ５０３：Ｎ）、アプリケーションタスク処理を終了する。継続して受信するデータがあれば、Ｓ５０４に進む。
Ｓ５０４において、アプリケーション処理部３３は、アプリケーションタスク２２の処理優先度が、プロトコルスタックタスク２１の処理優先度より高くなっているかを判定する。アプリケーションタスク２２の処理優先度が高くなっていない場合は、Ｓ５０５に進み、処理を実行するタスクを、アプリケーションタスク２２からプロトコルスタックタスク２１に移す。図５では、このことを「プロトコルスタックタスク２１にスイッチする」と記してある。プロトコルスタックタスク２１にスイッチすると、図４のフローチャート（プロトコルスタックタスク処理）に移る。なお、図４においてアプリケーションタスクにタスクスイッチする場合があるので、図５において、Ｓ５０５から上に延びる矢印はＳ５０１に到達するように描かれている。
【００３２】
Ｓ５０４において、アプリケーションタスク２２の処理優先度が、プロトコルスタックタスク２１の処理優先度より高くなっている場合（Ｓ５０４：Ｙ）、Ｓ５０６に進む。Ｓ５０４の判定がＹの場合とは、例えば、アプリケーションタスク２２の処理優先度を高くする処理（Ｓ４０５）を実行した後に、アプリケーションタスク２２の処理を開始していた場合である。
Ｓ５０６において、アプリケーション処理部３３は、アプリケーションタスク２２の処理優先度をプロトコルタスク２１の処理優先度より低くなるように処理優先度の設定を戻す。その後、Ｓ５０５に進み、処理を実行するタスクを、アプリケーションタスク２２からプロトコルスタックタスク２１に移す。
【００３３】
Ｓ５０５の後、再度プロトコルスタック処理部３２が動作し始めると、トランスポートレイヤプロトコル処理部３７で処理を実行するＴＣＰは、ソケットバッファ部３４ｂ内のデータがアプリケーションバッファ部にコピーされたことを確認する。当該確認の後、受信側ホスト１２は、送信側ホスト１１に広告ウィンドウサイズの拡大を通知する為の確認応答を送信する。
なお、ネットワークインタフェース部３１、プロトコルスタック処理部３２およアプリケーション処理部３３の処理は、後述する受信側ホスト１２の記憶部４１（図８）に記憶されたプログラムを制御部４２（図８）が読み出して実行することにより実現される。
【００３４】
（実施形態１の効果）
本実施形態では、ソケットバッファ部３４ｂの空き容量がゼロになる前に、ソケットバッファ部３４ｂに格納されたデータの量に応じて、アプリケーションタスク２２の処理優先度を上げ、アプリケーションタスク２２を起動している。この起動により、ソケットバッファ部３４ｂのデータをアプリケーションバッファ部３３ｂにコピーし（移動し）、ソケットバッファ部３４ｂの空き容量（データ格納容量）を増大する。ソケットバッファ部３４ｂの空き容量がゼロになる前にソケットバッファ部３４ｂのデータ格納容量の増大が送信側ホスト１１に通知されることにより、送信側ホスト１１はデータを受信側ホスト１２に滞りなく送信することができる。よって、受信側ホスト１２は、通信速度の低下を生じさせることなく、送信側ホスト１１からのデータを受信することができる。
このように、本実施形態では、ソケットバッファ部３４ｂに格納されたデータの量に基づいて（より詳しくは、ソケットバッファ部のデータ格納余裕度に基づいて）、受信側ホスト１２がアプリケーション処理部３３の処理を優先させる。その結果、送信側ホスト１１は効率的なデータ送信が可能になり、受信側ホストは効率的なデータ受信が可能になる。
実施形態１は、特に、アプリケーション処理に多くの時間を必要とする場合や、高速なデータ送信を必要するアプリケーションを使用する場合に有用である。
【００３５】
（変形例）
なお、Ｓ４０４の閾値として、ソケットバッファ部３４ｂに格納可能な最大データ量の７０％の値を設定するとしたが、送信側ホスト１１が滞りなくパケットを受信側ホスト１２に送信できるのであれば、７０％以外の数値でもよい。
送信側ホスト１１と受信側ホスト１２の接続は、無線でも有線でもよい。
実施形態１（図３）では、トランスポートレイヤ処理部３７に、ＲＴＴ計測部３７ａと、データ受信速度計測部３７ｂを設けたが、本発明はこのような構成に限定されない。例えば、閾値の設定にＲＴＴを用いない場合には、ＲＴＴ計測部３７ａを設けなくてもよいし、閾値の設定にデータ受信速度を用いない場合には、データ受信速度計測部３７ｂを設けなくてもよい。
【００３６】
実施形態１においてアプリケーションタスク２２やソケットバッファ部３４ｂは複数設けられているが、アプリケーションタスク２２やソケットバッファ部３４ｂの数は１つでもよい。
図３に示す機能ブロックの少なくとも一部をハードウェアにより実現してもよい。ハードウェアにより実現する場合、例えば、所定のコンパイラを用いることで、各ステップを実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。また、ＦＰＧＡと同様にしてＧａｔｅ  Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣにより実現するようにしてもよい。ＦＰＧＡは、Ｆｉｅｌｄ―Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙの略である。ＡＳＩＣは、Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔの略である。
【００３７】
実施形態２
実施形態１では、受信側ホスト１２で動作するアプリケーションの内容にかかわらず、ソケットバッファ部３４ｂに格納されたデータの量が閾値より大きい場合には（図４のＳ４０４の判定がＹ）、処理優先度の変更を行った（Ｓ４０５）。実施形態２では、受信側ホスト１２が、動作するアプリケーションの内容に基づいてアプリケーションごとに、アプリケーションタスク２２の処理を優先するか否かを設定する。以下、図６および図７のフローチャートを用いて、実施形態２のプロトコルスタックタスク処理とアプリケーションタスク処理を説明する。
なお、以下の説明において、実施形態１と同じ構成については、同じ参照符号を用いる。また、実施形態１と同じ動作については詳細な説明は省略し、実施形態１との相違点を中心に説明する。図１の通信システム１０、図２の受信側ホスト１２のタスク構成および図３の受信側ホスト１２の機能ブロックの構成は、実施形態２においても使用する。
【００３８】
実施形態２で用いるアプリケーションの少なくとも１つ（例えば、図２の左から２番目のアプリケーションタスク２２における処理）は、アプリケーション処理に多くの時間を要したり、高速なデータ送信を必要としないものであるとする。このようなアプリケーションタスク２２で処理を実行する場合、タスク優先度（処理優先度）を変更させない方が高効率でアプリケーション処理を実行できる場合がある。したがって、このようなアプリケーションタスク２２を使用する場合、受信側ホスト１２の処理の開始時に、アプリケーションタスク２２の処理優先度をプロトコルスタックタスク２１の処理優先度より高くしないという制御（設定）をする。以下に、この制御を図６に基づいて説明する。
【００３９】
図６は、アプリケーションタスク２２の処理を実行するアプリケーション処理部３３の動作例を表すフローチャートである。
Ｓ６０１において、アプリケーションタスク２２の処理優先度をプロトコルスタックタスク２１の処理優先度より高くしないという設定をするために、アプリケーション処理部３３に関連付けられたフラグをセット（設定）する。このフラグは、アプリケーション処理部３３ごとに設定してもよいし、アプリケーション処理部３３が生成したソケットごとに設定してもよい。ソケットごとにフラグをセットする場合は、そのソケットからのデータ受信を待機しているアプリケーションタスク２２の処理優先度を高くするかの判断を行うことになる。
【００４０】
Ｓ６０１でフラグをセットすることにより、このアプリケーションタスク２２はプロトコルスタックタスク２１よりも優先して処理が行われない。フラグのセットは、例えば、受信側ホスト１２の管理者または使用者が、当該アプリケーションタスク２２の処理の内容に基づいて実施する。つまり、どのアプリケーションタスク２２にフラグをセットするかは、受信側ホスト１２の管理者等が選択する。
Ｓ６０１でフラグをセットした後、Ｓ６０２からＳ６０４の処理・判定を行う。Ｓ６０２からＳ６０４の処理・判定は図５のＳ５０１からＳ５０３と同じであるので、説明を省略する。
継続して送信側ホスト１１からのデータを受信する場合（Ｓ６０４：Ｙ）、アプリケーションタスクの処理優先度の変更の確認をせずに（つまり、図５のＳ５０４のようなステップを経由することなく）、Ｓ６０５に進む。Ｓ６０５は、図５のＳ５０５と同じであるので、説明を省略する。
【００４１】
図７はアプリケーションタスク２２の処理を優先して行わないためのフラグを識別可能なプロトコルスタック処理部３２の処理を表すフローチャートである。
このプロトコルスタック処理部３２で行われるＳ７０１からＳ７０４の処理は、実施形態１（図４）のＳ４０１からＳ４０４の処理と同様である。
Ｓ７０４の判定がＹである場合、本実施形態では、Ｓ７０５に進む。以下に、Ｓ７０４において、ソケットバッファ部３４ｂに格納されたデータの量が、閾値よりも大きいと判断された場合の処理について説明する。
プロトコルスタックタスク２１よりも上位層で動作するアプリケーションタスク２２の処理は、異なる複数のアプリケーション毎にタスクを生成して実行される可能性がある。そのため、本実施形態では、プロトコルスタックタスク２１で処理（取得）したデータを渡すアプリケーションタスク２２が処理優先度を高くしてよいタスクなのかを、アプリケーション処理部３３に関連付けられたフラグを確認して判定する（Ｓ７０５）。
【００４２】
フラグがセットされていなければ（Ｓ７０５：Ｙ）、実施形態１と同様に、アプリケーションタスク２２の処理優先度がプロトコルスタックタスク２１の処理優先度よりも高くなるように設定する（Ｓ７０６）。Ｓ７０６の後、Ｓ７０７に進む。
フラグがセットされていた場合（Ｓ７０５：Ｎ）、アプリケーションタスク２２の処理優先度をプロトコルスタックタスク２１の処理優先度よりも低く設定したままにし、継続してプロトコル処理部３２の動作を続ける。Ｓ７０５の判定がＮの場合も、Ｓ７０７に進む。
Ｓ７０７からＳ７０９の処理は実施形態１のＳ４０６からＳ４０８と同様であるため、説明を省略する。
【００４３】
（実施形態２の効果）
以上のように、実施形態２では、各アプリケーションタスク２２の内容に応じて、処理優先度を高くするか否かを選択できるようにした。処理優先度を高くすべき内容のアプリケーションタスク２２については（Ｓ７０５：Ｙ）、実施形態１と同様な制御を行う。処理優先度を高くすべきではない内容のアプリケーションタスク２２については（Ｓ７０５：Ｎ）、アプリケーションの処理優先度を低く保つことができる。アプリケーションの処理優先度を低く保つことにより、アプリケーションの動作がプロトコルスタック処理部３２の動作を妨げなくなり、受信側ホスト１２の動作が効率良く実施される。
【００４４】
（受信側ホスト１２のハードウェア構成）
図８は受信側ホスト１２のハードウェア構成の例を示す。図８は実施形態１と実施形態２に共通して用いられるハードウェア構成を示している。
図８に示されているように、受信側ホスト１２は、記憶部４１と制御部４２と通信部４３と操作部４４と表示部４５を有する。受信側ホスト１２の各構成部（４１〜４５）は、バス４６により相互接続されている。
記憶部４１は、ＲＯＭやＲＡＭなどのメモリにより構成される。記憶部４１は、受信側ホスト１２の各種動作を行うためのプログラムや通信パラメータ等の各種情報を記憶する。なお、記憶部４１として、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体を用いてもよい。
【００４５】
制御部４２は、ＣＰＵまたはＭＰＵにより構成される。制御部４２は、記憶部４１に記憶されたプログラムを実行することにより、受信側ホスト１２全体を制御する。なお、制御部４２が実行しているＯＳと協働することにより受信側ホスト１２全体を制御するようにしてもよい。ＣＰＵはＣｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔの略である。ＭＰＵはＭｉｃｒｏ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔの略である。ＯＳはＯｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍの略である。
通信部４３は、ネットワーク１３を介して送信側ホスト１１と通信する。通信部４３は、無線通信と有線通信のいずれも行うことができるものとする。なお、通信部４３は、必要に応じて、無線通信のみ、または、有線通信のみを行う構造のものでもよい。
【００４６】
操作部４４は、受信側ホスト１２の管理者や使用者からの各種操作を受け入れる。例えば、図６のＳ６０１のフラグのセットは、操作部４４を用いて行う。操作部４４は、例えば、キーボードやマウスやタッチパネルなどから構成される。音声により管理者等からの操作を受け入れる場合には、操作部４４は音声入力部や音声解析部を含む。
表示部４５は、各種情報を表示する。表示部４５は、各種情報を表示するために、例えば、液晶ディスプレイを含む。なお、表示部４５は、表示機能以外の出力機能を備えてもよい。例えば、表示部４５は、スピーカによる音声出力機能、振動素子による振動出力機能および発光素子による発光出力機能の少なくとも１つの出力機能を備えてもよい。
【００４７】
（他の実施形態）
本発明は、上記した実施形態の１以上の機能を実現するプログラム（コンピュータプログラム）を、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（たとえば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００４８】
１０…通信システム、１１…送信側ホスト、１２…受信側ホスト、１３…ネットワーク、３２…プロトコルスタック処理部、３３…アプリケーション処理部、３４…パケットバッファ部、３４ｂ…ソケットバッファ部
【図１】
2018093330.tif 000003
【図２】
2018093330.tif 000004
【図３】
2018093330.tif 000005
【図４】
2018093330.tif 000006
【図５】
2018093330.tif 000007
【図６】
2018093330.tif 000008
【図７】
2018093330.tif 000009
【図８】
2018093330.tif 000010