(57)【要約】  システムレベルで動作するポートリスニングサービスが静的ポートで聴取するように割り当てられている。静的ポートはセッションレベルで動作する複数のアプリケーションに関連した複数の固有のＩＤにインデックスを付けることができる。サーバアプリケーションはクライアントに固有の接続ＩＤ、サーバのＩＰアドレス、接続のための静的なポート番号を提供する。クライアントが固有の接続ＩＤを参照して接続を行うと、アプリケーションがセッションレベルで動作するように、ポートリスニングサービスはアプリケーションがセッションレベルで更に動作するように接続のための対応するソケットを適切なアプリケーションインスタンスに転送することができる。このようにして、ポートリスニングサービスは、セッションレベルで動作している複数の異なったアプリケーションに１つの静的ポート用の接続サービスを供給することができる。
2009508260.tif 000002
【特許請求の範囲】
【請求項１】
セッションレベルで動作する複数のアプリケーションと、ネットワークを介する１または複数のクライアントコンピュータシステムとの間の通信を提供するように構成された共有コンピュータシステムにおいて、単一のポートを通して共有コンピュータシステム上で前記複数のアプリケーションにネットワーク接続を提供する方法において、
第一の接続識別子を第一のアプリケーションに、第二の接続識別子を第二のアプリケーションに関連付ける動作であって、前記第一と第二のアプリケーションは、セッションレベルで動作している動作と、
ポートと関連付けられたポート番号、前記共有コンピュータシステム用ネットワークアドレス、および前記第一の接続識別子を含むクライアント接続要求を受信する動作と、
前記クライアント接続要求を前記第一のアプリケーションに転送し、前記第一のアプリケーションが前記ポートを通して前記クライアントと接続する動作と、
前記ポート番号に一致する前記ポートを通して前記第二のアプリケーションへ異なったクライアント接続を提供する動作と
を備えたことを特徴とする方法。
【請求項２】
前記の異なったクライアント接続を提供する前に、前記異なったクライアント接続のための異なったクライアント接続要求を受信する動作であって、前記異なったクライアント接続要求は、前記ポート番号を含むが、前記第一または第二の接続識別子のいずれかを含まない動作をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記異なったクライアント接続を、ペンディング接続として記憶する動作をさらに備えたことを特徴とする請求項２に記載の方法。
【請求項４】
前記異なったクライアント接続用に、第二の接続識別子を受信する動作をさらに備えたことを特徴とする請求項３に記載の方法。
【請求項５】
前記第二の接続識別子と関連付けられた接続ソケットを、前記第二のアプリケーションに転送する動作をさらに備えたことを特徴とする請求項４に記載の方法。
【請求項６】
前記第一の接続識別子と前記第二の接続識別子を、１または複数のクライアントにＸＭＬ文書として送信する動作をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項７】
接続ソケットを、前記第一の接続識別子に関連付ける動作をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項８】
前記第一のアプリケーションに前記接続を転送することは、前記第一のアプリケーションに前記接続ソケットの制御を提供する動作を含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記ポート番号と関連付けられた前記ポートは、静的ポートであることを特徴とする請求項１に記載の方法。
【請求項１０】
クライアント接続要求を受信して前記第一のアプリケーションに前記クライアント要求を転送する動作は、システムレベルで動作するリスニングサービスにより実行されることを特徴とする請求項１に記載の方法。
【請求項１１】
前記第一と第二のアプリケーションを格納する前記共有コンピュータシステムは、クライアントコンピュータシステムであることを特徴とする請求項１に記載の方法。
【請求項１２】
次のクライアント接続要求は、パケットの初期のセットでは前記ポートと関連したいかなる接続識別子も提供できないが、前記ポートで次のクライアント接続要求を受信する動作と、
前記パケットの初期セット内に接続前データがないことを確認すると、前記クライアント接続要求を拒否する動作と
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１３】
複数の固有の接続識別子を前記ポート番号と関連付けられた前記ポートに割り当てる動作であって、前記複数の固有の接続識別子は、少なくとも前記第一と第二の接続識別子を有する動作をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１４】
前記第一の接続識別子は、前記クライアント接続要求を送信するクライアントからのユーザ名または電子メールアドレスのいずれかを含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記第一のアプリケーションはいつでも、１または複数のクライアントと通信できるという指示を少なくとも前記第一のアプリケーションから受信する動作をさらに備えたことを特徴とする請求項１３に記載の方法。
【請求項１６】
前記第一の接続識別子を前記第一のアプリケーションに割り当てる動作と、
少なくとも前記第一の接続識別子と前記ポート番号に関連付けられた前記ポートとを含む接続前データを前記第一のアプリケーションに送信する動作と
をさらに備えたことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記第一の接続識別子と前記第一のアプリケーションの識別子とを、前記第一のアプリケーションにより生成されたコンポーネントオブジェクトと関連付ける動作をさらに備え、
前記コンポーネントオブジェクトは、セッションレベルで動作する前記第一のアプリケーションと、システムレベルで動作するリスニングサービスとの間の通信を提供するように構成されていることを特徴とする請求項１６に記載の方法。
【請求項１８】
共有コンピュータシステムのセッションレベルで動作する複数のアプリケーションと通信するように構成されたコンピュータシステムにおいて、前記共有コンピュータシステムで単一のポートを通して前記複数のアプリケーションと通信を行う方法であって、
少なくともポート番号と第一の接続識別子を含む第一の呼び出しを受信して、サーバコンピュータシステムで第一のアプリケーションと通信を行う動作と、
少なくともポート番号と第二の接続識別子を含む第二の呼び出しを受信して、前記サーバコンピュータシステムで第二のアプリケーションと通信を行う動作と、
前記ポート番号を通して前記サーバ上で前記第一と第二のアプリケーションと通信を行い、前記クライアントがネットワーク上で、前記サーバの前記同じ静的ポートを通して複数のアプリケーションと通信するステップと
を備えたことを特徴とする方法。
【請求項１９】
前記ポート番号を通して前記第一と第二のアプリケーションと通信を行うステップは、
前記第一の接続識別子を含む前記第一の接続要求を前記サーバに送信する動作と、
前記第二の接続識別子を含む前記第二の接続要求を前記サーバに送信する動作と
をさらに備えたことを特徴とする請求項１８に記載の方法。
【請求項２０】
セッションレベルで動作する複数のアプリケーションと、ネットワークを介する１または複数のクライアントコンピュータシステムとの間の通信を提供するように構成されたコンピュータシステムにおいて、実行時には、前記共有コンピュータシステム上の１または複数のプロセッサに、前記複数のアプリケーションが１つの静的ポートを通して接続を提供する方法を実行させる、コンピュータ上に記憶されたコンピュータで実行可能な命令を有するコンピュータプログラム製品において、
第一の接続識別子を第一のアプリケーションに、第二の接続識別子を第二のアプリケーションに関連付ける動作であって、前記第一と第二のアプリケーションは、セッションレベルで動作していること、
ポートと関連付けられたポート番号、前記共有コンピュータシステム用ネットワークアドレス、および前記第一の接続識別子を含むクライアント接続要求を受信すること、
前記クライアント接続要求を前記第一のアプリケーションに転送し、前記第一のアプリケーションが前記ポートを通して前記クライアントと接続すること、および、
前記ポート番号に一致する前記ポートを通して前記第二のアプリケーションへ異なったクライアント接続を提供すること
を備えたことを特徴とするコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のプロセスにおけるポートの共有に関する。
【背景技術】
【０００２】
コンピュータ化されたシステムの普及が進むにつれて、大規模なものでも小規模なものでもネットワーク上でファイルやコンピュータシステムのリソースの分散化が要求される。一般的に、コンピュータシステムとその関連装置は、様々な理由からネットワーク上で情報のやりとりを行うが、例えば個人的な電子メールの交換、商品の購買、会計情報の提供等がある。コンピュータシステムとその関連アプリケーションがますます高度なものになるほど、ネットワーク上でのデータやリソース共有に関連する難題も増えてくることは想像に難くない。
【０００３】
ネットワーク内にリソースを分散する現行のいくつかの方法は、１または複数のクライアントとリソースを共有してローカルにはリソースをインストールしない、集中ネットワークサーバを含む集中コンピューティングシナリオを含む。この種の機能性のために使用されているプロトコルの１つに、リモートデスクトッププロトコル（「ＲＤＰ」）がある。リモートデスクトッププロトコルを使用すれば、集中ネットワークサーバはネットワーク上にある他のクライアントとデータやリソースを共有することができる。クライアントはリソースがあたかもローカルにインストールされているようにして、リソースとのやりとりが行なえる場合もある（例えば、マウス、キーボードにイベントを送信する）。クライアントのコンピュータシステムとネットワークサーバとのやりとりは、あたかもクライアントのコンピュータシステムが自身にインストールされているリソースでローカルにデータ処理しているかのようにシームレスに行われるのが理想である。
【０００４】
上記の集中化共有モデルとある面で類似している別のタイプのシステムには、ネットワーク上で他のクライアントコンピュータシステムとアプリケーションデータを共有するように構成されたサーバ（あるいは「送信」）コンピュータシステムを含む。この例では、サーバは、１または複数のクライアント（あるいは「受信」）コンピュータシステムとデータビューの共有に使用する「コラボレーションＡＰＩ」のようなＡＰＩ（Application Program Interface）を起動する。クライアントのコンピュータシステムは、ローカルで共有データ処理して表示することが可能であり、それは上述の集中コンピューティングシナリオと類似している。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
残念ながら、このようなタイプのシステムには潜在的に困難な問題が多数あり、アプリケーションにより作成されたデータを、ネットワーク上で比較的少数以上のクライアントコンピュータシステムと共有することを困難にしている。例えば、共有コンピュータシステムがデータ共有のアプリケーションを開始すると、サーバアプリケーションは共有コンピュータシステムにてポートリスナーを開始し、呼び出されたクライアントと通信して、そのポートを通じて接続する。呼び出された様々なクライアントは、このポートを通じてそのサーバアプリケーションに接続できる。残念ながら、サーバアプリケーションが異なれば、同じポート上に別のリスナーをたてることは除外されてしまい、異なったネットワーク接続を受信することになる。
【０００６】
ポート当たりアプリケーションリスナーが典型的に１人しかいない理由の１つは、ＴＣＰ（Transmission Control Protocol）の事情により、接続を開始するのに使用するデータがＩＰ（Internet Protocol）アドレスとコンピュータポート番号だけということがあげられる。単一のポートを通して接続データを受信する際、ネットワークサーバがアプリケーションを区別するためには、一般的にこれだけでは十分な情報ではない。特に、たとえ別のクライアントが別のアプリケーションでリザーブされた単一のポートでアプリケーションの別のインスタンスに接続しようと試みても、サーバができるのはクライアントの接続要求データを最初にリザーブしていたアプリケーションのインスタンスに送付することだけであろう。
【０００７】
１つのアプリケーションだけが典型的に１つの所与のポートをリザーブする別の理由は、上述のようにポートリスナーを開始する際、所与のアプリケーションはセッションレベル（例えば、コンピュータアクセスの限られたレベル）で動作している可能性があるからである。セッションレベルの実行は、かなり限定された動作レベルであり、コンピュータシステムの他のコンポーネントに対するアプリケーションの露出を最小化している。システムレベル（例えば、コンピュータ全体へのアクセス）で操作すると、サーバに対して動作責任が生じるので、一般的にセッションモードでアプリケーションを動作させるのが望ましい。例えば、システムレベルでアプリケーションを実行すると、アプリケーションはサーバ上の複数の異なったポートに制限なくアクセスすることはできるが、アプリケーションの危険要素（例えば、バグ）により、サーバ全体を危険にさらす可能性がある。
【０００８】
代案として異なったアプリケーションをセッションレベルの動作のままにすることも考えられるが、同じ静的ポートに由来する異なった動的ポートを単に開放しておくことも考えられる。しかしながら動的ポートは、ファイアウォール内で発見したり管理することが難しいので、ネットワークによっては利用できないことがよくある。更に、ネットワーク管理者は、動的ポートを禁止するだけでなく、同様の理由によりセキュリティを気にする余り、第一に、利用できる静的ポート数を制限してしまう。このためアプリケーションが異なると、利用可能なポートすべてがリザーブされている場合には、サーバの別の異なったポートを単に開放するだけでも除外されてしまう場合がある。
【０００９】
従って、現在のリソース共有技術には取り組むべきたくさんの難題がある。
【課題を解決するための手段】
【００１０】
本発明を実施すれば、セッションレベルでアプリケーションを実行しながらも、同一の静的ポートを通して異なったアプリケーションを区別できるシステム、方法、コンピュータプログラム製品の技術に関する上記の１または複数の問題を解決する。特に、セッションで動作している１または複数のサーバアプリケーション（およびその異なったインスタンス）は、対応する１または複数の固有の接続識別子（「ＩＤ」）により登録可能であり、多数の固有の接続ＩＤをポートと関連付けることができる。システムレベルで動作しているポートリスナーは、割り当てられたポートを通してクライアントの接続を受信すると固有の接続ＩＤを聴取することができる。固有の接続ＩＤを認識すると、ポートリスナーはセッションレベルで動作している対応するアプリケーションに接続用ソケットを渡すことが可能になり、固有の接続ＩＤで登録される。
【００１１】
例えば、単一のポートを通して複数のアプリケーションにネットワーク接続を提供するサーバか共有コンピュータの観点からの方法は、第一の接続識別子を第一のアプリケーションに関連付け、第二の接続識別子を第二のアプリケーションに関連付けることを含むことができる。この場合、第一と第二のアプリケーションはセッションレベルで動作している。この方法には、ポートにはポート番号、共有コンピュータシステムにはネットワークアドレス、および第一の接続識別子を含むクライアントの接続要求を受信することも含むことができる。更に、この方法はクライアントの接続要求を第一のアプリケーションに転送することを含むこともでき、そのポートを通して第一のアプリケーションがクライアントに接続することができる。更にまた、この方法は、ポート番号に対応するポートを通して異なったクライアント接続を、第二のアプリケーションに提供することを含むこともできる。
【００１２】
クライアントの観点から本発明を実行する場合の別の方法では、第一の呼び出しを受信して、サーバコンピュータシステムにて第一のアプリケーションと通信することを含むことができる。第一の呼び出しには少なくともポート番号と第一の接続識別子が含まれる。この方法は、第二の呼び出しを受信してサーバコンピュータシステム上で第二のアプリケーションと通信することも含まれ、第二の呼び出しもまた少なくともポート番号と第二の接続識別子を含んでいる。クライアントはポート番号を通してサーバ上で第一と第二のアプリケーションと通信するステップを行うことが可能であり、特に同じ静的ポートを通して多数のアプリケーションと通信をするようになる。
【００１３】
この要約は、概念の抽出を単純な形で紹介するために提供するものであり、以下の発明の詳細説明にて更に説明を加える。この要約は、請求された発明の対象の主要な特徴あるいは本質的な特徴を確認するためのものではなく、また請求された発明の対象の範囲を判定する際の補助用に使用されるものでもない。
【００１４】
本発明のさらなる特徴や利点は以下に説明するが、一部は説明だけで明確になるし、あるいは発明を実施することにより理解することができるものもある。本発明の特徴や利点は、特に添付の請求項内で指摘している機器とその組合せによって、実現し獲得することができる。本発明の様々な特徴は以下の記述や添付の請求項から更に明確になる、あるいは以下に説明する発明の実施により理解することができる。
【００１５】
上記およびその他の本発明の利点や特徴を得ることかできる方法を説明するために、添付図面に描かれている具体的な実施形態を参照することにより上記では簡単に説明した本発明についてさらにしく説明する。このような図面は発明の典型的な実施形態を描くだけであり、発明の範囲を制限するものでないが、添付図面を使用することにより、本発明は特異性と詳細を加味して記述し、説明することができる。
【発明を実施するための最良の形態】
【００１６】
本発明の実現範囲は、アプリケーションをセッションレベルで実行していても、同じ静的ポートを通して異なったアプリケーションと区別するシステム、方法、コンピュータプログラム製品に及ぶ。特に、セッションで動作している１または複数のサーバアプリケーション（および異なったそのインスタンス）は、対応する１または複数の固有の接続識別子（「ＩＤ」）に登録することが可能であり、その複数の固有の接続ＩＤはポートと関連付けすることができる。システムレベルで動作しているポートリスナーは、割り当てられたポートを通してクライアントの接続を受信する際、固有の接続ＩＤを聴取することができる。固有の接続ＩＤを認識すると、ポートリスナーは、セッションレベルで動作している対応するアプリケーションの接続のためのソケットを渡すことができて、固有の接続ＩＤに登録される。
【００１７】
以下の説明と特許請求の範囲から更によく理解されるように、重大なセキュリティの懸案事項には配慮を続けながら、これらおよび他の特徴はネットワーク通信にこれまでよりも大きな柔軟性を提供している。例えば、ネットワーク管理者は、動的なポート割り当てをしないで同じ静的ポートを通して通信する、あるいはシステムレベルでこれらのネットワークアプリケーションを動作させるいくつかのネットワークアプリケーションを有することができる。ある面では、このことにより、ネットワーク通信から重要なアプリケーションが除外されてしまわないかという不当な心配をせずに、ネットワーク管理者は、ポート数をかなり制限しておくことができる。更に、ネットワークアプリケーションは、セッションレベルの動作で通信ができるので１つのアプリケーションに対する問題がシステム全体に移転することの心配は最小限である。
【００１８】
図１Ａは、システムがどうようにして本発明の態様に従って動作するかの１つの概要例を示す。特に、図１Ａは、アプリケーション１１５とアプリケーション１２０が各々同じ静的ポート１４０を通して対応する異なったクライアント１４５とクライアント１５０とが通信することを示す。アプリケーション１１５とアプリケーション１２０がこのようにできるのは、少なくとも一部は各々のアプリケーションが個別の対応するネットワーク通信ソケット１９０、１９５にそれぞれ関連付けられているからである。
【００１９】
特に、通信ソケット１９０、１９５は、固有の接続識別子（「ＩＤ」、ここでは「固有のＩＤ」とも呼ぶ）と関連付けられており、双方とも同じ静的ポート１４０を使用するように登録されている。クライアントが明確に識別可能であり動作させることができる所与のアプリケーションのインスタンスだけがある場合のように、固有のＩＤがクライアントのユーザ名または電子メールアドレスを含むことができる。固有の接続ＩＤがランダムに作成した数字である場合もある。とにかく、ポート１４０がクライアント１４５からアプリケーション１１５に向けられたＴＣＰ通信を受信すると、ポート１４０にてポートリスニングサービス（図１Ａの１３５）により開かれたリスナーは、接続ＩＤを使用してそのクライアント通信をアプリケーション１１５かアプリケーション１２０（または、図示していない他のアプリケーション）に伝えるか否かを確認することができる。
【００２０】
図１Ｂは、セッションレベルでの動作を維持しながら、複数のアプリケーションがサーバ上でどのようにリスニングサービスに登録することができるかを更に詳細に示した概略図である。事前問題としては、以下の説明や請求項は頻繁に「サーバ」と呼んでいるが、それは一例であって限定するものではないことは理解されよう。特にサーバ１００は普通に理解されているようなネットワークサーバである必要はなく、ネットワークを介して別のクライアントコンピュータシステムとデータ共有することにより、コンピュータシステムを共有するように動作している単なる別のクライアントコンピュータシステムであってもよい。
【００２１】
図１Ｂにより、サーバ（あるいは「共有コンピュータ」）１００が、少なくとも動作のセッションレベル１０５（すなわち、コンピュータアクセスの限定レベル）と動作のシステムレベル１１０（例えば、「セッション０」）とを備えることを示す。一般的に動作のセッションレベルとは、コンピュータ上でアプリケーションが典型的に動作するモードであり、動作の所与の「セッション」に対する限定されたパラメータ内でメモリとハードウェアへのアクセスが制限される。一方、動作のシステムレベルとは、コードがコンピュータシステム内のすべてのハードウェアとメモリに直接アクセスできるようにする処理モードである。
【００２２】
図１Ｂは、サーバ１００がセッションレベル１０５で動作するサーバアプリケーション１１５、１２０（アプリケーション１２０は、アプリケーション１１５の別のインスタンス、あるいは全く別のアプリケーションであることができる）を含むことを示す。アプリケーション１１５、１２０は、サーバ１００にインストールできる複数のサーバアプリケーションの単なる例であり、単一の静的ポートを通して通信しようとするサーバ１００上のサーバアプリケーションはもっと沢山ある。アプリケーション１１５，１２０の例としては、一般的なワードプロセッシング、スプレッドシートプログラム、データベースプログラム等と同様に、サーバ１００から１または複数の他のクライアントにデータビューをブロードキャストするネットワーク表示プログラムも含まれる。
【００２３】
図１Ｂは、サーバ１００がポートリスニングサービス１３５を含んでいることを更に示す。一実施例では、サーバ１００がスタートアップ時あるいは初期起動時にポートリスニングサービス１３５を開始するが、その際リスニングサービス１３５はシステムレジストリから任意の適切な構成データ（図示せず）を読み込む。一般的に、リスニングサービス１３５は、システムレジストリ（図示せず）で指示された多くの静的ポートへのアクセスを保証するために、システムレベル１１０で動作しながらこれらの様々な起動関数を実施する。特に、サーバ１００は、例えば図１Ａのポート１４０のような１または複数の静的ポートを聴取するようにリスニングサービス１３５を割り当てる。更に、サーバ１００は、複数の他の静的ポート（図示せず）を聴取するようにリスニングサービス１３５を割り当てることができる。例えば、内部ネットワークと外部ネットワークにサービスを行うネットワークカードのような複数のネットワークカードを搭載したコンピュータシステムは、両方のカードおよび両方のネットワーク用の複数の静的ポート上で同じリスニングサービスを開始する場合もある。所与のポートを介して通信する必要があるサーバアプリケーションが開始されると、そのサーバアプリケーションは、適切なポートリスニングサービス（例えば、１３５）に「レディ（ready）」メッセージ（例えば、１２３）を送信することができる。レディメッセージは、多くの事象を発生させることができる。例えば、一実施例では、レディメッセージによりリスニングサービスが接続ＩＤアプリケーションプログラムインタフェース（ＡＰＩ）（図示せず）を呼び出し、それが固有の接続ＩＤを生成して、それがランダムに作成した数のように任意の適切で安全な識別子であることができる。この接続ＩＤは、システムメモリ中に記憶されてリスニングサービスに関連して接続ＩＤインデックス１３０の中で参照される。例えば、リスニングサービスは、この固有の接続ＩＤを接続ＩＤ  ＡＰＩから取り出して、この接続ＩＤを、接続ＩＤインデックス１３０のような適切な接続ＩＤインデックスまたはテーブル内のアプリケーション用の識別子に関連付ける。
【００２４】
特に、サーバアプリケーション１２０は、レディメッセージ１２３をポートリスニングサービス１３５に送信するが、プロセス最中のサーバアプリケーション１１５は、レディメッセージ１１３を既に送信していることを図１Ｂに示す。一般的に、サーバアプリケーションは、ソケット（例えば、図１Ａ、図１Ｄの１９０、１９５）を通してレディメッセージを送信し、サーバ１００がソケットを制御してそれを提供する際に、サーバアプリケーションが最終的に使用する。メッセージを送信する際、サーバアプリケーションにはアプリケーション用識別子が含まれており、それは生成した接続ＩＤと関連付けることができる。例えば、メッセージ１１３は、アプリケーション識別子「Ａｐｐ１１５」を含んでいるが、メッセージ１２３はアプリケーション識別子「Ａｐｐ１２０」を含むことを図１Ａに示す。
【００２５】
レディメッセージは、適切なリスニングサービスにコンポーネントオブジェクト、あるいはそれと等価なものを設定して、サーバ１００のシステムレベル１１０およびセッションレベル１０５の間のインタフェースになることができる。一実施例では、これはコンポーネントオペレーティングモデル（ＣＯＭ）であり、別の実施例ではこのコンポーネントオブジェクトは、パイプと呼ばれるリモートプロシージャコール（ＲＰＣ）メカニズム、あるいは任意の他のプロセス間通信メカニズムである。いずれにせよ、ポートリスニングサービス１３５はコンポーネントオブジェクト１１５を収容しており、それにはアプリケーション１１５用識別子（例えば、「Ａｐｐ１１５」）とインデックス１３０にある固有の接続ＩＤ１６０との両方へ参照することが含まれ、接続ＩＤ  ＡＰＩにより生成されることを図１Ｂに示す。
【００２６】
生成されたコンポーネントオブジェクトは、この固有のＩＤをサーバアプリケーションに返して、クライアント接続時に後で使用することができる。例えば、図１Ｂはコンポーネント１５５がメッセージ１１７をアプリケーション１１５に送信するが、メッセージ１１７には固有のＩＤ１６０が含まれていることを示す。場合によっては、メッセージ１１７は、他のクライアントとの接続に使用されるネットワークアドレスとポート番号（すなわちポート１４０）を含むこともできる。しかしながら、ごく一般的には、接続前データは少なくともポート１４０に関連付けられた固有の接続ＩＤ１６０とポート番号（図示せず）を備えることができる。上述のように、サーバアプリケーションは、究極的には接続前データをクライアントに送信する。
【００２７】
例えば、図１Ｃにおいてアプリケーション１１５は、呼び出しメッセージ１６３をクライアント１４５に送信するが、呼び出しメッセージ１６３には接続前データ１７０が含まれることを示す。アプリケーション１１５は、必ずしもこの接続前データ１７０を送信する特別なステップを事前に行う必要はない。具体的には、サーバが実際にクライアントに送信しなくても、クライアント１４５が接続前データ１７０内で発見した識別子を既に知っている実施例もある。例えば、クライアントコンピュータ名（アプリケーション１１５には既知である）またはクライアント１４５がログインしているユーザのユーザ名に識別子を基づかせるなど、よく知られた規則を確立することにより、識別子を完成させることができる。サーバは、何らかの事前に確立したプロトコルにより、ポートリスニングサービス１３５を通して接続を受け付けるアプリケーション１１５などの適切なアプリケーションにユーザ名を関連付けることがわかる。
【００２８】
図１Ｃは、アプリケーション１２０が呼び出しメッセージ１６７をクライアント１５０に送信するが、呼び出しメッセージ１６７には接続前データ１７５が含まれていることを示す。一般的に、メッセージ１６３、１６７は、電子メール、インスタントメッセージング、何らかの他のネットワーク通信形式等、任意の種類のデータ通信を備えることができる。少なくとも一実施例では、メッセージ１６３、１６７は、対応するクライアント１４５、１５０にインストールされたコラボレーションＡＰＩ（図示せず）にストリームされるＸＭＬ（eXtensible Markup Language）文書を備える。一実施例において、接続前データ、特に固有の接続ＩＤ１６０、１６５は、ベース６４テキストとして更に提供されている。
【００２９】
一般的に、所与のクライアントアプリケーションは、サーバ１００と通信するための返信ネットワークアドレスおよびポート番号を確認する以外には、恐らく受信した所与の接続前データを読み出し、解析、処理するか、そうでなければ解釈する必要はない。場合によっては、クライアントは、単に接続前データを使用して普通に使用されている静的ポートを通して特定のアプリケーションに接続することもできる。例えば、１つの所与のクライアントは、いくつかの異なる呼び出しメッセージを同じサーバ上で異なるサーバアプリケーションから受信することができる。そのクライアントの使用法が正しければ、異なった組合せの接続前データの各々によって、クライアントは同じサーバ上の同じ静的ポートを通して、対応する異なったサーバアプリケーション接続が可能となる。
【００３０】
例えば、図１Ｄはクライアント１４５がネットワーク１０３を介して接続要求１８０を送信し、サーバ１００との接続要求をするが、接続要求１８０には接続前データ１７０が含まれていることを示す。上述のように、この接続前データは、サーバ１００のネットワークアドレス、ポート１４０のポート番号、以前アプリケーション１１５より送信された固有の接続ＩＤ１６０を含む。これらのデータは各々、接続要求をポートの背後にある適切なアプリケーションに特に割り当てるのに使用することができる。例えば、ネットワークアドレスは、サーバ１００が受信するメッセージ１８０の経路情報を提供し、ポート番号は、サーバ１００への特定の入力点を確認し、固有のＩＤ１６０は、接続を取り扱う際使用するアプリケーションの識別を提供している。
【００３１】
例えば、図１Ｄにおいて、受信時にポート１４０のリスニングサービス１３５（例えば、リスニングサービス１３５により割り当てられた図示しないリスナーにより）は、ソケット１９０をアプリケーション１１５に渡すが、ソケット１９０は接続要求１８０で提供された接続ＩＤ１６０に対応することを示す。一実施例では、この転送にソケット１９０の取り扱いをアプリケーション１１５に渡すことを含むことができる。したがって、アプリケーション１１５は、ソケット１９０の制御を行い、ポート１４０を通してクライアント１４５（および接続要求で固有のＩＤ１６０を送出している任意の他のクライアント）と自由に通信することができる。適切な通信プロトコルであればどのようなものでもアプリケーションとリモートクライアントの間でこの通信を行うことが可能であるが、普通に使用されているプロトコルの中にはＲＰＣ（Remote Procedure）と同様に、ＲＤＰ（Remote Desktop Protocol）を含むことができる。
【００３２】
このように、複数のアプリケーションは、このクライアントまたは任意の他のクライアントとポート１４０を通して通信することができる。けれども、そうするためには、この接続には各々固有の接続ＩＤがそれぞれ含まれる必要があるので、異なったアプリケーション、およびアプリケーションが同じでも異なったインスタンスを区別することができる。例えば、図１Ｄは、クライアント１５０がネットワーク１０３を介してサーバ１００に接続要求１８３を送信することも示す。この場合、接続要求１８３は、いかなる接続前データも含まず、したがって一般のＴＣＰ通信で必要とされるネットワークアドレスとポート１４０に対するポート番号だけ含んでいることが多い。接続要求１８３は、いかなる接続前データも含まないので、リスニングサービス１３５は、アプリケーションにソケットを提供できない。むしろ図１Ｄは、リスニングサービス１３５がクライアント１５０のためのソケットを「ペンディング接続」１８５の格納場所に渡すのを示す。
【００３３】
具体的には、リスニングサービス１３５は、ポート１４０を通してリスニングサービス１３５とクライアント１５０との間で一時的なネットワーク接続を可能にするが、クライアント１５０がこのデータを提供するまではいかなるアプリケーションとの通信も許可しない。リスニングサービス１３５が接続を中断したり、あるいは単に接続前データを受信するまで一定の時間待つ場合もある。いったんクライアント１５０がこの接続前データ（例えば、データ１７５）を提供すると、リスニングサービス１３５は、固有のＩＤが正しいか否かを判定することができ、もし正しければその固有ＩＤのソケットをアプリケーション１２０のような適切なアプリケーションに渡す。
【００３４】
従って、図１Ａから図１Ｄは、複数のアプリケーションのセッションレベルでの動作を可能にして同じ静的ポートを通して通信するのに使用できる多数の異なるコンポーネントや構成図を示す。上記で確認したように、このようなコンポーネントや構成図によりこの機能が使用できるのは、少なくとも一部は接続を特定のアプリケーションに関連付けるために使用できる接続前データを追加で使用しているためである。複数のサーバアプリケーションが同じポートを使用できることに加えて、この機能は、ある種のサービス妨害（ＤＯＳ）型攻撃を抑制するのにも使用することができることがわかる。
【００３５】
具体的には、ＤＯＳのいくつかの種類は、外部の者がネットワーク接続要求によりコンピュータシステムを過負荷状態にし、最終的にはコンピュータシステムをシャットダウンして起こる可能性があり、場合によっては、外部の者にコンピュータ上のシステムレベル情報を変えさせてしまうこともある。接続前データを含まない接続要求では、サーバアプリケーションへの接続に対するソケットの制御を行うリスニングサービス１３５にはならないので、上述のコンポーネントはこの種の攻撃を抑制するのに役立てることができる。むしろ各接続は、接続要求の第一のパケットの中に接続前データが見つからないと明白に拒否されるか、あるいはペンディング接続ストア１８５の中で、ある一定時間保管してから捨てられる。従って、本発明を実施すると多数の有用なセキュリティの特徴を提供することができる。
【００３６】
上記に加えて、本発明の実施例はある特定の方法を行うための１または複数の機能ステップと、それに対応する機能的でない動作により記述することもできる。具体的には、図２と図３は、サーバの単一の静的ポートを通して、複数のサーバアプリケーションと通信するためのサーバ（例えば、サーバ１００）およびクライアント（例えば、クライアント１４５，１５０）の各々から見た一連の動作および／またはステップを備える方法を示している。図２および図３と以下の論議では、「第一の」および／または「第二の」という用語を参照することが何回かある。これらの呼称は、ある一定の順番というより、主に用語間の区別を示唆するものであることは理解されるべきである。例えば、「第一のアプリケーション」とは一番目に使用されるアプリケーションか、そうでなければ順番に動作するアプリケーションであっても、なくてもよく、少なくとも「第二のアプリケーション」とは異なるものであればよい。同様に、「第二のアプリケーション」は「第一のアプリケーション」とは異なっていればよく、従って「第一のアプリケーション」の前後に使用されたりアクセスされなければならないアプリケーションではない。
【００３７】
図２は、複数のアプリケーションに単一のポートとの通信をするためのアクセスを提供するサーバ（あるいは共有コンピュータシステム）から見た方法が、第一の接続識別子を第一のアプリケーションと関連付けるという動作２００を備えることを示す。動作２００は、第一の接続識別子を第一のアプリケーションと、第二の接続識別子を第二のアプリケーションと関連付けることを含み、第一と第二のアプリケーションはセッションレベルで動作している。例えば、ポートリスニングサービス１３５は、サーバ１００のシステムレベル１１０で作動しており、サーバ１００のセッションレベル１０５で動作しているアプリケーション（例えば、１１５、１２０）のインスタンスからレディメッセージ１１３、１２３を受信する。サービス１３５は、更にこれらのアプリケーションにより生成された、対応するコンポーネントオブジェクト（例えば、１５５、１５７）を収容しており、メッセージ１１３、１２３中のアプリケーション識別子（例えば、「ＡｐｐＩＤ１１５」、「ＡｐｐＩＤ１２０」）を対応する固有の接続ＩＤ１６０、１６５に関連付ける。
【００３８】
更に図２は、その方法が接続識別子を有するクライアント接続要求を受信する動作２１０を備えることを示す。動作２１０は、クライアント接続要求、ポート番号を含むクライアント接続要求、共有コンピュータシステムのネットワークアドレス、および第一の接続識別子を受信することを含む。例えば、アプリケーション１１５は、ＸＭＬデータストリーム上でメッセージ１６７を介して、接続前データ１７０をクライアント１４５に送信する。クライアント１４５は、今度はサーバ１００に接続要求１８０を送信し、要求１８０はメッセージ１６７で受信した接続前データ１７０を含む。
【００３９】
図２はまた、この方法がクライアント接続要求を第一のアプリケーションに転送する動作２２０を備えることを示し、第一のアプリケーションはポートを通してクライアントと接続している。例えば、メッセージ１８０の接続前データ１７０で発見された固有の接続ＩＤ１６０を確認すると、リスニングサービス１３５は、ソケット１９０の制御を転送するが、それはサーバアプリケーション１１５への固有の接続ＩＤ１６０に関連付けられている。更に図２において、その方法は、同じポートを通して異なったクライアント接続を提供する動作２３０を備えることを示す。動作２３０は、ポート番号に対応するポートを通して第二のアプリケーションに異なったクライアント接続を提供する。
【００４０】
例えば、図１Ｄに示すように、クライアント１５０は接続要求１８３を送信するが、それには以前メッセージ１６３で受信したいかなる接続前データ１７５も含んでいない。メッセージ１８３を受信すると、リスニングサービス１３５は、クライアント１５０とサーバ１００との間の接続は許可するが、いかなるアプリケーションとの接続も許可しない。それは少なくとも一部は、要求１８０から直ちに確認できないからである。従って、リスニングサービス１３５は、接続要求をクライアント１５０と固有の接続ＩＤ１６５に対応するソケット１９５に関連付け、ソケット１９５をペンディング接続ストア１８５に保管する。リスニングサービス１３５は、接続前データ１７５を受信するまでこの接続を保持することができるが、そうでなければある一定の時間後に、この接続を単に中止してしまう。
【００４１】
図３は、本発明の実施例に従ってクライアントの観点から、共有コンピュータシステムにて単一のポートを通して複数のアプリケーションと通信する代わりの方法を説明する。具体的には、図３は、この方法が第一のアプリケーションと通信するための呼び出しを受信する動作３００を備えることを示す。動作３００は、第一の呼び出しを受信して、サーバコンピュータシステム上で第一のアプリケーションと通信を行うことを含むが、第一の呼び出しは少なくともポート番号と第一の接続識別子を含む。例えば、クライアント１４５は、サーバ１００でアプリケーション１１５に接続する呼び出しを含むメッセージ１６７を受信する。メッセージ１６７は、接続前データを含み、それにはサーバ１００のネットワークアドレスとポート１４０に関連するポート番号と同様、アプリケーション１１５と関連する少なくとも固有の接続ＩＤ１６０を含む。
【００４２】
更に図３は、その方法が第二のアプリケーションと通信するための呼び出しを受信するという動作３１０を備えることを示す。動作３１０は、サーバコンピュータシステムにて第二のアプリケーションと通信するための第二の呼び出しを受信すること含むが、第二の呼び出しは少なくともポート番号と第二の接続識別子を含む。例えば、明示されていないが、クライアント１４５は呼び出し１６３を受信可能であり、それにはアプリケーション１２０と関連付けられている異なった固有のＩＤ１６５が含まれている。メッセージ１６７、メッセージ１６３については、サーバ１００用のネットワークアドレスとポート１４０に対するポート番号も含んでいる。ここで、メッセージ１６３、１６７は、少なくとも対応する固有の接続ＩＤ（すなわち１６５対１６０）が異なっている。
【００４３】
図３は、その方法がサーバ上の同じポートを通して第一と第二のアプリケーションと通信するためのステップ３４０を備えることを示す。ステップ３４０は、クライアントがネットワーク上でサーバの同じ静的ポートを通して複数のアプリケーションと通信するような、ポート番号を通してサーバ上で第一と第二のアプリケーションと通信することを含む。例えば、クライアント１４５は、もし呼び出し１６３、１６７に従って動作するならば、ポート１４０を通してサーバアプリケーション１１５、１２０と通信可能である。
【００４４】
ステップ３４０は、ステップを遂行するための対応する動作について、任意の数もしくはオーダーを含むことができるが、図３はステップ３４０が第一の接続識別子との第一の接続要求を送信する動作３２０を備えることを示す。動作３２０は、サーバに第一の接続要求を送信することを含み、第一の接続要求は第一の接続識別子を備える。例えば、クライアント１４５は、ポート１４０を介してサーバ１００にメッセージ１８０を送信することができるが、メッセージ１８０は接続前データ１７０を含み、接続前データ１７０は固有の接続ＩＤ１６０を含む。
【００４５】
図３は、またステップ３４０が第二の接続識別子との第二の接続要求を送信する動作３３０を備えることを示す。動作３３０は、サーバに第二の接続要求を送信することを含み、第二の接続要求は第二の接続識別子を含む。例えばクライアント１４５は、サーバ１００に接続要求メッセージ（図示せず）に類似した別のメッセージを送信可能であり、類似の接続要求は、少なくとも固有の接続ＩＤ１６５を含んだ接続前データ１７５を含むことが相違点である。
【００４６】
クライアント１４５からこれら第一と第二の接続要求を受信し、また各々の要求に関連する固有の接続ＩＤを確認すると、リスニングサービス１３５は、各接続用の異なった通信ソケットの制御を、各々異なったアプリケーションインスタンス（例えば１１５、１２０）に割り当てることができる。このためアプリケーション１１５、１２０は同じ静的ポート、例えばポート１４０を通してクライアントと別々の接続をすることができる。
【００４７】
従って、図２と図３で説明した方法は、同じサーバポートを通してクライアントとサーバが効率的に複数のアプリケーションに接続できる多くの方法を提供している。前述のように、特にファイアウォールを実装したネットワークシステム内のように、限られた数の静的ポートが懸念を提起することができる場合に、このことは現在のシステムに数多くの利点をもたらす。
【００４８】
本発明の実施形態は、詳細は以下で述べるように、様々なコンピュータハードウェアを含む専用あるいは汎用のコンピュータを含むことができる。特に、本発明の範囲内での実施形態は、コンピュータに記憶されたコンピュータが実行可能な命令もしくはデータ構造を運搬あるいは保持するためのコンピュータ読取り可能媒体を含む。そのようなコンピュータ読取り可能媒体は、汎用または専用コンピュータよりアクセスすることが可能で利用可能な任意の媒体であればよい。限定ではなく例として、そのようなコンピュータ読取り可能媒体には、ＲＡＭ，ＲＯＭ，ＥＥＰＲＯＭ，ＣＤ−ＲＯＭあるいは他の光ディスクストレージ、磁気ディスクストレージあるいは他の磁気ストレージ装置、コンピュータで実行可能な命令やデータ構造の形式の望ましいプログラムコード手段を運搬あるいは保存するのに使用でき、かつ汎用あるいは専用コンピュータでアクセス可能なその他の任意の記憶媒体からなる。
【００４９】
ネットワーク、コンピュータへの別の通信接続（配線接続、無線、あるいはそれらの組合せ）を介して情報が転送または供給される場合、コンピュータはその接続をコンピュータ読取り可能媒体と見なすのは適切であろう。このようにして、そのような接続はどんなものでもコンピュータ読取り可能媒体と呼ぶのは適切である。上記の組合せもまたコンピュータ読取り可能媒体の範囲に含まれるべきである。
【００５０】
コンピュータで実行可能な命令は、例えば汎用コンピュータ、専用コンピュータ、あるいは専用処理装置に、ある機能あるいは機能のグループを実行させる命令やデータからなる。内容は構造特徴そしてまたは方法論的な動作に特有の言語で記述されているが、添付の特許請求の範囲で定義されている主題は、上記の特定の特徴あるいは動作により必ずしも制限は受けないと理解できる。むしろ、上述の特定の特徴や動作は、特許請求の範囲を実装する形式の例として公開されている。
【００５１】
本発明はその精神あるいは本質的な特徴から逸脱することなく他の特定の形式で実現することができる。説明した実施例は実例となるだけで、制限とはならないあらゆる観点から考慮されている。従って本発明の範囲は上記記載よりもむしろ、添付の特許請求の範囲により指摘されている。特許請求の範囲の意味と等価性の範囲内で発生する変更はその範囲内で採用される。
【図面の簡単な説明】
【００５２】
【図１Ａ】本発明の実施例に従って、複数のアプリケーションが対応する複数のクライアントと単一のポートを通して通信する概観図である。
【図１Ｂ】本発明の実施例に従って、同じポートリスニングサービスを使用する単一のポートを通しての通信に従って、複数のアプリケーションが固有の接続ＩＤを登録することを示す概念図である。
【図１Ｃ】本発明の実施例に従って、複数のアプリケーションがクライアントを呼び出して単一のポートを通して通信を行うが、呼び出しにはポートリスニングサービスによるデータも含まれている、図１Ｂに示す概念図である。
【図１Ｄ】本発明の実施例に従って、複数のクライアントが単一のポートを通して複数のアプリケーションと通信しようとしている図１Ｂ、図１Ｃの概念図である。
【図２】本発明の実施例に従って、サーバの観点から複数のアプリケーションと単一のポートを通してクライアントとが通信するための方法における動作のシーケンスを示すフローチャートである。
【図３】本発明の実施例に従って、クライアントの観点からサーバ上で複数のサーバアプリケーションと単一のポートを通して通信するための方法における１または複数の動作とステップのシーケンスを示すフローチャートである。
【図１Ａ】
2009508260.tif 000003
【図１Ｂ】
2009508260.tif 000004
【図１Ｃ】
2009508260.tif 000005
【図１Ｄ】
2009508260.tif 000006
【図２】
2009508260.tif 000007
【図３】
2009508260.tif 000008
【国際調査報告】
2009508260.tif 000009
2009508260.tif 000010