JP2013115576A - 受信データ処理方法、通信装置、及びプログラム - Google Patents

Abstract

【課題】受信データのバッファリングによる応答性の低下を低減させること。
【解決手段】通信装置が、受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する。
【選択図】図５

Description

本発明は、受信データ処理方法、通信装置、及びプログラムに関する。

従来、ＴＣＰ（Transmission Control Protocol）に代表されるバイトストリーム型（バイト指向）の通信プロトコルを使用した通信において、通信プロトコルに応じた処理制御を行うプロトコル制御部は、受信したデータを即座に上位アプリケーションに渡していた。

図１は、受信データが即座に上位アプリケーションに渡される例を示す図である。図１では、送信装置５２０において、送信データがデータ１及びデータ２の二つのデータに分割されて受信装置５１０の上位アプリケーション宛に送信される例が示されている。

プロトコル制御部が受信データを即座に上位アプリケーションに渡す場合、プロトコル制御部と上位アプリケーションとの間での受信データの受け渡しは頻発する。したがって、受信データの受け渡しに要される処理のオーバーヘッドや、上位アプリケーション側での受信データの組み立て処理等によって処理効率が低下し、ＣＰＵ負荷が高まるという問題がある。

近年のコンピュータシステムにおいては、ネットワークの劇的な高速化に比べてＣＰＵ性能の向上が相対的に小さくなっている。したがって、ネットワーク通信のデータ量の増加に伴う、ＣＰＵ使用量の削減が求められている。

なお、バイトストリーム型の通信プロトコルとは、通信対象のデータを単なるバイトの列として扱う通信プロトコルをいう。バイトストリーム型の通信プロトコルでは、上位アプリケーションにとって意味の有る単位の区切りとは無関係に、データが分割又は結合されて送受信が行われる。したがって、上位アプリケーションは、プロトコル制御部より渡されたデータに関して、意味の有る単位に組み立てたり分割したりする必要がある。

特表２００２−５２７９４５号公報 特開２００５−１４３０９８号公報

プロトコル制御部が、データをバッファリングして、複数のデータをまとめて上位アプリケーションに渡すことにより、処理効率の向上を図ることができる。従来、最初のデータがバッファリングされてから一定時間経過後、又は一定データ長のデータがバッファリングされたときに、それまでにバッファリングされているデータがまとめて上位アプリケーションに渡されていた。

図２は、最初のデータがバッファリングされてから一定時間経過後に受信データが上位アプリケーションに渡される例を示す図である。図２において、プロトコル制御部は、受信されたデータを直ちに上位アプリケーションには渡さず、バッファに記憶する。最初のデータが受信されてから一定時間ｔが経過すると、プロトコル制御部は、バッファに記憶されているデータをまとめて上位アプリケーションに渡す。

しかしながら、上記のようなバッファリングでは、上位アプリケーションへの通知が遅延する結果、応答性が損なわれる場合がある。応答性とは、データが受信されてから、当該データが上位アプリケーションへ通知され、上位アプリケーションが当該データの処理を完了するまでの時間の短さのことをいう。データが受信されてから、上位アプリケーションへの通知が完了するまでの時間が短いほど、応答性は向上する。一般に、応答性が高いほどスループット（受信装置５１０の単位時間当たりの受信データの処理量）は向上する。

例えば、図２に示した例では、データ２が受信された時点で上位アプリケーションにデータ１及び２が通知されるのが効率的であるが、データ１のバッファリング時から一定時間が経過するまで、データ１及びデータ２の通知は遅延する。なお、バイトストリーム型の通信プロトコルでは、受信データが最後の受信データであるか否かをプロトコル制御部が判断することはできない。したがって、データ２の後続データが無い場合であっても、一定時間の待機は行われる。

一定時間の待機が行われる結果、プロトコル制御部のバッファに受信データが溜まり、データ通信のフロー制御に影響したり、バッファ枯渇が発生したりする可能性も有る。

そこで、一側面では、受信データのバッファリングによる応答性の低下を低減させることのできる受信データ処理方法、通信装置、及びプログラムの提供を目的とする。

一つの案では、通信装置が、受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する。

一態様によれば、受信データのバッファリングによる応答性の低下を低減させることができる。

受信データが即座に上位アプリケーションに渡される例を示す図である。 最初のデータがバッファリングされてから一定時間経過後に受信データが上位アプリケーションに渡される例を示す図である。 本発明の実施の形態における通信システムの構成例を示す図である。 本発明の実施の形態における受信装置のハードウェア構成例を示す図である。 本発明の実施の形態における受信装置の機能構成例を示す図である。 第一の実施の形態の受信装置が実行する処理手順の第一の例を説明するための図である。 処理待ちキュー及び受信バッファの状態の第一の例を示す図である。 処理待ちキュー及び受信バッファの状態の第二の例を示す図である。 処理待ちキュー及び受信バッファの状態の第三の例を示す図である。 処理待ちキュー及び受信バッファの状態の第四の例を示す図である。 第一の実施の形態の受信装置が実行する処理手順の第二の例を説明するための図である。 処理待ちキュー及び受信バッファの状態の第五の例を示す図である。 処理待ちキュー及び受信バッファの状態の第六の例を示す図である。 第一の実施の形態における受信セグメントの処理要求の受け付け時の処理手順の一例を説明するためのフローチャートである。 第一の実施の形態の処理待ちキューに記憶される処理要求の構成例を示す図である。 プロトコル処理前の受信セグメントの構成例を示す図である。 第一の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。 第一の実施の形態の受信バッファの構成例を示す図である。 第二の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。 第二の実施の形態の受信バッファの構成例を示す図である。 保留終了処理要求を処理しないで最後尾に移動させる例を示す図である。 第三の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。図３は、本発明の実施の形態における通信システムの構成例を示す図である。図３において、送信装置２０と受信装置１０とは、ＬＡＮ（Local Area Network）又はインターネット等のネットワークを介して通信可能とされている。なお、ネットワークの一部又は全部において、無線通信が利用されてもよい。

送信装置２０は、受信装置１０に対してデータを送信する情報処理装置である。受信装置１０は、送信装置２０より送信されるデータを受信する情報処理装置である。本実施の形態において、送信装置２０と受信装置１０との間のデータ通信には、バイトストリーム型（バイト指向）の通信プロトコルの一例として、ＴＣＰ（Transmission Control Protocol）が利用される。但し、ＴＣＰ以外のバイトストリーム型の通信プロトコルが利用されてもよい。

したがって、送信装置２０から受信装置１０へ送信されるデータは、セグメント単位に分割されて送信される。セグメントとは、送信用に分割されたデータをいい、セグメントごとにＩＰヘッダ及びＴＣＰヘッダ等が付与される。なお、送信データが一つのセグメントに収まる場合は、当該送信データは、分割されずに一つのセグメントとされる。

なお、送信装置２０及び受信装置１０という名称は、便宜的なものに過ぎない。すなわち、通信手順の進行に応じて、送信装置２０がデータの受信側になってもよいし、受信装置１０がデータの送信側になってもよい。

図４は、本発明の実施の形態における受信装置のハードウェア構成例を示す図である。図４の受信装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

受信装置１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って受信装置１０に係る機能を実行する。インタフェース装置１０５は、例えば、ネットワークカードであり、ネットワークに接続するためのインタフェースとして用いられる。

なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

なお、送信装置２０も、例えば、図４に示されるハードウェアを有している。

図５は、本発明の実施の形態における受信装置の機能構成例を示す図である。図５において、受信装置１０は、入出力制御部１１、プロトコル制御部１２、及び一以上のアプリケーション１３等を有する。

入出力制御部１１は、インタフェース装置１０５によって受信される受信データを、インタフェース装置１０５より読み出す。入出力制御部１１は、読み出したデータに関する処理要求を、セグメント単位でプロトコル制御部１２に入力する。なお、受信データは、入出力制御部１１によって読み出されるまで、インタフェース装置１０５のメモリ内に滞留する。入出力制御部１１は、例えば、受信装置１０にインストールされた、インタフェース装置１０５に対応したデバイスドライバとしてのプログラムがＣＰＵ１０４に実行させる処理によって実現される。以下、セグメント単位の受信データを、「受信セグメント」という。

プロトコル制御部１２は、入出力制御部１１からの処理要求に応じ、当該処理要求に係る受信セグメントに関して、通信プロトコル（ＴＣＰ）に従った処理を実行する。以下、通信プロトコルに従った処理を「プロトコル処理」という。プロトコル処理の一例として、ＩＰヘッダの解析処理及びＴＣＰヘッダの解析処理等が挙げられる。プロトコル処理によって、例えば、宛先（コネクション）の識別、改竄の有無のチェック、及び受信順序の正否等が判定される。宛先は、ＩＰヘッダに含まれているＩＰアドレスと、ＴＣＰヘッダに含まれているポート番号とによって識別される。なお、本実施の形態では、一つのアプリケーション１３は、一つのコネクションを有することとする。すなわち、宛先が識別されることによって、受信セグメントの通知先（又は伝達先）のアプリケーション１３が特定されることになる。改竄の有無のチェックは、ＩＰチェックサム及びＴＣＰチェックサム等を用いて行われる。受信順序の正否は、シーケンス番号及びＡＣＫ番号等に基づいて判定される。

プロトコル制御部１２は、処理待ちキュー１４及び受信バッファ１５等の記憶部を利用する。処理待ちキュー１４は、入出力制御部１１からの処理要求の待ち行列をＦＩＦＯ（First-In First-Out）形式で記憶する記憶部である。受信バッファ１５は、処理待ちキュー１４に記憶された処理要求に係る受信セグメントのうち、プロトコル処理が実行された受信セグメントを記憶する記憶部である。処理待ちキュー１４は、複数の宛先（コネクション）に対して共通であるのに対し、受信バッファ１５は、宛先（コネクション）ごとに形成される。受信バッファ１５に記憶された受信セグメントは、所定のタイミングで、当該受信バッファ１５に係る宛先のアプリケーション１３に通知（又は伝達）される。処理待ちキュー１４及び受信バッファ１５は、例えば、メモリ装置１０３を用いて実現可能である。

なお、プロトコル制御部１２は、受信装置１０にインストールされたプログラムがＣＰＵ１０４に実行させる処理によって実現される。

アプリケーション１３は、本実施の形態において、送信装置２０より送信されるデータの宛先となるプログラムである。アプリケーション１３は、例えば、受信データを利用して、所定の処理を実行する。

以下、受信装置１０が実行する処理手順について説明する。図６は、第一の実施の形態の受信装置が実行する処理手順の第一の例を説明するための図である。

インタフェース装置１０５においてデータが受信されると、入出力制御部１１は、インタフェース装置１０５に対して読み出し要求（ＲＥＡＤ要求）を発行し、受信データをインタフェース装置１０５より読み出す（Ｓ１０１）。ここでは、二つのセグメントが受信されていることとする。したがって、二つの受信セグメントが読み出される。通常、Ｎセグメント分のデータが送信装置２０より送信された場合、Ｎセグメント以下の複数セグメントがまとめて受信される。ここで、Ｎは２以上である。

続いて、入出力制御部１１は、各受信セグメントの処理要求を、受信セグメントの受信順（読み出し順）にプロトコル制御部１２に入力する（Ｓ１０２）。入力された処理要求は、プロトコル制御部１２の処理待ちキュー１４に登録される。ステップＳ１０２の実行直後において、処理待ちキュー１４及び受信バッファ１５は、例えば、図７に示されるような状態になる。

図７は、処理待ちキュー及び受信バッファの状態の第一の例を示す図である。図７において、処理待ちキュー１４には、１番目の受信セグメント（受信セグメント１）の処理要求と、２番目の受信セグメント（受信セグメント２）の処理要求との待ち行列が記憶されている。一方、受信バッファ１５は空の状態である。

続いて、プロトコル制御部１２は、処理待ちキュー１４の先頭の処理要求である、受信セグメント１の処理要求を取得し、当該処理要求に応じて受信セグメント１に関してプロトコル処理を実行する（Ｓ１０３）。なお、取得された処理要求は、処理待ちキュー１４より削除される。

続いて、プロトコル制御部１２は、プロトコル処理が行われた受信セグメント１を、受信セグメント１の宛先に対応する受信バッファ１５に記憶する（Ｓ１０４）。受信セグメント１を記憶する前において、受信バッファ１５は空である。そこで、プロトコル制御部１２は、処理待ちキュー１４に対して、保留終了処理要求を追加する（Ｓ１０５）。保留終了処理要求とは、受信バッファ１５における受信セグメントのバッファリング（保留）の終了の要求である。受信バッファ１５における受信セグメントのバッファリングの終了は、受信バッファ１５のクリア、すなわち、受信バッファ１５に記憶されている全ての受信セグメントを、宛先のアプリケーション１３に通知することを意味する。

ステップＳ１０５の実行直後において、処理待ちキュー１４及び受信バッファ１５は、例えば、図８に示されるような状態になる。

図８は、処理待ちキュー及び受信バッファの状態の第二の例を示す図である。図８において、既に処理された受信セグメント１の処理要求は処理待ちキュー１４より削除され、受信セグメント１は受信バッファ１５に記憶されている。また、保留終了処理要求が、処理待ちキュー１４における処理要求の待ち行列の最後尾に追加されている。

続いて、プロトコル制御部１２は、現時点において処理待ちキュー１４の先頭の処理要求である受信セグメント２の処理要求を取得し、当該処理要求に応じて受信セグメント２に関してプロトコル処理を実行する（Ｓ１０６）。続いて、プロトコル制御部１２は、プロトコル処理が行われた受信セグメント２を、受信セグメント２の宛先に対応する受信バッファ１５に記憶する（Ｓ１０７）。受信セグメント２の宛先は、受信セグメント１と同じであるとする。したがって、受信セグメント２は、受信セグメント１と同じ受信バッファ１５に記憶される。したがって、受信セグメント２を記憶する前において、受信バッファ１５は空ではない。すなわち、受信バッファ１５には受信セグメント１が記憶されている。したがって、プロトコル制御部１２は、処理待ちキュー１４に対して、保留終了処理要求は追加しない。

ステップＳ１０７の実行直後において、処理待ちキュー１４及び受信バッファ１５は、例えば、図９に示されるような状態になる。

図９は、処理待ちキュー及び受信バッファの状態の第三の例を示す図である。図８において、既に処理された受信セグメント２の処理要求は処理待ちキュー１４より削除され、受信セグメント２は、受信セグメント１と共に受信バッファ１５に記憶されている。

続いて、プロトコル制御部１２は、現時点において処理待ちキュー１４の先頭の処理要求である保留終了処理要求を処理対象とする。処理対象が保留終了処理要求であることに応じ、プロトコル制御部１２は、受信バッファ１５に記憶されている全ての受信セグメントを、当該受信バッファ１５に対応する宛先であるアプリケーション１３にまとめて通知する（Ｓ１０８）。

ステップＳ１０７の実行直後において、処理待ちキュー１４及び受信バッファ１５は、例えば、図１０に示されるような状態になる。

図１０は、処理待ちキュー及び受信バッファの状態の第四の例を示す図である。図１０において、処理待ちキュー１４及び受信バッファ１５は、共に空の状態となっている。

図６に示される処理によれば、受信セグメント１及び受信セグメント２をまとめた受信データに関して、待ち時間が発生することなくまとめてアプリケーション１３に通知することができる。また、アプリケーション１３への通知はバッファリングされた全ての受信セグメントに関してまとめて実行されるため、アプリケーション１３とプロトコル制御部１２との間のデータの受け渡しの回数を低減させることができる。その結果、バッファリングによる応答性の低下を低減させることができ、また、ＣＰＵ１０４の負荷の増加を抑制することができる。更に、待ち時間のタイマの設定が不要となる点においても、ＣＰＵ１０４の負荷の増加を抑制することができる。

なお、上記では、便宜上、二つの受信セグメントがまとめてアプリケーション１３に通知される例を示したが、通常は、更に多くの受信セグメントの処理要求がまとめて処理待ちキュー１４に記憶される可能性が高い。特に、入出力制御部１１においてもバッファリングが行われる場合は、処理待ちキュー１４に記憶される受信セグメント数が複数になる可能性が高い。このことは、複数の受信セグメントごとに、保留終了処理要求が処理待ちキュー１４に追加される可能性が高いことを意味する。処理待ちキュー１４にまとめて記憶される処理要求が多くなればなるほど、保留終了処理要求に基づく処理の効率化の効果が大きくなる。

但し、ネットワーク負荷の状態によっては、複数のセグメントがまとめて受信されない場合も考えられる。そこで、受信セグメント２の転送に遅延が発生した場合の処理手順について説明する。

図１１は、第一の実施の形態の受信装置が実行する処理手順の第二の例を説明するための図である。

ステップＳ１１１において、入出力制御部１１は、インタフェース装置１０５において受信されている受信セグメント１を読み出す（Ｓ１１１）。続いて、入出力制御部１１は、受信セグメント１の処理要求を、プロトコル制御部１２に入力する（Ｓ１１２）。ステップＳ１１２の実行直後において、処理待ちキュー１４及び受信バッファ１５は、例えば、図１２に示されるような状態になる。

図１２は、処理待ちキュー及び受信バッファの状態の第五の例を示す図である。図１２において、処理待ちキュー１４には、受信セグメントの処理要求のみが記憶されている。なお、受信バッファ１５は空の状態である。

続いて、プロトコル制御部１２は、処理待ちキュー１４の先頭の処理要求である受信セグメント１の処理要求を取得し、当該処理要求に応じて受信セグメント１に関してプロトコル処理を実行する（Ｓ１１３）。続いて、プロトコル制御部１２は、プロトコル処理が行われた受信セグメント１を、受信セグメント１の宛先に対応する受信バッファ１５に記憶する（Ｓ１１４）。受信セグメント１を記憶する前において、受信バッファ１５は空である。そこで、プロトコル制御部１２は、処理待ちキュー１４に対して、保留終了処理要求を追加する（Ｓ１１５）。

ステップＳ１１５の実行直後において、処理待ちキュー１４及び受信バッファ１５は、例えば、図１３に示されるような状態になる。

図１３は、処理待ちキュー及び受信バッファの状態の第六の例を示す図である。図１３において、既に処理された受信セグメント１の処理要求は処理待ちキュー１４より削除され、受信セグメント１は受信バッファ１５に記憶されている。また、保留終了処理要求が、処理待ちキュー１４に追加されている。

続いて、プロトコル制御部１２は、現時点において処理待ちキュー１４の先頭の処理要求である保留終了処理要求を処理対象とする。処理対象が保留終了処理要求であることに応じ、プロトコル制御部１２は、受信バッファ１５に記憶されている受信セグメント１を受信セグメント１の宛先であるアプリケーション１３に通知する（Ｓ１１６）。

その後、受信セグメント２が受信されると、入出力制御部１１は、受信セグメント２をインタフェース装置１０５より読み出す（Ｓ１１７）。続いて、入出力制御部１１は、受信セグメント２の処理要求を、プロトコル制御部１２に入力する（Ｓ１１８）。したがって、受信セグメント２の処理要求が処理待ちキュー１４に記憶される。

続いて、プロトコル制御部１２は、処理待ちキュー１４の先頭の処理要求である受信セグメント２の処理要求を取得し、当該処理要求に応じて受信セグメント２に関してプロトコル処理を実行する（Ｓ１１９）。ここで、プロトコル制御部１２は、受信セグメント２のセグメント長に基づいて、後続のセグメントは無いと判定した場合、受信セグメント２を受信バッファ１５に記憶することなく、即座に宛先のアプリケーション１３に通知する（Ｓ１２０）。そのため、バッファリングによる待ちが発生しないことに加えて、バッファリングによるオーバーヘッドも削減できる。後続のセグメントとは、既に受信されている受信セグメントと同一のデータに含まれるセグメントであって、送信装置２０から既に送信済みであり、ネットワーク中において転送中であるセグメントや、これから送信装置２０により送信されるセグメント等をいう。「同一のデータ」とは、アプリケーション１３にとって意味のあるデータの区切り間のデータをいう。

なお、セグメント長に基づく後続のセグメントの有無の判定は、図１１の受信セグメント１に関しても行われる。但し、受信セグメント１については、後続のセグメントは無いと推定きなかった場合であるとする。したがって、受信セグメント１は、受信バッファ１５に記憶される。

図１１のように、受信セグメント間に遅延が発生する場合は、受信セグメントごとに保留終了処理要求が処理待ちキュー１４に追加され、受信セグメントごとにアプリケーション１３への通知が行われることになる。したがって、バッファリングによる待ち時間の発生は回避できるが、アプリケーション１３とプロトコル制御部１２とのデータの受け渡しは頻発する。但し、本実施の形態では、受信セグメントの受け渡しによる負荷の増加よりも、受信セグメントを即時的に受け渡すことによる応答性の向上の方が重要であると考える。また、処理が遅延しているため、受け渡し処理が頻発による付加の増加は、遅延してない場合に比べて非常に小さいと考えられる。

ステップＳ１２０において説明したように、本実施の形態において、プロトコル制御部１２は、処理対象のセグメントのセグメント長に基づいて後続セグメントの有無の判定を行う。これにより、バッファリングの必要がない場合、例えば、複数セグメントではなく１セグメントに収まるデータが受信された場合等において、バッファリングによるオーバーヘッドの発生を回避することができる。

セグメント長に基づく後続セグメントの有無の判定方法の一例について説明する。

多くのＴＣＰ／ＩＰの実装系では、セグメントが伝送路で分割されないように、ＭＳＳ（Maximum Segment Size：最大セグメントサイズ）が設定される。ＭＳＳは、伝送路に流すことのできる最大データ長を示すＭＴＵ（Maximum Transmission Unit）からＩＰヘッダサイズ及びＴＣＰヘッダサイズを引いた値である。送信装置２０は、ＭＳＳを超えるデータを送信しようとすると、ＭＳＳごとのセグメントに分割し、各セグメントを伝送路に送信する。受信装置１０では分割されたセグメントをそのまま受信するため、受信セグメントのサイズ（セグメント長）がＭＳＳと等しければ、後続セグメントが存在する可能性は高いと考えられる。そこで、受信セグメントのセグメント長がＭＳＳと等しい場合、プロトコル制御部１２は、後続セグメントは存在すると判定又は推定し、バッファリング処理を実行する。

また、ＴＣＰの実装によっては、プロトコル処理の後、セグメント長がＭＳＳよりも大きい受信セグメントが処理される場合がある。セグメント長がＭＳＳよりも大きい受信セグメントの処理は、ネットワークにおいてセグメントの順序が逆転したり、セグメントが消失して再送が行われたりしたときに、受信装置１０のＴＣＰの順序制御により複数セグメントがまとめて処理された場合に行われる。したがって、セグメント長がＭＳＳよりも大きい受信セグメントが処理される場合も後続セグメントが存在する可能性が有る。そこで、プロトコル制御部１２は、セグメント長がＭＳＳより大きい受信セグメントを処理する場合も、バッファリング処理を行う。

一方、受信セグメントのセグメント長がＭＳＳ未満である場合、送信装置２０がセグメントの分割を実行しなかったデータ長であった可能性が高く、後続セグメントが存在しない可能性が高い。そこで、受信セグメントのセグメント長がＭＳＳ未満である場合、プロトコル制御部１２は、後続セグメントは存在しないと判定又は推定し、バッファリング処理を実行しない。なお、送信装置２０が送信したデータが最大セグメントサイズと一致する場合も有る。この場合、受信装置１０では、後続セグメントが実際には存在しないにもかかわらず、後続セグメントが有ると判定される。したがって、この場合、バッファリングは行われる。但し、当該セグメントに続いて保留終了処理要求が処理待ちキュー１４に追加される可能性が高い。したがって、当該セグメントは、即時的にアプリケーション１３に通知される。

なお、ＴＣＰ通信において、ＭＳＳの値は、コネクション確立時（通信開始時）に受信装置１０と送信装置２０との間のネゴシエーションにより決定され、コネクション確立要求及びコネクション確立応答のＴＣＰヘッダに含まれる。したがって、プロトコル制御部１２は、当該ＴＣＰヘッダよりＭＳＳを取得し、例えば、メモリ装置１０３に記憶しておく。

また、タイムスタンプオプション等のＴＣＰオプションが使用される場合、送信装置２０において、ＭＳＳからＴＣＰオプションサイズを引いた値にセグメント分割が行われる。したがって、ＴＣＰオプションが使用される場合、受信装置１０における後続セグメントの有無の判定には、ＭＳＳからＴＣＰオプションサイズを引いた値が採用される。

ところで、ＴＣＰ通信ではＰＳＨフラグの有無に基づいて後続セグメントの有無を判定することも考えられる。ＰＳＨフラグとは、ＴＣＰヘッダに含まれるＴＣＰフラグの一つであり、「ＰＳＨフラグ付きのＴＣＰセグメントを受け取ったら、（バッファリングせずに）速やかに上位プロトコル（上位アプリケーション１３）へ渡す」ことを意味する。ＴＣＰデータ送信時のＰＳＨフラグの付加の方法はＲＦＣ（Request for Comments）で規定されている。ＰＳＨフラグを利用して後続セグメントの有無を判定することにより、待ち時間の少ないバッファリングが可能である。しかし、図１１のように途中のセグメントの転送が遅れた場合や、送信装置２０のＰＳＨフラグの実装により、バッファリング時間が生じるといった問題点がある。また、ＰＳＨフラグは送信装置２０の実装に依存する。そのため、ほとんどの実装系ではＰＳＨフラグを利用したバッファリングは行われておらず、またＰＳＨフラグの有無が意識されていないのが現状である。

したがって、本実施の形態ではＰＳＨフラグに基づく後続セグメントの有無の判定は行わない。但し、ＰＳＨフラグの基づく後続セグメントの有無の判定と、本実施の形態におけるセグメント長に基づく後続セグメントの有無の判定との双方が重複して行われてもよい。

続いて、図６及び図１１等において説明した処理手順を実現するために、プロトコル制御部１２が実行する処理について詳細に説明する。

図１４は、第一の実施の形態における受信セグメントの処理要求の受け付け時の処理手順の一例を説明するためのフローチャートである。

受信セグメントの処理要求が入出力制御部１１より入力されると（Ｓ２０１でＹｅｓ）、プロトコル制御部１２は、当該処理要求を処理待ちキュー１４の最後尾に追加する（Ｓ２０２）。

図１５は、第一の実施の形態の処理待ちキューに記憶される処理要求の構成例を示す図である。既述したように、処理待ちキュー１４に記憶される処理要求には、受信セグメントの処理要求と保留終了処理要求とがある。

受信セグメントの処理要求は、例えば、処理要求コード、次の処理要求へのポインタ、及び受信セグメントへのポインタ等を含む。処理要求コードは、処理要求の種別を識別するためのコードである。受信セグメントの処理要求については、受信セグメントの処理要求であることを示す値が処理要求コードに設定される。次の処理要求へのポインタは、処理待ちキュー１４の待ち行列において、次の順番の処理要求へのポインタ（関連付け情報）である。受信セグメントへのポインタは、当該処理要求に関して処理対象とされる受信セグメントの実体へのポインタである。

一方、保留終了処理要求は、処理要求コード、次の処理要求へのポインタ、及び受信バッファへのポインタ等を含む。処理要求コード及び次の処理要求へのポインタについては、受信セグメントの処理要求と同様である。但し、保留終了処理要求の処理要求コードには、保留終了処理要求であることを示す値が設定される。受信バッファへのポインタは、当該保留終了処理要求が対応する受信バッファ１５へのポインタである。すなわち、受信バッファへのポインタは、当該保留終了処理要求が処理対象とされた際に、クリアすべき受信バッファ１５へのポインタである。

なお、ステップＳ２０２において追加されるのは、受信セグメントの処理要求である。当該処理要求を処理要求Ｒとし、処理要求Ｒが処理待ちキュー１４に追加される前の最後尾の処理要求を処理要求Ｅとすると、処理要求Ｅの「次の処理要求へのポインタ」には処理要求Ｒのアドレスが設定される。また、処理要求Ｒの「次の処理要求へのポインタ」には、例えば、終端又は末尾を示すＮＵＬＬが設定される。処理要求Ｒの「受信セグメントへのポインタ」には、入出力制御部１１より受け付けた受信セグメントへのポインタが設定される。この時点において、受信セグメントは、例えば、図１６に示されるような構成を有する。

図１６は、プロトコル処理前の受信セグメントの構成例を示す図である。図１６に示されるように、処理待ちキュー１４に記憶された時点、すなわち、プロトコル処理前の受信セグメントは、例えば、ネットワークインタフェース層ヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、及びユーザデータ等を含む。

ネットワークインタフェース層ヘッダの形式は、使用される物理的なネットワークの種類に依存する。ユーザデータは、アプリケーション１３にとって意味の有るデータである。

続いて、処理待ちキュー１４に記憶された処理要求に応じてプロトコル制御部１２が実行する処理手順について説明する。図１７は、第一の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。

ステップＳ２１０において、プロトコル制御部１２は、処理待ちキュー１４における待ち行列の先頭の処理要求を取得する。続いて、プロトコル制御部１２は、取得された処理要求の処理要求コードを参照して、取得された処理要求（以下、「対象処理要求」という。）が保留終了処理要求であるか否かを判定する（Ｓ２２０）。対象処理要求が保留終了処理要求である場合（Ｓ２２０でＹｅｓ）、当該保留終了処理要求の「受信バッファへのポインタ」によって特定される受信バッファ１５に記憶されている受信セグメントを、当該受信バッファ１５が対応する宛先のアプリケーション１３に通知する（Ｓ２３０）。

一方、対象処理要求が、受信セグメントの処理要求である場合（Ｓ２２０でＮｏ）、プロトコル制御部１２は、対象処理要求の「受信セグメントへのポインタ」によって特定される受信セグメントに関して、プロトコル処理を実行する（Ｓ２４０）。プロトコル処理において、ＴＣＰオプションサイズの算出も行われる。なお、対象処理要求の「受信セグメントへのポインタ」によって特定される受信セグメントを、以下「対象セグメント」という。

続いて、プロトコル制御部１２は、対象セグメントの宛先に対応する受信バッファ１５に１以上のセグメントが記憶されているか否かを判定する（Ｓ２５０）。当該受信バッファ１５に１以上のセグメントが記憶されている場合（Ｓ２５０でＹｅｓ）、プロトコル制御部１２は、対象セグメントを当該受信バッファ１５に記憶する（Ｓ２６０）。

図１８は、第一の実施の形態における受信バッファの構成例を示す図である。各受信バッファ１５は、制御テーブルＴ１を含む。制御テーブルは、各種制御情報、先頭ポインタ、及び最終ポインタ等の情報を記憶する。各種制御情報は、例えば、対応する宛先（ポート番号）等、各種の制御情報である。先頭ポインタは、当該受信バッファ１５において先頭の受信セグメントへのポインタである。最終ポインタは、当該受信バッファ１５において末尾の受信セグメントへのポインタである。

各受信セグメントは、次のセグメントへのポインタ、制御テーブルへのポインタ、全保留データ長、セグメント長、ＩＰヘッダ、ＴＣＰヘッダ、及びユーザデータ等を含む。図１６との比較より明らかなように、次のセグメントへのポインタ、制御テーブルへのポインタ、全保留データ長、及びセグメント長は、プロトコル処理又は受信バッファ１５への記憶時において、プロトコル制御部１２によって付与される情報である。

次のセグメントへのポインタは、当該受信バッファ１５において、次の受信セグメントへのポインタである。制御テーブルへのポインタは、当該受信バッファ１５の制御テーブルＴ１へのポインタである。全保留データ長は、当該受信バッファ１５に記憶されている全ての受信セグメントのセグメント長の合計である。全保留データ長は、受信バッファ１５の先頭の受信セグメントに関してのみ有効であってもよい。セグメント長は、当該受信セグメントのセグメント長である。

したがって、ステップＳ２６０では、対象セグメントの宛先に対応する受信バッファ１５の制御テーブルＴ１の保留最終ポインタによって特定される受信セグメントの「次のセグメントへのポインタ」に、対象セグメントへのポインタが設定される。また、対象セグメントの「次のセグメントへのポインタ」には、終端又は末尾を示すＮＵＬＬが設定される。また、当該制御テーブルＴ１の先頭ポインタによって特定される受信セグメントの「全保留データ長」に、対象セグメントのセグメント長が加算される。更に、当該制御テーブルＴ１の最終ポインタに、対象セグメントへのポインタが設定される。

一方、対象セグメントの宛先に対応する受信バッファ１５が空である場合（Ｓ２５０でＮｏ）、プロトコル制御部１２は、対象セグメントのセグメント長は、ＭＳＳ以上であるか否かを判定する（Ｓ２７０）。なお、ＴＣＰオプションサイズが０より大きい場合は、対象セグメントのセグメント長は、（ＭＳＳ−ＴＣＰオプションサイズ）と比較される。

対象セグメントのセグメント長が、ＭＳＳ以上である場合（Ｓ２７０でＹｅｓ）、プロトコル制御部１２は、対象セグメントを、対象セグメントの宛先に対応する受信バッファ１５に記憶する（Ｓ２８０）。続いて、プロトコル制御部１２は、保留終了処理要求を処理待ちキュー１４の待ち行列の最後尾に追加する（Ｓ２９０）。当該保留終了処理要求の「受信バッファへのポインタ」には、対象セグメントの宛先に対応する受信バッファ１５へのポインタが設定される。

一方、対象セグメントのセグメント長が、ＭＳＳ未満である場合（Ｓ２７０でＮｏ）、プロトコル制御部１２は、対象セグメントの宛先のアプリケーション１３に対象セグメントを通知する（Ｓ３００）。すなわち、対象セグメントは、受信バッファ１５に記憶されない。

なお、図１７によれば、対象セグメントの宛先に対応する受信バッファ１５に先着の受信セグメントが記憶されている場合（Ｓ２５０でＹｅｓ）、対象セグメントに関して、ＭＳＳ未満であるか否かを問わず、受信バッファ１５への記憶が行われる。先着の受信セグメントが記憶されている場合に対象セグメントがＭＳＳ未満であることを理由として受信バッファ１５のクリアを行ったとしても、いずれ保留終了処理要求によって受信バッファ１５のクリアが行われる。したがって、先着の受信セグメントが記憶されている場合に対象セグメントがＭＳＳ未満であることを理由として受信バッファ１５のクリアを行ったとしても、処理ステップの削減の効果は低いと考えられるからである。また、対象セグメントのセグメント長とＭＳＳとを比較する必要があり、却って処理ステップの増加を招くからである。

上述したように、第一の実施の形態によれば、受信セグメントの処理要求が処理される際に、当該受信セグメントの宛先に対応する受信バッファ１５が空であれば、保留終了処理要求が処理待ちキュー１４の最後尾（末尾）に追加される。保留終了処理要求が処理対象とされるまでは、各処理要求に係る受信セグメントは受信バッファ１５に記憶され、保留終了処理要求が処理対象とされた時点で、当該保留終了処理要求に係る受信バッファ１５内の受信セグメントはまとめて宛先のアプリケーション１３に通知される。

その結果、一定時間経過又は一定データ長のバッファリングによる応答性の低下を低減させることができる。また、プロトコル制御部１２とアプリケーション１３との間のセグメントの受け渡しが頻発するのを抑制することができ、当該受け渡しによるオーバーヘッドを削減することができる。

次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。

第一の実施の形態では、セグメント長がＭＳＳ以上である受信セグメントは、常にバッファリングされる。しかし、斯かる受信セグメントをバッファリングしたにも拘わらず、後続の受信セグメントが無かった場合、すなわち、バッファリング処理をしたにも拘わらず、複数の受信セグメントをまとめることができなかった場合、バッファリング処理が無駄となってしまう。このような状況は、例えば、図１１に示されるように、ネットワークの転送速度が、受信装置１０における受信セグメントの処理速度に対して遅い場合に発生しうる。

そこで、第二の実施の形態において、プロトコル制御部１２は、所定回数以上連続で、アプリケーション１３に通知される受信セグメントが一つである受信バッファ１５（コネクション）に関しては、バッファリング処理を一定時間実施しないようにする。一定時間経過後に、ネットワーク負荷が低下して、バッファリング処理の効果が得られるようになっていれば、プロトコル制御部１２は、バッファリング処理を再開する。

なお、斯かる処理制御は、宛先（コネクション）ごとに行われるため、通信相手の違いによる回線速度の違いに個別に対応することができる。

以下、斯かる処理制御を実現するためにプロトコル制御部１２が実行する処理について説明する。

図１９は、第二の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。図１９中、図１７と同一ステップには同一ステップ番号を付し、その説明は省略する。

図１９では、ステップＳ２６０の後にステップＳ２６１が実行される。ステップＳ２６１において、プロトコル制御部１２は、変数Ｎに１を加算する。変数Ｎは、対象セグメントの宛先に対応する受信バッファ１５に記憶されている受信セグメントの数が格納される変数である。変数Ｎを、以下「保留数Ｎ」という。なお、コネクションの開始時において、保留数Ｎの値は、０に初期化される。保留数Ｎは、例えば、受信バッファ１５の制御テーブルＴ１において管理されてもよい。

図２０は、第二の実施の形態の受信バッファの構成例を示す図である。図２０中、図１８と同一部分については、説明を省略する。

第二の実施の形態の制御テーブルＴ１ａは、更に、保留数Ｎ、連続数Ｍ、及びバッファリングフラグ等を含む。保留数Ｎは、上記した通りである。連続数Ｍは、保留数Ｎが１である状態における受信セグメントのアプリケーション１３への通知が連続した回数である。すなわち、１つの受信セグメントのみがバッファリングされている状態における受信セグメントのアプリケーション１３への通知が連続して発生した回数である。連続数Ｍの初期値は０である。バッファリングフラグは、バッファリングを行うか否かを示すフラグ変数である。バッファリングフラグの初期値は、ＯＮである。ＯＮは、バッファリングを行うことを示す。ＯＦＦは、バッファリングを行わないことを示す。

図１９では、また、対象処理要求が保留終了処理要求である場合（Ｓ２２０でＹｅｓ）において、ステップＳ２３０が実行される前に、ステップＳ２２１〜Ｓ２２７が実行される。

ステップＳ２２１において、プロトコル制御部１２は、対象処理要求である保留終了処理要求の「受信バッファへのポインタ」によって特定される受信バッファ１５の制御テーブルＴ１ａの保留数Ｎの値は１であるか否かを判定する。すなわち、当該受信バッファ１５に記憶されている受信セグメントは一つであるか否かが判定される。以下、当該受信バッファ１５を「対象受信バッファ１５」といい、当該制御テーブルＴ１ａを、「対象制御テーブルＴ１ａ」という。

保留数Ｎが１である場合（Ｓ２２１でＹｅｓ）、プロトコル制御部１２は、連続数Ｍに１を加算する（Ｓ２２２）。続いて、プロトコル制御部１２は、連続数Ｍが閾値α以上であるか否かを判定する（Ｓ２２３）。閾値αは、１つの受信セグメントのみがバッファリングされている状態における受信セグメントのアプリケーション１３への通知が何回以上連続したらバッファリングを停止するかを規定する閾値である。閾値αとして、例えば、「１０」が設定される。

連続数Ｍが閾値α以上である場合（Ｓ２２３でＹｅｓ）、プロトコル制御部１２は、対象制御テーブルＴ１ａのバッファリングフラグをＯＦＦにする（Ｓ２２４）。すなわち、対象受信バッファ１５に関してバッファリングは行わないことが設定される。続いて、プロトコル制御部１２は、タイマを起動させる（Ｓ２２５）。ここでいうタイマは、バッファリングフラグをＯＦＦのままとする一定時間を計測するタイマである。一定時間が経過すると、一定時間が経過したことが、タイマによってプロトコル制御部１２に通知される。プロトコル制御部１２は、タイマからの通知に応じて、バッファリングフラグをＯＮに戻す。そうすることにより、プロトコル制御部１２は、バッファリングが行われない状態が無制限に継続してしまうのを回避する。なお、一定時間バッファリングフラグがＯＦＦにされた後は、対象制御テーブルＴ１ａの連続数Ｍは初期化されない。したがって、タイマからの通知に応じてバッファリングフラグがＯＮに戻された後、保留数Ｎが１の状態で、ステップＳ２３０が実行されたら、直ちにバッファリングフラグはＯＦＦにされる。

一方、対象制御テーブルＴ１ａの保留数Ｎが１でない場合（Ｓ２２０でＮｏ）、プロトコル制御部１２は、対象制御テーブルＴ１ａの連続数Ｍを０に初期化する（Ｓ２２６）。対象受信バッファ１５には複数の受信セグメントが記憶されており、ステップＳ２３０において当該複数の受信セグメントがまとめて宛先のアプリケーション１３に通知されるからである。

ステップＳ２２６、又はステップＳ２２３でＮｏの場合に続いて、プロトコル制御部１２は、ステップＳ２３０を実行する。

図１９では、更に、ステップＳ２７０でＹｅｓの場合に、ステップＳ２７１が実行される。ステップＳ２７１において、プロトコル制御部１２は、対象制御テーブルＴ１ａのバッファリングフラグはＯＮであるか否かを判定する。当該バッファリングフラグがＯＮである場合（Ｓ２７１でＹｅｓ）、プロトコル制御部１２は、ステップＳ２８０及びＳ２９０を実行する。当該バッファリングフラグがＯＦＦである場合、プロトコル制御部１２は、ステップＳ３００を実行する。すなわち、対象セグメントは、対象受信バッファ１５に記憶されることなく、宛先のアプリケーション１３に通知される。

図１９では、更に、ステップＳ２８０に続いて、ステップＳ２８１が実行される。ステップＳ２８１において、プロトコル制御部１２は、保留数Ｎの値を１にする。

上述したように、第二の実施の形態によれば、ネットワーク負荷が高い場合等、セグメントがまとめて受信されない場合において、無駄なバッファリング処理の実行を回避することができる。その結果、処理効率を向上させることができる。

なお、上記では、保留数Ｎが１である場合に受信バッファ１５のクリアが実行される状態が所定回数連続したときに、バッファリング処理が一定時間行われない例を示した。但し、保留数Ｎが１であるという条件は、保留数Ｎが所定数（例えば、２等）以下であるという条件に置き換えられてもよい。すなわち、保留数Ｎが所定数以下である場合に受信バッファ１５のクリアが実行される状態が所定回数連続したときに、バッファリング処理が一定時間行われないようにしてもよい。

次に、第三の実施の形態について説明する。第三の実施の形態では、第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第二の実施の形態と同様でよい。

保留終了処理要求の直前に処理された処理要求に係る受信セグメントがＭＳＳ以上である場合、当該受信セグメントには後続セグメントが存在する可能性がある。そこで、第三の実施の形態のプロトコル制御部１２は、このような場合において、保留終了処理要求に応じた処理は実行せずに、当該保留終了処理要求を処理待ちキュー１４の最後尾に移動させる。

図２１は、保留終了処理要求を処理しないで最後尾に移動させる例を示す図である。図２１では、保留終了処理要求が処理対象とされる時点において、当該保留終了処理要求の直前に処理された処理要求に係る受信セグメント２のセグメント長がＭＳＳに一致する例が示されている。このような場合、プロトコル制御部１２は、当該保留終了処理要求を、処理待ちキュー１４の最後尾に移動させる。そうすることにより、例えば、図２１に示されるように、当該保留終了処理要求の直後に、受信セグメント２の後続セグメントである受信セグメント３の処理要求が処理待ちキュー１４に記憶されていた場合、処理効率を向上させることができる。すなわち、移動後の保留終了処理要求が処理されることにより、受信セグメント１、受信セグメント２、及び受信セグメント３をまとめて、宛先のアプリケーション１３に通知することができるからである。

但し、プロトコル制御部１２は、受信バッファ１５に記憶されている全ての受信セグメントのセグメント長の合計が所定値以上である場合、又は受信バッファ１５に記憶されている受信セグメントの総数が所定数以上である場合には、保留終了処理要求の移動は行わない。すなわち、これらの場合、受信バッファ１５に記憶されている全ての受信セグメントは、直ちに宛先のアプリケーション１３に通知される。受信バッファ１５の枯渇を防止するためである。

以下、斯かる処理制御を実現するためにプロトコル制御部１２が実行する処理について説明する。

図２２は、第三の実施の形態における処理要求の処理時の処理手順の一例を説明するためのフローチャートである。図２２中、図１９と同一ステップには同一ステップ番号を付し、その説明は省略する。

図２２では、ステップＳ２２６の後に、ステップＳ２３１〜Ｓ２３４が実行される。ステップＳ２３１において、プロトコル制御部１２は、対象制御テーブルＴ１ａの「最終ポインタ」によって特定される受信セグメントのセグメント長はＭＳＳ以上であるか否かを判定する。なお、当該受信セグメントは、現在処理対象とされている保留終了処理要求の直前に処理された処理要求に係る受信セグメントに相当する。以下、当該受信セグメントを、「最終セグメント」という。なお、ＴＣＰオブションサイズが０でない場合、最終セグメントのセグメント長は、（ＭＳＳ−ＴＣＰオプションサイズ）と比較されればよい。

最終セグメントのセグメント長がＭＳＳ以上である場合（Ｓ２３１でＹｅｓ）、プロトコル制御部１２は、対象受信バッファ１５に記憶されている全ての受信セグメントのセグメント長の合計は、所定値β未満であるか否かを判定する（Ｓ２３２）。所定値βは、受信バッファ１５のサイズに応じて、受信バッファ１５の枯渇を防止可能な値が設定されればよい。例えば、所定値βには、６４ＫＢｙｔｅが設定される。なお、ステップＳ２３２では、対象受信バッファ１５に記憶されている受信セグメントの総数が、所定数未満であるか否かが判定されてもよい。

セグメント長の合計が所定値β未満である場合（Ｓ２３２でＹｅｓ）、プロトコル制御部１２は、保留数Ｎの値を１にする（Ｓ２３３）。続いて、プロトコル制御部１２は、保留終了処理要求を処理待ちキュー１４の待ち行列の最後尾に追加する（Ｓ２３４）。その結果、実質的又は擬似的に、処理対象とされている保留終了処理要求が、処理待ちキュー１４の待ち行列の最後尾に移動される。

なお、ステップＳ２３４に続いて、ステップＳ２３０は実行されない。

一方、最終セグメントのセグメント長がＭＳＳ未満である場合（Ｓ２３１でＮｏ）、又はセグメント長の合計が所定値β以上である場合（Ｓ２３２でＮｏ）、ステップＳ２３０が実行される。

なお、上記各実施の形態において、処理待ちキュー１４は、処理要求記憶部の一例である。受信バッファ１５は、データ記憶部の一例である。プロトコル制御部１２は、制御部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
通信装置が、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する受信データ処理方法。
（付記２）
前記通知する処理は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する処理を実行する付記１記載の受信データ処理方法。
（付記３）
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する付記１又は２記載の受信データ処理方法。
（付記４）
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する付記１乃至３いずれか一項記載の受信データ処理方法。
（付記５）
受信データの受信順に、受信データに関する処理要求の待ち行列を記憶する処理要求記憶部と、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行し、当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する制御部とを有し、
前記制御部は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する通信装置。
（付記６）
前記制御部は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する付記５記載の通信装置。
（付記７）
前記制御部は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する付記５又は６記載の通信装置。
（付記８）
前記制御部は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する付記５乃至７いずれか一項記載の通信装置。
（付記９）
通信装置に、
受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行させ、
前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知するプログラム。
（付記１０）
前記通知する処理は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する付記９記載のプログラム。
（付記１１）
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する付記９又は１０記載のプログラム。
（付記１２）
前記通知する処理は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する付記９乃至１１いずれか一項記載のプログラム。

１０ 受信装置
１１ 入出力制御部
１２ プロトコル制御部
１３ アプリケーション
１４ 処理待ちキュー
１５ 受信バッファ
２０ 送信装置
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス

Claims (6)

1. 通信装置が、
   受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
   前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行し、
   前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する受信データ処理方法。
2. 前記通知する処理は、通信プロトコルに基づいて設定される最大サイズを有する受信データに関しては、前記データ記憶部に記憶せずに、前記宛先に通知する処理を実行する請求項１記載の受信データ処理方法。
3. 前記通知する処理は、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する受信データが所定数以下である状態が所定回数連続した場合は、一定時間の間、前記処理後の受信データを前記データ記憶部に記憶せずに当該受信データの宛先に通知する請求項１又は２記載の受信データ処理方法。
4. 前記通知する処理は、前記所定の処理要求が処理対象とされたときに、当該処理要求の直前の前記処理要求に係る受信データが通信プロトコルに基づいて設定される最大サイズを有する場合は、前記データ記憶部が記憶する受信データを、当該受信データの宛先に通知せずに、前記所定の処理要求を前記待ち行列に追加する請求項１乃至３いずれか一項記載の受信データ処理方法。
5. 受信データの受信順に、受信データに関する処理要求の待ち行列を記憶する処理要求記憶部と、
   前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する制御部とを有し、
   前記制御部は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知する通信装置。
6. 通信装置に、
   受信データの受信順に、受信データに関する処理要求の待ち行列を処理要求記憶部に記憶し、
   前記待ち行列の順番に、前記処理要求記憶部が記憶する前記処理要求に応じた処理を実行して当該処理要求に係る受信データをデータ記憶部に記憶し、前記データ記憶部に記憶された受信データを、当該受信データの宛先に通知する処理を実行させ、
   前記通知する処理は、前記データ記憶部に受信データが記憶されていない場合に前記処理後の受信データを前記データ記憶部に記憶するときは、前記待ち行列に所定の処理要求を追加し、前記所定の処理要求が処理対象とされたときに、前記データ記憶部が記憶する全ての受信データを、当該受信データの宛先に通知するプログラム。

Images