(57)【要約】【課題】ファイアウォールを通じてメディアストリーミング・アプリケーションをトンネリングする装置及び方法。【解決手段】マルチメディア・アプリケーションに関連付けられたマルチメディアデータの送信時に、クライアント・アプリケーションとサーバ・アプリケーション間にＴＣＰ／ＩＰ接続が確立される。ＵＤＰデータは一つ以上のＵＤＰデータポートからアプリケーションレベルでインターセプトされ、一つ以上のトンネルＴＣＰデータ接続に伝送される。ＴＣＰデータは一つ以上のＴＣＰデータポートからアプリケーションレベルでインターセプトされ、トンネルＴＣＰポートにリダイレクトされる。伝送されたＵＤＰデータは受信され、一つ以上のローカルＵＤＰデータポートにディスパッチされる。リダイレクトされたＴＣＰデータは受信され、次いで更に一つ以上のローカルＴＣＰデータポートにリダイレクトされる。【選択図】図２
2006304300.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア・アプリケーションに関連付けられたマルチメディアデータを送信する方法であって、
クライアント・アプリケーションとサーバ・アプリケーション間でＴＣＰ／ＩＰ接続を確立するステップと、
ＵＤＰデータ接続をトンネルＴＣＰデータ接続に伝送するステップと、
ＴＣＰデータ接続をトンネルＴＣＰポートにリダイレクトするステップであって、前記ＴＣＰデータ接続をインターセプトするステップと、前記ＴＣＰデータ接続をローカルにコールされたＴＣＰポートから前記トンネルＴＣＰポートを通じてリダイレクトするステップとを含むリダイレクトするステップと、
前記伝送されたＵＤＰデータ接続を受信し、前記ＵＤＰデータ接続をローカルＵＤＰデータポートにディスパッチするステップと、
前記リダイレクトされたＴＣＰデータ接続を受信し、前記ＴＣＰデータ接続をローカルＴＣＰデータポートにリダイレクトするステップと
を含む方法。
【請求項２】
前記ＵＤＰデータ接続の伝送をイネーブルしかつ前記ＴＣＰデータ接続のリダイレクトをイネーブルするＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリにアクセスするステップを更に含む請求項１に記載の方法。
【請求項３】
一つ乃至複数のＵＤＰデータ接続を一つ以上のＴＣＰトンネル接続に伝送するステップを更に含む請求項１に記載の方法。
【請求項４】
一つ乃至複数のＴＣＰデータ接続を対応する一つ乃至複数のＴＣＰデータポートにリダイレクトするステップを更に含む請求項１に記載の方法。
【請求項５】
前記ディスパッチされたデータＵＤＰ接続を受信するように構成されたＵＤＰデータキューを備えるステップを更に含む請求項１に記載の方法。
【請求項６】
請求項１の方法を実行するように機械に向けるように出来ている命令セットを含む媒体又は波形。
【請求項７】
データ送信方法であって、
クライアントシステムのアプリケーションレベルでデータストリームをインターセプトするステップと、
前記インターセプトされたデータストリームをトンネルポートに向けるステップと、
前記トンネルポートを通じて前記インターセプトされたデータストリームをＴＣＰ／ＩＰドライバに転送するステップと
を含む方法。
【請求項８】
送信されたデータストリームをサーバシステムのネットワークドライバレベルで受信するステップと、
前記受信されたデータストリームをサーバ・アプリケーションに転送するステップと、
前記転送されたデータを前記サーバ・アプリケーションのアプリケーションレベルでインターセプトするステップと、
インターセプトされたＴＣＰデータをローカルＴＣＰデータポートにリダイレクトするステップと、
インターセプトされたＵＤＰデータを一つ以上のローカルＵＤＰデータポートにディスパッチするステップと
を更に含む請求項７に記載の方法。
【請求項９】
前記インターセプトされたデータストリームがＵＤＰデータストリームとＴＣＰデータストリームを含むことを特徴とする請求項７に記載の方法。
【請求項１０】
前記インターセプトされたデータストリームを前記トンネルポートに向ける前記ステップが、インターセプトされたＵＤＰデータをトンネルＴＣＰデータ接続に伝送するステップと、インターセプトされたＴＣＰデータをトンネルＴＣＰポートにリダイレクトするステップとを含むことを特徴とする請求項９に記載方法。
【請求項１１】
前記中断されたＵＤＰデータを一つ乃至複数のトンネルＴＣＰデータ接続に伝送するステップを更に含む請求項１０に記載の方法。
【請求項１２】
分散されたネットワーク中にマルチメディアデータを送信するシステムにおいて、
送信トンネルポートを通じて送信されるマルチメディア・データストリームを送信するように構成された第１の計算システムと、
受信トンネルポートを通じて前記マルチメディア・データストリームを受信するように構成された第２の計算システムと
を備えるシステムであって、
前記第１の計算システムがＵＤＰデータをインターセプトし、送信トンネルＴＣＰデータポートを通じて前記ＵＤＰデータを伝送し、更にＴＣＰデータをインターセプトし、前記ＴＣＰデータを送信トンネルＴＣＰデータ接続にリダイレクトし、前記第２の計算システムが受信トンネルＴＣＰデータポートを通じて前記伝送されたＵＤＰデータを受信し、受信トンネルＴＣＰデータ接続を通じて前記リダイレクトされたＴＣＰデータストリームを受信する
ことを特徴とするシステム。
【請求項１３】
前記第１の計算システムのアプリケーションレベルでＵＤＰデータ接続をインターセプトしかつ前記送信トンネルＴＣＰデータポートを通じて前記インターセプトされたＵＤＰデータ接続を伝送するように構成されたクライアントＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリを更に備える請求項１２に記載のシステム。
【請求項１４】
前記クライアントＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリが、前記第１の計算システムのアプリケーションレベルで一つ乃至複数のＵＤＰデータ接続をインターセプトしかつ一つ乃至複数の送信トンネルＴＣＰデータポートを通じて前記インターセプトされた一つ乃至複数のＵＤＰデータ接続を伝送するように構成されることを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記第１の計算システムのアプリケーションレベルでＴＣＰデータ接続をインターセプトしかつ前記送信トンネルＴＣＰデータ接続を通じて前記インターセプトされたＴＣＰデータ接続をリダイレクトするように構成されたクライアントＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリを更に備える請求項１２に記載のシステム。
【請求項１６】
前記第２の計算システムのアプリケーションレベルで前記受信トンネルＴＣＰデータポートを通じて受信された前記伝送されたＵＤＰデータをインターセプトしかつ前記伝送されたＵＤＰデータを前記第２のシステムのローカルＵＤＰポートにディスパッチするように構成されたサーバＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリを更に備える請求項１２に記載のシステム。
【請求項１７】
前記第２の計算システムのアプリケーションレベルで前記受信トンネルＴＣＰデータポートを通じて受信された前記伝送されたＵＤＰデータをインターセプトしかつ前記伝送されたＵＤＰデータを前記第２のシステムのＵＤＰデータキューにディスパッチするように構成されたサーバＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリを更に備える請求項１２に記載のシステム。
【請求項１８】
前記第２の計算システムのアプリケーションレベルで前記受信トンネルＴＣＰデータポートを通じて受信された前記リダイレクトされたＴＣＰデータストリームをインターセプトしかつ前記リダイレクトされたＴＣＰデータストリームをローカルＴＣＰデータ接続に更にリダイレクトするように構成されたサーバＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリを更に備える請求項１２に記載のシステム。
【請求項１９】
コンピュータ間のマルチメディア通信をイネーブルする通信プロトコルであって、
ＴＣＰデータを送信するＴＣＰデータポートを開くように構成され、更にＵＤＰデータを送信するＵＤＰデータポートを開くように構成されたアプリケーションレベルのＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリと、
前記ＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリが前記ＴＣＰデータポートにおいて送信された前記ＴＣＰデータをインターセプトしかつ前記ＴＣＰデータをトンネルＴＣＰデータポートにリダイレクトするように構成され、更に前記ＵＤＰデータポートにおいて送信された前記ＵＤＰデータをインターセプトしかつ前記ＵＤＰデータを別のトンネルＴＣＰデータポートに伝送するように構成されることを特徴とする通信プロトコル。
【請求項２０】
前記アプリケーションレベルがＴＣＰデータを送信する一つ乃至複数のＴＣＰデータポートを開くように構成され、更にＵＤＰデータを送信する一つ乃至複数のＵＤＰデータポートを開くように構成されることを特徴とする請求項１９に記載の通信プロトコル。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本願は２００３年１０月８日に出願された名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＴＵＮＮＥＬＩＩＮＧ ＤＡＴＡ ＴＨＲＯＵＧＨ Ａ ＳＩＮＧＬＥ ＰＯＲＴ」の米国特許出願第１０／６８１５２３号、及び２００５年３月３日に出願された名称「ＭＵＬＴＩ−ＣＨＡＮＮＥＬ ＴＣＰ ＣＯＮＮＥＣＴＩＯＮＳ ＷＩＴＨ ＣＯＮＧＥＳＴＩＯＮ ＦＥＥＤＢＡＣＫ ＦＯＲ ＶＩＤＥＯ／ＡＵＤＩＯ ＤＡＴＡ ＴＲＡＮＳＭＩＳＳＩＯＮ」の米国特許出願第１１／０７３０６３号に関連する。
本発明は概ねインターネット中への情報送信に関し、より詳細には、インターネットを通じた、またネットワーク及びネットワークされたシステム内での、高速リアルタイムデータストリーミングの方法、システム、及び装置に関する。
【背景技術】
【０００２】
多くのインターネットに基づくアプリケーションは効率的に実行するためにデータのリアルタイムのストリーミングを提供及び交換を行う。例として、Ｈ．３２３インターネットビデオ会議システムはローカル及びリモート装置にいる出席者にビデオ及びオーディオデータを提供するために高速リアルタイムデータ交換を行う。典型的には、必要なリアルタイム・メディアストリーミングの利益を得るためにデータは信頼性のないユーザ・データグラム・プロトコル／インターネット・プロトコル（ＵＤＰ／ＩＰ、又は単にＵＤＰ）を用いて送信される。ＵＤＰはパケット確認応答、パケット検証、パケット再送信要求等を送信しないので、信頼性のあるトランスミッション・コントロール・プロトコル（ＴＣＰ、ＴＣＰ／ＩＰともいう）に対する、信頼性のないＵＤＰを用いる利点は主として速度の利点である。リアルタイム・メディアストリーミングにおいて、そのような送信及び検証処理はシステム性能に悪影響を及ぼす。
【０００３】
ＴＣＰは現行インターネットの主流のトランスポート・レイヤ・プロトコルである。ＴＣＰは、全てのデータが受信され、正しい順序で受信され、受信されたデータが正確でかつ送信されたデータと一致することを保証することにより最高度の信頼性を維持する。多くのアプリケーションにおいて、そのような信頼性は効率的な通信及びデータ交換にとって最も重要である。
【０００４】
ＴＣＰはほとんどの産業用及び民生用ファイアウォールにより広く受け入れられるので、メディア、即ちビデオ及びオーディオストリームのストリーミングがＴＣＰ接続を通じて行えれば好ましい。ＴＣＰストリームはＵＤＰストリームよりネットワークセキュリティーにフレンドリーであることも知られている。
【０００５】
しかしながら、オフィス又はホームネットワークから別のＨ．３２３クライアント又はＨ．３２３会議サーバに接続する際のＨ３２３アプリケーションに関する最も一般的な問題の一つは、これらのサイトのほとんどがファイアウォールにより保護されていることである。ファイアウォールは典型的には保護されたネットワークから望まないＩＰトラフィックを締め出すように設計されている。しかしながら、Ｈ．３２３プロトコルは、それが正しく働くためには多数のＴＣＰ及びＵＤＰポートがアンブロックされる必要がある（例えば、１０２４−６５５３８からの全てのＵＤＰポートがアンブロックされる必要がある）。あまり多くのポートを開くことはローカルネットワークのセキュリティーを低下させ、従って、通常は一般的なファイアウォールはそれを許さない。
【０００６】
一つの解決策はＨ．３２３で作動する、あるいは少なくともそれにフレンドリーな特殊ファイアウォールをインストールすることである。残念ながら、この種のファイアウォールを持つサイトは多くない。一方、ほとんどのファイアウォール（全部とは言わないが）は一般的なウェブブラウジングに対してＨＴＴＰ（ハイパー・テキスト・トランスファー・プロトコル）ポートを開いている。ＨＴＴＰポートは実効的にはポート８０上のＴＣＰ接続である。
【特許文献１】米国特許出願公開第2004/0029555号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００７】
以上を考慮すれば、必要とされるものは、ファイアウォールの外側で同じ伝送方法を実行する別のＨ．３２３アプリケーションと通信できるようにＴＣＰポート８０接続のみを通じてそのデータの全てを伝送するＨ．３２３アプリケーションである。
【課題を解決するための手段】
【０００８】
大雑把に言って、本発明は、Ｈ．３２３アプリケーションデータをトンネリングするために標準のＨＴＴＰ／ＴＣＰ（ポート８０）接続を利用する方法及び装置を提供することによりこれらのニーズを満たす。本発明はプロセス、装置、システム、デバイス、方法、又はコンピュータ読み取り可能な媒体としての実施を含む、多数のやり方で実施できる。本発明のいくつかの実施例が以下に述べられる。
【０００９】
一つの実施例において、マルチメディア・アプリケーションに関連するマルチメディアデータを送信する方法が提供される。この方法はクライアント・アプリケーションとサーバ・アプリケーション間のＴＣＰ／ＩＰ接続を確立することを含む。次いでこの方法はＵＤＰデータ接続をトンネルＴＣＰデータ接続に伝送し、ＴＣＰデータ接続をトンネルＴＣＰポートにリダイレクト（re-direct）するようにする。リダイレクトはＴＣＰデータ接続をインターセプト（intercept）し、ローカルにコールされたＴＣＰポートからトンネルポートを通じてＴＣＰデータ接続をリダイレクトすることを含む。この方法は更に、伝送されたＵＤＰデータ接続を受信し、ＵＤＰデータ接続をローカルＵＤＰデータポートにディスパッチ（dispatch）するようにする。更に、リダイレクトされたＴＣＰデータ接続が受信され、次いでＴＣＰデータ接続がローカルＴＣＰデータポートにリダイレクトされる。
【００１０】
もう一つの実施例において、データ送信方法が提供される。この方法はクライアントシステムのアプリケーションレベル（at an application level）のデータストリームをインターセプトし、インターセプトされたデータストリームをトンネルポートにリダイレクトすることを含む。インターセプトされたデータストリームはトンネルポートを通じてＴＣＰ／ＩＰドライバに転送される。
【００１１】
更なる実施例において、インターネット中にマルチメディアデータを送信するシステムが提供される。このシステムはマルチメディア・データストリームを送信するように構成された第１の計算システムを含む。マルチメディア・データストリームはトンネルポートを通じて送信される。このシステムは更にトンネルポートを通じてマルチメディア・データストリームを受信するように構成された第２の計算システムを含む。第１の計算システムはＵＤＰデータをインターセプトし、トンネルＴＣＰデータポートを通じてこのＵＤＰデータを伝送する。第１の計算システムは更に、ＴＣＰデータをインターセプトし、このＴＣＰデータをトンネルＴＣＰデータ接続にリダイレクトする。第２の計算システムは伝送されたＵＤＰデータをこのトンネルＴＣＰデータポートを通じて受信し、リダイレクトされたＴＣＰデータストリームをこのトンネルＴＣＰ接続を通じて受信する。
【００１２】
なお更なる実施例において、計算デバイス間のマルチメディア通信を可能にする通信プロトコルが提供される。この通信プロトコルは、ＴＣＰデータを送信するためにＴＣＰデータポートを開けるように構成され、更にはＵＤＰデータを送信するように構成されたアプリケーションレベルでＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリを備える。ＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリはＴＣＰデータポートにおいて送信されたＴＣＰデータをインターセプトしかつこのＴＣＰデータをトンネルＴＣＰデータポートにリダイレクトするように構成される。ＷｉｎＳｏｃｋＰｒｏｘｙ動的リンクライブラリは更にＵＤＰデータポートにおいて送信されたＵＤＰデータをインターセプトし、このＵＤＰデータを別のトンネルＴＣＰデータポートに伝送するように構成される。
【００１３】
本発明の先行技術に勝る利点は数知れない。発明の一つの顕著な恩恵と利点は性能である。全てのＵＤＰ及びＴＣＰデータが単一のＴＣＰ接続に伝送されるデータ転送のやり方もある。本願に述べられる実施例は単一のＴＣＰ接続への伝送に比較してネットワーク輻輳を緩和する。例えば、全てのデータが単一のＴＣＰ接続を通じて伝送される場合、たった一つのＴＣＰ／ＩＰパケットの再送が伝送ＴＣＰ接続において残りのデータを遅延することになる。本発明の実施例は多数のＴＣＰチャンネルを提供する。一つの伝送ＴＣＰ接続に再送があれば、データは他の接続にもやはり流れる。
【００１４】
もう一つの利点はフレキシビリティーである。単一のＴＣＰ伝送接続を実施する構成では、アプリケーションはデータを単一の伝送接続に多重化しなければならない。本発明の一つの実施例では、伝送ＴＣＰ接続は２タイプ、即ちＵＤＰ型及びＴＣＰ型伝送接続に分けられる。ＵＤＰ型伝送接続に対しては全てのＵＤＰトラフィックを共有する一つ以上のＴＣＰ伝送接続のプールがある。しかしながらＴＣＰ接続に対しては、各接続は、当初の所期のＴＣＰポートからトンネルポート（例えばポート８０）に１対１にマッピング、トンネリング、及び／又はリダイレクトされる。従って、アプリケーションがピア／サーバへの更なる接続を行う場合、新しいデータストリームは、ネットワーク帯域幅全体の使用に対する衝撃としてのものを除き、他の伝送接続に影響もせず、またそれと干渉もしない。
【００１５】
発明の他の利点は、例として発明の原理を図解する、添付図と関連して行われる以下の詳細な説明から明らかとなるであろう。
【発明を実施するための最良の形態】
【００１６】
本明細書に組み入れられ、その一部を構成する添付図は、発明の原理を説明する役目をする説明と共に発明の実施例を示す。
【００１７】
標準のＨＴＴＰ／ＴＣＰ（ポート８０、本願では通常ＴＣＰポート８０と呼ぶ）接続を利用してＨ．３２３アプリケーションデータを伝送する発明が提供される。好ましい実施例において、本発明は伝送細部の多くをＨ．３２３アプリケーション自身から防護している。以下の説明において、本発明の十分な理解を与えるために多数の個々の細部が記載される。しかしながら、本発明がこれらの個々の細部のいくつか又は全てを用いないで実施してよいことは言うまでもない。その他に、本発明を不必要に曖昧にしないように周知の処理動作は詳細には説明しなかった場合もある。
【００１８】
大雑把に言って、本発明の実施例は、全てのＨ．３２３ＴＣＰ／ＵＤＰポートトラフィックを多数のＨＴＴＰ／ＴＣＰ接続を通じてトンネリングすることにより実施される。関連する、現在同時係属中の米国特許出願において、例えば、データを送信するアンブロックされたポートを制限するように構成されたファイアウォールを通過するために単一のＨＴＴＰポートを通じてデータがトンネリングされるやり方が開示されており、それは標記の同時係属中の米国特許出願第１０／６８１５２３号に記述され、その開示はあらゆる目的で本願に引用して援用される。もう一つの試みは、多数のトンネルＴＣＰ接続を使用し、それは標記の同時係属中の米国特許出願第１１／０７３０６３号に記述され、その開示はやはりあらゆる目的で本願に引用して援用される。
【００１９】
これらの関連出願において、概して、実施がデバイスドライバ又はカーネルレベルで達成されるやり方が開示される。本発明の実施例は概してアプリケーションレベルで実施される。本発明の実施例は、トンネリングの実施をありきたりのソケットライブラリーの上に重ねられるプロキシソケットライブラリーに抽象化して現存のＨ．３２３型アプリケーションとトンネリング方法を統合することにより実施するようにする。更に本発明は、一つの実施例において、全てのＨ．３２３ＵＤＰデータを単一のＨＴＴＰ／ＴＣＰ接続に組み合わせ、各Ｈ．３２３ＴＣＰ接続に対してＨＴＴＰ／ＴＣＰ接続リダイレクトを実施することにより、Ｈ．３２３データトンネリングの実施を簡略化する。もう一つの実施例において、全てのＨ．３２３ＵＤＰデータは多数のＨＴＴＰ／ＴＣＰ接続に伝送される。
【００２０】
通常は、Ｈ．３２３アプリケーションはＴＣＰポート１７２０にリストされている別のＨ．３２３アプリケーションとのＴＣＰ接続を確立する。その後に続くデータ交換において、両方のアプリケーションはコントロールデータとメディアデータ（例えばストリーミングメディア等）の送信のためにもっと多くのＴＣＰ及びＵＤＰポートを開く。図１は典型的なＨ．３２３ＴＣＰ／ＵＤＰ接続シーケンスを図解する簡略化された模式図である。図１に図解されるように、Ｈ．３２３アプリケーションはＴＣＰポート１７２０にリストされている別のＨ．３２３アプリケーションとのＴＣＰ／ＩＰ接続を開始する。例えば、クライアントＡ、１１０はクライアントＢ、１１２への送信１１４を通じてポート１７２０へのＴＣＰ接続を要求する。セットアップ及びコールコントロール送信１１６のようなアプリケーション専用ＴＣＰ接続が信頼性のあるＴＣＰ接続を通じて進行する。その後に続くデータ交換は接続１１８、１２０、１２２、及び１２４により表され、これらは確立できる任意の数の接続を代表しているつもりである。例として、メディアストリーミング（例えば、リアルタイム及びその他のオーディオ及びビデオデータ）はＵＤＰポート及びプロトコルを利用してもよく、そのような接続はオーディオ・リアルタイム・コントロール・パケット１１８、オーディオ・リアルタイム・パケット１２０、ビデオ・リアルタイム・コントロール・パケット１２２、及びビデオ・リアルタイム・パケット１２４等に対して確立されてもよい。典型的な接続シーケンスの間、Ｈ．３２３アプリケーションはオープンソケット（ＴＣＰかＵＤＰかの何れか）にデータを書き込み、Ｗｉｎｓｏｃｋ３２．ｄｌｌモジュールがこのデータをＴＣＰ／ＩＰドライバに送る。
【００２１】
周知のように、Ｗｉｎｓｏｃｋ３２．ｄｌｌは動的リンクライブラリであり、これは小さいプログラムの集積であり、その何れもＨ．３２３ビデオ会議プログラムのようなコンピュータ上で実行しているより大きいプログラムが必要とするときにコールしてもよい。動的リンクライブラリの一つのバージョンはＷｉｎｓｏｃｋ．ｄｌｌとして知られている。用語「Ｗｉｎｓｏｃｋ．ｄｌｌ」及び「Ｗｉｎｓｏｃｋ３２．ｄｌｌ」は本願全体を通じて互換的に使用される。
【００２２】
本発明の一つの実施例において、発明の動的リンクライブラリ（ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ）モジュールはＨ．３２３アプリケーションと従来のＷｉｎｓｏｃｋ．ｄｌｌ／ＴＣＰ−ＩＰスタックの間に挿入される。ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュールは通常は従来のＷｉｎｓｏｃｋ．ｄｌｌにより実行されるＡＰＩ（アプリケーション・プログラミング・インターフェース）の全てを実行する。一つの実施例において、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌは、がＨ．３２３アプリケーションから全てのＡＰＩコールをインターセプトし、ＴＣＰポート８０（即ちＨＴＴＰ）トンネリングを実行する。その結果、本発明の実施例はアプリケーションのコードの修正を何ら必要としない。
【００２３】
図２は本発明によるクライアント１５２とサーバ１５４の間のデータフローの高レベルの模式図１５０である。高レベルの模式図１５０の以下の説明は本発明の一つの実施例によるデータ処理及びフローの概要を提供する。一つの実施例において、クライアント１５２はサーバ１５４との全ての接続を開始する。図２に図解されるように、例示的Ｈ．３２３クライアント・アプリケーション１５６が、それぞれ１５６ａ、１５６ｂで示されるＴＣＰポート１７２０及びアプリケーション専用ＴＣＰポート７７７７と、複数のＵＤＰポート１５６ｃ〜１５６ｆを開く。クライアントＨ．３２３アプリケーション１５６からのデータ送信（即ちソケットＡＰＩコール）に対する処理動作の全てはＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ１５８によりインターセプトされ、そこでデータは１６０で示されるＴＣＰポート８０を通じて伝送される。各ＴＣＰデータストリームは１６０ｃ及び１６０ｂで示されるＴＣＰポート８０にリダイレクトされ、複数のＵＤＰポート１５６ｃ〜１５６ｆのそれぞれからのＵＤＰデータはＴＣＰポート８０のＵＤＰトンネル多重化装置１６０ａにある単一のＴＣＰトンネル接続に伝送される。一つの実施例において、複数のＵＤＰポート１５６ｃ〜１５６ｆからのＵＤＰデータはＴＣＰポート８０のＵＤＰトンネル多重化装置１６０ａにある複数のＴＣＰトンネル接続に伝送される。クライアントＷｉｎｓｏｃｋ／ＴＣＰ−ＩＰスタック１６２は標準のＴＣＰポート８０接続データとしてデータの全てを送信し、サーバＷｉｎｓｏｃｋ／ＴＣＰ−ＩＰスタック１６４はこのＴＣＰトンネルポート８０トラフィックの全てを受信する。
【００２４】
サーバ側において、サーバＷｉｎｓｏｃｋ／ＴＣＰ−ＩＰスタック１６４は伝送されたトンネルＴＣＰデータの全てをＴＣＰポート８０、１６８上で受信し、このデータを該当するサーバＨ．３２３アプリケーション１７２に転送する。伝送されたトンネルＴＣＰデータはＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ１６６によりインターセプトされる。当初は異なるＴＣＰポートに対するＴＣＰデータとしてクライアントＨ．３２３アプリケーション１５６により送信されたインターセプトされたＴＣＰデータはＴＣＰポート８０、１６８内のＴＣＰリダイレクト１６８ｂで示されるように該当するローカルＴＣＰポートにリダイレクトされ、それによりサーバＷｉｎｓｏｃｋ／ＴＣＰ−ＩＰスタック１６４を通じて、サーバＨ．３２３アプリケーション１７２の所期のＴＣＰポート１７２ａ及び１７２ｂに送り返される。当初はＵＤＰデータとして送られたインターセプトされたＴＣＰデータはＵＤＰトンネル分波器１６８ａにおいてその当初のＵＤＰデータ状態に戻され、図解された実施例ではサーバＨ．３２３アプリケーション１７２により開かれた複数のローカルＵＤＰポート１７２ｃ〜１７２ｆにディスパッチされる。一つの実施例において、ＵＤＰキュー１７０がＵＤＰポート１７２ｃ〜１７２ｆにディスパッチされる。もう一つの実施例において、ＵＤＰキュー１７０がＵＤＰポート１７２ｃ〜１７２ｆのそれぞれに対して形成され、またＵＤＰデータパケットが該当するそのキュー１７０に追加される。もう一つの実施例において、ＵＤＰキューは追加のローカルに開かれたポートに置き換えられる。トンネリングされたＵＤＰデータはこれらのローカルに開かれたＵＤＰポートからＨ．３２３アプリケーションのＵＤＰポートに送られる。
【００２５】
上に述べられたように、本発明の一つの実施例はファイアウォール環境においてメディアストリームをトンネリングするようにする。典型的な接続シーケンスにおいて述べられた環境はＨ．３２３クライアントとＨ．３２３サーバ間の通信路にファイアウォールを含み、Ｈ．３２３クライアントはこのファイアウォールの内側にいる（「後に」いるとも言われる）。Ｈ．３２３クライアントはファイアウォールの外側のＨ．３２３サーバへのＴＣＰ接続を開始する。図３は本発明の一つの実施例によるＨ．３２３クライアント１８０とＨ．３２３サーバ１８４間の通信路を図解するために提示される。図解されるように、Ｈ．３２３クライアント１８０はファイアウォール１８２の内側におり、インターネット１８６又は何れかのネットワークを通じてＨ．３２３サーバ１８４にアクセスする。Ｈ．３２３サーバ１８４が別のＨ．３２３クライアント型のアプリケーション、ビデオ会議サーバ・アプリケーション等を含む他の何れのＨ．３２３でもよいことは言うまでもない。説明を容易にするために、Ｈ．３２３アプリケーション１８４は本願ではＨ．３２３サーバ１８４アプリケーションと呼ばれる。
【００２６】
本発明の実施例は発明の動的リンクライブラリ・モジュールＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌを含み、これはＨ．３２３アプリケーション（クライアント側とサーバ側の両方にある）とオペレーティングシステム（ＯＳ）Ｗｉｎｓｏｃｋ．ｄｌｌ／ＴＣＰ−ＩＰスタックの間に挿入される。本発明の実施例に対して述べられたトンネル・オペレーションの全てはこのＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュールにより、またその中で完了される。
【００２７】
図４は本発明の一つの実施例によるＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュール２０２の相対配置と内容を示す。上で述べられたように、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュール２０２はＨ．３２３アプリケーション２００とＯＳＷｉｎｓｏｃｋ／ＴＣＰ−ＩＰスタック２０４の間に挿入される。一つの実施例において、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュール２０２は接続マネージャ２０２ａ、ローカルポート・マネージャ２０２ｂ、及びＴＣＰリダイレクト・マネージャ２０２ｃを含む。ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュール２０２のコンポーネントのそれぞれは以下の段落において述べられる。
【００２８】
本発明の一つの実施例において、ＣｏｎｎｅｃｔｉｏｎＭｇｒコンポーネント２０２ａの主機能は、トンネルポート（この例ではポート８０）に対する入り側接続要求を処理することである。一般的にトンネルポートに対して二つのタイプのＴＣＰ接続がある。即ち、１）ＵＤＰデータに対するトンネル接続と、２）ＴＣＰデータに対するリダイレクト接続である。
【００２９】
ＣｏｎｎｅｃｔｉｏｎＭｇｒ２０２ａが接続要求を受け入れた後、それはデータの最初のブロックを読み取って接続のタイプを判定する。それがＵＤＰデータに対するトンネル接続であれば、ＣｏｎｎｅｃｔｉｏｎＭｇｒ２０２ａの一つの実施例は、この接続を通過するデータの全てを処理するＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒと呼ばれるスレッドを作成する。ＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒは入って来るデータの全てを読み取り、ＬｏｃａｌＰｏｒｔＭｇｒコンポーネント２０２ｂと通信してそのデータに対する所期の送信先ＵＤＰポートに基づいて然るべきキューにそのデータをディスパッチする。
【００３０】
一つの実施例において、ＬｏｃａｌＰｏｒｔＭｇｒ２０２ｂはＨ．３２３アプリケーションがバインドする各ＵＤＰポートに対するキュー・オブジェクト（これは本願では「キュー」とも呼ばれる）のリストを維持する。これらのキューは発明の一つの実施例では、入って来るデータ専用である。もう一つの実施例において、入って来るデータバッファリングと出て行くデータバッファリングの両方に対して一つのキューが作成及び維持され、もう一つの実施例では、出て行くデータの各ポートに対して別個のキューが作成及び維持される。一つの実施例において、このキューは従来のローカルメモリに割り当てられたキューされたデータオブジェクト、即ち「キュー」、あるいはＨ．３２３アプリケーションにより開かれた単一のＵＤＰポートにＵＤＰデータを転送する別のローカルにバインドされたＵＤＰポートである。
【００３１】
ＣｏｎｎｅｃｔｉｏｎＭｇｒ２０２ａにより受信された接続要求がリダイレクトＴＣＰ接続に対するものである場合、ＣｏｎｎｅｃｔｉｏｎＭｇｒ、２０２ａは接続要求をＴＣＰＲｅｄｉｒｅｃｔＭｇｒコンポーネント２０２ｃに送る。一つの実施例において、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２０２ｃは所期のローカルＴＣＰポートへの入側接続のためのローカルＴＣＰ接続を作成する。ＯＳの現存のＴＣＰ／ＩＰ方法が、ＴＣＰ接続の要求が行われたら、アプリケーションがそのＴＣＰ接続の点又は位置に影響できないように動作することは言うまでもない。その結果、本発明の実施例はローカルＴＣＰポートへのもう一つの別個の接続を行ってトンネル接続とローカル接続の間でデータを伝送する方法を提供する。ＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２０２ｃは一つの実施例において、図５にジャンクション２２３で示されるように、トンネル及びローカル接続間で全てのデータを転送する。本発明の一つの実施例において、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２０２ｃはＣｏｎｎｅｃｔｉｏｎＭｇｒ２０２ａから入側トンネルＴＣＰ接続を受け入れる。次いで、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２０２ｃは二方向即ち双方向データ転送を行いながら、トンネル及びローカル接続間でデータを転送する。
【００３２】
図５は、本発明の一つの実施例による、Ｈ．３２３クライアントがＨ．３２３サーバのポート１７２０へのＴＣＰ接続を行うＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２０２ｃの機能を図解する。Ｈ．３２３クライアント２１０はＨ．３２３サーバ２２４のポート１７２０へのＴＣＰ接続２１２を行う。ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ２１４はＨ．３２３クライアント２１０アプリケーションからのソケット機能コールをインターセプトする。ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ２１４はＨ．３２３クライアントの当初の送信先ポート番号をポート１７２０から、２１６で示されるポート８０に変更する。Ｈ．３２３サーバ側において、ＣｏｎｎｅｃｔｉｏｎＭｇｒ２２０ａがそのローカルＴＣＰポート８０上で入側トンネルＴＣＰ接続を待っている。Ｈ．３２３クライアント２１０とＨ．３２３サーバ２２４間のトンネルＴＣＰ接続が確立されたら、Ｈ．３２３クライアント側のＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ ２１４は、トンネルＴＣＰ接続がＨ．３２３クライアント２１０から当初どのローカルＴＣＰポートトンネル接続を意図されていたかを詳述するトンネリング専用の情報ブロックをＨ．３２３サーバ側のＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ２２０へ送る。
【００３３】
Ｈ．３２３サーバ側のＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ２２０がこの情報を受信した後、ＣｏｎｎｅｃｔｉｏｎＭｇｒ２２０ａはこの要求と情報をＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２２０ｂに転送する。ＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２２０ｂはローカルの所期のＴＣＰポート（この場合２２２で示されるポート１７２０）への新しいＴＣＰ接続を作成する。接続が確立されたら、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ２２０は、接続がポート８０にリダイレクトされたことを知ることなくＨ．３２３クライアント２１０アプリケーションがいつものようにデータを送受信する、Ｈ．３２３クライアント２１０アプリケーションにソケット処理を返す。一つの実施例において、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２２０ｂは、図５にジャンクション２２３で図解されるように、トンネルＴＣＰ接続とローカルＴＣＰ接続間でデータを転送する専用のスレッドを有する。Ｈ．３２３サーバ２２４アプリケーションはまたＴＣＰポート１７２０に対する新しい接続要求を受信するスレッドを有する。しかしながら、ソケットａｃｃｃｅｐｔ（）機能コールの間、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ２２０は入側接続リモートシステム（Ｈ．３２３クライアント２１０）ＩＰアドレスをローカルＩＰからリモートシステムのローカルＩＰに置き換える。この情報はトンネルデータの最初のブロックの間にＨ．３２３クライアント側ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ２１４からＨ．３２３サーバ側のＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ２２０に送られる。一つの実施例において、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２２０ｂは、トンネルヘッダ情報の最初のブロックを除き、二つのＴＣＰ接続の何れかに対して読み書きする如何なるデータも、修正、挿入、又は削除もしない。この実施例において、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２２０ｂはジャンクション２２３のトンネル及びローカル接続間でデータを転送する。
【００３４】
再び図２を眺めれば、本発明の一つの実施例において、Ｈ．３２３クライアント１５６は、Ｈ．３２３クライアント１５６とＨ．３２３サーバ１７２が互いへのＵＤＰデータ送信を開始する前にＨ．３２３サーバ１７２へのＴＣＰポート１７２０、１５６ａ接続を作成する。知られているように、Ｈ．３２３クライアント１５６がＴＣＰポート１７２０、１５６ａ接続を行う前に何れのＨ．３２３アプリケーションもＨ．３２３サーバ１７２への他のＴＣＰ接続を確立してもよい。しかしながら、Ｈ．３２３データ交換の一つの特長は、ＵＤＰデータが送られる前には概ね常にＨ．３２３サーバ１７２へのＴＣＰ接続が一つあることである。
【００３５】
本発明の実施例はＨ．３２３データ交換のこの特長を利用している。ある一意のリモートＩＰアドレスに対するＴＣＰ接続番号を追跡及び管理するために表が作成される。正に最初のＴＣＰ接続要求がリモートＩＰ（今の例ではサーバＨ．３２３アプリケーション１７２のＩＰ）に対して成されたときに、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ１５８は一つの実施例ではリモートＩＰへのトンネルＴＣＰ接続を、別の実施例では多数のトンネルＴＣＰ接続を作成する。このリモートＩＰへの最新の標準の（非トンネル）ＴＣＰ接続が閉じられたときに（即ち、クライアント・アプリケーション１５６により）、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ１５８はそのリモートＩＰに対するトンネルＴＣＰ接続を閉じることになる。クライアントが接続を閉じたら、ソケット（即ちＴＣＰ接続）がリモート側（Ｈ．３２３クライアント）により閉じられたことをサーバが知ることになるのは言うまでもない。その結果、Ｈ．３２３サーバ側のＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌがサーバ側の接続を閉じながらクリーンアップを開始することになる。
【００３６】
典型的なＨ．３２３データ交換においては二つの接続タイプがある。ＴＣＰ接続とＵＤＰ接続である。本発明の実施例においては、ＵＤＰ接続に対し、全てのデータは一つの実施例においては単一のトンネルＴＣＰ接続を用いて、別の実施例では多数のトンネルＴＣＰ接続を用いて送受信される。ＴＣＰ接続、即ち当初、通常にＴＣＰを用いて送信されるデータに対し、一つ以上の接続への多数のＴＣＰ接続データの伝送はない。その代わり、ＴＣＰデータに対して開かれた各ＴＣＰ接続はそれ自身の属性又は特長を維持する。本発明の実施例は元のＴＣＰ接続データが透過的にトンネルＴＣＰポートに送られるようにする。
【００３７】
上で述べられたように、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌは本発明の実施例においては、ＵＤＰデータに対してトンネル接続を作成し、ＴＣＰ接続を異なる専用のＴＣＰトンネルポート（例えば、本願で述べられた実施例ではＴＣＰポート８０）に透過的にリダイレクトするようにする。トンネルＵＤＰデータに対し、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌは各ＵＤＰデータブロックの前に、ＵＤＰデータが当初目指した元の送信先ＵＤＰポートを含む情報を有する個々の特殊なトンネルヘッダを挿入する。更に、一つの実施例において、以下にもっと詳細に述べられるように、トンネル接続のタイプがトンネルヘッダ情報の最初のブロックにより定義される。
【００３８】
図４を参照して上に述べられるように、ＣｏｎｎｅｃｔｉｏｎＭｇｒ２０２ａは二つのタイプのトンネルＴＣＰ接続、即ち、１）ＵＤＰトンネル接続、及び２）ＴＣＰリダイレクト接続を区別する。ＣｏｎｎｅｃｔｉｏｎＭｇｒ２０２ａが接続を受け入れたら、それはトンネルＴＣＰ接続からの所定の長さの最初のデータブロックをトンネルヘッダ情報として読み取る。このトンネルヘッダは当初送信された送信先ポートや、以下に述べられる他の情報のような情報を含む。発明の一つの実施例において、トンネルＴＣＰ接続からの情報の最初のブロックは２０バイトの接続ヘッダである。図６Ａは本発明の一つの実施例による接続ヘッダのデータフィールドを説明する表である。
【００３９】
図６Ａに示される接続ヘッダフィールドの表は各行にデータフィールドを記述し、列にはデータタイプ２５０、データフィールド名２５２、及びデータフィールドの簡単な説明２５４が記載されている。図６Ａにおいて特に注意すべきことは接続タイプ２５６を識別する接続ヘッダのデータフィールドであり、これは、２５８で示されるように、接続タイプをＵＤＰトンネル接続かＴＣＰリダイレクト接続かを識別するものとして説明される。一つの実施例において、接続ヘッダのもう一つのデータフィールドはＩｎｔｅｎｄｅｄＰｏｒｔフィールド２６０である。ＩｎｔｅｎｄｅｄＰｏｒｔデータフィールド２６０は、２６２で示されるように、ローカルホストにおいて接続が目指したポート番号を識別するものとして説明される。更に、接続ヘッダはＲｅｍｏｔｅＩＰデータフィールド２６４を含む。図示のように、ＲｅｍｏｔｅＩＰデータフィールド２６４はリモートシステムの元のローカルＩＰを識別する。ＲｅｍｏｔｅＩＰデータフィールド２６４は接続識別情報がデータフィールド２６６においてファイアウォールにより変換されたかも知れないＩＰを反映することになるので必須であることが強調される。
【００４０】
図６Ａに示されるように、接続ヘッダは、数ある属性のなかでも、ＵＤＰトンネル接続かＴＣＰリダイレクトかの接続タイプを識別する２５６、２５８。ＴＣＰリダイレクト接続に対し、接続ヘッダの後の全てのデータは本質的に標準又は典型的なアプリケーションデータであり、ローカル・ループバック接続まで送られる。ＵＤＰトンネル接続に対し、全てのデータはトンネルヘッダ内に押し込められる。
【００４１】
図６Ｂは本発明の一つの実施例によるトンネルヘッダのデータフィールドを説明する表である。図６Ｂは丁度図６Ａに提示されたように、各行にデータフィールドを記述し、各列にはデータタイプ２７０、データフィールド名２７２、及びデータフィールド２７４の簡単な説明を記述するデータフィールドを提示する。データフィールド自身は当業者には容易に理解される。特に注意すべきことは、所期のポートデータフィールド２７６が、ローカルホスト２７８においてデータパケットが目指したポート番号を識別することである。更に、ＲｅｍｏｔｅＩＰデータフィールド２８０はリモートシステム２８２の元のローカルＩＰを識別する。図６Ａの接続ヘッダに関連して上に述べられたように、接続識別情報はファイアウォール、ネットワークアドレス変換（ＮＡＴ）ルータ等において生じ得る変換によりリモートシステムの正しいローカルＩＰを識別しないかも知れない。同様に、データフィールドＲｅｍｏｔｅＰｏｒｔ２８４はデータフィールド２８６において述べられたようにデータパケットを送るリモートポート番号を識別する。
【００４２】
本発明の一つの実施例において、８バイトの０ｘＦＦＦ８ＦＦＦＦと、デリミタとしてトンネル・パケットブロックの前に設けられた０ｘＦＦＦＦＦ４ＦＦがある。デリミタはパケット境界の位置を決定するのを助ける。トンネル・データパケットはＴＣＰ接続を用いて送信され、所期の結果は全ての送信されたデータが受信されることである。しかしながら、本発明の実施例はこのようにしてパケット境界を識別することにより多少の保証を与える。デリミタがなく、データストリームが何かの理由で破損されたら、トンネルヘッダに対するオフセットが正しくなくなるのでデータを回復する手立てがない。本発明の実施例は、もし破損されたデータパケットがデータストリームに入ったら、パケット境界を直ちにかつ容易に識別してデータを回復し、残りのデータを読み続けることができるようにする。
【００４３】
図６Ａ及び６Ｂに示される実施例が接続（図６Ａ）及びトンネリング（図６Ｂ）に対する例示的データフィールドであることは言うまでもない。他の実施例が異なるフィールドを利用してもよく、あるいはデータを種々のやり方で配列してもよい。図６Ａ及び６Ｂに示される実施例は従って、唯一のものでも、これに限定するものでもなく、例示又は例証であると解釈すべきである。
【００４４】
本発明の一つの実施例において、本発明に従って送信されたデータはデータストリームの実際のデータの前に接続ヘッダとトンネルヘッダ（ＵＤＰデータパケットに対する）を有するバイトストリームを備える。図６Ｃは一つの実施例によるトンネルデータの例示的バイトストリームを示す表である。例示的バイトストリームは図６Ａを参照して述べられたように、８バイトのデリミタ２９０、１２バイトの接続ヘッダ２９２、図６Ｂを参照して述べられたように、８バイトのデリミタ２９０、１４バイトのトンネルヘッダ２９４、及びデータ２９６を含む。ＴＣＰリダイレクト・データがデリミタ２９０と１２バイトの接続ヘッダ２９２を含むが、１４バイトのトンネルヘッダ２９４を含まないことは言うまでもない。上に詳細に述べられたように、ＴＣＰリダイレクトは一つの実施例では接続ヘッダ２９２に付加され、例えばＨＴＴＰポート８０を用いて送信されるＴＣＰ接続データである。トンネルポートを介して受信されたＴＣＰデータは次いでサーバＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌにより所期のＴＣＰポートにリダイレクトされる。対照的に、ＵＤＰデータはトンネルＨＴＴＰ（ＴＣＰ）ポート８０を用いて、一つの実施例では単一のＴＣＰ接続に伝送され、別の実施例では多数のＴＣＰ接続に伝送され、従って、更なるトンネルヘッダ２９４はＴＣＰトンネル・データストリームとして送信されたＵＤＰデータに使用される。
【００４５】
入側トンネル接続を該当する処理モジュールにディスパッチする他に、本発明の一つの実施例は、ＣｏｎｎｅｃｔｉｏｎＭｇｒがリモートピアのＩＰアドレス衝突管理の機能を実行するようにする。知られているように、Ｈ．３２３サーバへの各Ｈ．３２３接続は各Ｈ．３２３クライアントに対する一意的でありかつ一貫したＩＰアドレスを必要とする。クライアントとサーバ間に介在するファイアウォールやＮＡＴがない環境においては、クライアントＩＰアドレスの全ては一意的でありかつ一貫している。サーバは一意的なＩＰアドレスにより各Ｈ．３２３クライアントを容易に識別できる。しかしながら、Ｈ．３２３クライアントとＨ．３２３サーバ間にファイアウォール、ＮＡＴ、又は他の類似のデバイスが存在するときは、ＩＰアドレス衝突として知られた状態のＩＰアドレスの重複が生じ得る。典型的な例は、二つのＨ．３２３クライアントが同じファイアウォール／ＮＡＴの後からＨ．３２３サーバに接続する状況である。Ｈ．３２３サーバは同じＩＰアドレス（例えばファイアウォール／ＮＡＴ・ＩＰアドレス）を有する二つのＨ．３２３接続要求を見ることになる。本発明の一つの実施例において、それぞれの入側トンネル接続からの下記の一対のＩＰアドレスが記録又は維持及びモニタされる。即ち、１）インターネット接続からのＩＰアドレス（例えばファイアウォール／ＮＡＴ・ＩＰアドレス）と、２）ローカルＨ．３２３クライアントＩＰアドレス（例えばファイアウォール／ＮＡＴにより保護されたローカルネットワーク内のローカルＩＰアドレス）である。一つの実施例において、この対は一意的である。
【００４６】
本発明の一つの実施例において、ＣｏｎｎｅｃｔｉｏｎＭｇｒが新しいトンネル接続を受信したら、接続ネットワークＩＰ（これはファイアウォール／ＮＡＴ・ＩＰアドレスでもよい）が検索され、このＩＰアドレスは、リモートクライアントから（即ち接続ヘッダから）送られたローカルＩＰアドレスとペアにされる。このＩＰアドレスペアを用いてＣｏｎｎｅｃｔｉｏｎＭｇｒは全ての現存するトンネル接続を検索して同じＩＰアドレスペアが既に存在するかどうかを判定する。合致があれば、即ちそのＩＰアドレスペアが既に既にマッピングされ、そのデータが、この新しい、あるいは追加されたトンネル接続を今送信しているのと同じリモートピアにより既に処理されていることを示したら、ＣｏｎｎｅｃｔｉｏｎＭｇｒは、アプリケーションに使用するために、この新しい入側トンネル接続に対して現存するトンネル接続から割り当てられたＩＰアドレスを入手する。合致がなければ、ＣｏｎｎｅｃｔｉｏｎＭｇｒは同じリモートピアのローカルＩＰアドレスを有する現存するトンネル接続の全てを検索する。合致がなければ、ＣｏｎｎｅｃｔｉｏｎＭｇｒはアプリケーションに使用するために新しいＩＰアドレス（マッピングされたＩＰ）と呼ばれる）を作成する。この場合、競合がないので、発明の一つの実施例はリモートピアのローカルＩＰアドレスが、マッピングされたＩＰアドレスとしてＣｏｎｎｅｃｔｉｏｎＭｇｒに知られたリモートピアのＩＰアドレスとしてアプリケーションに送られるようにする。しかしながら、同じマッピングされたＩＰアドレスとの別の接続があれば、ＩＰアドレス衝突がある。ＩＰアドレス衝突においては、ＣｏｎｎｅｃｔｉｏｎＭｇｒは使用中でないランダムなＩＰアドレスを作成する。一つの実施例において、ＣｏｎｎｅｃｔｉｏｎＭｇｒはそのとき、この新しく（かつランダムに）発生されたＩＰアドレスをマッピングされたＩＰとして割り当てる。
【００４７】
更に、ＩＰアドレス衝突は、リモートピアのローカルＩＰアドレスがサーバのローカルＩＰアドレスと同じ場合に起こり得る。この状況において、本発明の一つの実施例は、ＣｏｎｎｅｃｔｉｏｎＭｇｒが新しい入側トンネル接続に対して新しいマッピングされたＩＰアドレスをランダムに生成するようにする。
【００４８】
本発明の実施例によるＩＰアドレス衝突管理の二つの例を説明する。例１：ＩＰ１２２．６６．８０．８を有するファイアウォールの後にいる、ＩＰアドレス１９２．１６８．０．５を有するクライアント１とＩＰ１４４．２２．１７８．２４を有するファイアウォールの後にいる、ＩＰアドレス１９２．１６８．０．５を有するクライアント２が共にローカルＩＰアドレス１９２．１６８．０．２を有するサーバに接続される。クライアント１が接続された後（更にマッピングされたＩＰが１９２．１６８．０．５であるアプリケーションにも）、クライアント２がサーバへの接続を試みる。しかしながら、このとき、クライアント２のローカルＩＰ１９２．１６８．０．５は既にクライアント１により使用中である。従って、サーバにあるＣｏｎｎｅｃｔｉｏｎＭｇｒはマッピングされたＩＰとして新しいランダムな一意的ＩＰアドレス、例えば１７８．２２．１６．２０を生成する。これはアプリケーションに送ってもらうマッピングされたＩＰとなる。
【００４９】
例２：ＩＰアドレス１２２．６６．８０．８を有するファイアウォールの後にいるＩＰアドレス１９２．１６８．０．５を有するクライアント１がＩＰアドレス１９２．１６８．０．５を有するサーバに接続する。この場合、他のトンネル接続がないとしても、サーバはマッピングされたＩＰとしてリモートクライアントのローカルＩＰアドレスを受け入れられない。それがサーバ自身のローカルＩＰアドレスと競合するからである。従って、ＣｏｎｎｅｃｔｉｏｎＭｇｒはこの接続に対するマッピングされたＩＰアドレスとして新しい一意的なＩＰアドレスを生成する。
【００５０】
上に詳述されたように、発明の一つの実施例において、Ｈ．３２３アプリケーションが起動し、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュールをロードしたら、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌは図４に示される３つのコンポーネント、ＣｏｎｎｅｃｔｉｏｎＭｇｒ２０２ａ、ＬｏｃａｌＰｏｒｔＭｇｒ２０２ｂ、及びＴＣＰＲｅｄｉｒｅｃｔＭｇｒ２０２ｃを作成する。３つのコンポーネントを有するＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌは複数のソケット・オペレーションやトンネルポートによるバックグラウンド・リスニングのイネーブルを利用又はコールする。以下の図は例示的かつ典型的なソケット・オペレーションや、トンネルポートによるバックグラウンド・リスニング・オペレーションに対する論理フローを図解する。
【００５１】
図７Ａは本発明の一つの実施例によるソケット、即ち、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｂｉｎｄオペレーションの論理フローを図解する論理フローチャート図３００である。論理フローは判断ブロック３０２において、コールされたｂｉｎｄがＵＤＰソケットに対するものであるかどうかの判定で始まる。コールがＵＤＰソケットに対するものでなかったら、即ち、判断ブロック３０２に対して「ｎｏ」ならば、論理フローは続いてオペレーション３０６を行い、標準のｂｉｎｄオペレーションをコールする。コールがＵＤＰソケットに対するもの、即ち、判断ブロック３０２に対して「ｙｅｓ」ならば、続いて論理フローはまずオペレーション３０４に進み、そこでＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュールのＬｏｃａｌＰｏｒｔＭｇｒコンポーネントが、コールされたポート番号に対して新しい、即ち異なるＵＤＰポートを開く。ＬｏｃａｌＰｏｒｔＭｇｒにより開かれたこの新しい、即ち異なるＵＤＰポートはトンネル接続からアプリケーションの元のＵＤＰポートに受信されたデータをディスパッチするためのものである。続いて論理フローはオペレーション３０６を行い、標準のｂｉｎｄオペレーションをコールする。一つの実施例において、ソケット、即ちｂｉｎｄオペレーションはクライアントＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌとサーバＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌの何れか又は両方により実行されるオペレーションである。
【００５２】
図７Ｂは本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｃｏｎｎｅｃｔオペレーションの論理フローを図解する論理フローチャート図３１０である。ソケット、即ち図解されるようなｃｏｎｎｅｃｔオペレーションは一般的にＴＣＰ接続に対してコールされる。判断ブロック３１２において、トンネル接続がそのリモートＩＰアドレスに対して既に存在するかどうかが判定される。図１を参照して既に述べられたように、Ｈ．３２３の最初のハンドシェーク・シーケンスは典型的にはリモートピア／サーバへのＴＣＰ接続で始まり、あるいは開始される。最初のハンドシェークが異なるＵＤＰポートに送られた後にＵＤＰデータが送信される。効率を改善するために、あるリモートピア／サーバへの最初のＴＣＰ接続の間に、本発明の実施例は成功したＨ．３２３接続の過程を間もなく辿るＵＤＰに対するトンネル接続を作成する。上で述べられたように、実施例はＨ．３２３アプリケーションが送信データに対して開いている数のＴＣＰ接続を利用する。しかしながら、各接続はＨＴＴＰ（ＴＣＰ）ポート８０を使用してトンネリングされ、次いでサーバ又は受信者側で受信したときにローカルＴＣＰポート番号にリダイレクトされる。従って、リモートＩＰアドレスに対するトンネル接続が既にある、即ち、判断ブロック３１２に対して「ｙｅｓ」なら、論理フローはオペレーション３１６に進み、そこでＴＣＰリダイレクト接続が行われる。リモートＩＰアドレスに対するトンネル接続がない、即ち、判断ブロック３１２に対して「ｎｏ」なら、それが作成されねばならず、論理フローはオペレーション３１４を続いて行い、そこでは一つの実施例では一つのトンネルＴＣＰ接続が、別の実施例では多数のＴＣＰトンネル接続が作成される。オペレーション３１４に続き、論理フローは続いてオペレーション３１６を行い、ＴＣＰリダイレクト接続を作成する。ソケット、即ち図７Ｂに図解されるｃｏｎｎｅｃｔオペレーションは本質的にクライアント側オペレーションである。上で述べられたように、リダイレクトＴＣＰ接続が確立されたら、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌはトンネルヘッダ情報をリモート側に送り出し、このＴＣＰ接続が目指すＴＣＰポートを指示する。
【００５３】
図７Ｃは本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｓｅｎｄｔｏオペレーションを図解する論理フローチャート図３２０である。このオペレーションはあるいはソケットｓｅｎｄとして知られている。ソケットｓｅｎｄｔｏがコールされたら、判断ブロック３２２に示されるように、コールがＵＤＰソケットに対するものかどうかが先ず判定される。一つの実施例において、コールがＵＤＰソケットに対するものでない、即ち、判断ブロック３２２に対して「ｎｏ」なら、オペレーション３２４において標準のｓｅｎｄｔｏがコールされる。コールがＵＤＰソケットに対するもの、即ち、判断ブロック３２２に対し「ｙｅｓ」であったら、論理フローは判断ブロック３２６に進み、そこでデータがローカルホスト（ｌｏｃａｌｈｏｓｔ）に対するものであるかどうかが判定される。データがｌｏｃａｌｈｏｓｔに対するもの、即ち、判断ブロック３２２に対して「ｙｅｓ」ならば、論理フローは続いてオペレーション３２８を行い、そこではデータがＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュールのＬｏｃａｌＰｏｒｔＭｇｒコンポーネントに送られて、ローカルＵＤＰポートに、一つの実施例では、リモートＩＰ及びローカルＩＰアドレス等の情報を有する元のデータブロックの前にトンネルヘッダブロックが付加されるローカルＵＤＰポートのキューを通ってディスパッチされる。
【００５４】
データがｌｏｃａｌｈｏｓｔに対するものでなかったら、一つの実施例において、データは単一のＴＣＰトンネル接続のＴＣＰポート８０に伝送されることになる。もう一つの実施例において、データは一つ以上のＴＣＰトンネル接続のＴＣＰポート８０に伝送されることになる。従って、オペレーション３３０において、論理フローは所定のＩＰアドレスに対するトンネル接続を見つける。次に、オペレーション３３２において、データブロックの前にトンネルヘッダが付加されて、データがトンネル接続に送られる。
【００５５】
図７Ｄは本発明によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｒｅｃｖｆｒｏｍオペレーションを図解する論理フローチャート図３４０である。このソケット・オペレーションはあるいはソケットｒｅｃｖとして知られている。論理フローは判断ブロック３４２において、コールがＵＤＰソケットに対するものかどうかを先ず判定する。コールがＵＤＰソケットに対するものでない、即ち、判断ブロック３４２に対して「ｎｏ」なら、論理フローは標準のｒｅｃｖｆｒｏｍ（ｒｅｃｖ）をコールする。コールがＵＤＰソケットに対するもの、即ち、判断ブロック３４２に対して「ｙｅｓ」なら、論理は続いてオペレーション３４６を行い、そこでＵＤＰポートに対するローカルキューが見つけられる。一つの実施例において、オペレーション３４６はローカルＵＤＰポートを見つけることを含む。次に、ＵＤＰポートに対するローカルキューが判断ブロック３４８において調べられ、キューにデータがあるかどうか、即ち、キューサイズがゼロより大きいかどうかを判定する。キューにデータがある、即ち、判断ブロック３４８に対して「ｙｅｓ」なら、論理フローは続いてオペレーション３５０を行い、そこでデータパケットがキューから読み取られる。
【００５６】
キューにデータがない、即ち、判断ブロック３４８に対して「ｎｏ」なら、最もありそうな原因は、キューがまだデータレディー・イベントを処理していないことである。オペレーション３５４において、論理フローはキューのデータレディー・イベントの待機を行う。判断ブロック３５６は待機状態の判定を行う。キューがデータレディー・イベントを返す、従って、データが読み取られるべきキューにある、即ち、判断ブロック３５６に対して「成功」回答なら、ソケット、即ちｒｅｃｖｆｒｏｍコールに戻る。キューがデータレディー・イベントを返さない、即ち、判断ブロック３５６に対して「失敗」回答なら、エラーが返される。しかしながら、発明のもう一つの実施例において、ＬｏｃａｌＰｏｒｔＭｇｒはデータキューに対するローカルポートでなくデータのディスパッチに対する専用のＵＤＰポートを使用する。その実施例では、ｒｅｃｖｆｒｏｍ機能は通常のｒｅｃｖｆｒｏｍ機能をコールする。通常のｒｅｃｖｆｒｏｍは読み取り待機を自動的に処理する。通常のｒｅｃｖｆｒｏｍがＵＤＰデータを返した後、ＬｏｃａｌＰｏｒｔＭｇｒはＵＤＰデータの最初のブロック、即ちトンネルヘッダ情報ブロックを取り去り、リモートアドレスを更新するためにその情報を使用する。
【００５７】
図７Ｅは本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｓｅｌｅｃｔオペレーションの論理フローを図解する論理フローチャート図３６０の１枚目である。一つの実施例において、図７Ｅに図解される方法オペレーションは、ＬｏｃａｔＰｏｒｔＭｇｒが一つ以上のデータ・キュー・オブジェクトを用いてデータディスパッチを実行する実施に適用可能である。図７Ｅに図解されるように、ソケットのＦＤ＿ＳＥＴが３６２において設けられ、あるいは利用可能であり、判断ブロック３６４において、方法はＦＤ＿ＳＥＴ内の全てのソケットがＵＤＰソケットであるかどうかの判定を行う。ＦＤ＿ＳＥＴ内の全てのソケットがＵＤＰソケットでない、即ち、不判断ブロック３６４に対して「ｎｏ」なら、オペレーション３６６において、標準又は通常のｓｅｌｅｃｔ機能がコールされる。ＦＤ＿ＳＥＴ内の全てのソケットがＵＤＰソケットなら、即ち、不判断ブロック３６４に対して「ｙｅｓ」なら、本発明の実施例は、ｓｅｌｅｃｔ機能が、オペレーション３６８により示されるように、ＦＤ＿ＳＥＴを通って送られたローカル・キュー・オブジェクトの全てを見つけることを必須とする。次いで、それはＦＤ＿ＳＥＴ内に指定され、判断ブロック３７０により達成されたあらゆるキュー・オブジェクトを巡回しなければならない。キューがデータにデータがある、即ち、判断ブロック３７２に対して「ｙｅｓ」なら、オペレーション３７４においてそのソケット処理の値が戻るＦＤ＿ＳＥＴにおいて設定される。あらゆるキュー・オブジェクトがチェックされた後、データを有する少なくとも一つのソケットがある、即ち、判断ブロック３７６に対して「ｙｅｓ」なら、一つの実施例においてｓｅｌｅｃｔ機能はコール機能に戻る。しかしながら、どのデータ・キュー・オブジェクトもデータレディーをもっていない、即ち判断ブロック３７６に対して「ｎｏ」なら、ｓｅｌｅｃｔ機能は待ち時間を決定する必要があり、これは図７Ｆの論理フローチャート図３６０の続きに図解される。
【００５８】
図７Ｆは本発明による図７Ｅの論理フローチャート図３６０の続きである。一般的に、待機条件はｓｅｌｅｃｔ機能パラメータとしてコール機能から送られる。タイムアウト・パラメータ構造がＮＵＬＬ、即ち、判断ブロック３７８に対して「ｙｅｓ」なら、オペレーション３８０に示されるように、一つ以上のデータ・キュー・オブジェクトがデータを持つまでｓｅｌｅｃｔ機能は無期限に待つべきであると見なされる。タイムアウト構造が何かＮＵＬＬ以外のもの、即ち、判断ブロック３７８に対して「ｎｏ」であるが、タイムアウト値が０に設定される、即ち、判断ブロック３８２に対して「ｙｅｓ」なら、ｓｅｌｅｃｔ機能は直ちに戻る。この状況において、ｓｅｌｅｃｔ機能はタイムアウト構造において指定された時間まで待つことになる。問題のデータキューの何れかがタイムアウトに先立ち利用可能なデータをもっている、即ち、判断ブロック３７８に対して「ｎｏ」かつ判断ブロック３８２に対して「ｎｏ」なら、論理フローはオペレーション３８４において利用可能なデータを待ち、オペレーション３８６においてコール機能に見つけたことを報告するようにし、次いでｓｅｌｅｃｔ機能が戻る。
【００５９】
図７Ｇは本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのａｃｃｅｐｔオペレーションの論理フローを図解する論理フローチャート図３９０である。論理フローはオペレーション３９２において標準のａｃｃｅｐｔコールをコールすることで始まり、次いで３９４において、リモートＩＰアドレスを保持するデータセット「ｓｔｒｕｃｔ ｓｏｃｋａｄｄｒ」を受信する。判断ブロック３９６において、リモートＩＰ（データセットからの）が実際にローカル・ループバック接続を指定するローカルＩＰであるかどうかが判定される。リモートＩＰがローカルＩＰでない、即ち、判断ブロック３９６に対して「ｎｏ」なら、コールに戻る。リモートＩＰが実際にローカルＩＰ、即ち、判断ブロック３９６に対して「ｙｅｓ」なら、論理フローは引き続きオペレーション３９８においてトンネルヘッダからリモートＩＰアドレスを読み取り（図６Ｂ参照）、オペレーション４００において戻りのリモートＩＰアドレスをそのリモートＩＰアドレスに設定し、次いでオペレーション４０２においてソケット処理、リモートＩＰアドレス及びリモートポートを記録する。本発明の一つの実施例においては、ソケットａｃｃｅｐｔコールの論理フローは典型的にはＴＣＰリダイレクトに対してサーバ側で実行される。
【００６０】
図７Ｈは本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｇｅｔｐｅｅｒｎａｍｅオペレーションの論理フローを図解する論理フローチャート図４１０である。図７Ｇを参照して上で述べられたソケットａｃｃｅｐｔコールと同様に、ソケットｇｅｔｐｅｅｒｎａｍｅに対する論理フローはオペレーション４１２にいて標準のｇｅｔｐｅｅｒｎａｍｅコールをコールすることで始まる。データセット「ｓｔｒｕｃｔ ｓｏｃｋａｄｄｒ」が４１４に設けられ、次いで、ソケット処理がローカル・ループバック接続であるかどうかが判定される。ソケット処理がローカル・ループバック接続でない、即ち、判断ブロック４１６に対して「ｎｏ」ならば、ｇｅｔｐｅｅｒｎａｍｅコールに戻る。ソケット処理がローカル・ループバック接続、即ち判断ブロック４１６に対して「ｙｅｓ」なら、論理フローはリモートＩＰをｓｏｃｋａｄｄｒにリストされたものからリダイレクトされたリモートＩＰに変更するようにする。一つの実施例において、ソケット、即ちｇｅｔｐｅｅｒｎａｍｅコールは主としてＴＣＰリダイレクトに対して実行される。
【００６１】
図７Ｉは本発明の一つの実施例によるＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｂａｃｋｇｒｏｕｎｄ  ｌｉｓｔｅｎｉｎｇオペレーションの論理フローを図解する論理フローチャート図４２０である。準備オペレーション４２２に示されるように、論理フローはスタンバイ又はリスニングオペレーションから始まり、そこでは本発明の実施例はトンネルＴＣＰポート８０のリスニングモニタを維持する。接続要求を受信したら、論理フローは要求がＵＤＰトンネル接続であるかどうか（即ち、接続ヘッダを調べることにより。図６Ａ参照）を判定する。接続がＵＤＰトンネル接続でない、即ち、判断ブロック４２４に対して「ｎｏ」なら、論理フローは「ソケット処理」データセットからの入力を含み、次いで、オペレーション４２８において、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュールのＴＣＰＲｅｄｉｒｅｃｔＭｇｒコンポーネントが所期のローカルＴＣＰポートへのローカル・ループバック接続を行う。オペレーション４３０において、ソケットペアがＴＣＰＲｅｄｉｒｅｃｔＭｇｒの選択リストに追加される。論理フローは更にトンネルポートのモニタを継続して行うようになっている。
【００６２】
判断ブロック４２４において、要求がＵＤＰトンネル接続に対するもの、即ち、判断ブロックに対して「ｙｅｓ」なら、論理フローはＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッドを作成するようになっている。一つの実施例において、ＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッドはトンネル接続を通じて受信されたＵＤＰデータパケットを管理及び処理するために作成される。一つの実施例において、ＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッドはＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュールのもう一つのコンポーネントである。ＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッド（一つの実施例においてはトンネル・ピア又はシステムにつき一つ）はＬｏｃａｌＰｏｒｔＭｇｒと通信してその所期のＵＤＰポートにＵＤＰデータをディスパッチする。スレッドが実行している限り、論理フローは、ＵＤＰデータ入力４３６についてオペレーション４３４と４３８に表されるように、データを読み取り、そのデータを該当するキュー（又はＵＤＰディスパッチポート）に送り出し、あるいはディスパッチするようになっている。クライアントとサーバのアプリケーションの何れかが接続を閉じたら、オペレーション４４０においてクリーンアップが行われ、スレッドを出る。
【００６３】
図８Ａ及び８ＢはＰａｃｋｅｔＤｉｓｔｐａｔｃｈｅｒハンドラ・スレッドとＵＤＰディスパッチポートの実行を図解するために提示される。図８Ａは本発明の一つの実施例によるローカルに開かれたＵＤＰポートを用いてＵＤＰトンネルデータのディスパッチを示す高レベルの模式図５００である。図８Ａはクライアント側５０１からサーバ側５０３へのＵＤＰデータフローを示す。本発明の一つの実施例において、クライアントＨ．３２３アプリケーションは一つ乃至複数のＵＤＰデータポート５０２を開き、そこからリアルタイムのマルチメディアデータが送信される。クライアントＨ．３２３アプリケーションは一つないし複数のＵＤＰデータポート５０２、ソースデータポートを開き、ＵＤＰデータをサーバＨ．３２３アプリケーションの宛先又は送信先ＵＤＰデータポート５１４に送信する。上に述べられた本発明の実施例によれば、ＵＤＰデータはクライアントＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌによりインターセプトされ、一つの実施例では一つのトンネルＴＣＰデータ接続、別の実施例では多数のトンネルＴＣＰデータ接続に伝送される。データストリーム５０４はリアルタイム・トランスポート・プロトコルに従って送信され、サーバＨ．３２３アプリケーションの宛先又は送信先ＵＤＰデータポート５１４に宛てられる。
【００６４】
サーバ側５０３において、トンネルＴＣＰデータ接続はサーバＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ５０８によりインターセプトされる。上に詳述されたように、サーバＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌの実施例はＣｏｎｎｅｃｔｉｏｎＭｇｒモジュール５０８ａ、ＬｏｃａｌＰｏｒｔＭｇｒモジュール５０８ｂ、及びＴＣＰＲｅｄｉｒｅｃｔモジュール５０８ｃを含む。一つの実施例において、一つ以上のトンネルＴＣＰ接続を通じて送信されたＵＤＰデータはＣｏｎｎｅｃｔｉｏｎＭｇｒモジュール５０８ａにより受信され、ＬｏｃａｌＰｏｒｔＭｇｒモジュール５０８ｂにディスパッチされる。もう一つの実施例において、一つ以上のＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッド５１０が作成されてトンネルＴＣＰ接続を通じて受信されたＵＤＰデータを管理する。図７Ｉを参照して上に述べられたように、ＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッド５１０はトンネリングされたＵＤＰデータを読み取り、次いでこれは、一つの実施例ではデータキューに対する、別の実施例では一つ以上のＵＤＰデータポートに対するＬｏｃａｌＰｏｒｔＭｇｒ５０８ｂに送り出される。図８Ａに図解される実施例において、複数のローカルＵＤＰデータポート５１２が開かれ、トンネリングされたＵＤＰデータは複数のローカルＵＤＰデータポート５１２にディスパッチされる。一つの実施例において、ＬｏｃａｌＰｏｒｔＭｇｒ５０８ｂが一つ以上のローカルＵＤＰポートを、宛てられたＵＤＰデータポート５１４に合わせ、それにより、サーバＨ．３２３アプリケーションが宛てられたＵＤＰデータポート５１４のそれぞれからデータをコール又は取得したら、コールされたポート５１４に合ったローカルＵＤＰデータポート５１２に送られたデータが提供される。
【００６５】
図８Ｂは図８Ａに図解されるローカルに開かれたＵＤＰポートを用いるＵＤＰトンネルデータのディスパッチのサーバ側５０３の詳細図である。発明の一つの実施例において、ＵＤＰデータはＴＣＰトンネル接続５１６において受信され、サーバＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ５０８のＣｏｎｎｅｃｔｉｏｎＭｇｒ５０８ａによりインターセプトされる（図８Ａ参照）。ＣｏｎｎｅｃｔｉｏｎＭｇｒ５０８ａはＴＣＰトンネル接続５１６ａ、５１６ｂ、５１６ｃをＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッド５１０にディスパッチする。そして、ＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッド５１０はＬｏｃａｌＰｏｒｔＭｇｒ５０８ｂを通じてＵＤＰデータをディスパッチする。上に述べられたように、ＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッド５１０はＵＤＰデータ及びＬｏｃａｌＰｏｒｔＭｇｒ５０８ｂを読み取り、次いで、ＵＤＰデータをディスパッチする。図解された実施例において、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ５０８（図８Ａ参照）は複数のローカルＵＤＰデータポート５１２を開いており、これらはサーバＨ．３２３アプリケーションにより開かれた送信先又は宛先ＵＤＰデータポート５１４とペアにされる。サーバＨ．３２３アプリケーションが宛てられたＵＤＰデータポート５１４からデータをコール又は受信したら、対応するローカルＵＤＰデータポート５１２内のデータが提供される。一つの実施例において、ローカルＵＤＰデータポート５１２（ディスパッチポートとも呼ばれる）はクライアントＨ．３２３アプリケーションとサーバＨ．３２３アプリケーションの両方に対して透過的である。サーバＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌはＵＤＰデータを管理するためにローカルＵＤＰデータ・ディスパッチポート５１２を作成する。クライアントＨ．３２３アプリケーションとサーバＨ．３２３アプリケーションの両方は一つ乃至複数の宛先又は送信先ＵＤＰデータポート５１４を宛てかつ利用する。
【００６６】
発明の一つの実施例において、一つ乃至複数のトンネルＴＣＰ接続がＵＤＰデータを送信するために開かれる。図８Ｂは、それぞれの接続が上で述べられたように処理される複数のトンネルＴＣＰデータ接続５１６ａ、５１６ｂ、及び５１６ｃを図解する。一つの実施例において、ＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッド５１０が各トンネル・ピア又はクライアントシステムに対して作成される。従って、図８Ｂに図解されるように、三つのトンネルＴＣＰデータ接続５１６ａ、５１６ｂ、５１６ｃに対して一つのＰａｃｋｅｔＤｉｓｐａｔｃｈｅｒハンドラ・スレッド５１０が作成される。それは三つの接続の全てが同じトンネルクライアントシステムからのものであるからである。一つの実施例において、多数のトンネル接続を使用する利点は信頼性と性能の両方を含む。知られているように、ＴＣＰ送信にパケット損失があれば、失われたデータが再送信及び受信されるまで接続は新しいデータの送信を停止することになる。しかしながら、送信と確認応答プロセスはリアルタイム・ストリーミング・アプリケーションの性能に悪影響を及ぼす。一つより多いＴＣＰトンネル接続では、一つの実施例において、データは別のＴＣＰ接続により送信され、遅延される可能性のある一方の接続が再送信を管理する。
【００６７】
最後の論理フローチャートに戻れば、図７Ｊは本発明の一つの実施例によるＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのＴＣＰＲｅｄｉｒｅｃｔＭｇｒ機能の論理フローを図解する論理フローチャート図４５０である。上に詳述されるように、ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュールはＴＣＰＲｅｄｉｒｅｃｔＭｇｒコンポーネントを含む三つのコンポーネントを含み、このＴＣＰＲｅｄｉｒｅｃｔＭｇｒコンポーネントは発明の一つの実施例においてＴＣＰリダイレクト接続の全てを処理する。図７Ｊは本質的にＴＣＰＲｅｄｉｒｅｃｔＭｇｒのランタイムである。
【００６８】
本発明の一つの実施例において、ＴＣＰ接続要求又はデータストリームが作成又は受信される如何なる時点においても、ＷｉｎＳｏｃｋＰｒｏｘｙは全てのＴＣＰリダイレクト接続ペアに対して２００ｍｓｅｃのタイムアウトでｓｅｌｅｃｔをコールする。ｓｅｌｅｃｔのコールはＴＣＰリダイレクトトンネル接続とそのローカルカウンタ・ループバックＴＣＰ接続の全てのペアに対してファイル記述子セット（ＦＤ＿Ｓｅｔ）を作成する。次いで、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒはｓｅｌｅｃｔ待機状態４５２に行き、そこでＦＤ＿ＳＥＴでの何れかのソケットでデータが利用できるのを待つ。ＴＣＰＲｅｄｉｒｅｃｔＭｇｒは何れかのソケットでデータが利用できるのを２００ｍｓまで（タイムアウト）まで待つ。何れかのソケットでの何らかのデータ利用ができる前にタイムアウトが生じたら、４６２でＴＣＰＲｅｄｉｒｅｃｔＭｇは全てのソケットの最新のセットを用いてＦＤ＿ＳＥＴをチェック及び更新することになる。ＴＣＰＲｅｄｉｒｅｃｔＭｇｒスレッドがデータを待っている間、新しいＴＣＰリダイレクト接続が入ってきて、ＣｏｎｎｅｃｔｉｏｎＭｇｒによりＴＣＰＲｅｄｉｒｅｃｔＭｇｒオブジェクトにディスパッチされたかも知れない。その結果、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒスレッドはそのＦＤ＿ＳＥＴを定期的に更新する必要がある。次いで、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒはサイクルの最初４５２に戻る。
【００６９】
４５８で２００ｍｓのタイムアウトの前に利用可能なデータがあれば、４６０でＴＣＰＲｅｄｉｒｅｃｔＭｇｒは読み取り準備のできたデータを有する各ソケットからデータを読み取り、未修正のデータをそのソケットペアの他方のソケットに再送する（ソケットペアはリモートピアからのトンネルＴＣＰ接続に対する一つのソケットとクライアントの所期のＴＣＰポートへの一つのローカル・ループバックＴＣＰ接続から成る）。４５８において入手可能なデータがあることを示すソケットの全てからの全てのデータの後、４６２でＴＣＰＲｅｄｉｒｅｃｔＭｇｒはＴＣＰ接続ペアの最新のセットを用いてそのＦＤ＿ＳＥＴを更新する。そうしてサイクルの最初４５２に戻る。
【００７０】
一つの実施例において、４５２での待機中に、ｓｅｌｅｃｔ機能コールが、一つ以上のソケットが閉じられていることを返したら、ＴＣＰＲｅｄｉｒｅｃｔＭｇｒはそのソケットを除去し、４５４でソケットペア内のそのピアソケットを閉じ、４５６でソケットペアを除去する。次いで、４６２でＴＣＰＲｅｄｉｒｅｃｔＭｇｒはＴＣＰ接続ペアの最新のセットを用いてＦＤ＿ＳＥＴを更新する。次いで４５２でオペレーションはサイクルの最初４５２に戻る。
【００７１】
上の実施例を念頭におけば、発明がコンピュータシステムに記憶されたデータを伴う種々のコンピュータで実行されるオペレーションを採用してもよいことは言うまでもない。これらのオペレーションは物理量の物理的操作を必要とするものである。通常、必ずとは言わないが、これらの量は、記憶、転送、組合せ、比較、あるいは操作可能な電気的又は磁気的な形を取る。更に、行われる操作はしばしば、作成、識別、判定あるいは比較等の用語で言及される。
【００７２】
発明はまた媒体、例えばコンピュータ読み取り可能な媒体上のコンピュータ読み取り可能なコードとして具現化できる。コンピュータ読み取り可能な媒体はデータを保持又は記憶でき、その後にコンピュータシステムにより読み取れる何れかのデータ記憶装置である。コンピュータ読み取り可能な媒体はまたコンピュータコードが具現化された電磁搬送波を含む。コンピュータ読み取り可能な媒体の例はハードドライブ、ネットワーク接続ストーレジ（ＮＡＳ）、リードオンリーメモリー、ランダムアクセスメモリー、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、及び他の光学的、非光学的データ記憶デバイスを含む。コンピュータ読み取り可能な媒体はまた、コンピュータ読み取り可能なコードが分散方式で記憶及び実行されるように、ネットワーク結合されたコンピュータシステムを通じて配信できる。
【００７３】
以上の発明は理解を明確にするためにいくらか詳細に説明したが、添付された特許請求の範囲内で、ある一定の変更及び変形を実施し得ることは明らかであろう。従って、本実施例は制限的ではなく例示的であると考えるべきであり、発明は本願に提示された詳細に限定すべきではなく、添付された特許請求の範囲及びその均等物内で変形できる。特許請求の範囲において、要素及び／又はステップは特許請求の範囲に明示的に述べられない限り、オペレーションの如何なる具体的な順序も言外に含むものではない。
【図面の簡単な説明】
【００７４】
【図１】典型的なＨ．３２３ＴＣＰ／ＵＤＰ接続シーケンスを図解する簡略化された模式図である。
【図２】本発明の一つの実施例によるクライアントとサーバ間のデータフローの高レベルの模式図である。
【図３】発明の一つの実施例によるＨ．３２３クライアントとＨ．３２３サーバ間の通信路を図解する。
【図４】発明の一つの実施例によるＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌモジュールの相対的配置と内容を示す。
【図５】本発明の一つの実施例によるＨ．３２３クライアントとＨ．３２３サーバ間のデータフローを示す。
【図６Ａ】本発明の一つの実施例による接続ヘッダのデータフィールドを説明する表である。
【図６Ｂ】本発明の一つの実施例によるトンネルヘッダのデータフィールドを説明する表である。
【図６Ｃ】本発明の一つの実施例によるトンネルデータの例示的バイトストリームを図解する表である。
【図７Ａ】本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｂｉｎｄオペレーションの論理フローを図解する論理フローチャート図である。
【図７Ｂ】本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｃｏｎｎｅｃｔオペレーションの論理フローを図解する論理フローチャート図である。
【図７Ｃ】本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｓｅｎｄｔｏオペレーションの論理フローを図解する論理フローチャート図である。
【図７Ｄ】本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｒｅｃｖｆｒｏｍオペレーションの論理フローを図解する論理フローチャート図である。
【図７Ｅ】本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｓｅｌｅｃｔオペレーションの論理フローを図解する論理フローチャート図の１枚目である。
【図７Ｆ】本発明の一つの実施例による図７Ｅの論理フローチャート図の続きである。
【図７Ｇ】本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのａｃｃｅｐｔオペレーションの論理フローを図解する論理フローチャート図である。
【図７Ｈ】本発明の一つの実施例によるソケット、即ちＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのｇｅｔｐｅｅｒｎａｍｅオペレーションの論理フローを図解する論理フローチャート図である。
【図７Ｉ】発明の一つの実施例によるＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのバックグラウンド・リスニングオペレーションの論理フローを図解する論理フローチャート図である。
【図７Ｊ】発明の一つの実施例によるＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌのＴＣＰＲｅｄｉｒｅｃｔＭｇｒ機能の論理フローを図解する論理フローチャート図である。
【図８Ａ】発明の一つの実施例によるローカルに開かれたＵＤＰポートを用いたＵＤＰトンネルデータのディスパッチを示す高レベルの模式図である。
【図８Ｂ】発明の一つの実施例によるローカルに開かれたＵＤＰポートを用いたＵＤＰトンネルデータのディスパッチのサーバ側の詳細図である。
【符号の説明】
【００７５】
１５２  クライアント
１５４  サーバ
１５６  Ｈ．３２３クライアント
１５６ａ、１５６ｂ  ＴＣＰポート
１５６ｃ〜１５６ｆ  ＵＤＰポート
１５８  ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ
１６０  ＴＣＰポート８０
１６０ａ  多重化装置
１６０ｂ、１６０ｃ  ＴＣＰポート８０
１６２  クライアントＷｉｎｓｏｃｋ／ＴＣＰ−ＩＰスタック
１６４  サーバＷｉｎｓｏｃｋ／ＴＣＰ−ＩＰスタック
１６６  ＷｉｎＳｏｃｋＰｒｏｘｙ．ｄｌｌ
１６８  ＴＣＰポート８０
１６８ａ  ＵＤＰトンネル分波器
１６８ｂ  ＴＣＰリダイレクト
１７０  ＵＤＰキュー
１７２  Ｈ．３２３サーバ
１７２ａ、１７２ｂ  ＴＣＰポート
１７２ｃ〜１７２ｆ  ＵＤＰポート
１８０  Ｈ．３２３クライアント
１８２  ファイアウォール
１８４  Ｈ．３２３サーバ
１８６  インターネット
【図１】
2006304300.tif 000003
【図２】
2006304300.tif 000004
【図３】
2006304300.tif 000005
【図４】
2006304300.tif 000006
【図５】
2006304300.tif 000007
【図６Ａ】
2006304300.tif 000008
【図６Ｂ】
2006304300.tif 000009
【図６Ｃ】
2006304300.tif 000010
【図７Ａ】
2006304300.tif 000011
【図７Ｂ】
2006304300.tif 000012
【図７Ｃ】
2006304300.tif 000013
【図７Ｄ】
2006304300.tif 000014
【図７Ｅ】
2006304300.tif 000015
【図７Ｆ】
2006304300.tif 000016
【図７Ｇ】
2006304300.tif 000017
【図７Ｈ】
2006304300.tif 000018
【図７Ｉ】
2006304300.tif 000019
【図７Ｊ】
2006304300.tif 000020
【図８Ａ】
2006304300.tif 000021
【図８Ｂ】
2006304300.tif 000022