ネットワーク受信装置
【課題】受信データ中に即時処理の必要なデータが含まれていた場合であっても，ＬＲＯ受信処理の利点であるスループットを落とすことなく，即時処理が必要なデータを敏速に処理することができるネットワーク受信装置を提供する。
【解決手段】ネットワーク上の任意の通信における所望の受信データサイズ，および当該通信の識別情報を所定のテーブルに登録するテーブル登録手段と，少なくともトランスポート層よりも下位に位置するデータ受信手段であって，テーブルを参照し，テーブルに登録された識別情報ごとの通信について，受信したデータサイズを計数し，計数された受信データサイズが登録されたデータサイズに達するまで当該受信したデータを上位層に送らないデータ受信手段と，を備えるネットワーク受信装置。
【解決手段】ネットワーク上の任意の通信における所望の受信データサイズ，および当該通信の識別情報を所定のテーブルに登録するテーブル登録手段と，少なくともトランスポート層よりも下位に位置するデータ受信手段であって，テーブルを参照し，テーブルに登録された識別情報ごとの通信について，受信したデータサイズを計数し，計数された受信データサイズが登録されたデータサイズに達するまで当該受信したデータを上位層に送らないデータ受信手段と，を備えるネットワーク受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明はネットワーク受信装置，特に，効率的な受信が可能な装置に関するものである。
【背景技術】
【０００２】
ＴＣＰ送受信性能を改善する取り組みとして，ハードウェアによりＴＣＰセグメンテーション処理（結合処理）を行う発明や，ＬＡＮコントローラドライバに近い層でセグメンテーション処理を行うLARGE RECEIVE OFFLOAD（ＬＲＯ）などのソフト的な取り組みが存在する。
【０００３】
特に受信処理に関するＬＲＯは，特許文献１にて開示のあるように，ＴＣＰセグメンテーション処理を本来のＴＣＰ／ＩＰスタックから分離することで，ＴＣＰスタックの処理に要するＣＰＵ負荷（オーバーヘッド）を下げ，最終的に得られるスループットを向上させるという目的を達成する手段として効果的である。
【０００４】
しかしこのようなＬＲＯは，下位層で後続データを待ち続け，データが続く限りセグメンテーションを行うことを動作原理としているため，スループットの効果向上に伴い，即時性が損なわれていくという問題があった。例えば，印刷データを受信する場合，データサイズの大きい印刷データ本体はスループットが重視されるためＬＲＯが有効に働く。一方，印刷データとともにデータサイズの小さいコマンドデータを受信した場合，ＬＲＯの受信ではセグメンテーション単位で受信データを上位層に送るため，このコマンドの処理は即座に行われないことがある。もしコマンドが印刷中止の指示であれば，大幅に動作が遅れることがあり，その場合には甚大な被害を招くこととなってしまう。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２００７／００１４２４５号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
以上の問題に鑑み，本願発明では，受信データ中に即時処理の必要なデータが含まれていた場合であっても，ＬＲＯ受信処理の利点であるスループットを極力落とすことなく，即時処理が必要なデータを敏速に処理することができるネットワーク受信装置を提供する。
【課題を解決するための手段】
【０００７】
本願発明にかかる第１の形態は， セッションごとの所望受信データサイズを認定する手段と，トランスポート層よりも下位に位置するデータ受信手段であって，セッションごとの通信について，実際に受信したデータのサイズが，認定された所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と，を備えることを特徴とするネットワーク受信装置である。
【０００８】
さらに好ましくは，所定のデータサイズは，０であることを特徴とする。
【０００９】
本願発明にかかる第２の形態は， セッションごとの所望受信データサイズを認定する手段と，トランスポート層よりも下位に位置するデータ受信手段であって，セッションごとの通信について，実際に受信したデータのサイズが，認定された所望受信データサイズに到達せず，かつ，所定の条件が満たされない間は，当該実際に受信したデータを上位層に送らないデータ受信手段と，を備えることを特徴とするネットワーク受信装置である。
【００１０】
本願発明にかかる第３の形態は， コンピュータを，セッションごとの所望受信データサイズを認定する手段と，トランスポート層よりも下位に位置するデータ受信手段であって，セッションごとの通信について，実際に受信したデータのサイズが，認定された所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と，して機能させることを特徴とするプログラムである。
【００１１】
さらに好ましくは，所定のデータサイズは，０であることを特徴とする。
【００１２】
本願発明にかかる第４の形態は， コンピュータを，セッションごとの所望受信データサイズを認定する手段と，トランスポート層よりも下位に位置するデータ受信手段であって，セッションごとの通信について，実際に受信したデータのサイズが，認定された所望受信データサイズに到達せず，かつ，所定の条件が満たされない間は，当該実際に受信したデータを上位層に送らないデータ受信手段と，して機能させることを特徴とするプログラムである。
【発明の効果】
【００１３】
本願発明では，セッションごとに必要な受信データサイズを保持するテーブルを設け，データ受信手段は，当該テーブルに登録されているデータサイズに基づいて上位層に受信データを送る。このため，即時処理の必要なデータは即時に，スループットの必要なデータはまとまったサイズが溜まってからというように，必要な受信データサイズに応じて柔軟に受信処理を行うことができる。この結果，ＬＲＯ受信処理の利点であるスループットを極力落とすことなく，即時処理が必要なデータを敏速に処理することができるという効果を奏する。
【発明を実施するための形態】
【００１４】
以下では図面を参照し本願発明に係る実施例を説明する。
［実施例１］
［ブロック図］
【００１５】
図１は，本願発明にかかるネットワーク受信装置１０１のブロック図である。この図は，ネットワーク受信装置１０１のプロトコルスタックを中心に示したものである。なお，これより説明する処理は，ソフトウェアおよびハードウェアのいずれを用いても実現することが可能である。
【００１６】
ＴＣＰ／ＩＰアプリケーション１０２は，ＴＣＰ／ＩＰプロトコルを使用するアプリケーションであり，ＦＴＰ，ＨＴＴＰおよびＴＥＬＮＥＴなどが一般的には有名である。なお，本願発明で使用するＴＣＰ／ＩＰアプリケーション１０２は，これら従前のプロトコルも含めどのようなものであってもよい。なお，ＴＣＰ／ＩＰアプリケーション１０２は，後述するＴＣＰ１１１に，自身が受信を希望するデータサイズを通知する。
【００１７】
テーブル登録手段１０３は，ネットワーク受信装置１０１が備えるＲＡＭ（図示せず）などの記憶領域に，ネットワーク受信装置１０１が使用するセッション情報をテーブルとして登録する手段である。具体的には図３に示すテーブル情報であり，ソースＩＰアドレス，宛先ＩＰアドレス，ソースポート番号，宛先ポート番号およびセッションごとのデータサイズが登録されている。ソースＩＰアドレスは送信装置側のＩＰアドレスであり，宛先ＩＰアドレスは，ネットワーク受信装置１０１自身のＩＰアドレスである。
【００１８】
データサイズは，本願発明のポイントとなる項目であり，各セッションにおいて，ＴＣＰ／ＩＰアプリケーション１０２が所望する受信データサイズを示したものである。ここに登録されるデータサイズは，後に説明するデータ受信手段１０５が実際に受信したデータ数を減じたサイズとなっている。すなわち，常に最新の残り受信データサイズが反映されている。
【００１９】
ネットワークＩ／Ｆ１０７，ＬＡＮコントローラドライバ１０８，データリンク１０９，ＩＰ１１０およびＴＣＰ１１１は，一般的なネットワーク機器におけるものと同様であるため説明を省略する。図に示す通り，受信データはネットワークＩ／Ｆ１０７を通じてプロトコルスタックを順に進み，最終的にＴＣＰ／ＩＰアプリケーション１０２に送られる。
【００２０】
データ受信手段１０５は，ＬＡＮコントローラドライバ１０８とデータリンク１０９の間に位置する手段である。本願発明において，データ受信手段１０５はいわゆるＬＲＯ処理を実行するエンジン部分であるため，プロトコルスタック上ではデータリンク１０９の直下に位置している。なお，データ受信手段１０５が位置する階層は，上記したものだけでなく，少なくともトランスポート層（図ではＴＣＰ１１１）よりも下位であればよい。
これは，本願発明が，ＴＣＰ１１１が用いるセッション情報を用いて受信データを管理するためである。
【００２１】
データ受信手段１０５は，ＬＡＮコントローラドライバ１０８より送られた受信データを上位層であるデータリンクに１０９に送るかどうかを判定する手段である。具体的には，受信したデータのサイズがＴＣＰ／ＩＰ１１１が所望したサイズに達しているかどうかを，テーブル１０４を参照して判定する。所望したサイズに達していなければ，実際に受信したデータをバッファ１０６に保存するとともに，テーブルに登録されているデータサイズから実際に受信したデータサイズを減じたサイズにテーブル１０４のデータサイズを更新する。一方，受信したデータサイズがＴＣＰ／ＩＰ１１１が所望したサイズに達した場合は，データがバッファ１０６に登録されているなら，ここから読み出し，受信したデータと結合したうえでデータリンク１０９に送る。
【００２２】
図３では，所望データサイズが３２ＫＢｙｔｅと２Ｂｙｔｅの２つのセッションが例示されている。１回の受信データサイズにも依るが，通常は，最大が１５００Ｂｙｔｅ程度となるため所望データサイズが３２ＫＢｙｔｅであるセッションＮｏ．１は，受信データが３２ＫＢｙｔｅに達するまで，バッファ１０６への保存とテーブル１０４の更新が繰り返された後データリンク１０９に送られ，２ＢｙｔｅのセッションＮｏ．２は，受信が完了するとデータは即座にデータリンク１０９に送られる。
【００２３】
［フロー］
図２はネットワーク受信装置１０１の動作フローである。図に示す通り，ネットワーク受信装置１０１はテーブル登録タスクとデータ受信タスクの２つのタスクから構成されている。なお，それぞれのタスクは前述した各手段が実行する。具体的には，テーブル登録タスクはテーブル登録手段１０３が，データ受信タスクはデータ受信手段１０５が実行する。
【００２４】
まずはテーブル登録タスクについて説明する。ステップ２０１にて，ＴＣＰ／ＩＰアプリケーション１０２にてデータ受信要求が発生したかどうかを判定する。発生していなければ，発生するまで判定し続け，発生していれば処理がステップ２０２に進む。ステップ２０２にて，発生したデータ受信要求からに含まれる所望データサイズを認定する。例えば，所望の受信データが印刷データなら３２ＫＢｙｔｅであったり，コマンドデータなら２Ｂｙｔｅという具合である。ステップ２０３にて，受信要求の発生したセッションを認定する。具体的には，ソースＩＰアドレス，宛先ＩＰアドレス，ソースポート番号および宛先ポート番号である。ステップ２０４にて，認定した所望データサイズとセッション情報をセットにして，テーブル１０４に登録する。
【００２５】
次いでデータ受信タスクについて説明する。ステップ２５１にて，データ受信があるかどうかを判定し，データを受信していなければデータ受信を検出し続け，受信していれば処理がステップ２５２に進む。ステップ２５２にて，受信データのセッションを認定する。これは上述したようにソースＩＰアドレスなどの情報である。ステップ２５３にて，受信したデータのサイズを認定する。ステップ２５４にて，テーブル１０４を参照し，認定されたセッション情報の所望データサイズ分を受信したかどうかを判定する。所望データサイズに達していなければ，ステップ２５５にて，受信したデータをバッファ１０６に保存し，ステップ２５６にて，受信したデータサイズを減じたデータサイズにテーブル１０４を更新する。一方，ステップ２５４にて所望データサイズ分の受信をしていれば，受信データを上位層，本実施例ではデータリンク１０９に送る。もちろん，バッファに１０６に保存されている受信データがあれば，これを読み出し，受信したデータと結合したうえで送る。なお，図示していないが，この時点でテーブルに登録されているセッション情報を削除してもよい。
［その他の実施形態］
【００２６】
先の実施例では，テーブル登録手段１０３がＴＣＰ１１１に存在したが，ＴＣＰ／ＩＰアプリケーション１０２の側に存在してもよい。この場合，通常のＴＣＰ／ＩＰアプリケーション１０２にテーブル登録手段１０３を組み込めばよい。
【００２７】
また，テーブル登録手段１０３がテーブル１０４に登録するデータサイズは，必ずしもＴＣＰ１１１が所望するデータサイズと同じである必要はない。ネットワーク通信では，様々な要因により，データのロスト（欠落）が発生することがある。もし，テーブルのデータサイズが，ＴＣＰ１１１の所望するデータサイズと同じであるならば，受信データの欠落が発生した場合，一向に上位層に受信データが送られないという事態が発生する。このような事態を回避するため，予め，ＴＣＰ１１１の所望データサイズから所定のデータサイズ分（たとえば１パケット分１５００Ｂｙｔｅ）を減じたサイズをテーブル１０４に登録しておき，登録されたデータサイズ分のデータが受信されたら上位層に送るというようにしてもよい。一方，ネットワークの通信品質が高く，ロストの危険性が皆無と想定されるなら，減じるサイズを０（ゼロ）として，テーブル１０４に登録すればよい。
【００２８】
さらに，データのロストに備えるための別の手段として，テーブルに登録されたデータサイズに達していない場合でも，一定時間の経過など，所定の条件が満たされた場合に，上位層に受信データを送るようにしてもよい。図４は，受信データサイズと所定の条件のそれぞれのケースにおいて，データ受信手段１０５が，受信データを上位層に送るかどうかを示す表である。図からわかるとおり，「受信データサイズがテーブルに登録されたサイズに達する」，または「所定の条件」の少なくとも一方が満たされれば，受信データを上位層に送る。言い換えると，いずれも満たされない場合に限り，受信データを上位層に送らない。
［まとめ］
【００２９】
本願発明では，セッションごとに必要な受信データサイズを保持するテーブルを設け，データ受信手段は，当該テーブルに登録されているデータサイズに基づいて上位層に受信データを送る。このため，即時処理の必要なデータは即時に，スループットの必要なデータはまとまったサイズが溜まってからというように，必要な受信データサイズに応じて柔軟に受信処理を行うことができる。この結果，ＬＲＯ受信処理の利点であるスループットを極力落とすことなく，即時処理が必要なデータを敏速に処理することができるという効果を奏する。
【図面の簡単な説明】
【００３０】
【図１】ネットワーク受信装置のブロック図
【図２】ネットワーク受信装置の動作フロー
【図３】テーブル例
【図４】データ受信手段の挙動
【符号の説明】
【００３１】
１０３ テーブル登録手段
１０５ データ受信手段
【技術分野】
【０００１】
本願発明はネットワーク受信装置，特に，効率的な受信が可能な装置に関するものである。
【背景技術】
【０００２】
ＴＣＰ送受信性能を改善する取り組みとして，ハードウェアによりＴＣＰセグメンテーション処理（結合処理）を行う発明や，ＬＡＮコントローラドライバに近い層でセグメンテーション処理を行うLARGE RECEIVE OFFLOAD（ＬＲＯ）などのソフト的な取り組みが存在する。
【０００３】
特に受信処理に関するＬＲＯは，特許文献１にて開示のあるように，ＴＣＰセグメンテーション処理を本来のＴＣＰ／ＩＰスタックから分離することで，ＴＣＰスタックの処理に要するＣＰＵ負荷（オーバーヘッド）を下げ，最終的に得られるスループットを向上させるという目的を達成する手段として効果的である。
【０００４】
しかしこのようなＬＲＯは，下位層で後続データを待ち続け，データが続く限りセグメンテーションを行うことを動作原理としているため，スループットの効果向上に伴い，即時性が損なわれていくという問題があった。例えば，印刷データを受信する場合，データサイズの大きい印刷データ本体はスループットが重視されるためＬＲＯが有効に働く。一方，印刷データとともにデータサイズの小さいコマンドデータを受信した場合，ＬＲＯの受信ではセグメンテーション単位で受信データを上位層に送るため，このコマンドの処理は即座に行われないことがある。もしコマンドが印刷中止の指示であれば，大幅に動作が遅れることがあり，その場合には甚大な被害を招くこととなってしまう。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２００７／００１４２４５号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
以上の問題に鑑み，本願発明では，受信データ中に即時処理の必要なデータが含まれていた場合であっても，ＬＲＯ受信処理の利点であるスループットを極力落とすことなく，即時処理が必要なデータを敏速に処理することができるネットワーク受信装置を提供する。
【課題を解決するための手段】
【０００７】
本願発明にかかる第１の形態は， セッションごとの所望受信データサイズを認定する手段と，トランスポート層よりも下位に位置するデータ受信手段であって，セッションごとの通信について，実際に受信したデータのサイズが，認定された所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と，を備えることを特徴とするネットワーク受信装置である。
【０００８】
さらに好ましくは，所定のデータサイズは，０であることを特徴とする。
【０００９】
本願発明にかかる第２の形態は， セッションごとの所望受信データサイズを認定する手段と，トランスポート層よりも下位に位置するデータ受信手段であって，セッションごとの通信について，実際に受信したデータのサイズが，認定された所望受信データサイズに到達せず，かつ，所定の条件が満たされない間は，当該実際に受信したデータを上位層に送らないデータ受信手段と，を備えることを特徴とするネットワーク受信装置である。
【００１０】
本願発明にかかる第３の形態は， コンピュータを，セッションごとの所望受信データサイズを認定する手段と，トランスポート層よりも下位に位置するデータ受信手段であって，セッションごとの通信について，実際に受信したデータのサイズが，認定された所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と，して機能させることを特徴とするプログラムである。
【００１１】
さらに好ましくは，所定のデータサイズは，０であることを特徴とする。
【００１２】
本願発明にかかる第４の形態は， コンピュータを，セッションごとの所望受信データサイズを認定する手段と，トランスポート層よりも下位に位置するデータ受信手段であって，セッションごとの通信について，実際に受信したデータのサイズが，認定された所望受信データサイズに到達せず，かつ，所定の条件が満たされない間は，当該実際に受信したデータを上位層に送らないデータ受信手段と，して機能させることを特徴とするプログラムである。
【発明の効果】
【００１３】
本願発明では，セッションごとに必要な受信データサイズを保持するテーブルを設け，データ受信手段は，当該テーブルに登録されているデータサイズに基づいて上位層に受信データを送る。このため，即時処理の必要なデータは即時に，スループットの必要なデータはまとまったサイズが溜まってからというように，必要な受信データサイズに応じて柔軟に受信処理を行うことができる。この結果，ＬＲＯ受信処理の利点であるスループットを極力落とすことなく，即時処理が必要なデータを敏速に処理することができるという効果を奏する。
【発明を実施するための形態】
【００１４】
以下では図面を参照し本願発明に係る実施例を説明する。
［実施例１］
［ブロック図］
【００１５】
図１は，本願発明にかかるネットワーク受信装置１０１のブロック図である。この図は，ネットワーク受信装置１０１のプロトコルスタックを中心に示したものである。なお，これより説明する処理は，ソフトウェアおよびハードウェアのいずれを用いても実現することが可能である。
【００１６】
ＴＣＰ／ＩＰアプリケーション１０２は，ＴＣＰ／ＩＰプロトコルを使用するアプリケーションであり，ＦＴＰ，ＨＴＴＰおよびＴＥＬＮＥＴなどが一般的には有名である。なお，本願発明で使用するＴＣＰ／ＩＰアプリケーション１０２は，これら従前のプロトコルも含めどのようなものであってもよい。なお，ＴＣＰ／ＩＰアプリケーション１０２は，後述するＴＣＰ１１１に，自身が受信を希望するデータサイズを通知する。
【００１７】
テーブル登録手段１０３は，ネットワーク受信装置１０１が備えるＲＡＭ（図示せず）などの記憶領域に，ネットワーク受信装置１０１が使用するセッション情報をテーブルとして登録する手段である。具体的には図３に示すテーブル情報であり，ソースＩＰアドレス，宛先ＩＰアドレス，ソースポート番号，宛先ポート番号およびセッションごとのデータサイズが登録されている。ソースＩＰアドレスは送信装置側のＩＰアドレスであり，宛先ＩＰアドレスは，ネットワーク受信装置１０１自身のＩＰアドレスである。
【００１８】
データサイズは，本願発明のポイントとなる項目であり，各セッションにおいて，ＴＣＰ／ＩＰアプリケーション１０２が所望する受信データサイズを示したものである。ここに登録されるデータサイズは，後に説明するデータ受信手段１０５が実際に受信したデータ数を減じたサイズとなっている。すなわち，常に最新の残り受信データサイズが反映されている。
【００１９】
ネットワークＩ／Ｆ１０７，ＬＡＮコントローラドライバ１０８，データリンク１０９，ＩＰ１１０およびＴＣＰ１１１は，一般的なネットワーク機器におけるものと同様であるため説明を省略する。図に示す通り，受信データはネットワークＩ／Ｆ１０７を通じてプロトコルスタックを順に進み，最終的にＴＣＰ／ＩＰアプリケーション１０２に送られる。
【００２０】
データ受信手段１０５は，ＬＡＮコントローラドライバ１０８とデータリンク１０９の間に位置する手段である。本願発明において，データ受信手段１０５はいわゆるＬＲＯ処理を実行するエンジン部分であるため，プロトコルスタック上ではデータリンク１０９の直下に位置している。なお，データ受信手段１０５が位置する階層は，上記したものだけでなく，少なくともトランスポート層（図ではＴＣＰ１１１）よりも下位であればよい。
これは，本願発明が，ＴＣＰ１１１が用いるセッション情報を用いて受信データを管理するためである。
【００２１】
データ受信手段１０５は，ＬＡＮコントローラドライバ１０８より送られた受信データを上位層であるデータリンクに１０９に送るかどうかを判定する手段である。具体的には，受信したデータのサイズがＴＣＰ／ＩＰ１１１が所望したサイズに達しているかどうかを，テーブル１０４を参照して判定する。所望したサイズに達していなければ，実際に受信したデータをバッファ１０６に保存するとともに，テーブルに登録されているデータサイズから実際に受信したデータサイズを減じたサイズにテーブル１０４のデータサイズを更新する。一方，受信したデータサイズがＴＣＰ／ＩＰ１１１が所望したサイズに達した場合は，データがバッファ１０６に登録されているなら，ここから読み出し，受信したデータと結合したうえでデータリンク１０９に送る。
【００２２】
図３では，所望データサイズが３２ＫＢｙｔｅと２Ｂｙｔｅの２つのセッションが例示されている。１回の受信データサイズにも依るが，通常は，最大が１５００Ｂｙｔｅ程度となるため所望データサイズが３２ＫＢｙｔｅであるセッションＮｏ．１は，受信データが３２ＫＢｙｔｅに達するまで，バッファ１０６への保存とテーブル１０４の更新が繰り返された後データリンク１０９に送られ，２ＢｙｔｅのセッションＮｏ．２は，受信が完了するとデータは即座にデータリンク１０９に送られる。
【００２３】
［フロー］
図２はネットワーク受信装置１０１の動作フローである。図に示す通り，ネットワーク受信装置１０１はテーブル登録タスクとデータ受信タスクの２つのタスクから構成されている。なお，それぞれのタスクは前述した各手段が実行する。具体的には，テーブル登録タスクはテーブル登録手段１０３が，データ受信タスクはデータ受信手段１０５が実行する。
【００２４】
まずはテーブル登録タスクについて説明する。ステップ２０１にて，ＴＣＰ／ＩＰアプリケーション１０２にてデータ受信要求が発生したかどうかを判定する。発生していなければ，発生するまで判定し続け，発生していれば処理がステップ２０２に進む。ステップ２０２にて，発生したデータ受信要求からに含まれる所望データサイズを認定する。例えば，所望の受信データが印刷データなら３２ＫＢｙｔｅであったり，コマンドデータなら２Ｂｙｔｅという具合である。ステップ２０３にて，受信要求の発生したセッションを認定する。具体的には，ソースＩＰアドレス，宛先ＩＰアドレス，ソースポート番号および宛先ポート番号である。ステップ２０４にて，認定した所望データサイズとセッション情報をセットにして，テーブル１０４に登録する。
【００２５】
次いでデータ受信タスクについて説明する。ステップ２５１にて，データ受信があるかどうかを判定し，データを受信していなければデータ受信を検出し続け，受信していれば処理がステップ２５２に進む。ステップ２５２にて，受信データのセッションを認定する。これは上述したようにソースＩＰアドレスなどの情報である。ステップ２５３にて，受信したデータのサイズを認定する。ステップ２５４にて，テーブル１０４を参照し，認定されたセッション情報の所望データサイズ分を受信したかどうかを判定する。所望データサイズに達していなければ，ステップ２５５にて，受信したデータをバッファ１０６に保存し，ステップ２５６にて，受信したデータサイズを減じたデータサイズにテーブル１０４を更新する。一方，ステップ２５４にて所望データサイズ分の受信をしていれば，受信データを上位層，本実施例ではデータリンク１０９に送る。もちろん，バッファに１０６に保存されている受信データがあれば，これを読み出し，受信したデータと結合したうえで送る。なお，図示していないが，この時点でテーブルに登録されているセッション情報を削除してもよい。
［その他の実施形態］
【００２６】
先の実施例では，テーブル登録手段１０３がＴＣＰ１１１に存在したが，ＴＣＰ／ＩＰアプリケーション１０２の側に存在してもよい。この場合，通常のＴＣＰ／ＩＰアプリケーション１０２にテーブル登録手段１０３を組み込めばよい。
【００２７】
また，テーブル登録手段１０３がテーブル１０４に登録するデータサイズは，必ずしもＴＣＰ１１１が所望するデータサイズと同じである必要はない。ネットワーク通信では，様々な要因により，データのロスト（欠落）が発生することがある。もし，テーブルのデータサイズが，ＴＣＰ１１１の所望するデータサイズと同じであるならば，受信データの欠落が発生した場合，一向に上位層に受信データが送られないという事態が発生する。このような事態を回避するため，予め，ＴＣＰ１１１の所望データサイズから所定のデータサイズ分（たとえば１パケット分１５００Ｂｙｔｅ）を減じたサイズをテーブル１０４に登録しておき，登録されたデータサイズ分のデータが受信されたら上位層に送るというようにしてもよい。一方，ネットワークの通信品質が高く，ロストの危険性が皆無と想定されるなら，減じるサイズを０（ゼロ）として，テーブル１０４に登録すればよい。
【００２８】
さらに，データのロストに備えるための別の手段として，テーブルに登録されたデータサイズに達していない場合でも，一定時間の経過など，所定の条件が満たされた場合に，上位層に受信データを送るようにしてもよい。図４は，受信データサイズと所定の条件のそれぞれのケースにおいて，データ受信手段１０５が，受信データを上位層に送るかどうかを示す表である。図からわかるとおり，「受信データサイズがテーブルに登録されたサイズに達する」，または「所定の条件」の少なくとも一方が満たされれば，受信データを上位層に送る。言い換えると，いずれも満たされない場合に限り，受信データを上位層に送らない。
［まとめ］
【００２９】
本願発明では，セッションごとに必要な受信データサイズを保持するテーブルを設け，データ受信手段は，当該テーブルに登録されているデータサイズに基づいて上位層に受信データを送る。このため，即時処理の必要なデータは即時に，スループットの必要なデータはまとまったサイズが溜まってからというように，必要な受信データサイズに応じて柔軟に受信処理を行うことができる。この結果，ＬＲＯ受信処理の利点であるスループットを極力落とすことなく，即時処理が必要なデータを敏速に処理することができるという効果を奏する。
【図面の簡単な説明】
【００３０】
【図１】ネットワーク受信装置のブロック図
【図２】ネットワーク受信装置の動作フロー
【図３】テーブル例
【図４】データ受信手段の挙動
【符号の説明】
【００３１】
１０３ テーブル登録手段
１０５ データ受信手段
【特許請求の範囲】
【請求項１】
セッションごとの所望受信データサイズを認定する手段と，
トランスポート層よりも下位に位置するデータ受信手段であって，前記セッションごとの通信について，実際に受信したデータのサイズが，認定された前記所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と，
を備えることを特徴とするネットワーク受信装置。
【請求項２】
前記所定のデータサイズは，０であることを特徴とする請求項１に記載のネットワーク受信装置。
【請求項３】
セッションごとの所望受信データサイズを認定する手段と，
トランスポート層よりも下位に位置するデータ受信手段であって，前記セッションごとの通信について，実際に受信したデータのサイズが，認定された前記所望受信データサイズに到達せず，かつ，所定の条件が満たされない間は，当該実際に受信したデータを上位層に送らないデータ受信手段と，
を備えることを特徴とするネットワーク受信装置。
【請求項４】
コンピュータを，
セッションごとの所望受信データサイズを認定する手段と，
トランスポート層よりも下位に位置するデータ受信手段であって，前記セッションごとの通信について，実際に受信したデータのサイズが，認定された前記所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と，
して機能させることを特徴とするプログラム。
【請求項５】
前記所定のデータサイズは，０であることを特徴とする請求項４に記載のプログラム。
【請求項６】
コンピュータを，
セッションごとの所望受信データサイズを認定する手段と，
トランスポート層よりも下位に位置するデータ受信手段であって，前記セッションごとの通信について，実際に受信したデータのサイズが，認定された前記所望受信データサイズに到達せず，かつ，所定の条件が満たされない間は，当該実際に受信したデータを上位層に送らないデータ受信手段と，
して機能させることを特徴とするプログラム。
【請求項１】
セッションごとの所望受信データサイズを認定する手段と，
トランスポート層よりも下位に位置するデータ受信手段であって，前記セッションごとの通信について，実際に受信したデータのサイズが，認定された前記所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と，
を備えることを特徴とするネットワーク受信装置。
【請求項２】
前記所定のデータサイズは，０であることを特徴とする請求項１に記載のネットワーク受信装置。
【請求項３】
セッションごとの所望受信データサイズを認定する手段と，
トランスポート層よりも下位に位置するデータ受信手段であって，前記セッションごとの通信について，実際に受信したデータのサイズが，認定された前記所望受信データサイズに到達せず，かつ，所定の条件が満たされない間は，当該実際に受信したデータを上位層に送らないデータ受信手段と，
を備えることを特徴とするネットワーク受信装置。
【請求項４】
コンピュータを，
セッションごとの所望受信データサイズを認定する手段と，
トランスポート層よりも下位に位置するデータ受信手段であって，前記セッションごとの通信について，実際に受信したデータのサイズが，認定された前記所望受信データサイズから所定のデータサイズ分を減じたサイズに到達するまで当該実際に受信したデータを上位層に送らないデータ受信手段と，
して機能させることを特徴とするプログラム。
【請求項５】
前記所定のデータサイズは，０であることを特徴とする請求項４に記載のプログラム。
【請求項６】
コンピュータを，
セッションごとの所望受信データサイズを認定する手段と，
トランスポート層よりも下位に位置するデータ受信手段であって，前記セッションごとの通信について，実際に受信したデータのサイズが，認定された前記所望受信データサイズに到達せず，かつ，所定の条件が満たされない間は，当該実際に受信したデータを上位層に送らないデータ受信手段と，
して機能させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１２−２０４９５０（Ｐ２０１２−２０４９５０Ａ）
【公開日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願番号】特願２０１１−６５７６９（Ｐ２０１１−６５７６９）
【出願日】平成２３年３月２４日（２０１１．３．２４）
【出願人】（５００１１２１４６）サイレックス・テクノロジー株式会社 (74)
【Ｆターム（参考）】
【公開日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願日】平成２３年３月２４日（２０１１．３．２４）
【出願人】（５００１１２１４６）サイレックス・テクノロジー株式会社 (74)
【Ｆターム（参考）】
[ Back to top ]