(57)【要約】  ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用して、ピア間にピア・ツー・ピア通信チャンネルを与えるためにネットワーク障害を回避する方法は、障害を含むネットワークを通してピア装置から中継装置へＨＴＴＰ要求を通信するステップを備え、前記ＨＴＴＰ要求は、別のピア装置に意図されたものである。この方法は、更に、ＨＴＴＰ応答を中継装置からピア装置へ通信するステップと、ピア装置と別のピア装置との間で中継装置を経て通信チャンネルを確立するステップとを備えている。通信チャンネルは、ピア装置及び別のピア装置がデータを送信及び受信するのを許す。【選択図】図２
2008544386.tif 000002
【特許請求の範囲】
【請求項１】
ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用してピア間にピア・ツー・ピア通信チャンネルを与えるためにネットワーク障害を回避する方法において、
障害を含むネットワークを通してピア装置から中継装置へＨＴＴＰ要求を通信するステップであって、前記ＨＴＴＰ要求は別のピア装置に対して意図されたものであるステップと、
ＨＴＴＰ応答を前記中継装置から前記ピア装置へ通信するステップと、
前記ピア装置と別のピア装置との間で前記中継装置を経て通信チャンネルを確立するステップであって、前記通信チャンネルは、前記ピア装置及び別のピア装置がデータを送信及び受信するのを許すようなステップと、
を備えた方法。
【請求項２】
前記ＨＴＴＰ応答は、ピア特有のシグナリングを含む、請求項１に記載の方法。
【請求項３】
前記ピア装置は、移動装置で実行されるソフトウェアを含む、請求項１に記載の方法。
【請求項４】
前記ＨＴＴＰ要求は、別のピア装置に対して意図されたデータを含む、請求項１に記載の方法。
【請求項５】
前記ＨＴＴＰ要求は、コンフィギュレーション情報を含む、請求項１に記載の方法。
【請求項６】
前記ピア装置は、スマートフォンを含む、請求項１に記載の方法。
【請求項７】
前記障害は、ファイアウオールを含む、請求項１に記載の方法。
【請求項８】
前記障害は、ネットワークアドレス変換（ＮＡＴ）サーバーを含む、請求項１に記載の方法。
【請求項９】
前記ＨＴＴＰ要求は、前記ピア装置が接続を聴取しているという指示を含む、請求項１に記載の方法。
【請求項１０】
前記中継装置は、第１ピアから通信されるデータをバッファしない、請求項１に記載の方法。
【請求項１１】
ピア間にピア・ツー・ピア通信チャンネルを与えるためにネットワーク障害を回避するシステムにおいて、
障害を含むネットワークを経て中継装置と通信する第１ピア装置と、
前記中継装置を経て前記第１ピア装置と通信する第２ピア装置と、
前記第１及び第２ピア装置に結合されたサーバーであって、前記中継装置の機能を実行するためにプログラムされたインストラクションを含み、前記第１ピア装置からＨＴＴＰ要求を受け取るサーバーと、
を備え、前記ＨＴＴＰ要求は、別のピア装置に意図されたデータを含み、更に、前記サーバーは、前記第１ピア装置と第２ピア装置との間に通信チャンネルを確立して、データの送信及び受信を可能にする、システム。
【請求項１２】
前記障害は、ファイアウオールを含む、請求項１１に記載のシステム。
【請求項１３】
前記第１ピア装置は、スマートフォンを含む、請求項１２に記載のシステム。
【請求項１４】
前記ＨＴＴＰ要求は、ピア特有のシグナリングを含む、請求項１１に記載のシステム。
【請求項１５】
前記第１ピア装置は、アプリケーションプログラミングインターフェイス（ＡＰＩ）を実施するミッドレットを含む、請求項１１に記載のシステム。
【請求項１６】
ネットワーク障害を回避すると共に、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用してピア間にピア・ツー・ピア通信チャンネルを与えるためのコンピュータプログラム製品において、
ピア装置から、障害を含むネットワークを経て中継装置へＨＴＴＰ要求を通信するコンピュータコードであって、前記ＨＴＴＰ要求が別のピア装置に意図されたものであるようなコンピュータコードと、
前記中継装置から前記ピア装置へＨＴＴＰ応答を通信するコンピュータコードと、
前記ピア装置と別のピア装置との間に前記中継装置を経て通信チャンネルを確立するコンピュータコードであって、前記通信チャンネルは、前記ピア装置及び別のピア装置がデータを送信及び受信するのを許すようなコンピュータコードと、
を備えたコンピュータプログラム製品。
【請求項１７】
前記障害は、ファイアウオールを含む、請求項１６に記載のコンピュータプログラム製品。
【請求項１８】
前記障害は、ネットワークアドレス変換（ＮＡＴ）サーバーを含む、請求項１６に記載のコンピュータプログラム製品。
【請求項１９】
前記ピア装置は、スマートフォンを含む、請求項１６に記載のコンピュータプログラム製品。
【請求項２０】
前記ピア装置は、コンピュータを含む、請求項１６に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、ファイアウオール及びピア・ツー・ピア接続に係る。より詳細には、本発明は、ファイアウオール及びネットワークアドレス変換（ＮＡＴ）サーバーのような手段を使用してピア・ツー・ピア（Ｐ２Ｐ）接続を単純に確立するのを妨げるネットワークを経て、ＰＣと、スマートフォン、又はパーソナルコンピュータを含む他の装置との間に、Ｐ２Ｐ接続を確立するためのシステム及び方法に係る。
【背景技術】
【０００２】
本節は、背景又は環境について説明する。ここでの説明は、追及することのできる概念を含むが、これは、必ずしも、従来考えられ又は追求されたものではない。それ故、特に指示のない限り、本節で述べるのは、本出願の請求の範囲に対する従来技術でもないし、本節に含ませることにより従来技術であると認められるものでもない。
【０００３】
インターネット上の大半の装置は、固定のもの（例えば、パーソナルコンピュータ）であろうと移動のもの（例えば、スマートフォン）であろうと、あるインターネットサービスプロバイダー（ＩＳＰ）又はあるセルラーネットワークオペレータ（ＣＮＯ）によって提供されるネットワーク接続を経てインターネットに接続される。インターネットを経てコンテンツにアクセスするための慣習的なモデルは、ウェブサーバーを中心とするもので、コンテンツは、コンテンツプロバイダーにより、サービスプロバイダーにより動作されるウェブサーバーに入れられ（しばしば、ＩＳＰ及びＣＮＯは、コンテンツ及びサービスプロバイダーの両方の役割を果たす）、次いで、特定のコンテンツに関心のあるユーザがそれに対応するウェブサーバーにアクセスしてそれを得る。このコンテンツ配布モデルでは、あるコンテンツを所有できるユーザは、それをあるウェブサーバーに入れない限り、他のユーザへ直接提示することができない。
【０００４】
ウェブサーバーを中心とするこのコンテンツ配布モデルの代替がピア・ツー・ピア（Ｐ２Ｐ）接続モデルである。ここで、ユーザは、自分が所有するコンテンツを他のユーザと直接共有しない。各Ｐ２Ｐプロトコル（Ｎａｐｓｔｅｒ、Ｇｎｕｔｅｌｌａ、Ｃｈｏｒｄ、ＦａｓｔＴｒａｃｋ、等）は、コンテンツ位置サービスが集中化又は分散化された状態で出現し、これは、特定のコンテンツを含むピアの位置を許す。このような位置サービスを使用して、ある特定のコンテンツを探すユーザは、当該コンテンツを提示してそこから検索する別のユーザの装置に接続することができる。
【０００５】
Ｐ２Ｐプロトコルがインターネットを経て機能するためには、インターネットのエッジ（例えば、ＰＣ又はスマートフォン）において２つのピア間に接続を確立できねばならない。特に、ネットワークを保護し制御するためにＩＳＰ及びＣＮＯにより使用されるファイアウオール及びＮＡＴサーバーにより課せられる制約を考慮に入れて、この要件を満足することは、些細なことでは済まない。
【０００６】
ファイアウオールは、それらを通過するデータトラフィックを制御するために使用される。実際に、このようなファイアウオールの大多数は、平易なＩＰトラフィック（ＴＣＰ又はＵＤＰを経ての）が阻止される間に、懇請されたＨＴＴＰトラフィックだけがスマートフォン又はＰＣに到達することしか許さない。たとえスマートフォンがＨＴＴＰサーバーを有していても、リモート装置によりそのサーバーへ送信されるＨＴＴＰ要求は、これらファイアウオールを通過しない。というのは、ＨＴＴＰメッセージが受信側スマートフォンにより懇請されないからである。その結果、このような厳格なファイアウオールポリシーの場合に、このようなファイアウオールの異なる側に存在する２つのピア間にＰ２Ｐ接続を確立する簡単な方法はない。
【０００７】
又、ＮＡＴサーバーは、特に、一方のピアが、インターネットに接続される間に異なるＣＮＯを横切ってローミングするスマートフォンである場合には、Ｐ２Ｐ接続への障害物も生成する。この場合には、スマートフォンがＰ２Ｐオーバーレイネットワークに接続される間に、そのＩＰアドレスを変更し、その結果、以前のＩＰアドレスへと確立された全てのソケット接続を失うことになる。
【０００８】
固定及び移動の両インターネットの場合にファイアウオール及びＮＡＴサーバーを含む環境においてＰ２Ｐ接続を確立する問題を解決するために幾つかの試みが以前になされている。固定のインターネットにおいて、ピア（ＰＣ）には、それがネットワークに接続されるたびに、ＮＡＴサーバーによりおそらく異なるＩＰアドレスが指定される。しかしながら、ピアがネットワークに接続されたままである限り、ＩＰアドレスは変更されない。従って、ネットワークに接続されている間にＩＰアドレスを変更する問題は、固定のインターネットには現われず、その結果、既存のＰ２Ｐプロトコルは、このような場合の解決を与えない。しかしながら、移動装置によりインターネットに接続される用途では、ローミングするスマートフォンが、ネットワークに接続されている間にそのＩＰアドレスを変化させることがある。従って、固定のインターネットからのＰ２Ｐプロトコルは、正しく動作することができない。
【０００９】
固定のインターネットでは、会社のネットワークは、懇請されたＨＴＴＰトラフィックしか、会社のネットワークに接続されたＰＣには到達しないという厳格なセキュリティポリシーを実施するファイアウオールを備えることができる。同様に、多くのセルラーネットワークオペレータ（ＣＮＯ）ファイアウオールも、同じ厳格なセキュリティポリシーを実施する。ＣＮＯファイアウオールの存在にも関らずＰ２Ｐ接続に対する多数の解決策がＳＩＰ配備の状況において提案されている。というのは、ＳＩＰトラフィックが、懇請されない他のＨＴＴＰトラフィックと同じファイアウオールからの制約に直面するからである。これらの解決策は、ＳＩＰトラフィックの通過を許すためにファイアウオールにおけるピンホールの動的な割り当てに依存する。このような解決策は、懇請されたＨＴＴＰトラフィックと同様の、特定トラフィックの別のケースを生成する。それらは、Ｐ２Ｐ接続の確立に対する一般的な解決策ではない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
懇請されたＨＴＴＰトラフィックの通過しか許さないファイアウオールと、ローミングするスマートフォンのＩＰアドレスを変化させるＮＡＴサーバーとにより課せられる障害にも関らず、ＰＣとスマートフォンとの間にピア・ツー・ピア（Ｐ２Ｐ）接続を確立することが要望される。更に、特殊なファイアウオール特徴に依存しないファイアウオールを含むネットワーク環境において機能する信頼性のあるピア・ツー・ピア通信プロトコルも要望される。
【課題を解決するための手段】
【００１１】
一般に、ここに述べる実施形態は、懇請されたＨＴＴＰトラフィックの通過しか許さないファイアウオールと、ローミングするスマートフォンのＩＰアドレスを変化させるネットワークアドレス変換（ＮＡＴ）サーバーとにより課せられる障害にも関らず、パーソナルコンピュータ（ＰＣ）と、スマートフォンとの間にピア・ツー・ピア接続を確立する。この実施形態は、メッセージを中継するＨＴＴＰベースのプロトコルを利用する。このプロトコルの目的は、２つのターミナル間のファイアウオールにも関らず、それらの間のソケット接続を可能にすることである。このプロトコルは、ファイアウオールからの好都合な振舞い（例えば、特定のＴＣＰ（送信制御プロトコル）又はＵＤＰ（ユーザデータグラムプロトコル）トラフィックに対して「ピンホール」を開くこと）を期待せずに、ＨＴＴＰ要求及び応答を使用してピア間にメッセージを中継することである。
【００１２】
１つの実施形態は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用してピア間にピア・ツー・ピア通信チャンネルを与えるためにネットワーク障害を回避する方法に係る。この方法は、障害を含むネットワークを通してピア装置から中継装置へＨＴＴＰ要求を通信するステップを含み、ＨＴＴＰ要求は、別のピア装置に意図されたデータを含む。この方法は、更に、ＨＴＴＰ応答におけるデータを中継装置からピア装置へ通信するステップと、２つのピア装置間で中継装置を経て通信チャンネルを確立するステップとを備えている。通信チャンネルは、ピア装置及び別のピア装置がデータを送信及び受信するのを許す。
【００１３】
別の実施形態は、ピア間にピア・ツー・ピア通信チャンネルを与えるためにネットワーク障害を回避するシステムに係る。このシステムは、障害を含むネットワークを経て中継装置と通信する第１ピア装置と、別の装置を含むネットワークを経て同じ中継装置と通信する第２ピア装置と、これら第１及び第２ピア装置に結合されたサーバーであって、第１ピア装置から第２ピア装置へ及びそれとは逆に通信を中継する機能を実行するためのプログラムされたインストラクションを含むサーバーとを備えている。サーバーは、第１ピア装置からＨＴＴＰ要求を受け取る。このＨＴＴＰ要求は、別のピア装置に意図されたデータを含む。サーバーは、更に、前記データを意図されたピア装置へ中継し、第１ピア装置と第２ピア装置との間にバーチャル通信チャンネルを確立して、データの送信及び受信を可能にする。
【００１４】
別の実施形態は、ネットワーク障害を回避すると共に、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用してピア間にピア・ツー・ピア通信チャンネルを与えるためのコンピュータプログラム製品に係る。このコンピュータプログラム製品は、ピア装置から、障害を含むネットワークを経て中継装置へ、及び別のピア装置へ、ＨＴＴＰ要求を通信するコンピュータコードと、中継装置からピア装置へＨＴＴＰ応答を通信するコンピュータコードと、ピア装置と別のピア装置との間に中継装置を経て通信チャンネルを確立するコンピュータコードとを含むことができる。通信チャンネルは、ピア装置及び別のピア装置がデータを送信及び受信するのを許す。
【発明を実施するための最良の形態】
【００１５】
図１は、ピア・ツー・ピアシステム１０を示す。この実施形態において、ピア・ツー・ピアシステム１０は、ピア装置１２と、セルラーネットワークオペレータ（ＣＮＯ）１４と、ファイアウオール１６と、ネットワーク１８と、サーバー２０と、中間点ソフトウェア２２と、ＣＮＯ２４と、ファイアウオール２６と、ピア装置２８とを備えている。ピア・ツー・ピアシステム１０には、実施例又は実施形態に基づいて、付加的な、より少数の、又は異なる装置が含まれてもよい。ピア装置１２及びピア装置２８は、図１にピアソフトウェア１２１及びピアソフトウェア２８１と示されたソフトウェア、例えば、他のピア装置とピア・ツー・ピア通信するためのアプリケーションプログラミングインターフェイス（ＡＰＩ）を可能にするミドレット(midlet)を含む。ネットワーク１８は、インターネット、又は別の同様の装置ネットワークである。サーバー２０は、ネットワーク１８に結合され、そしてＨＴＴＰ（ハイパーテキスト転送プロトコル）メッセージを使用して通信する。中間点ソフトウェア２２がサーバー２０に常駐され、ピア装置間のピア・ツー・ピア通信を容易にするためのインストラクションを与える。中間点ソフトウェア２２及びサーバー２０は、ピア装置間のピア・ツー・ピア通信において中継装置として機能する。
【００１６】
ピア・ツー・ピアシステム１０におけるピア・ツー・ピア通信は、ピア間に確立される通信チャンネルを使用して実行される。ピア装置１２におけるアプリケーション１２２及びピア装置２８におけるアプリケーション２８２の観点から、通信チャンネルは、ソケット接続として動作する。一方のピアは、接続を聴取し、別のピアは、最初のピアとの接続を確立し、次いで、通信チャンネルの両側でそのチャンネルを経てデータを送信及び受信することができる。ピア装置１２及び２８における各々アプリケーション１２２及び２８２は、接続を聴取し、接続を確立し、そして確立された接続を経てデータを送信／受信することができる。あるピアは、他のピアがそれに接続して通信チャンネルを生成するのを許そうとするときに、このピアが接続を聴取すること、及び所与のピアが接続を聴取する終了点とをサーバー２０へ通信する。あるピアは、おそらく接続を聴取するリモートピアとの接続を確立するよう試みるときに、このピアがリモートピアへの接続の確立を試みることと、所与のピアが接続の確立を試みるリモートピアの終了点とをサーバー２０に通信しなければならない。
【００１７】
例えば、ピア装置１２のアプリケーションと、ピア装置２８のアプリケーションとの間の接続が確立されるときには、その各々が他方へデータを送信し、そして他方により送られるデータを受信することができる。アプリケーション１２２がアプリケーション２８２へ送信しようとするデータは、次の経路に沿って進行する。即ち、アプリケーション１２２は、ピア１２１により与えられるソケット接続にデータを書き込み、ピア１２１は、データをＨＴＴＰ要求でパッケージし、それを中間点２２へ送信し、中間点２２は、受信したＨＴＴＰ要求におけるデータをＨＴＴＰ応答にコピーし、これは、ピア２８１へ返送され、ピア２８１は、ＨＴＴＰ応答を受け取り、データを抽出し、そしてそれを、ピア２８１が与えるソケットにおいてアプリケーション２８２が読み取りオペレーションを遂行するまでバッファする。サーバー２０は、データをバッファしない。サーバー２０は、確立された通信チャンネルに関する情報を保持し、そしてピアにより送信されたデータを意図された受信者へ転送する。
【００１８】
ピアがリモートピアとで通信チャンネルを確立したときから、送信されたデータが到着するために受信側ピアによって明確なアクションが行われる必要はない。しかしながら、受信側ピアの最上部で実行されるアプリケーションは、受信したデータを直ちに消費することができない。このため、受信側ピアは、受信したデータを、それがその関連アプリケーションによって消費されるまでバッファする。ピアの受信バッファは、限定サイズであるから、オーバーフローすることが考えられる（例えば、関連アプリケーションが、それに対応するピアがデータを受信するよりもゆっくりとデータを消費する場合）。このような事象が生じると、受信側ピアは、受信側ピアは、サーバー２０にオーバーフローについて通知することができる。サーバー２０は、このような受信側サーバーのオーバーフロー通知を受け取ると、データを送信したピアに、事象に関してオーバーフローが生じたことを通知する。
【００１９】
受信側ピアが受信側バッファのオーバーフローについてサーバーに通知するかどうかの選択は、確立された通信チャンネルの特性に依存する。通信チャンネルが非信頼性接続（例えば、ＵＤＰデータグラム接続）として確立される場合には、バッファのオーバーフローを経験するピアにより通知を送信する必要がない。通信チャンネルが信頼性ストリーム（例えば、ＴＣＰセッション）として確立される場合には、バッファオーバーフローを経験するピアにより通知が発生される。
【００２０】
図２は、通信チャンネルが確立されそしてそれを経てデータが交換される、２つのピアと中継装置との間の対話のシーケンスを示す図である。ピアＡは、接続を聴取し、ピアＢは、ピアＡへの接続を確立し、ピアＡは、メッセージを送信し、そしてピアＢは、それを受け取ると、メッセージを送信する。ピアと中継装置との間の対話は、応答に関連した同期メッセージとして定義される。
【００２１】
例えば、他のピアからの接続を聴取したいピアは、接続を聴取するというピアの意図を指示するＬＩＳＴＥＮ＿ＲＥＱメッセージを中継装置へ送信することにより、その意図を中継装置に通知する。応答として、中継装置は、試みられた動作の成功又は失敗の理由を指示するＬＩＳＴＥＮ＿ＲＳＰメッセージを送信する。
【００２２】
ピアと中継装置との間のＬＩＳＴＥＮ＿ＲＥＱ及びＬＩＳＴＥＮ＿ＲＳＰメッセージの交換でサーバー側ソケットがオープンすると、ソケットサーバーは、それに対する接続を受け容れる。所与のピアがリモートピアからの接続を受け容れる準備ができたことを中継装置に指示するために、所与のピアは、ＡＣＣＥＰＴ＿ＲＥＱメッセージを中継装置へ送信する。リモートピアが所与のピアへの接続を確立することが要求されると、中継装置は、ＡＣＣＥＰＴ＿ＲＥＱメッセージにＡＣＣＥＰＴ＿ＲＳＰメッセージで応答する。
【００２３】
良く知られたサーバー側終了点との接続を確立することを希望するソケットのクライアント側は、そこへの接続を試みなければならない。このような接続を達成するために、ピアは、所与の終了点へ接続するためのピアの意図を指示するＣＯＮＮＥＣＴ＿ＲＥＱメッセージを中継装置へ送信する。応答として、中継装置は、試みられた接続の成功又は失敗の理由を指示するＣＯＮＮＥＣＴ＿ＲＳＰメッセージをピアへ送信する。
【００２４】
２つのピア間の接続が確立されると、各ピアが他のピアへデータを送信し、そこからデータを受信することができる。データを送信する動作は、送信すべきデータを有するときにピアにより行なわれる。データは、中継装置へ送られ、中継装置は、それをバッファせずに、確立された接続の他端へ転送する。従って、送信されたデータは、接続の受信端に直ちに配送されねばならない。データを受け取る動作は、確立された接続の各端において常時可能である。送信されたデータが、中継装置にバッファされずに、受信端に配送されることは、リモート通信のためにソケットを使用するアプリケーションがその受信したデータを直ちに消費しなければならないことを意味するものではない。むしろ、受信端におけるコードの役割は、受信したデータを、アプリケーションがそれを読み取るように試みるまでバッファすることである。次いで、受信端におけるアプリケーションは、その到来バッファからデータを検索するローカルオペレーションを遂行しなければならない。このローカルオペレーションは、到来バッファが空である場合には阻止される。
【００２５】
データを受け取るために、ピアは、データを受け取る準備ができたことを指示するＲＥＣＥＩＶＥ＿ＲＥＱメッセージを中継装置へ送信する。データがそのピアへ送信されると、中継装置は、ＲＥＣＥＩＶＥ＿ＲＥＱメッセージにＲＥＣＥＩＶＥ＿ＲＳＰメッセージで応答し、これは、当該ピアへ送信されるデータを含む。他方、ピアが、確立された接続を経て送信すべきデータを有するときには、それをＳＥＮＤ＿ＲＥＱメッセージと共に中継装置へ送信する。このようなメッセージを受信すると、中継装置は、受け取ったデータを意図された受信者へ転送し、そしてＳＥＮＤ＿ＲＳＰメッセージを送信側ピアへ返送する。
【００２６】
ソケットモデルに続いて、ピア間の対話の終りに、全ての確立された接続がクローズされる。更に、聴取側ピアが接続をもはや受け容れないときには、聴取接続をクローズする。これらのハウスキーピングアクションを遂行するために、ピアは、ＣＬＯＳＥ＿ＲＥＱメッセージを中継装置へ送信し、ハウスキーピングアクションの完了の確認としてＣＬＯＳＥ＿ＲＳＰを受け取る。
【００２７】
図１及び２を参照して説明した技術は、多数の効果を有する。例えば、ここに述べる解決策は、既存のインフラストラクチャーに何ら変更を必要とせず、現在のファイアウオールポリシーと矛盾することもない。標準的なＨＴＴＰを使用し且つ厳格なファイアウオールポリシーに従いながら、ピア・ツー・ピア接続を与える。更に、使い易く、開発者は、新たなプロトコルを学習する努力に投資する必要なくＴＣＰ／ＩＰソケットに取って代わるものとしてこの技術を使用することができる。更に、この解決策は、ピアに対する影響が少ない。プロトコルを使用できるようにするためにピアがもつ必要のあるものは、ＡＰＩを実施するミドレットだけである。このＡＰＩコードは、著しい量のコードを表わすものでなく、ピアにおける顕著な実行オーバーヘッドを表わすものでもない。
【００２８】
図１及び２を参照して説明した解決策は、２つのピア間に多数のファイアウオールが配置されるにも関らず、健全なピア・ツー・ピア通信プロトコルを提供する。この解決策の信頼性は、ファイアウオールにより実現されるセキュリティポリシーにおけるホールの効果を取り入れるように試みないことから生じる。又、若干の現在のファイアウオールにより実施されるか又は将来のファイアウオールにより実施されると予想される特殊な特徴に依存するものでもない。むしろ、この解決策は、懇請されたＨＴＴＰトラフィックがファイアウオール保護ネットワーク内のターミナルに到着するのを許す、等の、今日の大半のファイアウオールが従う最小セットのルールで構築される。
【００２９】
ここに述べる解決策は、ＪＸＴＡピア・ツー・ピアソケット（ウェブアドレスhttp://www.codinginparadise.org/p2psockets/l.htmlにおいて入手できる論文“Introduction to Peer-to-Peer Sockets”に説明された）のような既存のピア・ツー・ピアソケット実施形態とは異なる。例えば、ＪＸＴＡ  Ｐ２Ｐソケット解決策は、全ＪＸＴＡインフラストラクチャーが機能することを必要とするが、ここに述べる実施形態の解決策は、ＨＴＴＰ通信しか必要としない。ＪＸＴＡ  Ｐ２Ｐソケットは、ＪＸＴＡフレームワークの部分ではないファイアウオールを回避することができない。ここに示す実施形態は、懇請されたＨＴＴＰトラフィックのみを許すいかなるファイアウオールも回避することができる。
【００３０】
本発明の幾つかの実施形態を説明したが、本発明に関する当業者であれば、変更や修正がなされ得ることが理解されよう。従って、本発明は、特許請求の範囲により正確に限定される。
【図面の簡単な説明】
【００３１】
【図１】一実施形態に基づくピア・ツー・ピアシステムを一般的に示す図である。
【図２】一実施形態に基づく図１のピア・ツー・ピアシステムにおいて２つのピアと中継装置との間の対話のシーケンスを示す図である。
【図１】
2008544386.tif 000003
【図２】
2008544386.tif 000004
【国際調査報告】
2008544386.tif 000005
2008544386.tif 000006
2008544386.tif 000007