データ通信装置
【課題】複数の通信プロトコルでＩＰパケットの通信を行なうデータ通信装置であって、構成上および処理上の無駄の発生を削減することができるデータ通信装置を提供すること。
【解決手段】本発明のデータ通信装置は、先頭パケットが有する宛先情報を制御情報記憶部３０７に記憶させる先頭パケット判定部３０２と、宛先情報に基づき先頭パケットの出力先を判定する引渡し先判定部３０５と、宛先情報が制御情報記憶部３０７に記憶されている場合は後続パケットを引渡し先判定部３０５へ渡し、宛先情報が制御情報記憶部３０７に記憶されていない場合は後続パケットをバッファ３０９に記憶させる後続パケット判定部３０３とを備え、引渡し先判定部３０５は、宛先情報記憶手段に記憶されている宛先情報に基づき、後続パケットの出力先を判定する。
【解決手段】本発明のデータ通信装置は、先頭パケットが有する宛先情報を制御情報記憶部３０７に記憶させる先頭パケット判定部３０２と、宛先情報に基づき先頭パケットの出力先を判定する引渡し先判定部３０５と、宛先情報が制御情報記憶部３０７に記憶されている場合は後続パケットを引渡し先判定部３０５へ渡し、宛先情報が制御情報記憶部３０７に記憶されていない場合は後続パケットをバッファ３０９に記憶させる後続パケット判定部３０３とを備え、引渡し先判定部３０５は、宛先情報記憶手段に記憶されている宛先情報に基づき、後続パケットの出力先を判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定の通信プロトコルに従い、ネットワークを介して他の機器とのデータ通信を行うためのデータ通信装置に関する。
【背景技術】
【０００２】
近年、Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ（ＤＬＮＡ）に従ったホームネットワークの構築が活発化してきており、ＤＬＮＡに対応するＡＶネットワーク機器が商品化されてきている。
【０００３】
ＤＬＮＡは、一般の消費者が家庭内ネットワーク上につながっている異なるメーカーの製品同士がシームレスの相互接続環境を実現し、どの準拠製品からでも高い互換性が確保されたコンテンツをアクセスして楽しむことを可能にすることを目標とする規格である。
【０００４】
ＤＬＮＡでは、ホームネットワーク環境における機器間の相互接続に重要であるメディアサーバとそのネットワーク中のコンテンツを再生する機器についての設計ガイドラインが定義されている。
【０００５】
家庭内でのＡｕｄｉｏ ａｎｄ Ｖｉｓｕａｌ（ＡＶ）データ伝送が行われてきている昨今、地上波デジタル放送の開始などで高転送レートのＡＶデータを伝送する機能が必要となってきた。
【０００６】
その背景の中、低コスト化から能力の低いＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）が使用されるＡＶ機器では、高転送レートのＡＶデータ伝送を実現するための高速伝送用のＣＰＵとそれ以外のデータ通信を行うＣＰＵとの２つのＣＰＵを使用する構成がとられるのが一般的ある（例えば、特許文献１参照）。
【０００７】
さらに、両ＣＰＵには、データ通信を行うための通信プロトコルが搭載される。搭載される通信プロトコルの形態には、ハードウェアで構成するもの（例えば、特許文献２参照）や、ソフトウェアで構成するものがある。また、両ＣＰＵはバス接続され、ＣＰＵ間での通信を行う。
【０００８】
ここでいう通信プロトコルには、Ｔｒａｎｓｍｉｓｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＴＣＰ／ＩＰ）が標準として使用される。ＴＣＰ／ＩＰは、インターネット上の標準であり、世界中で最も広く使用されている通信プロトコルである。ＴＣＰ／ＩＰには、ＴＣＰとＩＰはもちろんのこと、一般的なこととして、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）、Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＡＲＰ）を含むものとする。ＩＣＭＰ、ＡＲＰについては後述する。
【０００９】
以下、従来のＡＶネットワーク機器において２つのＣＰＵで高転送レートのＡＶデータを伝送する従来の方法について、図１を使用して説明する。
【００１０】
図１は、従来のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【００１１】
図１に示すＡＶデータ伝送システムは、記録装置にＭｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）規格などで圧縮されたＡＶコンテンツが記録されているＡＶデータ送信装置１０と、ＡＶデータ送信装置から伝送されるＡＶデータを再生装置によって再生するＡＶデータ受信装置１３で構成される。ＡＶデータ受信装置１３は、通信プロトコルとしてＴＣＰ／ＩＰを使い、ネットワークを介してＡＶデータ送信装置に接続する。
【００１２】
なお、上述の記録装置および再生装置等の図示および説明は省略し、ＡＶデータの伝送に関する構成部についての図示および説明のみを行なう。
【００１３】
ＡＶデータ送信装置１０は、ＡＶデータを伝送する高速伝送用装置１２とＡＶデータの伝送以外のデータ通信を行うホスト装置１１とを備えている。ＡＶデータ受信装置１３は、同様に、高速伝送用装置１２とホスト装置１４とを備えている。
【００１４】
ホスト装置１１およびホスト装置１４は、第１の通信プロトコルによる通信を行なう第１通信プロトコル部１０２と、第１通信プロトコル部１０２にアクセスするための第１インターフェース（Ｉ／Ｆ）部１０１とをともに有する、また、それぞれは、第１Ｉ／Ｆ部１０１を介して第１通信プロトコル部１０２を使用する、通信のためのアプリケーションプログラム（以下、「ＡＰＰ」ともいう。）と、高速伝送用装置１２が有する第２通信プロトコル部１２２を使用するＡＶ伝送アプリケーションプログラムと、あらかじめホスト装置で所有している情報を高速伝送用装置１２に設定する情報設定部１０３とを有している。
【００１５】
高速伝送用装置１２は、ＡＶデータ伝送アプリケーションプログラムが使用する、第２の通信プロトコルによる通信を行なう第２通信プロトコル部１２２と、第２通信プロトコル部１２２にアクセスするための第２Ｉ／Ｆ部１２１と、第１通信プロトコル部１０２または第２通信プロトコル部１２２から入力されるデータを他の機器に送信し、また、ネットワークを介して受信したデータをパケット振り分け部１２４に出力する送受信部１２３と、送受信部１２３から入力された受信データを第１通信プロトコル部１０２または第２通信プロトコル部１２２に振り分けて出力するパケット振り分け部１２４とを有する。
【００１６】
ホスト装置１１およびホスト装置１４が有する通信アプリケーションプログラム、具体的には、サーバＡＰＰ１０５、クライアントＡＰＰ１０６、クライアントＡＰＰ１０８、およびサーバＡＰＰ１０９は、直接サービスを提供または利用するアプリケーションプログラムや、ＡＶデータ送信装置１０またはＡＶデータ受信装置１３を制御するアプリケーションプログラムなどである。
【００１７】
直接サービスを提供するアプリケーションプログラムとして、例えば、ＴＣＰ／ＩＰの上位プロトコルに位置するＦｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＦＴＰ）、Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）などの通信プロトコルを使用するものがある。また、独自仕様のアプリケーションプログラムである場合もある。
【００１８】
ＴＣＰ／ＩＰを使用する通信アプリケーションプログラムの多くは、クライアント／サーバモデルに準じて作られる。ホスト装置１１およびホスト装置１４の通信アプリケーションプログラムもこれに準じている。
【００１９】
また、ＡＶデータ送信装置１０が有するＡＶ伝送サーバＡＰＰ１０４はサーバアプリケーションであり、ＡＶデータ受信装置１３が有するＡＶ伝送クライアントＡＰＰ１０７はクライアントアプリケーションである。
【００２０】
ＴＣＰ／ＩＰを使う通信アプリケーションプログラムは、ポート番号を使用してアプリケーションプログラム間の通信回線を開く。ポート番号は、ＴＣＰおよびＵＤＰがアプリケーションプログラムを識別する際に使用される。
【００２１】
第１Ｉ／Ｆ部１０１および第２Ｉ／Ｆ部１２１は、一般的にソケットと呼ばれるＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）である。
【００２２】
ホスト装置１１の情報設定部１０３は、通信パスＡを使用して、ホスト装置１１で使用するＩＰアドレスやサブネットマスクなどの情報を高速伝送用装置１２に設定する。第１通信プロトコル部１０２は、通信パスＢを使用して送受信部１２３に送信したいデータを入力する。ＡＶ伝送サーバＡＰＰ１０４は、通信パスＣを使用し、第２Ｉ／Ｆ部を介して第２通信プロトコル部１２２と通信する。第２通信プロトコル部１２２は、通信パスＤを使用して送受信部１２３に送信したいデータを入力する。パケット振り分け部１２４は、通信パスＢと通信パスＤを使用して受信したデータを第１通信プロトコル部１０２と第２通信プロトコル部１２２とに振り分けて出力する。なお、ＡＶデータ受信装置１３のホスト装置１４の各構成部も同様の動作を行う。
【００２３】
上述のパケット振り分け部１２４は具体的には、次に説明する方法で振り分けを行う。
ＡＶデータ受信装置１３のＡＶ伝送クライアントＡＰＰ１０７は、接続する際に接続先ポート番号と第２通信プロトコル部１２２において使用するポート番号とを通信パスＣと第２Ｉ／Ｆ部１２１とを介して第２通信プロトコル部１２２に入力する。これにより、ＡＶデータ送信装置１０のＡＶ伝送サーバＡＰＰ１０４との通信回線を確立する。そして、ＡＶ伝送クライアントＡＰＰ１０７は、この確立されたポート番号を使用して、ＡＶデータの受信を行う。
【００２４】
ＡＶデータ送信装置１０のＡＶ伝送サーバＡＰＰ１０４は、使用するポート番号を通信パスＣと第２Ｉ／Ｆ部１２１とを介して第２通信プロトコル部１２２に入力して、使用する通信回線を開いて待機する。ＡＶ伝送クライアントＡＰＰ１０７からの通信回線確立が行われると、ＡＶ伝送サーバＡＰＰ１０４はＡＶデータの送信を行う。
【００２５】
上述のＡＶ伝送クライアントＡＰＰ１０７およびＡＶ伝送サーバＡＰＰ１０４が使用するポート番号のそれぞれは、通信パスＤを介し、ＡＶデータ伝送用として、それぞれのパケット振り分け部１２４に設定される。
【００２６】
パケット振り分け部１２４は、この設定されたポート番号と受信したパケットのポート番号とを照合して、該当するパケットであれば、通信パスＤにより第２通信プロトコル部１２２へ出力する。該当しないパケットであれば、通信パスＢにより第１通信プロトコル部１０２へ出力する。
【００２７】
ＡＶデータ送信装置１０とＡＶデータ受信装置１３とは、上述の構成および動作により、高転送レートのＡＶデータを伝送している。
【００２８】
本構成における、本発明に関わる従来技術について、（１）から（４）に分けて説明する。
【００２９】
（１）一般的なこととして、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）では、通過するネットワークが許容する最大転送単位（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ（ＭＴＵ）サイズ）にあわせてパケット分割（フラグメント）するという機能を持っている。
【００３０】
つまり、送信側では、アプリケーションプログラムから渡されたパケットがＭＴＵサイズよりも大きいとパケットの分割を行って送信する。受信側では、受信した分割パケット（フラグメントパケット）を元のパケットに再構築する。
【００３１】
なお、ＩＰにおけるフラグメントのことをＩＰフラグメントといい、ＩＰフラグメントにより生じる、分割された各パケットをＩＰフラグメントパケットという。
【００３２】
図２（ａ）は、ＩＰフラグメントの発生からＩＰフラグメントパケットの再構築までの処理の流れの一例を示す図である。図２（ｂ）は、ＩＰフラグメントパケットの一例を示す図である。
【００３３】
送信側の機器Ａと受信側の機器Ｂとが接続されたネットワークにおけるＭＴＵサイズは１５００オクテットである。ここで、図２（ａ）に示すように、そのネットワーク上に、ＭＴＵサイズが６２０オクテットのネットワークが存在する場合を想定する。このようなネットワーク構成において、機器Ａが機器Ｂに１０００オクテットのデータを送信する場合、ＩＰパケットはネットワークの境界にあるルータａで６００オクテットと４００オクテットのパケットに分割され送られる。そして、図２（ｂ）に示すように、ＴＣＰヘッダ（または、ＵＤＰヘッダ）の情報は、分割された先頭パケットにしか存在しない。つまり、ＩＰパケットの宛先である通信プロトコル部を特定するポート番号は、先頭パケットにのみ存在し、後続パケットには存在しない。
【００３４】
また、ＩＰフラグメントパケットは、ネットワークの状況によって順不同で到着することもある。最悪、パケットがネットワーク上で消失することもある。ＩＰでは、ＩＰフラグメントパケットの再構築の機能として、順不同で到着するパケットも許容される。
【００３５】
図３は、ＩＰフラグメントパケットが再構築できなかった際の処理の概要を示す図である。
【００３６】
図３に示すように、ネットワークでＩＰフラグメントパケットの一部が消失して再構築できない場合、ＩＰは、ＲＦＣ１１２２で推奨として記述されている６０ｓｅｃから１２０ｓｅｃのタイマ値の経過によって再構築できなかったパケットを廃棄する。廃棄する際、先頭パケットを受信していた場合に限り、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）によるＩＣＭＰ時間超過メッセージ（ＩＣＭＰフラグメントエラーメッセージ）を送信元に送出して再構築できなかったことを通知する。前述のＲＦＣとは、Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓの略であり、インターネットに関する技術の標準を定める団体であるＩＥＴＦが正式に発行する文書である。
【００３７】
従来のパケット振り分け部１２４のフラグメント再構築部２１０は、ＩＰフラグメントパケットの再構築が完了した後、先頭パケットに含まれるポート番号を照合して送信先に該当する通信プロトコル部に出力する。つまり、ポート番号に応じて第１通信プロトコル部１０２または第２通信プロトコル部１２２に再構築されたパケットを出力する。
【００３８】
また、再構築できずに残ってしまうパケットを１２０ｓｅｃ（推奨されているタイマ値の最大値）の経過により廃棄する。そして、廃棄する際、先頭パケットを受信していた場合には、ＩＣＭＰ時間超過メッセージ（ＩＣＭＰフラグメントエラーメッセージ）を送信する。このように、ＩＰフラグメントパケットを受信した場合には、ＩＰが行う処理、つまり、第１通信プロトコル部１０２および第２通信プロトコル部１２２が行なう処理をパケット振り分け部１２４でも行なっている。
【００３９】
図４は、従来のフラグメント再構築部の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント再構築部２１０の機能以外の機能を表す機能ブロックである。
【００４０】
図４を使用して、従来のフラグメント再構築部の構成について説明する。
受信したパケットはフラグメント判定部４０１に入力され、ＩＰフラグメントパケットであるか否かの判定を行う。フラグメント判定部４０１は、ＩＰフラグメントパケット以外であればパケット振り分け部１２４ａに渡し、ＩＰフラグメントパケットであれば先頭・後続パケット判定部４０２に出力する。
【００４１】
先頭・後続パケット判定部４０２は、入力されるＩＰフラグメントパケットをバッファ４０７に格納すると共に再構築情報記録部４０６に記憶されている再構築情報の情報更新を行う。また、フラグメント終了判定部にパケットを受信したことを通知する。そして、新規のＩＰパケットの断片であるＩＰフラグメントパケットを受信した際には、そのＩＰフラグメントパケットを１２０ｓｅｃ後に廃棄するためのタイマを起動する。
【００４２】
図５（ａ）は、ＩＰヘッダフォーマットを示す図であり、図５（ｂ）は、ＩＰヘッダに含まれるＰＲＯＴＯＣＯＬ領域の値とプロトコル名との対応を示す図であり、図５（ｃ）は、ＩＰヘッダに含まれるＦＬＡＧＳ領域のビットと意味との対応を示す図である。
【００４３】
図５（ａ）に示すＩＰヘッダに含まれるＩＤ３４０５、ＦＬＡＧＳ３４０６、ＯＦＦＳＥＴ３４０７、およびＴＯＴＡＬ＿ＬＥＮ３４０４の４種の情報により、ＩＰフラグメントパケットは識別される。この４種の情報からなる情報を以下、「ＩＰフラグメント識別情報」という。ＩＰフラグメント識別情報に基づいて再構築情報の更新やタイマ起動が行われる。
【００４４】
ＩＰフラグメントパケット到着の通知を受けたフラグメント終了判定部４０３では、再構築情報から再構築完了を判断する。再構築が完了している場合、引渡し先判定部４０４に通知する。通知を受けた引渡し先判定部４０４では、バッファ４０７に格納されている再構築が完了したＩＰフラグメントパケットを全て読み出し、再構築情報記憶部４０６の情報を消去しタイマを停止する。そして、先頭のＩＰフラグメントパケットに付与されているＴＣＰヘッダ（または、ＵＤＰヘッダ）に含まれるポート番号を照合して通信パスを決定し、再構築が完了したＩＰフラグメントパケットの出力要求を引渡し部４０５へ行う。
【００４５】
引渡し部４０５は要求にしたがって、通信パスＢまたは通信パスＤへ再構築完了したＩＰフラグメントパケットを出力する。
【００４６】
再構築が完了せずに、タイマによるタイムアウトが発生すると、情報消去部４０８は、タイムアウトとなるＩＰフラグメントパケットに関する再構築情報を再構築情報記憶部４０６から消去し、バッファ４０７内の、再構築できなかったＩＰフラグメントパケットを廃棄する。この際、再構築情報から先頭パケットを受信しているかどうかも判断する。先頭パケットを受信済みであった場合のみ、先頭パケットに含まれる情報を使用してＩＣＭＰ時間超過メッセージ（ＩＣＭＰフラグメントエラーメッセージ）を生成する。生成されたＩＣＭＰフラグメントエラーメッセージは送受信部１２３により、当該ＩＰフラグメントパケットの送信元に送信される。
【００４７】
従来のフラグメント再構築部２１０は以上のように構成され、動作している。
【００４８】
（２）一般的なこととして、通信プロトコル（ＴＣＰ／ＩＰ）には、ＩＰを補助するＩＣＭＰが含まれる。ＩＰパケットが何らかの障害によって到達できなかった時にＩＣＭＰによって障害の通知（ＩＣＭＰエラーメッセージ）が行われる。
【００４９】
ＩＣＭＰエラーメッセージにはＲＦＣ７９２で規定されるいくつかのタイプがあり、ＩＰを使って送信される。したがって、ＴＣＰヘッダ（または、ＵＤＰヘッダ）がつかないパケットであるため、パケット振り分け部ではどちらの通信プロトコル部に出力すればよいか判断できない。
【００５０】
そこで、従来のパケット振り分け部１２４のＩＣＭＰ複製部２１１では、受信したＩＣＭＰエラーメッセージパケットを複製して、第１通信プロトコル部１０２と第２通信プロトコル部１２２へ出力している。
【００５１】
図６は、従来のＩＣＭＰ複製部の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、ＩＣＭＰ複製部２１１の機能以外の機能を表す機能ブロックである。図６を使用して、ＩＣＭＰ複製部の構成および動作について説明する。
【００５２】
受信されたパケットはＩＣＭＰパケット判定部７０１に入力され、ＩＣＭＰパケット判定部７０１は入力されたパケットがＩＣＭＰパケットであるか否かの判定を行う。ＩＣＭＰパケット判定部７０１は、ＩＣＭＰパケット以外であればパケット振分け部１２４ａに渡し、ＩＣＭＰパケットであればパケット複製部７０２へ出力する。パケット複製部７０２は、入力されたＩＣＭＰパケットを複製して、通信パスＢと通信パスＤへ送信する要求と共に２つのＩＣＭＰパケットを引渡し部７０３へ出力する。引渡し部７０３は要求にしたがって、通信パスＢと通信パスＤへそれぞれＩＣＭＰパケットを出力する。
【００５３】
つまり、ＩＣＭＰパケットは第１通信プロトコル部１０２および第２通信プロトコル部１２２の双方へ出力される。
【００５４】
従来のＩＣＭＰ複製部２１０は以上のように構成され、動作している。
【００５５】
（３）従来のパケット振り分け部１２４において、正常に通信パスＢと通信パスＤへパケットを振り分けるためには、通信パスＣを使って設定されるポート番号が、ＡＶデータ伝送アプリケーションプログラム以外の通信アプリケーションプログラムで使用されるポート番号と異なる番号でなければならない。
【００５６】
従って、従来のＡＶデータ受信装置１３では、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号の範囲を取り決めて、クライアントＡＰＰ１０８およびサーバＡＰＰ１０９がそのポートを使用しないようにしている。例えば、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号を１０００１〜１０００２とし、それ以外をクライアントＡＰＰ１０８等の他の通信アプリケーションプログラムが使うようにしている（例えば、特許文献３参照）。
【００５７】
しかし、この方法では全てのアプリケーションプログラムで自らが使用するポート番号をあらかじめ決定するか、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号を、第１Ｉ／Ｆ部１０１にて使わないように制限をかけることをする必要がある。
【００５８】
一般的なこととして、サーバアプリケーションプログラムは通信回線を開いておかなければならないため、通信プロトコルＩ／Ｆを介して自らが使用するポート番号を通信プロトコル部に指定して通信回線を開かせる。一方、クライアントアプリケーションプログラムは、自らが使用するポート番号は意識することなく、通信プロトコルＩ／Ｆを介して通信回線を確立したいサーバアプリケーションプログラムのポート番号とＩＰアドレスとを指定して通信プロトコル部に通信回線を確立させる。しかし、クライアントアプリケーションプログラムは自らのポート番号を意識しないが、実際には通信プロトコルＩ／Ｆが使用されていないポート番号を適切に割り当てて通信プロトコル部に通信回線を確立させることが行われている。
【００５９】
（４）一般的なこととして、通信プロトコル部は、宛先ＩＰアドレスがわかれば、ＩＰパケットを送信することができる。しかし、実際にはＩＰアドレスに対応した物理アドレス（ＭＡＣアドレス）がわかれなければ通信相手にパケットを到着させることができない。
【００６０】
この物理アドレスの解決は、通信プロトコル部が装備するアドレス解決プロトコル（ＡＲＰ）によって行われる。アドレス解決の仕組みについて、図７に図解する。
【００６１】
図７は、アドレス解決プロトコル（ＡＲＰ）による一般的なアドレス解決の仕組みを示す図である。
【００６２】
ＡＲＰは、通信元が、ＩＰアドレスは知っているが物理アドレスがわからない通信相手の物理アドレスを検索するためのプロトコルである。通信元は、通信相手を探すためのＡＲＰ要求パケットをブロードキャストし、該当する通信相手はＡＲＰ応答パケットを返送して自らの物理アドレスを通知する。ＡＲＰ応答パケットを受信した送信元は、ＩＰアドレスと物理アドレスとの関連を管理するＡＲＰテーブルに記録する。これによって、物理アドレスを解決した通信プロトコル部は、ＩＰパケットを通信相手に送信することが可能となる。
【００６３】
従来、例えば、特許文献４に記述される方法でアドレス解決が行われる。
図８は、特許文献４に開示された、物理アドレスの解決を行なう従来のホストコンピュータの機能的な構成を示す機能ブロック図である。
【００６４】
特許文献４に記述されるアドレス解決方法を、図１に示すＡＶデータ受信装置１３に適用した場合を想定する。
【００６５】
ＡＶ伝送クライアントＡＰＰ１０７が通信先の物理アドレスを知らなかった場合、通信先宛のダミーＩＰパケットが第１Ｉ／Ｆ部を介して第１通信プロトコル部１０２に送られる。第１通信プロトコル部１０２では、ＡＲＰによるアドレス解決が実行され、通信パスＢを使用してダミーＩＰパケットの送信を行おうとする。ここで、通信先の機器がダミーＩＰパケットを廃棄しない構成である場合、ダミーＩＰパケットの送信を止めるために、通信パスＢ上にダミーＩＰパケットを廃棄する処理部を設けなければならない。
【００６６】
ＡＶ伝送クライアントＡＰＰ１０７は、第１通信プロトコル部１０２でＡＲＰによるアドレス解決が行われたことをＡＲＰからの通知により、または、第１通信プロトコル部１０２が有するＡＲＰテーブルを監視することにより所望の物理アドレスを得たことを検知し、その物理アドレスを取得する。そして、通信パスＣにより、第２Ｉ／Ｆ部１２１を介して、取得した物理アドレスを第２通信プロトコル部１２２のＡＲＰテーブルへ登録する。このようにして、第２の通信プロトコルにおけるアドレス解決を行い、ＡＶ伝送クライアントＡＰＰ１０７は、通信パスＣを使用して通信を開始する。
【特許文献１】特開２０００−２３５５３６号公報 （第４−５頁、第１図）
【特許文献２】特開２００２−３５４０４６号公報 （第４頁、第２図）
【特許文献３】特開２０００−２３５５３６号公報 （第１０頁）
【特許文献４】特開２０００−２３５５３６号公報 （第１１頁、第五図）
【発明の開示】
【発明が解決しようとする課題】
【００６７】
上述のように、上記従来のＡＶネットワーク機器は、高転送レートが要求されるため、ホスト装置と高速伝送用装置とで構成されている。さらに、１つの機器に複数の通信プロトコルが搭載されている。このような構成の機器においては、以下のような課題がある。
【００６８】
パケット振り分け部１２４におけるフラグメント再構築部２１０では、適切に出力する通信パスを決定するためにＩＰフラグメントパケットを再構築する処理を行っている。このパケットの再構築機能は、ＩＰに標準搭載されている機能である。つまり、第１通信プロトコル部１０２および第２通信プロトコル部１２２に搭載されている機能をフラグメント再構築部２１０にも搭載することとなり、冗長に機能が追加されている。
【００６９】
また、パケットの再構築が完了するまでバッファ４０７にＩＰフラグメントパケットを保持しておかなければならず、バッファ４０７を他の処理と共有する際に有効活用できないという課題を有している。さらに、再構築が完了しなければ第１通信プロトコル部１０２または第２通信プロトコル部１２２へ出力しないため、第１通信プロトコル部１０２または第２通信プロトコル部１２２へのパケット到着がＩＰフラグメントパケットの場合には常に遅延するという課題も有している。
【００７０】
また、上記従来の技術においては、更に、以下のような課題も有している。
パケット振り分け部１２４のＩＣＭＰ複製部２１１では、受信したＩＣＭＰエラーメッセージパケットの送信先の通信パスを判断することができない。そのため、受信したＩＣＭＰエラーメッセージパケットを複製して第１通信プロトコル部１０２と第２通信プロトコル部１２２とへ出力していた。つまり、第１通信プロトコル部１０２を使用してデータ通信を行っている通信回線に異常が発生した際、受信するＩＣＭＰエラーメッセージパケットをまったく関係のない第２通信プロトコル部１２２にも出力することになる。また、当然に逆のパターンも発生する。
【００７１】
したがって、冗長にＩＣＭＰエラーメッセージパケットの複製処理を行い、ＣＰＵの処理能力を使用していることとなる。さらに、第１通信プロトコル部１０２を使用してデータ通信を行っている通信回線に異常が頻発した際、無関係である第２通信プロトコル部１２２にも処理負荷をかけることとなり、高速伝送に弊害を及ぼす課題も有している。
【００７２】
また、上記従来の技術では、パケット振り分け部１２４にて正常にポート番号の照合を行うために、全てのアプリケーションプログラムで自らが使用するポート番号をあらかじめ決定するか、第１Ｉ／Ｆ部１０１を改変し、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号を使用しないように制限をかける必要がある。さらに、通常のクライアントアプリケーションプログラムは一般的に、ポート番号の決定を通信プロトコルインターフェースに委ねており、他のシステムで使用されていた通信アプリケーションプログラムを、従来のＡＶネットワーク機器で使用する際には、その通信アプリケーションプログラムにも改変を加えなければならないという課題を有している。
【００７３】
また、上記従来の技術では、第２通信プロトコル部１２２が使用する物理アドレスを解決するために、第１通信プロトコル部１０２が物理アドレスの解決を実行する必要があった。また、解決したアドレスを通信パスＣを介して登録するという通信を行わなければならなかった。さらに、ホスト装置のＡＶ伝送アプリケーションプログラムはダミーＩＰパケットを送信する動作を行わなければならず、高速伝送装置はダミーＩＰパケットを廃棄する動作を行わなければない。このように、ＡＶ伝送アプリケーションが第１通信プロトコル部１０２も使用しなければならないという課題と、ホスト装置と高速伝送装置の両装置で連動して動作する処理を追加しなければならないという課題とを有している。
【００７４】
本発明は、上記従来の課題を考慮し、複数の通信プロトコルでＩＰパケットの通信を行なうデータ通信装置であって、構成上および処理上の無駄の発生を削減することができるデータ通信装置を提供することを目的とする。
【課題を解決するための手段】
【００７５】
上記目的を達成するために、本発明のデータ管理装置は、第１の通信プロトコルで通信する第１通信プロトコル部と、第２の通信プロトコルで通信する第２通信プロトコル部とを備え、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）パケットによる通信を行なうデータ通信装置であって、前記ＩＰパケットは、前記ＩＰパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するための宛先情報を有する１つの第１パケットと、前記宛先情報を有しない１つ以上の第２パケットとに分割されており、前記データ通信装置は、前記第１パケットまたは前記第２パケットである、ＩＰフラグメントパケットを受信する受信手段と、前記宛先情報を記憶するための宛先情報記憶手段と、前記第２パケットを記憶するためのバッファと、前記ＩＰフラグメントパケットが第１パケットであるか否かを判定し、前記ＩＰフラグメントパケットが第１パケットである場合、前記第１パケットが有する宛先情報を、前記宛先情報記憶手段に記憶させる第１パケット判定手段と、前記第１パケットを、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する振り分け手段と前記ＩＰフラグメントパケットが、前記第１パケット判定手段により前記第１パケットでないと判定された第２パケットである場合、前記宛先情報が前記宛先情報記憶手段に記憶されているとき、前記第２パケットを前記振り分け手段へ渡し、前記宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させる第２パケット制御手段とを備え、前記振り分け手段は、前記第２パケット制御手段から前記第２パケットを受け取ると、前記宛先情報記憶手段に記憶されている前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ前記第２パケットを出力する。
【００７６】
これにより、本発明のデータ通信装置は、ＩＰフラグメントパケットの再構築処理を通信プロトコル部と重複してパケット振り分け部に設けなくてよい。さらに、第１パケットである先頭パケットを受信すると、その先頭パケットを第１通信プロトコル部または第２通信プロトコル部へ引き渡すことができる。これにより、先頭パケット引渡しまでの遅延時間が減少する。また、その宛先に関する宛先情報は記憶されるため、第２パケットである後続パケットは、その宛先情報に基づいて適切に第１通信プロトコル部または第２通信プロトコル部へ振り分けられて出力される。従って先頭パケットが到着した後に到着する後続パケットは、バッファを使用しなくてもよい。つまり、バッファを効率良く使用できる。
【００７７】
また、前記受信手段は、更に、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）エラーメッセージパケットを受信し、前記データ通信装置は、更に、前記ＩＣＭＰエラーメッセージパケットが、前記ＩＣＭＰエラーメッセージパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するためのエラー通知先情報を有するか否かを判定するエラーパケット判定手段と、前記エラーパケット判定手段により前記エラー通知先情報を有していると判定された前記ＩＣＭＰエラーメッセージパケットを、前記通知先情報に基づき、第１通信プロトコル部および第２通信プロトコル部のいずれか一方に出力するエラー出力手段と、前記エラーパケット判定手段により前記エラー通知先情報を有していないと判定された前記ＩＣＭＰエラーメッセージパケットを複製し、第１通信プロトコル部および第２通信プロトコル部のそれぞれに前記ＩＣＭＰエラーメッセージパケットを１つずつ出力するエラー複製手段とを備えるとしてもよい。
【００７８】
これにより、複製が必要なＩＣＭＰパケットのみ複製を行うようになり、無用なパケット複製による処理負荷を減らすことができる。また、第１通信プロトコル部および第２通信プロトコル部は、自身に不要なＩＣＭＰパケットを受信する回数が減り、無駄な処理負担を削減することができる。
【００７９】
また、本発明のデータ通信装置は、更に、前記第１通信プロトコル部で使用されるポート番号の登録要求と削除とを受け付けるインターフェースと、前記第２通信プロトコル部で使用される使用ポート番号を決定するポート番号決定手段と、前記ポート番号決定手段により決定された前記使用ポート番号の登録要求を、前記インターフェースを介して前記第１通信プロトコル部に行なうポート番号登録手段と、前記第２通信プロトコル部からの所定の通知により、前記第１通信プロトコル部に登録されている前記使用ポート番号を削除するポート番号削除手段とを備え、前記インターフェースは、前記第１プロトコル部に登録されているポート番号の登録は受け付けず、前記ポート番号登録手段が、前記使用ポート番号を前記第１通信プロトコル部に登録できた場合、前記使用ポート番号は前記第１通信プロトコル部では使用されないとしてもよい。
【００８０】
これにより、例えば、第２通信プロトコル部を使用するＡＶデータ伝送を行うクライアントアプリケーションは、従来のクライアントアプリケーションと同様にポート番号を意識せずデータ通信を行うことができる。さらに、第１通信プロトコル部のインターフェースにポート番号の制限を行うための改変を行わなくてもよい。
【００８１】
また、本発明のデータ通信装置は、更に、前記第１通信プロトコル部または前記第２通信プロトコル部から送信される、他の機器の物理アドレスの解決を要求するＡｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＡＲＰ）要求パケットを受け付けるＡＲＰ要求受付手段と、前記ＡＲＰ要求受付手段により受け付けられた前記ＡＲＰ要求パケットから得られる、送信元を示す送信元情報と、前記他の機器のＩＰアドレスである送信先アドレスとを対応付けて記憶するＡＲＰ情報記憶手段と、前記ＡＲＰ要求パケットを前記他の機器に送信するＡＲＰ送信手段と、前記他の機器から送信される、前記ＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットを受信するＡＲＰ応答受信手段と、前記ＡＲＰ応答受信手段により受信された前記ＡＲＰ応答パケットから得られる、前記他の機器のＩＰアドレスと、前記ＡＲＰ情報記憶手段に記憶されている前記送信先アドレスとから、前記ＡＲＰ応答パケットの出力先を判定する応答出力判定手段と、前記応答出力判定手段の判定結果に従い、前記ＡＲＰ応答パケットを前記第１通信プロトコル部または前記第２通信プロトコル部のいずれか一方に出力する応答出力手段とを備えるとしてもよい。
【００８２】
これにより、例えば、第１通信プロトコル部を有するホスト装置と、第２通信プロトコル部を有する高速伝送用装置とで構成されたＡＶデータ送信装置において、ホスト装置への機能および処理の追加を行なうことなく、さらに、第２通信プロトコル部を使用するＡＶ伝送アプリケーションが第１通信プロトコル部を使用することなく、第１通信プロトコル部および第２通信プロトコル部が要求する物理アドレスの解決を行うことができる。
【００８３】
更に、本発明は、本発明のデータ通信装置の特徴的な構成部をステップとする方法として実現したり、それらのステップを含むプログラムとして実現したり、そのプログラムが格納された、ＣＤ−ＲＯＭ等の記録媒体として実現したり、集積回路として実現することもできる。プログラムは、通信ネットワーク等の伝送媒体を介して流通させることもできる。
【発明の効果】
【００８４】
本発明により、高転送レートでの通信が要求されるデータ通信装置であって、構成上および処理上の無駄の発生を削減するためのデータ通信装置を提供することができる。
【００８５】
以上説明したように、本発明によれば、ホスト装置と高速伝送用装置に複数の通信プロトコルを搭載するＡＶデータ伝送装置において、ＩＰフラグメントパケットの再構築処理を通信プロトコルと重複して高速伝送用装置に設けることなく、フラグメントパケットを処理可能であり、先頭パケットを受信した時点でパケットの引渡しを行うため引渡しまでの遅延が減り、バッファを効率良く使用することが可能となる。そして、ＩＣＭＰパケットの受信では、複製が必要なＩＣＭＰパケットのみ複製を行うことができ、無用なパケット複製による処理負荷を減らすことが可能となる。また、通信プロトコルインターフェースに改変をいれることなく、ＡＶデータ伝送を行うクライアントアプリケーションに対して、従来のクライアントアプリケーションと同様にポート番号を意識させないことが可能である。さらに、通信プロトコルのアドレス解決では、ホスト装置と高速伝送用装置の両装置で連動して動作する処理を必要とせず、さらにＡＶ伝送アプリケーションが第１通信プロトコル部１０２を使用せずに解決することが可能となる。
【００８６】
本発明によるさらなる効果については、後述する本発明の実施の形態の説明や図面に基づく詳細な説明で記述する。
【発明を実施するための最良の形態】
【００８７】
以下、本発明の実施の形態について図面を用いて説明する。
【００８８】
＜実施の形態１＞
本発明の実施の形態１として、ＩＰフラグメントパケットを受信した際のバッファの効率的な利用を可能とする形態について説明する。
【００８９】
本発明の実施の形態１について、図９〜図１３を用いて説明する。
図９は、実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【００９０】
ＡＶデータ送信装置１０およびＡＶデータ受信装置１３のそれぞれは、本発明のデータ通信装置の一例である。具体的には、ＡＶコンテンツをネットワーク伝送する機能を有するＤＶＤレコーダや、ネットワーク伝送でＡＶコンテンツを受信して再生する機能を有するデジタルＴＶ等により実現される。
【００９１】
なお、ＡＶコンテンツを蓄積する機能等、ＡＶデータ送信装置１０およびＡＶデータ受信装置１３が本来備えている構成部についての図示および説明は省略し、本発明の特徴的な構成部についてのみ図示および説明を行なう。後述する実施の形態２〜１６においても同様である。
【００９２】
図９に示すように、実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、図１に示した従来のＡＶデータ送信装置１０およびＡＶデータ受信装置１３と比較すると、パケット振り分け部１２４内に、フラグメント制御部１１０を持つことを特徴とする。フラグメント制御部１１０は、受信したＩＰフラグメントパケットが先頭パケットであるか後続パケットであるかに応じ、効率的に処理する処理部である。
【００９３】
なお、先頭パケットは本発明のデータ通信装置における第１パケットの一例であり、後続パケットは本発明のデータ通信装置における第２パケットの一例である。
【００９４】
図１０は、実施の形態１におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【００９５】
フラグメント制御部１１０は、制御情報記憶部３０７に記憶されている制御情報に基づき、ＩＰフラグメントパケットの通信プロトコル部への送信を制御する。
【００９６】
図１１は、実施の形態１における制御情報記憶部３０７に記憶されている制御情報のデータ構成の一例を示す図である。制御情報がどのように用いられるかについては、後述の動作の説明の中で述べる。
【００９７】
図１２（ａ）は、ＴＣＰヘッダフォーマットを示す図であり、図１２（ｂ）は、ＵＤＰヘッダフォーマットを示す図である。
【００９８】
受信パケットのフォーマットであるＩＰヘッダフォーマットにおけるＤＡＴＡ３４１４（図５（ａ）参照）に、図１２（ａ）および図１２（ｂ）に示すフォーマットのＴＣＰヘッダまたはＵＤＰヘッダなどがペイロードデータとして格納されている。
【００９９】
図１３は、実施の形態１におけるフラグメント制御部１１０の動作の流れを示すフローチャートである。図１３を用いフラグメント制御部１１０の各構成部の動作について説明する。
【０１００】
まず、送受信部１２３を介し、ネットワークからパケットを受信すると、フラグメント判定部３０１へ受信パケットが入力される。
【０１０１】
フラグメント判定部３０１では、受信したパケットＩＰフラグメントパケットかどうかを判定する。受信したパケットがＩＰフラグメントパケットでない場合（Ｓ１０でＮｏ）、パケット振り分け部１２４ａへと受信パケットを出力（Ｓ１１）することで、以降そのパケットは適切な通信パスへ振り分けられる。
【０１０２】
受信パケットがＩＰフラグメントパケットである場合（Ｓ１０でＹｅｓ）、先頭パケット判定部３０２へ受信パケットが出力される。
【０１０３】
先頭パケット判定部３０２は、入力された受信パケットが先頭パケットであるかどうかを判断する。なお、先頭パケット判定部３０２は、本発明のデータ通信装置における第１パケット判定手段の一例である。先頭パケットであるかどうかの判断方法は、一般的なＩＰの仕様であるため、その説明は省略する。
【０１０４】
受信パケットが後続パケットである場合（Ｓ１２でＮｏ）、先頭パケット判定部３０２は、この受信パケットであるＩＰフラグメントパケットを後続パケット判定部３０３へ出力する。後続パケット判定部３０３では、制御情報記憶部３０７に記憶されている制御情報を参照し、以前に、このＩＰフラグメントパケットに対応する先頭パケットが到着していたかどうかを確認する。この確認は、制御情報記憶部３０７に記憶されている制御情報に基づき行なわれる。なお、先頭パケット判定部３０２は、本発明のデータ通信装置における第２パケット制御手段の一例である。
【０１０５】
制御情報記憶部３０７には、図１１に示す制御情報が記憶されている。制御情報記憶部３０７は、本発明のデータ通信装置における宛先情報記憶手段の一例であり、制御情報は、本発明のデータ通信装置における宛先情報の一例である。
【０１０６】
制御情報は１つ以上のエントリで構成される。１つのエントリは、ＩＰヘッダパラメータであるＳＯＵＲＣＥ ＡＤＤＲＥＳＳ１６０１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ１６０２、ＩＤ１６０３、およびＰＲＯＴＯＣＯＬ１６０４の各情報と、送信元ポート番号１６０６、宛先ポート番号１６０７、および先頭パケットの到着有無を示すフラグである先頭パケット到着ｆｌｇ１６０５とで構成される。
【０１０７】
後続パケット判定部３０３は、ＩＰフラグメントパケットを受信するたびに、そのＩＰヘッダ内にあるＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２、およびＩＤ３４０５、を各エントリと比較する。この比較の結果、上記３種の情報が一致し、かつ先頭パケットの到着ｆｌｇ１６０５が到着ありを示すエントリがある場合、受信したＩＰフラグメントパケットに対応する先頭パケットがすでに到着済みであると判断する（Ｓ１３でＹｅｓ）。
【０１０８】
このようにして、先頭パケットが到着済みであることを確認することができる。なお、上述の確認方法は一例であり、この方法に限定するものではない。例えば、先頭パケットのみが有し、後続パケットは有しない情報である宛先ポート番号が、上記３種の情報が一致するエントリに登録されている場合、先頭パケットが到着済みであると判断してもよい。
【０１０９】
後続パケット判定部３０３は、以前に先頭パケットが到着していたことを確認した場合（Ｓ１３でＹｅｓ）、引渡し先判定部３０５へ受信パケットを出力する（Ｓ１４）。また、上記条件を満たすエントリがない場合、まだ先頭パケットが到着していないことを確認し（Ｓ１３でＮｏ）、バッファ３０９へ受信パケットを保存する（Ｓ１５）。
【０１１０】
なお、このとき、受信パケットのＩＰヘッダ内にあるＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２およびＩＤ３４０５の組み合わせを有する制御情報のエントリが、制御情報記憶部３０７に存在しない場合、つまり、受信パケットが初めて到着したＩＰフラグメントパケットである場合（Ｓ１６でＹｅｓ）、新たなエントリとして登録し、情報消去部３１０のタイマ（例えば１２０秒など）を起動させる（Ｓ１７）。
【０１１１】
情報消去部３１０は、タイマを有しており、タイマに設定された期間（例えば１２０秒など）が満了した場合、そのエントリを消去する。また、そのエントリに対応する後続パケットもバッファ３０９から消去する。
【０１１２】
また、先頭パケット判定部３０２が、受信パケットは先頭パケットであると判断した場合（Ｓ１２でＹｅｓ）、制御情報記憶部３０７に記憶されている制御情報を参照し、その先頭パケットに対応する後続パケットがバッファ３０９に保存されているかどうかを確認する。
【０１１３】
この確認は、制御情報記憶部３０７に記憶されている制御情報に基づき行なわれる。
制御情報記憶部３０７は、制御情報に、ＳＯＵＲＣＥ ＡＤＤＲＥＳＳ１６０１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ１６０２、およびＩＤ１６０３の情報の組み合わせが、受信した先頭パケットのＩＰヘッダ内の同パラメータ値の組み合わせと一致するエントリがある場合、その先頭パケットに対応する後続パケットがバッファ３０９に保存されていると判断する（Ｓ１８でＹｅｓ）。なお、上記３つの情報の組合せは本発明のデータ通信装置における識別情報の一例である。
【０１１４】
この場合、先頭パケット判定部３０２は、受信した先頭パケットだけでなく、バッファ３０９に保存されている、その先頭パケットに対応する全ての後続パケットも、引渡し先判定部３０５へ出力する（Ｓ１９）。さらに、当該エントリの先頭パケット到着ｆｌｇ１６０５を到着有りを示す値に変更し、ＰＲＯＴＯＣＯＬ１６０４、送信元ポート番号１６０６、宛先ポート番号１６０７に各情報を登録する。
【０１１５】
後続パケットがバッファ３０９に保存されていない場合、つまり、上記条件に該当するエントリが制御情報記憶部３０７に存在しない場合（Ｓ１８でＮｏ）、受信した先頭パケットのみを引渡し先判定部３０５へ出力する（Ｓ２０）。
【０１１６】
このとき、先頭パケット判定部３０２は、この先頭パケットに対応する新たなエントリを登録し、情報消去部３１０のタイマ（例えば１２０秒など）を起動させる（Ｓ２１）。
【０１１７】
この登録の際、先頭パケット到着ｆｌｇ１６０５は到着有りを示す値に設定される。さらに、ＰＲＯＴＯＣＯＬ１６０４、送信元ポート番号１６０６、宛先ポート番号１６０７に加えＳＯＵＲＣＥ ＡＤＤＲＥＳＳ１６０１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ１６０２、およびＩＤ１６０３が登録される。
【０１１８】
このように、受信パケットまたはバッファ３０９に保持されていたパケットは、先頭パケット判定部３０２または後続パケット判定部３０３により、引渡し先判定部３０５へ出力される。
【０１１９】
引渡し先判定部３０５では、入力された受信パケットのＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２、およびＩＤ３４０５の情報の組み合わせと一致する組合せを有するエントリを検索する。さらに、該当するエントリの宛先ポート番号から宛先ポート番号を特定し（Ｓ２２）、特定した宛先ポート番号と受信パケットとを引渡し部３０６へ出力する。
【０１２０】
引渡し部３０６では、受信した宛先ポート番号に該当する通信プロトコル部への通信パスへ、パケットを送信する（Ｓ２３）。具体的には、第１通信プロトコル部１０２へ送信する場合は、通信パスＢに送信し、第２通信プロトコル部１２２へ送信する場合は、通信パスＤに送信する。このように、引渡し先判定部３０５と引渡し部３０６とにより、本発明のデータ通信装置における振り分け手段は実現される。
【０１２１】
上述のように、実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、フラグメント制御部１１０を有している。フラグメント制御部１１０により、受信したＩＰプラグメントパケットが先頭パケットであるか否か判断され、先頭パケットである場合、その先頭パケットは、宛先である通信プロトコル部へ送信される。
【０１２２】
その際、バッファ３０９に格納されている、その先頭パケットに対応する後続パケットも先頭パケットと共に送信される。
【０１２３】
つまり、後続パケットは先頭パケットが到着するまで、バッファ３０９に保持されるが、先頭パケットが到着すると、宛先の通信プロトコル部に送信される。その後に到着した後続パケットも、制御情報記憶部３０７に宛先のポート番号が記憶されているため、正しく宛先の通信プロトコル部へ送られることとなる。
【０１２４】
従来では、ある１つのデータの振り分けを実施する際に、そのデータを構成する全てのＩＰフラグメントパケットをバッファに保持して再構築する必要がある。そのため、多量のバッファが必要となる。しかしながら、実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３においては、フラグメント制御部１１０の動作により、ある１つデータを宛先の通信プロトコル部へ到達させる際の一時的なバッファの使用量を、そのデータの先頭パケットが到着するまでの最低限の使用量に低減することができる。
【０１２５】
このように、本発明はバッファの利用効率を向上させる効果を有する。つまり、バッファ利用における無駄を削減することができる。
【０１２６】
また、第１通信プロトコル部１０２および第２通信プロトコル部１２２へのパケットの到着の遅延を防ぐことができる。
【０１２７】
＜実施の形態２＞
本発明の実施の形態２として、第１通信プロトコル部１０２または第２通信プロトコル１２２がＩＣＭＰエラーメッセージを送信する際に、不要となる制御情報をバッファから削除する形態について説明する。
【０１２８】
本発明の実施の形態２について、図１４〜図１６を用いて説明する。
図１４は、実施の形態２のＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０１２９】
図１４に示すように、実施の形態２のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、図９に示した実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３と比較すると、送受信部１２３内に、ＩＣＭＰ監視部１１２を持つことを特徴とする。ＩＣＭＰ監視部１１２はＩＣＭＰエラーメッセージを監視する処理部である。
【０１３０】
図１５は、実施の形態２におけるフラグメント制御部１１０およびＩＣＭＰ監視部１１２の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０１３１】
図１６は、ＩＣＭＰエラーメッセージのパケットフォーマットを示す図である。なお、フラグメントタイムアウト用のＩＣＭＰエラーメッセージ（ＴｉｍｅＥｘｃｅｅｄｅｄ ｃｏｄｅ＝１）も本フォーマットであり、タイプ３６０１には、“１１”が設定され、コード３６０２には、“１”が設定されていることで識別される。
【０１３２】
また、ＤＡＴＡ３６０５には、エラーの発生したパケットに関する情報が格納される。この情報を利用する形態については実施の形態１０として後述する。
【０１３３】
実施の形態２のＡＶデータ送信装置１０およびＡＶデータ受信装置１３の動作は、送信パケットを監視する部分以外は、実施の形態１の各装置の動作と同様の動作である。そのため、実施の形態１との差分の説明のみ記載する。
【０１３４】
第１通信プロトコル部１０２または、第２通信プロトコル部１２２が送信するパケットは、通信パスＢまたは通信パスＤを介して、送受信部１２３に入力される。このときのＩＣＭＰ監視部１１２の動作について説明する。なお、以下、第１通信プロトコル部１０２または、第２通信プロトコル部１２２により送信されたパケットを送信パケットという。
【０１３５】
ＩＣＭＰ監視部１１２内の、タイムアウト（以下、「ＴＭＯ」ともいう。）判定部３１１は、送信パケットが、フラグメントタイムアウト用のＩＣＭＰエラーメッセージ（ＴｉｍｅＥｘｃｅｅｄｅｄ ｃｏｄｅ＝１）であるかをチェックする。フラグメントタイムアウト用のＩＣＭＰエラーメッセージである場合、当該メッセージのＤＡＴＡ３６０５の内容を解析する。なお、ＴＭＯ判定部３１１は、本発明のデータ通信装置におけるタイムアウト検出手段の一例である。
【０１３６】
ＤＡＴＡ３６０５には、フラグメントの再構築に失敗した先頭パケットの情報が格納されている。その格納されている情報が図５（ａ）に示すＩＰヘッダフォーマットであり、ＤＡＴＡ３４１４内に、図１２（ａ）および図１２（ｂ）に示したＴＣＰヘッダまたはＵＤＰヘッダのフォーマットが格納されていた場合、その中の、ＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２、およびＩＤ３４０５の情報を参照する。
【０１３７】
次に、ＴＭＯパケット判定部３１１は、これらの情報の組に一致する情報の組を有するエントリが、制御情報記憶部３０７内にあるかをチェックする。該当するエントリがある場合、そのエントリの全ての情報を０クリアする。また、そのエントリに関して、情報消去部３１０のタイマ（例えば１２０秒など）についても停止させた後、前記送信パケットをネットワークへ送出する。また、ＴＭＯパケット判定部３１１は、上記条件を満たすエントリが制御情報記憶部３０７に存在しない場合は、そのまま送信パケットをネットワークへ送出する。
【０１３８】
このように、実施の形態２によれば、情報消去部３１０だけでなく、ＴＭＯパケット判定部３１１が制御情報を消去することができる。具体的には、ＴＭＯパケット判定部３１１は、第１通信プロトコル部１０２または第２通信プロトコル部１２２によりＩＣＭＰエラーメッセージパケットが送信されたことを検出する。ＩＣＭＰエラーメッセージパケットが送信されたということは、そのメッセージに対応する受信パケットについての制御情報は不要であり削除する。これによりバッファ３０９を有効活用することが可能となる。
【０１３９】
なお、ＴＭＯパケット判定部３１１の指示により、情報消去部３１０が、不要な制御情報を消去してもよい。
【０１４０】
＜実施の形態３＞
本発明の実施の形態３として、ＩＰフラグメントパケットの廃棄のための適切なタイマ値設定を考慮した形態を説明する。
【０１４１】
本発明の実施の形態３について、図１７を用いて説明する。
図１７は、実施の形態３におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０１４２】
実施の形態３は、フラグメント制御部１１０がタイマ設定部１９０１を備える形態である。タイマ設定部１９０１は、第１通信プロトコル部１０２に設定されたタイマ値を通信パスＡを介して取得し、情報消去部３１０に設定されたタイマ値（例えば１２０秒など）と比較する。比較の結果、大きい方を情報消去部３１０で使用する。他の処理については、実施の形態１と同様である。
【０１４３】
実施の形態３によれば、情報消去部３１０に、第２通信プロトコル部１０２に設定されたタイマ値が設定されている場合、第１通信プロトコル部１０２に設定されたタイマ値と、第２通信プロトコル部１０２に設定されたタイマ値とを比較することができる。
【０１４４】
この比較の結果、大きい方のタイマ値を採用することで、第１通信プロトコル部１０２に求められるタイムアウトのための期間と、第２通信プロトコル部１２２（１２２）に求められるタイムアウトのための期間とを包含したタイマ値で動作することができる。結果、どんなホスト装置に高速伝送用装置１２を接続した場合でも、高速伝送用装置１２に手を加えることなく、適切なタイマ値で動作させることができる。
【０１４５】
一般に、高速伝送用装置の用途として、さまざまなＡＶネットワーク機器のホスト装置と接続することが求められる。そのため、第１通信プロトコル部１０２はホスト装置ごとに異なり、当然、前述のタイマ値もそれぞれ異なることが考えられる。そこで実施の形態３の構成をとることにより、高速伝送用装置１２は、簡単な実現手段で、汎用的かつ量産に適した構成をとることが可能となる。
【０１４６】
＜実施の形態４＞
本発明の実施の形態４として、ＩＰフラグメントパケットの廃棄のための適切なタイマ値設定を考慮した第２の形態を説明する。
【０１４７】
本発明の実施の形態４について、図１８と図１９を用いて説明する。
図１８は、実施の形態４におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０１４８】
図１８に示すように、実施の形態４におけるフラグメント制御部１１０は、実施の形態３におけるフラグメント制御部１１０の情報消去部３１０に換えて、第１消去部２００１および第２消去部２００２を配置した構成となる。
【０１４９】
第１消去部２００１および第２消去部２００２は、それぞれタイマを有しており（図示せず）、それぞれのタイマに異なるタイマ値を設定することが可能である。
【０１５０】
具体的には、第１消去部２００１は、第１通信プロトコル部１０２用のタイマ値が設定され、第２消去部２００２は、第２通信プロトコル部１２２用のタイマ値が設定される。第１通信プロトコル部１０２のタイマ値の取得方法については、実施の形態３と同様である。
【０１５１】
図１９は、実施の形態４における制御情報記憶部３０７に記憶されている制御情報のデータ構成の一例を示す図である。第１プロトコル配送不可フラグ２１０１は第１通信プロトコル部１０２への振り分けが不要であることを示すフラグ値が設定される管理情報領域である。第２プロトコル配送不可フラグ２１０２は、第２通信プロトコル部１２２への振り分けが不要であることを示すフラグ値が設定される管理情報領域である。それぞれ初期化時は、配送可能を示す値をとる。
【０１５２】
なお、第１プロトコル配送不可フラグ２１０１に設定されるフラグ値は、本発明のデータ通信装置における第１経過情報の一例であり、第２プロトコル配送不可フラグ２１０２に設定されるフラグ値は、本発明のデータ通信装置における第２経過情報の一例である。
【０１５３】
実施の形態４では、図１９に示す各エントリに対して、登録された時点から上記２つのタイマを同時に開始し、第１消去部２００１または第２消去部２００２のタイマが満了した場合に、それぞれ対応する第１プロトコル配送不可フラグ２１０１または第２プロトコル配送不可フラグ２１０２に配送不可を示す値が設定される。結果、両方とも配送不可になった場合は、第１消去部２００１または第２消去部２００２は、該当するエントリを消去する。
【０１５４】
パケット受信時の処理において、実施の形態１〜３と異なる部分について記載する。
引渡し先判定部３０５では、入力されたパケットのＳＯＵＲＣＥ ＡＤＤＲＥＳＳ（３４１１）、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ（３４１２）およびＩＤ（３４０５）の情報の組み合わせと一致する情報の組を有するエントリを検索し特定する。特定したエントリの宛先ポート番号１６０７から読み出した宛先ポート番号と、パケットとを、引渡し部３０６へ出力する。
【０１５５】
このとき、第１プロトコル配送不可フラグ２１０１または、第２プロトコル配送不可フラグ２１０２の値も併せて、引渡し部３０６に出力する。
【０１５６】
引渡し部３０６では、宛先ポート番号に該当する通信プロトコル部への通信パスにパケットの振り分けを行なう。
【０１５７】
具体的には、第１プロトコル配送不可フラグ２１０１の値が配送不可になっており、かつ、振り分けるべき通信パスが通信パスＢ、つまりパケットの宛先が第１通信プロトコル部１０２である場合、そのパケットは廃棄する。同様に、第２プロトコル配送不可フラグ２１０２の値が配送不可になっており、かつ、振り分けるべき通信パスが通信パスＤ、つまりパケットの宛先が第２通信プロトコル部１２２である場合、そのパケットは廃棄する。
【０１５８】
このように、実施の形態４によれば、先頭パケットが到着した時点で既にタイムアウトが発生している通信プロトコル部へは、ＩＰフラグメントパケットを引き渡さない。したがって、無駄なコピー処理と通信処理を行わず、処理負荷を低減することができる。
【０１５９】
＜実施の形態５＞
本発明の実施の形態５として、第１通信プロトコル部１０２のタイマ値を自動的に測定するための形態を説明する。
【０１６０】
本発明の実施の形態５について、図２０を用いて説明する。
図２０は、実施の形態５におけるフラグメント制御部１１０およびＩＣＭＰ監視部１１２の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０１６１】
図２０に示すように、実施の形態５におけるフラグメント制御部１１０およびＩＣＭＰ監視部１１２は、実施の形態３におけるフラグメント制御部１１０にＴＭＯ測定開始部２２０１が追加され、ＩＣＭＰ監視部１１２にＴＭＯパケット判定部３１１とＴＭＯ測定完了部２２０２とが追加された構成となっている。
【０１６２】
ＡＶデータ送信装置１０およびＡＶデータ受信装置１３の高速伝送用装置１２がＴＭＯ測定開始部２２０１とＴＭＯ測定完了部２２０２を備えることにより、ＡＶデータ送信装置１０においてはホスト装置１１の、ＡＶデータ受信装置１３においてはホスト装置１１のタイマ値の測定が可能となる。
【０１６３】
ＴＭＯ測定開始部２２０１と、ＴＭＯ測定完了部２２０２の動作について説明する。なお、ＴＭＯ測定開始部２２０１は、本発明のデータ通信装置におけるダミーパケット出力手段の一例である。また、ＴＭＯ測定開始部２２０１とＴＭＯ測定完了部２２０２とにより、本発明のデータ通信装置におけるタイムアウト計測手段は実現される。
【０１６４】
まず、ＴＭＯ測定開始部２２０１は、ダミーの先頭フラグメントパケットを作成し、通信パスＢへ送信する。つまり第１通信プロトコル部１０２に対して送信する。
【０１６５】
この時、ＴＭＯ測定開始部２２０１は、内部でタイマを起動する。その後、任意の時間が経過すると、先頭フラグメントのみを受け取った第１通信プロトコル部１０２は、フラグメントの再構築に失敗するので、ＩＰの規格に従い、フラグメントタイムアウト用のＩＣＭＰエラーメッセージ（ＴｉｍｅＥｘｃｅｅｄｅｄ ｃｏｄｅ＝１）を送信する。ＴＭＯ測定完了部２２０２は、このＩＣＭＰエラーメッセージを通信パスＢを介して、受け取る。
【０１６６】
ＴＭＯ測定完了部２２０２は、フラグメントタイムアウト用のＩＣＭＰエラーメッセージ（ＴｉｍｅＥｘｃｅｅｄｅｄ ｃｏｄｅ＝１）であるかをまずチェックし、フラグメントタイムアウト用のＩＣＭＰエラーメッセージである場合、ＤＡＴＡ３６０５の内容を解析する。実施の形態２の説明で述べたように、その格納されている情報が図５（ａ）に示すＩＰヘッダフォーマットであり、ＤＡＴＡ３４１４内に、図１２（ａ）および図１２（ｂ）に示したＴＣＰヘッダまたはＵＤＰヘッダのフォーマットが格納されていた場合、その、ＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２およびＩＤ３４０５の情報を参照する。これらの情報が、ダミーの先頭フラグメントパケットの情報と一致した場合、ＴＭＯ測定開始部２２０１に対して、測定完了を示す通知を行う。なお、通知の方法は、信号でも、割込みでも、コマンドでもよい。
【０１６７】
ＴＭＯ測定開始部２２０１は、測定完了を示す通知を受け取ると、ダミーの先頭フラグメントパケットを送信した際に起動したタイマを停止する。さらに、ダミーの先頭フラグメントパケットを送信してから測定完了を示す通知を受け取るまでにかかった時間を、第１通信プロトコル部１０２のタイマ値として、タイマ設定部１９０１に渡す。
【０１６８】
実施の形態５によれば、第１通信プロトコル部１０２のタイマ値を、自動的に測定することができる。一般に、高速伝送用装置は、その用途として、さまざまなＡＶネットワーク機器のホスト装置と接続することが求められるが、ホスト装置に一切手を加えることなく、具体的にはホスト装置にタイマ値を高速伝送用装置に通知する機能を追加することなく、ホスト装置のタイマ値を取得して、動作することができる。
【０１６９】
つまり、ホスト装置に、機能を無駄に追加することなく、ホスト装置側のタイマ値を高速伝送用装置が知ることができる。
【０１７０】
＜実施の形態６＞
本発明の実施の形態６として、バッファ３０９の空き容量が少なくなった場合であっても後続パケットを廃棄することなく通信を継続するための形態を説明する。
【０１７１】
本発明の実施の形態６について、図２１および図２２を用いて説明する。
図２１は、実施の形態６におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである
実施の形態６におけるフラグメント制御部１１０は、図２１に示すように、図１０に示す実施の形態１におけるフラグメント制御部１１０の構成にバッファ量監視部２３０１とパケット複製制御部２３０２とが加えられた構成である。
【０１７２】
なお、バッファ量監視部２３０１は、本発明のデータ通信装置における容量検出手段の一例であり、パケット複製制御部２３０２は、本発明のデータ通信装置におけるパケット複製手段の一例である。
【０１７３】
図２２は、実施の形態６における制御情報記憶部３０７に記憶されている制御情報のデータ構成の一例を示す図である。
【０１７４】
この制御情報は、バッファ量監視部２３０１、パケット複製制御部２３０２、および引渡し先判定部２３０３によって使用される情報である。
【０１７５】
各エントリに含まれる強制通信フラグ２４０５には、そのエントリに対応する後続パケットが、先頭パケットの到着を待たずに、第１通信プロトコル部１０２および第２通信プロトコル部１２２へ送信された場合、強制通信を示すフラグ値が登録される。
【０１７６】
強制通信フラグ２４０５の登録および、後続パケットの送信は、バッファ量監視部２３０１、パケット複製制御部２３０２、および引渡し先判定部２３０３によって行なわれる。
【０１７７】
まず、バッファ量監視部２３０１の動作について説明する。
後続パケット判定部３０３により、先頭パケットが未受信であると判定された後続パケットはバッファ量監視部２３０１に渡される。この後続パケットを受けたバッファ量監視部２３０１は、この後続パケットのパケット長を検出し、バッファ３０９の空き容量と比較する。
【０１７８】
このとき“パケット長≦バッファ３０９の空き容量”であれば、後続パケットをバッファ３０９に格納する。また、“パケット長＞バッファ３０９の空き容量”であれば、バッファ３０９に格納することなくパケット複製制御部２３０２に出力する。さらに、制御情報記憶部３０７に登録時刻２４０１、フラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４の各情報を登録する。
【０１７９】
次に、パケット複製制御部２３０２の動作について説明する。
受信した後続パケットをバッファ３０９に格納できないために、パケット複製制御部２３０２は、バッファ量監視部２３０１から受け取った後続パケットを保持し、バッファ３０９に格納されている後続パケットを、格納された順番に取り出す。さらに、取り出した後続パケットを通信プロトコル部の数だけ複製する。つまり、本実施の形態においては１つの後続パケットを２つに複製する。複製した後続パケットを引渡し先判定部２３０３に出力する。さらにこのとき、取り出した後続パケットに対するエントリの強制通信フラグ２４０５に強制通信を示すフラグを設定する。なお、バッファ３０９に格納された順番の判断には、制御情報の登録時刻２４０１が用いられる。
【０１８０】
この処理を“バッファ量監視部２３０１から受信した後続パケットのパケット長≦バッファ３０９の空き容量”が成立するまで行う。その後、受信した後続パケットをバッファ３０９へ格納し、制御情報記憶部３０７に、登録時刻２４０１、フラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４の全ての情報が一致するエントリが無ければ新しいエントリとして登録する。
【０１８１】
次に、引渡し先判定部２３０３の動作について説明する。
パケット複製制御部２３０２から後続パケットを受け取った引渡し先判定部２３０３は、制御情報記憶部３０７から、その後続パケットに対応するエントリ情報を読み出す。このとき強制通信フラグ２４０５に強制通信を示すフラグ値が設定されていれば、受け取った後続パケットと、全ての通信パスに対してその後続パケットを送信する要求とを引渡し部３０６へ出力する。本実施の形態においては、引渡し部３０６は、同一の後続パケットを２つずつ受け取ることになり、その後続パケットを、第１通信プロトコル部１および第２通信プロトコル部２に１つずつ送信する。
【０１８２】
つまり、強制通信フラグ２４０５に強制通信を示すフラグ値が設定されたエントリに対応する後続パケットは、第１通信プロトコル部１および第２通信プロトコル部２へ送信されることとなる。
【０１８３】
また、先頭パケット判定部３０２、後続パケット判定部３０３からフラグメントパケットを受け取った場合の引渡し先判定部３０５は、前述した実施の形態１〜５の手順に従って動作する。
【０１８４】
このように、実施の形態６によれば、複数のフラグメントされたＩＰフラグメントパケットを受信し、かつ、それぞれのＩＰフラグメントパケットの先頭パケットを受信しない状態が続く場合など、バッファ３０９の空き容量が少なくなった場合であっても、後続パケットを破棄することなく通信を継続することができる。また各通信プロトコル部に最低限のバッファを使用するだけで通信を継続することが可能となる。
【０１８５】
なお、本実施の形態で示した、パケット複製制御部２３０２が行う制御情報記憶部３０７への登録時刻２４０１、フラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４の登録処理を先頭パケット判定部で行っても良い。また、前述したエントリの登録時刻２４０１は、登録した順番が分かるものであれば、例えばシーケンス番号でも良い。
【０１８６】
＜実施の形態７＞
本発明の実施の形態７として、バッファ３０９の空き容量が少なくなった場合に、強制通信の対象となった後続パケットに対応する後続パケットを、バッファ３０９から読み出して優先的に通信プロトコル部へ送信するための形態について説明する。
【０１８７】
本発明の実施の形態７について、図２３を用いて説明する。
図２３は、実施の形態７におけるパケット複製制御部２３０２の動作の流れを示すフローチャートである。
【０１８８】
なお、実施の形態７におけるフラグメント制御部１１０の機能ブロックの構成および制御情報のデータ構成は、実施の形態６と同じであり、それぞれ図２１および図２２に示したものである。
【０１８９】
実施の形態７におけるパケット複製制御部２３０２は、バッファ３０９から後続パケットを取り出す際に強制通信フラグ２４０５に設定された値を参照し、取り出す後続パケットを選択することを特徴とする。
【０１９０】
なお、バッファ３０９から後続パケットを取り出す際の選択方法以外は、実施の形態６と同様の動作であるため、その差分を中心に説明する。
【０１９１】
まず、実施の形態６で示すように、受信した後続パケットがバッファ３０９に格納できない場合は、バッファ量監視部２３０１からパケット複製制御部２３０２へ後続パケットが渡される。
【０１９２】
次に、パケット複製制御部２３０２は制御情報記憶部３０７に登録されているエントリで強制通信フラグ２４０５に強制通信を示すフラグ値が設定されているものがあるかを検索する。
【０１９３】
強制通信を示すフラグ値が設定されたエントリがあれば（Ｓ２５０１でＹｅｓ）、そのエントリに対応する後続パケット、つまりエントリに含まれるフラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４の情報が一致する後続パケットを検索する（Ｓ２５０６）。
【０１９４】
一致する後続パケットがある場合（Ｓ２５０７でＹｅｓ）、その後続パケットをバッファ３０９から取り出し、引渡し先判定部へ出力する（Ｓ２５０８）。この処理を“バッファ量監視部２３０１から受信した後続パケットのパケット長≦バッファ３０９の空き容量”が成立するまで行う（Ｓ２５０９でＮｏ）、バッファ３０９の空き容量が上記条件を満たすまでになった場合（Ｓ２５０９でＹｅｓ）、受信した後続パケットをバッファ３０９へ格納する。さらに、制御情報記憶部３０７に登録時刻２４０１、フラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４を登録する。
【０１９５】
実施の形態７では、強制通信を示すフラグ値が設定されたエントリが無い場合（Ｓ２５０１でＮｏ）、または、強制通信を示すフラグが設定されたエントリはあるが、そのエントリに対応する後続パケットが無い場合（Ｓ２５０７でＮｏ）は、制御情報記憶部３０７に登録されたエントリの中から最も古い登録時刻をもつエントリ（以下、「最古のエントリ」という。）を検索する（２５０２）。パケット複製制御部２３０２は、最古のエントリを検出すると、最古のエントリの強制通信フラグ（２４０５）に強制通信を示すフラグ値を設定する。以降の動作は実施の形態６に従うものとする。
【０１９６】
このように、実施の形態７によれば、各通信プロトコル部に対し、強制通信を示すフラグ値が設定されたエントリに対応する後続パケットを優先的に送信することが可能である。つまり、実施の形態６と同様に、後続パケットを破棄することなく、かつ、バッファを効率よく使用することが可能となる。さらに、各通信プロトコル部は複数のフラグメントされたＩＰフラグメントパケットを受信処理している状態であっても、優先的に送られるフラグメントパケットの再構築処理のみを行うだけでよく、再構築処理にかかるオーバーヘッドを抑制できる。
【０１９７】
＜実施の形態８＞
本発明の実施の形態８として、バッファ３０９の空き容量が少なくなった場合に、より多くのバッファ３０９の空き容量を確保するための形態について説明する。
【０１９８】
本発明の実施の形態８について、図２４を用いて説明する。
図２４は、実施の形態８におけるパケット複製制御部２３０２の動作の流れを示すフローチャートである。
【０１９９】
なお、実施の形態８におけるフラグメント制御部１１０の機能ブロックの構成および制御情報のデータ構成は、実施の形態６および７と同じであり、それぞれ図２１および図２２に示したものである。
【０２００】
実施の形態８におけるパケット複製制御部２３０２は、図２４に示すように、バッファ３０９から後続パケットを取り出す際に、後続パケットのサイズを考慮して取り出す後続パケットを選択することを特徴とする。
【０２０１】
なお、実施の形態８では、バッファ３０９から後続パケットを取り出す際の選択方法以外は、実施の形態７と同様の動作であるため、その差分のみを説明する。
【０２０２】
本実施の形態では、実施の形態７において制御情報記憶部３０７に登録されているエントリの強制通信フラグ２４０５に強制通信を示すフラグ値が設定されているものが無い場合（Ｓ２５０１でＮｏ）のバッファ３０９の有効な使用方法を示す。
【０２０３】
この場合、制御情報記憶部３０７に登録されているエントリの中で、バッファ３０９に格納されている後続パケットの合計サイズが、最も大きなエントリを選択する（Ｓ２６０１）。
【０２０４】
つまり、実施の形態７では、バッファ３０９に格納されている後続パケットのうち、最古のエントリに対応する後続パケットを強制通信の対象とするのに対し、実施の形態８では、合計サイズが最大となるエントリに対応する後続パケットを強制通信の対象としている。
【０２０５】
このように、実施の形態８によれば、バッファ３０９の空き容量が少なくなった際、フラグメント制御部１１０内のバッファ３０９から一度に大量の後続パケットを取り出し、各通信プロトコル部へ送信することが可能となる。その結果、バッファ３０９からより多くの空き容量を確保することが可能となり、より多くの後続パケットを格納することが可能となる。つまり、実施の形態７よりもバッファを効率よく使用することができる。
【０２０６】
なお、フラグメント制御部１１０は、実施の形態７の特徴と実施の形態８の特徴とを併せ持ってもよい。例えば、バッファ３０９の空き容量が少なくなり、かつ、強制通信の対象となった後続パケットがない場合、まず、合計サイズが最大となるエントリを検索する。この検索の結果、同一のサイズとなるエントリが複数あった場合、最古のエントリを選択し、そのエントリに対応する後続パケットを強制通信の対象としてもよい。
【０２０７】
こうすることで、さらに、バッファ３０９の使用における効率化を向上させることが可能となる。
【０２０８】
＜実施の形態９＞
本発明の実施の形態９として、各通信プロトコル部のパケットの再構築処理に係る負担を軽減させるための形態を説明する。
【０２０９】
本発明の実施の形態９について、図２５を用いて説明する。
図２５は、実施の形態９におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０２１０】
図２５に示すように、実施の形態９におけるフラグメント制御部１１０は、図１０に示す実施の形態１におけるフラグメント制御部１１０の構成に順序制御部２７０１が加えられた構成である。順序制御部２７０１は、本発明のデータ通信装置における整列手段の一例である。
【０２１１】
実施の形態９では、先頭パケット判定部３０２から引渡し先判定部３０５へＩＰフラグメントパケットを送信するときの方法以外は、実施の形態１と同様の動作である。そのため、実施の形態１との差分を中心に説明する。
【０２１２】
実施の形態１に示す先頭パケット判定部３０２では、入力された受信パケットが先頭パケットであるかどうかを判断し、先頭パケットだった場合、制御情報記憶部３０７の情報を参照し、その先頭パケットに対応する後続パケットがバッファ３０９に格納されているかを確認する。該当する後続パケットがある場合には受信した先頭パケットと、該当する後続パケットを引渡し先判定部３０５へ送信するという動作を行う。
【０２１３】
しかし、このとき引渡し先判定部３０５に送信される先頭パケットおよび後続パケットは、フラグメント再構築に適した順番となる保証は無く各通信プロトコル部は順不同で受け取るフラグメントパケットを再構築しなければならない。
【０２１４】
そこで、図２５に示す順序制御部２７０１では、先頭パケット判定部３０２から受け取った先頭パケットおよび後続パケットを、ＩＰフラグメントパケットの並び順を示すＯＦＦＳＥＴ３４０７の値で昇順に整列し、引渡し先判定部へ通信する。
このように、実施の形態９によれば、フラグメント制御部１１０がフラグメントパケットを順不同で受信した場合でも、先頭パケットを含む受信済みの全ての後続パケットを正しく並べ替えたうえで、各通信プロトコル部に送信することが可能となる。これにより、各通信プロトコル部におけるパケットの再構築処理に係る負担を軽減することが出来る。
【０２１５】
＜実施の形態１０＞
本発明の実施の形態１０として、ＩＣＭＰエラーパケットの処理に係る負担を低減することのできる形態について説明する。
【０２１６】
本発明の実施の形態１０について、図２６〜図２８を用いて説明する。
図２６は、実施の形態１０におけるＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０２１７】
図２６に示すように、実施の形態１０のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、図１に示した従来のＡＶデータ送信装置１０およびＡＶデータ受信装置１３と比較すると、パケット振り分け部１２４内に、ＩＣＭＰ制御部５１０を持つことを特徴とする。ＩＣＭＰ制御部５１０は、受信したＩＣＭＰエラーメッセージパケットを効率的に処理する処理部である。
【０２１８】
図２７は、実施の形態１０におけるＩＣＭＰ制御部５１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、ＩＣＭＰ制御部５１０の機能以外の機能を表す機能ブロックである。
【０２１９】
ＩＣＭＰ制御部５１０は、図１６に示したパケットフォーマットのＩＣＭＰエラーメッセージパケットを受信する。
【０２２０】
図１６に示す、ＩＣＭＰエラーメッセージパケットのＤＡＴＡ３６０５には、エラーの発生したパケットにおけるＩＰヘッダとＩＰヘッダに続くデータの先頭６４ビットが格納される。したがって、エラーの発生したパケットがＴＣＰパケットまたはＵＤＰパケットであった場合、図１２（ａ）に示すＴＣＰヘッダにおける送信元ポート番号３５０１および宛先ポート番号３５０２、または、図１２（ａ）に示すＵＤＰヘッダにおける送信元ポート番号３５１３および宛先ポート番号３５１４が含まれる。
【０２２１】
ＩＣＭＰ制御部５１０は、このＩＣＭＰエラーメッセージパケットのＤＡＴＡ３６０５に格納されている情報を利用して、ＩＣＭＰエラーメッセージパケットを適切な出力先に出力することができる。
【０２２２】
なお、常に、ＤＡＴＡ３６０５にエラーパケットの情報が格納されているのではなく、ＩＣＭＰエラーメッセージパケットに含まれるエラーメッセージの種類を示す情報によりエラーパケットの情報が格納されているか否かを判定することができる。
【０２２３】
図２８は、ＩＣＭＰエラーメッセージパケットのＤＡＴＡ３６０５にエラーパケットの情報が格納される場合の代表的なＩＣＭＰエラーメッセージの種類を示す図である。
【０２２４】
図２８に示す“タイプ”および“コード”は、図１６に示すフォーマットのタイプ３６０１およびコード３６０２のそれぞれに格納されている。
【０２２５】
なお、エラーメッセージ以外のメッセージを通知するためのＩＣＭＰパケットも図１６に示すパケットフォーマットと同じフォーマットである。ＩＣＭＰパケットがＩＣＭＰエラーメッセージパケットであるか否かは、そのＩＣＭＰパケットのタイプ３６０１に格納されている値により判定可能である。
【０２２６】
図２８に示すタイプ“３”、“１１”、および“１２”は、ＩＣＭＰパケットがＩＣＭＰエラーメッセージパケットであると判定されるタイプの例である。この判定は、ＩＣＭＰ判定部６０１により行われる。
【０２２７】
さらに、コード３６０２に格納されている値により、ＤＡＴＡ３６０５にエラーパケットの情報が格納されているか否かの判断が可能である。
【０２２８】
図２８に示す“０”から“１５”までのコードは、ＤＡＴＡ３６０５にエラーパケットの情報が格納されていると判定されるコードの例である。この判定は、エラーパケット判定部６０２により行われる。
【０２２９】
ＩＣＭＰ制御部５１０の動作について説明する。
まず、送受信部１２３がネットワークからパケットを受信すると、ＩＣＭＰ判定部６０１へ受信パケットが入力される。
【０２３０】
ＩＣＭＰ判定部６０１は、ＩＣＭＰパケットであるか否かを判定する。判定の結果、ＩＣＭＰパケットでない場合、パケット振り分け部１２４ａへと受信パケットを出力する。出力されたパケットは、パケット振り分け部１２４ａの処理により適切な通信パスへと振り分けられる。また、判定の結果、ＩＣＭＰパケットであった場合、エラーパケット判定部６０２へ出力する。
【０２３１】
エラーパケット判定部６０２は、入力されたＩＣＭＰパケットのタイプ３６０１からＩＣＭＰパケットがＩＣＭＰエラーメッセージパケットであるか否かを判定する。判定の結果、ＩＣＭＰエラーメッセージパケットでなかった場合、パケット複製部６０５に出力する。また、判定の結果、エラーパケットであった場合、入力されたＩＣＭＰパケットのコード３６０２からＤＡＴＡ３６０５にエラーパケット情報が格納されているか否かを判定する。
【０２３２】
上述のように、図２８に示すタイプおよびコードは、ＩＣＭＰパケットがＩＣＭＰエラーメッセージパケットであり、かつ、ＤＡＴＡ３６０５にエラーパケット情報が格納されていることを示すタイプおよびコードの例である。
【０２３３】
ＤＡＴＡ３６０５にエラーパケット情報が格納されていない場合、パケット複製部６０５に出力する。ＤＡＴＡ３６０５にエラーパケット情報が格納されている場合、ＴＣＰヘッダまたはＵＤＰヘッダが格納されているかを判定する。さらに、ＴＣＰヘッダまたはＵＤＰヘッダに含まれるパケットの送信元ポート番号と第２通信プロトコル部１２２が使用しているポート番号とを照合する。
【０２３４】
照合の結果、一致した場合、このＩＣＭＰエラーメッセージパケットの出力先は第２通信プロトコル部１２２であると判定する。また、照合の結果、一致しなかった場合、このＩＣＭＰエラーメッセージパケットの出力先は第１通信プロトコル部１０２であると判定する。
【０２３５】
なお、第２通信プロトコル部１２２が使用しているポート番号の情報は、パケット振り分け部１２４の所定の記憶領域に保持されている。
【０２３６】
そして、ＩＣＭＰエラーメッセージパケットと、その出力先を示す情報とを引渡し部６０４へ出力する。
【０２３７】
引渡し部６０４は、入力されたＩＣＭＰエラーメッセージパケットを、入力された出力先を示す情報に従って、出力すべき通信パスへ振り分ける。
【０２３８】
なお、パケット複製部６０５は、入力されたＩＣＭＰパケットを複製し、第１通信プロトコル部１０２および第２通信プロトコル部１２２の双方へ出力する指示とともに、２つのＩＣＭＰパケットを引渡し部６０４へ出力する。
【０２３９】
引渡し部６０４は、入力された２つのＩＣＭＰパケットを入力された指示に従って、通信パスＢおよび通信パスＣへ出力する。
【０２４０】
このように、エラーパケット判定部６０２と引渡し部６０４とにより、本発明のデータ通信装置におけるエラー出力手段が実現される。また、パケット複製部６０５と引渡し部６０４とにより、本発明のデータ通信装置におけるエラー複製手段が実現される。
【０２４１】
実施の形態１０によれば、従来のＩＣＭＰ複製部で行っていたパケットの複製を、複製が必要なＩＣＭＰエラーメッセージパケットのみに行うことが可能となる。
【０２４２】
これにより、パケットの複製処理にともなう負荷を低減することができる。さらに、従来では、第１通信プロトコル部１０２でのデータ通信にエラーが多発した際、ＩＣＭＰエラーメッセージパケットは、第２通信プロトコル部１２２にも出力されることとなる。つまり、第２通信プロトコル部１２２では無関係のエラーパケットを処理しなければならず、第２通信プロトコル部１２２を使ったデータ通信の転送レートを劣化させる影響を及ぼしていた。
【０２４３】
本実施の形態によれば、第１通信プロトコル部１０２宛のＩＣＭＰエラーメッセージパケットによる第２通信プロトコル部１２２への影響を最低限のものにすることができる。
【０２４４】
＜実施の形態１１＞
本発明の実施の形態１１は、第１通信プロトコル部１０２を使用するアプリケーションプログラムのポート番号と、第２通信プロトコル部１２２を使用するアプリケーションプログラムのポート番号との排他制御に関する形態について説明する。
【０２４５】
本発明の実施の形態１１について、図２９および図３０を用いて説明する。
図２９は、実施の形態１１におけるＡＶデータ送信装置１０とＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０２４６】
図２９に示すように、ＡＶデータ受信装置１３のホスト装置１４にポート予約制御部８０１を持つことを特徴とする。
【０２４７】
ポート予約制御部８０１は、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号を第１通信プロトコル部に登録する処理部である。
【０２４８】
図３０は、実施の形態１１におけるポート予約制御部８０１の機能的な構成を示す機能ブロック図である。図３０を用いてポート予約制御部８０１の構成および動作について説明する。ポート番号確定部９０３は、ＡＶデータの伝送を行うクライアントアプリケーションプログラムであるＡＶ伝送クライアントＡＰＰ１０７からの接続要求を受け取る。接続要求を受け取ると、ポート番号（Ｘ）を確定する。ポート番号（Ｘ）はＯＳから提供されるサービスコールの時間管理機能（ＧＥＴ＿ＴＩＭ）で取得した値を使用してランダムに確定する。なお、ポート番号確定部９０３は本発明のデータ通信装置におけるポート番号決定手段の一例である。
【０２４９】
このポート番号（Ｘ）は０〜６５５３５の範囲の未使用ポート番号の中からランダムに確定される。ポート番号確定部９０３は、その確定したポート番号（Ｘ）をポート番号登録部９０２へ出力する。
【０２５０】
なお、このポート番号（Ｘ）はランダム関数で確定してもよい。また、未使用のポート番号を順に検索して使用してもよい。
【０２５１】
一般的なことであるが、ポート番号（Ｘ）の登録はソケットが提供するＡＰＩを使用して行なう。使用するＡＰＩは、ＳＯＣＫＥＴ、ＢＩＮＤ、ＣＯＮＮＥＣＴ、およびＣＬＯＳＥＳＯＣＫＥＴである。ＳＯＣＫＥＴはソケットを生成、ＢＩＮＤはソケットのポート番号や通信方式を登録、ＣＯＮＮＥＣＴはサーバに接続要求を行って通信回線を確立、ＣＬＯＳＥＳＯＣＫＥＴは通信回線を切断してソケットを閉じる役割を持つ。
【０２５２】
ポート番号登録部９０２はＳＯＣＫＥＴを使用し、第１Ｉ／Ｆ部１０１とのソケットを生成する。次に、ＢＩＮＤを使用し、確定したポート番号（Ｘ）を第１Ｉ／Ｆ部１０１へ登録する。
【０２５３】
第１Ｉ／Ｆ部においてポート番号（Ｘ）が使用中である場合、第１Ｉ／Ｆ部１０１はポート番号登録部９０２に登録失敗を示す情報を返す。ポート番号登録部９０２はＡＶ伝送クライアントＡＰＰ１０７へ接続エラー通知を行う。
【０２５４】
第１Ｉ／Ｆ部においてポート番号（Ｘ）が未使用の場合、第１Ｉ／Ｆ部１０１はポート番号登録部９０２に登録成功を示す情報を返す。ポート番号登録部９０２は第２Ｉ／Ｆ部１２１に対してＳＯＣＫＥＴおよびＣＯＮＮＥＣＴを使用し、ポート番号（Ｘ）を使用して接続要求を行う。
【０２５５】
また、第２Ｉ／Ｆ部１２１から切断通知を受けると、ポート番号削除部９０１はＣＬＯＳＥＳＯＣＫＥＴを使用して、第１Ｉ／Ｆ部１０１から使用ポート番号（Ｘ）を削除する。その後、ポート番号削除部９０１はＡＶ伝送クライアントＡＰＰ１０７に対して切断通知を行う。
【０２５６】
このように、実施の形態１１によれば、第１Ｉ／Ｆ部１０１へ使用ポート番号（Ｘ）を登録することで、第１Ｉ／Ｆ部１０１を改変せずに、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号と、第１Ｉ／Ｆ部１０１を使用するクライアントＡＰＰ１０８等のポート番号との排他制御が可能となる。
【０２５７】
なお、本実施の形態はＡＶ伝送サーバＡＰＰ１０４がウェルノウンポート以外（１０２４〜６５５３５）で通信する場合にも適用できる。
【０２５８】
＜実施の形態１２＞
本発明の実施の形態１２として第１通信プロトコル部に対するポート番号の予約を確実に行なうための形態について説明する。
【０２５９】
本発明の実施の形態１２について、図３１を用いて説明する。
図３１は、実施の形態１２におけるポート予約制御部８０１の機能的な構成を示す機能ブロック図である。
【０２６０】
図３１に示すように、実施の形態１２におけるポート予約制御部８０１は、図３０に示した実施の形態１２におけるポート予約制御部８０１が有する構成に加え、繰り返し要求部２８０３を有することを特徴とする。繰り返し要求部２８０３は、本発明のデータ通信装置における繰り返し制御手段の一例であり、第１Ｉ／Ｆ部１０１に対して、ポート番号の登録の要求を繰り返し行なう処理部である。
【０２６１】
実施の形態１２では、ポート番号登録部２８０１とポート番号確定部２８０２と繰り返し要求部２８０３の動作以外は、実施の形態１１と同様の動作であるため、その差分のみを説明する。
【０２６２】
ポート番号登録部２８０１は第１Ｉ／Ｆ部１０１へのポート番号（Ｘ）の登録に失敗した場合、繰り返し要求部２８０３に対して接続エラー通知を行う。
【０２６３】
繰り返し要求部２８０３はポート番号登録部２８０１から接続エラー通知を受けると、ポート番号確定部２８０２に新たなポート番号の登録要求を行う。繰り返し要求部２８０３は繰り返し回数（Ｎ回）の制限機能を備え、ポート番号の登録に失敗し続けた場合に要求を無限に繰り返さないようにする。
【０２６４】
繰り返し要求部２８０３は、接続エラー通知を受けた回数が繰り返し回数（Ｎ回）未満の場合、繰り返し要求部２８０３はポート番号確定部２８０２へ新たなポート番号の登録の要求を行う。接続エラー通知を受けた回数が繰り返し回数（Ｎ回）に達した場合、繰り返し要求部２８０３はＡＶ伝送クライアントＡＰＰ１０７にエラー通知を行う。
【０２６５】
このように、実施の形態１２によれば、ポート予約制御部８０１に繰り返し要求部２８０３を設けることで第１Ｉ／Ｆ部１０１へのポート番号の登録を繰り返し行うことができる。したがって、ポート番号確定部２８０２が、第１Ｉ／Ｆ部１０１においてすでに使用されていたポート番号を選択してしまった場合でも、異なるポート番号に変えて再登録を繰り返す。そのため、偶発的に発生するポート番号の衝突により、ポート番号の予約が失敗に終わることを回避することができ、実質的に、第１Ｉ／Ｆ部１０１に対するポート番号の予約を確実なものにすることができる。
【０２６６】
尚、本実施の形態で示した、繰り返し要求部（２８０３）の繰り返し制限は期間（例えば、Ｍ秒間）で行ってもよい。また、ＡＶ伝送クライアントＡＰＰ１０７が接続要求を行なうとともに回数または期間を指定する構成でもよい。
【０２６７】
尚、本実実施の形態はＡＶ伝送サーバＡＰＰ１０４がウェルノウンポート以外（１０２４〜６５５３５）で通信する場合にも使用できる。
【０２６８】
＜実施の形態１３＞
本発明の実施の形態１３として、通信先の機器の物理アドレスの解決を効率的に行なうことができる形態について説明する。
【０２６９】
本発明の実施の形態１３について、図３２〜図３５を用いて説明する。
図３２は、実施の形態１３のＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０２７０】
図３２に示すように、実施の形態１３のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、高速伝送用装置１２の送受信部１２３にＡＲＰ監視制御部１００１を持つことを特徴とする。
【０２７１】
ＡＲＰ監視制御部１００１は、通信先の機器の物理アドレスの解決を要求およびその応答であるＡＲＰ要求パケットおよびＡＲＰ応答パケットの送受信を監視し、ＡＲＰ応答パケット受信した場合に適切な出力先に出力する処理部である。
【０２７２】
図３３は、実施の形態１３におけるＡＲＰ監視制御部１００１の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、ＡＲＰ監視制御部１００１の機能以外の機能を表す機能ブロックである。
【０２７３】
なお、ＡＲＰ要求パケット判定部１２０１は、本発明のデータ通信装置におけるＡＲＰ要求受付手段の一例であり、ＡＲＰ応答パケット判定部１２０４は、本発明のデータ通信装置におけるＡＲＰ応答受信手段とであり、引渡し部１２０６は、本発明のデータ通信装置における応答出力手段の一例である。
【０２７４】
ＡＲＰ監視制御部１００１は、通信パスＢまたは通信パスＤにより直接接続されている第１通信プロトコル部１０２または第２通信プロトコル部１２２からＡＲＰ要求パケットを受け取ると、そのＡＲＰ要求パケットに関する情報をＡＲＰ情報記憶部１２０３に記憶する。
【０２７５】
図３４は、実施の形態１３におけるＡＲＰ情報記憶部１２０３に記憶されたＡＲＰ情報のデータ構成例を示す図である。
【０２７６】
図３４に示すように、ＡＲＰ情報記憶部１２０３には、ＡＲＰ監視制御部１００１が受け取ったＡＲＰ要求パケットごとに、そのＡＲＰ要求パケットに関する情報が１つのエントリとして記憶されている。
【０２７７】
各エントリの通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２は、ＡＲＰ監視制御部１００１がＡＲＰ要求パケットを受け取った際、どちらの通信プロトコル部から送られてきたかを示す情報である。例えば、通信パスＢ要求ビット１３０１が立っている、つまり、通信パスＢ要求ビット１３０１が“１”である場合、そのエントリに対応するＡＲＰ要求パケットは、通信パスＢから送られてきたことを示す。ＡＲＰ要求パケットが通信パスＢから送られてきたということは、そのＡＲＰ要求パケットは第１通信プロトコル部１０２から送られてきたことを意味する。
【０２７８】
同様に、通信パスＤ要求ビット１３０２が“１”である場合は、そのＡＲＰ要求パケットは第２通信プロトコル部１２２から送られてきたことを意味する。通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２は、どちらか一方のみが“１”に設定される。
【０２７９】
ターゲットＩＰアドレス１３０３は、ＡＲＰ要求パケットの宛先のＩＰアドレスを示す情報である。ターゲットＩＰアドレス１３０３の後ろの“（１）”等はエントリ番号に対応している。ターゲットＩＰアドレスは、ＡＲＰ要求パケットに含まれる情報である。
【０２８０】
図３５は、ＡＲＰパケットのパケットフォーマットを示す図である。ＡＲＰ要求パケットおよびＡＲＰ応答パケットのパケットフォーマットは、図３５に示すパケットフォーマットである。
【０２８１】
図３５に示す探索ＩＰアドレス３７１２が、ＡＲＰパケットの宛先のＩＰアドレスである。つまり、図３４に示すＡＲＰ情報のエントリのターゲットＩＰアドレス１３０３には、ＡＲＰ要求パケットに含まれる探索ＩＰアドレス３７１２が格納される。
【０２８２】
ＡＲＰ監視制御部１００１の動作について説明する。
ＡＲＰ監視制御部１００１は通信パスＢまたは通信パスＤから送信パケットを受けると、ＡＲＰ要求パケット判定部１２０１へ送信パケットを入力する。ＡＲＰ要求パケット判定部１２０１では、送信パケットがＡＲＰ要求パケットかどうかを判定する。なお、ＡＲＰ要求パケットであるかどうかの判定方法は、一般的なＩＰプロトコルの仕様であるため記載は省略する。
【０２８３】
ＡＲＰ要求パケットでない場合、送受信部１２３へ送信パケットを出力する。ＡＲＰ要求パケットである場合、要求元判定部１２０２へ送信パケットを出力する。
【０２８４】
要求元判定部１２０２はＡＲＰ要求パケットの探索ＩＰアドレス３７１２を読み出し、ＡＲＰ要求パケットの送信元（以下、「ＡＲＰ要求元」という。）を判定する。判定後、ＡＲＰ情報記憶部１２０３へのエントリの登録を行なう。そのエントリのターゲットＩＰアドレス１３０３には探索ＩＰアドレス３７１２が記録され、通信パス要求ビットが設定される。
【０２８５】
具体的には、要求元判定部１２０２は、ＡＲＰ要求元が第１通信プロトコル部１０２の場合は通信パスＢ要求ビット１３０１を“１”に設定し、第２通信プロトコル部１２２の場合は通信パスＤ要求ビット１３０２を“１”に設定する。
【０２８６】
ＡＲＰ情報記憶部１２０３へのエントリの登録後、要求元判定部１２０２は送受信部１２３へＡＲＰ要求パケットである送信パケットを出力する。
【０２８７】
その後、ＡＲＰ監視制御部１００１は、ネットワークを介して送信され、送受信部１２３により受信された受信パケットを受け取る。受け取られた受信パケットはＡＲＰ応答パケット判定部１２０４へ入力される。ＡＲＰ応答パケット判定部１２０４は、受信パケットがＡＲＰ応答パケットであるか否かを判定する。なお、ＡＲＰ応答パケットであるかどうかの判定方法は、一般的なＩＰプロトコルの仕様であるため記載は省略する。受信パケットがＡＲＰ応答パケットでない場合、パケット振り分け部１２４ａへ受信パケットを出力する。受信パケットがＡＲＰ応答パケットである場合、応答出力先判定部１２０５へ受信パケットを出力する。
【０２８８】
応答出力先判定部１２０５では、ＡＲＰ応答パケットの送信元ＩＰアドレス３７１０とＡＲＰ情報記憶部１２０３に記憶されているターゲットＩＰアドレス１３０３とを比較し、一致しているエントリを探す。一致したエントリの通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２のどちらに“１”が設定されているかによりＡＲＰ応答パケットを出力すべき通信パスを判定する。
【０２８９】
判定後、応答出力先判定部１２０５は引渡し部１２０６に対して、判定した通信パスへＡＲＰ応答パケットを出力するように要求する。
【０２９０】
引渡し部１２０６は、応答出力先判定部１２０５から要求される出力先にＡＲＰ応答パケットを出力する。ＡＲＰ応答パケットは、通信パスＢに出力された場合は第１通信プロトコル部１０２に受け取られ、通信パスＤに出力された場合は第２通信プロトコル部１２２に受け取られる。
【０２９１】
このように、実施の形態１３では、パケット振り分け部１２４の内部にＡＲＰ監視制御部１００１が備えられる。さらに、ＡＲＰ監視制御部１００１が有するＡＲＰ情報記憶部１２０３にＡＲＰ要求パケットの宛先であるターゲットＩＰアドレスを示す情報とＡＲＰ要求元を示す情報とが対応付けられて記憶される。これにより、ＡＲＰ要求パケットに対する応答であるＡＲＰ応答パケットを適切に振り分けることが可能となる。
【０２９２】
結果として、ホスト装置１１およびホスト装置１４への機能の追加を行なうことなく、また、処理の負荷を増加させることなく、効率的に物理アドレスの解決を行なうことができる。さらに、ＡＶ伝送を行うアプリケーションプログラム（ＡＶ伝送サーバＡＰＰ１０４およびＡＶ伝送クライアントＡＰＰ１０７）が第１通信プロトコル部１０２を使用することなく、物理アドレスの解決を行うことができる。
【０２９３】
なお、要求元判定部２９０１が、ＡＲＰ要求元を判定する方法は、上述のＡＲＰ要求パケットのＰＲＯＴＯＣＯＬ３７０７の情報などを利用してもよい。また、例えば、どの通信パスからＡＲＰ要求パケットが送られてきたかの情報を、ＡＲＰ要求パケット判定部１２０１から受け取り、その情報を利用してもよい。
【０２９４】
＜実施の形態１４＞
本発明の実施の形態１４として、通信先の機器の物理アドレスの解決を効率的に行い、かつ、ネットワーク上の負荷を低減すことができる形態について説明する。
【０２９５】
本発明の実施の形態１４について図３６を用いて説明する。
図３６は、実施の形態１４におけるＡＲＰ監視制御部１００１の機能的な構成を示す機能ブロック図である。
【０２９６】
図３６に示すように、実施の形態１４におけるＡＲＰ監視制御部１００１は、図３３に示した実施の形態１３におけるＡＲＰ監視制御部１００１が有する構成に加え、パケット複製部２９０３を有することを特徴とする。なお、要求元判定部２９０１は、本発明のデータ通信装置におけるＡＲＰ要求元判定手段の一例であり、パケット複製部２９０３は、本発明のデータ通信装置におけるＡＲＰパケット複製手段の一例である。
【０２９７】
なお、実施の形態１４におけるＡＲＰ情報記憶部に１２０３記憶されているＡＲＰ情報のデータ構成は、図３４に示したデータ構成と同じである。また、実施の形態１４におけるＡＲＰ監視制御部１００１が扱うＡＲＰパケットのパケットフォーマットは、図３５に示したパケットフォーマットと同じである。
【０２９８】
実施の形態１４では、２つの通信プロトコル部から受け取ったＡＲＰ要求パケットのそれぞれの宛先が同一であった場合の要求元判定部２９０１、応答出力先判定部２９０２およびパケット複製部２９０３の動作以外は、実施の形態１３における各構成部の動作と同様の動作である。そのため、実施の形態１３との差分のみを説明する。
【０２９９】
要求元判定部２９０１は、ＡＲＰ要求パケット判定部１２０１から受け取ったＡＲＰ要求パケットに含まれる探索ＩＰアドレス３７１２が、ターゲットＩＰアドレス１３０３としてＡＲＰ情報記憶部１２０３にすでに登録されているか否かを確認する。登録されていた場合、新たにエントリを追加せず、その探索ＩＰアドレス３７１２がターゲットＩＰアドレス１３０３に記録されているエントリに、ＡＲＰ要求元に対応する通信要求ビットを設定する。つまり、通信パスＢ要求ビット１３０１または通信パスＤ要求ビット１３０２を“１”に設定する。また、ＡＲＰ要求パケットは送信せずに廃棄する。
【０３００】
例えば、第１通信プロトコル部１０２から、ＩＰアドレス“１１１．１１１．１１１．１１１”に対するＡＲＰ要求パケットが送信され、その応答が帰ってくる前に、第２通信プロトコル部１２２から、同じＩＰアドレス“１１１．１１１．１１１．１１１”に対するＡＲＰ要求パケットが送信された場合を想定する。
【０３０１】
この場合、第１通信プロトコル部１０２および第２通信プロトコル部１２２は、ともに同じ機器の物理アドレスの解決を要求している。従って、先に送信されたＡＲＰ要求パケットのみを宛先に送信し、その応答を第１通信プロトコル部１０２だけでなく第２通信プロトコル部１２２にも送信すればよい。
【０３０２】
そこで、先に送信されたＡＲＰ要求パケットに対応するＡＲＰ応答パケットを第２通信プロトコル部１２２にも送信するために、要求元判定部２９０１は、先に送信されたＡＲＰ要求パケットに対応するエントリの通信パスＤ要求ビット１３０２も“１”に設定する。
【０３０３】
ＡＲＰ応答パケットが両方の通信プロトコル部に送信される際の各処理部の動作は以下のようになる。
【０３０４】
応答出力先判定部２９０２は、ＡＲＰ応答パケット判定部１２０４から受け取ったＡＲＰ応答パケットの送信元ＩＰアドレス３７１０とＡＲＰ情報記憶部１２０３に記憶されているターゲットＩＰアドレス１３０３とを比較し、一致しているエントリを探す。一致したエントリの通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２のそれぞれに“１”が設定されているか否かでＡＲＰ要求元を判定する。
【０３０５】
通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２の両方に“１”が設定されている場合、応答出力先判定部２９０２はパケット複製部２９０３にＡＲＰ応答パケットを出力する。
【０３０６】
パケット複製部２９０３はＡＲＰ応答パケットを複製し、引渡し部１２０６に対して通信パスＢおよび通信パスＤへＡＲＰ応答パケットを出力するように要求する。
【０３０７】
引渡し部１２０６は、要求に従い、両方の通信パスにＡＲＰ応答パケットを出力する。その結果、第１通信プロトコル部１０２および第２通信プロトコル部１２２はともにＡＲＰ応答パケットを受け取ることができる。
【０３０８】
このように、実施の形態１４では、実施の形態１３と同じく、パケット振り分け部１２４の内部にＡＲＰ監視制御部１００１が備えられ、ＡＲＰ情報記憶部１２０３にＡＲＰ要求パケットのターゲットＩＰアドレスとＡＲＰ要求元とが対応付けられて１つのエントリとして記憶される。
【０３０９】
しかし、実施の形態１３とは異なり、ＡＲＰ監視制御部１００１は、両方の通信プロトコル部から同じターゲットＩＰアドレスへのＡＲＰ要求パケットを受けた場合、１つのＡＲＰ要求パケットのみを送信する。さらに、そのＡＲＰ要求パケットに対応するエントリに、２つの要求元を示す情報が登録される。その後、そのＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットを受信した場合、両方の通信プロトコル部に出力する。
【０３１０】
結果として、実施の形態１４のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、必要のないＡＲＰ要求パケットの送出処理を行なわず、さらに、そのＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットの受信処理を行う必要がない。つまり、実施の形態１４のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、実施の形態１３の説明で述べた物理アドレスの解決処理の効率化に加え、ネットワーク上の負荷を低減することができるという効果を有する。
【０３１１】
＜実施の形態１５＞
本発明の実施の形態１５として、通信先の機器の物理アドレスの解決を効率的に行い、かつ、ネットワーク上の負荷をさらに低減すことができる形態について説明する。
【０３１２】
本発明の実施の形態１５について、図３７を用いて説明する。
図３７は、実施の形態１５におけるＡＲＰ監視制御部１００１の機能的な構成を示す機能ブロック図である。
【０３１３】
図３７に示すように、実施の形態１５のＡＲＰ監視制御部１００１は、図３６に示した実施の形態１４のＡＲＰ監視制御部１００１が有する構成に加え、テーブル参照部３００１と応答パケット生成部３００２とを有することを特徴とする。応答パケット生成部３００２は、本発明のデータ通信装置におけるＡＲＰ応答生成手段の一例である。
【０３１４】
また、第２通信プロトコル部１２２が有するアドレス解決テーブル３００３は、解決された、通信先の機器の物理アドレスをその機器のＩＰアドレスと対応付けて記録するためのテーブルである。
【０３１５】
また、アドレス解決テーブル３００３は、第２通信プロトコル部１２２の要求により解決された物理アドレスだけでなく、第１通信プロトコル部１０２の要求により解決された物理アドレスも記録されている。
【０３１６】
実施の形態１５におけるＡＲＰ監視制御部１００１の動作は、テーブル参照部３００１、応答パケット生成部３００２、および応答出力先判定部３００４の動作以外は、実施の形態１４における各構成部の動作と同様の動作である。そのため、実施の形態１４との差分のみを説明する。
【０３１７】
ＡＲＰ要求パケット判定部１２０１は送信パケットがＡＲＰ要求パケットである場合、テーブル参照部３００１へ送信パケットを出力する。
【０３１８】
テーブル参照部３００１は、第２通信プロトコル部１２２が備えるアドレス解決テーブル３００３を参照し、このＡＲＰ要求パケットのターゲットＩＰアドレスが記録されているか否かを確認する。該当するターゲットＩＰアドレスが記録されていない場合、要求元判定部２９０１にＡＲＰ要求パケットを出力する。
【０３１９】
該当するターゲットＩＰアドレスが記録されている場合、テーブル参照部３００１は、そのターゲットＩＰアドレスと対応付けられた物理アドレスをアドレス解決テーブル３００３から読み出す。更に、ＡＲＰ要求パケットを廃棄し、応答パケット生成部３００２へ、読み出した物理アドレスを通知するとともに、ＡＲＰ応答パケットの生成を要求する。
【０３２０】
ここで、この廃棄されたＡＲＰ要求パケットの宛先であるターゲットＩＰアドレスがアドレス解決テーブル３００３に記録されているということは、このＡＲＰ要求パケットの送信元は、第２通信プロトコル部１２２ではないことが分かる。つまり、応答パケット生成部３００２により生成されるＡＲＰ応答パケットは、第１通信プロトコル部１０２へ出力されればよい。
【０３２１】
応答パケット生成部３００２は、テーブル参照部３００１から受け取った物理アドレスを用いＡＲＰ応答パケットを生成する。
【０３２２】
生成後、引渡し部１２０６に対して、通信パスＢへＡＲＰ応答パケットの出力要求を行う。引渡し部１２０６はＡＲＰ応答パケットを通信パスＢへ出力する。出力されたＡＲＰ応答パケットは、第１通信プロトコル部１０２に受け取られる。
【０３２３】
このように、すでに解決済みの物理アドレスの解決を要求するＡＲＰ要求パケットは送出されることがない。
【０３２４】
また、解決していない物理アドレス、つまり、アドレス解決テーブル３００３に記録されていないターゲットＩＰアドレスに対応する物理アドレスは、以下の動作によりアドレス解決テーブル３００３に追加される。
【０３２５】
応答出力先判定部３００４は、ＡＲＰ応答パケット判定部１２０４からＡＲＰ応答パケットを受け取る。さらに、そのＡＲＰ応答パケットの送信元ＩＰアドレス３７１０とＡＲＰ情報記憶部１２０３に記憶されているＡＲＰ情報とから、ＡＲＰ応答パケットの出力先の通信パスが通信パスＢであるのか通信パスＤであるのかを判定する。
【０３２６】
判定の結果、出力先が通信パスＢである場合、第２通信プロトコル部１２２が備えるアドレス解決テーブル３００３に、そのＡＲＰ応答パケットの送信元ＩＰアドレス３７１０が記録されていないことを確認する。確認後、アドレス解決テーブル３００３にその送信元ＩＰアドレス３７１０と、ＡＲＰ応答パケットに含まれる物理アドレスとを追加記録する。
【０３２７】
なお、ＡＲＰ応答パケットの出力先の通信パスが通信パスＤである場合は、そのＡＲＰ応答パケットは第２通信プロトコル部１２２に出力される。そのため、第２通信プロトコル部１２２で、アドレス解決テーブル３００３への新たな物理アドレスの追加記録が行なわれる。
【０３２８】
このように、実施の形態１５によれば、ＡＲＰ監視制御部１００１にテーブル参照部３００１を設けることにより、第２通信プロトコル部１２２および第１通信プロトコル部１０２においてすでに物理アドレスが解決されているＩＰアドレスへはＡＲＰ要求パケットを送信しなくてもよい。したがって、冗長なパケットの送出をふせぐことができる。従って、実施の形態１４と比較すると、さらにネットワーク上の負荷を低減することができる。
【０３２９】
＜実施の形態１６＞
上述の本発明の実施の形態１〜１５の説明では、各実施の形態において特徴的な構成部についてのみ説明を行なった。しかしながら、ＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、各実施の形態において特徴的な構成部を複数同時に備えていてもよい。
【０３３０】
図３８は、本発明において特徴的な構成部を複数有するＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０３３１】
図３８に示すＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、実施の形態１におけるＡＶデータ送信装置１０およびＡＶデータ受信装置１３に、実施の形態２におけるＩＣＭＰ監視部１１２と、実施の形態１０におけるＩＣＭＰ制御部５１０と、実施の形態１３におけるＡＲＰ監視制御部１００１とが備えられ、ＡＶデータ受信装置１３には、さらに、実施の形態１１におけるポート予約制御部８０１が備えられている。
【０３３２】
例えば、ＡＶデータ送信装置１０およびＡＶデータ受信装置１３は図３８に示す各構成部を同時に備えていてもよく、各構成部の動作および機能は、他の構成部の動作および機能を妨げるものではない。
【０３３３】
また、図３８において、例えば、実施の形態１３におけるＡＲＰ監視制御部１００１に換えて実施の形態１４におけるＡＲＰ監視制御部１００１が備えられてもよい。また、例えば、ＡＶデータ送信装置１０がポート予約制御部８０１を備えていてもよい。さらに、また、例えば、ＩＣＭＰ監視部１１２は、ＡＶデータ受信装置１３にのみ備えられていてもよい。
【０３３４】
つまり、ＩＣＭＰ制御部５１０等の、本発明の特徴的な構成部は、製造コスト、ユーザのニーズ等に応じ、自由に組み合わせてＡＶデータ送信装置１０およびＡＶデータ受信装置１３に備えてもよい。
【０３３５】
こうすることで、ＡＶデータ送信装置１０およびＡＶデータ受信装置１３の構成上および処理上の無駄の発生をさらに削減することが可能となる。
【産業上の利用可能性】
【０３３６】
本発明のデータ通信装置は、ホスト装置と高速伝送用装置のそれぞれに通信プロトコルを搭載しつつ、構成上および処理上の無駄の発生を削減することができるデータ通信装置を提供することができる。特に、高転送レートのＡＶデータを伝送する装置に有用である。例えば、ＡＶコンテンツをネットワーク伝送する機能を有するＤＶＤレコーダや、ネットワーク伝送でＡＶコンテンツを受信して再生する機能を有するデジタルＴＶ等に応用できる。
【図面の簡単な説明】
【０３３７】
【図１】従来のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図２】図２（ａ）は、ＩＰフラグメントの発生からＩＰフラグメントパケットの再構築までの処理の流れの一例を示す図であり、図２（ｂ）は、ＩＰフラグメントパケットの一例を示す図である。
【図３】フラグメントパケットが再構築できなかった際の処理の概要を示す図である。
【図４】従来のフラグメント再構築部の機能的な構成を示す機能ブロック図である。
【図５】図５（ａ）は、ＩＰヘッダフォーマットを示す図であり、図５（ｂ）は、ＩＰヘッダに含まれるＰＲＯＴＯＣＯＬ領域の値とプロトコル名との対応を示す図であり、図５（ｃ）は、ＩＰヘッダに含まれるＦＬＡＧＳ領域のビットと意味との対応を示す図である。
【図６】従来のＩＣＭＰ複製部の機能的な構成を示す機能ブロック図である。
【図７】アドレス解決プロトコル（ＡＲＰ）による一般的なアドレス解決の仕組みを示す図である。
【図８】特許文献４に開示された、物理アドレスの解決を行なう従来のホストコンピュータの機能的な構成を示す機能ブロック図である。
【図９】実施の形態１のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図１０】実施の形態１におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図１１】実施の形態１における制御情報記憶部に記憶されている制御情報のデータ構成の一例を示す図である。
【図１２】図１２（ａ）は、ＴＣＰヘッダフォーマットを示す図であり、図１２（ｂ）は、ＵＤＰヘッダフォーマットを示す図である。
【図１３】実施の形態１におけるフラグメント制御部の動作の流れを示すフローチャートである。
【図１４】実施の形態２のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図１５】実施の形態２におけるフラグメント制御部およびＩＣＭＰ監視部の機能的な構成を示す機能ロック図である。
【図１６】ＩＣＭＰエラーメッセージのパケットフォーマットを示す図である。
【図１７】実施の形態３におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図１８】実施の形態４におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図１９】実施の形態４における制御情報記憶部に記憶されている制御情報のデータ構成の一例を示す図である。
【図２０】実施の形態５におけるフラグメント制御部およびＩＣＭＰ監視部の機能的な構成を示す機能ブロック図である。
【図２１】実施の形態６におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図２２】実施の形態６における制御情報記憶部に記憶されている制御情報のデータ構成の一例を示す図である。
【図２３】実施の形態７における複製制御部の動作の流れを示すフローチャートである。
【図２４】実施の形態８における複製制御部の動作の流れを示すフローチャートである。
【図２５】実施の形態９におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図２６】実施の形態１０におけるＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図２７】実施の形態１０におけるＩＣＭＰ制御部の機能的な構成を示す機能ブロック図である。
【図２８】ＩＣＭＰエラーメッセージパケットのＤＡＴＡ領域にエラーパケットの情報が格納される場合の代表的なＩＣＭＰエラーメッセージの種類を示す図である。
【図２９】実施の形態１１におけるＡＶデータ送信装置とＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図３０】実施の形態１１におけるポート予約制御部の機能的な構成を示す機能ブロック図である。
【図３１】実施の形態１２におけるポート予約制御部の機能的な構成を示す機能ブロック図である。
【図３２】実施の形態１３のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図３３】実施の形態１３におけるＡＲＰ監視制御部の機能的な構成を示す機能ブロック図である。
【図３４】実施の形態１３におけるＡＲＰ情報記憶部に記憶されたＡＲＰ情報のデータ構成例を示す図である。
【図３５】ＡＲＰパケットのパケットフォーマットを示す図である。
【図３６】実施の形態１４におけるＡＲＰ監視制御部の機能的な構成を示す機能ブロック図である。
【図３７】実施の形態１５におけるＡＲＰ監視制御部の機能的な構成を示す機能ブロック図である。
【図３８】本発明において特徴的な構成部を複数有するＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【符号の説明】
【０３３８】
１０ ＡＶデータ送信装置
１１、１４ ホスト装置
１２ 高速伝送用装置
１３ ＡＶデータ受信装置
１０１ 第１Ｉ／Ｆ部１０１
１０２ 第１通信プロトコル部１０２
１０３ 情報設定部
１０４ ＡＶ伝送サーバＡＰＰ
１０５、１０９ サーバＡＰＰ
１０６、１０８ クライアントＡＰＰ
１０７ ＡＶ伝送クライアントＡＰＰ
１１０ フラグメント制御部
１１２ ＩＣＭＰ監視部
１２１ 第２Ｉ／Ｆ部
１２２ 第２通信プロトコル部
１２３ 送受信部
１２４ パケット振り分け部
３０１ フラグメント判定部
３０２ 先頭パケット判定部
３０３ 後続パケット判定部
３０５、２３０３ 引渡し先判定部
３０６、６０４、１２０６ 引渡し部
３０７ 制御情報記憶部
３０９ バッファ
３１０ 情報消去部
３１１ ＴＭＯパケット判定部
５１０ ＩＣＭＰ制御部
６０１ ＩＣＭＰ判定部
６０２ エラーパケット判定部
６０５、２９０３ パケット複製部
８０１ ポート予約制御部
９０１ ポート番号削除部
９０２ ポート番号登録部
９０３ ポート番号確定部
１００１ ＡＲＰ監視制御部
１２０１ ＡＲＰ要求パケット判定部
１２０２ 要求元判定部
１２０３ ＡＲＰ情報記憶部
１２０４ ＡＲＰ応答パケット判定部
１２０５ 応答出力先判定部
１９０１ タイマ設定部
２００１ 第１消去部
２００２ 第２消去部
２１０１ 第１プロトコル配送不可フラグ
２１０２ 第２プロトコル配送不可フラグ
２２０１ ＴＭＯ測定開始部
２２０２ ＴＭＯ測定完了部
２３０１ バッファ量監視部
２３０２ パケット複製制御部
２７０１ 順序制御部
２８０１ ポート番号登録部
２８０２ ポート番号確定部
２８０３ 繰り返し要求部
２９０１ 要求元判定部
２９０２ 応答出力先判定部
３００１ テーブル参照部
３００２ 応答パケット生成部
３００３ アドレス解決テーブル
３００４ 応答出力先判定部
【技術分野】
【０００１】
本発明は、所定の通信プロトコルに従い、ネットワークを介して他の機器とのデータ通信を行うためのデータ通信装置に関する。
【背景技術】
【０００２】
近年、Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ（ＤＬＮＡ）に従ったホームネットワークの構築が活発化してきており、ＤＬＮＡに対応するＡＶネットワーク機器が商品化されてきている。
【０００３】
ＤＬＮＡは、一般の消費者が家庭内ネットワーク上につながっている異なるメーカーの製品同士がシームレスの相互接続環境を実現し、どの準拠製品からでも高い互換性が確保されたコンテンツをアクセスして楽しむことを可能にすることを目標とする規格である。
【０００４】
ＤＬＮＡでは、ホームネットワーク環境における機器間の相互接続に重要であるメディアサーバとそのネットワーク中のコンテンツを再生する機器についての設計ガイドラインが定義されている。
【０００５】
家庭内でのＡｕｄｉｏ ａｎｄ Ｖｉｓｕａｌ（ＡＶ）データ伝送が行われてきている昨今、地上波デジタル放送の開始などで高転送レートのＡＶデータを伝送する機能が必要となってきた。
【０００６】
その背景の中、低コスト化から能力の低いＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）が使用されるＡＶ機器では、高転送レートのＡＶデータ伝送を実現するための高速伝送用のＣＰＵとそれ以外のデータ通信を行うＣＰＵとの２つのＣＰＵを使用する構成がとられるのが一般的ある（例えば、特許文献１参照）。
【０００７】
さらに、両ＣＰＵには、データ通信を行うための通信プロトコルが搭載される。搭載される通信プロトコルの形態には、ハードウェアで構成するもの（例えば、特許文献２参照）や、ソフトウェアで構成するものがある。また、両ＣＰＵはバス接続され、ＣＰＵ間での通信を行う。
【０００８】
ここでいう通信プロトコルには、Ｔｒａｎｓｍｉｓｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＴＣＰ／ＩＰ）が標準として使用される。ＴＣＰ／ＩＰは、インターネット上の標準であり、世界中で最も広く使用されている通信プロトコルである。ＴＣＰ／ＩＰには、ＴＣＰとＩＰはもちろんのこと、一般的なこととして、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）、Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＡＲＰ）を含むものとする。ＩＣＭＰ、ＡＲＰについては後述する。
【０００９】
以下、従来のＡＶネットワーク機器において２つのＣＰＵで高転送レートのＡＶデータを伝送する従来の方法について、図１を使用して説明する。
【００１０】
図１は、従来のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【００１１】
図１に示すＡＶデータ伝送システムは、記録装置にＭｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）規格などで圧縮されたＡＶコンテンツが記録されているＡＶデータ送信装置１０と、ＡＶデータ送信装置から伝送されるＡＶデータを再生装置によって再生するＡＶデータ受信装置１３で構成される。ＡＶデータ受信装置１３は、通信プロトコルとしてＴＣＰ／ＩＰを使い、ネットワークを介してＡＶデータ送信装置に接続する。
【００１２】
なお、上述の記録装置および再生装置等の図示および説明は省略し、ＡＶデータの伝送に関する構成部についての図示および説明のみを行なう。
【００１３】
ＡＶデータ送信装置１０は、ＡＶデータを伝送する高速伝送用装置１２とＡＶデータの伝送以外のデータ通信を行うホスト装置１１とを備えている。ＡＶデータ受信装置１３は、同様に、高速伝送用装置１２とホスト装置１４とを備えている。
【００１４】
ホスト装置１１およびホスト装置１４は、第１の通信プロトコルによる通信を行なう第１通信プロトコル部１０２と、第１通信プロトコル部１０２にアクセスするための第１インターフェース（Ｉ／Ｆ）部１０１とをともに有する、また、それぞれは、第１Ｉ／Ｆ部１０１を介して第１通信プロトコル部１０２を使用する、通信のためのアプリケーションプログラム（以下、「ＡＰＰ」ともいう。）と、高速伝送用装置１２が有する第２通信プロトコル部１２２を使用するＡＶ伝送アプリケーションプログラムと、あらかじめホスト装置で所有している情報を高速伝送用装置１２に設定する情報設定部１０３とを有している。
【００１５】
高速伝送用装置１２は、ＡＶデータ伝送アプリケーションプログラムが使用する、第２の通信プロトコルによる通信を行なう第２通信プロトコル部１２２と、第２通信プロトコル部１２２にアクセスするための第２Ｉ／Ｆ部１２１と、第１通信プロトコル部１０２または第２通信プロトコル部１２２から入力されるデータを他の機器に送信し、また、ネットワークを介して受信したデータをパケット振り分け部１２４に出力する送受信部１２３と、送受信部１２３から入力された受信データを第１通信プロトコル部１０２または第２通信プロトコル部１２２に振り分けて出力するパケット振り分け部１２４とを有する。
【００１６】
ホスト装置１１およびホスト装置１４が有する通信アプリケーションプログラム、具体的には、サーバＡＰＰ１０５、クライアントＡＰＰ１０６、クライアントＡＰＰ１０８、およびサーバＡＰＰ１０９は、直接サービスを提供または利用するアプリケーションプログラムや、ＡＶデータ送信装置１０またはＡＶデータ受信装置１３を制御するアプリケーションプログラムなどである。
【００１７】
直接サービスを提供するアプリケーションプログラムとして、例えば、ＴＣＰ／ＩＰの上位プロトコルに位置するＦｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＦＴＰ）、Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）などの通信プロトコルを使用するものがある。また、独自仕様のアプリケーションプログラムである場合もある。
【００１８】
ＴＣＰ／ＩＰを使用する通信アプリケーションプログラムの多くは、クライアント／サーバモデルに準じて作られる。ホスト装置１１およびホスト装置１４の通信アプリケーションプログラムもこれに準じている。
【００１９】
また、ＡＶデータ送信装置１０が有するＡＶ伝送サーバＡＰＰ１０４はサーバアプリケーションであり、ＡＶデータ受信装置１３が有するＡＶ伝送クライアントＡＰＰ１０７はクライアントアプリケーションである。
【００２０】
ＴＣＰ／ＩＰを使う通信アプリケーションプログラムは、ポート番号を使用してアプリケーションプログラム間の通信回線を開く。ポート番号は、ＴＣＰおよびＵＤＰがアプリケーションプログラムを識別する際に使用される。
【００２１】
第１Ｉ／Ｆ部１０１および第２Ｉ／Ｆ部１２１は、一般的にソケットと呼ばれるＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）である。
【００２２】
ホスト装置１１の情報設定部１０３は、通信パスＡを使用して、ホスト装置１１で使用するＩＰアドレスやサブネットマスクなどの情報を高速伝送用装置１２に設定する。第１通信プロトコル部１０２は、通信パスＢを使用して送受信部１２３に送信したいデータを入力する。ＡＶ伝送サーバＡＰＰ１０４は、通信パスＣを使用し、第２Ｉ／Ｆ部を介して第２通信プロトコル部１２２と通信する。第２通信プロトコル部１２２は、通信パスＤを使用して送受信部１２３に送信したいデータを入力する。パケット振り分け部１２４は、通信パスＢと通信パスＤを使用して受信したデータを第１通信プロトコル部１０２と第２通信プロトコル部１２２とに振り分けて出力する。なお、ＡＶデータ受信装置１３のホスト装置１４の各構成部も同様の動作を行う。
【００２３】
上述のパケット振り分け部１２４は具体的には、次に説明する方法で振り分けを行う。
ＡＶデータ受信装置１３のＡＶ伝送クライアントＡＰＰ１０７は、接続する際に接続先ポート番号と第２通信プロトコル部１２２において使用するポート番号とを通信パスＣと第２Ｉ／Ｆ部１２１とを介して第２通信プロトコル部１２２に入力する。これにより、ＡＶデータ送信装置１０のＡＶ伝送サーバＡＰＰ１０４との通信回線を確立する。そして、ＡＶ伝送クライアントＡＰＰ１０７は、この確立されたポート番号を使用して、ＡＶデータの受信を行う。
【００２４】
ＡＶデータ送信装置１０のＡＶ伝送サーバＡＰＰ１０４は、使用するポート番号を通信パスＣと第２Ｉ／Ｆ部１２１とを介して第２通信プロトコル部１２２に入力して、使用する通信回線を開いて待機する。ＡＶ伝送クライアントＡＰＰ１０７からの通信回線確立が行われると、ＡＶ伝送サーバＡＰＰ１０４はＡＶデータの送信を行う。
【００２５】
上述のＡＶ伝送クライアントＡＰＰ１０７およびＡＶ伝送サーバＡＰＰ１０４が使用するポート番号のそれぞれは、通信パスＤを介し、ＡＶデータ伝送用として、それぞれのパケット振り分け部１２４に設定される。
【００２６】
パケット振り分け部１２４は、この設定されたポート番号と受信したパケットのポート番号とを照合して、該当するパケットであれば、通信パスＤにより第２通信プロトコル部１２２へ出力する。該当しないパケットであれば、通信パスＢにより第１通信プロトコル部１０２へ出力する。
【００２７】
ＡＶデータ送信装置１０とＡＶデータ受信装置１３とは、上述の構成および動作により、高転送レートのＡＶデータを伝送している。
【００２８】
本構成における、本発明に関わる従来技術について、（１）から（４）に分けて説明する。
【００２９】
（１）一般的なこととして、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）では、通過するネットワークが許容する最大転送単位（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ（ＭＴＵ）サイズ）にあわせてパケット分割（フラグメント）するという機能を持っている。
【００３０】
つまり、送信側では、アプリケーションプログラムから渡されたパケットがＭＴＵサイズよりも大きいとパケットの分割を行って送信する。受信側では、受信した分割パケット（フラグメントパケット）を元のパケットに再構築する。
【００３１】
なお、ＩＰにおけるフラグメントのことをＩＰフラグメントといい、ＩＰフラグメントにより生じる、分割された各パケットをＩＰフラグメントパケットという。
【００３２】
図２（ａ）は、ＩＰフラグメントの発生からＩＰフラグメントパケットの再構築までの処理の流れの一例を示す図である。図２（ｂ）は、ＩＰフラグメントパケットの一例を示す図である。
【００３３】
送信側の機器Ａと受信側の機器Ｂとが接続されたネットワークにおけるＭＴＵサイズは１５００オクテットである。ここで、図２（ａ）に示すように、そのネットワーク上に、ＭＴＵサイズが６２０オクテットのネットワークが存在する場合を想定する。このようなネットワーク構成において、機器Ａが機器Ｂに１０００オクテットのデータを送信する場合、ＩＰパケットはネットワークの境界にあるルータａで６００オクテットと４００オクテットのパケットに分割され送られる。そして、図２（ｂ）に示すように、ＴＣＰヘッダ（または、ＵＤＰヘッダ）の情報は、分割された先頭パケットにしか存在しない。つまり、ＩＰパケットの宛先である通信プロトコル部を特定するポート番号は、先頭パケットにのみ存在し、後続パケットには存在しない。
【００３４】
また、ＩＰフラグメントパケットは、ネットワークの状況によって順不同で到着することもある。最悪、パケットがネットワーク上で消失することもある。ＩＰでは、ＩＰフラグメントパケットの再構築の機能として、順不同で到着するパケットも許容される。
【００３５】
図３は、ＩＰフラグメントパケットが再構築できなかった際の処理の概要を示す図である。
【００３６】
図３に示すように、ネットワークでＩＰフラグメントパケットの一部が消失して再構築できない場合、ＩＰは、ＲＦＣ１１２２で推奨として記述されている６０ｓｅｃから１２０ｓｅｃのタイマ値の経過によって再構築できなかったパケットを廃棄する。廃棄する際、先頭パケットを受信していた場合に限り、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）によるＩＣＭＰ時間超過メッセージ（ＩＣＭＰフラグメントエラーメッセージ）を送信元に送出して再構築できなかったことを通知する。前述のＲＦＣとは、Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓの略であり、インターネットに関する技術の標準を定める団体であるＩＥＴＦが正式に発行する文書である。
【００３７】
従来のパケット振り分け部１２４のフラグメント再構築部２１０は、ＩＰフラグメントパケットの再構築が完了した後、先頭パケットに含まれるポート番号を照合して送信先に該当する通信プロトコル部に出力する。つまり、ポート番号に応じて第１通信プロトコル部１０２または第２通信プロトコル部１２２に再構築されたパケットを出力する。
【００３８】
また、再構築できずに残ってしまうパケットを１２０ｓｅｃ（推奨されているタイマ値の最大値）の経過により廃棄する。そして、廃棄する際、先頭パケットを受信していた場合には、ＩＣＭＰ時間超過メッセージ（ＩＣＭＰフラグメントエラーメッセージ）を送信する。このように、ＩＰフラグメントパケットを受信した場合には、ＩＰが行う処理、つまり、第１通信プロトコル部１０２および第２通信プロトコル部１２２が行なう処理をパケット振り分け部１２４でも行なっている。
【００３９】
図４は、従来のフラグメント再構築部の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント再構築部２１０の機能以外の機能を表す機能ブロックである。
【００４０】
図４を使用して、従来のフラグメント再構築部の構成について説明する。
受信したパケットはフラグメント判定部４０１に入力され、ＩＰフラグメントパケットであるか否かの判定を行う。フラグメント判定部４０１は、ＩＰフラグメントパケット以外であればパケット振り分け部１２４ａに渡し、ＩＰフラグメントパケットであれば先頭・後続パケット判定部４０２に出力する。
【００４１】
先頭・後続パケット判定部４０２は、入力されるＩＰフラグメントパケットをバッファ４０７に格納すると共に再構築情報記録部４０６に記憶されている再構築情報の情報更新を行う。また、フラグメント終了判定部にパケットを受信したことを通知する。そして、新規のＩＰパケットの断片であるＩＰフラグメントパケットを受信した際には、そのＩＰフラグメントパケットを１２０ｓｅｃ後に廃棄するためのタイマを起動する。
【００４２】
図５（ａ）は、ＩＰヘッダフォーマットを示す図であり、図５（ｂ）は、ＩＰヘッダに含まれるＰＲＯＴＯＣＯＬ領域の値とプロトコル名との対応を示す図であり、図５（ｃ）は、ＩＰヘッダに含まれるＦＬＡＧＳ領域のビットと意味との対応を示す図である。
【００４３】
図５（ａ）に示すＩＰヘッダに含まれるＩＤ３４０５、ＦＬＡＧＳ３４０６、ＯＦＦＳＥＴ３４０７、およびＴＯＴＡＬ＿ＬＥＮ３４０４の４種の情報により、ＩＰフラグメントパケットは識別される。この４種の情報からなる情報を以下、「ＩＰフラグメント識別情報」という。ＩＰフラグメント識別情報に基づいて再構築情報の更新やタイマ起動が行われる。
【００４４】
ＩＰフラグメントパケット到着の通知を受けたフラグメント終了判定部４０３では、再構築情報から再構築完了を判断する。再構築が完了している場合、引渡し先判定部４０４に通知する。通知を受けた引渡し先判定部４０４では、バッファ４０７に格納されている再構築が完了したＩＰフラグメントパケットを全て読み出し、再構築情報記憶部４０６の情報を消去しタイマを停止する。そして、先頭のＩＰフラグメントパケットに付与されているＴＣＰヘッダ（または、ＵＤＰヘッダ）に含まれるポート番号を照合して通信パスを決定し、再構築が完了したＩＰフラグメントパケットの出力要求を引渡し部４０５へ行う。
【００４５】
引渡し部４０５は要求にしたがって、通信パスＢまたは通信パスＤへ再構築完了したＩＰフラグメントパケットを出力する。
【００４６】
再構築が完了せずに、タイマによるタイムアウトが発生すると、情報消去部４０８は、タイムアウトとなるＩＰフラグメントパケットに関する再構築情報を再構築情報記憶部４０６から消去し、バッファ４０７内の、再構築できなかったＩＰフラグメントパケットを廃棄する。この際、再構築情報から先頭パケットを受信しているかどうかも判断する。先頭パケットを受信済みであった場合のみ、先頭パケットに含まれる情報を使用してＩＣＭＰ時間超過メッセージ（ＩＣＭＰフラグメントエラーメッセージ）を生成する。生成されたＩＣＭＰフラグメントエラーメッセージは送受信部１２３により、当該ＩＰフラグメントパケットの送信元に送信される。
【００４７】
従来のフラグメント再構築部２１０は以上のように構成され、動作している。
【００４８】
（２）一般的なこととして、通信プロトコル（ＴＣＰ／ＩＰ）には、ＩＰを補助するＩＣＭＰが含まれる。ＩＰパケットが何らかの障害によって到達できなかった時にＩＣＭＰによって障害の通知（ＩＣＭＰエラーメッセージ）が行われる。
【００４９】
ＩＣＭＰエラーメッセージにはＲＦＣ７９２で規定されるいくつかのタイプがあり、ＩＰを使って送信される。したがって、ＴＣＰヘッダ（または、ＵＤＰヘッダ）がつかないパケットであるため、パケット振り分け部ではどちらの通信プロトコル部に出力すればよいか判断できない。
【００５０】
そこで、従来のパケット振り分け部１２４のＩＣＭＰ複製部２１１では、受信したＩＣＭＰエラーメッセージパケットを複製して、第１通信プロトコル部１０２と第２通信プロトコル部１２２へ出力している。
【００５１】
図６は、従来のＩＣＭＰ複製部の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、ＩＣＭＰ複製部２１１の機能以外の機能を表す機能ブロックである。図６を使用して、ＩＣＭＰ複製部の構成および動作について説明する。
【００５２】
受信されたパケットはＩＣＭＰパケット判定部７０１に入力され、ＩＣＭＰパケット判定部７０１は入力されたパケットがＩＣＭＰパケットであるか否かの判定を行う。ＩＣＭＰパケット判定部７０１は、ＩＣＭＰパケット以外であればパケット振分け部１２４ａに渡し、ＩＣＭＰパケットであればパケット複製部７０２へ出力する。パケット複製部７０２は、入力されたＩＣＭＰパケットを複製して、通信パスＢと通信パスＤへ送信する要求と共に２つのＩＣＭＰパケットを引渡し部７０３へ出力する。引渡し部７０３は要求にしたがって、通信パスＢと通信パスＤへそれぞれＩＣＭＰパケットを出力する。
【００５３】
つまり、ＩＣＭＰパケットは第１通信プロトコル部１０２および第２通信プロトコル部１２２の双方へ出力される。
【００５４】
従来のＩＣＭＰ複製部２１０は以上のように構成され、動作している。
【００５５】
（３）従来のパケット振り分け部１２４において、正常に通信パスＢと通信パスＤへパケットを振り分けるためには、通信パスＣを使って設定されるポート番号が、ＡＶデータ伝送アプリケーションプログラム以外の通信アプリケーションプログラムで使用されるポート番号と異なる番号でなければならない。
【００５６】
従って、従来のＡＶデータ受信装置１３では、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号の範囲を取り決めて、クライアントＡＰＰ１０８およびサーバＡＰＰ１０９がそのポートを使用しないようにしている。例えば、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号を１０００１〜１０００２とし、それ以外をクライアントＡＰＰ１０８等の他の通信アプリケーションプログラムが使うようにしている（例えば、特許文献３参照）。
【００５７】
しかし、この方法では全てのアプリケーションプログラムで自らが使用するポート番号をあらかじめ決定するか、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号を、第１Ｉ／Ｆ部１０１にて使わないように制限をかけることをする必要がある。
【００５８】
一般的なこととして、サーバアプリケーションプログラムは通信回線を開いておかなければならないため、通信プロトコルＩ／Ｆを介して自らが使用するポート番号を通信プロトコル部に指定して通信回線を開かせる。一方、クライアントアプリケーションプログラムは、自らが使用するポート番号は意識することなく、通信プロトコルＩ／Ｆを介して通信回線を確立したいサーバアプリケーションプログラムのポート番号とＩＰアドレスとを指定して通信プロトコル部に通信回線を確立させる。しかし、クライアントアプリケーションプログラムは自らのポート番号を意識しないが、実際には通信プロトコルＩ／Ｆが使用されていないポート番号を適切に割り当てて通信プロトコル部に通信回線を確立させることが行われている。
【００５９】
（４）一般的なこととして、通信プロトコル部は、宛先ＩＰアドレスがわかれば、ＩＰパケットを送信することができる。しかし、実際にはＩＰアドレスに対応した物理アドレス（ＭＡＣアドレス）がわかれなければ通信相手にパケットを到着させることができない。
【００６０】
この物理アドレスの解決は、通信プロトコル部が装備するアドレス解決プロトコル（ＡＲＰ）によって行われる。アドレス解決の仕組みについて、図７に図解する。
【００６１】
図７は、アドレス解決プロトコル（ＡＲＰ）による一般的なアドレス解決の仕組みを示す図である。
【００６２】
ＡＲＰは、通信元が、ＩＰアドレスは知っているが物理アドレスがわからない通信相手の物理アドレスを検索するためのプロトコルである。通信元は、通信相手を探すためのＡＲＰ要求パケットをブロードキャストし、該当する通信相手はＡＲＰ応答パケットを返送して自らの物理アドレスを通知する。ＡＲＰ応答パケットを受信した送信元は、ＩＰアドレスと物理アドレスとの関連を管理するＡＲＰテーブルに記録する。これによって、物理アドレスを解決した通信プロトコル部は、ＩＰパケットを通信相手に送信することが可能となる。
【００６３】
従来、例えば、特許文献４に記述される方法でアドレス解決が行われる。
図８は、特許文献４に開示された、物理アドレスの解決を行なう従来のホストコンピュータの機能的な構成を示す機能ブロック図である。
【００６４】
特許文献４に記述されるアドレス解決方法を、図１に示すＡＶデータ受信装置１３に適用した場合を想定する。
【００６５】
ＡＶ伝送クライアントＡＰＰ１０７が通信先の物理アドレスを知らなかった場合、通信先宛のダミーＩＰパケットが第１Ｉ／Ｆ部を介して第１通信プロトコル部１０２に送られる。第１通信プロトコル部１０２では、ＡＲＰによるアドレス解決が実行され、通信パスＢを使用してダミーＩＰパケットの送信を行おうとする。ここで、通信先の機器がダミーＩＰパケットを廃棄しない構成である場合、ダミーＩＰパケットの送信を止めるために、通信パスＢ上にダミーＩＰパケットを廃棄する処理部を設けなければならない。
【００６６】
ＡＶ伝送クライアントＡＰＰ１０７は、第１通信プロトコル部１０２でＡＲＰによるアドレス解決が行われたことをＡＲＰからの通知により、または、第１通信プロトコル部１０２が有するＡＲＰテーブルを監視することにより所望の物理アドレスを得たことを検知し、その物理アドレスを取得する。そして、通信パスＣにより、第２Ｉ／Ｆ部１２１を介して、取得した物理アドレスを第２通信プロトコル部１２２のＡＲＰテーブルへ登録する。このようにして、第２の通信プロトコルにおけるアドレス解決を行い、ＡＶ伝送クライアントＡＰＰ１０７は、通信パスＣを使用して通信を開始する。
【特許文献１】特開２０００−２３５５３６号公報 （第４−５頁、第１図）
【特許文献２】特開２００２−３５４０４６号公報 （第４頁、第２図）
【特許文献３】特開２０００−２３５５３６号公報 （第１０頁）
【特許文献４】特開２０００−２３５５３６号公報 （第１１頁、第五図）
【発明の開示】
【発明が解決しようとする課題】
【００６７】
上述のように、上記従来のＡＶネットワーク機器は、高転送レートが要求されるため、ホスト装置と高速伝送用装置とで構成されている。さらに、１つの機器に複数の通信プロトコルが搭載されている。このような構成の機器においては、以下のような課題がある。
【００６８】
パケット振り分け部１２４におけるフラグメント再構築部２１０では、適切に出力する通信パスを決定するためにＩＰフラグメントパケットを再構築する処理を行っている。このパケットの再構築機能は、ＩＰに標準搭載されている機能である。つまり、第１通信プロトコル部１０２および第２通信プロトコル部１２２に搭載されている機能をフラグメント再構築部２１０にも搭載することとなり、冗長に機能が追加されている。
【００６９】
また、パケットの再構築が完了するまでバッファ４０７にＩＰフラグメントパケットを保持しておかなければならず、バッファ４０７を他の処理と共有する際に有効活用できないという課題を有している。さらに、再構築が完了しなければ第１通信プロトコル部１０２または第２通信プロトコル部１２２へ出力しないため、第１通信プロトコル部１０２または第２通信プロトコル部１２２へのパケット到着がＩＰフラグメントパケットの場合には常に遅延するという課題も有している。
【００７０】
また、上記従来の技術においては、更に、以下のような課題も有している。
パケット振り分け部１２４のＩＣＭＰ複製部２１１では、受信したＩＣＭＰエラーメッセージパケットの送信先の通信パスを判断することができない。そのため、受信したＩＣＭＰエラーメッセージパケットを複製して第１通信プロトコル部１０２と第２通信プロトコル部１２２とへ出力していた。つまり、第１通信プロトコル部１０２を使用してデータ通信を行っている通信回線に異常が発生した際、受信するＩＣＭＰエラーメッセージパケットをまったく関係のない第２通信プロトコル部１２２にも出力することになる。また、当然に逆のパターンも発生する。
【００７１】
したがって、冗長にＩＣＭＰエラーメッセージパケットの複製処理を行い、ＣＰＵの処理能力を使用していることとなる。さらに、第１通信プロトコル部１０２を使用してデータ通信を行っている通信回線に異常が頻発した際、無関係である第２通信プロトコル部１２２にも処理負荷をかけることとなり、高速伝送に弊害を及ぼす課題も有している。
【００７２】
また、上記従来の技術では、パケット振り分け部１２４にて正常にポート番号の照合を行うために、全てのアプリケーションプログラムで自らが使用するポート番号をあらかじめ決定するか、第１Ｉ／Ｆ部１０１を改変し、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号を使用しないように制限をかける必要がある。さらに、通常のクライアントアプリケーションプログラムは一般的に、ポート番号の決定を通信プロトコルインターフェースに委ねており、他のシステムで使用されていた通信アプリケーションプログラムを、従来のＡＶネットワーク機器で使用する際には、その通信アプリケーションプログラムにも改変を加えなければならないという課題を有している。
【００７３】
また、上記従来の技術では、第２通信プロトコル部１２２が使用する物理アドレスを解決するために、第１通信プロトコル部１０２が物理アドレスの解決を実行する必要があった。また、解決したアドレスを通信パスＣを介して登録するという通信を行わなければならなかった。さらに、ホスト装置のＡＶ伝送アプリケーションプログラムはダミーＩＰパケットを送信する動作を行わなければならず、高速伝送装置はダミーＩＰパケットを廃棄する動作を行わなければない。このように、ＡＶ伝送アプリケーションが第１通信プロトコル部１０２も使用しなければならないという課題と、ホスト装置と高速伝送装置の両装置で連動して動作する処理を追加しなければならないという課題とを有している。
【００７４】
本発明は、上記従来の課題を考慮し、複数の通信プロトコルでＩＰパケットの通信を行なうデータ通信装置であって、構成上および処理上の無駄の発生を削減することができるデータ通信装置を提供することを目的とする。
【課題を解決するための手段】
【００７５】
上記目的を達成するために、本発明のデータ管理装置は、第１の通信プロトコルで通信する第１通信プロトコル部と、第２の通信プロトコルで通信する第２通信プロトコル部とを備え、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）パケットによる通信を行なうデータ通信装置であって、前記ＩＰパケットは、前記ＩＰパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するための宛先情報を有する１つの第１パケットと、前記宛先情報を有しない１つ以上の第２パケットとに分割されており、前記データ通信装置は、前記第１パケットまたは前記第２パケットである、ＩＰフラグメントパケットを受信する受信手段と、前記宛先情報を記憶するための宛先情報記憶手段と、前記第２パケットを記憶するためのバッファと、前記ＩＰフラグメントパケットが第１パケットであるか否かを判定し、前記ＩＰフラグメントパケットが第１パケットである場合、前記第１パケットが有する宛先情報を、前記宛先情報記憶手段に記憶させる第１パケット判定手段と、前記第１パケットを、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する振り分け手段と前記ＩＰフラグメントパケットが、前記第１パケット判定手段により前記第１パケットでないと判定された第２パケットである場合、前記宛先情報が前記宛先情報記憶手段に記憶されているとき、前記第２パケットを前記振り分け手段へ渡し、前記宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させる第２パケット制御手段とを備え、前記振り分け手段は、前記第２パケット制御手段から前記第２パケットを受け取ると、前記宛先情報記憶手段に記憶されている前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ前記第２パケットを出力する。
【００７６】
これにより、本発明のデータ通信装置は、ＩＰフラグメントパケットの再構築処理を通信プロトコル部と重複してパケット振り分け部に設けなくてよい。さらに、第１パケットである先頭パケットを受信すると、その先頭パケットを第１通信プロトコル部または第２通信プロトコル部へ引き渡すことができる。これにより、先頭パケット引渡しまでの遅延時間が減少する。また、その宛先に関する宛先情報は記憶されるため、第２パケットである後続パケットは、その宛先情報に基づいて適切に第１通信プロトコル部または第２通信プロトコル部へ振り分けられて出力される。従って先頭パケットが到着した後に到着する後続パケットは、バッファを使用しなくてもよい。つまり、バッファを効率良く使用できる。
【００７７】
また、前記受信手段は、更に、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）エラーメッセージパケットを受信し、前記データ通信装置は、更に、前記ＩＣＭＰエラーメッセージパケットが、前記ＩＣＭＰエラーメッセージパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するためのエラー通知先情報を有するか否かを判定するエラーパケット判定手段と、前記エラーパケット判定手段により前記エラー通知先情報を有していると判定された前記ＩＣＭＰエラーメッセージパケットを、前記通知先情報に基づき、第１通信プロトコル部および第２通信プロトコル部のいずれか一方に出力するエラー出力手段と、前記エラーパケット判定手段により前記エラー通知先情報を有していないと判定された前記ＩＣＭＰエラーメッセージパケットを複製し、第１通信プロトコル部および第２通信プロトコル部のそれぞれに前記ＩＣＭＰエラーメッセージパケットを１つずつ出力するエラー複製手段とを備えるとしてもよい。
【００７８】
これにより、複製が必要なＩＣＭＰパケットのみ複製を行うようになり、無用なパケット複製による処理負荷を減らすことができる。また、第１通信プロトコル部および第２通信プロトコル部は、自身に不要なＩＣＭＰパケットを受信する回数が減り、無駄な処理負担を削減することができる。
【００７９】
また、本発明のデータ通信装置は、更に、前記第１通信プロトコル部で使用されるポート番号の登録要求と削除とを受け付けるインターフェースと、前記第２通信プロトコル部で使用される使用ポート番号を決定するポート番号決定手段と、前記ポート番号決定手段により決定された前記使用ポート番号の登録要求を、前記インターフェースを介して前記第１通信プロトコル部に行なうポート番号登録手段と、前記第２通信プロトコル部からの所定の通知により、前記第１通信プロトコル部に登録されている前記使用ポート番号を削除するポート番号削除手段とを備え、前記インターフェースは、前記第１プロトコル部に登録されているポート番号の登録は受け付けず、前記ポート番号登録手段が、前記使用ポート番号を前記第１通信プロトコル部に登録できた場合、前記使用ポート番号は前記第１通信プロトコル部では使用されないとしてもよい。
【００８０】
これにより、例えば、第２通信プロトコル部を使用するＡＶデータ伝送を行うクライアントアプリケーションは、従来のクライアントアプリケーションと同様にポート番号を意識せずデータ通信を行うことができる。さらに、第１通信プロトコル部のインターフェースにポート番号の制限を行うための改変を行わなくてもよい。
【００８１】
また、本発明のデータ通信装置は、更に、前記第１通信プロトコル部または前記第２通信プロトコル部から送信される、他の機器の物理アドレスの解決を要求するＡｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＡＲＰ）要求パケットを受け付けるＡＲＰ要求受付手段と、前記ＡＲＰ要求受付手段により受け付けられた前記ＡＲＰ要求パケットから得られる、送信元を示す送信元情報と、前記他の機器のＩＰアドレスである送信先アドレスとを対応付けて記憶するＡＲＰ情報記憶手段と、前記ＡＲＰ要求パケットを前記他の機器に送信するＡＲＰ送信手段と、前記他の機器から送信される、前記ＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットを受信するＡＲＰ応答受信手段と、前記ＡＲＰ応答受信手段により受信された前記ＡＲＰ応答パケットから得られる、前記他の機器のＩＰアドレスと、前記ＡＲＰ情報記憶手段に記憶されている前記送信先アドレスとから、前記ＡＲＰ応答パケットの出力先を判定する応答出力判定手段と、前記応答出力判定手段の判定結果に従い、前記ＡＲＰ応答パケットを前記第１通信プロトコル部または前記第２通信プロトコル部のいずれか一方に出力する応答出力手段とを備えるとしてもよい。
【００８２】
これにより、例えば、第１通信プロトコル部を有するホスト装置と、第２通信プロトコル部を有する高速伝送用装置とで構成されたＡＶデータ送信装置において、ホスト装置への機能および処理の追加を行なうことなく、さらに、第２通信プロトコル部を使用するＡＶ伝送アプリケーションが第１通信プロトコル部を使用することなく、第１通信プロトコル部および第２通信プロトコル部が要求する物理アドレスの解決を行うことができる。
【００８３】
更に、本発明は、本発明のデータ通信装置の特徴的な構成部をステップとする方法として実現したり、それらのステップを含むプログラムとして実現したり、そのプログラムが格納された、ＣＤ−ＲＯＭ等の記録媒体として実現したり、集積回路として実現することもできる。プログラムは、通信ネットワーク等の伝送媒体を介して流通させることもできる。
【発明の効果】
【００８４】
本発明により、高転送レートでの通信が要求されるデータ通信装置であって、構成上および処理上の無駄の発生を削減するためのデータ通信装置を提供することができる。
【００８５】
以上説明したように、本発明によれば、ホスト装置と高速伝送用装置に複数の通信プロトコルを搭載するＡＶデータ伝送装置において、ＩＰフラグメントパケットの再構築処理を通信プロトコルと重複して高速伝送用装置に設けることなく、フラグメントパケットを処理可能であり、先頭パケットを受信した時点でパケットの引渡しを行うため引渡しまでの遅延が減り、バッファを効率良く使用することが可能となる。そして、ＩＣＭＰパケットの受信では、複製が必要なＩＣＭＰパケットのみ複製を行うことができ、無用なパケット複製による処理負荷を減らすことが可能となる。また、通信プロトコルインターフェースに改変をいれることなく、ＡＶデータ伝送を行うクライアントアプリケーションに対して、従来のクライアントアプリケーションと同様にポート番号を意識させないことが可能である。さらに、通信プロトコルのアドレス解決では、ホスト装置と高速伝送用装置の両装置で連動して動作する処理を必要とせず、さらにＡＶ伝送アプリケーションが第１通信プロトコル部１０２を使用せずに解決することが可能となる。
【００８６】
本発明によるさらなる効果については、後述する本発明の実施の形態の説明や図面に基づく詳細な説明で記述する。
【発明を実施するための最良の形態】
【００８７】
以下、本発明の実施の形態について図面を用いて説明する。
【００８８】
＜実施の形態１＞
本発明の実施の形態１として、ＩＰフラグメントパケットを受信した際のバッファの効率的な利用を可能とする形態について説明する。
【００８９】
本発明の実施の形態１について、図９〜図１３を用いて説明する。
図９は、実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【００９０】
ＡＶデータ送信装置１０およびＡＶデータ受信装置１３のそれぞれは、本発明のデータ通信装置の一例である。具体的には、ＡＶコンテンツをネットワーク伝送する機能を有するＤＶＤレコーダや、ネットワーク伝送でＡＶコンテンツを受信して再生する機能を有するデジタルＴＶ等により実現される。
【００９１】
なお、ＡＶコンテンツを蓄積する機能等、ＡＶデータ送信装置１０およびＡＶデータ受信装置１３が本来備えている構成部についての図示および説明は省略し、本発明の特徴的な構成部についてのみ図示および説明を行なう。後述する実施の形態２〜１６においても同様である。
【００９２】
図９に示すように、実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、図１に示した従来のＡＶデータ送信装置１０およびＡＶデータ受信装置１３と比較すると、パケット振り分け部１２４内に、フラグメント制御部１１０を持つことを特徴とする。フラグメント制御部１１０は、受信したＩＰフラグメントパケットが先頭パケットであるか後続パケットであるかに応じ、効率的に処理する処理部である。
【００９３】
なお、先頭パケットは本発明のデータ通信装置における第１パケットの一例であり、後続パケットは本発明のデータ通信装置における第２パケットの一例である。
【００９４】
図１０は、実施の形態１におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【００９５】
フラグメント制御部１１０は、制御情報記憶部３０７に記憶されている制御情報に基づき、ＩＰフラグメントパケットの通信プロトコル部への送信を制御する。
【００９６】
図１１は、実施の形態１における制御情報記憶部３０７に記憶されている制御情報のデータ構成の一例を示す図である。制御情報がどのように用いられるかについては、後述の動作の説明の中で述べる。
【００９７】
図１２（ａ）は、ＴＣＰヘッダフォーマットを示す図であり、図１２（ｂ）は、ＵＤＰヘッダフォーマットを示す図である。
【００９８】
受信パケットのフォーマットであるＩＰヘッダフォーマットにおけるＤＡＴＡ３４１４（図５（ａ）参照）に、図１２（ａ）および図１２（ｂ）に示すフォーマットのＴＣＰヘッダまたはＵＤＰヘッダなどがペイロードデータとして格納されている。
【００９９】
図１３は、実施の形態１におけるフラグメント制御部１１０の動作の流れを示すフローチャートである。図１３を用いフラグメント制御部１１０の各構成部の動作について説明する。
【０１００】
まず、送受信部１２３を介し、ネットワークからパケットを受信すると、フラグメント判定部３０１へ受信パケットが入力される。
【０１０１】
フラグメント判定部３０１では、受信したパケットＩＰフラグメントパケットかどうかを判定する。受信したパケットがＩＰフラグメントパケットでない場合（Ｓ１０でＮｏ）、パケット振り分け部１２４ａへと受信パケットを出力（Ｓ１１）することで、以降そのパケットは適切な通信パスへ振り分けられる。
【０１０２】
受信パケットがＩＰフラグメントパケットである場合（Ｓ１０でＹｅｓ）、先頭パケット判定部３０２へ受信パケットが出力される。
【０１０３】
先頭パケット判定部３０２は、入力された受信パケットが先頭パケットであるかどうかを判断する。なお、先頭パケット判定部３０２は、本発明のデータ通信装置における第１パケット判定手段の一例である。先頭パケットであるかどうかの判断方法は、一般的なＩＰの仕様であるため、その説明は省略する。
【０１０４】
受信パケットが後続パケットである場合（Ｓ１２でＮｏ）、先頭パケット判定部３０２は、この受信パケットであるＩＰフラグメントパケットを後続パケット判定部３０３へ出力する。後続パケット判定部３０３では、制御情報記憶部３０７に記憶されている制御情報を参照し、以前に、このＩＰフラグメントパケットに対応する先頭パケットが到着していたかどうかを確認する。この確認は、制御情報記憶部３０７に記憶されている制御情報に基づき行なわれる。なお、先頭パケット判定部３０２は、本発明のデータ通信装置における第２パケット制御手段の一例である。
【０１０５】
制御情報記憶部３０７には、図１１に示す制御情報が記憶されている。制御情報記憶部３０７は、本発明のデータ通信装置における宛先情報記憶手段の一例であり、制御情報は、本発明のデータ通信装置における宛先情報の一例である。
【０１０６】
制御情報は１つ以上のエントリで構成される。１つのエントリは、ＩＰヘッダパラメータであるＳＯＵＲＣＥ ＡＤＤＲＥＳＳ１６０１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ１６０２、ＩＤ１６０３、およびＰＲＯＴＯＣＯＬ１６０４の各情報と、送信元ポート番号１６０６、宛先ポート番号１６０７、および先頭パケットの到着有無を示すフラグである先頭パケット到着ｆｌｇ１６０５とで構成される。
【０１０７】
後続パケット判定部３０３は、ＩＰフラグメントパケットを受信するたびに、そのＩＰヘッダ内にあるＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２、およびＩＤ３４０５、を各エントリと比較する。この比較の結果、上記３種の情報が一致し、かつ先頭パケットの到着ｆｌｇ１６０５が到着ありを示すエントリがある場合、受信したＩＰフラグメントパケットに対応する先頭パケットがすでに到着済みであると判断する（Ｓ１３でＹｅｓ）。
【０１０８】
このようにして、先頭パケットが到着済みであることを確認することができる。なお、上述の確認方法は一例であり、この方法に限定するものではない。例えば、先頭パケットのみが有し、後続パケットは有しない情報である宛先ポート番号が、上記３種の情報が一致するエントリに登録されている場合、先頭パケットが到着済みであると判断してもよい。
【０１０９】
後続パケット判定部３０３は、以前に先頭パケットが到着していたことを確認した場合（Ｓ１３でＹｅｓ）、引渡し先判定部３０５へ受信パケットを出力する（Ｓ１４）。また、上記条件を満たすエントリがない場合、まだ先頭パケットが到着していないことを確認し（Ｓ１３でＮｏ）、バッファ３０９へ受信パケットを保存する（Ｓ１５）。
【０１１０】
なお、このとき、受信パケットのＩＰヘッダ内にあるＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２およびＩＤ３４０５の組み合わせを有する制御情報のエントリが、制御情報記憶部３０７に存在しない場合、つまり、受信パケットが初めて到着したＩＰフラグメントパケットである場合（Ｓ１６でＹｅｓ）、新たなエントリとして登録し、情報消去部３１０のタイマ（例えば１２０秒など）を起動させる（Ｓ１７）。
【０１１１】
情報消去部３１０は、タイマを有しており、タイマに設定された期間（例えば１２０秒など）が満了した場合、そのエントリを消去する。また、そのエントリに対応する後続パケットもバッファ３０９から消去する。
【０１１２】
また、先頭パケット判定部３０２が、受信パケットは先頭パケットであると判断した場合（Ｓ１２でＹｅｓ）、制御情報記憶部３０７に記憶されている制御情報を参照し、その先頭パケットに対応する後続パケットがバッファ３０９に保存されているかどうかを確認する。
【０１１３】
この確認は、制御情報記憶部３０７に記憶されている制御情報に基づき行なわれる。
制御情報記憶部３０７は、制御情報に、ＳＯＵＲＣＥ ＡＤＤＲＥＳＳ１６０１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ１６０２、およびＩＤ１６０３の情報の組み合わせが、受信した先頭パケットのＩＰヘッダ内の同パラメータ値の組み合わせと一致するエントリがある場合、その先頭パケットに対応する後続パケットがバッファ３０９に保存されていると判断する（Ｓ１８でＹｅｓ）。なお、上記３つの情報の組合せは本発明のデータ通信装置における識別情報の一例である。
【０１１４】
この場合、先頭パケット判定部３０２は、受信した先頭パケットだけでなく、バッファ３０９に保存されている、その先頭パケットに対応する全ての後続パケットも、引渡し先判定部３０５へ出力する（Ｓ１９）。さらに、当該エントリの先頭パケット到着ｆｌｇ１６０５を到着有りを示す値に変更し、ＰＲＯＴＯＣＯＬ１６０４、送信元ポート番号１６０６、宛先ポート番号１６０７に各情報を登録する。
【０１１５】
後続パケットがバッファ３０９に保存されていない場合、つまり、上記条件に該当するエントリが制御情報記憶部３０７に存在しない場合（Ｓ１８でＮｏ）、受信した先頭パケットのみを引渡し先判定部３０５へ出力する（Ｓ２０）。
【０１１６】
このとき、先頭パケット判定部３０２は、この先頭パケットに対応する新たなエントリを登録し、情報消去部３１０のタイマ（例えば１２０秒など）を起動させる（Ｓ２１）。
【０１１７】
この登録の際、先頭パケット到着ｆｌｇ１６０５は到着有りを示す値に設定される。さらに、ＰＲＯＴＯＣＯＬ１６０４、送信元ポート番号１６０６、宛先ポート番号１６０７に加えＳＯＵＲＣＥ ＡＤＤＲＥＳＳ１６０１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ１６０２、およびＩＤ１６０３が登録される。
【０１１８】
このように、受信パケットまたはバッファ３０９に保持されていたパケットは、先頭パケット判定部３０２または後続パケット判定部３０３により、引渡し先判定部３０５へ出力される。
【０１１９】
引渡し先判定部３０５では、入力された受信パケットのＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２、およびＩＤ３４０５の情報の組み合わせと一致する組合せを有するエントリを検索する。さらに、該当するエントリの宛先ポート番号から宛先ポート番号を特定し（Ｓ２２）、特定した宛先ポート番号と受信パケットとを引渡し部３０６へ出力する。
【０１２０】
引渡し部３０６では、受信した宛先ポート番号に該当する通信プロトコル部への通信パスへ、パケットを送信する（Ｓ２３）。具体的には、第１通信プロトコル部１０２へ送信する場合は、通信パスＢに送信し、第２通信プロトコル部１２２へ送信する場合は、通信パスＤに送信する。このように、引渡し先判定部３０５と引渡し部３０６とにより、本発明のデータ通信装置における振り分け手段は実現される。
【０１２１】
上述のように、実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、フラグメント制御部１１０を有している。フラグメント制御部１１０により、受信したＩＰプラグメントパケットが先頭パケットであるか否か判断され、先頭パケットである場合、その先頭パケットは、宛先である通信プロトコル部へ送信される。
【０１２２】
その際、バッファ３０９に格納されている、その先頭パケットに対応する後続パケットも先頭パケットと共に送信される。
【０１２３】
つまり、後続パケットは先頭パケットが到着するまで、バッファ３０９に保持されるが、先頭パケットが到着すると、宛先の通信プロトコル部に送信される。その後に到着した後続パケットも、制御情報記憶部３０７に宛先のポート番号が記憶されているため、正しく宛先の通信プロトコル部へ送られることとなる。
【０１２４】
従来では、ある１つのデータの振り分けを実施する際に、そのデータを構成する全てのＩＰフラグメントパケットをバッファに保持して再構築する必要がある。そのため、多量のバッファが必要となる。しかしながら、実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３においては、フラグメント制御部１１０の動作により、ある１つデータを宛先の通信プロトコル部へ到達させる際の一時的なバッファの使用量を、そのデータの先頭パケットが到着するまでの最低限の使用量に低減することができる。
【０１２５】
このように、本発明はバッファの利用効率を向上させる効果を有する。つまり、バッファ利用における無駄を削減することができる。
【０１２６】
また、第１通信プロトコル部１０２および第２通信プロトコル部１２２へのパケットの到着の遅延を防ぐことができる。
【０１２７】
＜実施の形態２＞
本発明の実施の形態２として、第１通信プロトコル部１０２または第２通信プロトコル１２２がＩＣＭＰエラーメッセージを送信する際に、不要となる制御情報をバッファから削除する形態について説明する。
【０１２８】
本発明の実施の形態２について、図１４〜図１６を用いて説明する。
図１４は、実施の形態２のＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０１２９】
図１４に示すように、実施の形態２のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、図９に示した実施の形態１のＡＶデータ送信装置１０およびＡＶデータ受信装置１３と比較すると、送受信部１２３内に、ＩＣＭＰ監視部１１２を持つことを特徴とする。ＩＣＭＰ監視部１１２はＩＣＭＰエラーメッセージを監視する処理部である。
【０１３０】
図１５は、実施の形態２におけるフラグメント制御部１１０およびＩＣＭＰ監視部１１２の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０１３１】
図１６は、ＩＣＭＰエラーメッセージのパケットフォーマットを示す図である。なお、フラグメントタイムアウト用のＩＣＭＰエラーメッセージ（ＴｉｍｅＥｘｃｅｅｄｅｄ ｃｏｄｅ＝１）も本フォーマットであり、タイプ３６０１には、“１１”が設定され、コード３６０２には、“１”が設定されていることで識別される。
【０１３２】
また、ＤＡＴＡ３６０５には、エラーの発生したパケットに関する情報が格納される。この情報を利用する形態については実施の形態１０として後述する。
【０１３３】
実施の形態２のＡＶデータ送信装置１０およびＡＶデータ受信装置１３の動作は、送信パケットを監視する部分以外は、実施の形態１の各装置の動作と同様の動作である。そのため、実施の形態１との差分の説明のみ記載する。
【０１３４】
第１通信プロトコル部１０２または、第２通信プロトコル部１２２が送信するパケットは、通信パスＢまたは通信パスＤを介して、送受信部１２３に入力される。このときのＩＣＭＰ監視部１１２の動作について説明する。なお、以下、第１通信プロトコル部１０２または、第２通信プロトコル部１２２により送信されたパケットを送信パケットという。
【０１３５】
ＩＣＭＰ監視部１１２内の、タイムアウト（以下、「ＴＭＯ」ともいう。）判定部３１１は、送信パケットが、フラグメントタイムアウト用のＩＣＭＰエラーメッセージ（ＴｉｍｅＥｘｃｅｅｄｅｄ ｃｏｄｅ＝１）であるかをチェックする。フラグメントタイムアウト用のＩＣＭＰエラーメッセージである場合、当該メッセージのＤＡＴＡ３６０５の内容を解析する。なお、ＴＭＯ判定部３１１は、本発明のデータ通信装置におけるタイムアウト検出手段の一例である。
【０１３６】
ＤＡＴＡ３６０５には、フラグメントの再構築に失敗した先頭パケットの情報が格納されている。その格納されている情報が図５（ａ）に示すＩＰヘッダフォーマットであり、ＤＡＴＡ３４１４内に、図１２（ａ）および図１２（ｂ）に示したＴＣＰヘッダまたはＵＤＰヘッダのフォーマットが格納されていた場合、その中の、ＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２、およびＩＤ３４０５の情報を参照する。
【０１３７】
次に、ＴＭＯパケット判定部３１１は、これらの情報の組に一致する情報の組を有するエントリが、制御情報記憶部３０７内にあるかをチェックする。該当するエントリがある場合、そのエントリの全ての情報を０クリアする。また、そのエントリに関して、情報消去部３１０のタイマ（例えば１２０秒など）についても停止させた後、前記送信パケットをネットワークへ送出する。また、ＴＭＯパケット判定部３１１は、上記条件を満たすエントリが制御情報記憶部３０７に存在しない場合は、そのまま送信パケットをネットワークへ送出する。
【０１３８】
このように、実施の形態２によれば、情報消去部３１０だけでなく、ＴＭＯパケット判定部３１１が制御情報を消去することができる。具体的には、ＴＭＯパケット判定部３１１は、第１通信プロトコル部１０２または第２通信プロトコル部１２２によりＩＣＭＰエラーメッセージパケットが送信されたことを検出する。ＩＣＭＰエラーメッセージパケットが送信されたということは、そのメッセージに対応する受信パケットについての制御情報は不要であり削除する。これによりバッファ３０９を有効活用することが可能となる。
【０１３９】
なお、ＴＭＯパケット判定部３１１の指示により、情報消去部３１０が、不要な制御情報を消去してもよい。
【０１４０】
＜実施の形態３＞
本発明の実施の形態３として、ＩＰフラグメントパケットの廃棄のための適切なタイマ値設定を考慮した形態を説明する。
【０１４１】
本発明の実施の形態３について、図１７を用いて説明する。
図１７は、実施の形態３におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０１４２】
実施の形態３は、フラグメント制御部１１０がタイマ設定部１９０１を備える形態である。タイマ設定部１９０１は、第１通信プロトコル部１０２に設定されたタイマ値を通信パスＡを介して取得し、情報消去部３１０に設定されたタイマ値（例えば１２０秒など）と比較する。比較の結果、大きい方を情報消去部３１０で使用する。他の処理については、実施の形態１と同様である。
【０１４３】
実施の形態３によれば、情報消去部３１０に、第２通信プロトコル部１０２に設定されたタイマ値が設定されている場合、第１通信プロトコル部１０２に設定されたタイマ値と、第２通信プロトコル部１０２に設定されたタイマ値とを比較することができる。
【０１４４】
この比較の結果、大きい方のタイマ値を採用することで、第１通信プロトコル部１０２に求められるタイムアウトのための期間と、第２通信プロトコル部１２２（１２２）に求められるタイムアウトのための期間とを包含したタイマ値で動作することができる。結果、どんなホスト装置に高速伝送用装置１２を接続した場合でも、高速伝送用装置１２に手を加えることなく、適切なタイマ値で動作させることができる。
【０１４５】
一般に、高速伝送用装置の用途として、さまざまなＡＶネットワーク機器のホスト装置と接続することが求められる。そのため、第１通信プロトコル部１０２はホスト装置ごとに異なり、当然、前述のタイマ値もそれぞれ異なることが考えられる。そこで実施の形態３の構成をとることにより、高速伝送用装置１２は、簡単な実現手段で、汎用的かつ量産に適した構成をとることが可能となる。
【０１４６】
＜実施の形態４＞
本発明の実施の形態４として、ＩＰフラグメントパケットの廃棄のための適切なタイマ値設定を考慮した第２の形態を説明する。
【０１４７】
本発明の実施の形態４について、図１８と図１９を用いて説明する。
図１８は、実施の形態４におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０１４８】
図１８に示すように、実施の形態４におけるフラグメント制御部１１０は、実施の形態３におけるフラグメント制御部１１０の情報消去部３１０に換えて、第１消去部２００１および第２消去部２００２を配置した構成となる。
【０１４９】
第１消去部２００１および第２消去部２００２は、それぞれタイマを有しており（図示せず）、それぞれのタイマに異なるタイマ値を設定することが可能である。
【０１５０】
具体的には、第１消去部２００１は、第１通信プロトコル部１０２用のタイマ値が設定され、第２消去部２００２は、第２通信プロトコル部１２２用のタイマ値が設定される。第１通信プロトコル部１０２のタイマ値の取得方法については、実施の形態３と同様である。
【０１５１】
図１９は、実施の形態４における制御情報記憶部３０７に記憶されている制御情報のデータ構成の一例を示す図である。第１プロトコル配送不可フラグ２１０１は第１通信プロトコル部１０２への振り分けが不要であることを示すフラグ値が設定される管理情報領域である。第２プロトコル配送不可フラグ２１０２は、第２通信プロトコル部１２２への振り分けが不要であることを示すフラグ値が設定される管理情報領域である。それぞれ初期化時は、配送可能を示す値をとる。
【０１５２】
なお、第１プロトコル配送不可フラグ２１０１に設定されるフラグ値は、本発明のデータ通信装置における第１経過情報の一例であり、第２プロトコル配送不可フラグ２１０２に設定されるフラグ値は、本発明のデータ通信装置における第２経過情報の一例である。
【０１５３】
実施の形態４では、図１９に示す各エントリに対して、登録された時点から上記２つのタイマを同時に開始し、第１消去部２００１または第２消去部２００２のタイマが満了した場合に、それぞれ対応する第１プロトコル配送不可フラグ２１０１または第２プロトコル配送不可フラグ２１０２に配送不可を示す値が設定される。結果、両方とも配送不可になった場合は、第１消去部２００１または第２消去部２００２は、該当するエントリを消去する。
【０１５４】
パケット受信時の処理において、実施の形態１〜３と異なる部分について記載する。
引渡し先判定部３０５では、入力されたパケットのＳＯＵＲＣＥ ＡＤＤＲＥＳＳ（３４１１）、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ（３４１２）およびＩＤ（３４０５）の情報の組み合わせと一致する情報の組を有するエントリを検索し特定する。特定したエントリの宛先ポート番号１６０７から読み出した宛先ポート番号と、パケットとを、引渡し部３０６へ出力する。
【０１５５】
このとき、第１プロトコル配送不可フラグ２１０１または、第２プロトコル配送不可フラグ２１０２の値も併せて、引渡し部３０６に出力する。
【０１５６】
引渡し部３０６では、宛先ポート番号に該当する通信プロトコル部への通信パスにパケットの振り分けを行なう。
【０１５７】
具体的には、第１プロトコル配送不可フラグ２１０１の値が配送不可になっており、かつ、振り分けるべき通信パスが通信パスＢ、つまりパケットの宛先が第１通信プロトコル部１０２である場合、そのパケットは廃棄する。同様に、第２プロトコル配送不可フラグ２１０２の値が配送不可になっており、かつ、振り分けるべき通信パスが通信パスＤ、つまりパケットの宛先が第２通信プロトコル部１２２である場合、そのパケットは廃棄する。
【０１５８】
このように、実施の形態４によれば、先頭パケットが到着した時点で既にタイムアウトが発生している通信プロトコル部へは、ＩＰフラグメントパケットを引き渡さない。したがって、無駄なコピー処理と通信処理を行わず、処理負荷を低減することができる。
【０１５９】
＜実施の形態５＞
本発明の実施の形態５として、第１通信プロトコル部１０２のタイマ値を自動的に測定するための形態を説明する。
【０１６０】
本発明の実施の形態５について、図２０を用いて説明する。
図２０は、実施の形態５におけるフラグメント制御部１１０およびＩＣＭＰ監視部１１２の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０１６１】
図２０に示すように、実施の形態５におけるフラグメント制御部１１０およびＩＣＭＰ監視部１１２は、実施の形態３におけるフラグメント制御部１１０にＴＭＯ測定開始部２２０１が追加され、ＩＣＭＰ監視部１１２にＴＭＯパケット判定部３１１とＴＭＯ測定完了部２２０２とが追加された構成となっている。
【０１６２】
ＡＶデータ送信装置１０およびＡＶデータ受信装置１３の高速伝送用装置１２がＴＭＯ測定開始部２２０１とＴＭＯ測定完了部２２０２を備えることにより、ＡＶデータ送信装置１０においてはホスト装置１１の、ＡＶデータ受信装置１３においてはホスト装置１１のタイマ値の測定が可能となる。
【０１６３】
ＴＭＯ測定開始部２２０１と、ＴＭＯ測定完了部２２０２の動作について説明する。なお、ＴＭＯ測定開始部２２０１は、本発明のデータ通信装置におけるダミーパケット出力手段の一例である。また、ＴＭＯ測定開始部２２０１とＴＭＯ測定完了部２２０２とにより、本発明のデータ通信装置におけるタイムアウト計測手段は実現される。
【０１６４】
まず、ＴＭＯ測定開始部２２０１は、ダミーの先頭フラグメントパケットを作成し、通信パスＢへ送信する。つまり第１通信プロトコル部１０２に対して送信する。
【０１６５】
この時、ＴＭＯ測定開始部２２０１は、内部でタイマを起動する。その後、任意の時間が経過すると、先頭フラグメントのみを受け取った第１通信プロトコル部１０２は、フラグメントの再構築に失敗するので、ＩＰの規格に従い、フラグメントタイムアウト用のＩＣＭＰエラーメッセージ（ＴｉｍｅＥｘｃｅｅｄｅｄ ｃｏｄｅ＝１）を送信する。ＴＭＯ測定完了部２２０２は、このＩＣＭＰエラーメッセージを通信パスＢを介して、受け取る。
【０１６６】
ＴＭＯ測定完了部２２０２は、フラグメントタイムアウト用のＩＣＭＰエラーメッセージ（ＴｉｍｅＥｘｃｅｅｄｅｄ ｃｏｄｅ＝１）であるかをまずチェックし、フラグメントタイムアウト用のＩＣＭＰエラーメッセージである場合、ＤＡＴＡ３６０５の内容を解析する。実施の形態２の説明で述べたように、その格納されている情報が図５（ａ）に示すＩＰヘッダフォーマットであり、ＤＡＴＡ３４１４内に、図１２（ａ）および図１２（ｂ）に示したＴＣＰヘッダまたはＵＤＰヘッダのフォーマットが格納されていた場合、その、ＳＯＵＲＣＥ ＡＤＤＲＥＳＳ３４１１、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ３４１２およびＩＤ３４０５の情報を参照する。これらの情報が、ダミーの先頭フラグメントパケットの情報と一致した場合、ＴＭＯ測定開始部２２０１に対して、測定完了を示す通知を行う。なお、通知の方法は、信号でも、割込みでも、コマンドでもよい。
【０１６７】
ＴＭＯ測定開始部２２０１は、測定完了を示す通知を受け取ると、ダミーの先頭フラグメントパケットを送信した際に起動したタイマを停止する。さらに、ダミーの先頭フラグメントパケットを送信してから測定完了を示す通知を受け取るまでにかかった時間を、第１通信プロトコル部１０２のタイマ値として、タイマ設定部１９０１に渡す。
【０１６８】
実施の形態５によれば、第１通信プロトコル部１０２のタイマ値を、自動的に測定することができる。一般に、高速伝送用装置は、その用途として、さまざまなＡＶネットワーク機器のホスト装置と接続することが求められるが、ホスト装置に一切手を加えることなく、具体的にはホスト装置にタイマ値を高速伝送用装置に通知する機能を追加することなく、ホスト装置のタイマ値を取得して、動作することができる。
【０１６９】
つまり、ホスト装置に、機能を無駄に追加することなく、ホスト装置側のタイマ値を高速伝送用装置が知ることができる。
【０１７０】
＜実施の形態６＞
本発明の実施の形態６として、バッファ３０９の空き容量が少なくなった場合であっても後続パケットを廃棄することなく通信を継続するための形態を説明する。
【０１７１】
本発明の実施の形態６について、図２１および図２２を用いて説明する。
図２１は、実施の形態６におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである
実施の形態６におけるフラグメント制御部１１０は、図２１に示すように、図１０に示す実施の形態１におけるフラグメント制御部１１０の構成にバッファ量監視部２３０１とパケット複製制御部２３０２とが加えられた構成である。
【０１７２】
なお、バッファ量監視部２３０１は、本発明のデータ通信装置における容量検出手段の一例であり、パケット複製制御部２３０２は、本発明のデータ通信装置におけるパケット複製手段の一例である。
【０１７３】
図２２は、実施の形態６における制御情報記憶部３０７に記憶されている制御情報のデータ構成の一例を示す図である。
【０１７４】
この制御情報は、バッファ量監視部２３０１、パケット複製制御部２３０２、および引渡し先判定部２３０３によって使用される情報である。
【０１７５】
各エントリに含まれる強制通信フラグ２４０５には、そのエントリに対応する後続パケットが、先頭パケットの到着を待たずに、第１通信プロトコル部１０２および第２通信プロトコル部１２２へ送信された場合、強制通信を示すフラグ値が登録される。
【０１７６】
強制通信フラグ２４０５の登録および、後続パケットの送信は、バッファ量監視部２３０１、パケット複製制御部２３０２、および引渡し先判定部２３０３によって行なわれる。
【０１７７】
まず、バッファ量監視部２３０１の動作について説明する。
後続パケット判定部３０３により、先頭パケットが未受信であると判定された後続パケットはバッファ量監視部２３０１に渡される。この後続パケットを受けたバッファ量監視部２３０１は、この後続パケットのパケット長を検出し、バッファ３０９の空き容量と比較する。
【０１７８】
このとき“パケット長≦バッファ３０９の空き容量”であれば、後続パケットをバッファ３０９に格納する。また、“パケット長＞バッファ３０９の空き容量”であれば、バッファ３０９に格納することなくパケット複製制御部２３０２に出力する。さらに、制御情報記憶部３０７に登録時刻２４０１、フラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４の各情報を登録する。
【０１７９】
次に、パケット複製制御部２３０２の動作について説明する。
受信した後続パケットをバッファ３０９に格納できないために、パケット複製制御部２３０２は、バッファ量監視部２３０１から受け取った後続パケットを保持し、バッファ３０９に格納されている後続パケットを、格納された順番に取り出す。さらに、取り出した後続パケットを通信プロトコル部の数だけ複製する。つまり、本実施の形態においては１つの後続パケットを２つに複製する。複製した後続パケットを引渡し先判定部２３０３に出力する。さらにこのとき、取り出した後続パケットに対するエントリの強制通信フラグ２４０５に強制通信を示すフラグを設定する。なお、バッファ３０９に格納された順番の判断には、制御情報の登録時刻２４０１が用いられる。
【０１８０】
この処理を“バッファ量監視部２３０１から受信した後続パケットのパケット長≦バッファ３０９の空き容量”が成立するまで行う。その後、受信した後続パケットをバッファ３０９へ格納し、制御情報記憶部３０７に、登録時刻２４０１、フラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４の全ての情報が一致するエントリが無ければ新しいエントリとして登録する。
【０１８１】
次に、引渡し先判定部２３０３の動作について説明する。
パケット複製制御部２３０２から後続パケットを受け取った引渡し先判定部２３０３は、制御情報記憶部３０７から、その後続パケットに対応するエントリ情報を読み出す。このとき強制通信フラグ２４０５に強制通信を示すフラグ値が設定されていれば、受け取った後続パケットと、全ての通信パスに対してその後続パケットを送信する要求とを引渡し部３０６へ出力する。本実施の形態においては、引渡し部３０６は、同一の後続パケットを２つずつ受け取ることになり、その後続パケットを、第１通信プロトコル部１および第２通信プロトコル部２に１つずつ送信する。
【０１８２】
つまり、強制通信フラグ２４０５に強制通信を示すフラグ値が設定されたエントリに対応する後続パケットは、第１通信プロトコル部１および第２通信プロトコル部２へ送信されることとなる。
【０１８３】
また、先頭パケット判定部３０２、後続パケット判定部３０３からフラグメントパケットを受け取った場合の引渡し先判定部３０５は、前述した実施の形態１〜５の手順に従って動作する。
【０１８４】
このように、実施の形態６によれば、複数のフラグメントされたＩＰフラグメントパケットを受信し、かつ、それぞれのＩＰフラグメントパケットの先頭パケットを受信しない状態が続く場合など、バッファ３０９の空き容量が少なくなった場合であっても、後続パケットを破棄することなく通信を継続することができる。また各通信プロトコル部に最低限のバッファを使用するだけで通信を継続することが可能となる。
【０１８５】
なお、本実施の形態で示した、パケット複製制御部２３０２が行う制御情報記憶部３０７への登録時刻２４０１、フラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４の登録処理を先頭パケット判定部で行っても良い。また、前述したエントリの登録時刻２４０１は、登録した順番が分かるものであれば、例えばシーケンス番号でも良い。
【０１８６】
＜実施の形態７＞
本発明の実施の形態７として、バッファ３０９の空き容量が少なくなった場合に、強制通信の対象となった後続パケットに対応する後続パケットを、バッファ３０９から読み出して優先的に通信プロトコル部へ送信するための形態について説明する。
【０１８７】
本発明の実施の形態７について、図２３を用いて説明する。
図２３は、実施の形態７におけるパケット複製制御部２３０２の動作の流れを示すフローチャートである。
【０１８８】
なお、実施の形態７におけるフラグメント制御部１１０の機能ブロックの構成および制御情報のデータ構成は、実施の形態６と同じであり、それぞれ図２１および図２２に示したものである。
【０１８９】
実施の形態７におけるパケット複製制御部２３０２は、バッファ３０９から後続パケットを取り出す際に強制通信フラグ２４０５に設定された値を参照し、取り出す後続パケットを選択することを特徴とする。
【０１９０】
なお、バッファ３０９から後続パケットを取り出す際の選択方法以外は、実施の形態６と同様の動作であるため、その差分を中心に説明する。
【０１９１】
まず、実施の形態６で示すように、受信した後続パケットがバッファ３０９に格納できない場合は、バッファ量監視部２３０１からパケット複製制御部２３０２へ後続パケットが渡される。
【０１９２】
次に、パケット複製制御部２３０２は制御情報記憶部３０７に登録されているエントリで強制通信フラグ２４０５に強制通信を示すフラグ値が設定されているものがあるかを検索する。
【０１９３】
強制通信を示すフラグ値が設定されたエントリがあれば（Ｓ２５０１でＹｅｓ）、そのエントリに対応する後続パケット、つまりエントリに含まれるフラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４の情報が一致する後続パケットを検索する（Ｓ２５０６）。
【０１９４】
一致する後続パケットがある場合（Ｓ２５０７でＹｅｓ）、その後続パケットをバッファ３０９から取り出し、引渡し先判定部へ出力する（Ｓ２５０８）。この処理を“バッファ量監視部２３０１から受信した後続パケットのパケット長≦バッファ３０９の空き容量”が成立するまで行う（Ｓ２５０９でＮｏ）、バッファ３０９の空き容量が上記条件を満たすまでになった場合（Ｓ２５０９でＹｅｓ）、受信した後続パケットをバッファ３０９へ格納する。さらに、制御情報記憶部３０７に登録時刻２４０１、フラグメントＩＤ２４０２、送信元ＩＰアドレス２４０３、宛先ＩＰアドレス２４０４を登録する。
【０１９５】
実施の形態７では、強制通信を示すフラグ値が設定されたエントリが無い場合（Ｓ２５０１でＮｏ）、または、強制通信を示すフラグが設定されたエントリはあるが、そのエントリに対応する後続パケットが無い場合（Ｓ２５０７でＮｏ）は、制御情報記憶部３０７に登録されたエントリの中から最も古い登録時刻をもつエントリ（以下、「最古のエントリ」という。）を検索する（２５０２）。パケット複製制御部２３０２は、最古のエントリを検出すると、最古のエントリの強制通信フラグ（２４０５）に強制通信を示すフラグ値を設定する。以降の動作は実施の形態６に従うものとする。
【０１９６】
このように、実施の形態７によれば、各通信プロトコル部に対し、強制通信を示すフラグ値が設定されたエントリに対応する後続パケットを優先的に送信することが可能である。つまり、実施の形態６と同様に、後続パケットを破棄することなく、かつ、バッファを効率よく使用することが可能となる。さらに、各通信プロトコル部は複数のフラグメントされたＩＰフラグメントパケットを受信処理している状態であっても、優先的に送られるフラグメントパケットの再構築処理のみを行うだけでよく、再構築処理にかかるオーバーヘッドを抑制できる。
【０１９７】
＜実施の形態８＞
本発明の実施の形態８として、バッファ３０９の空き容量が少なくなった場合に、より多くのバッファ３０９の空き容量を確保するための形態について説明する。
【０１９８】
本発明の実施の形態８について、図２４を用いて説明する。
図２４は、実施の形態８におけるパケット複製制御部２３０２の動作の流れを示すフローチャートである。
【０１９９】
なお、実施の形態８におけるフラグメント制御部１１０の機能ブロックの構成および制御情報のデータ構成は、実施の形態６および７と同じであり、それぞれ図２１および図２２に示したものである。
【０２００】
実施の形態８におけるパケット複製制御部２３０２は、図２４に示すように、バッファ３０９から後続パケットを取り出す際に、後続パケットのサイズを考慮して取り出す後続パケットを選択することを特徴とする。
【０２０１】
なお、実施の形態８では、バッファ３０９から後続パケットを取り出す際の選択方法以外は、実施の形態７と同様の動作であるため、その差分のみを説明する。
【０２０２】
本実施の形態では、実施の形態７において制御情報記憶部３０７に登録されているエントリの強制通信フラグ２４０５に強制通信を示すフラグ値が設定されているものが無い場合（Ｓ２５０１でＮｏ）のバッファ３０９の有効な使用方法を示す。
【０２０３】
この場合、制御情報記憶部３０７に登録されているエントリの中で、バッファ３０９に格納されている後続パケットの合計サイズが、最も大きなエントリを選択する（Ｓ２６０１）。
【０２０４】
つまり、実施の形態７では、バッファ３０９に格納されている後続パケットのうち、最古のエントリに対応する後続パケットを強制通信の対象とするのに対し、実施の形態８では、合計サイズが最大となるエントリに対応する後続パケットを強制通信の対象としている。
【０２０５】
このように、実施の形態８によれば、バッファ３０９の空き容量が少なくなった際、フラグメント制御部１１０内のバッファ３０９から一度に大量の後続パケットを取り出し、各通信プロトコル部へ送信することが可能となる。その結果、バッファ３０９からより多くの空き容量を確保することが可能となり、より多くの後続パケットを格納することが可能となる。つまり、実施の形態７よりもバッファを効率よく使用することができる。
【０２０６】
なお、フラグメント制御部１１０は、実施の形態７の特徴と実施の形態８の特徴とを併せ持ってもよい。例えば、バッファ３０９の空き容量が少なくなり、かつ、強制通信の対象となった後続パケットがない場合、まず、合計サイズが最大となるエントリを検索する。この検索の結果、同一のサイズとなるエントリが複数あった場合、最古のエントリを選択し、そのエントリに対応する後続パケットを強制通信の対象としてもよい。
【０２０７】
こうすることで、さらに、バッファ３０９の使用における効率化を向上させることが可能となる。
【０２０８】
＜実施の形態９＞
本発明の実施の形態９として、各通信プロトコル部のパケットの再構築処理に係る負担を軽減させるための形態を説明する。
【０２０９】
本発明の実施の形態９について、図２５を用いて説明する。
図２５は、実施の形態９におけるフラグメント制御部１１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、フラグメント制御部１１０の機能以外の機能を表す機能ブロックである。
【０２１０】
図２５に示すように、実施の形態９におけるフラグメント制御部１１０は、図１０に示す実施の形態１におけるフラグメント制御部１１０の構成に順序制御部２７０１が加えられた構成である。順序制御部２７０１は、本発明のデータ通信装置における整列手段の一例である。
【０２１１】
実施の形態９では、先頭パケット判定部３０２から引渡し先判定部３０５へＩＰフラグメントパケットを送信するときの方法以外は、実施の形態１と同様の動作である。そのため、実施の形態１との差分を中心に説明する。
【０２１２】
実施の形態１に示す先頭パケット判定部３０２では、入力された受信パケットが先頭パケットであるかどうかを判断し、先頭パケットだった場合、制御情報記憶部３０７の情報を参照し、その先頭パケットに対応する後続パケットがバッファ３０９に格納されているかを確認する。該当する後続パケットがある場合には受信した先頭パケットと、該当する後続パケットを引渡し先判定部３０５へ送信するという動作を行う。
【０２１３】
しかし、このとき引渡し先判定部３０５に送信される先頭パケットおよび後続パケットは、フラグメント再構築に適した順番となる保証は無く各通信プロトコル部は順不同で受け取るフラグメントパケットを再構築しなければならない。
【０２１４】
そこで、図２５に示す順序制御部２７０１では、先頭パケット判定部３０２から受け取った先頭パケットおよび後続パケットを、ＩＰフラグメントパケットの並び順を示すＯＦＦＳＥＴ３４０７の値で昇順に整列し、引渡し先判定部へ通信する。
このように、実施の形態９によれば、フラグメント制御部１１０がフラグメントパケットを順不同で受信した場合でも、先頭パケットを含む受信済みの全ての後続パケットを正しく並べ替えたうえで、各通信プロトコル部に送信することが可能となる。これにより、各通信プロトコル部におけるパケットの再構築処理に係る負担を軽減することが出来る。
【０２１５】
＜実施の形態１０＞
本発明の実施の形態１０として、ＩＣＭＰエラーパケットの処理に係る負担を低減することのできる形態について説明する。
【０２１６】
本発明の実施の形態１０について、図２６〜図２８を用いて説明する。
図２６は、実施の形態１０におけるＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０２１７】
図２６に示すように、実施の形態１０のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、図１に示した従来のＡＶデータ送信装置１０およびＡＶデータ受信装置１３と比較すると、パケット振り分け部１２４内に、ＩＣＭＰ制御部５１０を持つことを特徴とする。ＩＣＭＰ制御部５１０は、受信したＩＣＭＰエラーメッセージパケットを効率的に処理する処理部である。
【０２１８】
図２７は、実施の形態１０におけるＩＣＭＰ制御部５１０の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、ＩＣＭＰ制御部５１０の機能以外の機能を表す機能ブロックである。
【０２１９】
ＩＣＭＰ制御部５１０は、図１６に示したパケットフォーマットのＩＣＭＰエラーメッセージパケットを受信する。
【０２２０】
図１６に示す、ＩＣＭＰエラーメッセージパケットのＤＡＴＡ３６０５には、エラーの発生したパケットにおけるＩＰヘッダとＩＰヘッダに続くデータの先頭６４ビットが格納される。したがって、エラーの発生したパケットがＴＣＰパケットまたはＵＤＰパケットであった場合、図１２（ａ）に示すＴＣＰヘッダにおける送信元ポート番号３５０１および宛先ポート番号３５０２、または、図１２（ａ）に示すＵＤＰヘッダにおける送信元ポート番号３５１３および宛先ポート番号３５１４が含まれる。
【０２２１】
ＩＣＭＰ制御部５１０は、このＩＣＭＰエラーメッセージパケットのＤＡＴＡ３６０５に格納されている情報を利用して、ＩＣＭＰエラーメッセージパケットを適切な出力先に出力することができる。
【０２２２】
なお、常に、ＤＡＴＡ３６０５にエラーパケットの情報が格納されているのではなく、ＩＣＭＰエラーメッセージパケットに含まれるエラーメッセージの種類を示す情報によりエラーパケットの情報が格納されているか否かを判定することができる。
【０２２３】
図２８は、ＩＣＭＰエラーメッセージパケットのＤＡＴＡ３６０５にエラーパケットの情報が格納される場合の代表的なＩＣＭＰエラーメッセージの種類を示す図である。
【０２２４】
図２８に示す“タイプ”および“コード”は、図１６に示すフォーマットのタイプ３６０１およびコード３６０２のそれぞれに格納されている。
【０２２５】
なお、エラーメッセージ以外のメッセージを通知するためのＩＣＭＰパケットも図１６に示すパケットフォーマットと同じフォーマットである。ＩＣＭＰパケットがＩＣＭＰエラーメッセージパケットであるか否かは、そのＩＣＭＰパケットのタイプ３６０１に格納されている値により判定可能である。
【０２２６】
図２８に示すタイプ“３”、“１１”、および“１２”は、ＩＣＭＰパケットがＩＣＭＰエラーメッセージパケットであると判定されるタイプの例である。この判定は、ＩＣＭＰ判定部６０１により行われる。
【０２２７】
さらに、コード３６０２に格納されている値により、ＤＡＴＡ３６０５にエラーパケットの情報が格納されているか否かの判断が可能である。
【０２２８】
図２８に示す“０”から“１５”までのコードは、ＤＡＴＡ３６０５にエラーパケットの情報が格納されていると判定されるコードの例である。この判定は、エラーパケット判定部６０２により行われる。
【０２２９】
ＩＣＭＰ制御部５１０の動作について説明する。
まず、送受信部１２３がネットワークからパケットを受信すると、ＩＣＭＰ判定部６０１へ受信パケットが入力される。
【０２３０】
ＩＣＭＰ判定部６０１は、ＩＣＭＰパケットであるか否かを判定する。判定の結果、ＩＣＭＰパケットでない場合、パケット振り分け部１２４ａへと受信パケットを出力する。出力されたパケットは、パケット振り分け部１２４ａの処理により適切な通信パスへと振り分けられる。また、判定の結果、ＩＣＭＰパケットであった場合、エラーパケット判定部６０２へ出力する。
【０２３１】
エラーパケット判定部６０２は、入力されたＩＣＭＰパケットのタイプ３６０１からＩＣＭＰパケットがＩＣＭＰエラーメッセージパケットであるか否かを判定する。判定の結果、ＩＣＭＰエラーメッセージパケットでなかった場合、パケット複製部６０５に出力する。また、判定の結果、エラーパケットであった場合、入力されたＩＣＭＰパケットのコード３６０２からＤＡＴＡ３６０５にエラーパケット情報が格納されているか否かを判定する。
【０２３２】
上述のように、図２８に示すタイプおよびコードは、ＩＣＭＰパケットがＩＣＭＰエラーメッセージパケットであり、かつ、ＤＡＴＡ３６０５にエラーパケット情報が格納されていることを示すタイプおよびコードの例である。
【０２３３】
ＤＡＴＡ３６０５にエラーパケット情報が格納されていない場合、パケット複製部６０５に出力する。ＤＡＴＡ３６０５にエラーパケット情報が格納されている場合、ＴＣＰヘッダまたはＵＤＰヘッダが格納されているかを判定する。さらに、ＴＣＰヘッダまたはＵＤＰヘッダに含まれるパケットの送信元ポート番号と第２通信プロトコル部１２２が使用しているポート番号とを照合する。
【０２３４】
照合の結果、一致した場合、このＩＣＭＰエラーメッセージパケットの出力先は第２通信プロトコル部１２２であると判定する。また、照合の結果、一致しなかった場合、このＩＣＭＰエラーメッセージパケットの出力先は第１通信プロトコル部１０２であると判定する。
【０２３５】
なお、第２通信プロトコル部１２２が使用しているポート番号の情報は、パケット振り分け部１２４の所定の記憶領域に保持されている。
【０２３６】
そして、ＩＣＭＰエラーメッセージパケットと、その出力先を示す情報とを引渡し部６０４へ出力する。
【０２３７】
引渡し部６０４は、入力されたＩＣＭＰエラーメッセージパケットを、入力された出力先を示す情報に従って、出力すべき通信パスへ振り分ける。
【０２３８】
なお、パケット複製部６０５は、入力されたＩＣＭＰパケットを複製し、第１通信プロトコル部１０２および第２通信プロトコル部１２２の双方へ出力する指示とともに、２つのＩＣＭＰパケットを引渡し部６０４へ出力する。
【０２３９】
引渡し部６０４は、入力された２つのＩＣＭＰパケットを入力された指示に従って、通信パスＢおよび通信パスＣへ出力する。
【０２４０】
このように、エラーパケット判定部６０２と引渡し部６０４とにより、本発明のデータ通信装置におけるエラー出力手段が実現される。また、パケット複製部６０５と引渡し部６０４とにより、本発明のデータ通信装置におけるエラー複製手段が実現される。
【０２４１】
実施の形態１０によれば、従来のＩＣＭＰ複製部で行っていたパケットの複製を、複製が必要なＩＣＭＰエラーメッセージパケットのみに行うことが可能となる。
【０２４２】
これにより、パケットの複製処理にともなう負荷を低減することができる。さらに、従来では、第１通信プロトコル部１０２でのデータ通信にエラーが多発した際、ＩＣＭＰエラーメッセージパケットは、第２通信プロトコル部１２２にも出力されることとなる。つまり、第２通信プロトコル部１２２では無関係のエラーパケットを処理しなければならず、第２通信プロトコル部１２２を使ったデータ通信の転送レートを劣化させる影響を及ぼしていた。
【０２４３】
本実施の形態によれば、第１通信プロトコル部１０２宛のＩＣＭＰエラーメッセージパケットによる第２通信プロトコル部１２２への影響を最低限のものにすることができる。
【０２４４】
＜実施の形態１１＞
本発明の実施の形態１１は、第１通信プロトコル部１０２を使用するアプリケーションプログラムのポート番号と、第２通信プロトコル部１２２を使用するアプリケーションプログラムのポート番号との排他制御に関する形態について説明する。
【０２４５】
本発明の実施の形態１１について、図２９および図３０を用いて説明する。
図２９は、実施の形態１１におけるＡＶデータ送信装置１０とＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０２４６】
図２９に示すように、ＡＶデータ受信装置１３のホスト装置１４にポート予約制御部８０１を持つことを特徴とする。
【０２４７】
ポート予約制御部８０１は、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号を第１通信プロトコル部に登録する処理部である。
【０２４８】
図３０は、実施の形態１１におけるポート予約制御部８０１の機能的な構成を示す機能ブロック図である。図３０を用いてポート予約制御部８０１の構成および動作について説明する。ポート番号確定部９０３は、ＡＶデータの伝送を行うクライアントアプリケーションプログラムであるＡＶ伝送クライアントＡＰＰ１０７からの接続要求を受け取る。接続要求を受け取ると、ポート番号（Ｘ）を確定する。ポート番号（Ｘ）はＯＳから提供されるサービスコールの時間管理機能（ＧＥＴ＿ＴＩＭ）で取得した値を使用してランダムに確定する。なお、ポート番号確定部９０３は本発明のデータ通信装置におけるポート番号決定手段の一例である。
【０２４９】
このポート番号（Ｘ）は０〜６５５３５の範囲の未使用ポート番号の中からランダムに確定される。ポート番号確定部９０３は、その確定したポート番号（Ｘ）をポート番号登録部９０２へ出力する。
【０２５０】
なお、このポート番号（Ｘ）はランダム関数で確定してもよい。また、未使用のポート番号を順に検索して使用してもよい。
【０２５１】
一般的なことであるが、ポート番号（Ｘ）の登録はソケットが提供するＡＰＩを使用して行なう。使用するＡＰＩは、ＳＯＣＫＥＴ、ＢＩＮＤ、ＣＯＮＮＥＣＴ、およびＣＬＯＳＥＳＯＣＫＥＴである。ＳＯＣＫＥＴはソケットを生成、ＢＩＮＤはソケットのポート番号や通信方式を登録、ＣＯＮＮＥＣＴはサーバに接続要求を行って通信回線を確立、ＣＬＯＳＥＳＯＣＫＥＴは通信回線を切断してソケットを閉じる役割を持つ。
【０２５２】
ポート番号登録部９０２はＳＯＣＫＥＴを使用し、第１Ｉ／Ｆ部１０１とのソケットを生成する。次に、ＢＩＮＤを使用し、確定したポート番号（Ｘ）を第１Ｉ／Ｆ部１０１へ登録する。
【０２５３】
第１Ｉ／Ｆ部においてポート番号（Ｘ）が使用中である場合、第１Ｉ／Ｆ部１０１はポート番号登録部９０２に登録失敗を示す情報を返す。ポート番号登録部９０２はＡＶ伝送クライアントＡＰＰ１０７へ接続エラー通知を行う。
【０２５４】
第１Ｉ／Ｆ部においてポート番号（Ｘ）が未使用の場合、第１Ｉ／Ｆ部１０１はポート番号登録部９０２に登録成功を示す情報を返す。ポート番号登録部９０２は第２Ｉ／Ｆ部１２１に対してＳＯＣＫＥＴおよびＣＯＮＮＥＣＴを使用し、ポート番号（Ｘ）を使用して接続要求を行う。
【０２５５】
また、第２Ｉ／Ｆ部１２１から切断通知を受けると、ポート番号削除部９０１はＣＬＯＳＥＳＯＣＫＥＴを使用して、第１Ｉ／Ｆ部１０１から使用ポート番号（Ｘ）を削除する。その後、ポート番号削除部９０１はＡＶ伝送クライアントＡＰＰ１０７に対して切断通知を行う。
【０２５６】
このように、実施の形態１１によれば、第１Ｉ／Ｆ部１０１へ使用ポート番号（Ｘ）を登録することで、第１Ｉ／Ｆ部１０１を改変せずに、ＡＶ伝送クライアントＡＰＰ１０７が使用するポート番号と、第１Ｉ／Ｆ部１０１を使用するクライアントＡＰＰ１０８等のポート番号との排他制御が可能となる。
【０２５７】
なお、本実施の形態はＡＶ伝送サーバＡＰＰ１０４がウェルノウンポート以外（１０２４〜６５５３５）で通信する場合にも適用できる。
【０２５８】
＜実施の形態１２＞
本発明の実施の形態１２として第１通信プロトコル部に対するポート番号の予約を確実に行なうための形態について説明する。
【０２５９】
本発明の実施の形態１２について、図３１を用いて説明する。
図３１は、実施の形態１２におけるポート予約制御部８０１の機能的な構成を示す機能ブロック図である。
【０２６０】
図３１に示すように、実施の形態１２におけるポート予約制御部８０１は、図３０に示した実施の形態１２におけるポート予約制御部８０１が有する構成に加え、繰り返し要求部２８０３を有することを特徴とする。繰り返し要求部２８０３は、本発明のデータ通信装置における繰り返し制御手段の一例であり、第１Ｉ／Ｆ部１０１に対して、ポート番号の登録の要求を繰り返し行なう処理部である。
【０２６１】
実施の形態１２では、ポート番号登録部２８０１とポート番号確定部２８０２と繰り返し要求部２８０３の動作以外は、実施の形態１１と同様の動作であるため、その差分のみを説明する。
【０２６２】
ポート番号登録部２８０１は第１Ｉ／Ｆ部１０１へのポート番号（Ｘ）の登録に失敗した場合、繰り返し要求部２８０３に対して接続エラー通知を行う。
【０２６３】
繰り返し要求部２８０３はポート番号登録部２８０１から接続エラー通知を受けると、ポート番号確定部２８０２に新たなポート番号の登録要求を行う。繰り返し要求部２８０３は繰り返し回数（Ｎ回）の制限機能を備え、ポート番号の登録に失敗し続けた場合に要求を無限に繰り返さないようにする。
【０２６４】
繰り返し要求部２８０３は、接続エラー通知を受けた回数が繰り返し回数（Ｎ回）未満の場合、繰り返し要求部２８０３はポート番号確定部２８０２へ新たなポート番号の登録の要求を行う。接続エラー通知を受けた回数が繰り返し回数（Ｎ回）に達した場合、繰り返し要求部２８０３はＡＶ伝送クライアントＡＰＰ１０７にエラー通知を行う。
【０２６５】
このように、実施の形態１２によれば、ポート予約制御部８０１に繰り返し要求部２８０３を設けることで第１Ｉ／Ｆ部１０１へのポート番号の登録を繰り返し行うことができる。したがって、ポート番号確定部２８０２が、第１Ｉ／Ｆ部１０１においてすでに使用されていたポート番号を選択してしまった場合でも、異なるポート番号に変えて再登録を繰り返す。そのため、偶発的に発生するポート番号の衝突により、ポート番号の予約が失敗に終わることを回避することができ、実質的に、第１Ｉ／Ｆ部１０１に対するポート番号の予約を確実なものにすることができる。
【０２６６】
尚、本実施の形態で示した、繰り返し要求部（２８０３）の繰り返し制限は期間（例えば、Ｍ秒間）で行ってもよい。また、ＡＶ伝送クライアントＡＰＰ１０７が接続要求を行なうとともに回数または期間を指定する構成でもよい。
【０２６７】
尚、本実実施の形態はＡＶ伝送サーバＡＰＰ１０４がウェルノウンポート以外（１０２４〜６５５３５）で通信する場合にも使用できる。
【０２６８】
＜実施の形態１３＞
本発明の実施の形態１３として、通信先の機器の物理アドレスの解決を効率的に行なうことができる形態について説明する。
【０２６９】
本発明の実施の形態１３について、図３２〜図３５を用いて説明する。
図３２は、実施の形態１３のＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０２７０】
図３２に示すように、実施の形態１３のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、高速伝送用装置１２の送受信部１２３にＡＲＰ監視制御部１００１を持つことを特徴とする。
【０２７１】
ＡＲＰ監視制御部１００１は、通信先の機器の物理アドレスの解決を要求およびその応答であるＡＲＰ要求パケットおよびＡＲＰ応答パケットの送受信を監視し、ＡＲＰ応答パケット受信した場合に適切な出力先に出力する処理部である。
【０２７２】
図３３は、実施の形態１３におけるＡＲＰ監視制御部１００１の機能的な構成を示す機能ブロック図である。なお、図中のパケット振分け部１２４ａは、パケット振分け部１２４が有する、ＡＲＰ監視制御部１００１の機能以外の機能を表す機能ブロックである。
【０２７３】
なお、ＡＲＰ要求パケット判定部１２０１は、本発明のデータ通信装置におけるＡＲＰ要求受付手段の一例であり、ＡＲＰ応答パケット判定部１２０４は、本発明のデータ通信装置におけるＡＲＰ応答受信手段とであり、引渡し部１２０６は、本発明のデータ通信装置における応答出力手段の一例である。
【０２７４】
ＡＲＰ監視制御部１００１は、通信パスＢまたは通信パスＤにより直接接続されている第１通信プロトコル部１０２または第２通信プロトコル部１２２からＡＲＰ要求パケットを受け取ると、そのＡＲＰ要求パケットに関する情報をＡＲＰ情報記憶部１２０３に記憶する。
【０２７５】
図３４は、実施の形態１３におけるＡＲＰ情報記憶部１２０３に記憶されたＡＲＰ情報のデータ構成例を示す図である。
【０２７６】
図３４に示すように、ＡＲＰ情報記憶部１２０３には、ＡＲＰ監視制御部１００１が受け取ったＡＲＰ要求パケットごとに、そのＡＲＰ要求パケットに関する情報が１つのエントリとして記憶されている。
【０２７７】
各エントリの通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２は、ＡＲＰ監視制御部１００１がＡＲＰ要求パケットを受け取った際、どちらの通信プロトコル部から送られてきたかを示す情報である。例えば、通信パスＢ要求ビット１３０１が立っている、つまり、通信パスＢ要求ビット１３０１が“１”である場合、そのエントリに対応するＡＲＰ要求パケットは、通信パスＢから送られてきたことを示す。ＡＲＰ要求パケットが通信パスＢから送られてきたということは、そのＡＲＰ要求パケットは第１通信プロトコル部１０２から送られてきたことを意味する。
【０２７８】
同様に、通信パスＤ要求ビット１３０２が“１”である場合は、そのＡＲＰ要求パケットは第２通信プロトコル部１２２から送られてきたことを意味する。通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２は、どちらか一方のみが“１”に設定される。
【０２７９】
ターゲットＩＰアドレス１３０３は、ＡＲＰ要求パケットの宛先のＩＰアドレスを示す情報である。ターゲットＩＰアドレス１３０３の後ろの“（１）”等はエントリ番号に対応している。ターゲットＩＰアドレスは、ＡＲＰ要求パケットに含まれる情報である。
【０２８０】
図３５は、ＡＲＰパケットのパケットフォーマットを示す図である。ＡＲＰ要求パケットおよびＡＲＰ応答パケットのパケットフォーマットは、図３５に示すパケットフォーマットである。
【０２８１】
図３５に示す探索ＩＰアドレス３７１２が、ＡＲＰパケットの宛先のＩＰアドレスである。つまり、図３４に示すＡＲＰ情報のエントリのターゲットＩＰアドレス１３０３には、ＡＲＰ要求パケットに含まれる探索ＩＰアドレス３７１２が格納される。
【０２８２】
ＡＲＰ監視制御部１００１の動作について説明する。
ＡＲＰ監視制御部１００１は通信パスＢまたは通信パスＤから送信パケットを受けると、ＡＲＰ要求パケット判定部１２０１へ送信パケットを入力する。ＡＲＰ要求パケット判定部１２０１では、送信パケットがＡＲＰ要求パケットかどうかを判定する。なお、ＡＲＰ要求パケットであるかどうかの判定方法は、一般的なＩＰプロトコルの仕様であるため記載は省略する。
【０２８３】
ＡＲＰ要求パケットでない場合、送受信部１２３へ送信パケットを出力する。ＡＲＰ要求パケットである場合、要求元判定部１２０２へ送信パケットを出力する。
【０２８４】
要求元判定部１２０２はＡＲＰ要求パケットの探索ＩＰアドレス３７１２を読み出し、ＡＲＰ要求パケットの送信元（以下、「ＡＲＰ要求元」という。）を判定する。判定後、ＡＲＰ情報記憶部１２０３へのエントリの登録を行なう。そのエントリのターゲットＩＰアドレス１３０３には探索ＩＰアドレス３７１２が記録され、通信パス要求ビットが設定される。
【０２８５】
具体的には、要求元判定部１２０２は、ＡＲＰ要求元が第１通信プロトコル部１０２の場合は通信パスＢ要求ビット１３０１を“１”に設定し、第２通信プロトコル部１２２の場合は通信パスＤ要求ビット１３０２を“１”に設定する。
【０２８６】
ＡＲＰ情報記憶部１２０３へのエントリの登録後、要求元判定部１２０２は送受信部１２３へＡＲＰ要求パケットである送信パケットを出力する。
【０２８７】
その後、ＡＲＰ監視制御部１００１は、ネットワークを介して送信され、送受信部１２３により受信された受信パケットを受け取る。受け取られた受信パケットはＡＲＰ応答パケット判定部１２０４へ入力される。ＡＲＰ応答パケット判定部１２０４は、受信パケットがＡＲＰ応答パケットであるか否かを判定する。なお、ＡＲＰ応答パケットであるかどうかの判定方法は、一般的なＩＰプロトコルの仕様であるため記載は省略する。受信パケットがＡＲＰ応答パケットでない場合、パケット振り分け部１２４ａへ受信パケットを出力する。受信パケットがＡＲＰ応答パケットである場合、応答出力先判定部１２０５へ受信パケットを出力する。
【０２８８】
応答出力先判定部１２０５では、ＡＲＰ応答パケットの送信元ＩＰアドレス３７１０とＡＲＰ情報記憶部１２０３に記憶されているターゲットＩＰアドレス１３０３とを比較し、一致しているエントリを探す。一致したエントリの通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２のどちらに“１”が設定されているかによりＡＲＰ応答パケットを出力すべき通信パスを判定する。
【０２８９】
判定後、応答出力先判定部１２０５は引渡し部１２０６に対して、判定した通信パスへＡＲＰ応答パケットを出力するように要求する。
【０２９０】
引渡し部１２０６は、応答出力先判定部１２０５から要求される出力先にＡＲＰ応答パケットを出力する。ＡＲＰ応答パケットは、通信パスＢに出力された場合は第１通信プロトコル部１０２に受け取られ、通信パスＤに出力された場合は第２通信プロトコル部１２２に受け取られる。
【０２９１】
このように、実施の形態１３では、パケット振り分け部１２４の内部にＡＲＰ監視制御部１００１が備えられる。さらに、ＡＲＰ監視制御部１００１が有するＡＲＰ情報記憶部１２０３にＡＲＰ要求パケットの宛先であるターゲットＩＰアドレスを示す情報とＡＲＰ要求元を示す情報とが対応付けられて記憶される。これにより、ＡＲＰ要求パケットに対する応答であるＡＲＰ応答パケットを適切に振り分けることが可能となる。
【０２９２】
結果として、ホスト装置１１およびホスト装置１４への機能の追加を行なうことなく、また、処理の負荷を増加させることなく、効率的に物理アドレスの解決を行なうことができる。さらに、ＡＶ伝送を行うアプリケーションプログラム（ＡＶ伝送サーバＡＰＰ１０４およびＡＶ伝送クライアントＡＰＰ１０７）が第１通信プロトコル部１０２を使用することなく、物理アドレスの解決を行うことができる。
【０２９３】
なお、要求元判定部２９０１が、ＡＲＰ要求元を判定する方法は、上述のＡＲＰ要求パケットのＰＲＯＴＯＣＯＬ３７０７の情報などを利用してもよい。また、例えば、どの通信パスからＡＲＰ要求パケットが送られてきたかの情報を、ＡＲＰ要求パケット判定部１２０１から受け取り、その情報を利用してもよい。
【０２９４】
＜実施の形態１４＞
本発明の実施の形態１４として、通信先の機器の物理アドレスの解決を効率的に行い、かつ、ネットワーク上の負荷を低減すことができる形態について説明する。
【０２９５】
本発明の実施の形態１４について図３６を用いて説明する。
図３６は、実施の形態１４におけるＡＲＰ監視制御部１００１の機能的な構成を示す機能ブロック図である。
【０２９６】
図３６に示すように、実施の形態１４におけるＡＲＰ監視制御部１００１は、図３３に示した実施の形態１３におけるＡＲＰ監視制御部１００１が有する構成に加え、パケット複製部２９０３を有することを特徴とする。なお、要求元判定部２９０１は、本発明のデータ通信装置におけるＡＲＰ要求元判定手段の一例であり、パケット複製部２９０３は、本発明のデータ通信装置におけるＡＲＰパケット複製手段の一例である。
【０２９７】
なお、実施の形態１４におけるＡＲＰ情報記憶部に１２０３記憶されているＡＲＰ情報のデータ構成は、図３４に示したデータ構成と同じである。また、実施の形態１４におけるＡＲＰ監視制御部１００１が扱うＡＲＰパケットのパケットフォーマットは、図３５に示したパケットフォーマットと同じである。
【０２９８】
実施の形態１４では、２つの通信プロトコル部から受け取ったＡＲＰ要求パケットのそれぞれの宛先が同一であった場合の要求元判定部２９０１、応答出力先判定部２９０２およびパケット複製部２９０３の動作以外は、実施の形態１３における各構成部の動作と同様の動作である。そのため、実施の形態１３との差分のみを説明する。
【０２９９】
要求元判定部２９０１は、ＡＲＰ要求パケット判定部１２０１から受け取ったＡＲＰ要求パケットに含まれる探索ＩＰアドレス３７１２が、ターゲットＩＰアドレス１３０３としてＡＲＰ情報記憶部１２０３にすでに登録されているか否かを確認する。登録されていた場合、新たにエントリを追加せず、その探索ＩＰアドレス３７１２がターゲットＩＰアドレス１３０３に記録されているエントリに、ＡＲＰ要求元に対応する通信要求ビットを設定する。つまり、通信パスＢ要求ビット１３０１または通信パスＤ要求ビット１３０２を“１”に設定する。また、ＡＲＰ要求パケットは送信せずに廃棄する。
【０３００】
例えば、第１通信プロトコル部１０２から、ＩＰアドレス“１１１．１１１．１１１．１１１”に対するＡＲＰ要求パケットが送信され、その応答が帰ってくる前に、第２通信プロトコル部１２２から、同じＩＰアドレス“１１１．１１１．１１１．１１１”に対するＡＲＰ要求パケットが送信された場合を想定する。
【０３０１】
この場合、第１通信プロトコル部１０２および第２通信プロトコル部１２２は、ともに同じ機器の物理アドレスの解決を要求している。従って、先に送信されたＡＲＰ要求パケットのみを宛先に送信し、その応答を第１通信プロトコル部１０２だけでなく第２通信プロトコル部１２２にも送信すればよい。
【０３０２】
そこで、先に送信されたＡＲＰ要求パケットに対応するＡＲＰ応答パケットを第２通信プロトコル部１２２にも送信するために、要求元判定部２９０１は、先に送信されたＡＲＰ要求パケットに対応するエントリの通信パスＤ要求ビット１３０２も“１”に設定する。
【０３０３】
ＡＲＰ応答パケットが両方の通信プロトコル部に送信される際の各処理部の動作は以下のようになる。
【０３０４】
応答出力先判定部２９０２は、ＡＲＰ応答パケット判定部１２０４から受け取ったＡＲＰ応答パケットの送信元ＩＰアドレス３７１０とＡＲＰ情報記憶部１２０３に記憶されているターゲットＩＰアドレス１３０３とを比較し、一致しているエントリを探す。一致したエントリの通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２のそれぞれに“１”が設定されているか否かでＡＲＰ要求元を判定する。
【０３０５】
通信パスＢ要求ビット１３０１および通信パスＤ要求ビット１３０２の両方に“１”が設定されている場合、応答出力先判定部２９０２はパケット複製部２９０３にＡＲＰ応答パケットを出力する。
【０３０６】
パケット複製部２９０３はＡＲＰ応答パケットを複製し、引渡し部１２０６に対して通信パスＢおよび通信パスＤへＡＲＰ応答パケットを出力するように要求する。
【０３０７】
引渡し部１２０６は、要求に従い、両方の通信パスにＡＲＰ応答パケットを出力する。その結果、第１通信プロトコル部１０２および第２通信プロトコル部１２２はともにＡＲＰ応答パケットを受け取ることができる。
【０３０８】
このように、実施の形態１４では、実施の形態１３と同じく、パケット振り分け部１２４の内部にＡＲＰ監視制御部１００１が備えられ、ＡＲＰ情報記憶部１２０３にＡＲＰ要求パケットのターゲットＩＰアドレスとＡＲＰ要求元とが対応付けられて１つのエントリとして記憶される。
【０３０９】
しかし、実施の形態１３とは異なり、ＡＲＰ監視制御部１００１は、両方の通信プロトコル部から同じターゲットＩＰアドレスへのＡＲＰ要求パケットを受けた場合、１つのＡＲＰ要求パケットのみを送信する。さらに、そのＡＲＰ要求パケットに対応するエントリに、２つの要求元を示す情報が登録される。その後、そのＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットを受信した場合、両方の通信プロトコル部に出力する。
【０３１０】
結果として、実施の形態１４のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、必要のないＡＲＰ要求パケットの送出処理を行なわず、さらに、そのＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットの受信処理を行う必要がない。つまり、実施の形態１４のＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、実施の形態１３の説明で述べた物理アドレスの解決処理の効率化に加え、ネットワーク上の負荷を低減することができるという効果を有する。
【０３１１】
＜実施の形態１５＞
本発明の実施の形態１５として、通信先の機器の物理アドレスの解決を効率的に行い、かつ、ネットワーク上の負荷をさらに低減すことができる形態について説明する。
【０３１２】
本発明の実施の形態１５について、図３７を用いて説明する。
図３７は、実施の形態１５におけるＡＲＰ監視制御部１００１の機能的な構成を示す機能ブロック図である。
【０３１３】
図３７に示すように、実施の形態１５のＡＲＰ監視制御部１００１は、図３６に示した実施の形態１４のＡＲＰ監視制御部１００１が有する構成に加え、テーブル参照部３００１と応答パケット生成部３００２とを有することを特徴とする。応答パケット生成部３００２は、本発明のデータ通信装置におけるＡＲＰ応答生成手段の一例である。
【０３１４】
また、第２通信プロトコル部１２２が有するアドレス解決テーブル３００３は、解決された、通信先の機器の物理アドレスをその機器のＩＰアドレスと対応付けて記録するためのテーブルである。
【０３１５】
また、アドレス解決テーブル３００３は、第２通信プロトコル部１２２の要求により解決された物理アドレスだけでなく、第１通信プロトコル部１０２の要求により解決された物理アドレスも記録されている。
【０３１６】
実施の形態１５におけるＡＲＰ監視制御部１００１の動作は、テーブル参照部３００１、応答パケット生成部３００２、および応答出力先判定部３００４の動作以外は、実施の形態１４における各構成部の動作と同様の動作である。そのため、実施の形態１４との差分のみを説明する。
【０３１７】
ＡＲＰ要求パケット判定部１２０１は送信パケットがＡＲＰ要求パケットである場合、テーブル参照部３００１へ送信パケットを出力する。
【０３１８】
テーブル参照部３００１は、第２通信プロトコル部１２２が備えるアドレス解決テーブル３００３を参照し、このＡＲＰ要求パケットのターゲットＩＰアドレスが記録されているか否かを確認する。該当するターゲットＩＰアドレスが記録されていない場合、要求元判定部２９０１にＡＲＰ要求パケットを出力する。
【０３１９】
該当するターゲットＩＰアドレスが記録されている場合、テーブル参照部３００１は、そのターゲットＩＰアドレスと対応付けられた物理アドレスをアドレス解決テーブル３００３から読み出す。更に、ＡＲＰ要求パケットを廃棄し、応答パケット生成部３００２へ、読み出した物理アドレスを通知するとともに、ＡＲＰ応答パケットの生成を要求する。
【０３２０】
ここで、この廃棄されたＡＲＰ要求パケットの宛先であるターゲットＩＰアドレスがアドレス解決テーブル３００３に記録されているということは、このＡＲＰ要求パケットの送信元は、第２通信プロトコル部１２２ではないことが分かる。つまり、応答パケット生成部３００２により生成されるＡＲＰ応答パケットは、第１通信プロトコル部１０２へ出力されればよい。
【０３２１】
応答パケット生成部３００２は、テーブル参照部３００１から受け取った物理アドレスを用いＡＲＰ応答パケットを生成する。
【０３２２】
生成後、引渡し部１２０６に対して、通信パスＢへＡＲＰ応答パケットの出力要求を行う。引渡し部１２０６はＡＲＰ応答パケットを通信パスＢへ出力する。出力されたＡＲＰ応答パケットは、第１通信プロトコル部１０２に受け取られる。
【０３２３】
このように、すでに解決済みの物理アドレスの解決を要求するＡＲＰ要求パケットは送出されることがない。
【０３２４】
また、解決していない物理アドレス、つまり、アドレス解決テーブル３００３に記録されていないターゲットＩＰアドレスに対応する物理アドレスは、以下の動作によりアドレス解決テーブル３００３に追加される。
【０３２５】
応答出力先判定部３００４は、ＡＲＰ応答パケット判定部１２０４からＡＲＰ応答パケットを受け取る。さらに、そのＡＲＰ応答パケットの送信元ＩＰアドレス３７１０とＡＲＰ情報記憶部１２０３に記憶されているＡＲＰ情報とから、ＡＲＰ応答パケットの出力先の通信パスが通信パスＢであるのか通信パスＤであるのかを判定する。
【０３２６】
判定の結果、出力先が通信パスＢである場合、第２通信プロトコル部１２２が備えるアドレス解決テーブル３００３に、そのＡＲＰ応答パケットの送信元ＩＰアドレス３７１０が記録されていないことを確認する。確認後、アドレス解決テーブル３００３にその送信元ＩＰアドレス３７１０と、ＡＲＰ応答パケットに含まれる物理アドレスとを追加記録する。
【０３２７】
なお、ＡＲＰ応答パケットの出力先の通信パスが通信パスＤである場合は、そのＡＲＰ応答パケットは第２通信プロトコル部１２２に出力される。そのため、第２通信プロトコル部１２２で、アドレス解決テーブル３００３への新たな物理アドレスの追加記録が行なわれる。
【０３２８】
このように、実施の形態１５によれば、ＡＲＰ監視制御部１００１にテーブル参照部３００１を設けることにより、第２通信プロトコル部１２２および第１通信プロトコル部１０２においてすでに物理アドレスが解決されているＩＰアドレスへはＡＲＰ要求パケットを送信しなくてもよい。したがって、冗長なパケットの送出をふせぐことができる。従って、実施の形態１４と比較すると、さらにネットワーク上の負荷を低減することができる。
【０３２９】
＜実施の形態１６＞
上述の本発明の実施の形態１〜１５の説明では、各実施の形態において特徴的な構成部についてのみ説明を行なった。しかしながら、ＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、各実施の形態において特徴的な構成部を複数同時に備えていてもよい。
【０３３０】
図３８は、本発明において特徴的な構成部を複数有するＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【０３３１】
図３８に示すＡＶデータ送信装置１０およびＡＶデータ受信装置１３は、実施の形態１におけるＡＶデータ送信装置１０およびＡＶデータ受信装置１３に、実施の形態２におけるＩＣＭＰ監視部１１２と、実施の形態１０におけるＩＣＭＰ制御部５１０と、実施の形態１３におけるＡＲＰ監視制御部１００１とが備えられ、ＡＶデータ受信装置１３には、さらに、実施の形態１１におけるポート予約制御部８０１が備えられている。
【０３３２】
例えば、ＡＶデータ送信装置１０およびＡＶデータ受信装置１３は図３８に示す各構成部を同時に備えていてもよく、各構成部の動作および機能は、他の構成部の動作および機能を妨げるものではない。
【０３３３】
また、図３８において、例えば、実施の形態１３におけるＡＲＰ監視制御部１００１に換えて実施の形態１４におけるＡＲＰ監視制御部１００１が備えられてもよい。また、例えば、ＡＶデータ送信装置１０がポート予約制御部８０１を備えていてもよい。さらに、また、例えば、ＩＣＭＰ監視部１１２は、ＡＶデータ受信装置１３にのみ備えられていてもよい。
【０３３４】
つまり、ＩＣＭＰ制御部５１０等の、本発明の特徴的な構成部は、製造コスト、ユーザのニーズ等に応じ、自由に組み合わせてＡＶデータ送信装置１０およびＡＶデータ受信装置１３に備えてもよい。
【０３３５】
こうすることで、ＡＶデータ送信装置１０およびＡＶデータ受信装置１３の構成上および処理上の無駄の発生をさらに削減することが可能となる。
【産業上の利用可能性】
【０３３６】
本発明のデータ通信装置は、ホスト装置と高速伝送用装置のそれぞれに通信プロトコルを搭載しつつ、構成上および処理上の無駄の発生を削減することができるデータ通信装置を提供することができる。特に、高転送レートのＡＶデータを伝送する装置に有用である。例えば、ＡＶコンテンツをネットワーク伝送する機能を有するＤＶＤレコーダや、ネットワーク伝送でＡＶコンテンツを受信して再生する機能を有するデジタルＴＶ等に応用できる。
【図面の簡単な説明】
【０３３７】
【図１】従来のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図２】図２（ａ）は、ＩＰフラグメントの発生からＩＰフラグメントパケットの再構築までの処理の流れの一例を示す図であり、図２（ｂ）は、ＩＰフラグメントパケットの一例を示す図である。
【図３】フラグメントパケットが再構築できなかった際の処理の概要を示す図である。
【図４】従来のフラグメント再構築部の機能的な構成を示す機能ブロック図である。
【図５】図５（ａ）は、ＩＰヘッダフォーマットを示す図であり、図５（ｂ）は、ＩＰヘッダに含まれるＰＲＯＴＯＣＯＬ領域の値とプロトコル名との対応を示す図であり、図５（ｃ）は、ＩＰヘッダに含まれるＦＬＡＧＳ領域のビットと意味との対応を示す図である。
【図６】従来のＩＣＭＰ複製部の機能的な構成を示す機能ブロック図である。
【図７】アドレス解決プロトコル（ＡＲＰ）による一般的なアドレス解決の仕組みを示す図である。
【図８】特許文献４に開示された、物理アドレスの解決を行なう従来のホストコンピュータの機能的な構成を示す機能ブロック図である。
【図９】実施の形態１のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図１０】実施の形態１におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図１１】実施の形態１における制御情報記憶部に記憶されている制御情報のデータ構成の一例を示す図である。
【図１２】図１２（ａ）は、ＴＣＰヘッダフォーマットを示す図であり、図１２（ｂ）は、ＵＤＰヘッダフォーマットを示す図である。
【図１３】実施の形態１におけるフラグメント制御部の動作の流れを示すフローチャートである。
【図１４】実施の形態２のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図１５】実施の形態２におけるフラグメント制御部およびＩＣＭＰ監視部の機能的な構成を示す機能ロック図である。
【図１６】ＩＣＭＰエラーメッセージのパケットフォーマットを示す図である。
【図１７】実施の形態３におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図１８】実施の形態４におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図１９】実施の形態４における制御情報記憶部に記憶されている制御情報のデータ構成の一例を示す図である。
【図２０】実施の形態５におけるフラグメント制御部およびＩＣＭＰ監視部の機能的な構成を示す機能ブロック図である。
【図２１】実施の形態６におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図２２】実施の形態６における制御情報記憶部に記憶されている制御情報のデータ構成の一例を示す図である。
【図２３】実施の形態７における複製制御部の動作の流れを示すフローチャートである。
【図２４】実施の形態８における複製制御部の動作の流れを示すフローチャートである。
【図２５】実施の形態９におけるフラグメント制御部の機能的な構成を示す機能ブロック図である。
【図２６】実施の形態１０におけるＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図２７】実施の形態１０におけるＩＣＭＰ制御部の機能的な構成を示す機能ブロック図である。
【図２８】ＩＣＭＰエラーメッセージパケットのＤＡＴＡ領域にエラーパケットの情報が格納される場合の代表的なＩＣＭＰエラーメッセージの種類を示す図である。
【図２９】実施の形態１１におけるＡＶデータ送信装置とＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図３０】実施の形態１１におけるポート予約制御部の機能的な構成を示す機能ブロック図である。
【図３１】実施の形態１２におけるポート予約制御部の機能的な構成を示す機能ブロック図である。
【図３２】実施の形態１３のＡＶデータ送信装置およびＡＶデータ受信装置の機能的な構成を示す機能ブロック図である。
【図３３】実施の形態１３におけるＡＲＰ監視制御部の機能的な構成を示す機能ブロック図である。
【図３４】実施の形態１３におけるＡＲＰ情報記憶部に記憶されたＡＲＰ情報のデータ構成例を示す図である。
【図３５】ＡＲＰパケットのパケットフォーマットを示す図である。
【図３６】実施の形態１４におけるＡＲＰ監視制御部の機能的な構成を示す機能ブロック図である。
【図３７】実施の形態１５におけるＡＲＰ監視制御部の機能的な構成を示す機能ブロック図である。
【図３８】本発明において特徴的な構成部を複数有するＡＶデータ送信装置１０およびＡＶデータ受信装置１３の機能的な構成を示す機能ブロック図である。
【符号の説明】
【０３３８】
１０ ＡＶデータ送信装置
１１、１４ ホスト装置
１２ 高速伝送用装置
１３ ＡＶデータ受信装置
１０１ 第１Ｉ／Ｆ部１０１
１０２ 第１通信プロトコル部１０２
１０３ 情報設定部
１０４ ＡＶ伝送サーバＡＰＰ
１０５、１０９ サーバＡＰＰ
１０６、１０８ クライアントＡＰＰ
１０７ ＡＶ伝送クライアントＡＰＰ
１１０ フラグメント制御部
１１２ ＩＣＭＰ監視部
１２１ 第２Ｉ／Ｆ部
１２２ 第２通信プロトコル部
１２３ 送受信部
１２４ パケット振り分け部
３０１ フラグメント判定部
３０２ 先頭パケット判定部
３０３ 後続パケット判定部
３０５、２３０３ 引渡し先判定部
３０６、６０４、１２０６ 引渡し部
３０７ 制御情報記憶部
３０９ バッファ
３１０ 情報消去部
３１１ ＴＭＯパケット判定部
５１０ ＩＣＭＰ制御部
６０１ ＩＣＭＰ判定部
６０２ エラーパケット判定部
６０５、２９０３ パケット複製部
８０１ ポート予約制御部
９０１ ポート番号削除部
９０２ ポート番号登録部
９０３ ポート番号確定部
１００１ ＡＲＰ監視制御部
１２０１ ＡＲＰ要求パケット判定部
１２０２ 要求元判定部
１２０３ ＡＲＰ情報記憶部
１２０４ ＡＲＰ応答パケット判定部
１２０５ 応答出力先判定部
１９０１ タイマ設定部
２００１ 第１消去部
２００２ 第２消去部
２１０１ 第１プロトコル配送不可フラグ
２１０２ 第２プロトコル配送不可フラグ
２２０１ ＴＭＯ測定開始部
２２０２ ＴＭＯ測定完了部
２３０１ バッファ量監視部
２３０２ パケット複製制御部
２７０１ 順序制御部
２８０１ ポート番号登録部
２８０２ ポート番号確定部
２８０３ 繰り返し要求部
２９０１ 要求元判定部
２９０２ 応答出力先判定部
３００１ テーブル参照部
３００２ 応答パケット生成部
３００３ アドレス解決テーブル
３００４ 応答出力先判定部
【特許請求の範囲】
【請求項１】
第１の通信プロトコルで通信する第１通信プロトコル部と、第２の通信プロトコルで通信する第２通信プロトコル部とを備え、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）パケットによる通信を行なうデータ通信装置であって、
前記ＩＰパケットは、前記ＩＰパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するための宛先情報を有する１つの第１パケットと、前記宛先情報を有しない１つ以上の第２パケットとに分割されており、
前記データ通信装置は、
前記第１パケットまたは前記第２パケットである、ＩＰフラグメントパケットを受信する受信手段と、
前記宛先情報を記憶するための宛先情報記憶手段と、
前記第２パケットを記憶するためのバッファと、
前記ＩＰフラグメントパケットが第１パケットであるか否かを判定し、前記ＩＰフラグメントパケットが第１パケットである場合、前記第１パケットが有する宛先情報を、前記宛先情報記憶手段に記憶させる第１パケット判定手段と、
前記第１パケットを、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する振り分け手段と、
前記ＩＰフラグメントパケットが、前記第１パケット判定手段により前記第１パケットでないと判定された第２パケットである場合、前記宛先情報が前記宛先情報記憶手段に記憶されているとき、前記第２パケットを前記振り分け手段へ渡し、前記宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させる第２パケット制御手段とを備え、
前記振り分け手段は、前記第２パケット制御手段から前記第２パケットを受け取ると、前記宛先情報記憶手段に記憶されている前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ前記第２パケットを出力する
データ通信装置。
【請求項２】
前記第１パケット判定手段は、前記ＩＰフラグメントパケットが第１パケットであると判定した場合、前記バッファに前記第２パケットが記憶されているとき、前記バッファから前記第２パケットを読み出し、前記第１パケットとともに読み出した前記第２パケットを前記振り分け手段に渡し、
前記振り分け手段は、前記第１パケット判定手段から渡された前記第１パケットと前記第２パケットとを、前記宛先情報記憶手段に記憶されている前記宛先情報に基づき前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する
請求項１記載のデータ通信装置。
【請求項３】
前記第１パケットおよび前記第２パケットのそれぞれは、前記ＩＰパケットにおける自身の位置を示す位置情報を有しており、
前記データ通信装置は、更に、
前記第１パケットと１つ以上の第２パケットとを、前記位置情報に従って整列させる整列手段を備え、
前記振り分け手段は、前記整列手段により整列された前記第１パケットと１つ以上の第２パケットとを、前記宛先情報記憶手段に記憶されている前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する
請求項２記載のデータ通信装置。
【請求項４】
前記第１通信プロトコル部および前記第２通信プロトコル部は、それぞれ所定の期間内に前記ＩＰパケットを構成する前記第１パケットおよび全ての第２パケットが入力されない場合、タイムアウト通知を出力し、
前記データ通信装置は、更に、
前記第１通信プロトコル部または前記第２通信プロトコル部から出力されるタイムアウト通知を検出するタイムアウト検出手段と、
前記タイムアウト検出手段により、前記タイムアウト通知が検出された場合、前記宛先情報記憶手段に記憶されている前記宛先情報を消去する消去手段とを備える
請求項１記載のデータ通信装置。
【請求項５】
更に、時間の経過を計測するタイマと、
前記タイマから所定の通知を受けると、前記宛先情報記憶手段に記憶されている前記宛先情報と前記バッファに記憶されている第２パケットとを消去する消去手段とを備え、
前記第１パケット判定手段は、前記受信手段により受信された前記ＩＰフラグメントパケットが第１パケットであるか否かを判定するとともに、前記タイマを起動させ、
前記タイマは、所定の期間を示す値が設定されており、前記第１パケット判定手段により起動されてから設定された期間が経過すると、前記消去手段に前記所定の通知を送る
請求項１記載のデータ管理装置。
【請求項６】
前記第１通信プロトコル部および前記第２通信プロトコル部のそれぞれには、前記ＩＰパケットを構成する前記第１パケットおよび全ての第２パケットが揃うのを待つ期間を示す値であるタイムアウト値が設定されており、
前記データ通信装置は、更に、
前記第１プロトコル部に設定されている第１タイムアウト値と、前記第２プロトコル部に設定されている第２タイムアウト値とを比較し、より大きなタイムアウト値を、前記タイマに設定するタイマ設定手段を備える
請求項５記載のデータ通信装置。
【請求項７】
前記第１通信プロトコル部および前記第２通信プロトコル部のそれぞれには、前記ＩＰパケットを構成する前記第１パケットおよび全ての第２パケットが揃うのを待つ期間を示す値であるタイムアウト値が設定されており、
前記データ通信装置は、更に、
時間の経過を計測する第１タイマおよび第２タイマと、
前記第１プロトコル部に設定されている第１タイムアウト値を前記第１タイマに設定し、前記第２プロトコル部に設定されている第２タイムアウト値を前記第２タイマに設定するタイマ設定手段と、
前記第１タイマから前記第１タイムアウト値の経過の通知を受けると、前記第２タイムアウト値が経過したことを示す第２経過情報が前記宛先情報記憶手段に記憶されていない場合、前記第１タイムアウト値が経過したことを示す第１経過情報を前記宛先情報記憶手段に記憶させ、前記第２経過情報が前記宛先情報記憶手段に記憶されている場合、前記宛先情報記憶手段に記憶されている前記宛先情報と前記第２経過情報とを消去する第１消去手段と、
前記第２タイマから前記第２タイムアウト値の経過の通知を受けると、前記第１経過情報が前記宛先情報記憶手段に記憶されていない場合、前記第２経過情報を前記宛先情報記憶手段に記憶させ、前記第１経過情報が前記宛先情報記憶手段に記憶されている場合、前記宛先情報記憶手段に記憶されている前記宛先情報と前記第１経過情報とを消去する第１消去手段とを備え、
前記振り分け手段は、前記第１パケットまたは前記第２パケットを受け取ると、前記宛先情報記憶手段に前記第１経過情報が記憶されている場合、前記宛先情報の内容に関わらず前記第１パケットまたは前記第２パケットを前記第１プロトコル部へは出力せず、前記宛先情報記憶手段に前記第２経過情報が記憶されている場合、前記宛先情報の内容に関わらず前記第１パケットまたは前記第２パケットを前記第２プロトコル部へは出力しない
請求項１記載のデータ管理装置。
【請求項８】
更に、
１つのＩＰフラグメントパケットであるダミーパケットを前記第１通信プロトコル部に出力するダミーパケット出力手段と、
ダミーパケット出力手段により前記ダミーパケットが出力されてから、前記ダミーパケットに対応して前記第１通信プロトコル部から出力されるタイムアウト通知を受け取るまでの時間を計測するタイムアウト計測手段とを備え、
前記タイマ設定手段は、前記タイムアウト計測手段により計測された時間を、前記第１タイムアウト値として、前記第１タイマに設定する
請求項７記載のデータ通信装置。
【請求項９】
第１パケットが有する宛先情報はポート番号と、前記ＩＰパケットを識別するための識別情報とを含み、
第２パケットは前記識別情報を有し、
前記第２パケット制御手段は、前記第２パケットが有する識別情報と同じ識別情報を含む宛先情報が前記宛先情報記憶手段に記憶されている場合、前記第２パケットを前記振り分け手段へ渡し、前記第２パケットが有する識別情報と同じ識別情報を含む宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させ、
前記振り分け手段は、前記第２パケットを受け取ると、前記第２パケットが有する識別情報と同じ識別情報を含む宛先情報に含まれるポート番号と、前記第１通信プロトコル部または前記第２通信プロトコル部で使用されるポート番号とを比較して出力先を決定する
請求項１記載のデータ通信装置。
【請求項１０】
前記データ通信装置は、更に、
前記バッファの空き容量を検出する容量検出手段と、
前記第２パケット制御手段から第２パケットを受け取ると、受け取った前記第２パケットを複製し、２つの前記第２パケットを前記振り分け手段に渡すパケット複製手段とを備え、
前記第２パケット制御手段は、更に、前記バッファに記憶させようとする第２パケットの容量が、前記空き容量検出手段により検出された前記空き容量を超える場合、前記バッファに記憶されている複数の第２パケットの中から、所定の条件を満たす第２パケットを取り出して前記パケット複製手段に渡し、
前記振り分け手段は、前記パケット複製手段から２つの第２パケットを受け取ると、前記第１通信プロトコル部および前記第２通信プロトコル部のそれぞれに１つの前記第２パケットを出力する
請求項１記載のデータ通信装置。
【請求項１１】
前記所定の条件とは、前記バッファに記憶されている第２パケットの中で、前記バッファに記憶された時期が最も早い第２パケットである、または、最も容量が大きい第２パケットであるという条件である
請求項１０記載のデータ通信装置。
【請求項１２】
前記第２パケットは、前記第２パケットが含まれていた前記ＩＰパケットを識別するための識別情報を有し、
前記宛先情報記憶手段には、第２パケットが前記バッファに記憶された際に、前記第２パケット制御手段により、前記第２パケットの識別情報が書き込まれており、
前記第２パケット制御手段は、前記バッファに記憶させようとする第２パケットの容量が、前記空き容量検出手段により検出された前記空き容量を超える場合、前記宛先情報記憶手段に記憶された時期が最も早い識別情報と同一の識別情報を有する第２パケットを、前記バッファの中から取り出してパケット複製手段に渡す
請求項１０記載のデータ通信装置。
【請求項１３】
前記第２パケットは、前記第２パケットが含まれていた前記ＩＰパケットを識別するための識別情報を有し、
前記宛先情報記憶手段には、第２パケットが前記バッファに記憶された際に、前記第２パケット制御手段により、前記第２パケットの識別情報が書き込まれており、
前記第２パケット制御手段は、前記バッファに記憶させようとする第２パケットの容量が、前記空き容量検出手段により検出された前記空き容量を超える場合、前記宛先情報記憶手段に記憶されている識別情報ごとに、前記識別情報と同じ識別情報を有する第２パケットの合計容量を求め、前記合計容量が最大となる識別情報を有する第２パケットを前記バッファの中から取り出してパケット複製手段に渡す
請求項１０記載のデータ通信装置。
【請求項１４】
前記受信手段は、更に、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）エラーメッセージパケットを受信し、
前記データ通信装置は、更に、
前記ＩＣＭＰエラーメッセージパケットが、前記ＩＣＭＰエラーメッセージパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するためのエラー通知先情報を有するか否かを判定するエラーパケット判定手段と、
前記エラーパケット判定手段により前記エラー通知先情報を有していると判定された前記ＩＣＭＰエラーメッセージパケットを、前記通知先情報に基づき、第１通信プロトコル部および第２通信プロトコル部のいずれか一方に出力するエラー出力手段と、
前記エラーパケット判定手段により前記エラー通知先情報を有していないと判定された前記ＩＣＭＰエラーメッセージパケットを複製し、第１通信プロトコル部および第２通信プロトコル部のそれぞれに前記ＩＣＭＰエラーメッセージパケットを１つずつ出力するエラー複製手段とを備える
請求項１記載のデータ通信装置。
【請求項１５】
前記ＩＣＭＰエラーメッセージパケットが有する通知先情報はポート番号を含み、
前記エラー出力手段は、前記通知先情報に含まれるポート番号と、前記第１通信プロトコル部または前記第２通信プロトコル部で使用されるポート番号とを比較して出力先を決定する
請求項１４記載のデータ通信装置。
【請求項１６】
前記データ通信装置は、更に、
前記第１通信プロトコル部で使用されるポート番号の登録要求と削除とを受け付けるインターフェースと、
前記第２通信プロトコル部で使用される使用ポート番号を決定するポート番号決定手段と、
前記ポート番号決定手段により決定された前記使用ポート番号の登録要求を、前記インターフェースを介して前記第１通信プロトコル部に行なうポート番号登録手段と、
前記第２通信プロトコル部からの所定の通知により、前記第１通信プロトコル部に登録されている前記使用ポート番号を削除するポート番号削除手段とを備え、
前記インターフェースは、前記第１プロトコル部に登録されているポート番号の登録は受け付けず、
前記ポート番号登録手段が、前記使用ポート番号を前記第１通信プロトコル部に登録できた場合、前記使用ポート番号は前記第１通信プロトコル部では使用されない
請求項１記載のデータ通信装置。
【請求項１７】
前記ポート番号登録手段が、前記使用ポート番号を前記第１通信プロトコル部に登録できなかった場合、更に、前記ポート番号決定手段に使用ポート番号を決定させ前記ポート番号登録手段に前記使用ポート番号の登録要求を行わせる繰り返し制御手段を備える
請求項１６記載のデータ通信装置。
【請求項１８】
前記繰り返し制御手段は、使用ポート番号を前記第１通信プロトコル部へ登録できるまでの間であって、かつ、所定の期間が経過するまで、または、使用ポート番号を前記第１通信プロトコル部に登録できなかった回数が所定の回数に達するまで、前記ポート番号決定手段に使用ポート番号を決定させ、前記ポート番号登録手段に前記使用ポート番号の登録要求を行わせる
請求項１７記載のデータ通信装置。
【請求項１９】
更に、
前記第１通信プロトコル部または前記第２通信プロトコル部から送信される、他の機器の物理アドレスの解決を要求するＡｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＡＲＰ）要求パケットを受け付けるＡＲＰ要求受付手段と、
前記ＡＲＰ要求受付手段により受け付けられた前記ＡＲＰ要求パケットから得られる、送信元を示す送信元情報と、前記他の機器のＩＰアドレスである送信先アドレスとを対応付けて記憶するＡＲＰ情報記憶手段と、
前記ＡＲＰ要求パケットを前記他の機器に送信するＡＲＰ送信手段と、
前記他の機器から送信される、前記ＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットを受信するＡＲＰ応答受信手段と、
前記ＡＲＰ応答受信手段により受信された前記ＡＲＰ応答パケットから得られる、前記他の機器のＩＰアドレスと、前記ＡＲＰ情報記憶手段に記憶されている前記送信先アドレスとから、前記ＡＲＰ応答パケットの出力先を判定する応答出力判定手段と、
前記応答出力判定手段の判定結果に従い、前記ＡＲＰ応答パケットを前記第１通信プロトコル部または前記第２通信プロトコル部のいずれか一方に出力する応答出力手段とを備える
請求項１記載のデータ通信装置。
【請求項２０】
更に、
前記ＡＲＰ要求受付手段により受け付けられたＡＲＰ要求パケットから得られる送信先アドレスが、前記ＡＲＰ情報記憶手段に記憶されていた場合、前記ＡＲＰ要求パケットから得られる送信元情報を前記送信先アドレスに更に対応付けて前記ＡＲＰ情報記憶手段に記憶させ、前記ＡＲＰ要求パケットを廃棄するＡＲＰ要求元判定手段と、
前記ＡＲＰ応答受信手段により受信されたＡＲＰ応答パケットから得られる、他の機器のＩＰアドレスが、送信先アドレスとして前記ＡＲＰ情報記憶手段に記憶されており、かつ、前記送信先アドレスに２つの異なる送信元情報が対応付けられている場合、前記ＡＲＰ応答パケットを複製し、２つの前記ＡＲＰ応答パケットを前記応答出力手段に渡すＡＲＰパケット複製手段とを備え、
前記応答出力手段は、更に、前記ＡＲＰパケット複製手段から２つの前記ＡＲＰ応答パケットを受け取ると、前記第１通信プロトコル部および前記第２通信プロトコル部のそれぞれに１つの前記ＡＲＰ応答パケットを出力する
請求項１９記載のデータ通信装置。
【請求項２１】
更に、
前記ＡＲＰ応答受信手段により受信されたＡＲＰ応答パケットから得られる他の機器のＩＰアドレスと物理アドレスとを対応付けて記憶するアドレス解決テーブルと、
前記ＡＲＰ要求受付手段により受け付けられたＡＲＰ要求パケットから得られる送信先アドレスが、前記他の機器のＩＰアドレスとしてアドレス解決テーブルに記憶されていた場合、前記他の機器のＩＰアドレスに対応付けられた前記物理アドレスを含むＡＲＰ応答パケットを生成し前記応答出力手段に渡すＡＲＰ応答生成手段とを備え、
前記応答出力手段は、更に、前記ＡＲＰ応答生成手段から前記ＡＲＰ応答パケットを受け取ると、前記ＡＲＰ要求パケットの送信元である前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方に前記ＡＲＰ応答パケットを出力し、
前記応答出力判定手段は、更に、前記ＡＲＰ応答受信手段により受信された前記ＡＲＰ応答パケットから得られる他の機器のＩＰアドレスが、アドレス解決テーブルに記憶されていない場合、前記他の機器のＩＰアドレスと前記ＡＲＰ応答パケットから得られる前記物理アドレスとを対応付けてアドレス解決テーブルに記憶させる
請求項２０記載のデータ通信装置。
【請求項２２】
前記受信手段は、更に、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）エラーメッセージパケットを受信し、
前記データ通信装置は、更に、
前記ＩＣＭＰエラーメッセージパケットが、前記ＩＣＭＰエラーメッセージパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するためのエラー通知先情報を有するか否かを判定するエラーパケット判定手段と、
前記エラーパケット判定手段により前記エラー通知先情報を有していると判定された前記ＩＣＭＰエラーメッセージパケットを、前記通知先情報に基づき、第１通信プロトコル部および第２通信プロトコル部のいずれか一方に出力するエラー出力手段と、
前記エラーパケット判定手段により前記エラー通知先情報を有していないと判定された前記ＩＣＭＰエラーメッセージパケットを複製し、第１通信プロトコル部および第２通信プロトコル部のそれぞれに前記ＩＣＭＰエラーメッセージパケットを１つずつ出力するエラー複製手段と、
前記第１通信プロトコル部で使用されるポート番号の登録要求と削除とを受け付けるインターフェースと、
前記第２通信プロトコル部で使用される使用ポート番号を決定するポート番号決定手段と、
前記ポート番号決定手段により決定された前記使用ポート番号の登録要求を、前記インターフェースを介して前記第１通信プロトコル部に行なうポート番号登録手段と、
前記第２通信プロトコル部からの所定の通知により、前記第１通信プロトコル部に登録されている前記使用ポート番号を削除するポート番号削除手段と、
前記第１通信プロトコル部または前記第２通信プロトコル部から送信される、他の機器の物理アドレスの解決を要求するＡｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＡＲＰ）要求パケットを受け付けるＡＲＰ要求受付手段と、
前記ＡＲＰ要求受付手段により受け付けられた前記ＡＲＰ要求パケットから得られる、送信元を示す送信元情報と、前記他の機器のＩＰアドレスである送信先アドレスとを対応付けて記憶するＡＲＰ情報記憶手段と、
前記ＡＲＰ要求パケットを前記他の機器に送信するＡＲＰ送信手段と、
前記他の機器から送信される、前記ＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットを受信するＡＲＰ応答受信手段と、
前記ＡＲＰ応答受信手段により受信された前記ＡＲＰ応答パケットから得られる、前記他の機器のＩＰアドレスと、前記ＡＲＰ情報記憶手段に記憶されている前記送信先アドレスとから、前記ＡＲＰ応答パケットの出力先を判定する応答出力判定手段と、
前記応答出力判定手段の判定結果に従い、前記ＡＲＰ応答パケットを前記第１通信プロトコル部または前記第２通信プロトコル部のいずれか一方に出力する応答出力手段とを備え、
前記インターフェースは、前記第１プロトコル部に登録されているポート番号の登録は受け付けず、
前記ポート番号登録手段が、前記使用ポート番号を前記第１通信プロトコル部に登録できた場合、前記使用ポート番号は前記第１通信プロトコル部では使用されない
請求項１記載のデータ通信装置。
【請求項２３】
前記ＩＰパケットは、コンテンツデータの一部または全部を構成するパケットである、請求項２２記載のデータ通信装置を備えるコンテンツ再生装置。
【請求項２４】
前記ＩＰパケットは、コンテンツデータの一部または全部を構成するパケットである、請求項２２記載のデータ通信装置を備えるコンテンツ記録再生装置。
【請求項２５】
第１の通信プロトコルで通信する第１通信プロトコル部と、第２の通信プロトコルで通信する第２通信プロトコル部とを備えるデータ通信装置において、ＩＰパケットによる通信を行なう通信方法であって、
前記ＩＰパケットは、前記ＩＰパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するための宛先情報を有する１つの第１パケットと、前記宛先情報を有しない１つ以上の第２パケットとに分割されており、
前記データ通信装置は、
前記宛先情報を記憶するための宛先情報記憶手段と、
前記第２パケットを記憶するためのバッファとを備えており、
前記第１パケットまたは前記第２パケットである、ＩＰフラグメントパケットを受信する受信ステップと、
前記ＩＰフラグメントパケットが第１パケットであるか否かを判定し、前記ＩＰフラグメントパケットが第１パケットである場合、前記第１パケットが有する宛先情報を、前記宛先情報記憶手段に記憶させる第１パケット判定ステップと、
前記第１パケットを、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する第１パケット制御ステップと、
前記ＩＰフラグメントパケットが、前記第１パケット判定ステップにおいて前記第１パケットでないと判定された第２パケットである場合、前記宛先情報が前記宛先情報記憶手段に記憶されているとき、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ前記第２パケットを出力し、前記宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させる第２パケット制御ステップと
を含む通信方法。
【請求項２６】
第１の通信プロトコルで通信する第１通信プロトコル部と、第２の通信プロトコルで通信する第２通信プロトコル部とを備えるデータ通信装置において、ＩＰパケットによる通信を行なうためのプログラムであって、
前記ＩＰパケットは、前記ＩＰパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するための宛先情報を有する１つの第１パケットと、前記宛先情報を有しない１つ以上の第２パケットとに分割されており、
前記データ通信装置は、
前記宛先情報を記憶するための宛先情報記憶手段と、
前記第２パケットを記憶するためのバッファとを備えており、
前記第１パケットまたは前記第２パケットである、ＩＰフラグメントパケットを受信する受信ステップと、
前記ＩＰフラグメントパケットが第１パケットであるか否かを判定し、前記ＩＰフラグメントパケットが第１パケットである場合、前記第１パケットが有する宛先情報を、前記宛先情報記憶手段に記憶させる第１パケット判定ステップと、
前記第１パケットを、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する第１パケット制御ステップと、
前記ＩＰフラグメントパケットが、前記第１パケット判定ステップにおいて前記第１パケットでないと判定された第２パケットである場合、前記宛先情報が前記宛先情報記憶手段に記憶されているとき、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ前記第２パケットを出力し、前記宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させる第２パケット制御ステップと
をコンピュータに実行させるためのプログラム。
【請求項１】
第１の通信プロトコルで通信する第１通信プロトコル部と、第２の通信プロトコルで通信する第２通信プロトコル部とを備え、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）パケットによる通信を行なうデータ通信装置であって、
前記ＩＰパケットは、前記ＩＰパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するための宛先情報を有する１つの第１パケットと、前記宛先情報を有しない１つ以上の第２パケットとに分割されており、
前記データ通信装置は、
前記第１パケットまたは前記第２パケットである、ＩＰフラグメントパケットを受信する受信手段と、
前記宛先情報を記憶するための宛先情報記憶手段と、
前記第２パケットを記憶するためのバッファと、
前記ＩＰフラグメントパケットが第１パケットであるか否かを判定し、前記ＩＰフラグメントパケットが第１パケットである場合、前記第１パケットが有する宛先情報を、前記宛先情報記憶手段に記憶させる第１パケット判定手段と、
前記第１パケットを、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する振り分け手段と、
前記ＩＰフラグメントパケットが、前記第１パケット判定手段により前記第１パケットでないと判定された第２パケットである場合、前記宛先情報が前記宛先情報記憶手段に記憶されているとき、前記第２パケットを前記振り分け手段へ渡し、前記宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させる第２パケット制御手段とを備え、
前記振り分け手段は、前記第２パケット制御手段から前記第２パケットを受け取ると、前記宛先情報記憶手段に記憶されている前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ前記第２パケットを出力する
データ通信装置。
【請求項２】
前記第１パケット判定手段は、前記ＩＰフラグメントパケットが第１パケットであると判定した場合、前記バッファに前記第２パケットが記憶されているとき、前記バッファから前記第２パケットを読み出し、前記第１パケットとともに読み出した前記第２パケットを前記振り分け手段に渡し、
前記振り分け手段は、前記第１パケット判定手段から渡された前記第１パケットと前記第２パケットとを、前記宛先情報記憶手段に記憶されている前記宛先情報に基づき前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する
請求項１記載のデータ通信装置。
【請求項３】
前記第１パケットおよび前記第２パケットのそれぞれは、前記ＩＰパケットにおける自身の位置を示す位置情報を有しており、
前記データ通信装置は、更に、
前記第１パケットと１つ以上の第２パケットとを、前記位置情報に従って整列させる整列手段を備え、
前記振り分け手段は、前記整列手段により整列された前記第１パケットと１つ以上の第２パケットとを、前記宛先情報記憶手段に記憶されている前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する
請求項２記載のデータ通信装置。
【請求項４】
前記第１通信プロトコル部および前記第２通信プロトコル部は、それぞれ所定の期間内に前記ＩＰパケットを構成する前記第１パケットおよび全ての第２パケットが入力されない場合、タイムアウト通知を出力し、
前記データ通信装置は、更に、
前記第１通信プロトコル部または前記第２通信プロトコル部から出力されるタイムアウト通知を検出するタイムアウト検出手段と、
前記タイムアウト検出手段により、前記タイムアウト通知が検出された場合、前記宛先情報記憶手段に記憶されている前記宛先情報を消去する消去手段とを備える
請求項１記載のデータ通信装置。
【請求項５】
更に、時間の経過を計測するタイマと、
前記タイマから所定の通知を受けると、前記宛先情報記憶手段に記憶されている前記宛先情報と前記バッファに記憶されている第２パケットとを消去する消去手段とを備え、
前記第１パケット判定手段は、前記受信手段により受信された前記ＩＰフラグメントパケットが第１パケットであるか否かを判定するとともに、前記タイマを起動させ、
前記タイマは、所定の期間を示す値が設定されており、前記第１パケット判定手段により起動されてから設定された期間が経過すると、前記消去手段に前記所定の通知を送る
請求項１記載のデータ管理装置。
【請求項６】
前記第１通信プロトコル部および前記第２通信プロトコル部のそれぞれには、前記ＩＰパケットを構成する前記第１パケットおよび全ての第２パケットが揃うのを待つ期間を示す値であるタイムアウト値が設定されており、
前記データ通信装置は、更に、
前記第１プロトコル部に設定されている第１タイムアウト値と、前記第２プロトコル部に設定されている第２タイムアウト値とを比較し、より大きなタイムアウト値を、前記タイマに設定するタイマ設定手段を備える
請求項５記載のデータ通信装置。
【請求項７】
前記第１通信プロトコル部および前記第２通信プロトコル部のそれぞれには、前記ＩＰパケットを構成する前記第１パケットおよび全ての第２パケットが揃うのを待つ期間を示す値であるタイムアウト値が設定されており、
前記データ通信装置は、更に、
時間の経過を計測する第１タイマおよび第２タイマと、
前記第１プロトコル部に設定されている第１タイムアウト値を前記第１タイマに設定し、前記第２プロトコル部に設定されている第２タイムアウト値を前記第２タイマに設定するタイマ設定手段と、
前記第１タイマから前記第１タイムアウト値の経過の通知を受けると、前記第２タイムアウト値が経過したことを示す第２経過情報が前記宛先情報記憶手段に記憶されていない場合、前記第１タイムアウト値が経過したことを示す第１経過情報を前記宛先情報記憶手段に記憶させ、前記第２経過情報が前記宛先情報記憶手段に記憶されている場合、前記宛先情報記憶手段に記憶されている前記宛先情報と前記第２経過情報とを消去する第１消去手段と、
前記第２タイマから前記第２タイムアウト値の経過の通知を受けると、前記第１経過情報が前記宛先情報記憶手段に記憶されていない場合、前記第２経過情報を前記宛先情報記憶手段に記憶させ、前記第１経過情報が前記宛先情報記憶手段に記憶されている場合、前記宛先情報記憶手段に記憶されている前記宛先情報と前記第１経過情報とを消去する第１消去手段とを備え、
前記振り分け手段は、前記第１パケットまたは前記第２パケットを受け取ると、前記宛先情報記憶手段に前記第１経過情報が記憶されている場合、前記宛先情報の内容に関わらず前記第１パケットまたは前記第２パケットを前記第１プロトコル部へは出力せず、前記宛先情報記憶手段に前記第２経過情報が記憶されている場合、前記宛先情報の内容に関わらず前記第１パケットまたは前記第２パケットを前記第２プロトコル部へは出力しない
請求項１記載のデータ管理装置。
【請求項８】
更に、
１つのＩＰフラグメントパケットであるダミーパケットを前記第１通信プロトコル部に出力するダミーパケット出力手段と、
ダミーパケット出力手段により前記ダミーパケットが出力されてから、前記ダミーパケットに対応して前記第１通信プロトコル部から出力されるタイムアウト通知を受け取るまでの時間を計測するタイムアウト計測手段とを備え、
前記タイマ設定手段は、前記タイムアウト計測手段により計測された時間を、前記第１タイムアウト値として、前記第１タイマに設定する
請求項７記載のデータ通信装置。
【請求項９】
第１パケットが有する宛先情報はポート番号と、前記ＩＰパケットを識別するための識別情報とを含み、
第２パケットは前記識別情報を有し、
前記第２パケット制御手段は、前記第２パケットが有する識別情報と同じ識別情報を含む宛先情報が前記宛先情報記憶手段に記憶されている場合、前記第２パケットを前記振り分け手段へ渡し、前記第２パケットが有する識別情報と同じ識別情報を含む宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させ、
前記振り分け手段は、前記第２パケットを受け取ると、前記第２パケットが有する識別情報と同じ識別情報を含む宛先情報に含まれるポート番号と、前記第１通信プロトコル部または前記第２通信プロトコル部で使用されるポート番号とを比較して出力先を決定する
請求項１記載のデータ通信装置。
【請求項１０】
前記データ通信装置は、更に、
前記バッファの空き容量を検出する容量検出手段と、
前記第２パケット制御手段から第２パケットを受け取ると、受け取った前記第２パケットを複製し、２つの前記第２パケットを前記振り分け手段に渡すパケット複製手段とを備え、
前記第２パケット制御手段は、更に、前記バッファに記憶させようとする第２パケットの容量が、前記空き容量検出手段により検出された前記空き容量を超える場合、前記バッファに記憶されている複数の第２パケットの中から、所定の条件を満たす第２パケットを取り出して前記パケット複製手段に渡し、
前記振り分け手段は、前記パケット複製手段から２つの第２パケットを受け取ると、前記第１通信プロトコル部および前記第２通信プロトコル部のそれぞれに１つの前記第２パケットを出力する
請求項１記載のデータ通信装置。
【請求項１１】
前記所定の条件とは、前記バッファに記憶されている第２パケットの中で、前記バッファに記憶された時期が最も早い第２パケットである、または、最も容量が大きい第２パケットであるという条件である
請求項１０記載のデータ通信装置。
【請求項１２】
前記第２パケットは、前記第２パケットが含まれていた前記ＩＰパケットを識別するための識別情報を有し、
前記宛先情報記憶手段には、第２パケットが前記バッファに記憶された際に、前記第２パケット制御手段により、前記第２パケットの識別情報が書き込まれており、
前記第２パケット制御手段は、前記バッファに記憶させようとする第２パケットの容量が、前記空き容量検出手段により検出された前記空き容量を超える場合、前記宛先情報記憶手段に記憶された時期が最も早い識別情報と同一の識別情報を有する第２パケットを、前記バッファの中から取り出してパケット複製手段に渡す
請求項１０記載のデータ通信装置。
【請求項１３】
前記第２パケットは、前記第２パケットが含まれていた前記ＩＰパケットを識別するための識別情報を有し、
前記宛先情報記憶手段には、第２パケットが前記バッファに記憶された際に、前記第２パケット制御手段により、前記第２パケットの識別情報が書き込まれており、
前記第２パケット制御手段は、前記バッファに記憶させようとする第２パケットの容量が、前記空き容量検出手段により検出された前記空き容量を超える場合、前記宛先情報記憶手段に記憶されている識別情報ごとに、前記識別情報と同じ識別情報を有する第２パケットの合計容量を求め、前記合計容量が最大となる識別情報を有する第２パケットを前記バッファの中から取り出してパケット複製手段に渡す
請求項１０記載のデータ通信装置。
【請求項１４】
前記受信手段は、更に、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）エラーメッセージパケットを受信し、
前記データ通信装置は、更に、
前記ＩＣＭＰエラーメッセージパケットが、前記ＩＣＭＰエラーメッセージパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するためのエラー通知先情報を有するか否かを判定するエラーパケット判定手段と、
前記エラーパケット判定手段により前記エラー通知先情報を有していると判定された前記ＩＣＭＰエラーメッセージパケットを、前記通知先情報に基づき、第１通信プロトコル部および第２通信プロトコル部のいずれか一方に出力するエラー出力手段と、
前記エラーパケット判定手段により前記エラー通知先情報を有していないと判定された前記ＩＣＭＰエラーメッセージパケットを複製し、第１通信プロトコル部および第２通信プロトコル部のそれぞれに前記ＩＣＭＰエラーメッセージパケットを１つずつ出力するエラー複製手段とを備える
請求項１記載のデータ通信装置。
【請求項１５】
前記ＩＣＭＰエラーメッセージパケットが有する通知先情報はポート番号を含み、
前記エラー出力手段は、前記通知先情報に含まれるポート番号と、前記第１通信プロトコル部または前記第２通信プロトコル部で使用されるポート番号とを比較して出力先を決定する
請求項１４記載のデータ通信装置。
【請求項１６】
前記データ通信装置は、更に、
前記第１通信プロトコル部で使用されるポート番号の登録要求と削除とを受け付けるインターフェースと、
前記第２通信プロトコル部で使用される使用ポート番号を決定するポート番号決定手段と、
前記ポート番号決定手段により決定された前記使用ポート番号の登録要求を、前記インターフェースを介して前記第１通信プロトコル部に行なうポート番号登録手段と、
前記第２通信プロトコル部からの所定の通知により、前記第１通信プロトコル部に登録されている前記使用ポート番号を削除するポート番号削除手段とを備え、
前記インターフェースは、前記第１プロトコル部に登録されているポート番号の登録は受け付けず、
前記ポート番号登録手段が、前記使用ポート番号を前記第１通信プロトコル部に登録できた場合、前記使用ポート番号は前記第１通信プロトコル部では使用されない
請求項１記載のデータ通信装置。
【請求項１７】
前記ポート番号登録手段が、前記使用ポート番号を前記第１通信プロトコル部に登録できなかった場合、更に、前記ポート番号決定手段に使用ポート番号を決定させ前記ポート番号登録手段に前記使用ポート番号の登録要求を行わせる繰り返し制御手段を備える
請求項１６記載のデータ通信装置。
【請求項１８】
前記繰り返し制御手段は、使用ポート番号を前記第１通信プロトコル部へ登録できるまでの間であって、かつ、所定の期間が経過するまで、または、使用ポート番号を前記第１通信プロトコル部に登録できなかった回数が所定の回数に達するまで、前記ポート番号決定手段に使用ポート番号を決定させ、前記ポート番号登録手段に前記使用ポート番号の登録要求を行わせる
請求項１７記載のデータ通信装置。
【請求項１９】
更に、
前記第１通信プロトコル部または前記第２通信プロトコル部から送信される、他の機器の物理アドレスの解決を要求するＡｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＡＲＰ）要求パケットを受け付けるＡＲＰ要求受付手段と、
前記ＡＲＰ要求受付手段により受け付けられた前記ＡＲＰ要求パケットから得られる、送信元を示す送信元情報と、前記他の機器のＩＰアドレスである送信先アドレスとを対応付けて記憶するＡＲＰ情報記憶手段と、
前記ＡＲＰ要求パケットを前記他の機器に送信するＡＲＰ送信手段と、
前記他の機器から送信される、前記ＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットを受信するＡＲＰ応答受信手段と、
前記ＡＲＰ応答受信手段により受信された前記ＡＲＰ応答パケットから得られる、前記他の機器のＩＰアドレスと、前記ＡＲＰ情報記憶手段に記憶されている前記送信先アドレスとから、前記ＡＲＰ応答パケットの出力先を判定する応答出力判定手段と、
前記応答出力判定手段の判定結果に従い、前記ＡＲＰ応答パケットを前記第１通信プロトコル部または前記第２通信プロトコル部のいずれか一方に出力する応答出力手段とを備える
請求項１記載のデータ通信装置。
【請求項２０】
更に、
前記ＡＲＰ要求受付手段により受け付けられたＡＲＰ要求パケットから得られる送信先アドレスが、前記ＡＲＰ情報記憶手段に記憶されていた場合、前記ＡＲＰ要求パケットから得られる送信元情報を前記送信先アドレスに更に対応付けて前記ＡＲＰ情報記憶手段に記憶させ、前記ＡＲＰ要求パケットを廃棄するＡＲＰ要求元判定手段と、
前記ＡＲＰ応答受信手段により受信されたＡＲＰ応答パケットから得られる、他の機器のＩＰアドレスが、送信先アドレスとして前記ＡＲＰ情報記憶手段に記憶されており、かつ、前記送信先アドレスに２つの異なる送信元情報が対応付けられている場合、前記ＡＲＰ応答パケットを複製し、２つの前記ＡＲＰ応答パケットを前記応答出力手段に渡すＡＲＰパケット複製手段とを備え、
前記応答出力手段は、更に、前記ＡＲＰパケット複製手段から２つの前記ＡＲＰ応答パケットを受け取ると、前記第１通信プロトコル部および前記第２通信プロトコル部のそれぞれに１つの前記ＡＲＰ応答パケットを出力する
請求項１９記載のデータ通信装置。
【請求項２１】
更に、
前記ＡＲＰ応答受信手段により受信されたＡＲＰ応答パケットから得られる他の機器のＩＰアドレスと物理アドレスとを対応付けて記憶するアドレス解決テーブルと、
前記ＡＲＰ要求受付手段により受け付けられたＡＲＰ要求パケットから得られる送信先アドレスが、前記他の機器のＩＰアドレスとしてアドレス解決テーブルに記憶されていた場合、前記他の機器のＩＰアドレスに対応付けられた前記物理アドレスを含むＡＲＰ応答パケットを生成し前記応答出力手段に渡すＡＲＰ応答生成手段とを備え、
前記応答出力手段は、更に、前記ＡＲＰ応答生成手段から前記ＡＲＰ応答パケットを受け取ると、前記ＡＲＰ要求パケットの送信元である前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方に前記ＡＲＰ応答パケットを出力し、
前記応答出力判定手段は、更に、前記ＡＲＰ応答受信手段により受信された前記ＡＲＰ応答パケットから得られる他の機器のＩＰアドレスが、アドレス解決テーブルに記憶されていない場合、前記他の機器のＩＰアドレスと前記ＡＲＰ応答パケットから得られる前記物理アドレスとを対応付けてアドレス解決テーブルに記憶させる
請求項２０記載のデータ通信装置。
【請求項２２】
前記受信手段は、更に、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）エラーメッセージパケットを受信し、
前記データ通信装置は、更に、
前記ＩＣＭＰエラーメッセージパケットが、前記ＩＣＭＰエラーメッセージパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するためのエラー通知先情報を有するか否かを判定するエラーパケット判定手段と、
前記エラーパケット判定手段により前記エラー通知先情報を有していると判定された前記ＩＣＭＰエラーメッセージパケットを、前記通知先情報に基づき、第１通信プロトコル部および第２通信プロトコル部のいずれか一方に出力するエラー出力手段と、
前記エラーパケット判定手段により前記エラー通知先情報を有していないと判定された前記ＩＣＭＰエラーメッセージパケットを複製し、第１通信プロトコル部および第２通信プロトコル部のそれぞれに前記ＩＣＭＰエラーメッセージパケットを１つずつ出力するエラー複製手段と、
前記第１通信プロトコル部で使用されるポート番号の登録要求と削除とを受け付けるインターフェースと、
前記第２通信プロトコル部で使用される使用ポート番号を決定するポート番号決定手段と、
前記ポート番号決定手段により決定された前記使用ポート番号の登録要求を、前記インターフェースを介して前記第１通信プロトコル部に行なうポート番号登録手段と、
前記第２通信プロトコル部からの所定の通知により、前記第１通信プロトコル部に登録されている前記使用ポート番号を削除するポート番号削除手段と、
前記第１通信プロトコル部または前記第２通信プロトコル部から送信される、他の機器の物理アドレスの解決を要求するＡｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＡＲＰ）要求パケットを受け付けるＡＲＰ要求受付手段と、
前記ＡＲＰ要求受付手段により受け付けられた前記ＡＲＰ要求パケットから得られる、送信元を示す送信元情報と、前記他の機器のＩＰアドレスである送信先アドレスとを対応付けて記憶するＡＲＰ情報記憶手段と、
前記ＡＲＰ要求パケットを前記他の機器に送信するＡＲＰ送信手段と、
前記他の機器から送信される、前記ＡＲＰ要求パケットへの応答であるＡＲＰ応答パケットを受信するＡＲＰ応答受信手段と、
前記ＡＲＰ応答受信手段により受信された前記ＡＲＰ応答パケットから得られる、前記他の機器のＩＰアドレスと、前記ＡＲＰ情報記憶手段に記憶されている前記送信先アドレスとから、前記ＡＲＰ応答パケットの出力先を判定する応答出力判定手段と、
前記応答出力判定手段の判定結果に従い、前記ＡＲＰ応答パケットを前記第１通信プロトコル部または前記第２通信プロトコル部のいずれか一方に出力する応答出力手段とを備え、
前記インターフェースは、前記第１プロトコル部に登録されているポート番号の登録は受け付けず、
前記ポート番号登録手段が、前記使用ポート番号を前記第１通信プロトコル部に登録できた場合、前記使用ポート番号は前記第１通信プロトコル部では使用されない
請求項１記載のデータ通信装置。
【請求項２３】
前記ＩＰパケットは、コンテンツデータの一部または全部を構成するパケットである、請求項２２記載のデータ通信装置を備えるコンテンツ再生装置。
【請求項２４】
前記ＩＰパケットは、コンテンツデータの一部または全部を構成するパケットである、請求項２２記載のデータ通信装置を備えるコンテンツ記録再生装置。
【請求項２５】
第１の通信プロトコルで通信する第１通信プロトコル部と、第２の通信プロトコルで通信する第２通信プロトコル部とを備えるデータ通信装置において、ＩＰパケットによる通信を行なう通信方法であって、
前記ＩＰパケットは、前記ＩＰパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するための宛先情報を有する１つの第１パケットと、前記宛先情報を有しない１つ以上の第２パケットとに分割されており、
前記データ通信装置は、
前記宛先情報を記憶するための宛先情報記憶手段と、
前記第２パケットを記憶するためのバッファとを備えており、
前記第１パケットまたは前記第２パケットである、ＩＰフラグメントパケットを受信する受信ステップと、
前記ＩＰフラグメントパケットが第１パケットであるか否かを判定し、前記ＩＰフラグメントパケットが第１パケットである場合、前記第１パケットが有する宛先情報を、前記宛先情報記憶手段に記憶させる第１パケット判定ステップと、
前記第１パケットを、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する第１パケット制御ステップと、
前記ＩＰフラグメントパケットが、前記第１パケット判定ステップにおいて前記第１パケットでないと判定された第２パケットである場合、前記宛先情報が前記宛先情報記憶手段に記憶されているとき、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ前記第２パケットを出力し、前記宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させる第２パケット制御ステップと
を含む通信方法。
【請求項２６】
第１の通信プロトコルで通信する第１通信プロトコル部と、第２の通信プロトコルで通信する第２通信プロトコル部とを備えるデータ通信装置において、ＩＰパケットによる通信を行なうためのプログラムであって、
前記ＩＰパケットは、前記ＩＰパケットの宛先が第１通信プロトコル部であるか第２通信プロトコル部であるかを特定するための宛先情報を有する１つの第１パケットと、前記宛先情報を有しない１つ以上の第２パケットとに分割されており、
前記データ通信装置は、
前記宛先情報を記憶するための宛先情報記憶手段と、
前記第２パケットを記憶するためのバッファとを備えており、
前記第１パケットまたは前記第２パケットである、ＩＰフラグメントパケットを受信する受信ステップと、
前記ＩＰフラグメントパケットが第１パケットであるか否かを判定し、前記ＩＰフラグメントパケットが第１パケットである場合、前記第１パケットが有する宛先情報を、前記宛先情報記憶手段に記憶させる第１パケット判定ステップと、
前記第１パケットを、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ出力する第１パケット制御ステップと、
前記ＩＰフラグメントパケットが、前記第１パケット判定ステップにおいて前記第１パケットでないと判定された第２パケットである場合、前記宛先情報が前記宛先情報記憶手段に記憶されているとき、前記宛先情報に基づき、前記第１通信プロトコル部および前記第２通信プロトコル部のいずれか一方へ前記第２パケットを出力し、前記宛先情報が前記宛先情報記憶手段に記憶されていないとき、前記第２パケットを前記バッファに記憶させる第２パケット制御ステップと
をコンピュータに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【公開番号】特開２００７−１０４１３７（Ｐ２００７−１０４１３７Ａ）
【公開日】平成１９年４月１９日（２００７．４．１９）
【国際特許分類】
【出願番号】特願２００５−２８９０８９（Ｐ２００５−２８９０８９）
【出願日】平成１７年９月３０日（２００５．９．３０）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成１９年４月１９日（２００７．４．１９）
【国際特許分類】
【出願日】平成１７年９月３０日（２００５．９．３０）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]