【０００１】
【発明の属する技術分野】
本発明は、パケット受信処理に要求される高速性を実現しながら、既存プロトコルへの互換性も兼ね備えたパケット受信装置に関するものである。特に、映像／音声ストリームの受信装置に関する。
【０００２】
【従来の技術】
以前のネットワークシステムは、各々のベンダが独自方式で設計しており、様々な通信手順が存在した。しかし現在では、ＯＳＩ（開放型システム間相互接続）基本参照モデルに倣って、通信に必要な機能を階層化し、階層間のプロトコルを標準化する傾向にある（例えば、非特許文献１参照）。ここでは、ＯＳＩ基本参照モデルとＴＣＰ／ＩＰの階層の対応を図９に示す。このように、機能やプロトコルを体系的に分類することで、相互接続性の向上を図ったり、新しい機能やサービスの追加／変更を容易にすることが可能となる。
【０００３】
ここで具体的に、ＴＣＰ／ＩＰを利用するアプリケーションがデータを送信する手順を考える（図１０参照）。データはＴＣＰ／ＩＰの階層を下層に向かって順に辿り、最終的には物理的な回線の規格に合わせた電気信号に変換されて送出される。各層では、プロトコル制御情報をヘッダやトレーラとしてデータに追加していく。例えば、アプリケーションがトランスポート層のプロトコルとしてＵＤＰを利用する場合、送信すべきデータをＵＤＰ層に転送する（ＵＤＰは非特許文献２参照）。するとＵＤＰ層ではデータにＵＤＰヘッダを追加してＵＤＰデータグラムに加工し、それをネットワーク層であるＩＰ層に転送する（ＩＰは非特許文献３参照）。ＩＰ層ではＵＤＰデータグラムにＩＰヘッダを追加してＩＰパケットに加工し、ネットワークアクセス層に転送する。このとき、ＩＰデータグラムのサイズがネットワークの最大転送単位を超えるならば、ＩＰデータグラムを分割して送信する（フラグメント化）。ネットワークアクセス層がイーサネット（Ｒ）であれば、ＩＰデータグラムにヘッダとトレーラを追加してイーサネット（Ｒ）フレームに加工し、電気信号に変換して、宛先の通信装置に転送する（イーサネット（Ｒ）は非特許文献４参照）。
【０００４】
データを受け取った宛先の通信装置は、送信元の通信装置と逆の手順、つまりヘッダやトレーラの情報をもとに各層でデータを取り出し、それを上位層に転送していく。フラグメントを受信した場合は、それらをすべて集めて元のデータグラムに戻してから、上位のプロトコルに渡す（リアセンブル）。そして、最終的な宛先となるアプリケーションにデータが渡される。
【０００５】
このような、通信装置内に実装されるＴＣＰ／ＩＰなどのプロトコル処理部をプロトコルスタックと呼ぶ。プロトコルスタックでは、単一のプロトコルが任意の上位プロトコルを格納して転送する機能（多重化）や、多重化されたデータから選別して上位層のプロトコルに転送する機能（多重分離）を有する。
【０００６】
【非特許文献１】
ＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｘ．２００ （１９９４） ｜ ＩＳＯ／ＩＥＣ ７４９８−１ （１９９４）， Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ − Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ − Ｂａｓｉｃ ｒｅｆｅｒｅｎｃｅ ｍｏｄｅｌ： Ｔｈｅ ｂａｓｉｃ ｍｏｄｅｌ
【非特許文献２】
ＲＦＣ７６８ （１９８０）， ＳＴＤ６， Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ
【非特許文献３】
ＲＦＣ７９１ （１９８１）， ＳＴＤ５， Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ
【非特許文献４】
Ｓｔａｎｄａｒｄ ｆｏｒ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ − Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ ｉｎｆｏｒｍａｔｉｏｎ ｅｘｃｈａｎｇｅ ｂｅｔｗｅｅｎ ｓｙｓｔｅｍｓ − Ｌｏｃａｌ ａｎｄ ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋｓ − Ｓｐｅｃｉｆｉｃ ｒｅｑｕｉｒｅｍｅｎｔｓ − Ｐａｒｔ ３： Ｃａｒｒｉｅｒ ｓｅｎｓｅ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ ｗｉｔｈ ｃｏｌｌｉｓｉｏｎ ｄｅｔｅｃｔｉｏｎ （ＣＳＭＡ／ＣＤ） ａｃｃｅｓｓ ｍｅｔｈｏｄ ａｎｄ ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｐｅｃｉｆｉｃａｔｉｏｎｓ
【０００７】
【発明が解決しようとする課題】
しかしながら、受信処理における多重分離性能は、通信装置やＮＩＣ（ネットワーク・インタフェース・カード）の処理能力だけではなく、対応するプロトコルの種類や数に大きく左右されるため、十分な処理性能をもたない通信装置においては処理が追いつかずにパケットロスを招いたり、通信装置のその他の処理を遅延させるなどの課題を有していた。
【０００８】
本発明は、前記従来の課題を解決するもので、既存のプロトコルとの互換性を保持しながら、所定のパケットに要求される高速受信処理を実現するパケット受信装置を提供することを目的とする。特に映像／音声ストリームの受信処理に適したパケット受信装置を提供することを目的としている。
【０００９】
【課題を解決するための手段】
前記課題を解決するため、本発明のパケット受信装置は、設定条件のパケットを受信する第１のプロトコルスタックと、前記設定条件内のより狭い設定条件、或いは前記設定条件とは異なる設定条件のパケットのみを受信する、前記第１のプロトコルスタックよりも優先して処理される第２のプロトコルスタックを有する。第１のプロトコルスタックは、通常のパケット受信処理で使用し、設定条件に合致したパケットを受信する。前記第１のプロトコルスタックは、ＯＳ（オペレーティング・システム）のカーネル内に組み込まれることが多く、ダイナミックリンクライブラリによる実装方法も存在する。第２のプロトコルスタックは、第１のプロトコルスタックのもつ設定条件内のより狭い設定条件、或いは前記設定条件とは異なる設定条件に合致するパケットのみを受信し、高速受信処理や下位層において特殊な（簡略化した）受信処理を要する場合に特化する。
【００１０】
本構成によって、既存のプロトコルとの互換性を保持しながら、所定のパケットに要求される高速受信処理を実現する。
【００１１】
【発明の実施の形態】
（実施の形態１）
図１は、本発明の実施の形態１におけるパケット受信装置の構成図である。
【００１２】
図１において、パケット受信装置１０１は、通信回線１０８を終端するＤＣＥ（回線終端装置）１０７を介してデータの伝送を行う。パケット受信装置１０１は、データの（送）受信処理を行うアプリケーション１０５と、プロトコル処理、アクセスパスの管理、ネットワーク管理を行う通信アクセス制御プログラム１０４と、伝送制御、同期制御、フロー制御、誤り制御を行う通信制御装置１０６から構成される。通信アクセス制御プログラム１０４は第１のプロトコルスタック１０２と第２のプロトコルスタック１０３をもつ（実施の形態１の構成）。
【００１３】
図２は、パケット受信装置１０１の処理シーケンス図である。
【００１４】
図３は、第１のプロトコルスタック１０２と第２のプロトコルスタック１０３の階層図である。
【００１５】
アプリケーション１０５は、他のパケットとは差別化して受信すべきパケットがあれば、その受信条件、例えばクライアント側／サーバ側のＩＰアドレス／ポート番号の４つの数字の組み合わせ（ネームと呼ぶ）を、第２のプロトコルスタック１０３に設定する（図２のＳ１）。以降、パケット受信装置１０１がパケットを受信すると、第２のプロトコルスタック１０３が第１のプロトコルスタック１０２に優先して処理される。第２のプロトコルスタック１０３がパケットを受信すると（図２のＳ２）、第２のプロトコルスタック１０３に準じたパケットであるか、また設定されたネームと一致するパケットであるかを判断し、もし受信すべきパケットであればそのパケットにカプセル化されたデータをアプリケーション１０５に転送する（もしくは所定のメモリ領域にデータを転送する）。もし受信すべきパケットでなければ、パケットを破棄して終了する。第１のプロトコルスタック１０２では、他のアプリケーションから受信条件が設定されている、或いは何も設定されていない状態とし、その設定条件に応じて前記パケットを受信、或いは破棄する（図２のＳ３）。
【００１６】
このような第２のプロトコルスタックをもつことにより、ある設定条件に合致するパケットに対しては、アプリケーションに特化したプロトコルスタックで受信することにより、高速な受信処理を実現することができる。例えば、パケットの順序制御や再送制御などのプロトコル処理を簡略化し、重複制御やシーケンス管理は上位プロトコル（アプリケーション）に任せる方法がある。また、ＯＳに搭載されるような標準的なプロトコルスタックを第１のプロトコルスタックとして併用すれば、通常のパケット受信も行えるため、既存アプリケーションとの互換性も保持することができる。
【００１７】
なお、本実施の形態において、通信制御装置１０６はパケット受信装置１０１の内部に設けたが、外部から通信アクセス制御プログラム１０４と連携するように接続してもよい。また、ここでは受信条件としてネームを設定したが、伝送プロトコルなど特定のパケットを識別するための情報であれば、これに限るものではない。さらに、第１のプロトコルスタック１０２と第２のプロトコルスタック１０３においては、下位層（イーサネット（Ｒ）層乃至ＩＰ層）を２つのプロトコルスタックで共有してもよい。
【００１８】
（実施の形態２）
図４は、本発明の実施の形態２におけるパケット受信装置の処理シーケンス図である。実施の形態２の構成は、実施の形態１と同様とし、構成要素については説明を省略する。
【００１９】
アプリケーション１０５は、他のパケットとは差別化して受信すべきパケットがあれば、その受信条件となるネームを、第２のプロトコルスタック１０３に設定する（図４のＳ１）。パケット受信装置１０１がパケットを受信すると、第２のプロトコルスタック１０３に転送され、第２のプロトコルスタック１０３に準じたパケットであるか、また設定されたネームと一致するパケットであるかを判断する（図４のＳ２）。もし設定条件に一致しなければ、そのパケットを第１のプロトコルスタック１０２に委譲する。第１のプロトコルスタック１０２では、他のアプリケーションから受信条件が設定されている、或いは何も設定されていない状態とし、その設定条件に応じてパケットを受信、或いは破棄する（図４のＳ３）。パケット受信装置１０１が次のパケットを受信し、第２のプロトコルスタック１０３に転送されると、第２のプロトコルスタック１０３に準じたパケットであり、且つ設定条件に一致するパケットであれば、そのパケットにカプセル化されたデータをアプリケーション１０５に転送する（図４のＳ４）。このように、第２のプロトコルスタック１０３で正常に受信処理したパケットは、第１のプロトコルスタック１０２には転送しない。
【００２０】
かかる処理によれば、同一のパケットを第１、第２のプロトコルスタック両方で処理する必要がなく、パケット受信装置の処理負荷を軽減することができる。
【００２１】
なお、図４のＳ２の処理において、第２のプロトコルスタック１０３の受信条件に一致せず、その処理過程において第１のプロトコルスタック１０２の受信条件も満たさないことが判断できる場合、そのパケットを破棄してもよい。
【００２２】
（実施の形態３）
図５は、本発明の実施の形態３におけるパケット受信装置の処理シーケンス図である。実施の形態３の構成は、実施の形態１と同様とし、構成要素については説明を省略する。
【００２３】
図６は、第２のプロトコルスタック１０３で受信すべきパケットフォーマットの一例である。図６ａは、パケットの送信装置が送ろうとしているＩＰデータグラムを示している。この場合、送信装置が接続されているネットワークがイーサネット（Ｒ）であれば、その最大転送単位が１５００バイトであることから、図６ｂのようにフラグメント化される。
【００２４】
アプリケーション１０５は、他のパケットとは差別化して受信すべきパケットがあれば、その受信条件となるネームを、第２のプロトコルスタック１０３に設定する（図５のＳ１）。以降、パケット受信装置１０１がパケットを受信すると、第２のプロトコルスタック１０３が第１のプロトコルスタック１０２に優先して処理される。第２のプロトコルスタック１０３がパケットを受信すると（図５のＳ２）、第２のプロトコルスタック１０３に準じたパケットであるか、また設定されたネームと一致するパケットであるかを判断する。そして、受信すべきパケットで、且つそれがフラグメントであれば、ヘッダのオフセット情報を見て、順序に従って到着していれば、それをアプリケーションに転送する（もしくは所定のメモリ領域にデータを転送する）。このとき、第２のプロトコルスタック１０３では、リアセンブルを行わない。
【００２５】
かかる処理によれば、パケットロスを許容できるアプリケーションを利用する場合に、１つのフラグメントの損失が複数のフラグメントの損失につながるというＩＰ層の問題を回避できる。また、リアルタイム伝送を必要とするアプリケーションであれば、リアセンブルが完了する前にデータをアプリケーションに転送することもできる。
【００２６】
なお、ここでは、フラグメントの到着した順にアプリケーション１０５にデータを転送するものとしたが、第２のプロトコルスタック１０３のもつバッファにフラグメントを蓄積し、その蓄積された範囲内でフラグメントの到着順序を保証するようにしてもよい。
【００２７】
（実施の形態４）
図７は、本発明の実施の形態４におけるＭＰＥＧ２受信装置の構成図である。図７において図１と同じ構成要素については同じ符号を用い、説明を省略する。ＭＰＥＧ２受信装置は２０１は、パケット受信装置１０１にＭＰＥＧ２デコーダ２０２を付加したもので、映像／音声ストリームの再生機能を有する。ＭＰＥＧ２デコーダ２０２は、アプリケーション１０５と連携しながら、ＭＰＥＧ２トランスポートストリームをデコードし、映像／音声の出力を行う。
【００２８】
図８は、本発明の実施の形態４におけるＭＰＥＧ２受信装置の処理シーケンス図である。
【００２９】
アプリケーション１０５は、他のパケットとは差別化して受信すべきパケットとして、ＭＰＥＧ２トランスポートストリームを伝送するＵＤＰパケットのネームを、第２のプロトコルスタック１０３に設定する（図８のＳ１）。ＭＰＥＧ２受信装置２０１がパケットを受信すると、第２のプロトコルスタック１０３に転送され、第２のプロトコルスタック１０３に準じたパケットであるか、また設定されたネームと一致するパケットであるか判断する（図８のＳ２）。もし設定条件に一致しなければ、そのパケットを第１のプロトコルスタック１０２に委譲する。第１のプロトコルスタック１０２では、他のアプリケーションから受信条件が設定されている、或いは何も設定されていない状態とし、その設定条件に応じてパケットを受信、或いは破棄する（図８のＳ３）。ＭＰＥＧ２受信装置２０１が次のパケットを受信し、第２のプロトコルスタック１０３に転送されると、設定条件に一致するパケットであればそのパケットにカプセル化されたＭＰＥＧ２データをアプリケーション１０５に転送する（図８のＳ４）。ＭＰＥＧ２データを受信したアプリケーション１０５は、それをＭＰＥＧ２デコーダ２０２に転送し（図８のＳ５）、ＭＰＥＧ２デコーダ２０２がＭＰＥＧ２データのデコードを行い、映像／音声を出力する（図８のＳ６）。
【００３０】
かかる処理によれば、映像／音声ストリームを第２のプロトコルスタックで高速に処理しながら、その他のパケットは第１のプロトコルスタックで処理することにより、大容量マルチメディア情報の高速受信と既存アプリケーションとの互換性を実現できる。
【００３１】
なお、映像／音声ストリームとして、ＭＰＥＧ２トランスポートストリームを扱ったが、ＭＰＥＧ２プログラムストリームやその他のＩＰ伝送可能な映像／音声フォーマットでもかまわない。
【００３２】
【発明の効果】
以上のように、本発明のパケット受信装置によれば、新しい機能やサービスの追加／変更は容易であるが処理負荷が大きい第１のプロトコルスタックと、複数の階層のプロトコルに跨って柔軟に実装でき、所定のパケットに特化することで受信処理が軽い第２のプロトコルスタックを用いることによって、既存のプロトコルとの互換性を保持しながら、映像／音声ストリームなどの大容量マルチメディア情報を高速に処理することが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態１におけるパケット受信装置の構成図
【図２】本発明の実施の形態１におけるパケット受信装置の処理シーケンス図
【図３】本発明の実施の形態１における通信アクセス制御プログラムの階層図
【図４】本発明の実施の形態２におけるパケット受信装置の処理シーケンス図
【図５】本発明の実施の形態３におけるパケット受信装置の処理シーケンス図
【図６】本発明の実施の形態３におけるパケットフォーマットを示す図
【図７】本発明の実施の形態４におけるＭＰＥＧ２受信装置の構成図
【図８】本発明の実施の形態４におけるＭＰＥＧ２受信装置の処理シーケンス図
【図９】ＯＳＩ基本階層モデルとＴＣＰ／ＩＰの階層図
【図１０】ＴＣＰ／ＩＰによる送受信機能を有する通信装置の階層図
【符号の説明】
１０１ パケット受信装置
１０２ 第１のプロトコルスタック
１０３ 第２のプロトコルスタック
１０４ 通信アクセス制御プログラム
１０５ アプリケーション
１０６ 通信制御装置
１０７ ＤＣＥ
１０８ 通信回線
２０１ ＭＰＥＧ２受信装置
２０２ ＭＰＥＧ２デコーダ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a packet receiving apparatus that achieves high speed required for packet receiving processing and also has compatibility with existing protocols. In particular, the present invention relates to a video / audio stream receiving device.
[0002]
[Prior art]
Previous network systems were designed by each vendor in a unique manner, and had various communication procedures. However, at present, there is a tendency that functions necessary for communication are hierarchized and protocols between hierarchies are standardized in accordance with the OSI (Open System Interconnection) basic reference model (for example, see Non-Patent Document 1). Here, FIG. 9 shows the correspondence between the OSI basic reference model and the TCP / IP hierarchy. In this way, by systematically classifying functions and protocols, it is possible to improve interoperability and to easily add / change new functions and services.
[0003]
Here, specifically, a procedure in which an application using TCP / IP transmits data will be considered (see FIG. 10). The data sequentially goes down the TCP / IP layer toward the lower layers, and finally is converted into an electric signal conforming to the standard of the physical line and transmitted. At each layer, protocol control information is added to data as a header or trailer. For example, when an application uses UDP as a transport layer protocol, data to be transmitted is transferred to the UDP layer (see Non-Patent Document 2 for UDP). Then, the UDP layer adds a UDP header to the data, processes the data into a UDP datagram, and transfers it to the IP layer which is a network layer (for IP, see Non-Patent Document 3). In the IP layer, an IP header is added to the UDP datagram, processed into an IP packet, and transferred to the network access layer. At this time, if the size of the IP datagram exceeds the maximum transfer unit of the network, the IP datagram is divided and transmitted (fragmentation). If the network access layer is Ethernet (R), a header and a trailer are added to the IP datagram, processed into an Ethernet (R) frame, converted into an electric signal, and transferred to a destination communication device (Ethernet (R) ) Is Non-Patent Document 4).
[0004]
The destination communication device that has received the data extracts the data in each layer based on the header and trailer information, and transfers it to the upper layer, in the reverse procedure of the communication device of the transmission source. When fragments are received, they are all collected, returned to the original datagram, and then passed to a higher-level protocol (reassembly). Then, the data is passed to the final destination application.
[0005]
Such a protocol processing unit such as TCP / IP implemented in the communication device is called a protocol stack. The protocol stack has a function (multiplexing) of storing and transferring an arbitrary upper protocol by a single protocol, and a function of selecting from multiplexed data and transferring the selected data to a protocol of an upper layer (multiplex separation).
[0006]
[Non-patent document 1]
ITU-T Recommendation X. 200 (1994) | ISO / IEC 7498-1 (1994), Information technology-Open Systems Interconnection-Basic reference model: The basic model.
[Non-patent document 2]
RFC768 (1980), STD6, User Datagram Protocol
[Non-Patent Document 3]
RFC791 (1981), STD5, Internet Protocol
[Non-patent document 4]
Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA / CD) access method and physical layer specifications
[0007]
[Problems to be solved by the invention]
However, the demultiplexing performance in the reception processing is not sufficiently processed because it depends not only on the processing performance of the communication device and the NIC (network interface card) but also on the type and number of corresponding protocols. The communication device has problems in that the process cannot keep up, causing packet loss or delaying other processes of the communication device.
[0008]
SUMMARY OF THE INVENTION An object of the present invention is to provide a packet receiving apparatus which solves the above-mentioned conventional problems and realizes a high-speed receiving process required for a predetermined packet while maintaining compatibility with an existing protocol. . In particular, it is an object of the present invention to provide a packet receiving device suitable for receiving a video / audio stream.
[0009]
[Means for Solving the Problems]
In order to solve the above problem, a packet receiving device according to the present invention includes a first protocol stack for receiving a packet having a setting condition, a packet having a narrower setting condition within the setting condition, or a packet having a setting condition different from the setting condition. A second protocol stack that receives only the first protocol stack and is processed in preference to the first protocol stack. The first protocol stack is used in normal packet reception processing, and receives a packet that matches the set conditions. The first protocol stack is often incorporated in a kernel of an OS (operating system), and there is also a mounting method using a dynamic link library. The second protocol stack receives only packets that match the narrower setting conditions within the setting conditions of the first protocol stack or the setting conditions different from the above-mentioned setting conditions. Specialize when a (simplified) reception process is required.
[0010]
With this configuration, high-speed reception processing required for a predetermined packet is realized while maintaining compatibility with an existing protocol.
[0011]
BEST MODE FOR CARRYING OUT THE INVENTION
(Embodiment 1)
FIG. 1 is a configuration diagram of a packet receiving device according to Embodiment 1 of the present invention.
[0012]
In FIG. 1, a packet receiving apparatus 101 transmits data via a DCE (line terminating apparatus) 107 that terminates a communication line 108. The packet receiving apparatus 101 performs an application 105 for performing (transmission) and reception processing of data, a communication access control program 104 for performing protocol processing, access path management, and network management, and performs transmission control, synchronization control, flow control, and error control. The communication control unit 106 performs the communication. The communication access control program 104 has a first protocol stack 102 and a second protocol stack 103 (the configuration of the first embodiment).
[0013]
FIG. 2 is a processing sequence diagram of the packet receiving apparatus 101.
[0014]
FIG. 3 is a hierarchical diagram of the first protocol stack 102 and the second protocol stack 103.
[0015]
If there is a packet that should be received in a manner differentiating from other packets, the application 105 describes the reception conditions, for example, a combination of four numbers (called a name) of an IP address / port number on the client side / server side in the first packet. 2 is set in the protocol stack 103 (S1 in FIG. 2). Thereafter, when the packet receiving apparatus 101 receives a packet, the second protocol stack 103 is processed prior to the first protocol stack 102. When the second protocol stack 103 receives the packet (S2 in FIG. 2), it determines whether the packet conforms to the second protocol stack 103 or matches the set name. If it is a packet to be transferred, the data encapsulated in the packet is transferred to the application 105 (or the data is transferred to a predetermined memory area). If the packet is not a packet to be received, the packet is discarded and the process ends. In the first protocol stack 102, the receiving condition is set from another application or nothing is set, and the packet is received or discarded according to the setting condition (S3 in FIG. 2). .
[0016]
By having such a second protocol stack, high-speed reception processing can be realized by receiving a packet that matches a certain setting condition by using a protocol stack specialized for the application. For example, there is a method in which protocol processing such as packet order control and retransmission control is simplified, and duplication control and sequence management are left to an upper layer protocol (application). In addition, if a standard protocol stack mounted on the OS is used in combination as the first protocol stack, normal packet reception can be performed, so that compatibility with existing applications can be maintained.
[0017]
In this embodiment, the communication control device 106 is provided inside the packet receiving device 101, but may be connected from the outside so as to cooperate with the communication access control program 104. Although the name is set as the reception condition here, the information is not limited to this as long as it is information for identifying a specific packet such as a transmission protocol. Further, in the first protocol stack 102 and the second protocol stack 103, the lower layers (Ethernet (R) layer to IP layer) may be shared by the two protocol stacks.
[0018]
(Embodiment 2)
FIG. 4 is a processing sequence diagram of the packet receiving device according to the second embodiment of the present invention. The configuration of the second embodiment is the same as that of the first embodiment, and the description of the components will be omitted.
[0019]
If there is a packet to be received that is differentiated from other packets, the application 105 sets a name as a reception condition in the second protocol stack 103 (S1 in FIG. 4). When the packet receiving apparatus 101 receives the packet, it is transferred to the second protocol stack 103 and determines whether the packet conforms to the second protocol stack 103 or matches the set name ( S2 in FIG. 4). If the packet does not match the set condition, the packet is transferred to the first protocol stack 102. In the first protocol stack 102, the receiving condition is set from another application or nothing is set, and the packet is received or discarded according to the setting condition (S3 in FIG. 4). When the packet receiving apparatus 101 receives the next packet and transfers it to the second protocol stack 103, the packet is a packet conforming to the second protocol stack 103 and if the packet matches the set conditions, the packet is Is transferred to the application 105 (S4 in FIG. 4). In this manner, a packet normally received and processed by the second protocol stack 103 is not transferred to the first protocol stack 102.
[0020]
According to this processing, the same packet does not need to be processed by both the first and second protocol stacks, and the processing load on the packet receiving device can be reduced.
[0021]
In the process of S2 in FIG. 4, if it is determined that the reception condition of the second protocol stack 103 does not match and that the reception condition of the first protocol stack 102 is not satisfied in the process, the packet is discarded. May be.
[0022]
(Embodiment 3)
FIG. 5 is a processing sequence diagram of the packet receiving device according to the third embodiment of the present invention. The configuration of the third embodiment is the same as that of the first embodiment, and the description of the components will be omitted.
[0023]
FIG. 6 is an example of a packet format to be received by the second protocol stack 103. FIG. 6a shows an IP datagram that the sending device of the packet is about to send. In this case, if the network to which the transmitting device is connected is Ethernet (R), the fragmentation is performed as shown in FIG. 6B because the maximum transfer unit is 1500 bytes.
[0024]
If there is a packet to be received that is differentiated from other packets, the application 105 sets a name serving as a reception condition in the second protocol stack 103 (S1 in FIG. 5). Thereafter, when the packet receiving apparatus 101 receives a packet, the second protocol stack 103 is processed prior to the first protocol stack 102. When the second protocol stack 103 receives the packet (S2 in FIG. 5), it determines whether the packet conforms to the second protocol stack 103 or matches the set name. Then, if the packet is a packet to be received and is a fragment, the offset information of the header is checked, and if the packet arrives in order, it is transferred to the application (or the data is transferred to a predetermined memory area). . At this time, the second protocol stack 103 does not reassemble.
[0025]
According to such processing, when an application that can tolerate packet loss is used, the problem of the IP layer that loss of one fragment leads to loss of a plurality of fragments can be avoided. If the application requires real-time transmission, data can be transferred to the application before reassembly is completed.
[0026]
Here, the data is transferred to the application 105 in the order of arrival of the fragments. However, the fragments are accumulated in the buffer of the second protocol stack 103, and the order of arrival of the fragments is guaranteed within the accumulated range. You may make it.
[0027]
(Embodiment 4)
FIG. 7 is a configuration diagram of an MPEG2 receiving apparatus according to Embodiment 4 of the present invention. 7, the same components as those of FIG. 1 are denoted by the same reference numerals, and description thereof will be omitted. The MPEG2 receiving apparatus 201 is obtained by adding an MPEG2 decoder 202 to the packet receiving apparatus 101 and has a video / audio stream reproducing function. The MPEG2 decoder 202 decodes the MPEG2 transport stream and outputs video / audio in cooperation with the application 105.
[0028]
FIG. 8 is a processing sequence diagram of the MPEG2 receiving apparatus according to Embodiment 4 of the present invention.
[0029]
The application 105 sets the name of the UDP packet for transmitting the MPEG2 transport stream in the second protocol stack 103 as a packet to be received differentiating from other packets (S1 in FIG. 8). When the MPEG2 receiving apparatus 201 receives the packet, it is transferred to the second protocol stack 103 and determines whether the packet conforms to the second protocol stack 103 or matches the set name (FIG. 8 S2). If the packet does not match the set condition, the packet is transferred to the first protocol stack 102. In the first protocol stack 102, the receiving condition is set or not set from another application, and the packet is received or discarded according to the setting condition (S3 in FIG. 8). When the MPEG2 receiving apparatus 201 receives the next packet and transfers it to the second protocol stack 103, if the packet matches the set conditions, the MPEG2 data encapsulated in the packet is transferred to the application 105 (FIG. 8 S4). The application 105 that has received the MPEG2 data transfers it to the MPEG2 decoder 202 (S5 in FIG. 8), and the MPEG2 decoder 202 decodes the MPEG2 data and outputs video / audio (S6 in FIG. 8).
[0030]
According to this processing, while the video / audio stream is processed at a high speed by the second protocol stack, the other packets are processed by the first protocol stack, thereby enabling high-speed reception of large-capacity multimedia information and communication with existing applications. Compatibility can be realized.
[0031]
Although the MPEG2 transport stream is used as the video / audio stream, an MPEG2 program stream or another video / audio format that can be transmitted via IP may be used.
[0032]
【The invention's effect】
As described above, according to the packet receiving apparatus of the present invention, new functions and services can be easily added / changed, but the first protocol stack with a large processing load and the flexible implementation over a plurality of layers of protocols. High-speed multimedia information such as video / audio streams can be transmitted at high speed while maintaining compatibility with existing protocols by using a second protocol stack that can receive lightly by specializing a predetermined packet. Can be processed.
[Brief description of the drawings]
FIG. 1 is a configuration diagram of a packet receiving device according to Embodiment 1 of the present invention. FIG. 2 is a processing sequence diagram of a packet receiving device according to Embodiment 1 of the present invention. FIG. 3 is a communication diagram in Embodiment 1 of the present invention. FIG. 4 is a processing sequence diagram of the packet receiving device according to the second embodiment of the present invention. FIG. 5 is a processing sequence diagram of the packet receiving device according to the third embodiment of the present invention. FIG. 7 is a diagram showing a packet format in Embodiment 3 of the present invention. FIG. 7 is a configuration diagram of an MPEG2 receiving apparatus in Embodiment 4 of the present invention. FIG. 8 is a processing sequence diagram of an MPEG2 receiving apparatus in Embodiment 4 of the present invention. 9: OSI basic hierarchical model and hierarchical diagram of TCP / IP [FIG. 10] Hierarchical diagram of communication device having transmission / reception function by TCP / IP [Description of reference numerals]
101 packet receiving device 102 first protocol stack 103 second protocol stack 104 communication access control program 105 application 106 communication control device 107 DCE
108 Communication line 201 MPEG2 receiver 202 MPEG2 decoder