JP2007259374A - ネットワーク送受信装置 - Google Patents

Abstract

【課題】ネットワークを通じて伝送されるデータのパケットを高速かつ安定して受信し、処理することが可能なネットワーク送受信装置を提供すること。
【解決手段】ある特定の条件に合致し、アプリケーション処理回路５０５に直接転送すべきデータのパケットを格納する受信バッファ１１２を設け、さらに受信バッファ１１２の空き容量を検知する空き容量検知手段１１３と、受信バッファ１１２の空き容量を送信元端末に返信する空き容量返信手段１１４を設けた。
【選択図】図１

Description

本発明は、ネットワークを通じて伝送されるデータのパケットを、高速かつ安定して受信し、処理を行うことが可能であるネットワーク送受信装置に関するものである。

従来のネットワーク送受信装置は、通信プロトコルに関する処理を主にメインＣＰＵで行っている。図５は、従来のネットワーク送受信装置の構成を示すものである。

図５において、ネットワーク送受信装置にて受信されるパケットは、ＬＡＮコントローラ５０１内の物理層処理回路５１１にてＯＳＩ７階層モデルにおける第1層の物理層処理が、データリンク層処理回路５１２にて第2層のデータリンク層処理がそれぞれ行われている。処理されたパケットは、一時的に受信ＦＩＦＯ５１３に格納された後、メインＣＰＵバス５０２を経由してシステムメモリ５０３のカーネル領域５３１に蓄積される。カーネル領域５３１に蓄積されたパケットは、メインＣＰＵバス５０２を経由してメインＣＰＵ５０４により読み込まれ、第３層のネットワーク層処理、第４層のトランスポート層処理が行われる。メインＣＰＵ５０４により通信プロトコル処理が終了したパケット内のデータのうち、制御情報などの一般データは、メインＣＰＵ５０４でそのまま処理が行われ、一方、アプリケーションデータは、メインＣＰＵバス５０２を経由してシステムメモリ５０３内のユーザ領域５３２と呼ばれる、アプリケーション処理回路５０５がアクセス可能な領域に書き込まれる。アプリケーション処理回路５０５は、ユーザ領域５３２に格納されているアプリケーションデータをメインＣＰＵバス５０２経由で読み込み、アプリケーション処理の後、アプリケーション信号を出力する。トランスポート層のプロトコルとして送信元端末への伝達確認応答を必要とするＴＣＰが用いられている場合には、メインＣＰＵ５０４は、パケットを誤りなく受信できたときに、送信元端末に対する伝達応答確認のためのＡＣＫパケットを生成する。このとき、ＴＣＰフロー制御で利用され、ＡＣＫパケットで送信元端末に通知される情報のうち、受信端末が受信することが可能なデータのサイズを示しているウインドウサイズとしては、システムメモリ５０３内に通信コネクション毎に用意された領域の空き容量が用いられる。生成されたＡＣＫパケットは、メインＣＰＵ５０４でトランスポート層およびネットワーク層の通信プロトコル処理が行われる。その後、ＡＣＫパケットはメインＣＰＵバス５０２を経由してＬＡＮコントローラ５０１へ転送され、データリンク層処理回路５１２でデータリンク層処理が、物理層処理回路５１１で物理層処理がそれぞれ行われて、送信元端末に返信される。そして、ＡＣＫパケットを受信した送信元端末は、通知されたウインドウサイズ分のデータを受信端末に送信する。また、送信元端末は、受信端末からＡＣＫパケットが返信されて来ない場合には、そのＡＣＫパケットに対応するデータパケットの伝送ができなかったと判断して、データパケットの再送を行う。

一方、トランスポート層のプロトコルとして送信元端末への伝達確認応答が不要なＵＤＰを用いて伝送されるＡＶストリームなどのデータのパケットを、メインＣＰＵバス５０２やメインＣＰＵ５０４を経由せずにアプリケーション処理回路５０５に直接転送して処理を行うものもある（例えば、特許文献１参照）。図６は、前記特許文献１に記載されたネットワーク送受信装置の構成を示すものである。なお、図５と同じ構成要素については同じ符号を用い、説明を省略する。

図６においては、データリンク層処理回路５１２にてデータリンク層処理が行われたパケットは、パケット選別手段６１１にてＡＶストリームデータなどの優先パケットとそれ以外の一般パケットとに選別され、一般パケットについては、受信ＦＩＦＯ５１３に転送された後、従来例図５と同じ手順で処理が行われる。優先パケットについては、パケット選別手段６１１からパケット内のＵＤＰペイロード、つまりデータのみが直接アプリケーション処理回路５０５に転送され、アプリケーション処理の後、アプリケーション信号が出力される。

ここで、上記特許文献１においては、高速に伝送および処理されるべきＡＶストリームなどのデータのパケットは、トランスポート層のプロトコルとして処理が簡素なＵＤＰが用いられて伝送が行われるものとされているが、ＵＤＰによる伝送は、パケットの再送などによってデータの伝送品質を補償する手段を有していないことから、より高品質なデータの伝送を実現するためには、これらデータのパケットは、ＴＣＰにより伝送される必要がある。
特開２００３−２７３９２０号公報

前述の従来例図５の構成のネットワーク送受信装置を用いて、ＴＣＰによりデータのパケットを伝送する場合、送信元端末は、受信端末から通知されたウインドウサイズ分のデータを受信端末に送信する。送信されたパケットは、受信端末のＬＡＮコントローラ５０１において受信された後、メインＣＰＵバス５０２を経由してシステムメモリ５０３に転送され、格納される。ここで、メインＣＰＵバス５０２は、ＬＡＮコントローラ５０１とシステムメモリ５０３との間のデータの転送、システムメモリ５０３とアプリケーション処理回路５０５との間のデータの転送、メインＣＰＵ５０４によるシステムメモリ５０３内のカーネル領域５３１とユーザ領域５３２との間のデータコピーなどのパケットの受信処理や、それ以外のメインＣＰＵ５０４による汎用処理の際にも使用されることから、パケットの受信処理に使用できるメインＣＰＵバス５０２の帯域幅が十分に確保できないときには、パケットの受信処理に遅延が発生する。例えば、家電製品などの組み込み用途向けのマイコンシステムでは、ＰＣとは異なり、メインＣＰＵバス５０２の帯域幅は、パケットが伝送されるネットワークの帯域幅と比較して小さく、加えて、メインＣＰＵバス５０２の帯域幅のうち、パケットの受信処理などネットワーク機能に使用できる帯域幅はさらに制限されている。これを言い換えると、受信端末内でのパケットの受信処理の速度は、ネットワークから受信端末へのパケットの入力速度と比較して遅いということであり、このとき、ネットワークから入力されて受信処理を待つパケットは、ネットワークとメインＣＰＵバス５０２との境界である、ＬＡＮコントローラ５０１内の受信ＦＩＦＯ５１３に蓄積されていく。しかしながら、前述のように、送信元端末は、受信ＦＩＦＯ５１３の空き容量に関わらず、ウインドウサイズとして通知されるシステムメモリ５０３の空き容量分のデータを受信端末に送信する。一般に、システムメモリ５０３の容量は受信ＦＩＦＯ５１３の容量よりも大きく、また、送信元端末に通知されるウインドウサイズは最大６４Ｋバイトであり、現在多くとも１６Ｋバイトである受信ＦＩＦＯ５１３の容量よりも大きい。このため、パケットの受信処理に対して使用できるメインＣＰＵバス５０２の帯域幅がネットワークの伝送帯域幅以下に制限されている場合には、受信処理を待つパケットが受信ＦＩＦＯ５１３に次々と蓄積されていく一方で、受信ＦＩＦＯ５１３の空き容量がなくなっても、送信元端末からのパケットの送信をＴＣＰフロー制御によって止めることはできず、その結果、受信ＦＩＦＯ５１３のオーバーフローによるパケットロスが発生する。パケットロスが発生した場合、受信端末はロスしたパケットに対するＡＣＫパケットを返信しないため、送信元端末は、ＴＣＰフロー制御によりＡＣＫパケットの到着を数秒間待ってタイムアウトとなった後、該当パケットの再送を行う。

以上、従来例図５の構成において、パケットの受信処理に使用できるメインＣＰＵバス５０２の帯域幅が制限されている場合、システムメモリ５０３の空き容量をウインドウサイズとして送信元端末に通知するＴＣＰフロー制御のシステムは破綻を来たし、その結果、パケットの再送によりデータの伝送速度が低下するという課題を有している。

特に、従来例図５の構成によるネットワーク送受信装置が、ＡＶストリームなど高速伝送が要求されるデータのパケットを受信する場合には、上記課題はより顕著に現れる。

本発明では、前記従来の課題を解決するもので、ネットワークを通じて伝送されるデータのパケットを、高速かつ安定して受信し、処理を行うことが可能であるネットワーク送受信装置を提供することを目的とする。

前記従来の課題を解決するために、本発明のネットワーク送受信装置は、受信パケットのうち特定のパケットを分岐させるパケット分岐手段と、受信バッファと、受信バッファの空き容量を検知する空き容量検知手段と、受信バッファの空き容量をデータの送信元端末に返信する空き容量返信手段とを備え、パケットの送受信処理を行うことを主な特徴とする。

本発明によって、ＴＣＰにより伝送されるデータのパケットについて、パケットの受信処理に使用できるメインＣＰＵバスの帯域幅が制限されることに起因するパケットロスと、それに伴うパケットの再送がなくなり、高速かつ安定した受信および処理が可能となる。

以下本発明を実施するための最良の形態について、ＴＣＰ／ＩＰにより伝送されるＡＶストリームデータを受信する例を挙げ、図面を参照しながら説明する。

（実施の形態１）
図１は、本発明の実施の形態１におけるネットワーク送受信装置の構成図である。図１において、従来例図５と同じ構成要素については同じ符号を用い、説明を省略する。また、図２は、本発明の実施の形態１におけるパケット処理手順の概念図である。

図１において、ＬＡＮコントローラ１０１内のデータリンク層処理回路５１２にてデータリンク層処理が行われたパケットは、パケット分岐手段１１１に転送される。図３は、パケット分岐手段１１１に転送されるパケットの構成図を示している。図３において、ＩＰはＩＰｖ４と呼ばれるものであり、ＩＰヘッダはＲＦＣ７９１に、ＴＣＰヘッダはＲＦＣ７９３に、それぞれ定義されているものである。パケット分岐手段１１１は、転送されたパケットから、図３に示すパケット内のＩＰヘッダに含まれる、ネットワーク内で端末を識別するために付与されている送信元端末ＩＰアドレス、受信端末ＩＰアドレス、図３に示すパケット内のＴＣＰヘッダに含まれる、アプリケーションやサービスを識別するために付与されている送信元ポート番号、受信先ポート番号のうち、一部または全てを参照することによって、分岐対象とするＡＶストリームデータのパケットか否かを判別して分岐させ、アプリケーション処理回路５０５で処理を行うＡＶストリームデータのパケットを受信バッファ１１２に、メインＣＰＵ５０４で処理を行う制御情報などの一般データのパケットを受信ＦＩＦＯ５１３にそれぞれ転送する。分岐されたパケットのうち、受信バッファ１１２に転送されるＡＶストリームデータのパケットは、受信バッファ１１２に格納された後、直接アプリケーション処理回路５０５からパケット内のＴＣＰペイロード、つまりデータのみが抽出され読み込まれる。以降、従来例図５の構成と同様に、アプリケーション処理回路５０５は、圧縮、符号化されているＡＶストリームデータの復号化処理や、デジタル信号をアナログ信号に変換する処理などを行い、映像と音声からなるＡＶ信号を出力する。また、空き容量検知手段１１３は、ＡＶストリームデータのパケットを誤りなく受信できた場合に、受信バッファ１１２の空き容量を検知し、検知した空き容量を空き容量返信手段１１４に転送する。空き容量の検知方法としては、例えば、受信バッファ１１２の読み込み開始アドレスを示すポインタの値と書き込み開始アドレスを示すポインタの値との差分演算からデータが既に格納されている領域の容量を求め、受信バッファ１１２全体の容量と前記差分演算により求めたデータが既に格納されている領域の容量との差分演算から受信バッファ１１２の空き容量を求める。空き容量返信手段１１４は、ＴＣＰフロー制御を目的として、受信バッファ１１２の空き容量をウインドウサイズとした送信元端末に向けたＡＣＫパケットを生成する。生成されたＡＣＫパケットは、データリンク層処理回路５１２でデータリンク層処理が、物理層処理回路５１１で物理層処理がそれぞれ行われて、送信元端末に対して返信される。そして、ＡＣＫパケットを受信した送信元端末は、ＡＣＫパケットにより受信端末から通知されたウインドウサイズ分のＡＶストリームデータを新たに送信する。以上の構成と処理手順によれば、システムメモリ５０３の空き容量ではなく、ネットワークとメインＣＰＵバス５０２の境界である、ＬＡＮコントローラ１０１内の受信バッファ１１２の空き容量をウインドウサイズとして送信元端末に通知することにより、パケットの受信処理に対して使用できるメインＣＰＵバス５０２の帯域幅がネットワークの伝送帯域幅以下に制限されている場合であっても、送信元端末は、受信処理待ちのパケットが蓄積される受信バッファ１１２の空き容量分のみのデータのパケットを送信するようになる。このため、送信されたパケットは、パケットの受信処理に使用できるメインＣＰＵバス５０２の帯域幅に依存することなく、受信バッファ１１２に確実に格納され、従来例図５で課題となっていた、ＬＡＮコントローラ５０１内でのパケットロスの発生を防ぐことが可能である。一方、パケットの分岐後、受信ＦＩＦＯ５１３に転送される一般データのパケットの処理は、以降従来例図５の構成と同様である。このときは、システムメモリ５０３の空き容量がウインドウサイズとして送信元端末に対して通知されるものの、制御情報などの一般データは、ＡＶストリームデータと比較して、そのパケット数が非常に少なく、リアルタイム性も要求されないため、パケットの受信処理に使用できるメインＣＰＵバス５０２の帯域幅が制限される場合であっても、受信ＦＩＦＯ５１３のオーバーフローによるパケットロスと、それにパケットの再送はさほど問題とはならない。

上記図１の構成において、空き容量検知手段１１３、空き容量返信手段１１４は、それぞれハードウェアにより実現してもソフトウェアにより実現してもよい。

また、ＩＰとしてＩＰｖ６と呼ばれるＲＦＣ２４６０に定義されているものが用いられる場合、ＩＰヘッダの構成は図３に示すものとは異なるものの、送信元端末ＩＰアドレスおよび受信端末ＩＰアドレスは、ＩＰｖ６であってもＩＰヘッダ内に含まれることから、上記ＩＰとしてＩＰｖ４が用いられる場合と同様、送信元端末ＩＰアドレス、受信端末ＩＰアドレスをパケットの分岐条件として参照することは可能である。

以上、かかる構成によれば、ＴＣＰ／ＩＰにより伝送されるＡＶストリームデータのパケットについて、従来例図５の構成で課題となっていた、パケットの受信処理に使用できるメインＣＰＵバス５０２の帯域幅が制限されることに起因する、ＬＡＮコントローラ５０１内の受信ＦＩＦＯ５１３のオーバーフローによるパケットロスと、それに伴うパケットの再送によるデータの伝送速度の低下を防ぐことが可能である。併せて、データを格納している受信バッファ１１２からアプリケーション処理回路５０５に直接データを転送することにより、パケットの受信処理に使用できるメインＣＰＵバス５０２の帯域幅に依存せずに、データを高速かつ安定して受信および処理することが可能である。

（実施の形態２）
図４は、本発明の実施の形態２におけるネットワーク送受信装置の構成図である。図４において、上記図１および従来例図５と同じ構成要素については同じ符号を用い、説明を省略する。

図４においては、上記実施の形態１における図１の構成とは異なり、受信バッファ、空き容量検知手段、空き容量返信手段の処理系を複数設けている。各受信バッファは通信コネクション毎に、例えば、受信バッファ１１２Ａは送信端末Ａから送信されるＡＶストリームデータＡのパケットを、受信バッファ１１２Ｂは送信端末Ｂから送信されるＡＶストリームデータＢのパケットを、それぞれ格納するように割り当てられる。パケット分岐手段１１１は、受信パケットを分岐させて、受信バッファ１１２Ａ、受信バッファ１１２Ｂ、受信ＦＩＦＯ５１３のいずれかに転送する。受信バッファ１１２Ａ、受信バッファ１１２Ｂに格納されたデータのパケットは、メインＣＰＵバス５０２を経由せずに、それぞれ、アプリケーション処理回路５０５Ａ、アプリケーション処理回路５０５Ｂによりパケット内のＴＣＰペイロードが直接読み込まれてアプリケーション処理される。また、各受信バッファの空き容量の検知と、その空き容量をウインドウサイズとしたＡＣＫパケットの生成および返信も、それぞれの処理系において上記図１の構成と同様に行われる。

以上、かかる構成によれば、上記図１の構成における効果に加え、通信コネクション毎に受信バッファを設けて、パケットの受信処理と受信バッファの空き容量をウインドウサイズとしたＴＣＰフロー制御を、各処理系においてそれぞれ独立に行うことにより、従来例図５では、複数の通信コネクションのパケットをメインＣＰＵ５０４で逐次にしか受信処理できなかったものが、本構成においては、通信コネクション毎に並列にパケットを受信処理できるようになり、同時通信コネクション数が増大しても、処理時間が増大することなく、データを高速に受信および処理することが可能である。

本発明にかかるネットワーク送受信装置は、データのパケットを高速かつ安定して受信し、処理を行うことが可能であるので、ネットワークを通じて伝送されるＡＶストリームなどの大容量のデータを再生または保存する機器などに有用である。

本発明の実施の形態１におけるネットワーク送受信装置の構成図 本発明の実施の形態１におけるパケット処理手順の概念図 パケット分岐手段１１１に転送されるパケットの構成図 本発明の実施の形態２におけるネットワーク送受信装置の構成図 従来のネットワーク送受信装置の構成図 特許文献１におけるネットワーク送受信装置の構成図

符号の説明

１０１ 本発明の実施の形態１におけるＬＡＮコントローラ
１１１ パケット分岐手段
１１２ 受信バッファ
１１２Ａ 受信バッファ
１１２Ｂ 受信バッファ
１１３ 空き容量検知手段
１１３Ａ 空き容量検知手段
１１３Ｂ 空き容量検知手段
１１４ 空き容量返信手段
１１４Ａ 空き容量返信手段
１１４Ｂ 空き容量返信手段
４０１ 本発明の実施の形態２におけるＬＡＮコントローラ
５０１ 従来のＬＡＮコントローラ
５０２ メインＣＰＵバス
５０３ システムメモリ
５０４ メインＣＰＵ
５０５ アプリケーション処理回路
５０５Ａ アプリケーション処理回路
５０５Ｂ アプリケーション処理回路
５１１ 物理層処理回路
５１２ データリンク層処理回路
５１３ 受信ＦＩＦＯ
５１４ 送信ＦＩＦＯ
５３１ カーネル領域
５３２ ユーザ領域
６０１ 特許文献１におけるＬＡＮコントローラ
６１１ パケット選別手段

Claims (6)

1. 受信パケットのうち特定のパケットを分岐させるパケット分岐手段と、
   上記分岐させた特定のパケットを格納する受信バッファと、
   上記受信バッファに格納される特定のパケット以外のパケットを格納する受信ＦＩＦＯと、
   上記受信バッファの空き容量を検知する空き容量検知手段と、
   上記受信バッファの空き容量をデータの送信元端末に返信する空き容量返信手段とを備えた、ネットワーク送受信装置。
2. 受信バッファに格納されるパケットは、直接アプリケーション処理回路に転送されて処理され、一方、受信ＦＩＦＯに格納されるパケットは、メインＣＰＵバスを経由してメインＣＰＵに転送されて処理される、請求項１に記載のネットワーク送受信装置。
3. 受信バッファに格納されるパケットはＡＶストリームデータのパケットであり、受信ＦＩＦＯに格納されるパケットは制御情報など一般データのパケットである、請求項２に記載のネットワーク送受信装置。
4. 受信バッファと、空き容量検知手段と、空き容量返信手段とを複数備えた、請求項１に記載のネットワーク送受信装置。
5. パケット分岐手段は、パケット内のＩＰヘッダに含まれる送信元端末ＩＰアドレス、受信端末ＩＰアドレス、ＴＣＰヘッダに含まれる送信元ポート番号、受信先ポート番号のうち、一部または全てを参照することによりパケットを分岐させることを特徴とする、請求項１に記載のネットワーク送受信装置。
6. 空き容量検知手段は、受信バッファの読み込み開始アドレスを示すポインタの値と書き込み開始アドレスを示すポインタの値との差分演算からデータが既に格納されている領域の容量を求め、受信バッファ全体の容量とデータが既に格納されている領域の容量との差分演算から受信バッファの空き容量を求めることを特徴とする、請求項１に記載のネットワーク送受信装置。

Images