(57)【要約】ネットワークにおける伝送方式を自動的にセンスする方法。当該方法には、少なくとも１つのパケットを第１ホストに第１伝送方式で送出するステップと、少なくとも１つのパケットを当該第１ホストに第２伝送方式で送出するステップと、応答が受信された場合に前記第２伝送方式に従って前記第１ホストと通信を行なうように構成するステップとが含まれる。
2005503682.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにおける伝送方式を自動的にセンスする方法において、
少なくとも１つのパケットを第１ホストに第１伝送方式で送出するステップと、
少なくとも１つのパケットを前記第１ホストに第２伝送方式で送出するステップと、
前記第２伝送方式で送出された前記パケットに対する応答が受信された場合に、前記第１ホストと前記第２伝送方式で通信するために構成するステップと
を備えたことを特徴とする方法。
【請求項２】
請求項１において、前記構成するステップは、前記第２伝送方式で送出されたパケットに対する応答が受信されなかった場合に、前記第１ホストとの間での通信を前記第１伝送方式に従って行なうように構成するステップをさらに含むことを特徴とする方法。
【請求項３】
請求項１において、少なくとも１つのパケットを第１ホストに第１伝送方式で送出するステップは、前記第１伝送方式で送出された前記パケットに対する応答を前記第１ホストから受信するステップをさらに含むことを特徴とする方法。
【請求項４】
請求項３において、前記受信するステップは、さらに、前記第２伝送方式で送出されたパケットに対する応答が受信された場合に、前記第１ホストと前記第２伝送方式で通信するために構成するステップをさらに含むことを特徴とする方法。
【請求項５】
請求項３において、少なくとも１つのパケットを前記第１ホストに第２伝送方式で送出するステップは、前記第２伝送方式で送出されたパケットに対する応答を前記第１ホストから受信するステップをさらに備えたことを特徴とする方法。
【請求項６】
請求項５において、前記第２伝送方式で送出されたパケットに対する応答は、アドレスを備えたことを特徴とする方法。
【請求項７】
請求項６において、前記構成するステップは、前記第１ホストとの通信を、前記応答から得られた前記アドレスを用いて行なうために構成するステップをさらに備えたことを特徴とする方法。
【請求項８】
請求項３において、前記第２伝送方式で送出されたパケットに対する応答は、受信されないことを特徴とする方法。
【請求項９】
請求項８において、前記構成するステップは、前記第１ホストと前記第１伝送方式で通信するために構成するステップを備えたことを特徴とする方法。
【請求項１０】
請求項８において、前記第１伝送方式で送出されたパケットに対する応答は、アドレスを備えたことを特徴とする方法。
【請求項１１】
請求項１０において、前記構成するステップは、前記応答から得られたアドレスを用いて前記第１ホストとの間での通信を構成するステップをさらに含むことを特徴とする方法。
【請求項１２】
請求項１において、前記第２伝送方式で送出されたパケットに対する応答は、前記第１ホストから受信されることを特徴とする方法。
【請求項１３】
請求項１２において、前記応答は、アドレスを含むことを特徴とする方法。
【請求項１４】
請求項１３において、前記構成するステップは、前記応答から得られたアドレスを用いて前記第１ホストと通信するために構成するステップをさらに備えたことを特徴とする方法。
【請求項１５】
請求項１３において、前記第１伝送方式で送出されたパケットに対する応答は、受信されないことを特徴とする方法。
【請求項１６】
請求項１５において、前記構成するステップは、前記第１ホストと前記第２伝送方式で通信するために構成するステップを備えたことを特徴とする方法。
【請求項１７】
請求項１において、前記第１伝送方式で送出されたパケットに対する応答は、受信されないことを特徴とする方法。
【請求項１８】
請求項１７において、前記構成するステップは、前記第１伝送方式で送出されたパケットに対する応答が受信された場合に、前記第１ホストと前記第１伝送方式で通信するために構成するステップを備えたことを特徴とする方法。
【請求項１９】
請求項１８において、前記第２伝送方式で送出されたパケットに対する応答は、受信されないことを特徴とする方法。
【請求項２０】
請求項１９において、前記構成するステップは、前記第１ホストと前記第１伝送方式で通信するために構成するステップを含むことを特徴とする方法。
【請求項２１】
請求項１において、前記第１伝送方式は、ユニキャスト伝送方式であることを特徴とする方法。
【請求項２２】
請求項１において、前記第２伝送方式は、マルチキャスト伝送方式であることを特徴とする方法。
【請求項２３】
請求項１において、少なくとも１つのパケットを第１ホストに第１伝送方式で送出するステップは、前記第１ホストから成功応答が受信されるまで、所定の個数のパケットを前記第１ホストに前記第１伝送方式で送出するステップをさらに含むことを特徴とする方法。
【請求項２４】
請求項１において、少なくとも１つのパケットを前記第１ホストに第２伝送方式で送出するステップは、前記第１ホストから成功応答が受信されるまで、所定の個数のパケットを前記第１ホストに前記第２伝送方式で送出するステップをさらに含むことを特徴とする方法。
【請求項２５】
複数個のホストを含むネットワークにおける伝送方式を自動的にセンスする方法において、
第１ホストにより少なくとも１つのパケットを第２ホストに第１伝送方式で送出するステップと、
前記第１ホストにより少なくとも１つのパケットを前記第２ホストに第２伝送方式で送出するステップと、
前記第２伝送方式で送出されたパケットに対する応答が受信された場合に、前記第２ホストと前記第２伝送方式で通信するため、前記第１ホストを構成するステップと
を備えたことを特徴とする方法。
【請求項２６】
請求項２５において、前記構成するステップは、前記第２伝送方式で送出されたパケットに対する応答が受信されなかった場合に、前記第２ホストと前記第１伝送方式で通信するため、前記第１ホストを構成するステップをさらに含むことを特徴とする方法。
【請求項２７】
請求項２５において、前記第１伝送方式で送出されたパケットに対する応答は、受信されないことを特徴とする方法。
【請求項２８】
請求項２７において、前記第２伝送方式で送出されたパケットに対する応答は、受信されないことを特徴とする方法。
【請求項２９】
請求項２８において、前記構成するステップは、前記第２ホストと前記第１伝送方式で通信するために構成するステップを備えたことを特徴とする方法。
【請求項３０】
請求項２８において、前記構成するステップは、利用可能なアドレスを用いて、前記第２ホストと通信するために、前記第１ホストを構成するステップをさらに備えたことを特徴とする方法。
【請求項３１】
請求項２５において、前記第１伝送方式は、ユニキャスト伝送方式であることを特徴とする方法。
【請求項３２】
請求項２５において、前記第２伝送方式は、マルチキャスト伝送方式であることを特徴とする方法。
【請求項３３】
複数個のホストを含むネットワークにおける伝送方式を自動的にセンスする方法において、
第１ホストが第１伝送方式で第２ホストから送出されたパケットを受信するステップと、
前記第１ホストが少なくとも１つのパケットを前記第２ホストに第２伝送方式で送出するステップと、
前記第２伝送方式で送出されたパケットに対する応答が受信された場合に、前記第２ホストと前記第２伝送方式で通信するために構成するステップと
を備えたことを特徴とする方法。
【請求項３４】
請求項３３において、前記構成するステップは、前記第２伝送方式で送出されたパケットに対する応答が受信されなかった場合に、前記第２ホストと前記第１伝送方式で通信するため、前記第１ホストを構成するステップをさらに含むことを特徴とする方法。
【請求項３５】
ネットワークにおける伝送方式を自動的にセンスする方法において、
少なくとも１つの第１パケットを第１ホストに第１伝送方式で送出するステップと、
第２伝送方式で送出された第２パケットを前記第１ホストから受信するステップと、
前記第１ホストと前記第２伝送方式で通信するために構成するステップと
を備えたことを特徴とする方法。
【請求項３６】
ネットワークにおいて伝送方式を自動的にセンスするための命令を含むコンピュータ可読媒体において、
少なくとも１つのパケットを第１ホストに第１伝送方式で送出するステップと、
少なくとも１つのパケットを前記第１ホストに第２伝送方式で送出するステップと、
前記第２伝送方式で送出されたパケットに対する応答が受信された場合に、前記第１ホストと前記第２伝送方式で通信するために構成するステップと
を備えたことを特徴とするコンピュータ可読媒体。
【請求項３７】
請求項３６において、前記構成するステップは、前記第２伝送方式で送出されたパケットに対する応答が受信されなかった場合に、前記第１ホストと前記第１伝送方式で通信するために構成するステップをさらに含むことを特徴とするコンピュータ可読媒体。
【請求項３８】
請求項３６において、少なくとも１つのパケットを前記第１ホストに前記第１伝送方式で送出するステップは、前記第１伝送方式で送出されたパケットに対する応答を前記第１ホストから受信するステップをさらに含むことを特徴とするコンピュータ可読媒体。
【請求項３９】
請求項３８において、前記受信するステップは、前記第２伝送方式で送出されたパケットに対する応答が受信された場合に、前記第１ホストと前記第２伝送方式で通信するために構成するステップをさらに含むことを特徴とするコンピュータ可読媒体。
【請求項４０】
請求項３８において、少なくとも１つのパケットを前記第２伝送方式で送出するステップは、前記第２伝送方式で送出されたパケットに対する応答を前記第１ホストから受信するステップをさらに備えたことを特徴とするコンピュータ可読媒体。
【請求項４１】
請求項４０において、前記第２伝送方式で送出されたパケットに対する応答は、アドレスを備えたことを特徴とするコンピュータ可読媒体。
【請求項４２】
請求項４１において、前記構成するステップは、前記第１ホストとの通信を前記応答から得られたアドレスを用いて行なうために構成するステップをさらに備えたことを特徴とするコンピュータ可読媒体。
【請求項４３】
請求項３８において、前記第２伝送方式で送出されたパケットに対する応答が受信されないことを特徴とするコンピュータ可読媒体。
【請求項４４】
請求項４３において、前記構成するステップは、前記第１伝送方式に従って前記第１ホストと通信をするために構成するステップを備えたことを特徴とするコンピュータ可読媒体。
【請求項４５】
請求項４４において、前記第１伝送方式で送出されたパケットに対する応答は、アドレスを備えたことを特徴とするコンピュータ可読媒体。
【請求項４６】
請求項４５において、前記構成するステップは、前記応答から得られたアドレスを用いて前記第１ホストと通信するために構成するステップをさらに含むことを特徴とするコンピュータ可読媒体。
【請求項４７】
請求項３６において、前記第２伝送方式で送出されたパケットに対する応答は、前記第１ホストから受信されることを特徴とするコンピュータ可読媒体。
【請求項４８】
請求項４７において、前記応答は、アドレスを備えたことを特徴とするコンピュータ可読媒体。
【請求項４９】
請求項４８において、前記構成するステップは、前記応答から得られたアドレスを用いて前記第１ホストと通信するために構成するステップをさらに備えたことを特徴とするコンピュータ可読媒体。
【請求項５０】
請求項４７において、前記第１伝送方式で送出されたパケットに対する応答は、受信されないことを特徴とするコンピュータ可読媒体。
【請求項５１】
請求項５０において、前記構成するステップは、前記第１ホストと前記第２伝送方式で通信するため構成するステップを備えたことを特徴とするコンピュータ可読媒体。
【請求項５２】
請求項３６において、前記第１伝送方式で送出されたパケットに対する応答は、受信されないことを特徴とするコンピュータ可読媒体。
【請求項５３】
請求項５２において、前記構成するステップは、前記第１伝送方式で送出されたパケットに対する応答が受信された場合に前記第１伝送方式に従って前記第１ホストとの間での通信を構成するステップを含むことを特徴とするコンピュータ可読媒体。
【請求項５４】
請求項５２において、前記第２伝送方式で送出されたパケットに対する応答は、受信されないことを特徴とするコンピュータ可読媒体。
【請求項５５】
請求項５４において、前記構成するステップは、前記第１ホストと前記第１伝送方式で通信するために構成するステップを備えたことを特徴とするコンピュータ可読媒体。
【請求項５６】
請求項３６において、前記第１伝送方式は、ユニキャスト伝送方式であることを特徴とするコンピュータ可読媒体。
【請求項５７】
請求項３６において、前記第２伝送方式は、マルチキャスト伝送方式であることを特徴とするコンピュータ可読媒体。
【請求項５８】
請求項３６において、少なくとも１つのパケットを前記第１ホストに前記第１伝送方式で送出するステップは、前記第１ホストから成功応答が受信されるまで、所定数のパケットを前記第１ホストに前記第１伝送方式で送出するステップをさらに含むことを特徴とするコンピュータ可読媒体。
【請求項５９】
請求項３６において、少なくとも１つのパケットを前記第１ホストに前記第２伝送方式で送出するステップは、前記第１ホストから成功応答が受信されるまで、所定数のパケットを前記第１ホストに前記第２伝送方式で送出するステップをさらに含むことを特徴とするコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信の分野に関し、特に、ネットワーク通信のための伝送方式を判定する分野に関する。
【背景技術】
【０００２】
今日用いられている最も一般的なネットワークプロトコルの１つがＴＣＰ／ＩＰである。ＴＣＰ／ＩＰスイート（suite）は、典型的には、アプリケーション層と、トランスポート層と、ネットワーク層と、リンク層との４層より構成されている。
【０００３】
アプリケーションレベルでは、ソースアプリケーションからデスティネーションアプリケーション（あるいは、同一のアプリケーションの別のインスタンス）に、データが送出されることを、ユーザが要求すると、ソースアプリケーションは、それ自体のルーチンに従って、デスティネーションアプリケーションによって読み取られるようにデータをパッケージ化する。ソースアプリケーションによってパッケージ化されると、そのパッケージ化されたデータはトランスポート層に送られ、トランスポート層はそのデータをホスト間の伝送に適するようにパッケージ化する。このトランスポート層においては、デスティネーションアドレス情報が、パッケージ化されたデータに付加される。より詳細には、ＩＰアドレスがデスティネーションホストを識別し、ポートアドレスが当該データの送付先となるアプリケーションを識別する。その後、データパッケージはネットワーク層に送られ、ネットワーク層は、当該データパッケージをネットワークを介してデスティネーションホストにルーティングするために必要となる情報を付加する。最後に、リンク層は、インタフェースが当該パケットを実際に送出するために必要となるコマンド及び情報を供給する。当該データパッケージがデスティネーションホストに到達すると、デスティネーションアプリケーションが、当該パッケージ中に含まれるデータをデコードできるように、各層が剥ぎ取られる。
【０００４】
ＴＣＰ／ＩＰスイートにおいては、the Internetを介してアプリケーションデータをトランスポートするための２つの主要なトランスポートレベルプロトコル、すなわちＴＣＰ（transmission control protocol）及びＵＤＰ（user datagram protocol）が存在する。ＴＣＰは２つのホスト間の「コネクション（connection）」の概念に基づいており、このプロトコルを用いても、ホストは、（１）データが経路途中で失われるか、あるいは（２）データが送出されたときと異なる順序で受信される、という可能性がなく、互いに、データをリライアブル（reliable）に送出することができる。例えば、ＴＣＰは、事実上全てのｗｅｂブラウジング、ファイル転送、及びemail伝送に用いられる。
【０００５】
他方、ＵＤＰは、下層のＩＰモデルに基づいており、このＩＰモデルにおいては、データは個別のパケットとしてホストからホストへ送出される。ＵＤＰにおいては、パケットは、（１）デスティネーションに到達しなかったり、（２）１回しか送出されていないにも拘わらず複数回到達したり、（３）遅く送出された方のパケットが早く送出されたパケットより早く到達したりする。データが全てデスティネーションに到達することは、重要なことでない（これは、アプリケーションがパケット喪失を検出してリカバーするからである。）とのコンテキストにおいて、あるいは、ＴＣＰの伝送レイテンシコスト（例えば、コネクションのセットアップ、データ再伝送、等）が許容できないとのコンテキストにおいて、ＵＤＰが使用される。ＵＤＰを用いる今日のthe Internetにおける伝送のタイプの共通する例は、ストリーミング・オーディオ・ビデオ・データの伝送である。
【０００６】
ＵＤＰにおいては、データパケットがアドレシングされ配送される２つの主要な方式としては、ユニキャスト（unicast）とマルチキャスト（multicast）が存在する。両方式において、ＵＤＰパケットには、それぞれ、ソース及びデスティネーションアドレス情報と、ＵＤＰ「ポート」番号とが含まれている。
【０００７】
このユニキャスト方式においては、送出側アプリケーションは、そのホスト自体のＩＰアドレスと、アプリケーション自体のＵＤＰポート番号とを、ソースアドレシング情報として利用する。送出側アプリケーションは、この送出側アプリケーションが通信しようとするリモートホストのＩＰアドレスと、当該データを受信しようとするホスト上の特定のアプリケーションのＵＤＰポート番号とを、デスティネーションアドレシング情報として使用している。当該データパケットが送出されると、当該ネットワークは、「ベストエフォート（best effort）」を行って、そのデスティネーションアドレス情報に記述されたホスト及びアプリケーションに、当該パケットを配送する。
【０００８】
このマルチキャスト方式においては、ソースアドレシング情報の構成は、ユニキャスト方式と全く同一であるが、デスティネーション情報は異なる。ここでは、特定のＩＰアドレスセットのうちの１つのＩＰアドレスセットが、単一のホストを記述するためでなく、ホストセットの全体を記述するために使用されている。これらのマルチキャストアドレスは、ラジオ周波数のように機能している。すなわち、人がラジオ受信機を特定の周波数に同調させるのと全く同様にして、当該ネットワークに接続されたホストは、個々に、事前通知がなくても、セントラルコーディネーション（central coordination）がなくても、特定のマルチキャストアドレスに対して送出されたものを受信するとのインタレスト（interest）を動的に登録することができる。ＵＤＰパケットが、マルチキャストアドレスをデスティネーションアドレシング情報として用いて送出されると、当該ネットワークは、インタレストをそのアドレスに登録した全てのホストに対して、当該パケットのうちの１つのコピーを配送するように「ベストエフォート」を行なう。さらに、当該ネットワークは、当該配送を効率的に行って、特定のネットワークリンクを介して、当該パケットのコピーを１つだけ送出しようとする。伝送された同一のデータに対して受信者が複数いるアプリケーションにおいては、同一のパケットの複数個のコピーを、ユニキャストによって受信者にそれぞれ送出するよりも、単一のコピーをマルチキャストによって送出する方が、はるかに効率的である。マルチキャストで伝送するところを、ユーザがユニキャストでの伝送を表明することが有用なこともあるが、ほとんどの環境においては、全てのmulticast-capableなクライアントがマルチキャストを使用し、non-multicast-capableなクライアントのみがユニキャストを使用できるのが良い。
【０００９】
加えて、重要なことは、多くのアプリケーションにおいて、当該サーバが、当該サーバの受信する各データパケットのソースを決定することができることである。異なるクライアントからのパケットのハンドル（handle）は、サーバによってそれぞれ異ならせることができる（パケット、例えば、登録されたクライアントからのものではないパケットの中には、全く無視できるものがある。）。さらに、あるネットワークコンポーネントと、ネットワークアーキテクチャと、ネットワークアプリケーションとが、クライアントの送出するパケットにおいて見い出されるソースアドレスに対して、影響を及ぼすことができるので、これにより状況が複雑になっている。具体的には、multi-homedコンピュータ（すなわち、２つ以上のＩＰアドレスを有するコンピュータであって、通常、各アドレスが、異なるネットワークインタフェースに割り当てられているコンピュータ）は、当該クライアントが利用するべきソースアドレスに、影響を及ぼすことができる。例えば、ホストは、１つ以上のEthernet（登録商標）カードか、ダイヤルアップモデムか、又はこれを組み合わせたものとすることができる。multi-homedコンピュータ上のアプリケーションがネットワークパケットを送出するとき、当該パケット中のソースＩＰアドレスは、利用可能なインタフェースとすることができる。ソースアドレスの選択は、幾つかのファクタにより決定されている。これら幾つかのファクタとしては、どのインタフェースが現行においてイネーブルであるか（例えば、Ethernet（登録商標）カードにケーブルが接続されていないかもしれないし、又はダイヤルアップモデムが、現在、電話（phone call）に従事しないかもしれない）、及び当該ネットワークのルーティングトポロジー（例えば、サーバが、１つのEthernet（登録商標）コネクションからクライアントにリーチャブル（reachable）にできるが、他のEthernet（登録商標）コネクションからはリーチャブルにできなく、あるいは、当該サーバは、１つのEthernet（登録商標）コネクションを介することにより、ネットワークホップという点で、別のサーバより近くすることができる。）が含まれている。ＵＤＰパケットを伝送するのにどのソースＩＰアドレスを用いるかを事前に決定することは、アプリケーションにとって可能でないことがよくある。ほとんどのオペレーティングシステムは、アプリケーションがこの情報を直接獲得するためのメカニズムを、提供しない。
【００１０】
当該ネットワークがＮＡＴ（network address translator）デバイスを利用すると、クライアントがソースアドレスを選択することに対して影響を及ぼす。セキュリティ上の理由と、大きいブロックのグローバルＩＰアドレスを獲得することが困難であるとの理由とを含めた種々の理由から、多くの組織では、内部において、private-use-only ＩＰアドレス範囲を使用している。その結果、当該ネットワーク内で用いられるＩＰアドレスは、多く場合、当該ローカルネットワーク外では無効になる。この問題を改善するため、インターナルネットワークとパブリックInternetとの間の境界にある、組織やＬＡＮの中には、ＮＡＴデバイスをディプロイ（deploy）しているものがある。このＮＡＴデバイスは、ローカルＩＰアドレス、すなわちprivate-use-only ＩＰアドレスを、利用可能なグローバルに有効なグローバルＩＰにマッピングしている。ＮＡＴデバイスを用いると、このローカルネットワークのクライアントというユーザは、このローカルネットワーク外のクライアントに対して、このローカルネットワークのローカルＩＰアドレスを、グローバルに有効であるか否かにかかわらず使用して、通信を送ることができる。このＮＡＴデバイスは、そのローカルアドレスをグローバルに有効なアドレスに透過的にマッピングし、そのグローバルに有効なアドレスに対して、通信を送っている。当該クライアントからの応答（response）は、ＮＡＴデバイスのグローバルに有効なＩＰアドレスに到達する。当該ＮＡＴデバイスは、オリジナルの送出者に通信を送るため、当該アドレスをローカルＩＰアドレスにマッピングする。当該ＮＡＴデバイスによりマッピングされた結果として、クライアントが、当該クライアントが当該ＮＡＴデバイスと通信するとき、どのソースＩＰアドレスが所定のサーバによって見られることになるかを、事前に、決定することは、非常に困難になる虞がある。
【００１１】
ピア・ツー・ピアＵＤＰアプリケーションにおいては、データは、ＵＤＰによって、クライアントのグループの間を、デジタルネットワークを介して伝送される。１つのクライアントによって伝送されたデータの各パケットは、他の全てのクライアントによって受信されるようになっている。例えば、マルチパーティ・オーディオカンバセーション・アプリケーションにおいては、１つのユーザによる各発声を表わすデジタルオーディオサンプルは、同一のカンバセーションに参加している他の全てのユーザに伝送されるべきである。伝送されたデータパケットは、それぞれ、複数のデスティネーションに配信されるから、このようなアプリケーションは、マルチキャストによって提供される機能によくマッチしている。残念ながら、マルチキャスト配信は、現在では、the Internet上のどこにおいてもサポートされているわけではない。さらに悪いことには、１つのホストは、当該ホストと、ネットワーク上の他の特定のホストとの間において、マルチキャスト配信がサポートされているか否かを事前に知ることはできない。
【００１２】
その結果、このような大部分のアプリケーションは、マルチキャスト配信の使用についてその可能性を無視しているのであって、専らユニキャスト配信に依拠しており、このため、マルチキャスト配信が可能な場面でマルチキャスト配信を用いればできたであろう帯域幅の節約ができない。
【００１３】
有用な代替策によれば、multicast-capableなクライアントは、それぞれマルチキャストを用いることができ、他方、non-multicast-capableなクライアントは、ユニキャストを用いることができる。このことを実現するため、サーバは、マルチキャストを用いることができるクライアントと、マルチキャストを用いることができないクライアントとの間の一種のゲートウェイとしてアクト（act）する。
【００１４】
技術的にみれば、本質的に全てのクライアントは、マルチキャストを用いる能力を有するが、これらクライアント間のネットワークが、マルチキャストトラフィックを搬送する能力はない（又は、搬送できない。）。理論的に最悪のケースにおいては、マルチキャストコネクティビティ（multicast connectivity）は、全てのクライアントペアの間で独立して、イネーブル又はディセーブルにすることができる。しかしながら、このことは、ネットワークを設計する上で用いられる通常の基準、例えば、帯域幅を効率的に使用することや、ネットワーク内のコンピュータ間での一貫性（consistency）を、無視して構成されているネットワーク（あるいは、ネットワークのセット）においてのみ、可能である。そこで、各クライアントが、サーバに対して、マルチキャストにより通信することができるか否かを判定すれば充分である。適正に構成されているネットワークにおいて、仮に２つの異なるクライアントが、それぞれ、サーバと通信するためマルチキャストを用いることができる場合には、これらクライアントは、互いに通信するため、当然、マルチキャストを用いることができる。
【００１５】
multicast-capableなクライアントがパケットを送出する場合には、サーバは（他のmulticast-capableなクライアントからの全てのパケットと共に）そのパケットを受信し、当該パケットのコピーを、non-multicast-capableな各クライアントに、ユニキャストによって送出する。non-multicast-capableなクライアントがパケットを送出しようとする場合には、必ず、ユニキャストによってサーバに送出する。そして、当該サーバは、１つのコピーをマルチキャストでmulticast-capableの全てのクライアントに同時に送出し、他のコピーをnon-multicast-capableな他の全てのクライアントにそれぞれユニキャストで送出する。このようにして（全てのＵＤＰ伝送において本質的であり、ネットワークにおける潜在的なパケット喪失を無視する）、クライアントによって（multicast-capableか否かを問わず）送出されたパケットは、究極的には、他の全てのクライアントによって受信されることになる。同時に、全体的なネットワーク利用率は、前述したオールユニキャスト（all-unicast）アプローチに比して、低下する。
【００１６】
このハイブリッド・ユニキャスト／マルチキャスト・アプローチにおいては、当該サーバは、non-multicast-capableな全てのクライアントを含むリストが必要であり、受信したパケットをどこに再送出するかを知ることができる。当該サーバが、multicast-capableな全てのクライアントを含むリストを有することも、同様に有用である。そのリストが空である場合には、当該サーバは、受信したユニキャストパケットをマルチキャストで再送出することを回避することができ、さらにネットワーク利用率が低下する。これらリストを維持するための簡単なメカニズムには、クライアントが当該アプリケーションにジョイン（join）するとき、当該クライアントを、（例えば幾つかのリライアブルな通信メディア、例えばＴＣＰコネクションにより）、当該サーバに登録し、当該アプリケーションから離脱するとき、当該サーバに抹消登録することが、要請される。各クライアントに対して、当該サーバは、当該クライアントとの間の伝送がユニキャスト又はマルチキャストのいずれで送出されるかを知る必要があり、しかも当該クライアントのＩＰアドレス及び（ユニキャスト）ＵＤＰポートを知る必要がある。後者は、（１）ユニキャストクライアントに対しては、当該サーバは、当該クライアント宛のパケットをどこに再送出するかを知るため、（２）全てのクライアントに対して、当該サーバによって受信された全てパケットがどのクライアントによって送出されたものであるかを判別するため、及び（３）当該サーバにより受信されたパケットが、登録されたクライアントからのものでないとき、当該サーバがこのパケットを無視できるようにするため、必要である。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
ユーザが、マルチキャスト伝送を行える場面でユニキャスト伝送を選択すると表明することは、場合によっては有用であるが、通常は、multicast-capableな全てのクライアントがマルチキャストを使用して、ユニキャストは、non-multicast-capableなクライアントにのみに使用させることが、望ましい。しかしながら、大多数のユーザには、そのクライアント及び／又はネットワークが特定のアプリケーションのコンテキストにおいてmulticast-capableなか否かを決定する能力がない。同様に、ほとんどのユーザには、自身のコンピュータがmulti-homedであるか否かを判定する能力がなく、仮にこのような能力があったとしても、複数個の利用可能なＩＰアドレスのうちのいずれが特定のアプリケーションのコンテキストにおいて用いられるかを判定する能力はない。最後に、ほとんどのユーザには、自身のコンピュータとのネットワーク伝送が特定のアプリケーションのコンテキストにおいてＮＡＴユニットを通過するか否かを判定する能力がなく、仮にこのような能力があったとしても、ＮＡＴユニットによる修正がどのような形態をとるかを判定する能力はない。要するに、従来技術は、ネットワークを介したパケット通信を充分に最適化する上で、コンピュータユーザをアシスト（assist）しない。
【００１８】
そこで、従来技術におけるこのような問題点及びその他の問題点を解消し、ネットワークを介した通信をシームレスに最適化する効率的な方法を提供する必要がある。本発明は、以下に説明するが、前述した問題点を解消しようとするものである。
【課題を解決するための手段】
【００１９】
本発明は、ネットワークにおいて伝送方式を自動的にセンスする方法に係るものであり、本発明には、少なくとも１つの第１パケットを第１ホストに第１伝送方式で送出するステップと、少なくとも１つの第２パケットを前記第１ホストに第２伝送方式で送出するステップと、前記第２伝送方式に従って送出されたパケットに対する応答が受信された場合に、前記第２伝送方式に従って前記第１ホストと通信するために構成するステップとが含まれる。
【００２０】
本発明の追加の目的及び利点は、その一部を以下に記述し、一部は以下の記述から顕著であり、あるいは、本発明を実施することにより知ることができる。本発明の目的及び利点は、特許請求の範囲において特に指摘した要素とそれらを組み合わせたものとにより、理解され達成される。
【００２１】
上述の一般的な記述、及び以下の詳細な記述は、例及び説明にすぎず、本発明を制限するものではない、ことは当然のことである。
【００２２】
添付図面は、本明細書の一部であってその一部を構成しており、本発明の幾つかの実施の形態を示すものであり、本記述とともに、本発明の原理を説明するために供されている。
【発明を実施するための最良の形態】
【００２３】
以下、本発明の実施の形態を詳細に説明するが、これら実施の形態は添付図面に示してある。これら図面においては、同一又は類似の部分を参照するため、同一の参照番号を用いている。
【００２４】
ＵＤＰネットワーク環境は、典型的には、複数のＬＡＮ（local area network）により構成されている。図１はＵＤＰネットワーク環境１００を示し、このＵＤＰネットワーク環境１００には、３つのＬＡＮ１０２，１０４，１０６と、２つのルータ、すなわちルータＡＣ１０８及びルータＡＢ１１０とが含まれている。ＬＡＮ１０２は、クライアント１１２及びサーバ１１４より構成される。ＬＡＮ１０４及び１０６は、それぞれ、複数のクライアントコンピュータ１１２により構成される。
【００２５】
ルータＡＣ１０８は、non-multicast-capableなルータであって、ＬＡＮ１０６とＬＡＮ１０２との間の境界を形成している。ルータＡＢ１１０は、multicast-capableなルータであって、ＬＡＮ１０２とＬＡＮ１０４との間の境界を形成している。典型的なネットワーク構成においては、クライアントコンピュータ１１２は、同一のＬＡＮ上のサーバコンピュータと、ユニキャスト又はマルチキャスト伝送方式のいずれかによって、通信することができる。しかしながら、一方のＬＡＮと他方のＬＡＮとの間に存在するルータの機能によっては、この一方のＬＡＮ上のクライアントは、この他方のＬＡＮ上のサーバと通信することができない。例えば、ルータＡＣ１０８は、non-multicast-capableなルータであるので、ＬＡＮ１０６上のクライアント１１２は、ＬＡＮ１０２上のサーバ１１４と、マルチキャスト方式で通信することはできない。しかしながら、ルータＡＢ１１０はmulticast-capableなルータであるので、ＬＡＮ１０４上のクライアント１１２は、ユニキャストマ又はマルチキャストのいずれによっても、ＬＡＮ１０２上のサーバ１１４と通信することができる。
【００２６】
図２は、図１のクライアントコンピュータ１１２を詳細に示すブロック図である。クライアント１１２には、メモリ２００と、プロセッサ２０２と、バス２０４と、入力デバイス２０６と、出力デバイス２０８と、ネットワークインタフェース２１０とが含まれている。入力デバイス２０６にはマウスあるいはキーボードが含まれ、出力デバイス２０８にはスクリーンディスプレイ又はプリンタが含まれている。クライアント１１２は、ネットワークインタフェース２１０によって、ネットワーク接続１１０を介して、他のコンピュータと通信することができる。図２に示したように、各ネットワークインタフェース２１０には、さらに、ネットワーク上でクライアントを識別するユニークなＩＰアドレス２１２が含まれている。図２には図示していないが、クライアント１１２をmulti-homedクライアントとすることができる、ことに留意されたい。言い換えると、クライアント１１２には、ユニークなＩＰアドレスをそれぞれ有する複数個のネットワークインタフェースを含めることができる。メモリ２００には、クライアントオートセンシング（client auto-sensing）ルーチン２１４と、アプリケーション２１６と、ネットワークプロトコル２１８と、ＵＤＰポート２２０とがさらに含まれている。オペレーション中においては、各アプリケーションにＵＤＰポート番号２２０が割り当てられ、他のコンピュータ上でランしているアプリケーションとユニークに識別される。クライアント１１２は同様に他のコンポーネントを有することができるが、これらは、本発明の実施の形態の説明を容易にするため、図示していない。
【００２７】
図３は、本発明の一実施の形態に係るサーバ１１４を示すブロック図である。サーバ１１４には、メモリ３００と、プロセッサ３０２と、バス３０４と、入力デバイス３０６と、出力デバイス３０８と、ネットワークインタフェース３１０とが含まれている。入力デバイス３０６にはマウス又はキーボードが含まれ、出力デバイス３０８にはスクリーンディスプレイ又はプリンタが含まれている。加えて、ネットワークインタフェース３１０には、ネットワーク上で当該インタフェースを識別するためのＩＰアドレス３１２が含まれている。
【００２８】
図３に示したように、メモリ３００には、アプリケーション３１４と、ネットワークプロトコル３１６と、サーバオートセンシングルーチン３１８とがさらに含まれている。アプリケーション３１４には、ＵＤＰポート３２０が関係付けしてある。サーバ１１４は同様に他のコンポーネントを有することができるが、これらは、本発明の実施の形態の説明を容易にするため、図示していない。
【００２９】
処理中において、アプリケーション２１６は、ネットワークコネクション１１０に接続された他のコンピュータと、通信を望むことができる。通信が開始されると、プロセッサ２０２は、ＵＤＰポート２２０をアプリケーション２１６に割り当てる。アプリケーション２１６は、データを伝送するため、図示しないデータをパッケージ化することになる。割り当てられたＵＤＰポート番号は、ネットワーク通信を行うため、アプリケーション２１６が終了されるまで、アプリケーション２１６を識別する。クライアントオートセンシングルーチン２１４は、サーバ１１４により最良の伝送方式を識別させる。このことは、後述する。この識別された伝送方式によれば、ネットワークプロトコルは、当該データパケットに他の情報を付加することを要求することができる。例えば、仮にアプリケーション２１６がＵＤＰによってデータを送出している場合には、ＵＤＰのためのネットワークプロトコルは、当該パケットを送出できるネットワークインタフェースを識別するＩＰアドレスと、割り当てられたＵＤＰポート番号であって当該ソースアプリケーションを識別するＵＤＰポート番号とが、当該パケットに付加されることを要求する。加えて、当該ネットワークプロトコルは、デスティネーションアドレシング情報、例えば、デスティネーションＩＰアドレスと、デスティネーションＵＤＰポート番号とが、当該メッセージに付加されることを要求する。上述したように、デスティネーションアドレシング情報は、クライアントがＵＤＰユニキャスト伝送又はＵＤＰマルチキャスト伝送のいずれを用いているかによって、異ならせることができる。最後に、トランスポート層と、ネットワーク層と、リンク層プロトコルの要求する他の全ての情報が付加されることになる。そして、当該プロセッサは、付加された全ての情報を含むデータパケットを、ネットワークコネクション１１０を介して伝送するため、ネットワークインタフェース２１０に送出することになる。
【００３０】
加えて、サーバ１１４は、サーバオートセンシングルーチン３１８を連続的にランし、当該ルーチンは、クライアントオートセンシングルーチン２１４によってランされたテストの成功又は失敗を、当該クライアントに通知する。当該クライアントは、これら結果に基づいて、サーバ１１４と通信するための最良の伝送方式を選択する。ネットワークプロトコル３１６はデータパケットに付加される情報を指定し、当該パケットは、ネットワークコネクション１１０を介して通信するため、当該ネットワークインタフェースに送出される。
【００３１】
図４は、本発明の一実施の形態に係るプロセスであって、ネットワークにおける適正な伝送方式を自動的に判定するプロセスを記載した詳細な流れ図である。図４については、マルチキャストサーバ１１４と通信するように構成されたクライアント１１２の観点から、簡潔に説明する。ネットワーク１００を介した通信のプロセスは、クライアント１１２が初期設定されると、開始される。図４においては、クライアント１１２が、ＳＵＡ（server unicast address）と、ＳＵＰ（server unicast port）とで初期設定されるようになっている（ステップ４０２）。ＳＵＡはサーバ１１４のＩＰアドレス３１２である。ＳＵＡは、サーバ１１４への全てのユニキャスト伝送のデスティネーションアドレスとして用いられ、ＳＵＡを用いることにより、ネットワーク１００は、パケットを、サーバ１１４に対して、ネットワークインタフェース３１０を介してルーティングすることができる。サーバ１１４のＳＵＰは、当該データの受信側のアプリケーション３１４に関係付けされたＵＤＰポートアドレス３２０である。当該ＳＵＰは、サーバ１１４への全てのユニキャスト伝送において用いられる。当該ＳＵＰにより、サーバ１１４上のネットワークプロトコル３１６は、アプリケーション３１４をデータパケットのデスティネーションとして識別することができる。
【００３２】
初期設定された後、処理ステップ４０４へ進み、ステップ４０４において、当該クライアントは、その対応するＳＭＡ（server multicast address）とＳＭＰ（server multicast port）とをコンピュートする。当該ＳＵＡ及びＳＵＰは、全てのユニキャスト伝送のためのデスティネーションＩＰアドレス及びＵＤＰポートを識別し、これに対して、クライアント１１２は、その対応するＩＰアドレス及びポートアドレスであって、マルチキャスト伝送で用いられるＩＰアドレス及びポートアドレスをコンピュートしなければならない。マルチキャスト伝送はＩＰアドレスの特定の範囲を用いている。このＩＰアドレスの特定の範囲は、224.0.0.0から239.255.255.255の範囲とすることができる。これらＩＰアドレスにより、最上位（最左端）４ビットが１１１０に等しいＩＰアドレスの全範囲が構成される。
【００３３】
当該クライアントは、次のフォームを有するＳＵＡから、ＳＭＡをコンピュートする。
【００３４】
【表１】
2005503682.tif 000003
【００３５】
クライアント１１２は、このＳＵＡ（ＳＵＡ−１、ＳＵＡ−２等）を構成する４つの８ビットバイトを、２８ビットに圧縮し、現在空である上位４ビットを１１１０で充填して、当該ＳＭＡをコンピュートする。サーバ１１４は、ＳＭＡに送出されたメッセージをリスン（1isten）することになる。
【００３６】
この圧縮は、４つの８ビットよりなるワードのそれぞれからのビットをオーバラップするＸＯＲ関数を用いて行なわれる。Ｃプログラミング言語のシンタックスを用いると、このコードは次のようになる。
【００３７】
2005503682.tif 000004
【００３８】
これによると、２２４（２進数表記で１１１０００００）という数値は、左に２８ビットだけシフトされ、この式の他の引数とＸＯＲ演算される。各括弧内では、このＳＵＡの各８ビットバイトが分離され、２２４とオーバラップされる。例えば、ＳＵＡを２４ビットだけ右にシフトすると、このＳＵＡの上位８ビットが下位８ビットの位置に移動される。そして、この値が、０ｘＦＦ（下位８ビットが全て１）とＡＮＤ演算され、その結果、上位２４ビットに０がセットされる。得られた３２ビットにおいては、上位２４ビットが０であり、下位８ビットが、かって上位８ビットにあったビットである。そして、このビットストリングは左にシフトされ、８個の非ゼロビットが新しい位置に位置する。３２ビットは、このうち上位ビットが８ビットの場合には、２０ビットだけ左にシフトされる。このプロセスは、オリジナルの３２ビットＳＵＡから８ビットストリングをそれぞれ分離し、それらを新たな位置に位置させるように、パフォームされる。一度２２４という数値と、各８ビットストリングとが、新たな位置に移動されると、これら５つの引数がＸＯＲ演算により組み合わされる。その結果、オリジナルの３２ビットを、マルチキャストアドレスを選択するための２８ビット（下位）にパック（pack）するため、４バイトがオーバラップされたＳＭＡが得られる。その結果、次のようなフォーマットになる。
【００３９】
【表２】
2005503682.tif 000005
【００４０】
ＳＭＰも、このＳＵＡ及びＳＵＰからコンピュートされる。同様に、Ｃプログラミング言語を用いると、このコードは次のような形態になる。
【００４１】
SMP =  1024 + ((SUP^(SUA & 0xFFFF)) & 0x7FFF)
【００４２】
このＳＭＰをコンピュートする式は、ＳＵＡの下位２バイト（すなわち、入力されたＳＵＡアドレスのうちのＳＵＡ−３及びＳＵＡ−４）を、ＳＵＰ全体と（ここでも、ＸＯＲ演算によって）組み合わせ、（次のステップでのオーバフローを回避するため、０ｘ７ＦＦＦとＡＮＤ演算を行なって）最上位ビットにゼロをセットし、（その結果得られたポート番号が、「特権」アプリケーションにより多くのオペレーティングシステムに対して用いるために予約された０〜１０２３の範囲内に入らないことを保証するため）１０２４を追加する。
【００４３】
一度このＳＭＡ及びＳＭＰがコンピュートされると、サーバ１１４に登録するため、処理はステップ４０６へ進み、ステップ４０６において、クライアント１１２がクライアントオートセンシングルーチン２１４を実行する。このルーチンにおいては、コンピュートされたアドレスにおいて、クライアント１１２は、クライアント１１２がマルチキャスト伝送方式でサーバ１１４と通信することができるか否かを、自動的にセンスすることができる。加えて、このステップ４０６においては、クライアント１１２は、サーバ１１４がＩＰアドレス２１２及びＵＤＰポートから送出されたパケットを受信できるか否かを、判定することができる。
【００４４】
そして、クライアント１１２は、サーバ１１４に登録することができる（ステップ４０８）。このステップ４０８は、本発明の範囲外である。一度クライアント１１２が登録すると、処理はステップ４１０へ進み、ステップ４１０において、クライアント１１２は、この構成された伝送方式に従って、サーバ１１４と通信することができる。
【００４５】
図５は、ルーチン２１４によってパフォームされるステップであって、ステップ４０６（図４）における伝送方式を自動的にセンスするステップを詳細に示す流れ図である。ルーチン２１４においては、まず、ＳＵＡ３１２及びＳＵＰ３２０を用いて、サーバとユニキャスト伝送方式で通信することができるか否かを判定するため、ユニキャスト伝送方式をテストする（ステップ５０２）。このユニキャスト伝送方式のテストにおいて、サーバ１１４から応答させることもできるし、応答させないようにもできる。仮に応答が受信される場合には、クライアント１１２は、例えばBoolean変数のserver_unicast_responseに「１」をストアして、成功応答（successful response）の表示（indication）をストアする（ステップ５０６）。処理はステップ５０８へ進む。
【００４６】
仮に応答が受信されない場合には（ステップ５０２）、処理の流れはステップ５０８へ進み、ステップ５０８において、ルーチン２１４は、クライアント１１２が、ユニキャスト伝送を唯一の伝送方式として主張するように構成されているか否かを判定する。本発明の一実施の形態においては、ルーチン２１４は、ユーザプレファランスが無視されないことを保証するため、このチェックを行う。
【００４７】
仮にクライアント１１２がユニキャスト方式を主張するように構成されていない場合には、処理の流れはステップ６０２（図６）に進む。仮にクライアント１１２がユニキャスト伝送方式を主張するように構成されている場合には、処理の流れはステップ５１２へ進み、ステップ５１２において、ルーチン２１４は、ユニキャスト伝送方式をテストしている間に、サーバ１１４から有効な応答が受信されたか否かを判定する。仮に有効な応答が受信された場合には、ルーチン２１４はステップ５１４へ進み、ステップ５１４において、クライアント１１２は、ユニキャスト方式に従って伝送するため、構成される。本発明の一実施の形態においては、サーバ１１４から応答が受信されると、クライアント１１２は、サーバ応答パケットから、デスティネーションＩＰアドレス（ＤＡＤＤＲ）と、デスティネーションポート番号（ＤＰＯＲＴ）とを、サーバ登録におけるクライアントＩＰアドレス及びＵＤＰポートとして使用する。
【００４８】
仮に、ユニキャスト方式のテスト（ステップ５１２）から、有効な応答が受信されなかった場合には、処理の流れはステップ５１６へ進み、ステップ５１６において、ルーチン２１４は、ユーザに通知を送信する。本発明の一実施の形態においては、この通知は、クライアント１１２がユニキャスト伝送を主張するように構成されているが、クライアント１１２はユニキャスト方式でサーバ１１４と通信することができない旨を、説明する。それにも拘わらず、現行のシステムが、ユニキャスト伝送方式のために構成されることが、ユーザに通知される。本発明の一実施の形態においては、サーバ応答が受信されないので、クライアント１１２は、パケットに入れるＩＰアドレス及びポート番号を有していない。その結果、クライアント１１２は、そのマシンの可能な複数個のＩＰアドレスのうちの任意に選択された１つのＩＰアドレスと、そのローカルＵＤＰポート番号とを用いることができる。そして、処理はステップ５１４へ進み、ステップ５１４において、ルーチン２１４は、ユニキャスト方式により伝送を行なうように構成されることになる。
【００４９】
図６は、マルチキャスト方式をテストするために、クライアント１１２によって行なわれる処理を示す。仮に、クライアント１１２が、ステップ５０８（図５）において、ユニキャスト方式を主張するように構成されていない場合には、処理はステップ６０２（図６）へ進み、ステップ６０２において、ルーチン２１４は、マルチキャスト方式をテストすることになる。仮に、ルーチン２１４が、このテストの間にサーバ応答を受信した場合には、ルーチン２１４は、マルチキャスト伝送方式に従って伝送を行なうようにクライアント１１２を構成する（ステップ６０６）。本発明の一実施の形態においては、仮にサーバ１１４から応答が受信された場合には、クライアント１１２は、サーバ応答パケットから、ＤＡＤＤＲ及びＤＰＯＲＴ値を、サーバ登録におけるクライアントＩＰアドレス及びＵＤＰポートとして使用する。仮にサーバ１１４から応答が受信されなかった場合には、処理はステップ６０８へ進み、ステップ６０８において、ルーチン２１４は、クライアント１１２がマルチキャスト方式を主張するように構成されているか否かを判定しなければならない。
【００５０】
仮にクライアント１１２がマルチキャスト方式を主張するように構成されている場合には、ルーチン２１４は、クライアント１１２がマルチキャストを主張するように構成されているが、マルチキャストによってはサーバ１１４と通信できないことを説明する通知を、ユーザに表示する（ステップ６１０）。それにも拘わらず、ルーチン２１４がクライアント１１２をマルチキャスト伝送方式で通信するように構成することも、ユーザに通知される。そして、ルーチン２１４はステップ６１１へ進み、ステップ６１１において、サーバ１１４からユニキャスト応答が受信されたか否かを判定する。本発明の一実施の形態においては、仮にサーバ１１４から応答が受信された場合には、クライアント１１２は、サーバ応答パケットから、ＤＡＤＤＲ及びＤＰＯＲＴ値を、サーバ登録におけるクライアントＩＰアドレス及びＵＤＰポートとして使用する（ステップ６１２）。そして、処理はステップ６１３へ進み、ステップ６１３において、ルーチン２１４は、クライアント１１２を、マルチキャスト伝送方式に従って通信するように構成する。しかし、仮に、ルーチン２１４が、ステップ６１１において、ユニキャストサーバ応答が受信されなかったと判定した場合には、処理はステップ６１４へ進む。本発明の一実施の形態においては、サーバ応答が受信されないので、クライアント１１２は、そのパケットに入れるＩＰアドレス及びポート番号を有していないことになる。その結果、クライアント１１２は、そのマシンにおいて可能な複数個のＩＰアドレスのうちの任意に選択された１つのＩＰアドレスと、そのローカルＵＤＰポート番号とを用いることになる（ステップ６１４）。そして、処理はステップ６１３へ進み、ステップ６１３において、クライアント１１２を、マルチキャスト伝送方式に従って通信するように構成する。
【００５１】
しかしながら、仮にクライアント１１２がマルチキャストを主張するように構成されていない場合には（ステップ６０８）、処理はステップ６１５へ進み、ステップ６１５において、ルーチン２１４は、クライアント１１２がマルチキャスト方式を主張するように構成されていないこと、及びクライアント１１２がサーバ１１４とマルチキャストによって通信不可能であったこと、を判定する。その結果、ルーチン２１４は、ユニキャスト方式の使用を訴えることになる。仮に、ステップ６１５において、ユニキャスト方式をテストしたとき、ルーチン２１４がサーバから成功応答を受信した場合には、ステップ６１６において、クライアント１１２は、ユニキャスト方式に従って通信を行なうように構成される。本発明の一実施の形態においては、サーバ１１４から応答が受信されたので、クライアント１１２は、ECHO-REPLYパケットからのＤＡＤＤＲ及びＤＰＯＲＴ値を、サーバ登録におけるクライアントＩＰアドレス及びＵＤＰポートとして使用する。仮にユニキャスト方式をテストしたときサーバ応答が受信されなかった場合には、処理はステップ６１８へ進み、ステップ６１８において、クライアント１１２が、ステップ６１６においてユニキャスト方式に従って通信を行なうように構成される以前には、マルチキャスト方式及びユニキャスト方式のいずれによってもサーバ１１４と通信することができなかったことを説明する通知を、ユーザに表示する。本発明の一実施の形態においては、サーバ返答が受信されなかったので、当該クライアントは、そのマシンにおいて可能な複数個のＩＰアドレスのうちの任意に選択された１つのＩＰアドレスと、そのローカルＵＤＰポート番号とを用いる。
【００５２】
図７は、ルーチン２１４が、ステップ５０２（図５）においてユニキャスト方式をテストし、ステップ６０２（図６）においてマルチキャスト方式をテストするときに実行されるステップを示す流れ図である。オペレーションにおいて、ルーチン２１４は、ルーチン２１４が登録／通信を試みるサーバ１１４に対して、第１要求パケットを送出する（ステップ７０２）。ステップ７０２においては、ルーチン２１４は、テストしようと試みる伝送方式のいずれかを用いて、当該要求パケットを送出する。例えば、仮にルーチン２１４がマルチキャスト方式のテストを試みている場合（ステップ６０２）には、マルチキャスト方式を用いてパケットを送出する。他方、仮にルーチン２１４がユニキャスト方式のテストを試みている場合（ステップ５０２）には、ユニキャスト方式でパケットを送出する。
【００５３】
本発明の一実施の形態においては、ルーチン２１４は、ステップ７０２において、次に示すようなフォームのペイロードを有するオートセンシングパケットの形態で、要求パケットを送出する。
【００５４】
【表３】
2005503682.tif 000006
【００５５】
これを参照すると、先頭の２つの３２ビットワードが全てゼロであるから、他のハイレベルプロトコル、特にＲＴＰ（real time protocol）を用いたパケットと、これらパケットを、識別することができる。ＲＴＰパケットは、当業者には公知であるが、第１ワードにおいて、常に非ゼロのバージョン番号を含む。このため、サーバ１１４は、本明細書で記載されたプロトコルによって用いられているのと同一のＵＤＰポートにおいて、他のプロトコルパケットを受信し、適正に解釈することができる。
【００５６】
本発明の一実施の形態においては、クライアント１１２によってユニキャスト伝送方式で送出されるオートセンシング要求パケットは、全て、次のようなフォーマット及びデータを有する。オペレーションコード（ＯＰＣＯＤＥ）は、ECHO-REQUESTにセットされており、当該パケットが要求パケットであることを示すものである。デスティネーションアドレス（ＤＡＤＤＲ）フィールドは、ＳＵＡにセットされており、デスティネーションポート（ＤＰＯＲＴ）フィールドは、ＳＵＰにセットされている。（サーバがＥＸＴＲＡ−ＢＹＴＥＳフィールドとみる）ＫＥＹフィールドは、（例えば６４ビット以上の）乱数を含んでいる。所定の要求パケットに対する応答であって受信された応答は、そのＫＥＹフィールドに同一の乱数を有する。よって、ＫＥＹフィールドは、識別キーとしてサーブ（serve）し、クライアント１１２は、応答を所定の要求にマッチさせることができる。マルチキャスト方式で送出されるオートセンシング要求パケットは、ＯＰＣＯＤＥ及びＫＥＹフィールドが同様にしてセットされるが、ＤＡＤＤＲフィールド及びＤＰＯＲＴフィールドは、それぞれ、サーバ１１４のＳＭＡ及びＳＭＰを含むことになる。
【００５７】
一度この要求パケットが送出されると、ルーチン２１４は、応答を待つ（ステップ７０４）。この待機による遅延時間は、予め定めたものではなく、ファクタ、例えば、クライアント数と、クライアント間の応答時間等とに基づいて、個々のネットワークごとに、調整することができる。加えて、この遅延時間は、テストごとに、同一にすることができる。例えば、この遅延を、テストごとに、１定の２００msecとすることができ、あるいは、この遅延時間を変化させることができ、当該クライアントは、最初の５回のテストについては、２００msecの間だけ停止させ、次の５回のテストについては、１０００msecの間だけ停止させることができる。この遅延時間が経過すると、テスト５０２、６０２において、応答パケットが受信されたか否かを判定する（ステップ７０６）。仮に応答パケットが受信されている場合には、処理はステップ５０６又は６０６へ進む。仮に応答パケットが受信されていない場合には、処理はステップ７０８へ進み、ステップ７０８において、テスト５０２、６０２が、所定数のテストパケットが既に送信されたか否かを判定する。言い換えれば、クライアント１１２は、応答パケットが受信されなかったため、当該テストを中止する前に、所定数（例えば１０個）の要求パケットを送出するように構成することができる。仮に所定数の要求パケットが送信されていない場合（ステップ７０８）には、クライアント１１２は、ステップ７０２へ戻って、次の要求パケットを送出する。仮に所定数の要求パケットが既に送信された場合には、当該テストは、応答パケットが受信されなかったと判定し（ステップ７１０）、処理はステップ５０８又はステップ６０８へ進む。
【００５８】
本発明の一実施の形態においては、クライアント１１２は、所定の伝送方式が成功したとの証明として、前の伝送を用いることができる。例えば、仮にクライアント１１２がサーバ１１４と通信していた場合には、クライアント１１２は、当該ホスト（サーバ１１４）からパケットすなわち通信を受信できたはずである。仮にその通信がユニキャスト方式で行なわれている場合には、当該コネクションをさらにテストするため、ユニキャストを用いてパケットを送出する必要はないことになる。したがって、サーバ１１４から受信されたパケットは、ユニキャスト方式での伝送の成功を通知する応答パケットとしてアクトすることができる。
【００５９】
そして、クライアント１１２は、受信されたパケットが応答パケットか否かを判定しなければならない。本発明の一実施の形態においては、応答パケットは、テストされた伝送方式に従って送出された全てのパケットであって、伝送が成功したことを証明するものである。本発明の別の実施の形態においては、応答パケットは、オートセンシング応答パケットのフォームをとる。図８は、受信されたパケットがオートセンシング応答パケットであるか否かを判定するため、ステップ７０６において実行されるステップを詳細に示す流れ図である。パケットがテスト中に受信されると、クライアント１１２は、そのパケットがオートセンシングパケットであるか否かを判定する（ステップ８０２）。前述したように、オートセンシングパケットには、全てのビットがゼロである２つの３２ビットワードが含まれる。仮にステップ７０６のテストにおいて、受信されたパケットがオートセンシングパケットであると判定した場合には、処理はステップ８０４へ進む。ステップ７０６のテストにおいて、受信されたパケットがオートセンシングパケットではないと判定した場合には、処理はステップ７０８（図７）へ進む。ステップ８０４においては、ステップ７０６のテストが、受信されたパケットが応答パケットであるか否かを判定する。前述したように、クライアント１１２によってユニキャスト伝送方式に従って送出されたテストパケットは、ECHO-REQUESTにセットされたオペレーションコード（ＯＰＣＯＤＥ）を有する。ECHO-REQUESTパケットに対する応答（応答パケット）は、ECHO-REPLYにセットされたＯＰＣＯＤＥを有する。仮に受信されたＯＰＣＯＤＥがECHO-REPLYと等しくない場合には、受信されたパケットは応答パケットではなく、処理はステップ７０８（図７）へ進む。仮にＯＰＣＯＤＥがECHO-REPLYにセットされている場合には、処理はステップ８０６へ進み、ステップ８０６において、クライアント１１２は、受信されたパケットのＫＥＹフィールドが、ステップ７０２（図７）において送出された乱数と同一の乱数を有するか否かを判定する。仮にＫＥＹフィールドが同一である場合には、処理はステップ８０８へ進む。ＫＥＹフィールドが同一であれば、受信された伝送が、クライアント１１２によって送出されたテストパケットに対する返答であると識別される。ステップ８０８において、応答の成功、すなわち当該伝送方式のテストの成功が通知される。そして、処理はステップ５０６又はステップ６０６へ進む。仮にＫＥＹフィールドが同一ではない場合には、受信された応答パケットは要求パケットに対する応答ではなく、処理はステップ７０８（図７）へ進む。
【００６０】
図９は、要求パケットを受信したときサーバ１１４によって実行されるステップを詳細に示す流れ図である。図９に示すように、サーバ１１４のメモリ３００でオペレートしているサーバオートセンシングルーチン３１８は、当該サーバに関係付けされているＩＰアドレス（ＳＵＡ）３１２のうちの１つに送出されたユニキャストオートセンシング要求パケットを、特定のＵＤＰポート（ＳＵＰ）において、リスン（listen）する。サーバ１１４は、ＳＵＡ及びＳＵＰからコンピュートされたマルチキャストＩＰアドレス（ＳＭＡ）及びポート（ＳＭＰ）に送出されたマルチキャストＵＤＰパケットをリスンする。一度サーバ１１４が要求パケットを受信すると（ステップ９０４）、サーバ１１４は応答を送出する（ステップ９０６）。本発明の一実施の形態においては、仮に当該要求パケットがオートセンシング要求パケットではない場合には、当該応答は、伝送の成功を証明する全ての応答のフォームをとることができる。
【００６１】
しかしながら、仮に当該要求パケットがオートセンシング要求パケットのフォームを有する場合には、当該応答パケットは、そのオリジナルのフォームから修正されたオートセンシング応答パケットのフォームをとることになる。この場合、修正されたパケットが応答パケットとして機能し、テストパケットの成功を通知する。本発明の一実施の形態においては、この要求パケットは、修正されたECHO-REQUEST  ＵＤＰオートセンシングパケットのフォームをとる。
【００６２】
図１０は、ECHO-REQUEST  ＵＤＰオートセンシングパケットを識別し応答するため、サーバ１１４の一例によってパフォームされるステップ、すなわちステップ９０６（図９）を示す流れ図である。処理は、当該要求パケットがオートセンシングのフォーマットをとっているか否かを判定することにより開始される。仮に当該パケットがオートセンシングパケットのフォームをとっている場合には、サーバ１１４はステップ１０１４へ進み、ステップ１０１４において、ステップ９０２（図９）へ戻る前に、当該パケットを無視する。仮に当該要求パケットがオートセンシングパケットである場合には、処理はステップ１００４へ進み、ステップ１００４において、サーバ１１４は、当該パケットがECHO-REQUESTパケットであるか否かを判定する。仮に当該オートセンシングパケットがECHO-REQUESTでない場合には、当該オートセンシングパケットは要求パケットではなく、サーバ１１４からの応答を必要とせず、処理はステップ１０１４へ進む。
【００６３】
仮に当該パケットがECHO-REQUESTパケットである場合には、処理はステップ１００６へ進み、ステップ１００６において、サーバオートセンシングルーチン３１８は、当該要求パケットの送出における伝送方式を識別する。一度識別されると、サーバ１１４は、ステップ１００８において、当該パケットをクライアント１１２に戻すため、デスティネーションポート（ＤＰＯＲＴ）及びデスティネーションＩＰアドレス（ＤＡＤＤＲ）を、当該パケットヘッダから取り出したソースポート及びソースＩＰアドレスと置換して、当該パケットのアドレシングをやり直す。そして、サーバ１１４は、ステップ１０１０へ進み、ステップ１０１０において、当該応答パケットが特定の要求パケットへの返答であることを明示するため、ＯＰＣＯＤＥをECHO-REPLYに変更する。本発明の一実施の形態においては、これらの修正が行なわれた後は、新たなECHO-REPLY応答パケットには、オリジナルのECHO-REQUESTパケットと同一のEXTRA-BYTESデータが含まれている。
【００６４】
最後に、サーバ１１４は、当該要求パケットと同一の伝送方式を用いて、当該修正済みパケットを送出する（ステップ１０１２）。例えば、仮にオリジナルのECHO-REQUESTパケットがユニキャストで受信された場合には、当該ECHO-REPLYパケットはユニキャストで送出される。仮にオリジナルのECHO-REQUESTパケットがマルチキャストで受信された場合には、当該ECHO-REPLYパケットはマルチキャストで送出される。一度送出されると、サーバ１１４はステップ９０２（図９）に戻り、別のパケット伝送を待つ。
【００６５】
本発明の別の実施の形態においては、仮に、サーバ１１４が、受信された要求パケットがオートセンシングパケットではないと判定するか（ステップ１００２）、あるいはECHO-REQUESTパケットではないと判定した（ステップ１００４）場合には、サーバ１１４は任意の方法で応答することができる。サーバ１１４は、伝送を無視することができる（ステップ１００４）か、クライアントにエラーメッセージを送出するができるか、あるいはパケットの伝送が成功か又は不成功かを示す応答を返送することができる。これらの実施の形態のいずれにおいても、サーバ１１４による応答は、応答パケットとしてサーブし、オリジナルの伝送の成功又は不成功をクライアント１１２に示す。
【００６６】
当業者にとって公知のことであるが、本明細書においては、クライアントオートセンシングルーチン２１４及びサーバオートセンシングルーチン３１８が、メモリに駐在するものとして記載したが、このようなルーチンは、フロッピー（登録商標）ディスクのようなリムーバブルストレージ媒体上に駐在することができ、あるいは他のネットワークコンピュータからランされるネットワークアプリケーションとすることができる。
【００６７】
本明細書において開示された本発明の特徴及びその実施の形態からは、本発明の別の実施の形態は、当業者に顕著である。本明細書に記載された本発明の特徴及びその実施の形態は、例示にすぎず、本発明の真の範囲及び精神は、特許請求の範囲に明示されている。
【図面の簡単な説明】
【００６８】
【図１】マルチキャスト及びユニキャストサブネットワークを有するネットワークを示す図である。
【図２】本発明の実施の形態をホストする能力を有するクライアントを示す図である。
【図３】本発明の実施の形態をホストする能力を有するサーバを示す図である。
【図４】本発明の一実施の形態に係るクライアントコンピュータによって実行されるステップを示す流れ図である。
【図５】本発明の一実施の形態に係る伝送方式を自動的にセンスするためにクライアントによって実行されるステップを示す流れ図である。
【図６】本発明の一実施の形態に係る伝送方式を自動的にセンスするためにクライアントによって実行されるステップをさらに示す流れ図である。
【図７】本発明の一実施の形態に適合した伝送方式をテストするためにクライアントによって実行されるステップを示す流れ図である。
【図８】受信されたパケットが本発明の一実施の形態に係るオートセンシング応答パケットであるか否かを識別するためにクライアントによって実行されるステップを示す流れ図である。
【図９】本発明の一実施の形態に係るサーバの振る舞いを示す流れ図である。
【図１０】本発明の一実施の形態に係るオートセンシング要求パケットであって受信されたオートセンシング要求パケットを識別して応答するためにサーバによって実行されるステップを示す流れ図である。
【図１】
2005503682.tif 000007
【図２】
2005503682.tif 000008
【図３】
2005503682.tif 000009
【図４】
2005503682.tif 000010
【図５】
2005503682.tif 000011
【図６】
2005503682.tif 000012
【図７】
2005503682.tif 000013
【図８】
2005503682.tif 000014
【図９】
2005503682.tif 000015
【図１０】
2005503682.tif 000016
【国際公開パンフレット】
2005503682.tif 000017
2005503682.tif 000018
2005503682.tif 000019
2005503682.tif 000020
2005503682.tif 000021
2005503682.tif 000022
2005503682.tif 000023
2005503682.tif 000024
2005503682.tif 000025
2005503682.tif 000026
2005503682.tif 000027
2005503682.tif 000028
2005503682.tif 000029
2005503682.tif 000030
2005503682.tif 000031
2005503682.tif 000032
2005503682.tif 000033
2005503682.tif 000034
2005503682.tif 000035
2005503682.tif 000036
2005503682.tif 000037
2005503682.tif 000038
2005503682.tif 000039
2005503682.tif 000040
2005503682.tif 000041
2005503682.tif 000042
2005503682.tif 000043
2005503682.tif 000044
2005503682.tif 000045
2005503682.tif 000046
2005503682.tif 000047
2005503682.tif 000048
2005503682.tif 000049
2005503682.tif 000050
2005503682.tif 000051
2005503682.tif 000052
2005503682.tif 000053
2005503682.tif 000054
2005503682.tif 000055
2005503682.tif 000056
2005503682.tif 000057
2005503682.tif 000058
【国際公開パンフレット（コレクトバージョン）】
2005503682.tif 000059
2005503682.tif 000060
【国際公開パンフレット（コレクトバージョン）】
2005503682.tif 000061
2005503682.tif 000062
【国際調査報告】
2005503682.tif 000063
2005503682.tif 000064
2005503682.tif 000065