JP2010193015A - 通信装置およびその通信方法 - Google Patents

Abstract

【課題】複数のネットワークにおいて独立に管理されているドメイン名の名前解決を、ネットワークおよびユーザに余計な負荷をかけずに効率よく実行する通信装置を提供する。
【解決手段】ＤＮＳ体系が互いに異なる２以上のＩＰネットワークに接続され、それらのＩＰネットワークのいずれかを介して他の通信装置と通信する通信装置であって、所定のＩＰネットワークで名前解決ができることが保証されているドメイン名を用い、ドメイン名の名前解決が成功するか否かをそれらのＩＰネットワークに順番に接続して確認することで、ドメイン名の名前解決が成功したＩＰネットワークを第１域網、成功しなかったＩＰネットワークを第２域網として識別する識別部と、他の通信装置と通信を開始するのに先だって、第１域網と識別されたＩＰネットワークから優先して名前解決を試み、名前解決が成功したＩＰネットワークを介して他の通信装置と通信する通信制御部とを備える。
【選択図】図４

Description

本発明は、通信装置およびその通信方法に関し、特に、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）体系が互いに異なる２以上のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークに接続され、それらのＩＰネットワークのいずれかを介して他の通信装置と通信する通信装置およびその通信方法に関する。

近年、インターネットとは独立したネットワークであって、高品質な通信回線を利用して大容量コンテンツを配信するＣＤＮ（Ｃｏｎｔｅｎｔｓ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）の構築が進められている。

ＣＤＮは、インターネットと同様にＩＰネットワークで構築されることが多い。そのため、ＣＤＮは、インターネットと同様に、ＤＮＳと呼ばれる名前解決機構を利用する。

ＤＮＳは、階層的な分散型データベースシステムとして構築される。ＤＮＳでは、クライアントとなる通信端末（以下、クライアント通信端末と記載。）が、該当するＩＰネットワークに存在するいずれかのＤＮＳサーバに、通信相手を示すドメイン名の名前解決を要求する。そして、そのＤＮＳサーバにより、階層的な分散型データベースシステムを構成するＤＮＳサーバ間で適切な通信が行われ、該当するＩＰアドレスがクライアント通信端末に返信されるようになっている。

ここで、名前解決とは、ネットワーク上でのサーバ等の機器につけられた名前からアドレスを割り出すこと、またはその逆である。クライアント通信端末では、ネットワークで通信を行うのにＩＰアドレスが必要であるため、通信したいドメイン名からＩＰアドレスを割り出す（見つける）名前解決が、クライアント通信端末におけるすべての通信に先だって実行される。また、ＩＰアドレスとは、インターネットやイントラネットなどのＩＰネットワークに接続されたコンピュータや通信機器などの機器ごとに割り振られた識別番号であり、パケットを送受信したい等の通信を行いたい通信相手の機器を判別するための番号である。

また、一般のクライアント通信端末は、複数のＤＮＳサーバを登録することが可能となっている。そのため、一般のクライアント通信端末では、登録されてかつ現在使用中のＤＮＳサーバから応答がない場合に、登録されている予備のＤＮＳサーバに切り替えて、再度名前解決の要求を実施する。

なお、クライアント通信端末は、ＤＮＳサーバに対して、ＤＮＳで管理されていないドメイン名の解決要求を送信した場合、そのＤＮＳサーバにより該当名なしという応答が返される。その場合、クライアント通信端末は、登録されている予備のＤＮＳサーバへの切り替えを行わない。

しかしながら、ＣＤＮとインターネットは、互いに独立したネットワークであるために、ＤＮＳの管理においてＣＤＮとインターネットが連携しないことがある。すなわち、ＣＤＮに対して構築される階層的な分散型データベースシステムとネットワークに対して構築される階層的な分散型データベースとは別体系（独立な体系）であるため、ＣＤＮ側のＤＮＳサーバとネットワーク側のＤＮＳサーバとが連携しないことがある。

このため、従来のクライアント通信装置では、インターネットとＣＤＮとのネットワークの両方に接続する場合、インターネット側のＤＮＳサーバを使用している時はＣＤＮでのドメイン名解決が不可能である。反対にＣＤＮ側のＤＮＳサーバを利用している時はインターネットでのドメイン名解決が不可能となってしまうという課題がある。

そこで、接続している全てのネットワークのＤＮＳサーバに対して名前解決要求を送出し、受信した回答の中で最も優先順位が高い回答を採用する方法およびネットワークに優先順位をつけて優先順位の高いネットワークのＤＮＳサーバから使用する方法が提案されている（例えば特許文献１）。
特開２００４−２９７４９４号公報

しかしながら、従来の方法では以下のような問題がある。すなわち、インターネットとＣＤＮとネットワークの両方に接続するクライアント通信装置が、その両方のネットワークのドメイン名を解決するために、接続する全てのネットワークのＤＮＳサーバに対して名前解決要求を送出する方法は、非効率的であり、余計な負荷をネットワークに与える。また、ネットワークに優先順位をつけて優先順位の高いネットワークのＤＮＳサーバから使用する方法は、ネットワークの優先順位に言及しておらず、手動で設定する必要があり、利用者の負担が増大する。

本発明は、上記のような課題を解決するためになされたもので、複数のネットワークにおいて独立に管理されているドメイン名の名前解決を、ネットワークおよびユーザに余計な負荷をかけずに効率よく実行できる通信装置およびその通信方法を提供することを目的とする。

前記従来の課題を解決するために、本願第１の発明にかかる通信装置は、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）体系が互いに異なる２以上のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークに接続され、前記２以上のＩＰネットワークのいずれかを介して他の通信装置と通信する通信装置であって、所定のＩＰネットワークで名前解決ができることが保証されているドメイン名を用いて、前記ドメイン名の名前解決が成功するか否かを前記２以上のＩＰネットワークに順番に接続して確認することにより、前記ドメイン名の名前解決が成功したＩＰネットワークを第１域網、前記ドメイン名の名前解決が成功しなかったＩＰネットワークを第２域網として識別する識別部と、他の通信装置と通信を開始するのに先だって、前記第１域網と識別されたＩＰネットワークから優先して名前解決を試み、名前解決が成功したＩＰネットワークを介して他の通信装置と通信する通信制御部とを備えることを特徴とする。

本願第２の発明にかかる通信装置は、前記識別部は、ＩＰネットワークの前記ドメイン名の名前解決が成功するときに取得するＩＰアドレスに対して、疎通確認を実行する疎通確認部を有し、前記ドメイン名の名前解決が成功し、かつ、前記疎通確認部による疎通確認が成功した場合に、当該ＩＰネットワークを第１域網として識別することを特徴とする。

本願第３の発明にかかる通信装置は、前記通信装置は、前記識別部の識別結果を保持する保持部を備え、前記通信制御部は、前記識別結果に基づいて、前記名前解決を試みることを特徴とする。

本発明によれば、複数のネットワークにおいて独立に管理されているドメイン名の名前解決を、ネットワークおよびユーザに余計な負荷をかけずに効率よく実行する通信装置およびその通信方法を実現することができる。

以下に、本発明の実施の形態について、図面を参照しながら説明する。

（実施の形態１）
はじめに、図１〜図３を用いて本発明の実施の形態１におけるクライアント通信端末が複数のネットワーク接続時に名前解決する方法の構成について説明する。

図１は、実施の形態１におけるシステム構成を示した図である。このシステムは、クライアント通信端末１００と、インターネット２００と、ＣＤＮ３００とから構成され、クライアント通信端末は、複数のネットワークと接続している。

図１において、クライアント通信端末１００は、インターネット２００およびＣＤＮ３００の複数のネットワークに接続されている。

インターネット２００では、ＤＮＳサーバ群２１０とＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ２２０とが設置されている。

ＤＮＳサーバ群２１０は、階層的な分散型データベースシステムとして構築されており、インターネット２００上の機器のドメイン名とそのＩＰアドレスとの対応表を管理する。

ＤＨＣＰサーバ２２０は、インターネット２００上の機器にアクセスするためのクライアント通信端末１００のＩＰアドレスやＤＮＳサーバ群２１０のＩＰアドレス等をクライアント通信端末１００に対して配信する。

また、ＣＤＮ３００では、ＣＤＮ３００用のＤＮＳサーバ３１０が設置されている。ＤＮＳサーバ３１０は、ＣＤＮ３００上のドメイン名とＩＰアドレスの対応表を管理する。ここで、ＤＮＳサーバ群２１０とＤＮＳサーバ３１０は独立しており、相手側が管理しているドメイン名の名前解決は行えない。すなわち、ドメイン名は、インターネット２００およびＣＤＮ３００の複数のネットワークにおいて独立に管理されている。具体的には、ＤＮＳサーバ群２１０では、ＤＮＳサーバ３１０が管理しているドメイン名の名前解決は行えない。同様に、ＤＮＳサーバ３１０では、ＤＮＳサーバ群２１０が管理しているドメイン名の名前解決は行えない。

ＤＨＣＰサーバ３２０は、ＣＤＮ３００上の機器にアクセスするためのクライアント通信端末１００のＩＰアドレスやＤＮＳサーバ３１０のＩＰアドレス等をクライアント通信端末１００に対して配信する。

図２は、実施の形態１におけるクライアント通信端末１００の構成を示したブロック図である。

図２におけるクライアント通信端末１００は、通信インタフェース１０１および１０２と、ＩＰ設定部１０３と、ドメイン名保持部１０４と、広域／閉域識別部１０５と、名前解決部１０６と、ネットワークリスト１０７とを備える。

図２において、通信インタフェース１０１および１０２は、インターネット２００およびＣＤＮ３００にそれぞれ接続されている。

ＩＰ設定部１０３は、ＤＨＣＰクライアント機能を備えており、ＤＨＣＰサーバが運用されていれば、自動的にクライアント通信端末１００が使用するＩＰアドレスと共にＤＮＳサーバのＩＰアドレス等を取得する。ＩＰ設定部１０３は、取得したクライアント通信端末１００のＩＰアドレスとＤＮＳサーバのＩＰアドレスとを含む設定情報を、ネットワークリスト１０７に記録するとともに、通信インタフェースに対して設定する。例えば、ＩＰ設定部１０３は、ＣＤＮ３００におけるクライアント通信端末１００とＤＮＳサーバ３１０とのＩＰアドレスを含む設定情報を取得した場合には、それらのＩＰアドレスを通信インタフェース１０２に設定する。同様に、インターネット２００におけるクライアント通信端末１００とＤＮＳサーバ群２１０とのＩＰアドレスを含む設定情報を取得した場合には、それらのＩＰアドレスを通信インタフェース１０１に設定する。

なお、ＩＰ設定部１０３は、ＤＨＣＰサーバが運用されていない場合を考慮し、手動でクライアント通信端末１００やＤＮＳサーバのＩＰアドレスを含む設定情報を設定できるようにするためのユーザインタフェースを備えている。本実施の形態１ではインターネット２００およびＣＤＮ３００の両方ともＤＨＣＰサーバが運用されているとして説明する。すなわち、本実施の形態１では、ＩＰ設定部１０３は、ＤＨＣＰを用いてクライアント通信端末１００とＤＮＳサーバとのＩＰアドレスを含む設定情報を取得することができるものとして説明する。

ドメイン名保持部１０４は、インターネット２００のＤＮＳサーバ群２１０で名前解決ができることが保証されているドメイン名を保持している。ここで、ドメイン名保持部１０４が保持するドメイン名は、一般的には、クライアント通信端末１００の開発業者がインターネット２００のＤＮＳに登録しておいたドメイン名が使用される。例えば「ｗｗｗ．ｃｌｉｅｎｔ−ｍａｋｅｒ．ｊｐ」のような文字列がドメイン名保持部１０４に保持される。

広域／閉域識別部１０５は、各ネットワーク（ここでは、インターネット２００およびＣＤＮ３００）のＤＮＳサーバに対して、ドメイン名保持部１０４が保持するドメイン名の名前解決を、名前解決部１０６を用いて実施する。そして、広域／閉域識別部１０５は、例えばそのドメイン名のＩＰアドレスが取得できた場合には広域網と判定し、そのドメイン名のＩＰアドレスが取得できなかった場合には閉域網と判定する。広域／閉域識別部１０５は、その結果を識別情報としてネットワークリスト１０７に記録する。

名前解決部１０６は、ネットワークリスト１０７を参照し、使用するＤＮＳサーバを決定して名前解決を実行する。

ネットワークリスト１０７には、少なくともクライアント通信端末１００のＩＰアドレスと、ＤＮＳサーバのＩＰアドレスと、それらＩＰアドレスに対する識別情報とがデータとして記録されている（例えば図３）。

図３は、実施の形態１におけるネットワークリスト１０７が記録するデータの一例を示す図である。

図３において、ネットワークリスト１０７は、広域網と判断されたネットワークのクライアント通信端末１００のＩＰアドレス（１９２．１６８．０．１０）とそのサブネットマスク（２５５．２５５．２５５．０）とが記録されている。また、ネットワークリスト１０７は、広域網と判断されたネットワークのゲートウェイのＩＰアドレス（１９２．１６８．０．１）とＤＮＳサーバのＩＰアドレス（１９２．１６８．１０．１００／１９２．１６８．１０．１０１）とが記録されている。

同様に、ネットワークリスト１０７は、閉域網と判断されたネットワークのクライアント通信端末１００のＩＰアドレス（１０．０．０．２０）とそのサブネットマスク（２５５．２５５．２５５．０）とが記録されている。また、ネットワークリスト１０７は、閉域網と判断されたネットワークのゲートウェイのＩＰアドレス（１０．０．０．１）とＤＮＳサーバのＩＰアドレス（１０．０．１０．１００／１０．０．１０．１０１）とが記録されている。

通信インタフェース１０１は、ＩＰ設定部１０３により、インターネット２００におけるクライアント通信端末１００とＤＮＳサーバ群２１０とのＩＰアドレスが設定され、それらを含む設定情報を保持している。また、通信インタフェース１０１は、設定情報に基づいて、インターネット２００と接続する。

通信インタフェース１０２は、ＩＰ設定部１０３により、ＣＤＮ３００におけるクライアント通信端末１００とＤＮＳサーバ３１０とのＩＰアドレスが設定され、それらを含む設定情報を保持している。また、通信インタフェース１０２は、設定情報に基づいて、ＣＤＮ３００と接続する。

なお、通信インタフェース１０１および１０２は、クライアント通信端末１００に論理的に２つ備えられていればよく、物理的に２つ備えられていなくてもよい。例えばＩＰｖ６に対応した通信端末では、複数のＩＰｖ６アドレス（一般的にはリンクローカルアドレスとグローバルアドレス）が同一の物理インタフェースに設定できることはよく知られている。ＩＰｖ４に対応した通信端末においても、一部のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）では複数のＩＰｖ４アドレスを同一の物理インタフェースに設定することが可能である。さらに、ＩＰｖ６とＩＰｖ４の両方に対応した通信端末においては、ＩＰｖ６アドレスとＩＰｖ４アドレスを同一の物理インタフェースに設定することも可能である。

次に、図４〜図７を用いて、本発明の実施の形態１におけるクライアント通信端末が名前解決する方法の動作について説明する。

本発明の実施の形態１における名前解決方法は、１）ネットワークリスト１０７の生成と、２）ＤＮＳサーバへの問い合わせの２段階に分けることができる。また、１）ネットワークリスト１０７の生成は、クライアント通信端末１００の設置時および電源起動時などの起動時に一度だけ実行される。また、２）ＤＮＳサーバへの問い合わせは、名前解決が必要となる度に実行される。

まず、１）ネットワークリスト１０７の生成の方法について説明する。

図４は、実施の形態１における起動時のネットワークリスト１０７の生成する処理を示すフローチャートである。ここでは、クライアント通信端末１００は、２つの通信インタフェース１０１および１０２を備える。そして、通信インタフェース１０１が、インターネット２００に接続し、通信インタフェース１０２がＣＤＮ３００に接続するものとする。

ＩＰ設定部１０３は、クライアント通信端末１００が起動した際に、まず、通信インタフェース１０１および１０２それぞれに対してクライアント通信端末１００のＩＰアドレスが設定されているかを確認する（Ｓ１０１）。なお、通信インタフェース１０１および１０２それぞれにおいて、クライアント通信端末１００のＩＰアドレスがＩＰ設定部１０３を介して手動設定されていた場合（Ｓ１０１のＮｏの場合）、ここでの処理を終了する。

次に、ＩＰ設定部１０３は、例えば、クライアント通信端末１００のＩＰアドレスが通信インタフェース１０１に設定されていない場合（Ｓ１０１のＹｅｓの場合）、ＤＨＣＰクライアント機能を用いて、ＤＮＳサーバ群２１０のＩＰアドレスなどの設定情報を取得する（Ｓ１０２）。具体的には、ＩＰ設定部１０３は、通信インタフェース１０１に対する設定情報としてＤＨＣＰサーバ２２０からＩＰアドレス、サブネットマスク、ゲートウェイアドレスおよびＤＮＳサーバ群２１０のＩＰアドレスなどの設定情報を取得する。

そして、ＩＰ設定部１０３は、通信インタフェース１０１に、取得したＩＰアドレスを含む設定情報を設定する（Ｓ１０３）。また、同時に、その設定情報のうち少なくともクライアント通信端末１００のＩＰアドレスとＤＮＳサーバ群２１０のＩＰアドレスとをネットワークリスト１０７に記録する。

次に、ＩＰ設定部１０３は、ＤＨＣＰサーバ２２０からの応答、すなわちＳ１０２で取得した通信インタフェース１０１に対する設定情報に、ＤＮＳサーバ群２１０のＩＰアドレスが含まれていたかを判定する（Ｓ１０４）。

ここで、ＩＰ設定部１０３が取得した設定情報にＤＮＳサーバ群２１０のＩＰアドレスが含まれていなかった場合（Ｓ１０４のＮｏの場合）、Ｓ１０１に戻る。このとき、Ｓ１０４で判定した通信インタフェース１０１とは別の通信インタフェース１０２に対して、Ｓ１０１からの処理を実施する。

ＩＰ設定部１０３が取得した設定情報にＤＮＳサーバ群２１０のＩＰアドレスが含まれていた場合（Ｓ１０４のＹｅｓの場合）、広域／閉域識別部１０５は、ＤＮＳサーバ群２１０に対して、ドメイン名保持部１０４が保持するドメイン名の名前解決を実施する（Ｓ１０５）。

そして、広域／閉域識別部１０５は、そのドメイン名の名前解決を実施した結果からＤＮＳサーバ群２１０の識別情報をネットワークリスト１０７に記録する（Ｓ１０６）。ここでは、ドメイン名保持部１０４が保持するドメイン名がインターネット２００のＤＮＳサーバ群２１０で名前解決ができることが保証されており、ＤＮＳサーバ群２１０はそのドメイン名に対応するＩＰアドレスを取得することができる。すなわち、広域／閉域識別部１０５は、ＤＮＳサーバ群２１０から接続できるネットワークを広域網と判断し、ネットワークリスト１０７に記録する。

次に、Ｓ１０１に戻り、通信インタフェース１０２に対して同様の処理を実施する。

最終的には、通信インタフェース１０１および１０２それぞれに対してクライアント通信端末１００のＩＰアドレスが既に設定されていることを確認すると（Ｓ１０１のＮｏの場合）、ここでの処理を終了する。

以上のようにして、クライアント通信端末１００は、起動時におけるネットワークリスト１０７を生成する。

なお、Ｓ１０２において、図３に示すようにＤＨＣＰサーバ（例えばＤＨＣＰサーバ２２０）から２つ以上のＤＮＳサーバ（例えばＤＮＳサーバ群２１０）のＩＰアドレスが返される場合がある。その場合、広域／閉域識別部１０５は、一方のＩＰアドレスのＤＮＳサーバに対してドメイン名保持部１０４が保持するドメイン名の名前解決を実施する。そして、名前解決を実施した一方のＩＰアドレスのＤＮＳサーバから応答がなかった場合にのみ、他方のＩＰアドレスのＤＮＳサーバに対して名前解決を実施する。

ところで、ここで説明しているような、クライアント通信端末１００に複数の通信インタフェース（例えば２つの通信インタフェース１０１および１０２）が接続されているような環境を一般にマルチホーム環境と呼ぶ。

マルチホーム環境では、ある任意のサーバと通信を行うときに、どの通信インタフェースを使用すればよいかを、決定する必要がある。特に図１に示すように、クライアント通信端末１００における一方の通信インタフェース１０１はインターネット２００に、他方の通信インタフェース１０２はＣＤＮ３００に接続されているような場合は、出力する通信インタフェースを間違えると、通信ができなくなってしまう。

そのため、本発明におけるクライアント通信端末１００では、以下の（１）〜（３）で示すルールで使用する通信インタフェース（通信インタフェース１０１または１０２）を決定する。

（１）起動時、ＤＮＳサーバと通信する場合は、ネットワークリスト１０７において該ＤＮＳサーバに対応するクライアント通信端末１００のＩＰアドレス等の設定情報が設定された通信インタフェースを使用する。具体的には、ＤＮＳサーバ群２１０と通信する場合には、ネットワークリスト１０７においてＤＮＳサーバ群２１０に対するクライアント通信端末１００のＩＰアドレス等が設定された通信インタフェース１０１を使用する。

（２）閉域網のＤＮＳサーバから取得したＩＰアドレスに対しては、ネットワークリスト１０７においてそのＤＮＳサーバに対応するＩＰアドレスが設定された通信インタフェースを使用する。具体的には、閉域網におけるＩＰアドレスに対して、ネットワークリスト１０７において閉域網と識別されているＤＮＳサーバ３１０に対するクライアント通信端末１００のＩＰアドレス等が設定された通信インタフェース１０２を使用する。つまり、閉域網におけるＩＰアドレスを持つ機器等への接続には、閉域網に接続する通信インタフェース１０２を用いるというルールである。

（３）その他の通信、すなわち閉域網以外のＤＮＳサーバから取得したＩＰアドレスに対する通信には、ネットワークリスト１０７において広域網と判定されたＤＮＳサーバに対応するＩＰアドレスが設定された通信インタフェースを使用する。例えば、通信インタフェースが４つあり、そのうち１つが閉域網の通信インタフェースでその他が広域網の通信インタフェースである場合、閉域網以外のＩＰアドレスを持つ機器等への接続には、広域網に接続する通信インタフェースの３つのうちいずれを用いてもよいというルールである。これは、広域網であるインターネット２００におけるＤＮＳサーバ群２１０のどれに接続しても、ＩＰアドレスは、インターネット２００において１つに決まるからである。本実施例は、閉域網以外におけるＩＰアドレスに対して、ネットワークリスト１０７において広域網と識別されているＤＮＳサーバ群２１０に対するクライアント通信端末１００のＩＰアドレス等が設定された通信インタフェース１０１を使用する。

次に、図５〜図７を用いて、２）ＤＮＳサーバへの問い合わせの方法について説明する。

図５は、実施の形態１におけるＤＮＳサーバへの問い合わせ処理を示すフローチャートである。

まず、クライアント通信端末１００における名前解決部１０６は、ネットワークリスト１０７において「広域網」と識別されているＤＮＳサーバ群２１０を用いて、所望の接続先となるドメイン名の名前解決を実施する（Ｓ２１０）。

次に、名前解決部１０６は、そのドメイン名に対応するＩＰアドレスが取得できたかどうかの確認を行う（Ｓ２２０）。なお、名前解決部１０６は、ＩＰアドレスが取得できた場合は（Ｓ２２０のＹｅｓの場合）、処理を終了する。

名前解決部１０６は、そのドメイン名に対応するＩＰアドレスが取得できなかった場合（Ｓ２２０のＮｏの場合）、ネットワークリスト１０７において「閉域網」と識別されているＤＮＳサーバ３１０を用いてそのドメイン名の名前解決を実施し（Ｓ２３０）、終了する。

以上のようにして、クライアント通信端末１００はＤＮＳサーバ（ＤＮＳサーバ群２１０またはＤＮＳサーバ３１０）への問い合わせを行う。

次に、図６および図７を用いて図５におけるＳ２１０およびＳ２３０の詳細な動作について説明する。

図６は、図５におけるＳ２１０の詳細を示すフローチャートである。

図６において、まず、クライアント通信端末１００における名前解決部１０６は、ネットワークリスト１０７において「広域網」となっている全てのＤＮＳサーバ群２１０を用いて所望の接続先となるドメイン名の名前解決を実施したかどうか確認する（Ｓ２１１）。

名前解決部１０６は、「広域網」となっている全てのＤＮＳサーバ群２１０を用いて名前解決を実施したことを確認した場合（Ｓ２１１のＹｅｓの場合）、Ｓ２１０での処理を終了する。そして、図５のＳ２２０に遷移する。

一方、名前解決部１０６は、「広域網」となっている全てのＤＮＳサーバ群２１０を用いて名前解決を実施していないことを確認した場合（Ｓ２１１のＮｏの場合）、「広域網」となっている全てのＤＮＳサーバ群２１０の中で未使用のＤＮＳサーバ群２１０を１つ抽出する（Ｓ２１２）。

次に、名前解決部１０６は、抽出したＤＮＳサーバ群２１０の１つに対して名前解決要求を送出する（Ｓ２１３）。

次に、名前解決部１０６は、名前解決要求を送出後、送出先のＤＮＳサーバ群２１０から一定時間内に応答があるかどうかを判定する（Ｓ２１４）。

名前解決部１０６は、送出先のＤＮＳサーバ群２１０から応答があった場合（Ｓ２１４のＹｅｓの場合）、Ｓ２１０の処理を終了する。そして、図５のＳ２２０へ遷移する。

一方、名前解決部１０６は、送出先のＤＮＳサーバ群２１０から応答がなかった場合は（Ｓ２１４のＮｏの場合）、Ｓ２１１へ遷移する。

以上のようにして、クライアント通信端末１００は、Ｓ２１０の処理、すなわち「広域網」となっているＤＮＳサーバ群２１０による名前解決を行う。

なお、広域網に設置されたＤＮＳサーバ群２１０は、インターネット２００上の機器のドメイン名とそのＩＰアドレスとの対応表を連携して一義的に管理するので、全て同じ結果が返ってくる。名前解決部１０６は、一定時間に応答がなかった場合のみ、他のＤＮＳサーバに切り替える。

図７は、図５におけるＳ２３０の詳細を示すフローチャートである。

図７において、まず、名前解決部１０６は、ネットワークリスト１０７において「閉域網」となっている全てのＩＰアドレスに対応するいずれかのＤＮＳサーバ３１０を用いて所望の接続先となるドメイン名の名前解決を実施したかどうか確認する（Ｓ２３１）。ここで、名前解決部１０６は、「閉域網」となっている全てのＩＰアドレスに対応するいずれかのＤＮＳサーバ３１０を用いて名前解決を実施していた場合（Ｓ２３１のＹｅｓの場合）、名前解決が失敗したとして、Ｓ２３０での処理を終了する。

一方、名前解決部１０６は、「閉域網」となっている全てのＩＰアドレスに対応するいずれかのＤＮＳサーバ３１０を未だ用いてない場合（Ｓ２３１のＮｏの場合）、未使用のＤＮＳサーバ３１０に対応するＩＰアドレスを抽出する（Ｓ２３２）。

次に、名前解決部１０６は、抽出したＩＰアドレスに対応する全てのＤＮＳサーバ３１０を用いて名前解決を行ったかどうかを確認する（Ｓ２３３）。

名前解決部１０６は、全てのＤＮＳサーバ３１０を用いて名前解決を行ったことを確認した場合（Ｓ２３３のＹｅｓの場合）、Ｓ２３１に遷移する。

一方、名前解決部１０６は、名前解決に未だ用いていないＤＮＳサーバ３１０が存在すれば（Ｓ２３３のＮｏの場合）、未確認のＤＮＳサーバを１つ抽出し（Ｓ２３４）、名前解決要求を送出する（Ｓ２３５）。

次に、名前解決部１０６は、名前解決要求を送出後、送出先のＤＮＳサーバ３１０から一定時間内に応答があるかどうかを判定する（Ｓ２３６）。

名前解決部１０６は、送出先のＤＮＳサーバ３１０から応答がなかった場合は（Ｓ２３６のＮｏの場合）、Ｓ２１３へ遷移する。

一方、名前解決部１０６は、送出先のＤＮＳサーバ３１０から一定時間内に応答があった場合（Ｓ２３６のＹｅｓの場合）、所望の接続先となるドメイン名のＩＰアドレス取得に成功したかどうか判定する（Ｓ２３７）。

名前解決部１０６は、そのＩＰアドレスが取得できていれば（Ｓ２３７のＹｅｓの場合）、名前解決が成功したとして、Ｓ２３０での処理を終了する。

なお、名前解決部１０６は、そのＩＰアドレスが取得できなかった場合は（Ｓ２３７のＮｏの場合）、Ｓ２３１へ遷移する。

以上のようにして、クライアント通信端末１００は、Ｓ２３０の処理、すなわち「閉域網」となっているＤＮＳサーバ３１０による名前解決の処理を行う。

ここで、ネットワークリスト１０７に図３に示すデータが設定されていた場合に、名前解決部１０６が行うＤＮＳサーバへの問い合わせ順序について具体的に説明する。

はじめに、名前解決部１０６は、ネットワークリスト１０７において、広域網のＤＮＳサーバ「１９２．１６８．１０．１００」に問い合わせを行い、応答がタイムアウトした場合にのみ、広域網の他のＤＮＳサーバ「１９２．１６８．１０．１０１」に問い合わせを行う。すなわち、名前解決部１０６は、ＤＮＳサーバ「１９２．１６８．１０．１００」から所望の接続先であるドメイン名に該当する名前がないという該当名なしの回答の応答を受けた場合に、他のＤＮＳサーバ「１９２．１６８．１０．１０１」に問い合わせる。

さらに、名前解決部１０６は、他のＤＮＳサーバに問い合わせた結果、タイムアウト、もしくは該当名なしの回答の応答を受ける場合がある。その場合には、名前解決部１０６は、閉域網のＤＮＳサーバ「１０．０．１０．１００」に問い合わせを行う。名前解決部１０６は、同様に、その閉域網のＤＮＳサーバ「１０．０．１０．１００」からの応答がタイムアウトした場合には、それとは別のＤＮＳサーバ「１０．０．１０．１０１」に問い合わせを行う。

以上、実施の形態１によれば、クライアント通信端末１００が、ドメイン名が独立に管理されているＣＤＮ３００とインターネット２００との複数のネットワークに接続する場合でも、クライアント通信端末１００に複雑な設定をしなくても、複数のネットワークの非効率な利用もなく、所望の接続先であるドメイン名の名前解決を効率的に行うことができる。

すなわち、実施の形態１によれば、複数のネットワークにおいて独立に管理されているドメイン名の名前解決を、ネットワークおよびユーザに余計な負荷をかけずに効率よく実行する通信装置およびその通信方法を実現することができる。

（変形例１）
実施の形態１では、クライアント通信端末１００が、所望の接続先であるドメイン名の名前解決を行う場合の方針として、ＣＤＮ３００より優先してインターネット２００に接続することを考慮し、広域網のＤＮＳサーバに対する名前解決を優先したがそれに限らない。以下では、ＣＤＮ３００でのサービスを優先するとして、閉域網のＤＮＳサーバを優先する方法についての変形例を説明する。

図８は、変形例１におけるクライアント通信端末１００の構成を示したブロック図である。

図８に示すクライアント通信端末１００は、図２に示すクライアント通信端末１００に対して、ドメイン名保持部２０４の構成が異なる。なお、図２と同様の要素には同一の符号を付しており、詳細な説明は省略する。

ドメイン名保持部２０４は、ＣＤＮ３００のＤＮＳサーバ３１０で名前解決ができることが保証されているドメイン名を保持している。ここで、本変形例ではＣＤＮサービスを優先する場合としているので、ＣＤＮ事業者から教えられたドメイン名（例「ｗｗｗ．ｓｅｒｖｉｃｅ．ｃｄｎ」）がドメイン名保持部２０４に記録されている。

そして、広域／閉域識別部１０５では、ＣＤＮ３００のＤＮＳサーバ３１０に対して、ドメイン名保持部２０４が保持するドメイン名の名前解決を、名前解決部１０６を用いて実施する。そして、広域／閉域識別部１０５は、例えばそのドメイン名のＩＰアドレスが取得できた場合には閉域網と判断し、ＩＰアドレスが取得できなかった場合には広域網と判定する。すなわち、そのドメイン名を解決できたネットワークを閉域と判定すればよい。

その他の説明は実施の形態１と同様であるので、省略する。

ただし、上述のこの方法は、クライアント通信端末１００が、複数の閉域網に接続される場合には注意が必要である。

例えば、クライアント通信端末１００に、図９に示すようなネットワークリスト１０７が生成されているとする。なお、図９は、変形例１におけるネットワークリスト１０７が記録するデータの１例を示す図である。

図９において、クライアント通信端末１００のＩＰアドレスが「１９２．１６８．０．１０」でアクセスするネットワークは、インターネット２００につながっている。同様に、クライアント通信端末１００のＩＰアドレスが「１０．０．０．２０」および「１０．１０．０．３０」でアクセスするネットワークはＣＤＮ３００およびＣＤＮ３０１である。

この場合、ＣＤＮ事業者から教えられたドメイン名「ｗｗｗ．ｓｅｒｖｉｃｅ．ｃｄｎ」を用いて広域網であるか閉域網であるかを判定すると、「１０．０．０．２０」に対応するＤＮＳサーバだけが名前解決に成功し、「１０．１０．０．１００」に対応するＤＮＳサーバは広域と判定されてしまうことがある。これは、ＣＤＮ３００とＣＤＮ３０１とでは、ネットワークが独立である場合、すなわちドメイン名が独立に管理されている場合があるためである。

そのため、ＣＤＮ事業者から教えられたドメイン名を用いて広域網であるか閉域網であるかを判定する場合は、広域網と判定されたＤＮＳサーバ群に対し、図７で示すように広域網と判定された各ネットワークに対応するＤＮＳサーバに対してさらに問い合わせを行わなければならない。

（変形例２）
実施の形態１では、ネットワークリスト１０７には、図３で示したように、少なくともクライアント通信端末１００のＩＰアドレスと、ＤＮＳサーバのＩＰアドレスと、それらＩＰアドレスに対する識別情報とが記録されている例を説明したが、それに限らない。ネットワークリスト１０７に、図１０に示すように、過去に閉域網で名前解決したドメイン名を記録してもよい。以下、その場合を変形例２として説明する。

図１０は、変形例２におけるネットワークリスト１０７が記録するデータの１例を示す図である。

図１１は、変形例２における名前解決部１０６がネットワークリスト１０７を利用してＤＮＳサーバへの問い合わせをする処理を示したフローチャートである。なお、図１１は、基本的には図５と同様である。図５と同じ処理を行うステップには同じ番号を付しており、詳細な説明は省略する。

図１１において、名前解決部１０６は、まず、所望の接続先となるドメイン名、すなわち解決すべきドメイン名がネットワークリスト１０７に記録されているかどうかを確認する（Ｓ２０１）。具体的には、名前解決部１０６は、図１０に示すネットワークリスト１０７の解決可能ドメイン名の項目に、そのドメイン名の記録があるかどうかを確認する。

名前解決部１０６は、そのドメイン名がネットワークリスト１０７に記録されている場合（Ｓ２０１のＹｅｓの場合）、ネットワークリスト１０７においてそのドメイン名に対応するＤＮＳサーバであるが名前解決の実施は未確認であるＤＮＳサーバがあるかを確認する（Ｓ２０２）。

名前解決部１０６は、そのドメイン名に対応するが名前解決の実施は未確認であるＤＮＳサーバがある場合（Ｓ２０２のＹｅｓの場合）、そのＤＮＳサーバを抽出し（Ｓ２０３）、名前解決を実行する（Ｓ２０４）。なお、例えば主で用いられるＤＮＳサーバと予備で用いられるＤＮＳサーバとがある場合には、主で用いられるＤＮＳサーバを優先して抽出する。

次に、名前解決部１０６は、名前解決を実行したＤＮＳサーバから応答があるかどうかを確認し（Ｓ２０５）、応答がない場合には（Ｓ２０５のＮｏの場合）、Ｓ２０２に戻り、そのドメイン名に対応する他のＤＮＳサーバを用いて再び名前解決を試みる。

また、名前解決部１０６は、応答がある場合には（Ｓ２０５のＹｅｓの場合）、名前解決が成功したとして、解決したドメイン名をネットワークリスト１０７の該当する箇所に記録する。

以上のように、名前解決部１０６は、ネットワークリスト１０７を利用してＤＮＳサーバへの問い合わせを行う。

なお、Ｓ２０５における名前解決が成功した場合だけでなく、図１１（図５）のＳ２２０および図７のＳ２３７において、名前解決が成功した場合、解決したドメイン名を該当するＤＮＳサーバに対応させてネットワークリスト１０７に記録する。

以上、本変形例２によれば、解決したことがあるドメイン名をネットワークリスト１０７に記録することで、ドメイン名が名前解決できるＤＮＳサーバの確認をスキップすることができるので、名前解決の効率を上昇させることができる。

なお、実施の形態１と同様に広域網に接続されたＤＮＳサーバを優先して用いる場合、閉域網のＤＮＳサーバで解決できたドメイン名のみを記録するようにすれば、ネットワークリスト１０７の容量の節約を行うことができる。

（実施の形態２）
実施の形態１では、ＣＤＮ３００とインターネット２００とは、互いに独立したネットワークであって、ＤＮＳの管理において連携しない場合について説明した。ここでは、ＣＤＮ３００とインターネット２００とは、互いに独立したネットワークであるものの、ＤＮＳの管理において一部連携する場合について説明する。具体的には、ＣＤＮ３００におけるＤＮＳサーバ３３０からインターネット２００におけるＤＮＳサーバ群２１０に対しては連携が可能だが、逆は不可能である場合について以下説明する。

図１２は、実施の形態２におけるシステム構成を示した図である。なお、図１２は、実施の形態１における図１とほぼ同じ構成をとり、図１の説明と同じ構成要素については同じ番号を割り振り、説明を省略する。また、クライアント通信端末１００の構成については図２と同じであるため、説明を省略する。

図１２に示すシステム構成は、実施の形態１に係るシステム構成に対して、ＣＤＮ３３０の構成が異なる。

ＤＮＳサーバ３３０は、ＣＤＮ３００に設置されており、ＣＤＮ３００上のドメイン名とＩＰアドレスの対応表を管理する。また、ＤＮＳサーバ３３０は、ＤＮＳサーバ群２１０ともつながっており、ＣＤＮ３００で解決できないドメイン名に関しては、ＤＮＳサーバ群２１０に対して問い合わせを行う。ただし、ＤＮＳサーバ３３０は、ＤＮＳサーバ群２１０からの問い合わせには対処しない。

図１に示すシステム構成の場合、実施の形態１におけるネットワークリスト１０７の生成方法（図４）をそのまま使用すると、ＤＮＳサーバ３３０からＤＮＳサーバ群２１０に問い合わせができることでＤＮＳサーバ群２１０とＤＮＳサーバ３３０のいずれにおいても名前解決できてしまうため、誤動作をおこしてしまう。

そこで、実施の形態２では、クライアント通信端末１００は、誤動作は防ぎつつ、起動時におけるネットワークリスト１０７の生成方法を、図１２および図１３を用いて説明する。

図１３は、実施の形態２における起動時にネットワークリスト１０７を生成する処理を示すフローチャートである。

なお、図１３は、図４とほぼ同様のステップをとり、図４の説明と同じステップについては同じ番号を割り振り、説明を省略する。また、クライアント通信端末１００におけるＤＮＳサーバへの問い合わせ処理の方法は、図５〜図７と同じであるので、説明を省略する。

図１３において、広域／閉域識別部１０５は、Ｓ１０５の結果得られたＩＰアドレス、すなわちＤＮＳサーバに対してドメイン名保持部１０４が保持するドメイン名の名前解決を実施し、その実施の結果得られたＩＰアドレスに対して、疎通テストを実施する（Ｓ１１０）。ここで、疎通テストとは、例えばコマンド「Ｐｉｎｇ」を用いてネットワークが疎通しているかどうかを確認するテストであり、ＴＣＰレベルで接続状態を確認するテストである。

次に、図１４を用いて図１３におけるＳ１１０の詳細な動作について説明する。

図１４は、図１３におけるＳ１１０の詳細を示すフローチャートである。

広域／閉域識別部１０５は、Ｓ１０５の結果、名前解決を実施したドメイン名のＩＰアドレスが取得できたかを判定する（Ｓ１１１）。なお、広域／閉域識別部１０５は、Ｓ１１１で名前解決を実施したドメイン名のＩＰアドレスが取得できないと判定する場合（Ｓ１１１のＮｏの場合）、ネットワークリスト１０７において、名前解決を実施したＤＮＳサーバの識別情報を「閉域」と記録する（Ｓ１１５）。

広域／閉域識別部１０５は、名前解決を実施したドメイン名のＩＰアドレスが取得できた場合（Ｓ１１１のＹｅｓの場合）、そのＩＰアドレスに対して疎通確認を実施し（Ｓ１１２）、疎通ができたかを確認する（Ｓ１１３）。

次に、広域／閉域識別部１０５は、疎通ができていれば（Ｓ１１３のＹｅｓの場合）、ネットワークリスト１０７に、ＤＮＳサーバの識別情報を「広域網」と記録する（Ｓ１１４）。

なお、広域／閉域識別部１０５は、Ｓ１１３で疎通が確認できなかった場合（Ｓ１１３のＮｏの場合）、ネットワークリスト１０７において、名前解決を実施したＤＮＳサーバの識別情報を「閉域」と記録する（Ｓ１１５）。

以上のようにして、クライアント通信端末１００は、起動時におけるネットワークリスト１０７の生成の処理を行う。

以上、実施の形態２によれば、疎通テストをさらに行い、各ＤＮＳサーバが広域網か閉域網かに設置されていることを確認することで、互いに独立した複数のネットワークが、ＤＮＳの管理において一部連携する場合でも、ドメイン名の解決を効率よく実施することができる。

以上のように、クライアント通信端末がＤＮＳ体系の異なる複数のネットワークに接続する場合、そのクライアント通信端末には複数のＩＰアドレスと複数のＤＮＳサーバが割り当てられる。そのため、複数のＤＮＳサーバをどのような順番で使用するかを決める必要がある。本発明では、インターネット（広域網）のＤＮＳサーバと、閉域網のＤＮＳサーバとに分離して、順番付けて名前解決を実施する。

すなわち、インターネット上のＤＮＳサーバであるかを見分けるために、クライアント通信端末の起動時（設置時）において、クライアント通信端末に割り当てられたＤＮＳサーバに対して、予めインターネットのＤＮＳ管理団体に登録しているドメイン名を用いて名前解決を行う。それにより、割り当てられたＤＮＳサーバが、インターネットに接続されているＤＮＳサーバか否かを判定する。以後、所望の接続先となるドメイン名に対して名前解決を行う度に、例えばインターネット上のＤＮＳサーバを閉域網のＤＮＳサーバより先に使用して、すなわち順番付けて名前解決を行う。

以上、本発明によれば、複数のネットワークにおいて独立に管理されているドメイン名の名前解決を、ネットワークおよびユーザに余計な負荷をかけずに効率よく実行する通信装置およびその通信方法を実現することができる。

なお、本発明は、装置として実現するだけでなく、このような装置が備える処理手段を備える集積回路として実現したり、その装置を構成する処理手段をステップとする方法として実現したり、それらステップをコンピュータに実行させるプログラムとして実現したり、そのプログラムを示す情報、データまたは信号として実現したりすることもできる。そして、それらプログラム、情報、データおよび信号は、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の通信媒体を介して配信してもよい。

本発明は、通信装置およびその通信方法に利用でき、特に、互いに独立した複数のネットワークであってその複数のネットワークにおいて独立に管理されているドメイン名であっても効率よく解決でき、例えばインターネットサービスとＣＤＮとを利用したＩＰ放送サービス等に対応できる通信装置および通信方法に利用することができる。

実施の形態１におけるシステム構成を示した図である。 実施の形態１におけるクライアント通信端末の構成を示したブロック図である。 実施の形態１におけるネットワークリストが記録されるデータの１例を示す図である。 実施の形態１におけるネットワークリストの生成する処理を示したフローチャートである。 実施の形態１におけるＤＮＳサーバへの問い合わせ処理を示すフローチャートである。 図５におけるＳ２１０の詳細を示すフローチャートである。 図５におけるＳ２３０の詳細を示すフローチャートである。 変形例１におけるクライアント通信端末の構成を示したブロック図である。 変形例１におけるネットワークリストが記録されるデータの１例を示す図である。 変形例２におけるネットワークリストが記録されるデータの１例を示す図である。 変形例２における名前解決部１０６がネットワークリストを利用してＤＮＳサーバへの問い合わせをする処理を示したフローチャートである。 実施の形態２におけるシステム構成を示した図である。 実施の形態２における起動時にネットワークリストの生成する処理を示したフローチャートである。 図１３におけるＳ１１０の詳細を示すフローチャートである。

１００ クライアント通信端末
１０１、１０２ 通信インタフェース
１０３ ＩＰ設定部
１０４、２０４ ドメイン名保持部
１０５ 広域／閉域識別部
１０６ 名前解決部
１０７ ネットワークリスト
２００ インターネット
２１０ ＤＮＳサーバ群
２２０、３２０ ＤＨＣＰサーバ
３００ ＣＤＮ
３１０、３３０ ＤＮＳサーバ

Claims (7)

1. ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）体系が互いに異なる２以上のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークに接続され、前記２以上のＩＰネットワークのいずれかを介して他の通信装置と通信する通信装置であって、
   所定のＩＰネットワークで名前解決ができることが保証されているドメイン名を用いて、前記ドメイン名の名前解決が成功するか否かを前記２以上のＩＰネットワークに順番に接続して確認することにより、前記ドメイン名の名前解決が成功したＩＰネットワークを第１域網、前記ドメイン名の名前解決が成功しなかったＩＰネットワークを第２域網として識別する識別部と、
   他の通信装置と通信を開始するのに先だって、前記第１域網と識別されたＩＰネットワークから優先して名前解決を試み、名前解決が成功したＩＰネットワークを介して他の通信装置と通信する通信制御部とを備える
   ことを特徴とする通信装置。
2. 前記識別部は、
   ＩＰネットワークの前記ドメイン名の名前解決が成功するときに取得するＩＰアドレスに対して、疎通確認を実行する疎通確認部を有し、
   前記ドメイン名の名前解決が成功し、かつ、前記疎通確認部による疎通確認が成功した場合に、当該ＩＰネットワークを第１域網として識別する
   ことを特徴とする請求項１に記載の通信装置。
3. 前記通信装置は、
   前記識別部の識別結果を保持する保持部を備え、
   前記通信制御部は、前記識別結果に基づいて、前記名前解決を試みる
   ことを特徴とする請求項１または２に記載の通信装置。
4. 前記保持部は、前記２以上のＩＰネットワークごとに対応する、ＤＮＳサーバ装置のＩＰアドレスと前記通信装置のＩＰアドレスとを含むＩＰネットワーク情報を、前記識別結果とともに保持する
   ことを特徴とする請求項３に記載の通信装置。
5. 前記第１域網は、インターネットのＩＰネットワークである
   ことを特徴とする請求項１または２に記載の通信装置。
6. 前記第１域網は、ＣＤＮ（Ｃｏｎｔｅｎｔｓ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）のＩＰネットワークである
   ことを特徴とする請求項１または２に記載の通信装置。
7. ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）体系が互いに異なる２以上のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークに接続され、前記２以上のＩＰネットワークのいずれかを介して他の通信装置と通信する通信方法であって、
   所定のＩＰネットワークで名前解決ができることが保証されているドメイン名を用いて、前記ドメイン名の名前解決が成功するか否かを前記２以上のＩＰネットワークに順番に接続して確認することにより、前記ドメイン名の名前解決が成功したＩＰネットワークを第１域網、前記ドメイン名の名前解決が成功しなかったＩＰネットワークを第２域網として識別する識別ステップと、
   他の通信装置と通信を開始するのに先だって、前記第１域網と識別されたＩＰネットワークから優先して名前解決を試み、名前解決が成功したＩＰネットワークを介して他の通信装置と通信する通信制御ステップとを含む
   ことを特徴とする通信方法。

Images