(57)【要約】ピアツーピアネットワークにおいてファイアウォールの背後に配置されたピアサーバへのＷｅｂブラウザＨＴＴＰ接続を実行するコンピュータを提供するための方法及びシステムについて述べる。本方法及びシステムには、まず、ピアツーピアネットワークにプロキシサーバを提供する段階が含まれる。次に、ピアサーバは、プロキシサーバにアウトバウンドソケット接続を登録する。ピアサーバへアクセスせよというＨＴＴＰ要求をプロキシサーバがｗｅｂブラウザから受信するのに応じて、ＨＴＴＰ要求は、要求パケットに変換され、要求パケットは、ピアサーバに送信される。ピアサーバが要求パケットを受信するのに応じて、ピアサーバは、要求パケットを変換してＨＴＴＰ要求に戻し、次に、要求に応答し、これによって全般的なｗｅｂトラフィックが流れるようにする。【特許請求の範囲】
【請求項１】
ピアツーピアネットワークにおいてファイアウォールの背後に配置されたピアサーバへのＨＴＴＰ接続をコンピュータ上で走るＷｅｂブラウザに提供するための方法であって、
（ａ）前記ピアツーピアネットワークにプロキシサーバを提供する段階と、
（ｂ）前記ピアサーバによって前記プロキシサーバにアウトバウンドソケット接続を登録する段階と、
（ｃ）前記ピアサーバにアクセスせよというＨＴＴＰ要求を前記プロキシサーバが前記Ｗｅｂブラウザから受信するのに応じて、前記ＨＴＴＰ要求を要求パケットに変換し、前記要求パケットを前記ピアサーバに送る段階と、
（ｄ）前記ピアサーバが前記要求パケットを受信するのに応じて、前記要求パケットを変換して前記ＨＴＴＰ要求に戻し、前記要求に応答し、これによって全般的なｗｅｂトラフィックが流れるようにする段階と、
が含まれる方法。
【請求項２】
請求項１に記載の方法であって、前記ピアサーバには、更に、Ｗｅｂサーバが含まれ、段階（ｄ）には、更に、
（ｉ）前記ＨＴＴＰ要求を前記Ｗｅｂサーバに渡すことによって要求に応答する段階と、
（ｉｉ）ＷｅｂサーバからＨＴＴＰ応答を受信する段階と、
（ｉｉｉ）ＨＴＴＰ応答を応答パケットに変換する段階と、
（ｉｖ）前記アウトバウンドソケット接続上で、ピアサーバそして前記プロキシサーバに前記応答パケットを送る段階と、
（ｖ）前記応答パケットを前記プロキシサーバ上で受信し、応答パケットを変換して前記ＨＴＴＰ応答に戻す段階と、
（ｖｉ）前記ピアサーバから前記Ｗｅｂブラウザに前記ＨＴＴＰ応答を送る段階と、
が含まれる方法。
【請求項３】
請求項２に記載の方法であって、前記ピアツーピアネットワークには、多数のピアサーバが含まれ、また、前記プロキシサーバは、前記ピアサーバとは独立し分離している方法。
【請求項４】
請求項３に記載の方法であって、更に、前記各ピアサーバにピアノード、Ｗｅｂサーバ、及びＷｅｂブラウザを提供する段階が含まれる方法。
【請求項５】
請求項４に記載の方法であって、更に、前記ピアツーピアネットワークに登録サーバ及びＤＮＳサーバを提供する段階が含まれる方法。
【請求項６】
請求項５に記載の方法であって、段階（ｂ）には、更に、前記ピアサーバの名前を前記ピアサーバから前記登録サーバに渡し、それが割り当てられた前記プロキシサーバの名前及びＩＰアドレスを受信する段階が含まれる方法。
【請求項７】
請求項６に記載の方法であって、段階（ｂ）には、更に、前記ピアサーバによって、前記プロキシサーバの名前及び前記プロキシサーバのＩＰアドレスを前記ＤＮＳサーバに登録する段階が含まれる方法。
【請求項８】
請求項７に記載の方法であって、段階（ｂ）には、更に、前記ピアサーバが前記プロキシサーバに登録した後、コンテンツが前記ピアサーバ上に閲覧用に存在することを、電子メールを介して、前記コンピュータのユーザに通知し、前記電子メールに前記ピアサーバのＵＲＬを含める段階が含まれる方法。
【請求項９】
請求項８に記載の方法であって、段階（ｂ）には、更に、前記ユーザが前記ＵＲＬ電子メールをクリックするのに応じて、前記コンピュータは、前記ＤＮＳサーバと接触して、前記ＨＴＴＰ要求を送信するプロキシサーバを識別する段階が含まれる方法。
【請求項１０】
請求項３に記載の方法であって、更に、サーブレットスレッド、登録マネージャ、ピアマネージャ、ピアメッセージボックス、及びピア・パケット・マネージャ・スレッドを前記プロキシサーバに提供する段階が含まれる方法。
【請求項１１】
請求項１０に記載の方法であって、段階（ｃ）には、更に、前記サーブレットスレッドによって前記ＨＴＴＰ要求をＵＲＬとして受信し、前記登録マネージャを用いて、要求側ＵＲＬにおいて特定されたピアサーバが前記ピアサーバに登録されているかどうか判断し、そうであれば、前記対応するピアソケットを返す段階が含まれる方法。
【請求項１２】
請求項１１に記載の方法であって、段階（ｃ）には、更に、前記サーブレットスレッドによってピア要求パケットを生成し、前記ピア要求パケットを前記ピアマネージャに渡す段階が含まれる方法。
【請求項１３】
請求項１２に記載の方法であって、段階（ｃ）には、更に、メッセージボックスＩＤ、ＨＴＴＰ＿ＵＲＬ、ＨＴＴＰヘッダ、及びＨＴＴＰポストデータフィールドを前記ピア要求パケットに提供する段階が含まれる方法。
【請求項１４】
請求項１３に記載の方法であって、段階（ｃ）には、更に、前記ピアマネージャによって、前記ピアサーバへの前記ソケット接続を見つけ、前記ピア要求パケットを前記ピアサーバに渡す段階が含まれる方法。
【請求項１５】
請求項２に記載の方法であって、段階（ｄ）には、更に、前記ＨＴＴＰ応答をチャンクに分割し、連続的ピア応答パケットで前記チャンクを前記プロキシサーバに送信する段階が含まれる方法。
【請求項１６】
請求項１５に記載の方法であって、段階（ｄ）には、更に、前記プロキシサーバからのＨＴＴＰ要求を処理するための幾つかのスレッドを前記ピアサーバに提供し、それらの要求に対する応答を同じ応答ソケット上で前記プロキシサーバに多重伝送する段階が含まれる方法。
【請求項１７】
ピアツーピアネットワークにおいてファイアウォールの背後に配置されたピアサーバへのＨＴＴＰ接続をコンピュータ上で走るＷｅｂブラウザに提供するためのプログラム命令を含むコンピュータ判読可能媒体であって、前記プログラム命令は、
（ａ）前記ピアツーピアネットワークにプロキシサーバを提供し、
（ｂ）前記ピアサーバによって前記プロキシサーバにアウトバウンドソケット接続を登録し、
（ｃ）前記ピアサーバにアクセスせよというＨＴＴＰ要求を前記プロキシサーバが前記Ｗｅｂブラウザから受信するのに応じて、前記ＨＴＴＰ要求を要求パケットに変換し、前記要求パケットを前記ピアサーバに送り、
（ｄ）前記ピアサーバが前記要求パケットを受信するのに応じて、前記要求パケットを変換して前記ＨＴＴＰ要求に戻し、前記要求に応答し、これによって全般的なｗｅｂトラフィックが流れるようにする、
ためのものであるコンピュータ判読可能媒体。
【請求項１８】
請求項１７に記載のコンピュータ判読可能媒体であって、前記ピアサーバには、更に、Ｗｅｂサーバが含まれ、命令（ｄ）には、更に、
（ｉ）前記ＨＴＴＰ要求を前記Ｗｅｂサーバに渡すことによって要求に応答し、
（ｉｉ）ＷｅｂサーバからＨＴＴＰ応答を受信し、
（ｉｉｉ）ＨＴＴＰ応答を応答パケットに変換し、
（ｉｖ）前記アウトバウンドソケット接続上で、ピアサーバそして前記プロキシサーバに前記応答パケットを送り、
（ｖ）前記応答パケットを前記プロキシサーバ上で受信し、応答パケットを変換して前記ＨＴＴＰ応答に戻し、
（ｖｉ）前記ピアサーバから前記Ｗｅｂブラウザに前記ＨＴＴＰ応答を送る、
命令が含まれるコンピュータ判読可能媒体。
【請求項１９】
請求項１８に記載のコンピュータ判読可能媒体であって、前記ピアツーピアネットワークには、多数のピアサーバが含まれ、また、前記プロキシサーバは、前記ピアサーバとは独立し分離しているコンピュータ判読可能媒体。
【請求項２０】
請求項１９に記載のコンピュータ判読可能媒体であって、更に、前記各ピアサーバにピアノード、Ｗｅｂサーバ、及びＷｅｂブラウザを提供する命令が含まれるコンピュータ判読可能媒体。
【請求項２１】
請求項２０に記載のコンピュータ判読可能媒体であって、更に、前記ピアツーピアネットワークに登録サーバ及びＤＮＳサーバを提供する命令が含まれるコンピュータ判読可能媒体。
【請求項２２】
請求項２１に記載のコンピュータ判読可能媒体であって、命令（ｂ）には、更に、前記ピアサーバの名前を前記ピアサーバから前記登録サーバに渡し、それが割り当てられた前記プロキシサーバの名前及びＩＰアドレスを受信する命令が含まれるコンピュータ判読可能媒体。
【請求項２３】
請求項２２に記載のコンピュータ判読可能媒体であって、命令（ｂ）には、更に、前記ピアサーバによって、前記プロキシサーバの前記名前及び前記プロキシサーバの前記ＩＰアドレスを前記ＤＮＳサーバに登録する命令が含まれるコンピュータ判読可能媒体。
【請求項２４】
請求項２３に記載のコンピュータ判読可能媒体であって、命令（ｂ）には、更に、前記ピアサーバが前記プロキシサーバに登録した後、コンテンツが前記ピアサーバ上に閲覧用に存在することを、電子メールを介して、前記コンピュータのユーザに通知し、前記電子メールに前記ピアサーバのＵＲＬを含める命令が含まれるコンピュータ判読可能媒体。
【請求項２５】
請求項２４に記載のコンピュータ判読可能媒体であって、命令（ｂ）には、更に、前記ユーザが前記ＵＲＬ電子メールをクリックするのに応じて、前記コンピュータは、前記ＤＮＳサーバと接触して、前記ＨＴＴＰ要求を送信する前記プロキシサーバの識別を決定する命令が含まれるコンピュータ判読可能媒体。
【請求項２６】
請求項１９に記載のコンピュータ判読可能媒体であって、更に、サーブレットスレッド、登録マネージャ、ピアマネージャ、ピアメッセージボックス、及びピア・パケット・マネージャ・スレッドを前記プロキシサーバに提供する命令が含まれるコンピュータ判読可能媒体。
【請求項２７】
請求項２６に記載のコンピュータ判読可能媒体であって、命令（ｃ）には、更に、前記サーブレットスレッドによって前記ＨＴＴＰ要求をＵＲＬとして受信し、前記登録マネージャを用いて、要求側ＵＲＬにおいて特定された前記ピアサーバが前記ピアサーバに登録されているかどうか判断し、そうであれば、前記対応するピアソケットを返す命令が含まれ
るコンピュータ判読可能媒体。
【請求項２８】
請求項２７に記載のコンピュータ判読可能媒体であって、命令（ｃ）には、更に、前記サーブレットスレッドによってピア要求パケットを生成し、前記ピア要求パケットを前記ピアマネージャに渡す命令が含まれるコンピュータ判読可能媒体。
【請求項２９】
請求項２８に記載のコンピュータ判読可能媒体であって、命令（ｃ）には、更に、メッセージボックスＩＤ、ＨＴＴＰ＿ＵＲＬ、ＨＴＴＰヘッダ、及びＨＴＴＰポストデータフィールドを前記ピア要求パケットに提供する命令が含まれるコンピュータ判読可能媒体。
【請求項３０】
請求項２９に記載のコンピュータ判読可能媒体であって、命令（ｃ）には、更に、前記ピアマネージャによって、前記ピアサーバへの前記ソケット接続を見つけ、前記ピア要求パケットを前記ピアサーバに渡す命令が含まれるコンピュータ判読可能媒体。
【請求項３１】
請求項１８に記載のコンピュータ判読可能媒体であって、命令（ｄ）には、更に、前記ＨＴＴＰ応答をチャンクに分割し、連続的ピア応答パケットで前記チャンクを前記プロキシサーバに送信する命令が含まれるコンピュータ判読可能媒体。
【請求項３２】
請求項３１に記載のコンピュータ判読可能媒体であって、命令（ｄ）には、更に、前記プロキシサーバからのＨＴＴＰ要求を処理するための幾つかのスレッドを前記ピアサーバに提供し、それらの要求に対する応答を同じ応答ソケット上で前記プロキシサーバに多重伝送する命令が含まれるコンピュータ判読可能媒体。
【請求項３３】
ピアツーピアネットワークにおいてファイアウォールの背後に配置されたピアサーバへのＨＴＴＰ接続をＷｅｂブラウザに提供するための方法であって、
（ａ）前記ピアサーバからプロキシサーバへのアウトバウンドソケット接続を登録する段階と、
（ｂ）前記ピアサーバに向けられた全着信ＨＴＴＰ要求を前記プロキシサーバに転送する段階と、
（ｃ）前記転送されたＨＴＴＰ要求の内の１つを前記プロキシサーバが受信するのに応じて、前記ピアサーバへの前記ソケット接続を見つけ、前記ＨＴＴＰ要求を要求パケットが含まれる多重化プロトコルに変換し、前記要求パケットを前記ピアサーバに送信する段階と、
（ｄ）前記ピアノードが前記要求パケットを受信するのに応じて、前記要求を多重分離し、前記要求パケットを変換して前記元のＨＴＴＰ要求に戻し、前記ＨＴＴＰ要求をローカルｗｅｂサーバに渡す段階と、
（ｅ）前記ピアノードが前記ＷｅｂサーバからＨＴＴＰ応答を受信するのに応じて、前記ＨＴＴＰ応答を応答パケットに変換し、前記アウトバウンドソケット接続上で前記応答パケットを前記プロキシサーバに送信する段階と、
（ｆ）前記プロキシサーバが前記ピアサーバから前記応答パケットを受信するのに応じて、前記応答パケットを変換して前記ＨＴＴＰ応答に戻し、前記ＨＴＴＰ応答を前記要求側Ｗｅｂブラウザに送信する段階と、
が含まれる方法。
【請求項３４】
ピアツーピアネットワークにおいてファイアウォールの背後に配置されたピアサーバへのＨＴＴＰ接続をＷｅｂブラウザに提供するためのプログラム命令を含むコンピュータ判読可能媒体であって、前記プログラム命令は、
（ａ）前記ピアサーバからプロキシサーバへのアウトバウンドソケット接続を登録し、
（ｂ）前記ピアサーバに向けられた全着信ＨＴＴＰ要求を前記プロキシサーバに転送し、
（ｃ）前記転送されたＨＴＴＰ要求の内の１つを前記プロキシサーバが受信するのに応じて、前記ピアサーバへの前記ソケット接続を見つけ、前記ＨＴＴＰ要求を要求パケットが含まれる多重化プロトコルに変換し、前記要求パケットを前記ピアサーバに送信し、
（ｄ）前記ピアノードが前記要求パケットを受信するのに応じて、前記要求を多重分離し、前記要求パケットを変換して前記元のＨＴＴＰ要求に戻し、前記ＨＴＴＰ要求をローカルｗｅｂサーバに渡し、
（ｅ）前記ピアノードが前記ＷｅｂサーバからＨＴＴＰ応答を受信するのに応じて、前記ＨＴＴＰ応答を応答パケットに変換し、前記アウトバウンドソケット接続上で前記応答パケットを前記プロキシサーバに送信し、
（ｆ）前記プロキシサーバが前記ピアサーバから前記応答パケットを受信するのに応じて、前記応答パケットを変換して前記ＨＴＴＰ応答に戻し、前記ＨＴＴＰ応答を前記要求側Ｗｅｂブラウザに送信する、
ためのものであるコンピュータ判読可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ピアツーピアオンライン写真共有に関し、特に、ピアツーピアネットワーク内においてファイアウォールを介してＷｅｂブラウジングを提供するための方法及びシステムに関する。
【背景技術】
【０００２】
オンライン写真共有からの最も一般的なアプローチ手法は、集中演算処理に基づくサービス提供アーキテクチャであるが、この場合、中央サーバは、ユーザに対して、インターネット上の固定位置から彼らのｗｅｂブラウザに画像を提供することによって写真共有サービスを提供する。図１は、ｗｅｂブラウザ１６を介して、Ｗｅｂサーバ１４に接続するクライアント１２が含まれる従来のサーバアーキテクチャ１０を示す図である。Ｗｅｂブラウザ１６とＷｅｂサーバ１４との間の通信は、ハイパーテキスト・トランスポート・プロトコル（ＨＴＴＰ）に基づく。ＨＴＴＰの機能は、Ｗｅｂブラウザ１６とＷｅｂサーバ１４との間の接続を確立することであり、また、Ｗｅｂサーバ１４からのＨＴＭＬページをクライアントブラウザ１６に、又はＨＴＴＰアプリケーションによって要求されるいずれか他のファイルに送信することである。
【０００３】
ＨＴＴＰは、要求／応答システムである。接続は、直近の要求に対してのみクライアント１２とサーバ１４との間で維持される。伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）を用いて、Ｗｅｂブラウザ１６は、まず、サーバ１４とのＴＣＰ接続を確立し、次に、ＨＴＴＰ要求命令１８をＷｅｂサーバ１４に送信する。Ｗｅｂサーバ１４は、ヘッダ（メッセージ）及びファイル（ＨＴＭＬページ、Ｊａｖａ（登録商標）アプレット等）の形態でＴＣＰ／ＩＰパケット２０を送り返すことによって応答し、そして接続を閉じる。公知のように、ＴＣＰ／ＩＰは、ルーティング可能なプロトコルであり、この場合、全てのメッセージが、宛先局のアドレスばかりでなく宛先ネットワークのアドレスも含む。ＴＣＰ／ＩＰネットワークにおける各クライアント１２及びサーバ１４には、ＩＰアドレスが必要であるが、これは、恒久的に割り当てられるか、あるいは、起動時、動的に割り当てられる。
【０００４】
この解決策は、多くの写真共有の状況に対してある程度機能するが、不利な点は、Ｗｅｂサーバ１４がファイアウォールの背後に配置されている場合、この解決策は機能しないことである。同様な問題が、新しいピアツーピア（Ｐ２Ｐ）写真共有アプリケーションに存在するが、このアプリケーションでは、Ｐ２Ｐネットワークの各コンピュータ／ピアは、サーバとしての役割を果たしてネットワーク中の他のものと写真を共有し、ユーザは自分の写真をＷｅｂサイトにアップロードする必要がない。そのようなＰ２Ｐアプリケーションの一例は、マサチューセッツ州ニーダムにあるＸＦｏｒｍｘ社製のＰｈｏｔｏ＿Ｖｉｂｅ＿１．２である。しかしながら、問題は、全てのコンピュータが固定ＩＰアドレスを有するとは限らないことであり（世界的な不足による）、また、ピアは、保護されていないシステムに対するインターネットの敵対的性質のために、ファイアウォールの背後に常駐することが多いことである。従って、課題は、コンピュータが動的ＩＰを用いており、また、家庭又は会社のＬＡＮ上のファイアウォールの背後に常駐している時、如何にしてこれらのコンピュータに標準のＨＴＴＰを用いてアクセスするかということにある。
【０００５】
１つの解決策は、ピアツーピア構成における全てのコンピュータに固定アドレスを割当て、そして、ファイアウォールの背後にあるあらゆるピアにファイアウォールのポートを開かせて、着信インターネットトラフィックを受け入れさせることである。この解決策は
、技術的見地からは良好に機能するが、ネットワーク構成に余分な手順が必要であり、また、ユーザのネットワークに潜在的なセキュリティ欠陥が生じる。この解決策は、多くのインターネットゲーム並びにＰｈｏｔｏ＿Ｖｉｂｅ＿１．２等のピアツーピア写真共有ソフトウェアソリューションによって用いられる。この構成は、一般的なＨＴＴＰ／Ｗｅｂブラウザ環境をサポートするが、この解決策の不利な点は、ユーザが自分のファイアウォールに穴を開けて、ピアコンピュータに静的ＩＰアドレスを割り当てるか、又は、動的ＤＮＳサービス（ｗｗｗ．ｎｏ−ｉｐ．ｃｏｍ等）を用いて、変化するアドレスを追跡する必要があるということである。
【０００６】
従って、必要とされるものは、幾つかのピアがファイアウォールの背後に配置されている場合でも、他のコンピュータから写真共有Ｐ２Ｐネットワークの各ピアへのＨＴＴＰ接続を提供するための方法システムである。本発明は、そのようなニーズに対処する。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、ピアツーピアネットワークにおいてファイアウォールの背後に配置されたピアサーバへのＷｅｂブラウザＨＴＴＰ接続を実行するコンピュータを提供するための方法及びシステムを提供する。
【課題を解決するための手段】
【０００８】
本方法及びシステムには、まず、ピアツーピアネットワークにプロキシサーバを提供する段階が含まれる。次に、ピアサーバは、プロキシサーバにアウトバウンドソケット接続を登録する。ピアサーバにアクセスせよというＨＴＴＰ要求をプロキシサーバがｗｅｂブラウザから受信するのに応じて、ＨＴＴＰ要求が要求パケットに変換され、要求パケットがピアサーバに送られる。ピアサーバが要求パケットを受信するのに応じて、ピアサーバは、要求パケットを変換してＨＴＴＰ要求に戻し、次に、要求に応答し、これによって全般的なｗｅｂトラフィックが流れるようにする。
【０００９】
本明細書に開示する方法及びシステムによれば、本発明は、訪問者とファイアウォールの背後で走るピアとの間における全般的なｗｅｂブラウジングをサポートし、如何なるネットワーク構成も不要であり、また、着信接続のためにファイアウォールにポートを開く必要がない。
【発明を実施するための最良の形態】
【００１０】
本発明は、ピアツーピアネットワークにおいて、セキュリティ保護されたＷｅｂブラウジングを提供するための方法に関する。以下の説明は、当業者が本発明を実現し用いるために提示し、また、特許出願及びその要求事項という文脈で提供する。好適な実施形態に対する様々な修正並びに本明細書に述べる全般的な原理及び特徴は、当業者には容易に明らかであろう。従って、本発明は、例示した実施形態に限定することを意図するものではなく、本明細書に述べる原理及び特徴と合致する最も広い範囲に適合するものである。
【００１１】
本発明は、中央プロキシサーバを組み込んでファイアウォールの背後にあるピアに対するネットワーキングトラフィックを連係して働かせる一般的なＨＴＴＰ／ｗｅｂブラウザ構成にハイブリッド・ピアツーピア・アーキテクチャを提供し、こうしてファイアウォールの背後にあるピアへの他のピアによる、また、ネットワークにない訪問コンピュータによるアクセスを可能にする。
【００１２】
図２は、本発明のハイブリッド・ピアツーピア・アーキテクチャを示す図である。ハイブリッド・ピアツーピア・アーキテクチャ２０には、写真共有Ｐ２Ｐネットワーク２２が含まれ、これには、ピア・ノード・ソフトウェア２６及びＷｅｂサーバソフトウェア２８
を走らせる多数のピアサーバ２４が含まれる。本発明の好適な実施形態において、ピアノード及びサーバソフトウェア２４及び２６により、コンピュータのユーザは、Ｗｅｂブラウザ３０を介してネットワークの他者と写真を共有することが可能であり、自分の写真をＷｅｂサイトにアップロードする必要がない。訪問コンピュータ３２、即ち、ピアツーピアネットワーク２２に属していないコンピュータもまたピアサーバ２４からの画像にＷｅｂブラウザ３０を介してアクセスする。本明細書で用いるように、ピアサーバ２４及び訪問コンピュータ３２には、例えば、ＰＣ、ワークステーション、携帯電話、及びＰＤＡ等、適切なソフトウェアを実行するために必要な構成要素を備えた何らかの演算処理装置を含み得る。また、好適な実施形態において、物理的な通信ネットワークは、インターネットであるが、あらゆる種類のネットワークを用い得る。
【００１３】
図示したように、Ｐ２Ｐネットワーク２２内にある幾つかのピアサーバ２４’は、ファイアウォール３４の背後に配置されるが、ファイアウォール３４は、他のピアサーバ２４及び訪問コンピュータ３２からの従来のＨＴＴＰ要求をブロックする。本発明によると、ハイブリッド・ピアツーピア・アーキテクチャ２０によって、訪問コンピュータ３２又は他のピアサーバ２４など他のコンピュータ上で走るｗｅｂブラウザ３０は、ピアサーバ２４’へのＨＴＴＰ接続が可能になる。本明細書で用いるＨＴＴＰ接続とは、以下のアクティビティ、即ち、ｗｅｂページのブラウジング、ファイルダウンロード、トランザクションの実行を意味する。
【００１４】
一般的なＨＴＴＰ接続は、ピアサーバ２４から独立し分離されネットワーク２２を構成する少なくとも１つのプロキシサーバ３６をＰ２Ｐネットワーク２２に提供することによって、そして、ファイアウォール保護されたピアサーバ２４’からのプロキシサーバ３６とのアウトバウンド接続を確立することで、ファイアウォール保護されたピアサーバ２４’のユーザとイネーブル着信ｗｅｂトラフィックとの接続を可能にすることによって、達成される。こうして、ファイアウォール保護されたピアサーバ２４’への着信Ｗｅｂトラフィックは、プロキシサーバ３６に向けられる。プロキシサーバ３６は、ピアサーバ２４’に自社開発のプロトコルを用いてＷｅｂトラフィックを多重伝送し、こうしてファイアウォール３４が存在するにもかかわらず、全般的なｗｅｂトラフィックがピアサーバ２４’に流れるようになる。多数のファイアウォール保護されたピアサーバ２４’がある場合、プロキシサーバ３６は、交換機としての役割を果たし、着信ＨＴＴＰ要求を受信し適切なピアサーバ２４’に送出する。
【００１５】
図３は、ファイアウォール３４の背後にあるピアサーバ２４’へのＷｅｂブラウザ３０によるアクセスを可能にするためのプロセスを示すフロー図である。プロセスは、ステップ５０において始まり、ピアサーバ２４は、アウトバウンドソケット接続をプロキシサーバ３６に登録する。ステップ５２において、ピアサーバ２４’に向けられた全ての着信ＨＴＴＰ要求が、プロキシサーバ３６に転送される。ステップ５４において、転送されたＨＴＴＰ要求の受信に応じて、プロキシサーバ３６は、ピアサーバ２４’へのソケット接続を見つけ、ＨＴＴＰ要求を要求パケットが含まれる多重化プロトコルに変換し、その要求パケットをピアサーバ２４’に送る。ステップ５６において、ピアノード２６は、要求パケットを受信し、要求パケットを多重分離し、要求パケットを変換して元のＨＴＴＰ要求に戻し、ＨＴＴＰ要求をローカルＷｅｂサーバ２８に渡す。ステップ５８において、ピアノード２６は、Ｗｅｂサーバ２８からＨＴＴＰ応答を受信し、ＨＴＴＰ応答を応答パケットに変換し、アウトバウンドソケット接続上でプロキシサーバ３６に応答パケットを送る。ステップ６０において、プロキシサーバ３６は、ピアサーバ２４’から応答パケットを受信し、応答パケットをＨＴＴＰ応答に変換して戻し、ＨＴＴＰ応答を要求側ｗｅｂブラウザ３０に送る。
【００１６】
本発明は、どのようなネットワーク構成も必要とせずに、訪問者とファイアウォールの
背後で走るピアとの間における全般的なｗｅｂブラウジングをサポートするという点において、従来の手法に対して改善された解決策である。このことは、プロキシとサービス提供側マシンとの間の方向が反転されているという点において、（当業者には公知の）普通のＨＴＴＰプロキシとは異なる。これによって状況は複雑化するが、これは、ＨＴＴＰ要求の最後は、サービス提供側エンティティによりソケット接続を閉じることによって伝えられるべきであることをＨＴＴＰプロトコルが規定しているためである。本発明では、その接続は、開いたままであるが、これは、ピアサーバ２４’をアドレス指定可能にしているのがその接続であることによる。この問題は、常にピアから中央プロキシサーバ３６への接続を開いたままにすることによって解決されてきている。プロキシサーバ３６は、この開いた接続を制御ソケットとして用いる。これは、訪問ブラウザ３０からＨＴＴＰ要求を受信し、それら要求を命令に変え、ｗｅｂサービス提供を行うピアサーバ２４’にそれらを送信する。ｗｅｂサービス提供を行うピアサーバ２４’は、命令を受信するデーモンを走らせ、そのローカルｗｅｂサーバ２８に命令を供給する。そして、ＨＴＴＰ応答を取り上げて、アウトバウンド接続を開いてデータを送ることによって、それら応答をピアサーバ２４’に送り、次にパケット終端メッセージを送り、ピア応答パケットの完了を告げる。
【００１７】
更に、本発明により、ピアサーバ２４’が既知のＩＰアドレスを有する必要性がなくなる。ピアサーバ２４’は、プロキシサーバ３６に接続することから、プロキシサーバ３６は、システム２０が動作するためにピアサーバ２４’のアドレスを知る必要がない。これは、ピアサーバ２４’が１つのネットワークから他のネットワークに移動し得るため、モバイル設定における利点である。このことは、通常のインターネットサービスプロバイダＩＳＰは、ＤＨＣＰを用いてＩＰアドレスを動的に変更することから、消費者設定において重要である。
【００１８】
本発明の他の利点は、これによって企業設定のユーザがシステムを用い得ることである。このことは、着信接続に対してファイアウォールにポートを開く必要がないことから有用である。このことは、それらの環境におけるセキュリティ標準が極めて高いため、企業ユーザにとって重要である。彼らは、自らのファイアウォールに穴を開けようと考えることは、あるにしても極めてまれである。
【００１９】
図４は、ピアサーバ２４’が写真共有ピアツーピアネットワーク２２に登録して、ファイアウォール３４を介してそのサービス提供機能を評価可能にするプロセスを示すフロー図である。好適な実施形態において、Ｐ２Ｐネットワーク２２には、プロキシサーバアレイ３６と総称される幾つかのプロキシサーバ３６ａ−ｎと、ピアサーバテーブル７０、登録サーバ７２、及びＤＮＳサーバ７４が含まれる。
【００２０】
登録プロセスは、ステップ１００において始まり、ここで、ピアノード２６は、その名前を登録サーバ７２に渡し、登録サーバ７２は、チェックを行い、ピア名が固有であることを確認し、それが割り当てられたプロキシサーバ３６の名前及びＩＰアドレスをピアノード２６に返す。ステップ１０２において、ピアノード２６は、そのプロキシサーバ名及びプロキシサーバＩＰアドレスをＤＮＳサーバ７４に登録する。ＤＮＳサーバ７４は、全てのピア名及びそれらの対応するプロキシＩＰアドレスのテーブルを維持する。ステップ１０４において、ピアノード２６は、それが割り当てられたプロキシサーバ３６に対して、ピアサーバの名前及びソケットを登録する。
【００２１】
ステップ１０６において、訪問コンピュータ３２のユーザは、閲覧用のコンテンツ（例えば、写真）がピアサーバ２４’に存在することを通知される。この通知は、幾つかの方法を用いて実現し得るが、好適な実施形態において、ユーザは、電子メールを介して通知され、電子メールには、ピアサーバ２４’におけるコンテンツのＵＲＬが含まれる。ステ
ップ１０８において、訪問コンピュータ３２のユーザは、電子メールを受信し、ＵＲＬをクリックする。ＵＲＬにおいて、ピア名を用いて、訪問コンピュータ３２は、ＤＮＳサーバ７４と接触し、その要求を送るべきプロキシサーバ３６の識別を決定する。ＤＮＳサーバ７４は、ピアサーバ２４’に割り当てられたプロキシサーバ３６のＩＰアドレスで応答する。プロキシＩＰアドレスが与えられると、訪問コンピュータ３２のｗｅｂブラウザ３０は、ステップ１１０において、ＨＴＴＰ要求をプロキシサーバ３６に送る。
【００２２】
図５は、プロキシサーバ３６の構成要素と、プロキシサーバ３６を介してｗｅｂブラウザ３０がピアサーバ２４’にＨＴＴＰ接続できるようにするための要求側ｗｅｂブラウザ３０、プロキシサーバ３６、及びピアサーバ２４’間におけるフローと、を示す図である。好適な実施形態において、プロキシサーバ３６には、多重サーブレットスレッド１５０、登録マネージャ１５２、ピアマネージャ１５４、ピアメッセージボックス１５６、及びピア・パケット・マネージャ・スレッド１５８が含まれる。
【００２３】
プロセスは、ステップ２００において始まり、ここで、プロキシサーバ３６のサーブレットスレッド１５０が、ｗｅｂブラウザ３０からＵＲＬの形態でＨＴＴＰ要求を受信する。ステップ２０２において、登録マネージャ１５２は、サーバテーブル７０（図４参照）をチェックして、要求側ＵＲＬにおいて特定されたピアサーバがピアサーバ２４’に登録されているかどうか判断し、そうであれば、対応するピアソケットを返す。ステップ２０４において、サーブレットスレッド１５０は、ＨＴＴＰ要求からピア要求パケット１６０を生成し、そして、そのパケットをピアマネージャ１５４に渡す。
【００２４】
図６Ａは、ピア要求パケット１６０のコンテンツを示す図である。好適な実施形態において、ピア要求パケット１６０には、メッセージボックスＩＤ１６２、ＨＴＴＰ＿ＵＲＬ１６４、多数のＨＴＴＰヘッダ１６６、及びＨＴＴＰポストデータフィールド１６８が含まれる。メッセージボックスＩＤ１６２は、ピア要求パケット１６２、ピア応答パケット１７０、及びピアメッセージボックス１５６を相互に関連付けるための固有の識別子である。ＨＴＴＰ＿ＵＲＬ１６４は、訪問ｗｅｂブラウザ３０から要求されたＵＲＬである。ＨＴＴＰヘッダ１６６は、訪問ｗｅｂブラウザ３０からの元の要求のＨＴＴＰヘッダである。ＨＴＴＰポストデータフィールド１６８は、要求がＰＯＳＴ命令であってＧＥＴ命令ではない場合のデータを含む。
【００２５】
図５に戻ると、ステップ２０６において、ピアマネージャ１５４は、ピアサーバ２４’へのソケット接続を見つけ、ピア要求パケット１６０をピアサーバ２４’に渡す。ステップ２１０において、サーブレットスレッド１５０は、ピアマネージャ１５４からピアメッセージボックス１５６を得て閉鎖し、応答パケットがピアメッセージボックス１５６に到着するのを待つ。
【００２６】
ステップ２１２において、ピアノード２６は、要求パケット１６０を受信し、パケット１６０を変換してＨＴＴＰ要求に戻し、ｗｅｂサーバ２８にＨＴＴＰ要求を送る。ステップ２１４において、ＨＴＴＰ応答は、ｗｅｂサーバ２８からピアノード２６に送られ、そして、これは、応答からＨＴＴＰヘッダを取り上げて、ピア応答パケット１７０を生成し、それをプロキシサーバ３６に送り返す。ＨＴＴＰ応答の残りの部分は、ステップ２１６において２Ｋチャンクに分割され、連続ピア応答パケット１７０でプロキシサーバ３６に送られる。好適な実施形態において、ピアノード２６は、各ピア応答パケット１７０のルーティングアドレスを挿入する。プロキシサーバ３６からの要求を扱う幾つかのスレッドがあり得ることに留意されたい。従って、ピアノード２６は、同じ応答ソケット上でそれらの応答を多重伝送しプロキシサーバ３６に戻す。
【００２７】
図６Ｂは、ピア応答パケット１７０のコンテンツを示す図である。好適な実施形態にお
いて、ピア応答パケット１７０には、メッセージボックスＩＤ１７２、パケットサイズ１７４、パケットタイプ１７６、及びペイロードフィールド１７８が含まれる。メッセージボックスＩＤ１７２は、ピア要求パケット１６２、ピア応答パケット１７０、及びピアメッセージボックス１５６を相互に関連付けるための固有の識別子である。パケットサイズ１７４は、ピア要求パケット１６０に対する応答がチャンクでプロキシサーバ３６に送り返されることと関わりがある。２Ｋのパケットサイズが、好適な本実施形態に用いられる。個々のパケットは、プロキシサーバ３６上で組み立て直されて完全なＨＴＴＰ応答になり、そして、これが訪問ｗｅｂブラウザ３０に返される。パケットタイプ１７６は、ペイロードフィールド１７８で返されるデータのタイプを示す。可能な値には、［データ、ヘッダ、最終パケット］が含まれる。ペイロードフィールド１７８は、ピア応答パケット１７０のデータ部である。
【００２８】
図５に戻ると、ステップ２１８において、プロキシサーバ３６は、応答ソケット上で生のバイトを受信し、スレッドプールから選択されるピア・パケット・マネージャ１５８スレッドにそれらを渡す。好適な実施形態では、プロキシサーバ３６において、ピア当り１つのピア・パケット・マネージャ・スレッドだけが要求１５８、１７０を受信している。ステップ２２０において、ピア・パケット・マネージャ・スレッド１５８は、そのバッファに完全なパケットができるまで待ち、そして、完全なピア応答パケット１７０を対応するピアメッセージボックス１５６に回す。パケット１７０が、ピアメッセージボックス１５６に到着すると、対応するサーブレットスレッド１５０が活性化し完全なピア応答パケット１７０を取り込む。ステップ２４２において、サーブレットスレッド１５０は、ピア応答パケット１７０を変換してＨＴＴＰ応答に戻し、そして、ＨＴＴＰ応答を要求側ｗｅｂブラウザ３０に送り返す。本明細書に開示するように、プロキシサーバ３６とピアノード２６との組合せにより、訪問ｗｅｂブラウザ３０によるファイアウォール３４の背後に配置されたピアサーバ２４’へのＨＴＴＰ接続が可能になる。
【００２９】
本発明について、例示した実施形態に基づき説明したが、当業者は、実施形態に対する変形が存在し得ること、また、どのような変形も本発明の精神及び範囲内にあることを容易に認識されるであろう。従って、多くの修正が、添付された請求項の精神及び範囲から逸脱することなく、当業者によって行い得る。
【図面の簡単な説明】
【００３０】
【図１】従来のサーバアーキテクチャを示す図。
【図２】本発明のハイブリッド・ピアツーピア・アーキテクチャを示す図。
【図３】ファイアウォールの背後にあるピアサーバへのｗｅｂブラウザ接続を可能にするためのプロセスを示すフロー図。
【図４】ピアサーバが写真共有ピアツーピアネットワークに登録し、ファイアウォールを介して、そのサービス提供機能を評価可能にするプロセスを示すフロー図。
【図５】プロキシサーバの構成要素と、プロキシサーバを介してｗｅｂブラウザがピアサーバにＨＴＴＰ接続できるようにするための要求側ｗｅｂブラウザ、プロキシサーバ及びピアサーバ間におけるフローと、を示す図。
【図６Ａ】ピア要求パケットのコンテンツを示す図。
【図６Ｂ】ピア応答パケットのコンテンツを示す図。
【図１】
2007531166.tif 000002
【図２】
2007531166.tif 000003
【図３】
2007531166.tif 000004
【図４】
2007531166.tif 000005
【図５】
2007531166.tif 000006
【図６Ａ】
2007531166.tif 000007
【図６Ｂ】
2007531166.tif 000008
【国際調査報告】
2007531166.tif 000009