(57)【要約】シンメトリック・ファイアウォール／ＮＡＴの背後のクライアント間の双方向ピアツーピア・ネットワーク通信（図７）の確立および維持のためのシステムおよび方法が提供される。一実施形態では、本発明のシステムおよび方法により、サードパーティのアドレスおよびポート・ディスカバリ・サーバを使用して、与えられたクライアントのファイアウォール／ＮＡＴの性質およびポートマッピング・メトリックを突き止める。体系的な複数ＵＤＰホール・パンチ方法が、予測された範囲内のポートに使用され、インバウンド・パケットの第１の成功した転送のソース・ポートが、クライアントによって、後続の出力トラフィックのために使用される。この方法は、好ましくは、対称的に行われ、それにより、両方のクライアントのファイアウォールは、ソース／宛先ポートおよびソース／宛先アドレスが、保護されたネットワーク内から発信された先行のクライアント要求と完全にタプルが一致する、パケットを受け取り、したがって、パケットを各クライアントに正常に転送することを保証する（ピアツーピア）。さらに、このシステムおよび方法は、ファイアウォール／ＮＡＴ管理者による、接続の監視、管理、および防止を可能にする。
2007528677.tif 000002
【特許請求の範囲】
【請求項１】
第１のファイアウォールの背後の発呼側クライアントと第２のファイアウォールの背後の被呼側クライアントの間のネットワークを介した通信の方法であって、
前記ネットワークに結合された第１および第２の発見サーバを提供する工程であって、各前記発見サーバは、前記発呼側および被呼側クライアントに関連付けられたアドレスおよびポート情報を含む工程と、
前記発呼側クライアントにおいて、
前記第１および第２の発見サーバから前記発呼側クライアントのアドレスおよびポートを取り出す工程、および、
前記被呼側クライアントに、前記発呼側クライアントのアドレスおよびポートを含む第１のデータ・メッセージを生成し送信する工程と、
前記被呼側クライアントにおいて、
前記発呼側クライアントの第１のデータ・メッセージを受け取り、そこから前記発行クライアントのアドレスおよびポートを決定する工程、
前記第１および第２の発見サーバから前記被呼側クライアントのアドレスおよびポートを取り出す工程、
前記発呼側クライアントに、前記被呼側クライアントのアドレスおよびポートを含む第２のデータ・メッセージを生成し送信する工程、および
第１の発見データ・パケットを、前記発呼側クライアントのアドレスおよびポートに生成し送信する工程と、
前記発呼側クライアントにおいて、
前記被呼側クライアントの第２のデータ・メッセージを受け取り、そこから前記被呼側クライアントのアドレスおよびポートを決定する工程、および、
前記被呼側クライアントのアドレスおよびポートに、第２の発見データ・パケットを生成し送信する工程とを含み、
所定の時間後に、前記発呼側または被呼側クライアントが、前記第１または第２の発見データ・パケットを受け取らない場合、前記発呼側または被呼側クライアントに関連付けられたアクティブ・アドレスが発見されるまで複数の第３の発見データ・パケットを予め定義された範囲のポートに送信し、前記発見されたアドレスで前記第３の発見データ・パケットを受信し、さもなければ、前記発呼側および被呼側アドレスで前記第１および第２の発見データ・パケットをそれぞれ受信する、方法。
【請求項２】
前記ネットワークに結合され、前記発呼側および被呼側クライアントに関連付けられたサーバを提供する工程と、
前記発呼側クライアントにおいて、
前記被呼側クライアントに、前記発呼側クライアントのアドレスおよびポートを含む前記第１のデータ・メッセージを、前記サーバを介して送信する工程と、
前記被呼側クライアントにおいて、
前記被呼側クライアントに、前記被呼側クライアントのアドレスおよびポートを含む前記第２のデータ・メッセージを、前記サーバを介して送信する工程とをさらに含む、請求項１に記載の方法。
【請求項３】
前記第１および第２の発見サーバは、前記発呼側および被呼側クライアントと関連付けられたプライベートおよびパブリックのポートおよびアドレス情報を含む、請求項１に記載の方法。
【請求項４】
前記第１の発見サーバは、前記発呼側および被呼側クライアントに関連付けられた第１のポートおよびアドレス情報を含み、前記第２の発見サーバは、前記発呼側および被呼側クライアントに関連付けられた第２のポートおよびアドレス情報を含む、請求項１に記載の方法。
【請求項５】
前記第１のメッセージ生成工程は、前記発呼側クライアントの第１のポイントと第２のポートの間の第１の差分値を決定する工程と、前記発呼側クライアントのアドレスおよびポートならびに前記差分値を含む、前記第１のデータ・パケットを生成する工程とをさらに含む、請求項４に記載の方法。
【請求項６】
前記第２のメッセージ生成工程は、前記被呼側クライアントの第１のポートと第２のポートの間の第２の差分値を決定する工程と、前記被呼側クライアントのアドレスおよびポートならびに前記第２の差分値を含む、前記第２のデータ・パケットを生成する工程とをさらに含む、請求項４に記載の方法。
【請求項７】
前記第２のデータ・パケットは、前記発呼側クライアントの第１のデータ・パケットに対する変更をさらに含む、請求項６に記載の方法。
【請求項８】
前記予め定義された範囲のポートは、前記第１または第２の差分値から推定される、請求項１に記載の方法。
【請求項９】
前記データ・パケットは、ユニバーサル・データ・パケットである、請求項１に記載の方法。
【請求項１０】
前記第１および第２のファイアウォールは、ＳｙｍｍｅｔｒｉｃまたはＣｏｎｅファイアウォール／ネットワーク・アドレス変換を含む、請求項１に記載の方法。
【請求項１１】
前記第１および第２のファイアウォールは、ＳｙｍｍｅｔｒｉｃまたはＣｏｎｅネットワーク・アドレス変換／ポート・アドレス変換を含む、請求項１に記載の方法。
【請求項１２】
前記第１および第２のファイアウォールは、ＵＰｎＰ、ネットワーク・アドレス変換／ポート・アドレス変換、マルチ・ネットワーク・アドレス変換、または、これらの任意の組合せを含む、請求項１に記載の方法。
【請求項１３】
ネットワークを介した通信のためのシステムであって、
第１のファイアウォールに関連付けられた発呼側クライアントであって、前記ネットワークに結合された発呼側クライアントと、
第２のファイアウォールに関連付けられた被呼側クライアントであって、前記ネットワークに結合された被呼側クライアントと、
前記ネットワークに結合された第１および第２の発見サーバであって、前記発見サーバのそれぞれが、前記発呼側および被呼側クライアントに関連付けられたアドレスおよびポート情報を含む第１および第２の発見サーバとを含み、
前記発呼側クライアントは、
前記第１および第２の発見サーバから、前記発呼側クライアントのアドレスおよびポートを取り出し、
前記被呼側クライアントに、前記発呼側クライアントのアドレスおよびポートを含む第１のデータ・メッセージを生成し送信しするように構成され、
前記被呼側クライアントは、
前記発呼側クライアントの第１のデータ・メッセージを受信して、そこから前記発呼側クライアントのアドレスおよびポートを決定し、
前記第１および第２の発見サーバから、前記被呼側クライアントのアドレスおよびポートを取り出し、
前記発呼側クライアントに、前記被呼側クライアントのアドレスおよびポートを含む第２のデータ・メッセージを生成し送信し、
前記発呼側クライアントのアドレスおよびポートに、第１の発見データ・パケットを生成し送信するように構成され、
前記発呼側クライアントはさらに、
前記被呼側の第２のデータ・メッセージを受信して、そこから前記被呼側クライアントのアドレスおよびポートを決定し、
前記被呼側クライアントのアドレスおよびポートに、第２の発見データ・パケットを生成し送信するように構成され、
前記発呼側または被呼側クライアントはさらに、
所定の時間後に、前記発呼側または被呼側クライアントが、前記第１または第２の発見データ・パケットを受け取らない場合、前記発呼側または被呼側クライアントに関連付けられたアクティブ・アドレスが発見されるまで複数の第３の発見データ・パケットを予め定義された範囲のポートに送信し、前記発見されたアドレスで前記第３の発見データ・パケットを受信し、さもなければ、前記発呼側および被呼側アドレスで前記第１および第２の発見データ・パケットをそれぞれ受信するように構成される、システム。
【請求項１４】
前記ネットワークに結合され前記発呼側および被呼側クライアントに関連付けられたサーバと、
前記被呼側クライアントに、前記発呼側クライアントのアドレスおよびポートを含む前記第１のデータ・メッセージを、前記サーバを介して送信するように構成された前記発呼側クライアントと、
前記被呼側クライアントに、前記被呼側クライアントのアドレスおよびポートを含む前記第２のデータ・メッセージを、前記サーバを介して送信するように構成された前記被呼側クライアントとをさらに含む、請求項１３に記載のシステム。
【請求項１５】
前記第１および第２の発見サーバは、前記発呼側および被呼側クライアントに関連付けられた、プライベートおよびパブリックのポートおよびアドレス情報を含む、請求項１３に記載のシステム。
【請求項１６】
前記第１の発見サーバは、前記発呼側および被呼側クライアントに関連付けられた第１のポートおよびアドレス情報を含み、前記第３の発見サーバは、前記発呼側および被呼側クライアントに関連付けられた第２のポートおよびアドレス情報を含む、請求項１３に記載のシステム。
【請求項１７】
前記第１のメッセージ生成工程は、前記発呼側クライアントの第１のポートと第２のポートの間の第１の差分値を決定する工程と、前記発呼側クライアントのアドレスおよびポートならびに前記差分値を含む、前記第１のデータ・パケットを生成する工程とをさらに含む、請求項１６に記載のシステム。
【請求項１８】
前記第２のメッセージ生成工程は、前記被呼側クライアントの第１のポートと第２のポートの間の第２の差分値を決定する工程と、前記被呼側クライアントのアドレスおよびポートならびに前記第２の差分値を含む、前記第２のデータ・パケットを生成する工程とをさらに含む、請求項１６に記載のシステム。
【請求項１９】
前記第２のデータ・パケットは、前記発呼側クライアントの第１のデータ・パケットに対する変更をさらに含む、請求項１８に記載のシステム。
【請求項２０】
前記予め定義された範囲のポートは、前記第１または第２の差分値から推定される、請求項１３に記載のシステム。
【請求項２１】
前記データ・パケットは、ユニバーサル・データ・パケットである、請求項１３に記載のシステム。
【請求項２２】
前記第１および第２のファイアウォールは、ネットワーク・アドレス変換／ポート・アドレス変換を含む、請求項１３に記載のシステム。
【請求項２３】
前記第１および第２のファイアウォールは、ＳｙｍｍｅｔｒｉｃまたはＣｏｎｅファイアウォール／ネットワーク・アドレス変換、あるいは、これらの任意の組合せを含む、請求項１３に記載のシステム。
【請求項２４】
前記第１および第２のファイアウォールは、ＵＰｎＰ、ネットワーク・アドレス変換／ポート・アドレス変換、マルチ・ネットワーク・アドレス変換、または、これらの任意の組合せを含む、請求項１３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
発明者
ウィリアム・Ｌ・ガディ
関連出願の相互参照
本出願は、２００４年５月９日出願の米国特許出願第６０／５５１６１０号の優先権の利益を主張し、その開示の全体が、本明細書に詳述したかのように、参照により、本明細書に組み込まれる。
連邦政府による資金提供を受けた研究開発の記載
該当なし
「マイクロフィッシュ付録」の参照
該当なし
本発明は、ピアツーピア・ネットワーク通信に関する。より詳細には、本発明は、ポート・フォワーディングなしにかつ中継またはプロキシ・サービスなしに、出力ユニバーサル・データ・パケット（ＵＤＰ）トラフィックを可能にする、ファイアウォール／ネットワーク・アドレス変換（ＮＡＴ）ハードウェア／ソフトウェアの任意の組合せの背後のクライアントの間の直接的インターネット・プロトコル（ＩＰ）パケット・ベースのデータグラム通信を確立するのためのシステム、方法、装置、およびコンピュータ・プログラム製品に関する。
【背景技術】
【０００２】
ＩＰパケット交換ネットワークを介したサービスのいくつかのタイプでは、エンドユーザ間のピアツーピア通信を可能にすることが非常に望ましい。また、与えられた任意の方法により、可能な限り多くの組合せのクライアントが互いに通信できることが非常に好ましい。これを成功裏に達成する方法が欠如していることが、ビデオ会議などのサービスが普及しない主な理由である。
【０００３】
ビデオは、通信の各方向について広い帯域幅要件を特徴とし、通常の回線を圧倒するのに多数の同時接続を必要としない。したがって、物理的または単に金銭的な制限により基本的に制限のないトラフィックの量の正常な転送が妨げられるボトルネックにおける、この種のトラフィックの集中を回避することが非常に望ましい。
【０００４】
さらに、ある所与の方法をサポートするために必要な専門スタッフの時間および労力を最低限にすることが非常に望ましい。いくつかの方法では、保守、セットアップ、またはセキュリティの懸念事項によるコストの問題が引き起こされる。
【０００５】
音声およびビデオ用のピアツーピア様式を可能にするために、ＵＤＰホール・パンチング（ＵＤＰ  Ｈｏｌｅ  Ｐｕｎｃｈｉｎｇ）（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）ＭｉｄＣｏｍ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ，Ｐ２ＰＮＡＴ（Ｐｅｅｒ−２−Ｐｅｅｒ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）Ｄｒａｆｔ  ２）、およびＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ，Ｍｉｃｒｏｓｏｆｔ，ｅｔ．ａｌ）を含めて、ファイアウォールを横断するための既存の方法がいくつかあるが、これらの全ては、その使用時にピアツーピアの接続性をサポートするファイアウォールおよびその組合せの範囲が制限されている点で問題がある。
【０００６】
ＵＰｎＰ
簡単に言えば、適切に構成されたＵＰｎＰファイアウォール／ＮＡＴの背後の任意のクライアントは、ポートを外部のインターネットに直接マップすることができ、その結果、他の任意の外部クライアントをそれらのポートに対するサーバとして見ることになる。ほとんどのファイアウォールは、そのタイプに関わらず、クライアント／サーバ接続ができるように構成される。しかし、このプロトコルの欠点は、プロトコルが消費者用装置の製造者によってのみ採用されていることである。例えば、ＵＰｎＰサポートを有する企業クラスのファイアウォールはない。したがって、ＵＰｎＰは、企業間の接続性の問題を何ら解決することはなく、ピアの一方または両方が、それをサポートするファイアウォール／ＮＡＴの背後にある場合のみ機能する。
【０００７】
ＵＤＰホール・パンチング
ＵＤＰホール・パンチングは、より限定的である。ＩＥＴＦ  ＭｉｄＣｏｍワーキング・グループによって構想されるように、ファイアウォール／ＮＡＴの両方が、Ｃｏｎｅ−ＵＤＰタイプのものでなければならない（これは、通常、ローエンドの消費者用ステートレス・ファイアウォールに特有のものである）。これらの事例の状況が実際に発生する確率は、掛け算となるので、遺憾なことに、比較的稀となり、特に、企業対消費者ならびに企業間の事例では稀である。
【０００８】
他の方法
双方ともシンメトリック・ファイアウォール（一般に、企業対企業）の背後にある、何らかの２つの任意のクライアントの間のビデオ通信を可能にしたい場合、３つの選択肢があるが、全ての選択肢において、前述のトラフィックの集中とそれに伴う費用が発生するか、あるいは、特殊化されたインストール、設定、および／または積極的な管理、ならびに少なくとも一方のピアの内部ネットワークのための独自のプロキシ／リレー解決の権能がある要員による監視が必要である。
【０００９】
これら３つの選択肢とは、
１．少なくとも１つのクライアントが、共通のシグナリングおよび発呼プロトコルによって動的ポート・フォワーディングをサポートする機能を組み込むまたはインストールしたファイアウォールの背後にあることを要求することであり、それにより、前記ファイアウォールは、転送されたファイアウォールの背後にあるクライアントが、他のファイアウォールの背後のクライアントに対するサーバとして見えるように、使用されたポートが転送されることを保証されるようにすること、または、
２．クライアントのファイアウォールのうち１つの非武装地帯（ＤＭＺ）に配置されたプロキシ／リレー・サービスが、プロキシされたファイアウォールの背後のピアと外部のピアの間の通信を可能にすることを要求することであり、プロキシされたサービスの背後のクライアントは、やはり他のクライアントに対するサーバのように見えること、または、
３．プロキシ／リレー・サービスを、トラフィックを中継するために、両方のピアのファイアウォールの外部の既知の単一アドレスまたはアドレスのグループの背後に配置することであり、両方のクライアントは、共通のサーバによって通信し、すなわち中継されることである。
【００１０】
第１の選択肢は、国際電気通信連合のＨ．３２３プロトコル（Ｈ．３２３）、および、ＩＥＴＦのセッション開始プロトコル（ＳＩＰ）で例示される。両方のプロトコルは、ＩＰネットワークを介してピアツーピア接続を確立するための既定の接続およびシグナリング・プロトコルである。Ｈ．３２３およびＳＩＰは、多くの企業のファイアウォールでサポートされるが、全てでサポートされるわけではない。また、多くの大衆市場の消費者用ハードウェアおよびソフトウェア・ファイアウォールは、これらのプロトコルをサポートしない。これらのプロトコルは、多数および／または任意のＴＣＰおよびＵＤＰポートを使用するため、追跡することが難しく、解析し監視することが難しく、多くのファイアウォール管理者は、これらの監視および管理を業務とせずに、そのネイティブのサポートを有するファイアウォール内でこれらのプロトコルの機能を単にオフにする。さらに、Ｈ．３２３の参照実装でのセキュリティ・ホールに関する発見により、明らかに、多くの管理者がこのプロトコルを無効にする結果となる。一般に、この方法は、セキュリティ、管理容易性、広範性、および受容性の要件を満たすプロトコルであるかのように作用することができるが、Ｈ．３２３およびＳＩＰの場合には当てはまらず、上記の全ての要件を満たす標準化過程には存在しない。
【００１１】
第２の選択肢は、企業におけるピアツーピア・ビデオ・サービスを管理する好ましい方法となっているが、そのために発生するコストは、非対称的である。第２の選択肢では、管理者がＤＭＺにビデオ・リレー・サービスを（それに関するコストを負担して）提供するファイアウォールの背後に、少なくとも１つのクライアントがあることが必要なため、ＩＴ管理の視点からのあまりに防御可能な立場として、ビデオ・サービスが「私達」と「彼ら」の間にそれほど必要ならば、なぜ「彼ら」がプロキシ／リレー・サービスをインストールし維持するコストを引き受けないのか？、ということになる。一般的な結果として、結局誰もこの費用を引き受けないことになる。
【００１２】
第３の選択肢では、前記の２つの欠点の当然の帰結であり、任意の２つのシンメトリック・ファイアウォールの背後の任意の２つの所与のクライアントが互いに通信することを可能にする相当な費用よりも必要とされる費用が小さい相互運用可能な標準ベースの解決法が存在しない。第３者中継サービスを提供し、個別のエンドユーザ・ファイアウォール管理者のこのタスクを免除した場合、管理者の全体的アーキテクチャが大幅に単純化され、エンドユーザ間のコストが均等化され、共通のサービス・プロバイダ・ポイントが提供される。遺憾なことに、（複数の）共通ポイントは、この方法が、ビデオ接続性に対し、費用対効果が大きく拡張性のある解決法を提供する際の失敗の原因である。それぞれが各方向に（控えめに）２００Ｋｂを使用する、１００，０００の並行の双方向ビデオ会議に対する当該の解決法をサポートするために、中央のリレー・サービスは、４０，０００Ｍｂの回線接続性（４０００Ｔ１回線）をサポートしなければならない。追加のユーザごとに、さらに４００Ｋｂの能力を追加する必要がある。明らかに、これは、非常に高価であり、うまくスケール変更することができない。
【００１３】
以下に挙げる全ての間での真のピアツーピアの非プロキシ／非リレーの接続を同時に可能にすることによって、エンドユーザによる広範な採用および使用を妨げる上記の５つの方法（またはそれらの組合せ）の全ての上述の問題を、一挙に解決することができる既存のシステムは存在しないように思われる。
【００１４】
ＣｏｎｅまたはＵｐｎＰファイアウォール／ＮＡＴの背後のクライアントと同ファイアウォール／ＮＡＴの背後のクライアント、
ＣｏｎｅまたはＵｐｎＰファイアウォール／ＮＡＴの背後のクライアントとルーティング可能アドレス上のクライアント、
ＣｏｎｅまたはＵｐｎＰファイアウォール／ＮＡＴの背後のクライアントとＳｙｍｍｅｔｒｉｃファイアウォール／ＮＡＴの背後のクライアント、ならびに、
Ｓｙｍｍｅｔｒｉｃファイアウォール／ＮＡＴの背後のクライアントとルーティング可能アドレスの背後のクライアント、
Ｓｙｍｍｅｔｒｉｃファイアウォール／ＮＡＴの背後のクライアントとＳｙｍｍｅｔｒｉｃファイアウォール／ＮＡＴの背後のクライアント。
【特許文献１】米国特許出願第６０／５５１６１０号
【非特許文献１】Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）ＭｉｄＣｏｍ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ，Ｐ２ＰＮＡＴ（Ｐｅｅｒ−２−Ｐｅｅｒ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）Ｄｒａｆｔ  ２
【非特許文献２】Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ，Ｍｉｃｒｏｓｏｆｔ，ｅｔ．ａｌ
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明の目的は、各クライアントが背後にあるファイアウォール／ＮＡＴのタイプ、つまり、Ｃｏｎｅ（図１参照）、Ｐｏｒｔ−Ｒｅｓｔｒｉｃｔｅｄ  Ｃｏｎｅ（図２参照）、Ｓｙｍｍｅｔｒｉｃ（図３参照）、またはそれらの任意の組合せに関わらず、特定のプロトコル・サポート、クライアントごとのサーバ／サービスのインストール、あるいは一方または両方のクライアントのファイアウォール／ＮＡＴの設定なしに、クライアント間のピアツーピア接続を可能にすることである。
【００１６】
本発明の他の目的は、限定された状況において、ＮＡＴのいくつかは性質的に対称的である多重ＮＡＴ化されたクライアントの間のピアツーピア接続を可能にすることであり、これは、他の任意の方法または方法の組合せで不可能であった。
【課題を解決するための手段】
【００１７】
第１の目的を達成するために、シンメトリックまたはＣｏｎｅファイアウォール／ＮＡＴの背後のクライアント間のピアツーピア接続性を確立する方法は、クライアントのファイアウォールがクライアントにパケットを転送するために必要とされる適切なタプル（ソース／宛先ポート、およびソース／宛先アドレスの組合せ）が何であるかを発見することを含まなければならない。さらに、ファイアウォールの対称的ポート変換の振舞いは、Ｓｙｍｍｅｔｒｉｃ第２優先ＰＡＴ（Ｓｙｍｍｅｔｒｉｃ  Ｓｅｃｏｎｄ  Ｐｒｉｏｒｉｔｙ  ＰＡＴ）（図４Ａ参照）、およびＳｙｍｍｅｔｒｉｃ純粋ＰＡＴ（Ｓｙｍｍｅｔｒｉｃ  Ｐｕｒｅ  ＰＡＴ）（図４Ｂ参照）として特徴付けることができる。最終的に、発呼側クライアントは、被呼側クライアントとの双方向通信を確立したいと望み、そうするために、それぞれは、双方のクライアントのＮＡＴ／ＰＡＴ上のアドレスの組合せにどんなポートが割り当てられたかを詳しく知る。図５は、これを達成する際に内在する問題を示す。
【００１８】
第１の目的を達成するための第１の工程は、各クライアントのパブリックでルーティン可能なアドレスと、パブリックで可変なマスカレードされたポートの一例を、発見サーバと交信することによって得ることである。別個の各宛先サーバ・アドレス（および最終的には被呼側クライアントの宛先アドレス）は、Ｓｙｍｍｅｔｒｉｃ  ＮＡＴ／ＰＡＴに対する異なるポート・マッピングをもたらすので、第２の発見サーバに対する第２の要求が示される。これはまた、非常に過小利用のＮＡＴ／ＰＡＴにおいて、ポート・アドレス変換が、直接ポート・マッピングを、所与のポートの第１の内部ユーザに与え、後続のアドレスの連絡のためのマスカレードされたポートに与えない、図４Ａなどの事例を単純にする。したがって、第２および後続のアドレスされる要求は、マスカレードされたポートを使用することが保証される。
【００１９】
図５を参照すると、発呼側クライアントは、発見サーバからこの情報を取り出し第２のタプル（ソース／宛先ポートならびにソース／宛先アドレスの組合せ）を、既定のオープンの合意されたサーバを介して、被呼側クライアントに送る応答として、被呼側クライアントは、それ自体で同じことを行い、それの第２のタプルで発呼側クライアントに応答する。被呼側クライアントはまた、発呼側クライアントの報告されたソース・アドレスおよびソース・ポートへのＵＤＰパケットの送信を開始する。発呼側クライアントが、Ｃｏｎｅ  ＮＡＴの背後の場合、これらのパケットは送達される。発呼側クライアントが、Ｓｙｍｍｅｔｒｉｃ  ＮＡＴの背後の場合、これらのパケットは送達されない。その間に、発呼側クライアントが被呼側クライアントのタプルを受け取ると、発呼側クライアントも、被呼側クライアントの報告されたソース・アドレスおよびソース・ポートへのＵＤＰパケットの送信を開始する。被呼側クライアントが、Ｃｏｎｅ  ＮＡＴの背後の場合、これらのパケットは送達される。被呼側クライアントが、Ｓｙｍｍｅｔｒｉｃ  ＮＡＴの背後の場合、これらのパケットは、送達されない。
【００２０】
クライアントは、インバウンド・パケットを受け取った後、他のクライアントが背後にあるファイアウォール／ＮＡＴのタイプに関わらず、それのピアの適切な宛先ポートを分かる。
【００２１】
クライアントのうちの１つが、Ｃｏｎｅ  ＮＡＴの背後にある場合、元の宛先ポートへの送信の最初の数回の試みが成功する。ファイアウォールがパケットを転送すると、クライアントは、それを受け取りインバウンド・パケットのソース・ポートに留意し、次いで、その宛先ポートへ全てのトラフィックを送信することを理解する。さらに、クライアントは、成功パケットを送って、発見パケットの送信を停止できることを他のクライアントに示す。この段まで、プロセスは、逆向き接続と組み合わせた通常のＵＤＰホール・パンチと非常に類似しうる。プロセスの次の部分では、通常のＵＤＰホール・パンチ方法とは、大きく異なる。
【００２２】
両方のクライアントがシンメトリックＮＡＴの背後である場合、いずれのクライアントも、ＵＤＰパケットを受け取らない。
【００２３】
クライアントがこれらのＵＤＰパケットのうちの１つを受け取る前にある一定の期間が経過したとき、クライアントは、そのパケットを、単一の宛先ポートではなく全範囲のポートに送信すること（「ショットガン（ｓｈｏｔｇｕｎ）」）を開始する。  ポート・マスカレードを行うほどんとのファイアウォール／ＮＡＴは、単純なアルゴリズム（たいていは簡易な加算）を使用して、ポートを、ＵＤＰ要求を送るクライアントに割り当てる。十分に広い範囲では、ブルート・フォースで、他のピアのマスカレードされたポートが探し出されることが見込まれる。ファイアウォールがパケットを転送すると、クライアントは、それを受け取り、インバウンド・パケットのソース・ポートに留意し、次いで、全てのトラフィックをその宛先ポートに送ることを理解する。両方のクライアントは、シンメトリック・ファイアウォールの背後にある場合、それら双方は、この一連のＵＤＰパケットを、アクティブ・ポートを「探し出す」ために送り、両方のクライアントは、それらのピアのアクティブ宛先ポートを発見する。図６は、交換の各ポイントでの重要なファイアウォール状態テーブル・タプルを含む、このプロセスの全部のトラフィックおよびタプルの図である。図６は、簡潔にするために、第２の発見サーバの交信を省略していることに留意されたい。さらに、図中に記述されている「ショットガン」幅は、元のポートの幅から、例えば８などの値を元のポートに加えた幅までに限定される。好ましい実施形態では、例えば−１６から＋３２までのように、かなり広い範囲を使用する。
【００２４】
クライアントは、受信パケットの正の指標を得たとき、発見パケットの送信を停止できることを示すために、送信者に成功パケット応答を送る。これは、いつも成功するが、それは、応答を送るクライアントが、常に、このとき、送信すべき宛先ポートがどれかが分かるためである。図７は、上述のようなプロトコル交換全体のフローチャートを示す。
【００２５】
続いて、全てのペイロードが、所与のクライアントから、この識別されたポートを用いて送られる。
【００２６】
本発明の第２の目的を達成するために、ポートを直接マップするための第１の工程として、双方のクライアントは、使用可能ならばＵＰｎＰサポートを使用し、それにより、逆向き接続が保証される。ソース・ポートとマスカレード（偽装）された宛先ポートのマッチングするさらなる能力は、動的ポート範囲上の出力ＵＤＰ要求を許可しないよう手動で構成されたシンメトリック・ファイアウォールと通信する能力を提供する。図８は、ＵＰｎＰ工程を含むプロトコル交換全体のフローチャートを示す。
本発明の例示的実施形態を、添付の図面を参照して以下で簡潔に述べる。
【発明を実施するための最良の形態】
【００２７】
本発明の態様、特徴、および利点は、添付の図面を参照した以下の説明に関連し、より良く理解されよう。以下に述べるのは、本発明の好ましい実施形態である。上記は、例として提示されており、限定ではなく例示が目的に過ぎないことは、当業者には理解されるべきである。この説明に開示される全ての特徴は、特にことわらない限り、同じ目的、および等価または同様の目的を果たす、代替の特徴によって置き換えることができる。したがって、その修正された多数の他の実施形態が、本明細書に定義された本発明の範囲またはその均等物に含まれるものとして企図される。この説明の過程で、同じ番号が、使用されうるが、それは、本発明を例示する異なる複数の図における同様の要素を同一視している。
【００２８】
本発明の好ましい実施形態の一例は、以下のような方法を含む。
２つ以上の発見サーバが、異なるアドレスに配置され、それそれは、一連の既定のＵＳＤポートをリスンし、それぞれは、クライアントからの適格に形成された要求に対し、要求側クライアントのパブリック・アドレスおよびパブリック・ポートを含む応答によって応答し、２つのクライアントが、次の順序で、この方法の以下の工程を実行する。
【００２９】
発呼側クライアントは、ローカルＮＡＴがもし存在するならばＵｐｎＰをサポートするかどうかを決定する。発呼側クライアントはまた、ローカルＮＡＴがもし存在するならばＵｐｎＰクライアント起動ポート・フォワーディングをサポートするかどうかを決定する。
【００３０】
上記が真の場合、発呼側クライアントは、ＵＰｎＰを介して直接ＮＡＴによって、ソース・ポートを宛先ポートに全く同じにマップしようと試みる。
【００３１】
発呼側クライアントは、既定のソースおよび宛先ポートを介して、第１のアドレスにある第１の発見サーバと交信し応答を受け取ることによって、発呼側クライアントのプライベート・アドレス、プレイベート・ソース・ポート、パブリック・アドレス、パブリック・ソース・ポート、およびパブリック宛先ポート・タプルを取り出す（ＤＵＤＰ＿ＳＴＡＲＴ要求、ＤＵＤＰ＿ＰＵＢＩＮＦＯ応答）。
【００３２】
発呼側クライアントは、第１の場合と同様に同じ既定のソースおよび宛先ポートを介して、第２のアドレスにある第２の発見サーバと交信し応答を受け取ることによって、発呼側クライアントのプライベート・アドレス、パブリック・アドレス、プライベート宛先ポート、およびパブリック宛先ポート・タプルを取り出す（ＤＵＤＰ＿ＳＴＡＲＴ要求、ＤＵＤＰ＿ＰＵＢＩＮＦＯ応答）。
【００３３】
発呼側クライアントは、その受信した第２のタプルの内容、ならびに、第１の発見報告されたソース・ポートと第２の発見報告されたソース・ポートの差分を、この目的のために、互いに合意され確立されたサーバを介して被呼側クライアントに送る（ＭＥＳＳＡＧＥ＿ＣＯＮＴＲＯＬ）。
【００３４】
被呼側クライアントが、送信側から呼出しを受け取る意思がない場合、送信側に打切りの信号が送られ、プロセスを停止する。
【００３５】
被呼側クライアントが、送信側から呼出しを受け取る意思がある場合、被呼側クライアントは、ローカルＮＡＴがもし存在するならばＵＰｎＰをサポートするかどうかを決定する。次に、被呼側クライアントは、ローカルＮＡＴがもし存在するならばＵｐｎＰクライアント起動ポート・フォワーディングをサポートするかどうかを決定する。上記が真の場合、発呼側クライアントは、ＵＰｎＰを介して直接ＮＡＴによって、ソース・ポートを宛先ポートに全く同じにマップしようと試みる。
【００３６】
被呼側クライアントは、既定のソースおよび宛先ポートを介して、第１の発見サーバと交信し応答を受け取ることによって、発呼側クライアントのタプル（ＭＥＳＳＡＧＥ＿ＣＯＮＴＲＯＬ）、ならびに、被呼側クライアント自体のソース・アドレス、パブリック・アドレス、ソース・ポート、および宛先ポート・タプルを取り出す（ＤＵＤＰ＿ＳＴＡＲＴ要求、ＤＵＤＰ＿ＰＵＢＩＮＦＯ応答）。
被呼側クライアントは、上記のように同じ既定のソースおよび宛先ポートを介して、第２のアドレスにある第２の発見サーバと交信し応答を受け取ることによって、被呼側クライアントのソース・アドレス、パブリック・アドレス、ソース・ポート、および宛先ポート・タプルを取り出す。（ＤＵＤＰ＿ＳＴＡＲＴ要求、ＤＵＤＰ＿ＰＵＢＩＮＦＯ応答）。
【００３７】
被呼側クライアントは、その受信した第２のタプルの内容、第１の発見報告されたソース・ポートと第２の発見報告されたソース・ポートの差分、および、発呼側クライアントのタプルに対する任意の所望の変更を、互いに合意され確立されたサーバを介して発呼側クライアントに送る。
【００３８】
次いで、被呼側クライアントは、発呼側のＭＥＳＳＡＧＥ＿ＣＯＮＴＲＯＬがうまく受信できた場合、それによって、被呼側に報告されたタプルに従って、発呼側クライアントのアドレスおよびソース・ポートへのＵＤＰパケット（ＤＵＭＰ＿ＡＣＫ）の定期的送信を開始する。
【００３９】
発呼側クライアントは、被呼側クライアントからのタプル応答（ＭＥＳＳＡＧＥ＿ＣＯＮＴＲＯＬ）をうまく受信すると、被呼側クライアントのＭＥＳＳＡＧＥ＿ＣＯＮＴＲＯＬによって、発呼側に報告されたタプルに従って、被呼側クライアントのアドレスおよびソース・ポートへのＵＤＰパケット（ＤＵＭＰ＿ＡＣＫ）の定期的送信を開始する。
【００４０】
発呼側クライアントは、ＤＵＤＰ  ＡＣＫを受け取った場合、前記パケットのＩＰヘッダ内で識別されたソース・ポートに留意し、それを後続の出力ＤＵＤＰ＿ＡＣＫパケットのために使用し、このポートをさらなるぺイロード・トラフィックのためにマーク付けし、さらに、ＤＵＤＰ＿ＡＣＫ２パケットをこの宛先ポートに送る。ＤＵＤＰ＿ＡＣＫパケットが一定の期間内に受信されない場合、被呼側クライアントの差分により外挿された予測値を超えて隣接している範囲内の宛先ポートをそれぞれが有する一連のＤＵＤＰ＿ＡＣＫパケットを、単一宛先ポートへの単一パケットの代わりに、定期的に送信する。この一連の継続的な反復される送信は、反復のたびに、ポート範囲ウィンドウを移動させることができる。
【００４１】
被呼側クライアントは、ＤＵＤＰ  ＡＣＫパケットを受け取った場合、パケットのＩＰヘッダ内で識別されたソース・ポートに留意し、それを後続の出力ＤＵＤＰ＿ＡＣＫパケットのために使用し、このポートをさらなるぺイロード・トラフィックのためにマーク付けし、さらに、ＤＵＤＰ＿ＡＣＫ２パケットをこのポートに送る。ＤＵＤＰ＿ＡＣＫパケットが一定の期間内に受信されない場合、発呼側クライアントの差分により推定された予測値を超えて隣接している範囲内の宛先ポートをそれぞれが有する一連のＤＵＤＰ＿ＡＣＫパケットを、単一宛先ポートへの単一パケットの代わりに、定期的に送信する。この一連の継続的な反復される送信は、反復のたびに、ポート範囲ウィンドウを移動させることができる。
【００４２】
発呼側クライアントは、タイムアウトするかまたはＤＵＤＰ＿ＡＣＫ２パケットを受け取った場合、宛先ポート・フェイルオーバ値として、報告された被呼側クライアントの報告されたタプル・ソース・ポートを使用して、発呼側クライアントが適切にマーク付けされた宛先ポートを有すると仮定する。
【００４３】
被呼側クライアントは、タイムアウトするかまたはＤＵＤＰ＿ＡＣＫ２パケットを受け取った場合、宛先ポート・フェイルオーバ値として、報告された発呼側クライアントの報告されたタプル・ソース・ポートを使用して、被呼側クライアントが適切にマーク付けされた宛先ポートを有すると仮定する。
【００４４】
発呼側クライアントは、適切なマーク付けされた宛先ポートを有する場合、被呼側クライアントに対するこのポートへのペイロード・データの送信を開始する。
【００４５】
被呼側クライアントは、適切なマーク付けされた宛先ポートを有する場合、発呼側クライアントに対するこのポートへのペイロード・データの送信を開始する。
【００４６】
図９は、本発明の原理による、通信ネットワークを介するピアツーピア通信を提供するための例示的システムのハイレベル・ブロック図である。一般に、このシステムは、通信ネットワーク、および、通信ネットワークに接続された任意の数のクライアントを含む。クライアントは、関連付けられたファイアウォール技術の背後にある通信ネットワークとインターフェースをとる。
【００４７】
通信ネットワークは、以下に限定されないが、ローカルエリア・ネットワーク、インターネットまたは他の広域ネットワーク、衛星または無線通信ネットワーク、商業付加価値ネットワーク（ＶＡＮ）、通常の電話回線、あるいは専用線を含む、様々な形態を取ることができる。使用される通信ネットワークは、エンドポイント間の高速の信頼できるデータ通信を提供しさえすればよい。
【００４８】
各クライアントは、以下に限定されないが、コンピュータ・システム、メインフレーム・システム、スーパミニ・システム、ミニコンピュータ・システム、ワークステーション、ラップトップ・システム、ハンドヘルド・デバイス、モバイル・システム、または他の携帯機器などを含む、中央処理装置ならびに必要なビデオおよび／またはオーディオ機能を有する任意の形態のシステムとすることができる。
【００４９】
ファイアウォール技術には、本明細書に記載のものに加え、他の等価なハードウェアおよび／またはソフトウェア技法が含まれる。
【００５０】
本発明の好ましい実施形態について説明したが、上記は、例示が目的に過ぎず限定するものではなく、単に例として提示されていることは、当業者には明らかなはずである。（添付の特許請求の範囲、要約書、および図面のいずれも含む）この明細書に開示された全ての特徴は、特にことわらない限り、同じ目的、および等価または同様の目的を果たす、代替の特徴によって置き換えることができる。したがって、その修正された多数の他の実施形態が、添付の特許請求の範囲に定義された本発明の範囲またはその均等物に含まれるものとして企図される。
【００５１】
例えば、本発明は、ハードウェア、ソフトウェア、またはこの２つの組合せで実装してもよい。本発明の態様は、プロセッサ、（揮発性および不揮発性のメモリおよび／または記憶要素を含む）プロセッサで読取り可能な記憶媒体、ならびに少なくとも１つの入力装置および１つまたは複数の出力装置を、それぞれが含むプログラム可能コンピュータ上で実行される、１つまたは複数のコンピュータ・プログラムで実装されることが好ましい。プログラム・コードは、上記の機能を実行し、出力情報を生成するために、入力装置を用いて入力されたデータに適用される。出力情報は、１つまたは複数の出力装置に適用される。
【００５２】
各プログラムは、コンピュータ・システムと通信するために、高水準手続き型またはオブジェクト指向プログラミング言語で実装することが好ましいが、必要に応じてアセンブリ言語または機械語で実装することもできる。いずれの場合も、言語は、コンパイル型またはインタプリタ型言語とすることができる。
【００５３】
このような各コンピュータ・プログラムは、この文書に記載の手順を実行するために、記憶媒体または装置がコンピュータによって読み取られるときに、コンピュータを構成し動作させるために当該の汎用または専用のプログラム可能コンピュータによって読み取ることができる、記憶媒体または装置（例えば、ＣＤ−ＲＯＭ、ＲＯＭ、ハードディスク、または磁気ディスケット）上に記憶されることが好ましい。また、コンピュータ・プログラムによって構成されたコンピュータ可読記憶媒体としてシステムを実装し、こうして構成された記憶媒体により、コンピュータが特定または事前定義の方法で動作するようにすることも考えられる。例示として、本発明は、システム構成、動作および製品の方法、あるいは、フロッピー（登録商標）・ディスク、従来のハードディスク、ＣＤ−ＲＯＭ、フラッシュＲＯＭ、不揮発性ＲＯＭ、ＲＡＭ、および他の任意の同等のコンピュータ記憶装置などのコンピュータ可読媒体として実施される。システムならびに動作および製品の方法は、その構成および動作の細部について、本明細書に開示の基本概念から逸脱することなく変更できることは理解されよう。
【図面の簡単な説明】
【００５４】
【図１】クライアントがＣｏｎｅ  ＮＡＴ／ＰＡＴの背後にあるシステムにおける要求および応答を示す図である。
【図２】クライアントがＰｏｒｔ−Ｒｅｓｔｒｉｃｔｅｄ  Ｃｏｎｅ  ＮＡＴ／ＰＡＴの背後にあるシステムにおける要求および応答を示す図である。
【図３】クライアントがＳｙｍｍｅｔｒｉｃ  ＮＡＴ／ＰＡＴの背後にあるシステムにおける要求および応答を示す図である。
【図４Ａ】クライアントが第２優先マスカレードＮＡＴ／ＰＡＴの背後にあるシステムにおける要求および応答を示す図である。
【図４Ｂ】クライアントが純粋マスカレードＮＡＴ／ＰＡＴの背後にあるシステムにおける要求および応答を示す図である。
【図５Ａ】シンメトリックＮＡＴの背後のクライアントの間の逆向き接続の失敗における、初期の発見要求および応答を示す図である。
【図５Ｂ】シンメトリックＮＡＴの背後のクライアントの間の逆向き接続の失敗を示す図である。
【図６Ａ】シンメトリックＮＡＴ／ＰＡＴの背後のクライアントの間の初期段のショットガン交換を示す図である。
【図６Ｂ】シンメトリックＮＡＴ／ＰＡＴの背後のクライアントの間の後段のショットガン交換を示す図である。
【図７】発見、メッセージ交換、およびショットガン・プロセスを示すフローチャートである。
【図８】ＵＰｎＰを使用した、発見、メッセージ交換、およびショットガン・プロセスを示すフローチャートである。
【図９】本明細書の教示による本発明の他の態様を示す図である。
【図１】
2007528677.tif 000003
【図２】
2007528677.tif 000004
【図３】
2007528677.tif 000005
【図４Ａ】
2007528677.tif 000006
【図４Ｂ】
2007528677.tif 000007
【図５Ａ】
2007528677.tif 000008
【図５Ｂ】
2007528677.tif 000009
【図６Ａ】
2007528677.tif 000010
【図６Ｂ】
2007528677.tif 000011
【図７】
2007528677.tif 000012
【図８】
2007528677.tif 000013
【図９】
2007528677.tif 000014
【国際調査報告】
2007528677.tif 000015