"セッションごとの所望受信データサイズを認定する手段と,トランスポート層よりも下位に位置するデータ受信手段であって,前記セッションごとの通信について,実際に受信したデータのサイズが,認定された前記所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と,を備えることを特徴とするネットワーク受信装置。前記所定のデータサイズは,0であることを特徴とする請求項1に記載のネットワーク受信装置。セッションごとの所望受信データサイズを認定する手段と,トランスポート層よりも下位に位置するデータ受信手段であって,前記セッションごとの通信について,実際に受信したデータのサイズが,認定された前記所望受信データサイズに到達せず,かつ,所定の条件が満たされない間は,当該実際に受信したデータを上位層に送らないデータ受信手段と,を備えることを特徴とするネットワーク受信装置。コンピュータを,セッションごとの所望受信データサイズを認定する手段と,トランスポート層よりも下位に位置するデータ受信手段であって,前記セッションごとの通信について,実際に受信したデータのサイズが,認定された前記所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と,して機能させることを特徴とするプログラム。前記所定のデータサイズは,0であることを特徴とする請求項4に記載のプログラム。コンピュータを,セッションごとの所望受信データサイズを認定する手段と,トランスポート層よりも下位に位置するデータ受信手段であって,前記セッションごとの通信について,実際に受信したデータのサイズが,認定された前記所望受信データサイズに到達せず,かつ,所定の条件が満たされない間は,当該実際に受信したデータを上位層に送らないデータ受信手段と,して機能させることを特徴とするプログラム。以上の問題に鑑み,本願発明では,受信データ中に即時処理の必要なデータが含まれていた場合であっても,LRO受信処理の利点であるスループットを極力落とすことなく,即時処理が必要なデータを敏速に処理することができるネットワーク受信装置を提供する。本願発明にかかる第1の形態は,セッションごとの所望受信データサイズを認定する手段と,トランスポート層よりも下位に位置するデータ受信手段であって,セッションごとの通信について,実際に受信したデータのサイズが,認定された所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と,を備えることを特徴とするネットワーク受信装置である。さらに好ましくは,所定のデータサイズは,0であることを特徴とする。本願発明にかかる第2の形態は,セッションごとの所望受信データサイズを認定する手段と,トランスポート層よりも下位に位置するデータ受信手段であって,セッションごとの通信について,実際に受信したデータのサイズが,認定された所望受信データサイズに到達せず,かつ,所定の条件が満たされない間は,当該実際に受信したデータを上位層に送らないデータ受信手段と,を備えることを特徴とするネットワーク受信装置である。本願発明にかかる第3の形態は,コンピュータを,セッションごとの所望受信データサイズを認定する手段と,トランスポート層よりも下位に位置するデータ受信手段であって,セッションごとの通信について,実際に受信したデータのサイズが,認定された所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と,して機能させることを特徴とするプログラムである。さらに好ましくは,所定のデータサイズは,0であることを特徴とする。本願発明にかかる第4の形態は,コンピュータを,セッションごとの所望受信データサイズを認定する手段と,トランスポート層よりも下位に位置するデータ受信手段であって,セッションごとの通信について,実際に受信したデータのサイズが,認定された所望受信データサイズに到達せず,かつ,所定の条件が満たされない間は,当該実際に受信したデータを上位層に送らないデータ受信手段と,して機能させることを特徴とするプログラムである。本願発明では,セッションごとに必要な受信データサイズを保持するテーブルを設け,データ受信手段は,当該テーブルに登録されているデータサイズに基づいて上位層に受信データを送る。このため,即時処理の必要なデータは即時に,スループットの必要なデータはまとまったサイズが溜まってからというように,必要な受信データサイズに応じて柔軟に受信処理を行うことができる。この結果,LRO受信処理の利点であるスループットを極力落とすことなく,即時処理が必要なデータを敏速に処理することができるという効果を奏する。以下では図面を参照し本願発明に係る実施例を説明する。[実施例1][ブロック図]図1は,本願発明にかかるネットワーク受信装置101のブロック図である。この図は,ネットワーク受信装置101のプロトコルスタックを中心に示したものである。なお,これより説明する処理は,ソフトウェアおよびハードウェアのいずれを用いても実現することが可能である。TCP/IPアプリケーション102は,TCP/IPプロトコルを使用するアプリケーションであり,FTP,HTTPおよびTELNETなどが一般的には有名である。なお,本願発明で使用するTCP/IPアプリケーション102は,これら従前のプロトコルも含めどのようなものであってもよい。なお,TCP/IPアプリケーション102は,後述するTCP111に,自身が受信を希望するデータサイズを通知する。テーブル登録手段103は,ネットワーク受信装置101が備えるRAM図示せずなどの記憶領域に,ネットワーク受信装置101が使用するセッション情報をテーブルとして登録する手段である。具体的には図3に示すテーブル情報であり,ソースIPアドレス,宛先IPアドレス,ソースポート番号,宛先ポート番号およびセッションごとのデータサイズが登録されている。ソースIPアドレスは送信装置側のIPアドレスであり,宛先IPアドレスは,ネットワーク受信装置101自身のIPアドレスである。データサイズは,本願発明のポイントとなる項目であり,各セッションにおいて,TCP/IPアプリケーション102が所望する受信データサイズを示したものである。ここに登録されるデータサイズは,後に説明するデータ受信手段105が実際に受信したデータ数を減じたサイズとなっている。すなわち,常に最新の残り受信データサイズが反映されている。ネットワークI/F107,LANコントローラドライバ108,データリンク109,IP110およびTCP111は,一般的なネットワーク機器におけるものと同様であるため説明を省略する。図に示す通り,受信データはネットワークI/F107を通じてプロトコルスタックを順に進み,最終的にTCP/IPアプリケーション102に送られる。データ受信手段105は,LANコントローラドライバ108とデータリンク109の間に位置する手段である。本願発明において,データ受信手段105はいわゆるLRO処理を実行するエンジン部分であるため,プロトコルスタック上ではデータリンク109の直下に位置している。なお,データ受信手段105が位置する階層は,上記したものだけでなく,少なくともトランスポート層図ではTCP111よりも下位であればよい。これは,本願発明が,TCP111が用いるセッション情報を用いて受信データを管理するためである。データ受信手段105は,LANコントローラドライバ108より送られた受信データを上位層であるデータリンクに109に送るかどうかを判定する手段である。具体的には,受信したデータのサイズがTCP/IP111が所望したサイズに達しているかどうかを,テーブル104を参照して判定する。所望したサイズに達していなければ,実際に受信したデータをバッファ106に保存するとともに,テーブルに登録されているデータサイズから実際に受信したデータサイズを減じたサイズにテーブル104のデータサイズを更新する。一方,受信したデータサイズがTCP/IP111が所望したサイズに達した場合は,データがバッファ106に登録されているなら,ここから読み出し,受信したデータと結合したうえでデータリンク109に送る。図3では,所望データサイズが32KByteと2Byteの2つのセッションが例示されている。1回の受信データサイズにも依るが,通常は,最大が1500Byte程度となるため所望データサイズが32KByteであるセッションNo.1は,受信データが32KByteに達するまで,バッファ106への保存とテーブル104の更新が繰り返された後データリンク109に送られ,2ByteのセッションNo.2は,受信が完了するとデータは即座にデータリンク109に送られる。[フロー]図2はネットワーク受信装置101の動作フローである。図に示す通り,ネットワーク受信装置101はテーブル登録タスクとデータ受信タスクの2つのタスクから構成されている。なお,それぞれのタスクは前述した各手段が実行する。具体的には,テーブル登録タスクはテーブル登録手段103が,データ受信タスクはデータ受信手段105が実行する。まずはテーブル登録タスクについて説明する。ステップ201にて,TCP/IPアプリケーション102にてデータ受信要求が発生したかどうかを判定する。発生していなければ,発生するまで判定し続け,発生していれば処理がステップ202に進む。ステップ202にて,発生したデータ受信要求からに含まれる所望データサイズを認定する。例えば,所望の受信データが印刷データなら32KByteであったり,コマンドデータなら2Byteという具合である。ステップ203にて,受信要求の発生したセッションを認定する。具体的には,ソースIPアドレス,宛先IPアドレス,ソースポート番号および宛先ポート番号である。ステップ204にて,認定した所望データサイズとセッション情報をセットにして,テーブル104に登録する。次いでデータ受信タスクについて説明する。ステップ251にて,データ受信があるかどうかを判定し,データを受信していなければデータ受信を検出し続け,受信していれば処理がステップ252に進む。ステップ252にて,受信データのセッションを認定する。これは上述したようにソースIPアドレスなどの情報である。ステップ253にて,受信したデータのサイズを認定する。ステップ254にて,テーブル104を参照し,認定されたセッション情報の所望データサイズ分を受信したかどうかを判定する。所望データサイズに達していなければ,ステップ255にて,受信したデータをバッファ106に保存し,ステップ256にて,受信したデータサイズを減じたデータサイズにテーブル104を更新する。一方,ステップ254にて所望データサイズ分の受信をしていれば,受信データを上位層,本実施例ではデータリンク109に送る。もちろん,バッファに106に保存されている受信データがあれば,これを読み出し,受信したデータと結合したうえで送る。なお,図示していないが,この時点でテーブルに登録されているセッション情報を削除してもよい。[その他の実施形態]先の実施例では,テーブル登録手段103がTCP111に存在したが,TCP/IPアプリケーション102の側に存在してもよい。この場合,通常のTCP/IPアプリケーション102にテーブル登録手段103を組み込めばよい。また,テーブル登録手段103がテーブル104に登録するデータサイズは,必ずしもTCP111が所望するデータサイズと同じである必要はない。ネットワーク通信では,様々な要因により,データのロスト欠落が発生することがある。もし,テーブルのデータサイズが,TCP111の所望するデータサイズと同じであるならば,受信データの欠落が発生した場合,一向に上位層に受信データが送られないという事態が発生する。このような事態を回避するため,予め,TCP111の所望データサイズから所定のデータサイズ分たとえば1パケット分1500Byteを減じたサイズをテーブル104に登録しておき,登録されたデータサイズ分のデータが受信されたら上位層に送るというようにしてもよい。一方,ネットワークの通信品質が高く,ロストの危険性が皆無と想定されるなら,減じるサイズを0ゼロとして,テーブル104に登録すればよい。さらに,データのロストに備えるための別の手段として,テーブルに登録されたデータサイズに達していない場合でも,一定時間の経過など,所定の条件が満たされた場合に,上位層に受信データを送るようにしてもよい。図4は,受信データサイズと所定の条件のそれぞれのケースにおいて,データ受信手段105が,受信データを上位層に送るかどうかを示す表である。図からわかるとおり,受信データサイズがテーブルに登録されたサイズに達する,または所定の条件の少なくとも一方が満たされれば,受信データを上位層に送る。言い換えると,いずれも満たされない場合に限り,受信データを上位層に送らない。[まとめ]本願発明では,セッションごとに必要な受信データサイズを保持するテーブルを設け,データ受信手段は,当該テーブルに登録されているデータサイズに基づいて上位層に受信データを送る。このため,即時処理の必要なデータは即時に,スループットの必要なデータはまとまったサイズが溜まってからというように,必要な受信データサイズに応じて柔軟に受信処理を行うことができる。この結果,LRO受信処理の利点であるスループットを極力落とすことなく,即時処理が必要なデータを敏速に処理することができるという効果を奏する。"