受信データ処理方法、通信装置、及びプログラム
【課題】受信データのバッファリングによる応答性の低下を低減させること。
【解決手段】通信装置が、受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する。
【解決手段】通信装置が、受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、受信データ処理方法、通信装置、及びプログラムに関する。
【背景技術】
【0002】
従来、TCP(Transmission Control Protocol)に代表されるバイトストリーム型(バイト指向)の通信プロトコルを使用した通信において、通信プロトコルに応じた処理制御を行うプロトコル制御部は、受信したデータを即座に上位アプリケーションに渡していた。
【0003】
図1は、受信データが即座に上位アプリケーションに渡される例を示す図である。図1では、送信装置520において、送信データがデータ1及びデータ2の二つのデータに分割されて受信装置510の上位アプリケーション宛に送信される例が示されている。
【0004】
プロトコル制御部が受信データを即座に上位アプリケーションに渡す場合、プロトコル制御部と上位アプリケーションとの間での受信データの受け渡しは頻発する。したがって、受信データの受け渡しに要される処理のオーバーヘッドや、上位アプリケーション側での受信データの組み立て処理等によって処理効率が低下し、CPU負荷が高まるという問題がある。
【0005】
近年のコンピュータシステムにおいては、ネットワークの劇的な高速化に比べてCPU性能の向上が相対的に小さくなっている。したがって、ネットワーク通信のデータ量の増加に伴う、CPU使用量の削減が求められている。
【0006】
なお、バイトストリーム型の通信プロトコルとは、通信対象のデータを単なるバイトの列として扱う通信プロトコルをいう。バイトストリーム型の通信プロトコルでは、上位アプリケーションにとって意味の有る単位の区切りとは無関係に、データが分割又は結合されて送受信が行われる。したがって、上位アプリケーションは、プロトコル制御部より渡されたデータに関して、意味の有る単位に組み立てたり分割したりする必要がある。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特表2002−527945号公報
【特許文献2】特開2005−143098号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
プロトコル制御部が、データをバッファリングして、複数のデータをまとめて上位アプリケーションに渡すことにより、処理効率の向上を図ることができる。従来、最初のデータがバッファリングされてから一定時間経過後、又は一定データ長のデータがバッファリングされたときに、それまでにバッファリングされているデータがまとめて上位アプリケーションに渡されていた。
【0009】
図2は、最初のデータがバッファリングされてから一定時間経過後に受信データが上位アプリケーションに渡される例を示す図である。図2において、プロトコル制御部は、受信されたデータを直ちに上位アプリケーションには渡さず、バッファに記憶する。最初のデータが受信されてから一定時間tが経過すると、プロトコル制御部は、バッファに記憶されているデータをまとめて上位アプリケーションに渡す。
【0010】
しかしながら、上記のようなバッファリングでは、上位アプリケーションへの通知が遅延する結果、応答性が損なわれる場合がある。応答性とは、データが受信されてから、当該データが上位アプリケーションへ通知され、上位アプリケーションが当該データの処理を完了するまでの時間の短さのことをいう。データが受信されてから、上位アプリケーションへの通知が完了するまでの時間が短いほど、応答性は向上する。一般に、応答性が高いほどスループット(受信装置510の単位時間当たりの受信データの処理量)は向上する。
【0011】
例えば、図2に示した例では、データ2が受信された時点で上位アプリケーションにデータ1及び2が通知されるのが効率的であるが、データ1のバッファリング時から一定時間が経過するまで、データ1及びデータ2の通知は遅延する。なお、バイトストリーム型の通信プロトコルでは、受信データが最後の受信データであるか否かをプロトコル制御部が判断することはできない。したがって、データ2の後続データが無い場合であっても、一定時間の待機は行われる。
【0012】
一定時間の待機が行われる結果、プロトコル制御部のバッファに受信データが溜まり、データ通信のフロー制御に影響したり、バッファ枯渇が発生したりする可能性も有る。
【0013】
そこで、一側面では、受信データのバッファリングによる応答性の低下を低減させることのできる受信データ処理方法、通信装置、及びプログラムの提供を目的とする。
【課題を解決するための手段】
【0014】
一つの案では、通信装置が、受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する。
【発明の効果】
【0015】
一態様によれば、受信データのバッファリングによる応答性の低下を低減させることができる。
【図面の簡単な説明】
【0016】
【図1】受信データが即座に上位アプリケーションに渡される例を示す図である。
【図2】最初のデータがバッファリングされてから一定時間経過後に受信データが上位アプリケーションに渡される例を示す図である。
【図3】本発明の実施の形態における通信システムの構成例を示す図である。
【図4】本発明の実施の形態における受信装置のハードウェア構成例を示す図である。
【図5】本発明の実施の形態における受信装置の機能構成例を示す図である。
【図6】第一の実施の形態の受信装置が実行する処理手順の第一の例を説明するための図である。
【図7】処理待ちキュー及び受信バッファの状態の第一の例を示す図である。
【図8】処理待ちキュー及び受信バッファの状態の第二の例を示す図である。
【図9】処理待ちキュー及び受信バッファの状態の第三の例を示す図である。
【図10】処理待ちキュー及び受信バッファの状態の第四の例を示す図である。
【図11】第一の実施の形態の受信装置が実行する処理手順の第二の例を説明するための図である。
【図12】処理待ちキュー及び受信バッファの状態の第五の例を示す図である。
【図13】処理待ちキュー及び受信バッファの状態の第六の例を示す図である。
【図14】第一の実施の形態における受信セグメントの処理要求の受け付け時の処理手順の一例を説明するためのフローチャートである。
【図15】第一の実施の形態の処理待ちキューに記憶される処理要求の構成例を示す図である。
【図16】プロトコル処理前の受信セグメントの構成例を示す図である。
【図17】第一の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。
【図18】第一の実施の形態の受信バッファの構成例を示す図である。
【図19】第二の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。
【図20】第二の実施の形態の受信バッファの構成例を示す図である。
【図21】保留終了処理要求を処理しないで最後尾に移動させる例を示す図である。
【図22】第三の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。
【発明を実施するための形態】
【0017】
以下、図面に基づいて本発明の実施の形態を説明する。図3は、本発明の実施の形態における通信システムの構成例を示す図である。図3において、送信装置20と受信装置10とは、LAN(Local Area Network)又はインターネット等のネットワークを介して通信可能とされている。なお、ネットワークの一部又は全部において、無線通信が利用されてもよい。
【0018】
送信装置20は、受信装置10に対してデータを送信する情報処理装置である。受信装置10は、送信装置20より送信されるデータを受信する情報処理装置である。本実施の形態において、送信装置20と受信装置10との間のデータ通信には、バイトストリーム型(バイト指向)の通信プロトコルの一例として、TCP(Transmission Control Protocol)が利用される。但し、TCP以外のバイトストリーム型の通信プロトコルが利用されてもよい。
【0019】
したがって、送信装置20から受信装置10へ送信されるデータは、セグメント単位に分割されて送信される。セグメントとは、送信用に分割されたデータをいい、セグメントごとにIPヘッダ及びTCPヘッダ等が付与される。なお、送信データが一つのセグメントに収まる場合は、当該送信データは、分割されずに一つのセグメントとされる。
【0020】
なお、送信装置20及び受信装置10という名称は、便宜的なものに過ぎない。すなわち、通信手順の進行に応じて、送信装置20がデータの受信側になってもよいし、受信装置10がデータの送信側になってもよい。
【0021】
図4は、本発明の実施の形態における受信装置のハードウェア構成例を示す図である。図4の受信装置10は、それぞれバスBで相互に接続されているドライブ装置100、補助記憶装置102、メモリ装置103、CPU104、及びインタフェース装置105等を有する。
【0022】
受信装置10での処理を実現するプログラムは、記録媒体101によって提供される。プログラムを記録した記録媒体101がドライブ装置100にセットされると、プログラムが記録媒体101からドライブ装置100を介して補助記憶装置102にインストールされる。但し、プログラムのインストールは必ずしも記録媒体101より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置102は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【0023】
メモリ装置103は、プログラムの起動指示があった場合に、補助記憶装置102からプログラムを読み出して格納する。CPU104は、メモリ装置103に格納されたプログラムに従って受信装置10に係る機能を実行する。インタフェース装置105は、例えば、ネットワークカードであり、ネットワークに接続するためのインタフェースとして用いられる。
【0024】
なお、記録媒体101の一例としては、CD−ROM、DVDディスク、又はUSBメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置102の一例としては、HDD(Hard Disk Drive)又はフラッシュメモリ等が挙げられる。記録媒体101及び補助記憶装置102のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。
【0025】
なお、送信装置20も、例えば、図4に示されるハードウェアを有している。
【0026】
図5は、本発明の実施の形態における受信装置の機能構成例を示す図である。図5において、受信装置10は、入出力制御部11、プロトコル制御部12、及び一以上のアプリケーション13等を有する。
【0027】
入出力制御部11は、インタフェース装置105によって受信される受信データを、インタフェース装置105より読み出す。入出力制御部11は、読み出したデータに関する処理要求を、セグメント単位でプロトコル制御部12に入力する。なお、受信データは、入出力制御部11によって読み出されるまで、インタフェース装置105のメモリ内に滞留する。入出力制御部11は、例えば、受信装置10にインストールされた、インタフェース装置105に対応したデバイスドライバとしてのプログラムがCPU104に実行させる処理によって実現される。以下、セグメント単位の受信データを、「受信セグメント」という。
【0028】
プロトコル制御部12は、入出力制御部11からの処理要求に応じ、当該処理要求に係る受信セグメントに関して、通信プロトコル(TCP)に従った処理を実行する。以下、通信プロトコルに従った処理を「プロトコル処理」という。プロトコル処理の一例として、IPヘッダの解析処理及びTCPヘッダの解析処理等が挙げられる。プロトコル処理によって、例えば、宛先(コネクション)の識別、改竄の有無のチェック、及び受信順序の正否等が判定される。宛先は、IPヘッダに含まれているIPアドレスと、TCPヘッダに含まれているポート番号とによって識別される。なお、本実施の形態では、一つのアプリケーション13は、一つのコネクションを有することとする。すなわち、宛先が識別されることによって、受信セグメントの通知先(又は伝達先)のアプリケーション13が特定されることになる。改竄の有無のチェックは、IPチェックサム及びTCPチェックサム等を用いて行われる。受信順序の正否は、シーケンス番号及びACK番号等に基づいて判定される。
【0029】
プロトコル制御部12は、処理待ちキュー14及び受信バッファ15等の記憶部を利用する。処理待ちキュー14は、入出力制御部11からの処理要求の待ち行列をFIFO(First-In First-Out)形式で記憶する記憶部である。受信バッファ15は、処理待ちキュー14に記憶された処理要求に係る受信セグメントのうち、プロトコル処理が実行された受信セグメントを記憶する記憶部である。処理待ちキュー14は、複数の宛先(コネクション)に対して共通であるのに対し、受信バッファ15は、宛先(コネクション)ごとに形成される。受信バッファ15に記憶された受信セグメントは、所定のタイミングで、当該受信バッファ15に係る宛先のアプリケーション13に通知(又は伝達)される。処理待ちキュー14及び受信バッファ15は、例えば、メモリ装置103を用いて実現可能である。
【0030】
なお、プロトコル制御部12は、受信装置10にインストールされたプログラムがCPU104に実行させる処理によって実現される。
【0031】
アプリケーション13は、本実施の形態において、送信装置20より送信されるデータの宛先となるプログラムである。アプリケーション13は、例えば、受信データを利用して、所定の処理を実行する。
【0032】
以下、受信装置10が実行する処理手順について説明する。図6は、第一の実施の形態の受信装置が実行する処理手順の第一の例を説明するための図である。
【0033】
インタフェース装置105においてデータが受信されると、入出力制御部11は、インタフェース装置105に対して読み出し要求(READ要求)を発行し、受信データをインタフェース装置105より読み出す(S101)。ここでは、二つのセグメントが受信されていることとする。したがって、二つの受信セグメントが読み出される。通常、Nセグメント分のデータが送信装置20より送信された場合、Nセグメント以下の複数セグメントがまとめて受信される。ここで、Nは2以上である。
【0034】
続いて、入出力制御部11は、各受信セグメントの処理要求を、受信セグメントの受信順(読み出し順)にプロトコル制御部12に入力する(S102)。入力された処理要求は、プロトコル制御部12の処理待ちキュー14に登録される。ステップS102の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図7に示されるような状態になる。
【0035】
図7は、処理待ちキュー及び受信バッファの状態の第一の例を示す図である。図7において、処理待ちキュー14には、1番目の受信セグメント(受信セグメント1)の処理要求と、2番目の受信セグメント(受信セグメント2)の処理要求との待ち行列が記憶されている。一方、受信バッファ15は空の状態である。
【0036】
続いて、プロトコル制御部12は、処理待ちキュー14の先頭の処理要求である、受信セグメント1の処理要求を取得し、当該処理要求に応じて受信セグメント1に関してプロトコル処理を実行する(S103)。なお、取得された処理要求は、処理待ちキュー14より削除される。
【0037】
続いて、プロトコル制御部12は、プロトコル処理が行われた受信セグメント1を、受信セグメント1の宛先に対応する受信バッファ15に記憶する(S104)。受信セグメント1を記憶する前において、受信バッファ15は空である。そこで、プロトコル制御部12は、処理待ちキュー14に対して、保留終了処理要求を追加する(S105)。保留終了処理要求とは、受信バッファ15における受信セグメントのバッファリング(保留)の終了の要求である。受信バッファ15における受信セグメントのバッファリングの終了は、受信バッファ15のクリア、すなわち、受信バッファ15に記憶されている全ての受信セグメントを、宛先のアプリケーション13に通知することを意味する。
【0038】
ステップS105の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図8に示されるような状態になる。
【0039】
図8は、処理待ちキュー及び受信バッファの状態の第二の例を示す図である。図8において、既に処理された受信セグメント1の処理要求は処理待ちキュー14より削除され、受信セグメント1は受信バッファ15に記憶されている。また、保留終了処理要求が、処理待ちキュー14における処理要求の待ち行列の最後尾に追加されている。
【0040】
続いて、プロトコル制御部12は、現時点において処理待ちキュー14の先頭の処理要求である受信セグメント2の処理要求を取得し、当該処理要求に応じて受信セグメント2に関してプロトコル処理を実行する(S106)。続いて、プロトコル制御部12は、プロトコル処理が行われた受信セグメント2を、受信セグメント2の宛先に対応する受信バッファ15に記憶する(S107)。受信セグメント2の宛先は、受信セグメント1と同じであるとする。したがって、受信セグメント2は、受信セグメント1と同じ受信バッファ15に記憶される。したがって、受信セグメント2を記憶する前において、受信バッファ15は空ではない。すなわち、受信バッファ15には受信セグメント1が記憶されている。したがって、プロトコル制御部12は、処理待ちキュー14に対して、保留終了処理要求は追加しない。
【0041】
ステップS107の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図9に示されるような状態になる。
【0042】
図9は、処理待ちキュー及び受信バッファの状態の第三の例を示す図である。図8において、既に処理された受信セグメント2の処理要求は処理待ちキュー14より削除され、受信セグメント2は、受信セグメント1と共に受信バッファ15に記憶されている。
【0043】
続いて、プロトコル制御部12は、現時点において処理待ちキュー14の先頭の処理要求である保留終了処理要求を処理対象とする。処理対象が保留終了処理要求であることに応じ、プロトコル制御部12は、受信バッファ15に記憶されている全ての受信セグメントを、当該受信バッファ15に対応する宛先であるアプリケーション13にまとめて通知する(S108)。
【0044】
ステップS107の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図10に示されるような状態になる。
【0045】
図10は、処理待ちキュー及び受信バッファの状態の第四の例を示す図である。図10において、処理待ちキュー14及び受信バッファ15は、共に空の状態となっている。
【0046】
図6に示される処理によれば、受信セグメント1及び受信セグメント2をまとめた受信データに関して、待ち時間が発生することなくまとめてアプリケーション13に通知することができる。また、アプリケーション13への通知はバッファリングされた全ての受信セグメントに関してまとめて実行されるため、アプリケーション13とプロトコル制御部12との間のデータの受け渡しの回数を低減させることができる。その結果、バッファリングによる応答性の低下を低減させることができ、また、CPU104の負荷の増加を抑制することができる。更に、待ち時間のタイマの設定が不要となる点においても、CPU104の負荷の増加を抑制することができる。
【0047】
なお、上記では、便宜上、二つの受信セグメントがまとめてアプリケーション13に通知される例を示したが、通常は、更に多くの受信セグメントの処理要求がまとめて処理待ちキュー14に記憶される可能性が高い。特に、入出力制御部11においてもバッファリングが行われる場合は、処理待ちキュー14に記憶される受信セグメント数が複数になる可能性が高い。このことは、複数の受信セグメントごとに、保留終了処理要求が処理待ちキュー14に追加される可能性が高いことを意味する。処理待ちキュー14にまとめて記憶される処理要求が多くなればなるほど、保留終了処理要求に基づく処理の効率化の効果が大きくなる。
【0048】
但し、ネットワーク負荷の状態によっては、複数のセグメントがまとめて受信されない場合も考えられる。そこで、受信セグメント2の転送に遅延が発生した場合の処理手順について説明する。
【0049】
図11は、第一の実施の形態の受信装置が実行する処理手順の第二の例を説明するための図である。
【0050】
ステップS111において、入出力制御部11は、インタフェース装置105において受信されている受信セグメント1を読み出す(S111)。続いて、入出力制御部11は、受信セグメント1の処理要求を、プロトコル制御部12に入力する(S112)。ステップS112の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図12に示されるような状態になる。
【0051】
図12は、処理待ちキュー及び受信バッファの状態の第五の例を示す図である。図12において、処理待ちキュー14には、受信セグメントの処理要求のみが記憶されている。なお、受信バッファ15は空の状態である。
【0052】
続いて、プロトコル制御部12は、処理待ちキュー14の先頭の処理要求である受信セグメント1の処理要求を取得し、当該処理要求に応じて受信セグメント1に関してプロトコル処理を実行する(S113)。続いて、プロトコル制御部12は、プロトコル処理が行われた受信セグメント1を、受信セグメント1の宛先に対応する受信バッファ15に記憶する(S114)。受信セグメント1を記憶する前において、受信バッファ15は空である。そこで、プロトコル制御部12は、処理待ちキュー14に対して、保留終了処理要求を追加する(S115)。
【0053】
ステップS115の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図13に示されるような状態になる。
【0054】
図13は、処理待ちキュー及び受信バッファの状態の第六の例を示す図である。図13において、既に処理された受信セグメント1の処理要求は処理待ちキュー14より削除され、受信セグメント1は受信バッファ15に記憶されている。また、保留終了処理要求が、処理待ちキュー14に追加されている。
【0055】
続いて、プロトコル制御部12は、現時点において処理待ちキュー14の先頭の処理要求である保留終了処理要求を処理対象とする。処理対象が保留終了処理要求であることに応じ、プロトコル制御部12は、受信バッファ15に記憶されている受信セグメント1を受信セグメント1の宛先であるアプリケーション13に通知する(S116)。
【0056】
その後、受信セグメント2が受信されると、入出力制御部11は、受信セグメント2をインタフェース装置105より読み出す(S117)。続いて、入出力制御部11は、受信セグメント2の処理要求を、プロトコル制御部12に入力する(S118)。したがって、受信セグメント2の処理要求が処理待ちキュー14に記憶される。
【0057】
続いて、プロトコル制御部12は、処理待ちキュー14の先頭の処理要求である受信セグメント2の処理要求を取得し、当該処理要求に応じて受信セグメント2に関してプロトコル処理を実行する(S119)。ここで、プロトコル制御部12は、受信セグメント2のセグメント長に基づいて、後続のセグメントは無いと判定した場合、受信セグメント2を受信バッファ15に記憶することなく、即座に宛先のアプリケーション13に通知する(S120)。そのため、バッファリングによる待ちが発生しないことに加えて、バッファリングによるオーバーヘッドも削減できる。後続のセグメントとは、既に受信されている受信セグメントと同一のデータに含まれるセグメントであって、送信装置20から既に送信済みであり、ネットワーク中において転送中であるセグメントや、これから送信装置20により送信されるセグメント等をいう。「同一のデータ」とは、アプリケーション13にとって意味のあるデータの区切り間のデータをいう。
【0058】
なお、セグメント長に基づく後続のセグメントの有無の判定は、図11の受信セグメント1に関しても行われる。但し、受信セグメント1については、後続のセグメントは無いと推定きなかった場合であるとする。したがって、受信セグメント1は、受信バッファ15に記憶される。
【0059】
図11のように、受信セグメント間に遅延が発生する場合は、受信セグメントごとに保留終了処理要求が処理待ちキュー14に追加され、受信セグメントごとにアプリケーション13への通知が行われることになる。したがって、バッファリングによる待ち時間の発生は回避できるが、アプリケーション13とプロトコル制御部12とのデータの受け渡しは頻発する。但し、本実施の形態では、受信セグメントの受け渡しによる負荷の増加よりも、受信セグメントを即時的に受け渡すことによる応答性の向上の方が重要であると考える。また、処理が遅延しているため、受け渡し処理が頻発による付加の増加は、遅延してない場合に比べて非常に小さいと考えられる。
【0060】
ステップS120において説明したように、本実施の形態において、プロトコル制御部12は、処理対象のセグメントのセグメント長に基づいて後続セグメントの有無の判定を行う。これにより、バッファリングの必要がない場合、例えば、複数セグメントではなく1セグメントに収まるデータが受信された場合等において、バッファリングによるオーバーヘッドの発生を回避することができる。
【0061】
セグメント長に基づく後続セグメントの有無の判定方法の一例について説明する。
【0062】
多くのTCP/IPの実装系では、セグメントが伝送路で分割されないように、MSS(Maximum Segment Size:最大セグメントサイズ)が設定される。MSSは、伝送路に流すことのできる最大データ長を示すMTU(Maximum Transmission Unit)からIPヘッダサイズ及びTCPヘッダサイズを引いた値である。送信装置20は、MSSを超えるデータを送信しようとすると、MSSごとのセグメントに分割し、各セグメントを伝送路に送信する。受信装置10では分割されたセグメントをそのまま受信するため、受信セグメントのサイズ(セグメント長)がMSSと等しければ、後続セグメントが存在する可能性は高いと考えられる。そこで、受信セグメントのセグメント長がMSSと等しい場合、プロトコル制御部12は、後続セグメントは存在すると判定又は推定し、バッファリング処理を実行する。
【0063】
また、TCPの実装によっては、プロトコル処理の後、セグメント長がMSSよりも大きい受信セグメントが処理される場合がある。セグメント長がMSSよりも大きい受信セグメントの処理は、ネットワークにおいてセグメントの順序が逆転したり、セグメントが消失して再送が行われたりしたときに、受信装置10のTCPの順序制御により複数セグメントがまとめて処理された場合に行われる。したがって、セグメント長がMSSよりも大きい受信セグメントが処理される場合も後続セグメントが存在する可能性が有る。そこで、プロトコル制御部12は、セグメント長がMSSより大きい受信セグメントを処理する場合も、バッファリング処理を行う。
【0064】
一方、受信セグメントのセグメント長がMSS未満である場合、送信装置20がセグメントの分割を実行しなかったデータ長であった可能性が高く、後続セグメントが存在しない可能性が高い。そこで、受信セグメントのセグメント長がMSS未満である場合、プロトコル制御部12は、後続セグメントは存在しないと判定又は推定し、バッファリング処理を実行しない。なお、送信装置20が送信したデータが最大セグメントサイズと一致する場合も有る。この場合、受信装置10では、後続セグメントが実際には存在しないにもかかわらず、後続セグメントが有ると判定される。したがって、この場合、バッファリングは行われる。但し、当該セグメントに続いて保留終了処理要求が処理待ちキュー14に追加される可能性が高い。したがって、当該セグメントは、即時的にアプリケーション13に通知される。
【0065】
なお、TCP通信において、MSSの値は、コネクション確立時(通信開始時)に受信装置10と送信装置20との間のネゴシエーションにより決定され、コネクション確立要求及びコネクション確立応答のTCPヘッダに含まれる。したがって、プロトコル制御部12は、当該TCPヘッダよりMSSを取得し、例えば、メモリ装置103に記憶しておく。
【0066】
また、タイムスタンプオプション等のTCPオプションが使用される場合、送信装置20において、MSSからTCPオプションサイズを引いた値にセグメント分割が行われる。したがって、TCPオプションが使用される場合、受信装置10における後続セグメントの有無の判定には、MSSからTCPオプションサイズを引いた値が採用される。
【0067】
ところで、TCP通信ではPSHフラグの有無に基づいて後続セグメントの有無を判定することも考えられる。PSHフラグとは、TCPヘッダに含まれるTCPフラグの一つであり、「PSHフラグ付きのTCPセグメントを受け取ったら、(バッファリングせずに)速やかに上位プロトコル(上位アプリケーション13)へ渡す」ことを意味する。TCPデータ送信時のPSHフラグの付加の方法はRFC(Request for Comments)で規定されている。PSHフラグを利用して後続セグメントの有無を判定することにより、待ち時間の少ないバッファリングが可能である。しかし、図11のように途中のセグメントの転送が遅れた場合や、送信装置20のPSHフラグの実装により、バッファリング時間が生じるといった問題点がある。また、PSHフラグは送信装置20の実装に依存する。そのため、ほとんどの実装系ではPSHフラグを利用したバッファリングは行われておらず、またPSHフラグの有無が意識されていないのが現状である。
【0068】
したがって、本実施の形態ではPSHフラグに基づく後続セグメントの有無の判定は行わない。但し、PSHフラグの基づく後続セグメントの有無の判定と、本実施の形態におけるセグメント長に基づく後続セグメントの有無の判定との双方が重複して行われてもよい。
【0069】
続いて、図6及び図11等において説明した処理手順を実現するために、プロトコル制御部12が実行する処理について詳細に説明する。
【0070】
図14は、第一の実施の形態における受信セグメントの処理要求の受け付け時の処理手順の一例を説明するためのフローチャートである。
【0071】
受信セグメントの処理要求が入出力制御部11より入力されると(S201でYes)、プロトコル制御部12は、当該処理要求を処理待ちキュー14の最後尾に追加する(S202)。
【0072】
図15は、第一の実施の形態の処理待ちキューに記憶される処理要求の構成例を示す図である。既述したように、処理待ちキュー14に記憶される処理要求には、受信セグメントの処理要求と保留終了処理要求とがある。
【0073】
受信セグメントの処理要求は、例えば、処理要求コード、次の処理要求へのポインタ、及び受信セグメントへのポインタ等を含む。処理要求コードは、処理要求の種別を識別するためのコードである。受信セグメントの処理要求については、受信セグメントの処理要求であることを示す値が処理要求コードに設定される。次の処理要求へのポインタは、処理待ちキュー14の待ち行列において、次の順番の処理要求へのポインタ(関連付け情報)である。受信セグメントへのポインタは、当該処理要求に関して処理対象とされる受信セグメントの実体へのポインタである。
【0074】
一方、保留終了処理要求は、処理要求コード、次の処理要求へのポインタ、及び受信バッファへのポインタ等を含む。処理要求コード及び次の処理要求へのポインタについては、受信セグメントの処理要求と同様である。但し、保留終了処理要求の処理要求コードには、保留終了処理要求であることを示す値が設定される。受信バッファへのポインタは、当該保留終了処理要求が対応する受信バッファ15へのポインタである。すなわち、受信バッファへのポインタは、当該保留終了処理要求が処理対象とされた際に、クリアすべき受信バッファ15へのポインタである。
【0075】
なお、ステップS202において追加されるのは、受信セグメントの処理要求である。当該処理要求を処理要求Rとし、処理要求Rが処理待ちキュー14に追加される前の最後尾の処理要求を処理要求Eとすると、処理要求Eの「次の処理要求へのポインタ」には処理要求Rのアドレスが設定される。また、処理要求Rの「次の処理要求へのポインタ」には、例えば、終端又は末尾を示すNULLが設定される。処理要求Rの「受信セグメントへのポインタ」には、入出力制御部11より受け付けた受信セグメントへのポインタが設定される。この時点において、受信セグメントは、例えば、図16に示されるような構成を有する。
【0076】
図16は、プロトコル処理前の受信セグメントの構成例を示す図である。図16に示されるように、処理待ちキュー14に記憶された時点、すなわち、プロトコル処理前の受信セグメントは、例えば、ネットワークインタフェース層ヘッダ、IPヘッダ、TCPヘッダ、及びユーザデータ等を含む。
【0077】
ネットワークインタフェース層ヘッダの形式は、使用される物理的なネットワークの種類に依存する。ユーザデータは、アプリケーション13にとって意味の有るデータである。
【0078】
続いて、処理待ちキュー14に記憶された処理要求に応じてプロトコル制御部12が実行する処理手順について説明する。図17は、第一の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。
【0079】
ステップS210において、プロトコル制御部12は、処理待ちキュー14における待ち行列の先頭の処理要求を取得する。続いて、プロトコル制御部12は、取得された処理要求の処理要求コードを参照して、取得された処理要求(以下、「対象処理要求」という。)が保留終了処理要求であるか否かを判定する(S220)。対象処理要求が保留終了処理要求である場合(S220でYes)、当該保留終了処理要求の「受信バッファへのポインタ」によって特定される受信バッファ15に記憶されている受信セグメントを、当該受信バッファ15が対応する宛先のアプリケーション13に通知する(S230)。
【0080】
一方、対象処理要求が、受信セグメントの処理要求である場合(S220でNo)、プロトコル制御部12は、対象処理要求の「受信セグメントへのポインタ」によって特定される受信セグメントに関して、プロトコル処理を実行する(S240)。プロトコル処理において、TCPオプションサイズの算出も行われる。なお、対象処理要求の「受信セグメントへのポインタ」によって特定される受信セグメントを、以下「対象セグメント」という。
【0081】
続いて、プロトコル制御部12は、対象セグメントの宛先に対応する受信バッファ15に1以上のセグメントが記憶されているか否かを判定する(S250)。当該受信バッファ15に1以上のセグメントが記憶されている場合(S250でYes)、プロトコル制御部12は、対象セグメントを当該受信バッファ15に記憶する(S260)。
【0082】
図18は、第一の実施の形態における受信バッファの構成例を示す図である。各受信バッファ15は、制御テーブルT1を含む。制御テーブルは、各種制御情報、先頭ポインタ、及び最終ポインタ等の情報を記憶する。各種制御情報は、例えば、対応する宛先(ポート番号)等、各種の制御情報である。先頭ポインタは、当該受信バッファ15において先頭の受信セグメントへのポインタである。最終ポインタは、当該受信バッファ15において末尾の受信セグメントへのポインタである。
【0083】
各受信セグメントは、次のセグメントへのポインタ、制御テーブルへのポインタ、全保留データ長、セグメント長、IPヘッダ、TCPヘッダ、及びユーザデータ等を含む。図16との比較より明らかなように、次のセグメントへのポインタ、制御テーブルへのポインタ、全保留データ長、及びセグメント長は、プロトコル処理又は受信バッファ15への記憶時において、プロトコル制御部12によって付与される情報である。
【0084】
次のセグメントへのポインタは、当該受信バッファ15において、次の受信セグメントへのポインタである。制御テーブルへのポインタは、当該受信バッファ15の制御テーブルT1へのポインタである。全保留データ長は、当該受信バッファ15に記憶されている全ての受信セグメントのセグメント長の合計である。全保留データ長は、受信バッファ15の先頭の受信セグメントに関してのみ有効であってもよい。セグメント長は、当該受信セグメントのセグメント長である。
【0085】
したがって、ステップS260では、対象セグメントの宛先に対応する受信バッファ15の制御テーブルT1の保留最終ポインタによって特定される受信セグメントの「次のセグメントへのポインタ」に、対象セグメントへのポインタが設定される。また、対象セグメントの「次のセグメントへのポインタ」には、終端又は末尾を示すNULLが設定される。また、当該制御テーブルT1の先頭ポインタによって特定される受信セグメントの「全保留データ長」に、対象セグメントのセグメント長が加算される。更に、当該制御テーブルT1の最終ポインタに、対象セグメントへのポインタが設定される。
【0086】
一方、対象セグメントの宛先に対応する受信バッファ15が空である場合(S250でNo)、プロトコル制御部12は、対象セグメントのセグメント長は、MSS以上であるか否かを判定する(S270)。なお、TCPオプションサイズが0より大きい場合は、対象セグメントのセグメント長は、(MSS−TCPオプションサイズ)と比較される。
【0087】
対象セグメントのセグメント長が、MSS以上である場合(S270でYes)、プロトコル制御部12は、対象セグメントを、対象セグメントの宛先に対応する受信バッファ15に記憶する(S280)。続いて、プロトコル制御部12は、保留終了処理要求を処理待ちキュー14の待ち行列の最後尾に追加する(S290)。当該保留終了処理要求の「受信バッファへのポインタ」には、対象セグメントの宛先に対応する受信バッファ15へのポインタが設定される。
【0088】
一方、対象セグメントのセグメント長が、MSS未満である場合(S270でNo)、プロトコル制御部12は、対象セグメントの宛先のアプリケーション13に対象セグメントを通知する(S300)。すなわち、対象セグメントは、受信バッファ15に記憶されない。
【0089】
なお、図17によれば、対象セグメントの宛先に対応する受信バッファ15に先着の受信セグメントが記憶されている場合(S250でYes)、対象セグメントに関して、MSS未満であるか否かを問わず、受信バッファ15への記憶が行われる。先着の受信セグメントが記憶されている場合に対象セグメントがMSS未満であることを理由として受信バッファ15のクリアを行ったとしても、いずれ保留終了処理要求によって受信バッファ15のクリアが行われる。したがって、先着の受信セグメントが記憶されている場合に対象セグメントがMSS未満であることを理由として受信バッファ15のクリアを行ったとしても、処理ステップの削減の効果は低いと考えられるからである。また、対象セグメントのセグメント長とMSSとを比較する必要があり、却って処理ステップの増加を招くからである。
【0090】
上述したように、第一の実施の形態によれば、受信セグメントの処理要求が処理される際に、当該受信セグメントの宛先に対応する受信バッファ15が空であれば、保留終了処理要求が処理待ちキュー14の最後尾(末尾)に追加される。保留終了処理要求が処理対象とされるまでは、各処理要求に係る受信セグメントは受信バッファ15に記憶され、保留終了処理要求が処理対象とされた時点で、当該保留終了処理要求に係る受信バッファ15内の受信セグメントはまとめて宛先のアプリケーション13に通知される。
【0091】
その結果、一定時間経過又は一定データ長のバッファリングによる応答性の低下を低減させることができる。また、プロトコル制御部12とアプリケーション13との間のセグメントの受け渡しが頻発するのを抑制することができ、当該受け渡しによるオーバーヘッドを削減することができる。
【0092】
次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。
【0093】
第一の実施の形態では、セグメント長がMSS以上である受信セグメントは、常にバッファリングされる。しかし、斯かる受信セグメントをバッファリングしたにも拘わらず、後続の受信セグメントが無かった場合、すなわち、バッファリング処理をしたにも拘わらず、複数の受信セグメントをまとめることができなかった場合、バッファリング処理が無駄となってしまう。このような状況は、例えば、図11に示されるように、ネットワークの転送速度が、受信装置10における受信セグメントの処理速度に対して遅い場合に発生しうる。
【0094】
そこで、第二の実施の形態において、プロトコル制御部12は、所定回数以上連続で、アプリケーション13に通知される受信セグメントが一つである受信バッファ15(コネクション)に関しては、バッファリング処理を一定時間実施しないようにする。一定時間経過後に、ネットワーク負荷が低下して、バッファリング処理の効果が得られるようになっていれば、プロトコル制御部12は、バッファリング処理を再開する。
【0095】
なお、斯かる処理制御は、宛先(コネクション)ごとに行われるため、通信相手の違いによる回線速度の違いに個別に対応することができる。
【0096】
以下、斯かる処理制御を実現するためにプロトコル制御部12が実行する処理について説明する。
【0097】
図19は、第二の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。図19中、図17と同一ステップには同一ステップ番号を付し、その説明は省略する。
【0098】
図19では、ステップS260の後にステップS261が実行される。ステップS261において、プロトコル制御部12は、変数Nに1を加算する。変数Nは、対象セグメントの宛先に対応する受信バッファ15に記憶されている受信セグメントの数が格納される変数である。変数Nを、以下「保留数N」という。なお、コネクションの開始時において、保留数Nの値は、0に初期化される。保留数Nは、例えば、受信バッファ15の制御テーブルT1において管理されてもよい。
【0099】
図20は、第二の実施の形態の受信バッファの構成例を示す図である。図20中、図18と同一部分については、説明を省略する。
【0100】
第二の実施の形態の制御テーブルT1aは、更に、保留数N、連続数M、及びバッファリングフラグ等を含む。保留数Nは、上記した通りである。連続数Mは、保留数Nが1である状態における受信セグメントのアプリケーション13への通知が連続した回数である。すなわち、1つの受信セグメントのみがバッファリングされている状態における受信セグメントのアプリケーション13への通知が連続して発生した回数である。連続数Mの初期値は0である。バッファリングフラグは、バッファリングを行うか否かを示すフラグ変数である。バッファリングフラグの初期値は、ONである。ONは、バッファリングを行うことを示す。OFFは、バッファリングを行わないことを示す。
【0101】
図19では、また、対象処理要求が保留終了処理要求である場合(S220でYes)において、ステップS230が実行される前に、ステップS221〜S227が実行される。
【0102】
ステップS221において、プロトコル制御部12は、対象処理要求である保留終了処理要求の「受信バッファへのポインタ」によって特定される受信バッファ15の制御テーブルT1aの保留数Nの値は1であるか否かを判定する。すなわち、当該受信バッファ15に記憶されている受信セグメントは一つであるか否かが判定される。以下、当該受信バッファ15を「対象受信バッファ15」といい、当該制御テーブルT1aを、「対象制御テーブルT1a」という。
【0103】
保留数Nが1である場合(S221でYes)、プロトコル制御部12は、連続数Mに1を加算する(S222)。続いて、プロトコル制御部12は、連続数Mが閾値α以上であるか否かを判定する(S223)。閾値αは、1つの受信セグメントのみがバッファリングされている状態における受信セグメントのアプリケーション13への通知が何回以上連続したらバッファリングを停止するかを規定する閾値である。閾値αとして、例えば、「10」が設定される。
【0104】
連続数Mが閾値α以上である場合(S223でYes)、プロトコル制御部12は、対象制御テーブルT1aのバッファリングフラグをOFFにする(S224)。すなわち、対象受信バッファ15に関してバッファリングは行わないことが設定される。続いて、プロトコル制御部12は、タイマを起動させる(S225)。ここでいうタイマは、バッファリングフラグをOFFのままとする一定時間を計測するタイマである。一定時間が経過すると、一定時間が経過したことが、タイマによってプロトコル制御部12に通知される。プロトコル制御部12は、タイマからの通知に応じて、バッファリングフラグをONに戻す。そうすることにより、プロトコル制御部12は、バッファリングが行われない状態が無制限に継続してしまうのを回避する。なお、一定時間バッファリングフラグがOFFにされた後は、対象制御テーブルT1aの連続数Mは初期化されない。したがって、タイマからの通知に応じてバッファリングフラグがONに戻された後、保留数Nが1の状態で、ステップS230が実行されたら、直ちにバッファリングフラグはOFFにされる。
【0105】
一方、対象制御テーブルT1aの保留数Nが1でない場合(S220でNo)、プロトコル制御部12は、対象制御テーブルT1aの連続数Mを0に初期化する(S226)。対象受信バッファ15には複数の受信セグメントが記憶されており、ステップS230において当該複数の受信セグメントがまとめて宛先のアプリケーション13に通知されるからである。
【0106】
ステップS226、又はステップS223でNoの場合に続いて、プロトコル制御部12は、ステップS230を実行する。
【0107】
図19では、更に、ステップS270でYesの場合に、ステップS271が実行される。ステップS271において、プロトコル制御部12は、対象制御テーブルT1aのバッファリングフラグはONであるか否かを判定する。当該バッファリングフラグがONである場合(S271でYes)、プロトコル制御部12は、ステップS280及びS290を実行する。当該バッファリングフラグがOFFである場合、プロトコル制御部12は、ステップS300を実行する。すなわち、対象セグメントは、対象受信バッファ15に記憶されることなく、宛先のアプリケーション13に通知される。
【0108】
図19では、更に、ステップS280に続いて、ステップS281が実行される。ステップS281において、プロトコル制御部12は、保留数Nの値を1にする。
【0109】
上述したように、第二の実施の形態によれば、ネットワーク負荷が高い場合等、セグメントがまとめて受信されない場合において、無駄なバッファリング処理の実行を回避することができる。その結果、処理効率を向上させることができる。
【0110】
なお、上記では、保留数Nが1である場合に受信バッファ15のクリアが実行される状態が所定回数連続したときに、バッファリング処理が一定時間行われない例を示した。但し、保留数Nが1であるという条件は、保留数Nが所定数(例えば、2等)以下であるという条件に置き換えられてもよい。すなわち、保留数Nが所定数以下である場合に受信バッファ15のクリアが実行される状態が所定回数連続したときに、バッファリング処理が一定時間行われないようにしてもよい。
【0111】
次に、第三の実施の形態について説明する。第三の実施の形態では、第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第二の実施の形態と同様でよい。
【0112】
保留終了処理要求の直前に処理された処理要求に係る受信セグメントがMSS以上である場合、当該受信セグメントには後続セグメントが存在する可能性がある。そこで、第三の実施の形態のプロトコル制御部12は、このような場合において、保留終了処理要求に応じた処理は実行せずに、当該保留終了処理要求を処理待ちキュー14の最後尾に移動させる。
【0113】
図21は、保留終了処理要求を処理しないで最後尾に移動させる例を示す図である。図21では、保留終了処理要求が処理対象とされる時点において、当該保留終了処理要求の直前に処理された処理要求に係る受信セグメント2のセグメント長がMSSに一致する例が示されている。このような場合、プロトコル制御部12は、当該保留終了処理要求を、処理待ちキュー14の最後尾に移動させる。そうすることにより、例えば、図21に示されるように、当該保留終了処理要求の直後に、受信セグメント2の後続セグメントである受信セグメント3の処理要求が処理待ちキュー14に記憶されていた場合、処理効率を向上させることができる。すなわち、移動後の保留終了処理要求が処理されることにより、受信セグメント1、受信セグメント2、及び受信セグメント3をまとめて、宛先のアプリケーション13に通知することができるからである。
【0114】
但し、プロトコル制御部12は、受信バッファ15に記憶されている全ての受信セグメントのセグメント長の合計が所定値以上である場合、又は受信バッファ15に記憶されている受信セグメントの総数が所定数以上である場合には、保留終了処理要求の移動は行わない。すなわち、これらの場合、受信バッファ15に記憶されている全ての受信セグメントは、直ちに宛先のアプリケーション13に通知される。受信バッファ15の枯渇を防止するためである。
【0115】
以下、斯かる処理制御を実現するためにプロトコル制御部12が実行する処理について説明する。
【0116】
図22は、第三の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。図22中、図19と同一ステップには同一ステップ番号を付し、その説明は省略する。
【0117】
図22では、ステップS226の後に、ステップS231〜S234が実行される。ステップS231において、プロトコル制御部12は、対象制御テーブルT1aの「最終ポインタ」によって特定される受信セグメントのセグメント長はMSS以上であるか否かを判定する。なお、当該受信セグメントは、現在処理対象とされている保留終了処理要求の直前に処理された処理要求に係る受信セグメントに相当する。以下、当該受信セグメントを、「最終セグメント」という。なお、TCPオブションサイズが0でない場合、最終セグメントのセグメント長は、(MSS−TCPオプションサイズ)と比較されればよい。
【0118】
最終セグメントのセグメント長がMSS以上である場合(S231でYes)、プロトコル制御部12は、対象受信バッファ15に記憶されている全ての受信セグメントのセグメント長の合計は、所定値β未満であるか否かを判定する(S232)。所定値βは、受信バッファ15のサイズに応じて、受信バッファ15の枯渇を防止可能な値が設定されればよい。例えば、所定値βには、64KByteが設定される。なお、ステップS232では、対象受信バッファ15に記憶されている受信セグメントの総数が、所定数未満であるか否かが判定されてもよい。
【0119】
セグメント長の合計が所定値β未満である場合(S232でYes)、プロトコル制御部12は、保留数Nの値を1にする(S233)。続いて、プロトコル制御部12は、保留終了処理要求を処理待ちキュー14の待ち行列の最後尾に追加する(S234)。その結果、実質的又は擬似的に、処理対象とされている保留終了処理要求が、処理待ちキュー14の待ち行列の最後尾に移動される。
【0120】
なお、ステップS234に続いて、ステップS230は実行されない。
【0121】
一方、最終セグメントのセグメント長がMSS未満である場合(S231でNo)、又はセグメント長の合計が所定値β以上である場合(S232でNo)、ステップS230が実行される。
【0122】
なお、上記各実施の形態において、処理待ちキュー14は、処理要求記憶部の一例である。受信バッファ15は、データ記憶部の一例である。プロトコル制御部12は、制御部の一例である。
【0123】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【0124】
以上の説明に関し、更に以下の項を開示する。
(付記1)
通信装置が、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する受信データ処理方法。
(付記2)
前記通知する処理は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する処理を実行する付記1記載の受信データ処理方法。
(付記3)
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する付記1又は2記載の受信データ処理方法。
(付記4)
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する付記1乃至3いずれか一項記載の受信データ処理方法。
(付記5)
受信データの受信順に、受信データに関する処理要求の待ち行列を記憶する処理要求記憶部と、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行し、当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する制御部とを有し、
前記制御部は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する通信装置。
(付記6)
前記制御部は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する付記5記載の通信装置。
(付記7)
前記制御部は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する付記5又は6記載の通信装置。
(付記8)
前記制御部は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する付記5乃至7いずれか一項記載の通信装置。
(付記9)
通信装置に、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行させ、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知するプログラム。
(付記10)
前記通知する処理は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する付記9記載のプログラム。
(付記11)
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する付記9又は10記載のプログラム。
(付記12)
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する付記9乃至11いずれか一項記載のプログラム。
【符号の説明】
【0125】
10 受信装置
11 入出力制御部
12 プロトコル制御部
13 アプリケーション
14 処理待ちキュー
15 受信バッファ
20 送信装置
100 ドライブ装置
101 記録媒体
102 補助記憶装置
103 メモリ装置
104 CPU
105 インタフェース装置
B バス
【技術分野】
【0001】
本発明は、受信データ処理方法、通信装置、及びプログラムに関する。
【背景技術】
【0002】
従来、TCP(Transmission Control Protocol)に代表されるバイトストリーム型(バイト指向)の通信プロトコルを使用した通信において、通信プロトコルに応じた処理制御を行うプロトコル制御部は、受信したデータを即座に上位アプリケーションに渡していた。
【0003】
図1は、受信データが即座に上位アプリケーションに渡される例を示す図である。図1では、送信装置520において、送信データがデータ1及びデータ2の二つのデータに分割されて受信装置510の上位アプリケーション宛に送信される例が示されている。
【0004】
プロトコル制御部が受信データを即座に上位アプリケーションに渡す場合、プロトコル制御部と上位アプリケーションとの間での受信データの受け渡しは頻発する。したがって、受信データの受け渡しに要される処理のオーバーヘッドや、上位アプリケーション側での受信データの組み立て処理等によって処理効率が低下し、CPU負荷が高まるという問題がある。
【0005】
近年のコンピュータシステムにおいては、ネットワークの劇的な高速化に比べてCPU性能の向上が相対的に小さくなっている。したがって、ネットワーク通信のデータ量の増加に伴う、CPU使用量の削減が求められている。
【0006】
なお、バイトストリーム型の通信プロトコルとは、通信対象のデータを単なるバイトの列として扱う通信プロトコルをいう。バイトストリーム型の通信プロトコルでは、上位アプリケーションにとって意味の有る単位の区切りとは無関係に、データが分割又は結合されて送受信が行われる。したがって、上位アプリケーションは、プロトコル制御部より渡されたデータに関して、意味の有る単位に組み立てたり分割したりする必要がある。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特表2002−527945号公報
【特許文献2】特開2005−143098号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
プロトコル制御部が、データをバッファリングして、複数のデータをまとめて上位アプリケーションに渡すことにより、処理効率の向上を図ることができる。従来、最初のデータがバッファリングされてから一定時間経過後、又は一定データ長のデータがバッファリングされたときに、それまでにバッファリングされているデータがまとめて上位アプリケーションに渡されていた。
【0009】
図2は、最初のデータがバッファリングされてから一定時間経過後に受信データが上位アプリケーションに渡される例を示す図である。図2において、プロトコル制御部は、受信されたデータを直ちに上位アプリケーションには渡さず、バッファに記憶する。最初のデータが受信されてから一定時間tが経過すると、プロトコル制御部は、バッファに記憶されているデータをまとめて上位アプリケーションに渡す。
【0010】
しかしながら、上記のようなバッファリングでは、上位アプリケーションへの通知が遅延する結果、応答性が損なわれる場合がある。応答性とは、データが受信されてから、当該データが上位アプリケーションへ通知され、上位アプリケーションが当該データの処理を完了するまでの時間の短さのことをいう。データが受信されてから、上位アプリケーションへの通知が完了するまでの時間が短いほど、応答性は向上する。一般に、応答性が高いほどスループット(受信装置510の単位時間当たりの受信データの処理量)は向上する。
【0011】
例えば、図2に示した例では、データ2が受信された時点で上位アプリケーションにデータ1及び2が通知されるのが効率的であるが、データ1のバッファリング時から一定時間が経過するまで、データ1及びデータ2の通知は遅延する。なお、バイトストリーム型の通信プロトコルでは、受信データが最後の受信データであるか否かをプロトコル制御部が判断することはできない。したがって、データ2の後続データが無い場合であっても、一定時間の待機は行われる。
【0012】
一定時間の待機が行われる結果、プロトコル制御部のバッファに受信データが溜まり、データ通信のフロー制御に影響したり、バッファ枯渇が発生したりする可能性も有る。
【0013】
そこで、一側面では、受信データのバッファリングによる応答性の低下を低減させることのできる受信データ処理方法、通信装置、及びプログラムの提供を目的とする。
【課題を解決するための手段】
【0014】
一つの案では、通信装置が、受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する。
【発明の効果】
【0015】
一態様によれば、受信データのバッファリングによる応答性の低下を低減させることができる。
【図面の簡単な説明】
【0016】
【図1】受信データが即座に上位アプリケーションに渡される例を示す図である。
【図2】最初のデータがバッファリングされてから一定時間経過後に受信データが上位アプリケーションに渡される例を示す図である。
【図3】本発明の実施の形態における通信システムの構成例を示す図である。
【図4】本発明の実施の形態における受信装置のハードウェア構成例を示す図である。
【図5】本発明の実施の形態における受信装置の機能構成例を示す図である。
【図6】第一の実施の形態の受信装置が実行する処理手順の第一の例を説明するための図である。
【図7】処理待ちキュー及び受信バッファの状態の第一の例を示す図である。
【図8】処理待ちキュー及び受信バッファの状態の第二の例を示す図である。
【図9】処理待ちキュー及び受信バッファの状態の第三の例を示す図である。
【図10】処理待ちキュー及び受信バッファの状態の第四の例を示す図である。
【図11】第一の実施の形態の受信装置が実行する処理手順の第二の例を説明するための図である。
【図12】処理待ちキュー及び受信バッファの状態の第五の例を示す図である。
【図13】処理待ちキュー及び受信バッファの状態の第六の例を示す図である。
【図14】第一の実施の形態における受信セグメントの処理要求の受け付け時の処理手順の一例を説明するためのフローチャートである。
【図15】第一の実施の形態の処理待ちキューに記憶される処理要求の構成例を示す図である。
【図16】プロトコル処理前の受信セグメントの構成例を示す図である。
【図17】第一の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。
【図18】第一の実施の形態の受信バッファの構成例を示す図である。
【図19】第二の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。
【図20】第二の実施の形態の受信バッファの構成例を示す図である。
【図21】保留終了処理要求を処理しないで最後尾に移動させる例を示す図である。
【図22】第三の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。
【発明を実施するための形態】
【0017】
以下、図面に基づいて本発明の実施の形態を説明する。図3は、本発明の実施の形態における通信システムの構成例を示す図である。図3において、送信装置20と受信装置10とは、LAN(Local Area Network)又はインターネット等のネットワークを介して通信可能とされている。なお、ネットワークの一部又は全部において、無線通信が利用されてもよい。
【0018】
送信装置20は、受信装置10に対してデータを送信する情報処理装置である。受信装置10は、送信装置20より送信されるデータを受信する情報処理装置である。本実施の形態において、送信装置20と受信装置10との間のデータ通信には、バイトストリーム型(バイト指向)の通信プロトコルの一例として、TCP(Transmission Control Protocol)が利用される。但し、TCP以外のバイトストリーム型の通信プロトコルが利用されてもよい。
【0019】
したがって、送信装置20から受信装置10へ送信されるデータは、セグメント単位に分割されて送信される。セグメントとは、送信用に分割されたデータをいい、セグメントごとにIPヘッダ及びTCPヘッダ等が付与される。なお、送信データが一つのセグメントに収まる場合は、当該送信データは、分割されずに一つのセグメントとされる。
【0020】
なお、送信装置20及び受信装置10という名称は、便宜的なものに過ぎない。すなわち、通信手順の進行に応じて、送信装置20がデータの受信側になってもよいし、受信装置10がデータの送信側になってもよい。
【0021】
図4は、本発明の実施の形態における受信装置のハードウェア構成例を示す図である。図4の受信装置10は、それぞれバスBで相互に接続されているドライブ装置100、補助記憶装置102、メモリ装置103、CPU104、及びインタフェース装置105等を有する。
【0022】
受信装置10での処理を実現するプログラムは、記録媒体101によって提供される。プログラムを記録した記録媒体101がドライブ装置100にセットされると、プログラムが記録媒体101からドライブ装置100を介して補助記憶装置102にインストールされる。但し、プログラムのインストールは必ずしも記録媒体101より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置102は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【0023】
メモリ装置103は、プログラムの起動指示があった場合に、補助記憶装置102からプログラムを読み出して格納する。CPU104は、メモリ装置103に格納されたプログラムに従って受信装置10に係る機能を実行する。インタフェース装置105は、例えば、ネットワークカードであり、ネットワークに接続するためのインタフェースとして用いられる。
【0024】
なお、記録媒体101の一例としては、CD−ROM、DVDディスク、又はUSBメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置102の一例としては、HDD(Hard Disk Drive)又はフラッシュメモリ等が挙げられる。記録媒体101及び補助記憶装置102のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。
【0025】
なお、送信装置20も、例えば、図4に示されるハードウェアを有している。
【0026】
図5は、本発明の実施の形態における受信装置の機能構成例を示す図である。図5において、受信装置10は、入出力制御部11、プロトコル制御部12、及び一以上のアプリケーション13等を有する。
【0027】
入出力制御部11は、インタフェース装置105によって受信される受信データを、インタフェース装置105より読み出す。入出力制御部11は、読み出したデータに関する処理要求を、セグメント単位でプロトコル制御部12に入力する。なお、受信データは、入出力制御部11によって読み出されるまで、インタフェース装置105のメモリ内に滞留する。入出力制御部11は、例えば、受信装置10にインストールされた、インタフェース装置105に対応したデバイスドライバとしてのプログラムがCPU104に実行させる処理によって実現される。以下、セグメント単位の受信データを、「受信セグメント」という。
【0028】
プロトコル制御部12は、入出力制御部11からの処理要求に応じ、当該処理要求に係る受信セグメントに関して、通信プロトコル(TCP)に従った処理を実行する。以下、通信プロトコルに従った処理を「プロトコル処理」という。プロトコル処理の一例として、IPヘッダの解析処理及びTCPヘッダの解析処理等が挙げられる。プロトコル処理によって、例えば、宛先(コネクション)の識別、改竄の有無のチェック、及び受信順序の正否等が判定される。宛先は、IPヘッダに含まれているIPアドレスと、TCPヘッダに含まれているポート番号とによって識別される。なお、本実施の形態では、一つのアプリケーション13は、一つのコネクションを有することとする。すなわち、宛先が識別されることによって、受信セグメントの通知先(又は伝達先)のアプリケーション13が特定されることになる。改竄の有無のチェックは、IPチェックサム及びTCPチェックサム等を用いて行われる。受信順序の正否は、シーケンス番号及びACK番号等に基づいて判定される。
【0029】
プロトコル制御部12は、処理待ちキュー14及び受信バッファ15等の記憶部を利用する。処理待ちキュー14は、入出力制御部11からの処理要求の待ち行列をFIFO(First-In First-Out)形式で記憶する記憶部である。受信バッファ15は、処理待ちキュー14に記憶された処理要求に係る受信セグメントのうち、プロトコル処理が実行された受信セグメントを記憶する記憶部である。処理待ちキュー14は、複数の宛先(コネクション)に対して共通であるのに対し、受信バッファ15は、宛先(コネクション)ごとに形成される。受信バッファ15に記憶された受信セグメントは、所定のタイミングで、当該受信バッファ15に係る宛先のアプリケーション13に通知(又は伝達)される。処理待ちキュー14及び受信バッファ15は、例えば、メモリ装置103を用いて実現可能である。
【0030】
なお、プロトコル制御部12は、受信装置10にインストールされたプログラムがCPU104に実行させる処理によって実現される。
【0031】
アプリケーション13は、本実施の形態において、送信装置20より送信されるデータの宛先となるプログラムである。アプリケーション13は、例えば、受信データを利用して、所定の処理を実行する。
【0032】
以下、受信装置10が実行する処理手順について説明する。図6は、第一の実施の形態の受信装置が実行する処理手順の第一の例を説明するための図である。
【0033】
インタフェース装置105においてデータが受信されると、入出力制御部11は、インタフェース装置105に対して読み出し要求(READ要求)を発行し、受信データをインタフェース装置105より読み出す(S101)。ここでは、二つのセグメントが受信されていることとする。したがって、二つの受信セグメントが読み出される。通常、Nセグメント分のデータが送信装置20より送信された場合、Nセグメント以下の複数セグメントがまとめて受信される。ここで、Nは2以上である。
【0034】
続いて、入出力制御部11は、各受信セグメントの処理要求を、受信セグメントの受信順(読み出し順)にプロトコル制御部12に入力する(S102)。入力された処理要求は、プロトコル制御部12の処理待ちキュー14に登録される。ステップS102の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図7に示されるような状態になる。
【0035】
図7は、処理待ちキュー及び受信バッファの状態の第一の例を示す図である。図7において、処理待ちキュー14には、1番目の受信セグメント(受信セグメント1)の処理要求と、2番目の受信セグメント(受信セグメント2)の処理要求との待ち行列が記憶されている。一方、受信バッファ15は空の状態である。
【0036】
続いて、プロトコル制御部12は、処理待ちキュー14の先頭の処理要求である、受信セグメント1の処理要求を取得し、当該処理要求に応じて受信セグメント1に関してプロトコル処理を実行する(S103)。なお、取得された処理要求は、処理待ちキュー14より削除される。
【0037】
続いて、プロトコル制御部12は、プロトコル処理が行われた受信セグメント1を、受信セグメント1の宛先に対応する受信バッファ15に記憶する(S104)。受信セグメント1を記憶する前において、受信バッファ15は空である。そこで、プロトコル制御部12は、処理待ちキュー14に対して、保留終了処理要求を追加する(S105)。保留終了処理要求とは、受信バッファ15における受信セグメントのバッファリング(保留)の終了の要求である。受信バッファ15における受信セグメントのバッファリングの終了は、受信バッファ15のクリア、すなわち、受信バッファ15に記憶されている全ての受信セグメントを、宛先のアプリケーション13に通知することを意味する。
【0038】
ステップS105の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図8に示されるような状態になる。
【0039】
図8は、処理待ちキュー及び受信バッファの状態の第二の例を示す図である。図8において、既に処理された受信セグメント1の処理要求は処理待ちキュー14より削除され、受信セグメント1は受信バッファ15に記憶されている。また、保留終了処理要求が、処理待ちキュー14における処理要求の待ち行列の最後尾に追加されている。
【0040】
続いて、プロトコル制御部12は、現時点において処理待ちキュー14の先頭の処理要求である受信セグメント2の処理要求を取得し、当該処理要求に応じて受信セグメント2に関してプロトコル処理を実行する(S106)。続いて、プロトコル制御部12は、プロトコル処理が行われた受信セグメント2を、受信セグメント2の宛先に対応する受信バッファ15に記憶する(S107)。受信セグメント2の宛先は、受信セグメント1と同じであるとする。したがって、受信セグメント2は、受信セグメント1と同じ受信バッファ15に記憶される。したがって、受信セグメント2を記憶する前において、受信バッファ15は空ではない。すなわち、受信バッファ15には受信セグメント1が記憶されている。したがって、プロトコル制御部12は、処理待ちキュー14に対して、保留終了処理要求は追加しない。
【0041】
ステップS107の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図9に示されるような状態になる。
【0042】
図9は、処理待ちキュー及び受信バッファの状態の第三の例を示す図である。図8において、既に処理された受信セグメント2の処理要求は処理待ちキュー14より削除され、受信セグメント2は、受信セグメント1と共に受信バッファ15に記憶されている。
【0043】
続いて、プロトコル制御部12は、現時点において処理待ちキュー14の先頭の処理要求である保留終了処理要求を処理対象とする。処理対象が保留終了処理要求であることに応じ、プロトコル制御部12は、受信バッファ15に記憶されている全ての受信セグメントを、当該受信バッファ15に対応する宛先であるアプリケーション13にまとめて通知する(S108)。
【0044】
ステップS107の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図10に示されるような状態になる。
【0045】
図10は、処理待ちキュー及び受信バッファの状態の第四の例を示す図である。図10において、処理待ちキュー14及び受信バッファ15は、共に空の状態となっている。
【0046】
図6に示される処理によれば、受信セグメント1及び受信セグメント2をまとめた受信データに関して、待ち時間が発生することなくまとめてアプリケーション13に通知することができる。また、アプリケーション13への通知はバッファリングされた全ての受信セグメントに関してまとめて実行されるため、アプリケーション13とプロトコル制御部12との間のデータの受け渡しの回数を低減させることができる。その結果、バッファリングによる応答性の低下を低減させることができ、また、CPU104の負荷の増加を抑制することができる。更に、待ち時間のタイマの設定が不要となる点においても、CPU104の負荷の増加を抑制することができる。
【0047】
なお、上記では、便宜上、二つの受信セグメントがまとめてアプリケーション13に通知される例を示したが、通常は、更に多くの受信セグメントの処理要求がまとめて処理待ちキュー14に記憶される可能性が高い。特に、入出力制御部11においてもバッファリングが行われる場合は、処理待ちキュー14に記憶される受信セグメント数が複数になる可能性が高い。このことは、複数の受信セグメントごとに、保留終了処理要求が処理待ちキュー14に追加される可能性が高いことを意味する。処理待ちキュー14にまとめて記憶される処理要求が多くなればなるほど、保留終了処理要求に基づく処理の効率化の効果が大きくなる。
【0048】
但し、ネットワーク負荷の状態によっては、複数のセグメントがまとめて受信されない場合も考えられる。そこで、受信セグメント2の転送に遅延が発生した場合の処理手順について説明する。
【0049】
図11は、第一の実施の形態の受信装置が実行する処理手順の第二の例を説明するための図である。
【0050】
ステップS111において、入出力制御部11は、インタフェース装置105において受信されている受信セグメント1を読み出す(S111)。続いて、入出力制御部11は、受信セグメント1の処理要求を、プロトコル制御部12に入力する(S112)。ステップS112の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図12に示されるような状態になる。
【0051】
図12は、処理待ちキュー及び受信バッファの状態の第五の例を示す図である。図12において、処理待ちキュー14には、受信セグメントの処理要求のみが記憶されている。なお、受信バッファ15は空の状態である。
【0052】
続いて、プロトコル制御部12は、処理待ちキュー14の先頭の処理要求である受信セグメント1の処理要求を取得し、当該処理要求に応じて受信セグメント1に関してプロトコル処理を実行する(S113)。続いて、プロトコル制御部12は、プロトコル処理が行われた受信セグメント1を、受信セグメント1の宛先に対応する受信バッファ15に記憶する(S114)。受信セグメント1を記憶する前において、受信バッファ15は空である。そこで、プロトコル制御部12は、処理待ちキュー14に対して、保留終了処理要求を追加する(S115)。
【0053】
ステップS115の実行直後において、処理待ちキュー14及び受信バッファ15は、例えば、図13に示されるような状態になる。
【0054】
図13は、処理待ちキュー及び受信バッファの状態の第六の例を示す図である。図13において、既に処理された受信セグメント1の処理要求は処理待ちキュー14より削除され、受信セグメント1は受信バッファ15に記憶されている。また、保留終了処理要求が、処理待ちキュー14に追加されている。
【0055】
続いて、プロトコル制御部12は、現時点において処理待ちキュー14の先頭の処理要求である保留終了処理要求を処理対象とする。処理対象が保留終了処理要求であることに応じ、プロトコル制御部12は、受信バッファ15に記憶されている受信セグメント1を受信セグメント1の宛先であるアプリケーション13に通知する(S116)。
【0056】
その後、受信セグメント2が受信されると、入出力制御部11は、受信セグメント2をインタフェース装置105より読み出す(S117)。続いて、入出力制御部11は、受信セグメント2の処理要求を、プロトコル制御部12に入力する(S118)。したがって、受信セグメント2の処理要求が処理待ちキュー14に記憶される。
【0057】
続いて、プロトコル制御部12は、処理待ちキュー14の先頭の処理要求である受信セグメント2の処理要求を取得し、当該処理要求に応じて受信セグメント2に関してプロトコル処理を実行する(S119)。ここで、プロトコル制御部12は、受信セグメント2のセグメント長に基づいて、後続のセグメントは無いと判定した場合、受信セグメント2を受信バッファ15に記憶することなく、即座に宛先のアプリケーション13に通知する(S120)。そのため、バッファリングによる待ちが発生しないことに加えて、バッファリングによるオーバーヘッドも削減できる。後続のセグメントとは、既に受信されている受信セグメントと同一のデータに含まれるセグメントであって、送信装置20から既に送信済みであり、ネットワーク中において転送中であるセグメントや、これから送信装置20により送信されるセグメント等をいう。「同一のデータ」とは、アプリケーション13にとって意味のあるデータの区切り間のデータをいう。
【0058】
なお、セグメント長に基づく後続のセグメントの有無の判定は、図11の受信セグメント1に関しても行われる。但し、受信セグメント1については、後続のセグメントは無いと推定きなかった場合であるとする。したがって、受信セグメント1は、受信バッファ15に記憶される。
【0059】
図11のように、受信セグメント間に遅延が発生する場合は、受信セグメントごとに保留終了処理要求が処理待ちキュー14に追加され、受信セグメントごとにアプリケーション13への通知が行われることになる。したがって、バッファリングによる待ち時間の発生は回避できるが、アプリケーション13とプロトコル制御部12とのデータの受け渡しは頻発する。但し、本実施の形態では、受信セグメントの受け渡しによる負荷の増加よりも、受信セグメントを即時的に受け渡すことによる応答性の向上の方が重要であると考える。また、処理が遅延しているため、受け渡し処理が頻発による付加の増加は、遅延してない場合に比べて非常に小さいと考えられる。
【0060】
ステップS120において説明したように、本実施の形態において、プロトコル制御部12は、処理対象のセグメントのセグメント長に基づいて後続セグメントの有無の判定を行う。これにより、バッファリングの必要がない場合、例えば、複数セグメントではなく1セグメントに収まるデータが受信された場合等において、バッファリングによるオーバーヘッドの発生を回避することができる。
【0061】
セグメント長に基づく後続セグメントの有無の判定方法の一例について説明する。
【0062】
多くのTCP/IPの実装系では、セグメントが伝送路で分割されないように、MSS(Maximum Segment Size:最大セグメントサイズ)が設定される。MSSは、伝送路に流すことのできる最大データ長を示すMTU(Maximum Transmission Unit)からIPヘッダサイズ及びTCPヘッダサイズを引いた値である。送信装置20は、MSSを超えるデータを送信しようとすると、MSSごとのセグメントに分割し、各セグメントを伝送路に送信する。受信装置10では分割されたセグメントをそのまま受信するため、受信セグメントのサイズ(セグメント長)がMSSと等しければ、後続セグメントが存在する可能性は高いと考えられる。そこで、受信セグメントのセグメント長がMSSと等しい場合、プロトコル制御部12は、後続セグメントは存在すると判定又は推定し、バッファリング処理を実行する。
【0063】
また、TCPの実装によっては、プロトコル処理の後、セグメント長がMSSよりも大きい受信セグメントが処理される場合がある。セグメント長がMSSよりも大きい受信セグメントの処理は、ネットワークにおいてセグメントの順序が逆転したり、セグメントが消失して再送が行われたりしたときに、受信装置10のTCPの順序制御により複数セグメントがまとめて処理された場合に行われる。したがって、セグメント長がMSSよりも大きい受信セグメントが処理される場合も後続セグメントが存在する可能性が有る。そこで、プロトコル制御部12は、セグメント長がMSSより大きい受信セグメントを処理する場合も、バッファリング処理を行う。
【0064】
一方、受信セグメントのセグメント長がMSS未満である場合、送信装置20がセグメントの分割を実行しなかったデータ長であった可能性が高く、後続セグメントが存在しない可能性が高い。そこで、受信セグメントのセグメント長がMSS未満である場合、プロトコル制御部12は、後続セグメントは存在しないと判定又は推定し、バッファリング処理を実行しない。なお、送信装置20が送信したデータが最大セグメントサイズと一致する場合も有る。この場合、受信装置10では、後続セグメントが実際には存在しないにもかかわらず、後続セグメントが有ると判定される。したがって、この場合、バッファリングは行われる。但し、当該セグメントに続いて保留終了処理要求が処理待ちキュー14に追加される可能性が高い。したがって、当該セグメントは、即時的にアプリケーション13に通知される。
【0065】
なお、TCP通信において、MSSの値は、コネクション確立時(通信開始時)に受信装置10と送信装置20との間のネゴシエーションにより決定され、コネクション確立要求及びコネクション確立応答のTCPヘッダに含まれる。したがって、プロトコル制御部12は、当該TCPヘッダよりMSSを取得し、例えば、メモリ装置103に記憶しておく。
【0066】
また、タイムスタンプオプション等のTCPオプションが使用される場合、送信装置20において、MSSからTCPオプションサイズを引いた値にセグメント分割が行われる。したがって、TCPオプションが使用される場合、受信装置10における後続セグメントの有無の判定には、MSSからTCPオプションサイズを引いた値が採用される。
【0067】
ところで、TCP通信ではPSHフラグの有無に基づいて後続セグメントの有無を判定することも考えられる。PSHフラグとは、TCPヘッダに含まれるTCPフラグの一つであり、「PSHフラグ付きのTCPセグメントを受け取ったら、(バッファリングせずに)速やかに上位プロトコル(上位アプリケーション13)へ渡す」ことを意味する。TCPデータ送信時のPSHフラグの付加の方法はRFC(Request for Comments)で規定されている。PSHフラグを利用して後続セグメントの有無を判定することにより、待ち時間の少ないバッファリングが可能である。しかし、図11のように途中のセグメントの転送が遅れた場合や、送信装置20のPSHフラグの実装により、バッファリング時間が生じるといった問題点がある。また、PSHフラグは送信装置20の実装に依存する。そのため、ほとんどの実装系ではPSHフラグを利用したバッファリングは行われておらず、またPSHフラグの有無が意識されていないのが現状である。
【0068】
したがって、本実施の形態ではPSHフラグに基づく後続セグメントの有無の判定は行わない。但し、PSHフラグの基づく後続セグメントの有無の判定と、本実施の形態におけるセグメント長に基づく後続セグメントの有無の判定との双方が重複して行われてもよい。
【0069】
続いて、図6及び図11等において説明した処理手順を実現するために、プロトコル制御部12が実行する処理について詳細に説明する。
【0070】
図14は、第一の実施の形態における受信セグメントの処理要求の受け付け時の処理手順の一例を説明するためのフローチャートである。
【0071】
受信セグメントの処理要求が入出力制御部11より入力されると(S201でYes)、プロトコル制御部12は、当該処理要求を処理待ちキュー14の最後尾に追加する(S202)。
【0072】
図15は、第一の実施の形態の処理待ちキューに記憶される処理要求の構成例を示す図である。既述したように、処理待ちキュー14に記憶される処理要求には、受信セグメントの処理要求と保留終了処理要求とがある。
【0073】
受信セグメントの処理要求は、例えば、処理要求コード、次の処理要求へのポインタ、及び受信セグメントへのポインタ等を含む。処理要求コードは、処理要求の種別を識別するためのコードである。受信セグメントの処理要求については、受信セグメントの処理要求であることを示す値が処理要求コードに設定される。次の処理要求へのポインタは、処理待ちキュー14の待ち行列において、次の順番の処理要求へのポインタ(関連付け情報)である。受信セグメントへのポインタは、当該処理要求に関して処理対象とされる受信セグメントの実体へのポインタである。
【0074】
一方、保留終了処理要求は、処理要求コード、次の処理要求へのポインタ、及び受信バッファへのポインタ等を含む。処理要求コード及び次の処理要求へのポインタについては、受信セグメントの処理要求と同様である。但し、保留終了処理要求の処理要求コードには、保留終了処理要求であることを示す値が設定される。受信バッファへのポインタは、当該保留終了処理要求が対応する受信バッファ15へのポインタである。すなわち、受信バッファへのポインタは、当該保留終了処理要求が処理対象とされた際に、クリアすべき受信バッファ15へのポインタである。
【0075】
なお、ステップS202において追加されるのは、受信セグメントの処理要求である。当該処理要求を処理要求Rとし、処理要求Rが処理待ちキュー14に追加される前の最後尾の処理要求を処理要求Eとすると、処理要求Eの「次の処理要求へのポインタ」には処理要求Rのアドレスが設定される。また、処理要求Rの「次の処理要求へのポインタ」には、例えば、終端又は末尾を示すNULLが設定される。処理要求Rの「受信セグメントへのポインタ」には、入出力制御部11より受け付けた受信セグメントへのポインタが設定される。この時点において、受信セグメントは、例えば、図16に示されるような構成を有する。
【0076】
図16は、プロトコル処理前の受信セグメントの構成例を示す図である。図16に示されるように、処理待ちキュー14に記憶された時点、すなわち、プロトコル処理前の受信セグメントは、例えば、ネットワークインタフェース層ヘッダ、IPヘッダ、TCPヘッダ、及びユーザデータ等を含む。
【0077】
ネットワークインタフェース層ヘッダの形式は、使用される物理的なネットワークの種類に依存する。ユーザデータは、アプリケーション13にとって意味の有るデータである。
【0078】
続いて、処理待ちキュー14に記憶された処理要求に応じてプロトコル制御部12が実行する処理手順について説明する。図17は、第一の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。
【0079】
ステップS210において、プロトコル制御部12は、処理待ちキュー14における待ち行列の先頭の処理要求を取得する。続いて、プロトコル制御部12は、取得された処理要求の処理要求コードを参照して、取得された処理要求(以下、「対象処理要求」という。)が保留終了処理要求であるか否かを判定する(S220)。対象処理要求が保留終了処理要求である場合(S220でYes)、当該保留終了処理要求の「受信バッファへのポインタ」によって特定される受信バッファ15に記憶されている受信セグメントを、当該受信バッファ15が対応する宛先のアプリケーション13に通知する(S230)。
【0080】
一方、対象処理要求が、受信セグメントの処理要求である場合(S220でNo)、プロトコル制御部12は、対象処理要求の「受信セグメントへのポインタ」によって特定される受信セグメントに関して、プロトコル処理を実行する(S240)。プロトコル処理において、TCPオプションサイズの算出も行われる。なお、対象処理要求の「受信セグメントへのポインタ」によって特定される受信セグメントを、以下「対象セグメント」という。
【0081】
続いて、プロトコル制御部12は、対象セグメントの宛先に対応する受信バッファ15に1以上のセグメントが記憶されているか否かを判定する(S250)。当該受信バッファ15に1以上のセグメントが記憶されている場合(S250でYes)、プロトコル制御部12は、対象セグメントを当該受信バッファ15に記憶する(S260)。
【0082】
図18は、第一の実施の形態における受信バッファの構成例を示す図である。各受信バッファ15は、制御テーブルT1を含む。制御テーブルは、各種制御情報、先頭ポインタ、及び最終ポインタ等の情報を記憶する。各種制御情報は、例えば、対応する宛先(ポート番号)等、各種の制御情報である。先頭ポインタは、当該受信バッファ15において先頭の受信セグメントへのポインタである。最終ポインタは、当該受信バッファ15において末尾の受信セグメントへのポインタである。
【0083】
各受信セグメントは、次のセグメントへのポインタ、制御テーブルへのポインタ、全保留データ長、セグメント長、IPヘッダ、TCPヘッダ、及びユーザデータ等を含む。図16との比較より明らかなように、次のセグメントへのポインタ、制御テーブルへのポインタ、全保留データ長、及びセグメント長は、プロトコル処理又は受信バッファ15への記憶時において、プロトコル制御部12によって付与される情報である。
【0084】
次のセグメントへのポインタは、当該受信バッファ15において、次の受信セグメントへのポインタである。制御テーブルへのポインタは、当該受信バッファ15の制御テーブルT1へのポインタである。全保留データ長は、当該受信バッファ15に記憶されている全ての受信セグメントのセグメント長の合計である。全保留データ長は、受信バッファ15の先頭の受信セグメントに関してのみ有効であってもよい。セグメント長は、当該受信セグメントのセグメント長である。
【0085】
したがって、ステップS260では、対象セグメントの宛先に対応する受信バッファ15の制御テーブルT1の保留最終ポインタによって特定される受信セグメントの「次のセグメントへのポインタ」に、対象セグメントへのポインタが設定される。また、対象セグメントの「次のセグメントへのポインタ」には、終端又は末尾を示すNULLが設定される。また、当該制御テーブルT1の先頭ポインタによって特定される受信セグメントの「全保留データ長」に、対象セグメントのセグメント長が加算される。更に、当該制御テーブルT1の最終ポインタに、対象セグメントへのポインタが設定される。
【0086】
一方、対象セグメントの宛先に対応する受信バッファ15が空である場合(S250でNo)、プロトコル制御部12は、対象セグメントのセグメント長は、MSS以上であるか否かを判定する(S270)。なお、TCPオプションサイズが0より大きい場合は、対象セグメントのセグメント長は、(MSS−TCPオプションサイズ)と比較される。
【0087】
対象セグメントのセグメント長が、MSS以上である場合(S270でYes)、プロトコル制御部12は、対象セグメントを、対象セグメントの宛先に対応する受信バッファ15に記憶する(S280)。続いて、プロトコル制御部12は、保留終了処理要求を処理待ちキュー14の待ち行列の最後尾に追加する(S290)。当該保留終了処理要求の「受信バッファへのポインタ」には、対象セグメントの宛先に対応する受信バッファ15へのポインタが設定される。
【0088】
一方、対象セグメントのセグメント長が、MSS未満である場合(S270でNo)、プロトコル制御部12は、対象セグメントの宛先のアプリケーション13に対象セグメントを通知する(S300)。すなわち、対象セグメントは、受信バッファ15に記憶されない。
【0089】
なお、図17によれば、対象セグメントの宛先に対応する受信バッファ15に先着の受信セグメントが記憶されている場合(S250でYes)、対象セグメントに関して、MSS未満であるか否かを問わず、受信バッファ15への記憶が行われる。先着の受信セグメントが記憶されている場合に対象セグメントがMSS未満であることを理由として受信バッファ15のクリアを行ったとしても、いずれ保留終了処理要求によって受信バッファ15のクリアが行われる。したがって、先着の受信セグメントが記憶されている場合に対象セグメントがMSS未満であることを理由として受信バッファ15のクリアを行ったとしても、処理ステップの削減の効果は低いと考えられるからである。また、対象セグメントのセグメント長とMSSとを比較する必要があり、却って処理ステップの増加を招くからである。
【0090】
上述したように、第一の実施の形態によれば、受信セグメントの処理要求が処理される際に、当該受信セグメントの宛先に対応する受信バッファ15が空であれば、保留終了処理要求が処理待ちキュー14の最後尾(末尾)に追加される。保留終了処理要求が処理対象とされるまでは、各処理要求に係る受信セグメントは受信バッファ15に記憶され、保留終了処理要求が処理対象とされた時点で、当該保留終了処理要求に係る受信バッファ15内の受信セグメントはまとめて宛先のアプリケーション13に通知される。
【0091】
その結果、一定時間経過又は一定データ長のバッファリングによる応答性の低下を低減させることができる。また、プロトコル制御部12とアプリケーション13との間のセグメントの受け渡しが頻発するのを抑制することができ、当該受け渡しによるオーバーヘッドを削減することができる。
【0092】
次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。
【0093】
第一の実施の形態では、セグメント長がMSS以上である受信セグメントは、常にバッファリングされる。しかし、斯かる受信セグメントをバッファリングしたにも拘わらず、後続の受信セグメントが無かった場合、すなわち、バッファリング処理をしたにも拘わらず、複数の受信セグメントをまとめることができなかった場合、バッファリング処理が無駄となってしまう。このような状況は、例えば、図11に示されるように、ネットワークの転送速度が、受信装置10における受信セグメントの処理速度に対して遅い場合に発生しうる。
【0094】
そこで、第二の実施の形態において、プロトコル制御部12は、所定回数以上連続で、アプリケーション13に通知される受信セグメントが一つである受信バッファ15(コネクション)に関しては、バッファリング処理を一定時間実施しないようにする。一定時間経過後に、ネットワーク負荷が低下して、バッファリング処理の効果が得られるようになっていれば、プロトコル制御部12は、バッファリング処理を再開する。
【0095】
なお、斯かる処理制御は、宛先(コネクション)ごとに行われるため、通信相手の違いによる回線速度の違いに個別に対応することができる。
【0096】
以下、斯かる処理制御を実現するためにプロトコル制御部12が実行する処理について説明する。
【0097】
図19は、第二の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。図19中、図17と同一ステップには同一ステップ番号を付し、その説明は省略する。
【0098】
図19では、ステップS260の後にステップS261が実行される。ステップS261において、プロトコル制御部12は、変数Nに1を加算する。変数Nは、対象セグメントの宛先に対応する受信バッファ15に記憶されている受信セグメントの数が格納される変数である。変数Nを、以下「保留数N」という。なお、コネクションの開始時において、保留数Nの値は、0に初期化される。保留数Nは、例えば、受信バッファ15の制御テーブルT1において管理されてもよい。
【0099】
図20は、第二の実施の形態の受信バッファの構成例を示す図である。図20中、図18と同一部分については、説明を省略する。
【0100】
第二の実施の形態の制御テーブルT1aは、更に、保留数N、連続数M、及びバッファリングフラグ等を含む。保留数Nは、上記した通りである。連続数Mは、保留数Nが1である状態における受信セグメントのアプリケーション13への通知が連続した回数である。すなわち、1つの受信セグメントのみがバッファリングされている状態における受信セグメントのアプリケーション13への通知が連続して発生した回数である。連続数Mの初期値は0である。バッファリングフラグは、バッファリングを行うか否かを示すフラグ変数である。バッファリングフラグの初期値は、ONである。ONは、バッファリングを行うことを示す。OFFは、バッファリングを行わないことを示す。
【0101】
図19では、また、対象処理要求が保留終了処理要求である場合(S220でYes)において、ステップS230が実行される前に、ステップS221〜S227が実行される。
【0102】
ステップS221において、プロトコル制御部12は、対象処理要求である保留終了処理要求の「受信バッファへのポインタ」によって特定される受信バッファ15の制御テーブルT1aの保留数Nの値は1であるか否かを判定する。すなわち、当該受信バッファ15に記憶されている受信セグメントは一つであるか否かが判定される。以下、当該受信バッファ15を「対象受信バッファ15」といい、当該制御テーブルT1aを、「対象制御テーブルT1a」という。
【0103】
保留数Nが1である場合(S221でYes)、プロトコル制御部12は、連続数Mに1を加算する(S222)。続いて、プロトコル制御部12は、連続数Mが閾値α以上であるか否かを判定する(S223)。閾値αは、1つの受信セグメントのみがバッファリングされている状態における受信セグメントのアプリケーション13への通知が何回以上連続したらバッファリングを停止するかを規定する閾値である。閾値αとして、例えば、「10」が設定される。
【0104】
連続数Mが閾値α以上である場合(S223でYes)、プロトコル制御部12は、対象制御テーブルT1aのバッファリングフラグをOFFにする(S224)。すなわち、対象受信バッファ15に関してバッファリングは行わないことが設定される。続いて、プロトコル制御部12は、タイマを起動させる(S225)。ここでいうタイマは、バッファリングフラグをOFFのままとする一定時間を計測するタイマである。一定時間が経過すると、一定時間が経過したことが、タイマによってプロトコル制御部12に通知される。プロトコル制御部12は、タイマからの通知に応じて、バッファリングフラグをONに戻す。そうすることにより、プロトコル制御部12は、バッファリングが行われない状態が無制限に継続してしまうのを回避する。なお、一定時間バッファリングフラグがOFFにされた後は、対象制御テーブルT1aの連続数Mは初期化されない。したがって、タイマからの通知に応じてバッファリングフラグがONに戻された後、保留数Nが1の状態で、ステップS230が実行されたら、直ちにバッファリングフラグはOFFにされる。
【0105】
一方、対象制御テーブルT1aの保留数Nが1でない場合(S220でNo)、プロトコル制御部12は、対象制御テーブルT1aの連続数Mを0に初期化する(S226)。対象受信バッファ15には複数の受信セグメントが記憶されており、ステップS230において当該複数の受信セグメントがまとめて宛先のアプリケーション13に通知されるからである。
【0106】
ステップS226、又はステップS223でNoの場合に続いて、プロトコル制御部12は、ステップS230を実行する。
【0107】
図19では、更に、ステップS270でYesの場合に、ステップS271が実行される。ステップS271において、プロトコル制御部12は、対象制御テーブルT1aのバッファリングフラグはONであるか否かを判定する。当該バッファリングフラグがONである場合(S271でYes)、プロトコル制御部12は、ステップS280及びS290を実行する。当該バッファリングフラグがOFFである場合、プロトコル制御部12は、ステップS300を実行する。すなわち、対象セグメントは、対象受信バッファ15に記憶されることなく、宛先のアプリケーション13に通知される。
【0108】
図19では、更に、ステップS280に続いて、ステップS281が実行される。ステップS281において、プロトコル制御部12は、保留数Nの値を1にする。
【0109】
上述したように、第二の実施の形態によれば、ネットワーク負荷が高い場合等、セグメントがまとめて受信されない場合において、無駄なバッファリング処理の実行を回避することができる。その結果、処理効率を向上させることができる。
【0110】
なお、上記では、保留数Nが1である場合に受信バッファ15のクリアが実行される状態が所定回数連続したときに、バッファリング処理が一定時間行われない例を示した。但し、保留数Nが1であるという条件は、保留数Nが所定数(例えば、2等)以下であるという条件に置き換えられてもよい。すなわち、保留数Nが所定数以下である場合に受信バッファ15のクリアが実行される状態が所定回数連続したときに、バッファリング処理が一定時間行われないようにしてもよい。
【0111】
次に、第三の実施の形態について説明する。第三の実施の形態では、第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第二の実施の形態と同様でよい。
【0112】
保留終了処理要求の直前に処理された処理要求に係る受信セグメントがMSS以上である場合、当該受信セグメントには後続セグメントが存在する可能性がある。そこで、第三の実施の形態のプロトコル制御部12は、このような場合において、保留終了処理要求に応じた処理は実行せずに、当該保留終了処理要求を処理待ちキュー14の最後尾に移動させる。
【0113】
図21は、保留終了処理要求を処理しないで最後尾に移動させる例を示す図である。図21では、保留終了処理要求が処理対象とされる時点において、当該保留終了処理要求の直前に処理された処理要求に係る受信セグメント2のセグメント長がMSSに一致する例が示されている。このような場合、プロトコル制御部12は、当該保留終了処理要求を、処理待ちキュー14の最後尾に移動させる。そうすることにより、例えば、図21に示されるように、当該保留終了処理要求の直後に、受信セグメント2の後続セグメントである受信セグメント3の処理要求が処理待ちキュー14に記憶されていた場合、処理効率を向上させることができる。すなわち、移動後の保留終了処理要求が処理されることにより、受信セグメント1、受信セグメント2、及び受信セグメント3をまとめて、宛先のアプリケーション13に通知することができるからである。
【0114】
但し、プロトコル制御部12は、受信バッファ15に記憶されている全ての受信セグメントのセグメント長の合計が所定値以上である場合、又は受信バッファ15に記憶されている受信セグメントの総数が所定数以上である場合には、保留終了処理要求の移動は行わない。すなわち、これらの場合、受信バッファ15に記憶されている全ての受信セグメントは、直ちに宛先のアプリケーション13に通知される。受信バッファ15の枯渇を防止するためである。
【0115】
以下、斯かる処理制御を実現するためにプロトコル制御部12が実行する処理について説明する。
【0116】
図22は、第三の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。図22中、図19と同一ステップには同一ステップ番号を付し、その説明は省略する。
【0117】
図22では、ステップS226の後に、ステップS231〜S234が実行される。ステップS231において、プロトコル制御部12は、対象制御テーブルT1aの「最終ポインタ」によって特定される受信セグメントのセグメント長はMSS以上であるか否かを判定する。なお、当該受信セグメントは、現在処理対象とされている保留終了処理要求の直前に処理された処理要求に係る受信セグメントに相当する。以下、当該受信セグメントを、「最終セグメント」という。なお、TCPオブションサイズが0でない場合、最終セグメントのセグメント長は、(MSS−TCPオプションサイズ)と比較されればよい。
【0118】
最終セグメントのセグメント長がMSS以上である場合(S231でYes)、プロトコル制御部12は、対象受信バッファ15に記憶されている全ての受信セグメントのセグメント長の合計は、所定値β未満であるか否かを判定する(S232)。所定値βは、受信バッファ15のサイズに応じて、受信バッファ15の枯渇を防止可能な値が設定されればよい。例えば、所定値βには、64KByteが設定される。なお、ステップS232では、対象受信バッファ15に記憶されている受信セグメントの総数が、所定数未満であるか否かが判定されてもよい。
【0119】
セグメント長の合計が所定値β未満である場合(S232でYes)、プロトコル制御部12は、保留数Nの値を1にする(S233)。続いて、プロトコル制御部12は、保留終了処理要求を処理待ちキュー14の待ち行列の最後尾に追加する(S234)。その結果、実質的又は擬似的に、処理対象とされている保留終了処理要求が、処理待ちキュー14の待ち行列の最後尾に移動される。
【0120】
なお、ステップS234に続いて、ステップS230は実行されない。
【0121】
一方、最終セグメントのセグメント長がMSS未満である場合(S231でNo)、又はセグメント長の合計が所定値β以上である場合(S232でNo)、ステップS230が実行される。
【0122】
なお、上記各実施の形態において、処理待ちキュー14は、処理要求記憶部の一例である。受信バッファ15は、データ記憶部の一例である。プロトコル制御部12は、制御部の一例である。
【0123】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【0124】
以上の説明に関し、更に以下の項を開示する。
(付記1)
通信装置が、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する受信データ処理方法。
(付記2)
前記通知する処理は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する処理を実行する付記1記載の受信データ処理方法。
(付記3)
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する付記1又は2記載の受信データ処理方法。
(付記4)
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する付記1乃至3いずれか一項記載の受信データ処理方法。
(付記5)
受信データの受信順に、受信データに関する処理要求の待ち行列を記憶する処理要求記憶部と、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行し、当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する制御部とを有し、
前記制御部は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する通信装置。
(付記6)
前記制御部は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する付記5記載の通信装置。
(付記7)
前記制御部は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する付記5又は6記載の通信装置。
(付記8)
前記制御部は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する付記5乃至7いずれか一項記載の通信装置。
(付記9)
通信装置に、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行させ、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知するプログラム。
(付記10)
前記通知する処理は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する付記9記載のプログラム。
(付記11)
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する付記9又は10記載のプログラム。
(付記12)
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する付記9乃至11いずれか一項記載のプログラム。
【符号の説明】
【0125】
10 受信装置
11 入出力制御部
12 プロトコル制御部
13 アプリケーション
14 処理待ちキュー
15 受信バッファ
20 送信装置
100 ドライブ装置
101 記録媒体
102 補助記憶装置
103 メモリ装置
104 CPU
105 インタフェース装置
B バス
【特許請求の範囲】
【請求項1】
通信装置が、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する受信データ処理方法。
【請求項2】
前記通知する処理は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する処理を実行する請求項1記載の受信データ処理方法。
【請求項3】
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する請求項1又は2記載の受信データ処理方法。
【請求項4】
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する請求項1乃至3いずれか一項記載の受信データ処理方法。
【請求項5】
受信データの受信順に、受信データに関する処理要求の待ち行列を記憶する処理要求記憶部と、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する制御部とを有し、
前記制御部は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する通信装置。
【請求項6】
通信装置に、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行させ、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知するプログラム。
【請求項1】
通信装置が、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する受信データ処理方法。
【請求項2】
前記通知する処理は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する処理を実行する請求項1記載の受信データ処理方法。
【請求項3】
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する請求項1又は2記載の受信データ処理方法。
【請求項4】
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する請求項1乃至3いずれか一項記載の受信データ処理方法。
【請求項5】
受信データの受信順に、受信データに関する処理要求の待ち行列を記憶する処理要求記憶部と、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する制御部とを有し、
前記制御部は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する通信装置。
【請求項6】
通信装置に、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行させ、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知するプログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【公開番号】特開2013−115576(P2013−115576A)
【公開日】平成25年6月10日(2013.6.10)
【国際特許分類】
【出願番号】特願2011−259442(P2011−259442)
【出願日】平成23年11月28日(2011.11.28)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
【公開日】平成25年6月10日(2013.6.10)
【国際特許分類】
【出願日】平成23年11月28日(2011.11.28)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
[ Back to top ]