JP2006318499A - サーバとクライアントノードとの間の接続を管理するシステムおよび方法 - Google Patents

Abstract

【課題】クライアントサーバ環境において翻訳言語で書き込まれたアプリケーションの遠隔実行。
【解決手段】サーバクライアントシステムのサーバにおいて通信制御を提供する接続マネジャーは、指定されたサーバポートとの基礎的な接続をクライアントノードが確立することを可能にし、その後、サーバ上で実行するアプリケーションに特定の通信ポートへの接続に移行する。特定の通信ポートは、その後、クライアントノードによって要求されたプロトコルドライバを伴う通信マネジャにより構成される。アプリケーションはＨＴＭＬページに表示され得る。一実施形態では、サーバノード上で実行するアプリケーションから少なくとも二つのクライアントノードに、同一のデータが実質的同時的に伝送され得る。クライアント−サーバシステム上のサーバノードは、関連するクライアントノードの代わりに、解釈型言語で記述されたアプリケーションをダウンロードし実行し得る。
【選択図】図２

Description

発明の分野
本発明は、分散クライアントサーバ環境におけるアプリケーションの実行に関し、詳細には、クライアントサーバ環境において翻訳言語で書き込まれたアプリケーションの遠隔実行に関する。

発明の背景
クライアントサーバコンピュータネットワークは、通常、クライアントおよびサーバが、ある１組の予め確立されてたルールに従って通信を確立することを要求する。これらのルールは、通信プロトコルと呼ばれる。このようなプロトコルは、全てのクライアントノードがサーバノードとして同じ通信プロトコルを用いるように予め定義され得る。あるいは、サーバは各クライアントによって用いられる通信プロトコルの記録を維持し得、そして、サーバ上のアプリケーションと通信する要求をクライアントが送信する場合には、プロトコルを用いてクライアントと通信し得る。

このような通信方法に関わる問題は、要求されている全ての機能性を必要としないアプリケーションにとって、プロトコルの定義が堅すぎ得るか、または、クライアントがサーバと通信できるようになるよりも前に、クライアントプロトコルがサーバに認知される必要があるかのいずれかの点にある。本発明は、予め定義されたプロトコルの堅さおよびサーバ側に予め接触して知らせる必要性の両方を除去することを目的とする。

シャドウイング（あるクライアントノードに向けられたデータを実質的に同時に第２のクライアントノードに伝送すること）およびブロードキャスティング（同じデータを２以上のクライアントノードに実質的に同時に伝送すること）は、通常、サーバノード上の特別伝送アプリケーションおよび各クライアントノード上の特別受信アプリケーションを用いて行われてきた。シャドウイングは、データ整合性(data integrity）およびシステム
セキュリティのために、データトラフィックを監視し、かつ、伝送されている情報の余分なコピーを生成するのに有用である。このような情報が「リアルタイム」である場合、または、情報がそれ自体のはじめ(beginning)およびおわり(ending)を有さない場合には、
ブロードキャスティングは、多くのユーザに同じ情報を提供するのに有用である。例えば、株価相場プログラム(stockprice quotation program)は、所定の為替に基づくさまざまなストックの現在価格を単に伝送し、一旦株式の相場表(list)が検討され尽くすと、相場表は最新の価格で更新される。従って、相場プログラムに相場表を始める場所を指定することは、ユーザには無関係である。

このようなプログラムは、通常、ブロードキャストプログラムで書かれ、そして、伝送されたデータを受け取るために専用受信プログラムを要求する。アプリケーションがブロードキャストプログラムとして書かれなかった場合、このようなアプリケーションによって伝送されたデータは、通常、複数のクライアントノードにブロードキャストすることができない。

本発明は、ブロードキャスト機能のために書かれていないプログラムを、ネットワーク上でデータをブロードキャストするために使用できるようにすることによって、この問題を克服することを目的とする。

専用クライアントサーバネットワークとして、この数年間に爆発的成長を遂げた、「インターネット」として一般に公知のコンピュータのワールドワイドネットワークが挙げられる。この成長のほとんどが、ワールドワイドウェブ(WWW)の人気の増加によるものであ
る。WWWは、一般に「ウェブページ」と呼ばれるハイパーテキストマークアップ言語(HTML)を用いて書き込まれたファイルの集合体である。HTMLファイルは、「ウェブ」ブラウザ
として公知の専用アプリケーションを用いてアクセスおよびディスプレイされ得る。ウェブブラウザにより、ユーザは、単純なグラフィカルユーザインターフェース(GUI)を用い
て、HTMLファイルにアクセスすることができる。

HTMLファイルをホスト(host)するサーバは、ハイパーテキスト転送プロトコル(HTTP)を用いて通信を行うことができる。HTTPは、HTMLページ記述言語を用いた、（テキスト、グラフィックス、画像、音、映像等の異なるフォーマットであり得る）ファイルへのアクセスをユーザに提供するアプリケーションプロトコルである。HTMLはベーシックドキュメントフォーマッティングを提供し、それにより、デベロッパーは他のサーバおよびファイルへの通信「リンク」を特定することができる。HTML対応クライアントブラウザの使用は、ユニフォームリソースロケーターまたは「ＵＲＬ」によってリンクを特定することを含む。この特定に基づいて、クライアントは、リンク内に識別されたサーバに対してTCP/IP要求を行い、代わりに「ウェブページ」を受け取る。さらに、機構(organization)が、機構内からアクセス可能であるがWWWからはアクセスできないHTMLファイルを提供し得る。こ
れらの内部ネットワークおよびHTMLファイルの集合体は、一般に「イントラネット」と呼ばれる。

HTMLを用いて書かれたファイルは「タグ」を含む。タグは、特別なアクションをとる必要のある場合に、ファイルを表示しているブラウザにそのことを示し得る。例えば、タグはブラウザに対して、（１）グラフィクスファイルがドキュメント内の特定の点にディスプレイされる必要があること、（２）所定のテキストが、センタリングされる、ボールドされる、あるいはフォーマッティングが行われる必要があること、（３）ドキュメントのバックグラウンドに陰をつけるかまたは特定のパターンが付される必要があること、または、（４）異なるHTMLが、ブラウザが現在ディスプレイしているHTMLに代わってロードされる必要があることを示し得る。

ワールドワイドウェブおよび他のHTMLアプリケーションの人気が、幅広い産業に亘る広範囲の企業から、マーケティングおよびセールスの努力を引き出してきた。他企業との差別化が次第に困難になるにつれ、多くの企業が、HTMLに固有の静的な性質を克服する試みを行ってきた。また、情報を共有する方法としてHTMLファイルを用いる機構は、イントラネットを、さまざまなユーザに情報以上のものへのアクセスを提供する便利な方法であると認識してきた。

しかし、HTMLファイルの主要な欠点は、それらが本質的に静的であるという点にある。つまり、HTMLは「ディスプレイ専用」言語であって、HTMLページ内でアプリケーションを実行することは容易でない。WWWの人気および遍在性にテコ入れをする企業は、HTMLファ
イル内にアプリケーションを組み込む方法を捜すようになってきている。

ActiveX^TMオブジェクトは、実行中のアプリケーションを表示する能力を有するHTMLフ
ァイルを提供する試みの１つである。ActiveX^TMオブジェクトは、ActiveX^TMインターフェースを有するブラウザで使用し得るデータオブジェクトである。これらのオブジェクトの明らかな欠点は、ユーザのブラウザがActiveX^TMインターフェースを持っていない場合に
実行中のアプリケーションを表示できないことにある。ほとんどのHTMLページの第１の目的は、可能な限り多くのユーザによって視聴されることであるので、このことがActiveX^T
Mオブジェクトのユーティリティを制限する。

また、実行可能なコードをHTMLファイルに加えることを可能にする方法として、JAVA（登録商標）と呼ばれるプログラム言語が提案されてきた。JAVA（登録商標）は言語であるので、特定のブラウザインターフェースを要求せず、かつ、潜在的により広い視聴を有する。しかし、一般にアプレットと呼ばれるJAVA（登録商標）プログラムは、実行の前にクライアントにダウンロードされる。このことは、アプレットをダウンロードする十分なメモリのないクライアントにとって問題となり得、クライアントが十分なメモリを有する場合であっても、アプレットがダウンロードされるまでクライアントを待たせる。さらに、JAVA（登録商標）それ自体はプログラム言語であるので、既存のアプリケーションは、ウェブページに組み込まれる前に、JAVA（登録商標）言語で書き換えられる必要がある。

発明の要旨
ある局面において、本発明は、クライアントノードとサーバノード上で実行されるアプリケーションプログラムとの間の通信を管理する通信システムおよび通信方法に関する。

上記局面の一つの実施形態において、本発明の方法は、クライアントノードとサーバノード上に配置された一般通信ポートとの間の接続を確立するステップを含む。上記方法は、エンドポイントデータ構造を形成するステップと、クライアント空間をエンドポイントデータ構造と関連付けるステップと、アプリケーションプログラムに関連する特定の通信ポートに関するプロトコルスタックを形成するステップとをさらに含む。接続を接続マネジャーに通知を行い、そして、接続は一般通信ポートから特定の通信ポートのプロトコルスタックへと伝送される。

上記局面の別の実施形態において、接続を確立するステップは、マスターネットワーク情報ノードによってアプリケーション要求をクライアントノードから受け取るステップと、マスターネットワーク情報ノードによってクライアントノードに要求されたアプリケーションを有するサーバのサーバアドレスを提供するステップと、サーバによってクライアントノードからの要求を受け取って、提供されたアドレスに基づいて一般通信ポートへと接続するステップと、クライアントノードと一般通信ポートとの間の接続を確立するステップとを含む。

上記局面のさらなる実施形態において、通信システムはサーバノードおよびクライアントノードを含む。サーバノードは一般通信ポートを有する。クライアントノードは、クライアントノードとサーバノードの一般通信ポートとの間の接続を確立する通信デバイスを有する。サーバノードはまた、エンドポイントデータ構造を含むプロトコルスタックおよびメモリ内に配置されたクライアント空間を含む。クライアント空間は、プロトコルスタックに関連する。通信マネジャーおよび通知デバイスは、サーバノード上に配置される。通知デバイスは、クライアントノードと一般通信ポートとの間の接続を接続マネジャーに通知を行い、それに応答して、通信マネジャーは一般通信ポートとクライアントノードとの間の接続をプロトコルスタックに伝送する。一つの実施形態において、システムは、複数のプロトコルスタックのうちの、各プロトコルスタックと通信するマルチプレクサをさらに含む。

上記局面のさらに別の実施形態において、本発明は、コンピュータ読み出し可能プログラム手段を有する、該手段に設けられたクライアントノードと通信するための製品に関する。上記製品は、予め決定されたポートを介してクライアントノードとの接続を確立するためのコンピュータ読み出し可能プログラム手段と、エンドポイントデータ構造を形成するためのコンピュータ読み出し可能プログラム手段と、メモリ空間をエンドポイントデー
タ構造と関連付けるためのコンピュータ読み出し可能プログラム手段と、メモリ空間および関連するエンドポイントデータ構造でプロトコルスタックを形成するためのコンピュータ読み出し可能プログラム手段と、予め決められたポートとクライアントノードとの間の接続を接続マネジャーに通知を行うためのコンピュータ読み出し可能プログラム手段と、予め決められたポートとクライアントノードとの間の接続を関連するプロトコルスタックに伝送するためのコンピュータ読み出し可能プログラム手段とを含む。

別の局面において、本発明は、アプリケーションを特別な言語で書き直すことを要求せず、かつ、視聴ユーザのブラウザに専用インターフェースをサポートさせる要求をせずに、実行中のアプリケーションを表示されたHTMLファイル内に表示する方法に関する。アプリケーションはサーバ上で実行され、ダウンロード時間およびクライアント側のメモリ制限を緩和する。さらに、クライアントは、複数のページについて複数のアプリケーションの実行を呼び出し、アプリケーションを終了することなくHTMLドキュメント間を移動する。

上記局面の別の実施形態において、実行中のアプリケーションをHTMLページに表示する方法は、ユーザがアプリケーションプログラムの実行を望んでいる旨の信号を送るユーザからの入力を受け取ることによって開始される。アプリケーションが実行されるウィンドウのパラメータが決定され、そして、HTMLページ内のアプリケーションウィンドウへの通信チャネルが形成される。サーバ上で実行中のアプリケーションプログラムの出力は、通信チャネルを介してアプリケーションウィンドウ内に表示される。

上記局面のさらに別の実施形態において、HTMLページ内に実行中のアプリケーションを表示する装置は、パラメータハンドラーおよびネットワークエグゼクティブを含む。パラメータハンドラーは、HTMLファイル内に含まれるアプリケーション実行ウィンドウに関連するパラメータを受け取る。パラメータハンドラーは、パラメータハンドラーからのパラメータを受け取り、アプリケーションプログラムのサーバ上での実行を開始し、そして、パラメータハンドラーからのネットワークエグゼクティブによって受け取られたパラメータに基づいて、アプリケーション実行ウィンドウ内で実行中のアプリケーションの出力を表示する。

上記局面のさらなる実施形態において、製品は、実行中のアプリケーションをアプリケーション上に設けられたHTMLページ内に表示するためのコンピュータ読み出し可能コード手段を有する。製品は、サーバ上のアプリケーションプログラムの実行を開始する必要がある旨の信号を送るクライアントからの入力を受け取るためのコンピュータ読み出し可能コード手段を含む。製品はまた、実行中のアプリケーションが表示されるウィンドウのパラメータを決定するためのコンピュータ読み出し可能コード手段を含む。決定されたパラメータを用いてHTMLページへの通信チャネルを形成するためのコンピュータ読み出し可能コード手段、および通信チャネルを介して、アプリケーションウィンドウ内のサーバ上で実行中のアプリケーションの出力を表示するためのコンピュータ読み出し可能コード手段がさらに含まれる。

上記局面のさらなる実施形態において、HTMLページ内にアプリケーションを組み込むシステムは、サーバと、ネットワークエグゼクティブと、パラメータハンドラーと、HTMLファイルとを含む。サーバは、アプリケーションプログラムを格納および実行する。ネットワークエグゼクティブは、特定のアプリケーションの実行を開始する必要があることを示すコマンドをサーバに送り、そして、ネットワークエグゼクティブは、サーバ上で実行中のアプリケーションから出力を受け取る。パラメータハンドラーはパラメータを受け取り、それらをネットワークエグゼクティブに渡す。HTMLファイルはアプリケーションウィンドウを含む。アプリケーションウィンドウはウィンドウパラメータをパラメータハンドラ
ーに渡し、ネットワークエグゼクティブからアプリケーションプログラム出力を受け取る。

本発明のさらなる局面は、同じデータを２以上のクライアントノードに実質的に同時に伝送するシステムおよび方法に関する。一つの実施形態において、本発明は、サーバノード上で実行中のアプリケーションから、一般化されたレシーバプログラムを実行する少なくとも２つのクライアントノードへと、同じデータを実質的に同時に伝送する方法に関する。上記方法は、第１のクライアントノードとサーバノード上の第１のクライアントプロトコルスタックとの間の接続を確立するステップと、サーバノード上で実行中のアプリケーションと第１のクライアントプロトコルスタックとの間の接続を確立するステップと、第１の最小通信プロトコルスタックを第１のクライアントプロトコルスタックと関連付けるステップと、サーバノード上で実行中のアプリケーションと第１の最小通信プロトコルスタックとの間の接続を確立するステップと、第２のクライアントノードとサーバノード上の第２のクライアントプロトコルスタックとの間の接続を確立するステップと、第２の最小通信プロトコルスタックを第２のクライアントプロトコルスタックと関連付けるステップと、第１の最小プロトコルスタックと第２の最小プロトコルスタックとの間に接続を提供するステップと、第２の最小プロトコルスタックと第２のクライアントプロトコルスタックとの間に接続を提供するステップと、アプリケーションプログラムから第１のクライアントプロトコルスタックおよび第１の最小プロトコルスタックへとデータを実質的に同時に伝送するステップとを含む。

本発明の上記局面の別の実施形態は、サーバおよび２以上のクライアントノードを含む通信システムに関する。一つの実施形態において、サーバノードは、アプリケーションプログラムと、アプリケーションプログラムと電気的に通信する第１のクライアントプロトコルスタックと、アプリケーションプログラムと電気的に通信する第１の最小プロトコルスタックと、第１の最小プロトコルスタックと電気的に通信する第２の最小プロトコルスタックと、第２の最小プロトコルスタックと電気的に通信する第２のクライアントプロトコルスタックとを含む。さらに、上記システムは、第１のクライアントプロトコルスタックと電気的に通信する第１のクライアントノードと、第２のクライアントプロトコルスタックと電気的に通信する第２のクライアントノードとを含む。アプリケーションプログラムからのデータは、クライアントプロトコルスタックおよび第１の最小プロトコルスタックに実質的に同時に伝送される。

さらなる局面において、本発明は、クライアントサーバ環境において、翻訳言語を遠隔的に実行する方法に関する。クライアントが結合されるサーバは、JAVA（登録商標）アプレット等の翻訳言語で書かれたアプリケーションをダウンロードし、そしてそれを実行する。サーバはクライアントからの入力を受け取り、そして、クライアントにスクリーンデータを提供する。このことにより、アプリケーションをホストおよび実行する計算リソースおよびメモリリソースの拡張をクライアントに要求しなくても、クライアントがあたかも従来の様態でアプリケーションを実行しているかのように見える。さらに、サーバは、クライアントよりも速くアプリケーションのダウンロードが実行可能であり得る。サーバはまた、クライアントノードから入力を受け取り、それにより、クライアントノードは、入力を制御して、そして、入力をダウンロードされたアプリケーションに提供することができる。

上記局面の一つの実施形態において、本発明は、クライアントノードによって行われた要求に応答してサーバノードにアプリケーションをダウンロードすることにより開始される翻訳言語で書かれたアプリケーションを遠隔的に実行する方法に関する。クライアントノードとサーバ上に配置された予め決められた通信ポートとの間に、接続が確立される。サーバは、エンドポイントデータ構造を形成し、サーバによってホストされたクライアン
ト空間をエンドポイントデータ構造と関連付ける。サーバは、クライアント空間に関連するプロトコルスタックおよび関連するエンドポイントデータ構造を生成し、接続を接続マネジャーに通知を行い、そして、予め決められた通信ポートとクライアントノードとの間の接続を関連するプロトコルスタックに伝送する。

上記局面の別の実施形態において、本発明は、翻訳言語で書かれたアプリケーションを遠隔的に実行するための、コンピュータ読み出し可能プログラム手段を備えた製品に関する。上記製品は、クライアントノードによって行われた要求に応答してアプリケーションをサーバノードにダウンロードするためのコンピュータ読み出し可能プログラム手段と、クライアントノードとサーバ上に配置された予め決められた通信ポートとの間に接続を確立するためのコンピュータ読み出し可能プログラム手段と、エンドポイントデータ構造を形成するためのコンピュータ読み出し可能プログラム手段と、サーバによってホストされたクライアント空間をエンドポイントデータ構造と関連付けるためのコンピュータ読み出し可能プログラム手段と、クライアント空間と関連するプロトコルスタックおよび関連するエンドポイントデータ構造を生成するためのコンピュータ読み出し可能プログラム手段と、接続を接続マネジャーに通知するためのコンピュータ読み出し可能プログラム手段と、予め決められた通信ポートとクライアントノードとの間の接続を関連するプロトコルスタックに伝送するためのコンピュータ読み出し可能プログラム手段とを含む。

上記局面のさらに別の実施形態において、本発明は、翻訳言語で書かれたアプリケーションを遠隔的に実行するためのシステムに関する。上記システムは、予め決められた通信ポートを有するサーバノード、およびクライアントノードとサーバノードの予め決められた通信ポートとの間の接続を確立する通信デバイスを有するクライアントノードを含む。プロトコルスタックはサーバノード上に配置され、プロトコルスタックはエンドポイントデータ構造を含む。サーバノード上のメモリ内のクライアント空間はプロトコルスタックに関連し、翻訳言語で書かれたアプリケーションのための実行環境を提供する。システムは、サーバノード上に配置された通信マネジャー、およびサーバノード上に配置された通知デバイスをさらに含む。通知デバイスは、クライアントノードと予め決められた通信ポートとの間の接続を接続マネジャーに通知を行い、通信マネジャーは、予め決められた通信ポートとクライアントノードとの間の接続をプロトコルスタックに伝送する。

発明の詳細な説明
まず図１を参照すると、簡単に概覧したところでは、通常のネットワーク２０は、少なくとも１つのクライアントノード２４、少なくとも１つのサーバノード３４および３４’、ならびにマスターネットワーク情報ノード４０を含む。これらは、通信リンク４４によって一体に結合されている。図１に示す実施形態は、通信リンク４４をローカルエリアネットワークリングまたはＬＡＮリングとして示すが、いかなる通信トポロジーを使用してもよい。説明のために、サーバノード３４が、クライアントノード２４によって要求されたアプリケーション３０を有するものとみなす。また、説明のために、マスターネットワーク情報ノード４０を別個のサーバノードとみなすが、実際には、マスターネットワーク情報ノード４０は、アプリケーション実行サーバノード３４であり得る。所定のＬＡＮ上で、複数のノードがネットワーク情報ノードとして機能することが可能であり得るが、任意のある時間において、このようなノードのうちの１つのノードのみが、システム２０のマスターネットワーク情報ノード４０に指定され、そして、このノードに対してサーバ情報に関するクライアント要求が指示されることに留意されたい。

マスターネットワーク情報ノード４０は、アプリケーション実行サーバノード３４および３４’に関するアドレスのテーブルを維持する。さらに、マスターネットワーク情報ノード４０は、活動(activity)のレベルを示す、各アプリケーション実行サーバノード３４
および３４’からのメッセージを受け取る。アプリケーション実行サーバノード３４および３４’の活動のレベルは、アプリケーション実行サーバノード３４の各々のアドレスと共に、テーブル内に維持され、ロードレベリング(loadleveling)に関する通信システム４４によって使用される。

クライアント２４が、アプリケーション実行サーバノード３４上でアプリケーションを実行させたい場合には、クライアントノード２４は、既に通信プロトコルによって定義されている一般通信ポート、またはマスターネットワーク情報ノード４０上の「周知の」通信ポートに要求を送る。一つの実施形態において、通信はデータグラムサービスによって行われる。マスターネットワーク情報ノード４０は、サーバアドレスのテーブルにアクセスし、そして、アプリケーション実行サーバ、または、要求されたアプリケーションを有し、かつ、最低限のロード(the least load)を有するアプリケーションサーバ３４のアドレスを含むメッセージを戻す。それに続く通信は、クライアントによって、サーバノード３４上の「周知の」または予め定義された一般通信ポートに自動的にアドレスされる。一つの実施形態では、マスターネットワーク情報ノード４０へのはじめの問合わせ(query)
を行うのに用いたプロトコルのタイプは、マスターネットワーク情報ノード４０によってクライアントノード２４に戻された情報のプロトコルを判定する。従って、TCP/IPデータグラムを用いて要求が行われた場合、マスターネットワーク情報ノード４０は、サーバ３４のTCP/IPアドレスをクライアントノード２４に戻し、そして、クライアントノード２４はその後、そのプロトコルを用いて、サーバノード３４とのコンタクトを確立する。別の実施形態において、クライアント２４によってアプリケーションアドレスを要求するデータグラムは、マスターネットワーク情報ノード４０に要求を送るのに使用されたプロトコルとは異なるタイプのプロトコルについての要求を含む。例えば、クライアント２４は、IPXプロトコルを用いてマスターネットワーク情報ノード４０に要求を行い、かつ、TCP/IPプロトコルアドレスとしてアプリケーションサーバのアドレスを要求し得る。

クライアントノード２４（実際にはクライアントノード２４上のクライアントプロセス５６）がサーバノード３４および３４’上のアプリケーションと通信したい場合、クライアントノード２４は、ネットワーク要求を発行(issue)することにより、所望のアプリケ
ーションを有するサーバ３４のロケーションを判定し始める。この要求は、ネットワーク上のある場所に存在するマスターネットワーク情報ノード４０（ネットワークブラウザ４０とも呼ぶ）によって受け取られる。この図１において、簡略化のために、ネットワークブラウザ４０を、アプリケーションを有するサーバとは異なるサーバ４０上に存在するものとして示すが、このことは一般的なケースでないかもしれない。

ネットワークマスター情報ノード４０は、所望のアプリケーション３０を有するサーバノード３４のネットワークアドレスをクライアントノード２４に戻す。次に、クライアントノード２４は、ネットワークマスター情報ノード４０から受け取った情報を用いて、特定のサーバ３４上で実行中のアプリケーションへの接続を要求する。上述のように、このような接続は、まず「周知の」通信ポートに対して確立され、そしてその後、接続マネジャーの制御下で特定の通信ポートへと転送される。特定の通信ポートは、特定の通信ポートを介してクライアントノード２４と通信するサーバノード３４上で実行中のアプリケーションに関連する。

より詳細には、図２を参照すると、クライアントノード２４上のクライアントプロセス５６がネットワークマスター情報ノード４０に対して要求５４を行って、所望のアプリケーション６２を含むサーバノード３４のアドレスを得る。ネットワークマスター情報ノード４０は、クライアントノード２４にサーバアプリケーション６２を含むサーバノード３４のアドレスを含むメッセージ５８を戻す。一つの実施形態において、接続のこの点において使用されるプロトコルは、データグラムサービスである。

クライアントノード２４は、戻されたアドレスを用いてサーバ３４との通信チャネル６８を確立する。クライアント２４によって使用されるポート番号は、ネットワークプロトコルによりサーバ３４がクライアント２４との通信接続を確立するのに用いたポートとして定義されたサーバ３４内の「周知のポート」に対応する。周知のポート７２は、エンドポイントデータ構造７８を主に含む基礎(rudimentary)プロトコルスタック７６を有する
。

エンドポイントデータ構造７８が、通信プロトコルスタック７６およびクライアント接続を指すことにより、クライアント２４についての独自の表示または「ハンドル」が確立される。エンドポイントデータ構造７８は、サーバ３４とクライアント２４との間の接続が、サーバ３４上の接続マネジャー８０とさまざまなアプリケーション６２との間を自由に移動することを認める。一つの実施形態において、エンドポイントデータ構造７８は、クライアント２４へのハンドルを含むだけではなく、クライアント接続に関連する他の情報を含み得る。図示の実施形態によると、アプリケーションサーバ３４は、特定の通信システム（例えば、LANまたはWAN）上での活動を監視し、この最小プロトコルスタック７６を、「TTY」通信モードをサポートするのに必要なプロトコルモジュールのみで初期化し
てしまう。「TTY」通信モードは、トランスポート層よりも上にプロトコルアサンプショ
ンを有さないシンプルASCIIストリームである。つまり、伝送されたデータの圧縮、暗号
化、信頼度(reliability)、フレーミング、またはプレゼンテーションのためのプロトコ
ル層は存在しない。従ってサーバ３４上で実行されるアプリケーション６２を捜す(seek)クライアントノード２４は、TTY通信モードのサポートに必要な最小のプロトコルセット
で、周知の通信ポート７２への接続を確立する。

サーバノード３４上で実行される接続マネジャー８０は、接続要求６８に関する、周知の通信ポートを「聞く(listening)」。接続要求６８がクライアントノード２４から受け
取られた場合、接続マネジャー８０は通知を受ける(notified)８４。接続マネジャー８０は、通知８４に基づいてどのプロトコルが使用されているかを知る。

この情報を基に、接続マネジャー８０は新たな最小プロトコル通信スタック１０４を生成し、実行環境９６を開始し、そして、新たな最小プロトコルスタック１０４を実行環境９６に結合する。一つの実施形態において、サーバ３４は、既に開始しているが、通信ポートと関係していない複数の実行環境を含む。この実施形態において、実行環境のプレ接続(pre-connection)開始により、接続要求がクライアント２４から受け取られる時点で各実行環境９６が開始される場合よりも、より速い応答時間が実現される。実行環境９６が開始される場合、クライアント２４によって要求されたサーバアプリケーション６２も開始される。別の実施形態において、クライアント２４がアプリケーションを特定しない場合、デフォルトアプリケーションが開始されるか、または、単に、アプリケーションを有さない実行環境９６が開始される。

次に、接続マネジャー８０は、独自のクライアント識別子またはハンドルを有するクライアント接続を、周知のポート７６から新たな最小プロトコルスタック１０４へと移動する。接続マネジャー８０は、最小プロトコルスタックを用いて、サービスが利用可能であることを示すTTYデータストリームを送る。従って、クライアント接続を検出するこの方
法は、接続がはじめに確立されるポートから独立している。クライアントノード２４がサービス利用可能メッセージに対して予め決められた期間（例えば５秒）内に応答しない場合、「サービス利用可能」メッセージの再送信がサーバ３４によって実行される。

クライアント２４がメッセージを受け取る場合、クライアント２４は、「サービス利用可能」メッセージが検出されたことを示すTTYストリングを送る。クライアント２４はサ
ーバ３４が応答するのを待ち、そして、応答が予め決められた期間（例えば５秒）内に行われない場合には、クライアント２４はメッセージを再送信する。次に、接続マネジャー８０は、クライアントのデフォルト通信パラメータを請求するクライアント２４に対して問合わせ９０を行う。この問合わせ９０は、クライアント２４に戻されるメッセージであって、クライアント２４が接続内でクライアント２４がどのプロトコルを使用したいかに関して詳細に応答する必要があることを示すメッセージの形態をとる。

応答として、クライアント２４は１組のプロトコルパケット９２を送る。各パケットを用いて、サーバ３４から要求されている必要なまたは追加的なプロトコルモジュールが特定される。一つの実施形態において、１組内のパケットの数は、各プロトコル要求毎に送られる１つのパケットにより可変である。別の実施形態において、送られるパケットの数は、第１のパケットのヘッダ内に含まれる。第３の実施形態において、送られるパケットの残りの数は各パケットのヘッダ内に含まれ、次のパケットが送られる度にデクリメントされる。従って、クライアント２４は、例えば、暗号化およびデータ圧縮が用いられることを示すことによって問合わせ９０に応答し得る。このような場合、クライアント２４からサーバ３４へと２つのプロトコルパケットが送られ、そして、一つの実施形態において、第１のパケットのヘッダはパケットの数を２と示す。

問合わせ９０への応答が一旦受け取られると、接続マネジャー８０が、クライアントノード２４によって要求されたプロトコルに対応するプロトコルドライバ１２０、１２０’、１２０’’を用いてプロトコルスタックを構築する。一つの実施形態において、接続マネジャー８０は、要求されたプロトコルドライバ１２０、１２０’、１２０’’の各々を配置して、要求されたクライアントプロトコル（例えば、暗号化が求められる場合には、暗号化ドライバ）をプロトコルスタック「コンテナ」１１２に対応付けて、それらを一体にリンクさせる。このダイナミックプロセスにより、クライアントノード２４が、特定のクライアントノード２４に関してサーバ３４が優先度の高いプロトコルスタックデスクリプションを有する必要なく、プロトコルスタックのコンテンツを動的に特定することができる。この方法を用いると、個々のクライアント２４が関連する通信チャネルについての大きく異なる要件を有する場合であっても、複数のクライアント２４が１つのサーバによって執行(serve)され得る。図示の実施形態において、各クライアント２４、２４’、２
４’’は各通信プロトコルスタック１０４、１０４’、１０４’’に関連する。このようなダイナミックに拡張可能なプロトコルスタックを以下により詳細に説明するが、これは1995年10月11日に出願された米国特許出願番号第08/540,891号に記載されており、本明細書中で参考として援用する。

説明したばかりの実施形態において、「コンテナ」１１２は、NT^TMデバイスドライバ等のユーザレベルまたはケネルレベルデバイスドライバである。このコンテナドライバは、クライアントノード２４のプロトコル要件に対応する内部プロトコルモジュールまたは「ドライバ」（通常１２０）に補助サポート(ancillarysupport)を提供する。この補助サポートは、例えば、あるプロトコルドライバを助けてデータを次のドライバに転送するヘルパールーチンの形態である。あるいは、別の実施形態において、各プロトコルドライバは、それ自体に含まれる完全なユーザレベルまたはカーネルレベル(kernel-level)のドライバである。

ここで図３に図示した実施形態を参照すると、通信マネジャー６０は２つのソフトウェアモジュールICASRV.EXE９０およびICAAPI.DLL９４を含む。図示の実施形態において、ICASRV.EXE９０はクライアント／サーバインターフェースのサーバ側である。ICASRV.EXE９０は全ての通信状態を管理し、一つの実施形態においては、WINDOWS NT（登録商標）サービスとして設けられている。接続マネジャー６０の第２の部分はICAAPI.DLL９４である。ICAAPI.DLL９４は、クライアントとの接続を確立し、使用されるプロトコルを確立し、そ
して、ICASRV.EXE９０にプロトコルスタックの完了を通知する。一つの実施形態において、第３のモジュールCDMODEM.DLL９６はICAAPI.DLL９４’にリンクされる。CDMODEM.DLL９６は、モデムデバイスと通信するのにICAAPI.DLL９４’が用いるモジュールである。

ウェブブラウザプログラムを実行するクライアント２４について、上記の接続方法を使用し得る。本明細書のために、ウェブブラウザプログラムを実行するユーザを「視聴ユーザ」と呼ぶ。実行され得るHTMLファイルまたはアプリケーションをホストするマシンを呼ぶのに、「サーバ」または「サーバノード」という用語を用いる。例えば、視聴ユーザはクライアントノード上でウェブブラウザを実行し、HTTPプロトコルを介してサーバへのファイル要求を行う。サーバは、HTTPプロトコルを介してファイルデータをクライアントに伝送することにより応答する。クライアント上で実行されるウェブブラウザは、伝送されたデータを受け取り、そして、データをHTMLページとして視聴ユーザに対して表示する。

図４を概覧かつ参照すると、サーバ３４’上に配置され、かつ、本発明の実施形態に従って構築されたHTMLファイル６４は、包括組み込みウィンドウタグ(generic embedded window tag)６６を含む。包括組み込みウィンドウタグ６６は、包括組み込みウィンドウ６
６’がHTMLファイル６４によって記述されたHTMLページ６４’内の特定のロケーションに示す必要があることをHTMLファイル６４を表示するブラウザ６０に対して示す、任意のデータ構築物である。包括組み込みウィンドウタグ６６は、ウィンドウの高さ、ウィンドウの幅、ウィンドウのボーダースタイル(borderstyle)、ウィンドウ内の背景色またはパタ
ーン、どのアプリケーションをウィンドウ内に表示し得るか、もしくは、出力表示を更新せねばならない頻度等のさらなる情報、もしくは、アプリケーション出力の表示を向上するのに有用な他のさらなる情報を含み得る。

HTMLファイル内に組み込み得る包括組み込みウィンドウタグの例を、以下にいくつか挙げる。

上記の各場合において、タグは、アプリケーション出力を受け取るために295画素の高
さおよび436画素の幅を有するウィンドウを描く必要があることを示す。各タグはまた、
アプリケーションが自動的に実行を開始すること、かつ、アプリケーション出力が表示されるウィンドウが境界線で描かれることを特定する。ActiveX^TMタグおよびNetscapePlugin^TMタグは、ディレクトリ「/ica」内に配置されたファイル「direct,ica」内に特定され
た遠隔アプリケーションパラメータを有する。Java（登録商標）タグは、遠隔アプリケーションパラメータを直接特定する。上記実施例において、実行されるアプリケーションの名前と共に、アプリケーションをホストするサーバのアドレスが特定される。

ブラウザアプリケーション６０は、特定のユニフォームリソースロケーター（ＵＲＬ）アドレスに要求を発行することにより、HTMLファイル６４にアクセスする。HTMLファイル６４をホストするサーバ３４’は、HTMLファイル６４データをブラウザアプリケーション６０に伝送する。ブラウザアプリケーション６０は、テキストを表示し、HTMLファイル６４に含まれる任意のタグを変換する。ブラウザアプリケーション６０は、HTMLファイル６４データをHTMLページ６４’として表示する。包括組み込みウィンドウタグ６６は、上記タグの１つ等のHTMLファイル内に存在する場合、ブラウザ６０は、表示されたHTMLページ６４’内に空のウィンドウ６６’を描く。

所望のアプリケーション６２’の実行は、HTMLページ６４’が表示されるとすぐに始まり得るか、または、実行は何らかの信号、例えばアプリケーション６２’の実行を開始する必要があることを示す特定化されたユーザ入力、を待ち得る。アプリケーション６２’の実行が一旦開始されると、ブラウザアプリケーション６０は、アプリケーションウィンドウ６６に関連するパラメータハンドラー４０を例示(instantiate)する。パラメータハ
ンドラー４０は、ブラウザアプリケーション６０の子プロセスとして、ブラウザアプリケーション６０の同等プロセス(peerprocess)として、または、ブラウザアプリケーション
６０に関連する動的リンクトライブラリー（「DLL」）として生み出され得る。

ブラウザアプリケーション６０は、包括組み込みウィンドウ６６タグによって提供されたアプリケーションウィンドウ６６’に関連する特定のパラメータを、パラメータハンドラー４０の例に渡す。さらに、ブラウザアプリケーション６０は、アプリケーションウィンドウ６６’についてのハンドルをパラメータハンドラー４０の例に渡し得るか、または、パラメータハンドラー４０の例は、ブラウザアプリケーション６０に問い合わせて、アプリケーションウィンドウ６６’についてのハンドルを取り出し得る。パラメータハンドラー４０の例は、ネットワークエグゼクティブ５０も生み出し得る。ネットワークエグゼクティブ５０は、パラメータハンドラー４０の場合は子プロセス、または、パラメータハンドラー４０の場合は同等プロセスとして生み出され得る。

パラメータハンドラー４０の例は、ある特定のアプリケーションウィンドウ６６’パラメータをネットワークエグゼクティブ５０に転送する。パラメータハンドラー４０の例によって特定されないパラメータ、または組み込み包括ウィンドウタグ６６が、デフォルト値に設定され得る。ネットワークエグゼクティブ５０は、所定のハードコード(hard-coded)されたパラメータデフォルトを有し得るか、もしくは、ネットワークエグゼクティブ５０は、パラメータデフォルト値を含むファイルにアクセスし得る。

ネットワークエグゼクティブ５０は、それ自身のアプリケーション出力ウィンドウ６６’を形成する。ネットワークエグゼクティブ５０は、そのアプリケーション出力ウィンドウ６６’’を表示されたアプリケーションウィンドウ６６’の子として形成し、そのアプリケーション出力ウィンドウ６６’’を、ブラウザアプリケーション６０によって描かれた親ウィンドウ６６’上に直接表示する。ネットワークエグゼクティブ５０によって描かれたアプリケーション出力ウィンドウ６６’’は、ブラウザアプリケーション６０によって描かれたアプリケーションウィンドウ６６’の子であるので、アプリケーション出力ウィンドウ６６’’は、位置情報を含むその親のさまざまな特性を引き継ぐ。従って、視聴ユーザがブラウザアプリケーション６０のスクリーンをスクロールするか、または、アプリケーションウィンドウ６６’の位置を変える他の活動を実行すると、アプリケーション出力ウィンドウ６６’’は、アプリケーション出力ウィンドウ６６’に続く。

ネットワークエグゼクティブ５０はまた、サーバ６０との通信チャネルを確立し、上記の接続方法を用いてサーバ３４’’により所望のアプリケーション６２’の実行を呼び出
す。上の説明においてクライアントとして活動するネットワークエグゼクティブ５０は、それがパラメータハンドラー４０の例から受け取った任意のパラメータを、任意の必要なデフォルト値と共にサーバに渡す。パラメータがサーバに渡されなかった場合には、サーバは、もしそれがデフォルト値、例えばユーザid.(user id.)を有さない必要なパラメー
タである場合には、パラメータを要求し得るか、もしくは、パラメータ、例えば実行優先度についてのデフォルト値を提供し得る。サーバ３４’’は、所望のアプリケーションプログラム６２’の実行を開始し、そして、出力をネットワークエグゼクティブ５０に向ける。ネットワークエグゼクティブ５０は、アプリケーションプログラム６２’からのデータを受け取り、アプリケーション出力ウィンドウ６６’’に出力データを表示する。アプリケーション出力ウィンドウ６６’’は、ブラウザアプリケーション６０によって描かれたアプリケーションウィンドウ６６’の先端に描かれるので、アプリケーション出力データはHTMLページ６４’内に表示される。上で述べたように、ネットワークエグゼクティブ５０によって描かれたアプリケーション出力ウィンドウ６６’’は、ブラウザアプリケーション６０によって描かれたアプリケーション出力ウィンドウ６６’の子である。このことにより、HTMLページ６４’がスクロールされると、アプリケーション出力ウィンドウ６６’もスクロールする。

アプリケーション出力ウィンドウ６６’’はまた、視聴ユーザから入力を受け取る。未処理入力データ(raw input data)、例えばマウスクリックは、ネットワークエグゼクティブ５０によって、アプリケーション出力ウィンドウ６６’’へと受け取られる。ネットワークエグゼクティブ５０は、未処理データを、サーバ３４’’上で実行されるアプリケーション６２’に転送する。この様態で、視聴ユーザは、HTMLページ６４’を介してアプリケーション６２’と相互作用することができる。

ここで図５を参照すると、視聴ユーザは、いわゆる「ブラウザ」プログラムを用いて、アプリケーションウィンドウ６６’を有するHTMLページ６４’をユーザのコンピュータ１４のスクリーン１８上に表示する。視聴ユーザは、アプリケーションプログラム６２’の実行を呼び出し得る。通常、このことは、「ポイント−アンド−クリック」インターフェースを用いるユーザによって行われる。つまり、視聴ユーザはマウス１６を用いて、視聴ユーザのコンピュータ１４のスクリーン１８上にも表示されたカーソル１２を操作する。一旦カーソル１２がHTMLページ６４’の特定の部分上にあると、視聴ユーザはマウス１６上のボタン１５を「クリック」することによって信号を送る。あるいは、視聴ユーザはまた、付属キーボード１７上のリターンキーのようなキーを押すことによって信号を送り得る。別の実施形態において、視聴ユーザはマウス１６を全く使わないかもしれないが、代わりに、タッチパッド、トラックボール、感圧タブレットおよびペン、またはカーソル１２を操作する他の入力機構を使用し得る。

別の実施形態において、アプリケーションウィンドウ６６’またはHTMLページ６４’の別の部分が「ホットゾーン」を規定し得る。視聴ユーザがカーソル１２を「ホットゾーン」に移動すると、サーバ３４’’上でのアプリケーション６２’の実行が開始される。

アプリケーション６２’の実行を開始するべきだと、いったん視聴ユーザが指示したら、ブラウザアプリケーション６０はパラメータハンドラ４０を具体化（instantiate）し
、包括的に（generic）統合されたウィンドウタグ６６によって、アプリケーションウィ
ンドウ６６’に関連するインスタンシエーション（instantiation）パラメータを渡す。
パラメータハンドラ４０インスタンスは、ネットワークエグゼクティブ（executive）５
０を産出し、アプリケーションウィンドウ６６’のパラメータをこれに渡す。ネットワークエグゼクティブ５０は、どのアプリケーション６２’が呼び出されるのか、および、そのアプリケーション６２’がどのサーバ３４”上に常駐するのかを判定する。一般的にこの情報は、ブラウザアプリケーション６０から情報を獲得したパラメータハンドラ４０イ
ンスタンスによって、一般的統合ウィンドウタグ６６の形式で、ネットワークエグゼクティブ５０に渡されるが、ネットワークエグゼクティブ５０は、サーバが存在する場合、どのサーバが所望のアプリケーション６２’をホストするのかを判断するために、マスタネットワーク情報ノード４０または他の様々なサーバに照会を行う必要があり得る。次に、ネットワークエグゼクティブ５０は、上記詳述したように、アプリケーションの実行を開始し、アプリケーションプログラム６２’の出力をアプリケーションウィンドウ６６’に表示する。

ネットワークエグゼクティブ５０は、視聴ユーザが、例えばアプリケーションウィンドウ６６’を閉じることによって、アプリケーション６２’の実行を停止すべきだと指示するまで、または、視聴ユーザが、異なるＨＴＭＬページが表示されるべきだと指示するタグをクリックするまで、アプリケーション出力ウィンドウ６６’’におけるアプリケーション出力の表示を継続する。これが発生するとき、アプリケーション６２’の実行は終了し得る。しかしながら、接続を「キャッシュする（cache）」ことが、より好ましい。要
するに、第１のパラメータハンドラ４０インスタンスは、即座に終了しない。しかしながら、アプリケーション６２’は、低減された優先レベル、即ち「バックグラウンド」モードで実行を続ける。これは、第１のパラメータハンドラ４０が、もはや「注目（focus）
」を有していないからである。

一般的には、インスタンスを登録するために、グローバルにアクセス可能なデータ構造を用いて、パラメータハンドラ４０にソースコードを供給することにより、接続キャッシュを達成することが望ましい。例えば、パラメータハンドラ４０は、グローバルにアクセス可能なリンクリストデータ構造、データアレイ、データテーブル、または他のデータ構造を供給され得る。データ構造がグローバルに利用できるので、パラメータハンドラ４０の各インスタンスは、データ構造に対して読み出しおよび書き込みが可能である。この結果、その存在を信号伝達することをデータ構造に書き込むことにより、他の各々のインスタンスに「登録」できる。

他の接続情報がまったく格納されていない実施形態では、任意の時点でキャッシュされ得る接続数に関する所定の制限が設定され得る。これらの実施形態では、インスタンスの登録がキャッシュされる接続数の過剰を引き起こす場合、「キャッシュされた」接続の一つが除去される。即ち、その接続に関連するパラメータハンドラ４０インスタンシエーションが、終了すべきであると通告される。終了の前に、パラメータハンドラ４０は、関連するネットワークエグゼクティブ５０に、終了すべきであることを通告する。ひいては、ネットワークエグゼクティブ５０が、アプリケーションプログラム６２’をホストしているサーバとのセッションを閉じ、それから終了する。

他の情報が格納されている実施形態では、キャッシュされた接続をより効率よく管理するために追加の情報を使用し得る。例えば、所定の分数、例えば１０分間において、ユーザが積極的にＨＴＭＬページ６４’を見ていなかった場合、パラメータハンドラ４０インスタンシエーションは、終了を命令され、ホストをしているサーバとのセッションは終了されて、パラメータハンドラ４０インスタンスはレジストリ内のエントリを除去する。

キャッシュされた接続情報は、公知任意のキャッシュ管理スキームを用いて管理され得る。接続エントリは、「先入れ先出し（first in, first out）」ベース、即ち新規エン
トリの追加を要するとき毎に最も古いエントリが破棄され得る。あるいは、キャッシュされた接続情報エントリは、「最近不使用」ベースで破棄され得る。これはユーザによって最小量使用されてきた接続に関する情報を破棄する。ランダム置換など、他のキャッシュ管理技術も使用し得る。

視聴ユーザが、キャッシュされた接続を有する、以前のＨＴＭＬページ６４’に戻る場合、ＨＴＭＬページ６４’に関連するネットワークエグゼクティブ５０は、フォアグラウンドに戻る。即ち、「注目」を回復し、関連するアプリケーションの処理が通常の優先レベルで再開する。必要であれば、ネットワークエグゼクティブ５０は、アプリケーション６２’との接続を再確立する。キャッシュされた接続に対する出力データは、ネットワークエグゼクティブ５０によって、まったく格納されていないが、アプリケーションウィンドウ６６’のための接続が再確立されると直ちに、アプリケーション６２’への接続は再確立され、アプリケーション１０は、再びアプリケーションウィンドウ６６’に直接書き込む。

同様に、上述の接続方法論は、解釈型言語で記述されたアプリケーションの遠隔的実行を提供するのに使用され得る。再び図２を参照して、クライアントノード２４は、クライアントノード２４の代わりにアプリケーション６２を実行するサーバノード３４に接続される。この例では、サーバアプリケーション６２は、解釈可能な言語で記述されたアプリケーションを、クライアントノード２４が要求することを可能にする任意のアプリケーションである。例えば、アプリケーション６２は、クライアントノード２４が、ＵＲＬアドレスを使用するＪＡＶＡ（登録商標）アプリケーションをダウンロードすることを可能にするウェブブラウザであり得る。上述の例では、アプリケーションのダウンロード元となるノード、およびサーバノード３４は、コンピュータネットワークによって接続された別々のマシンである。しかしながら、いくつかの実施形態では、それらのマシンは一つであり得、同一であり得る。

ダウンロードしたアプリケーションをクライアントノード２４が格納し実行することは、クライアントメモリおよびプロセッサ利用の両観点から禁止され得るので、これをクライアントノード２４に要求するのを回避するため、クライアントノード２４が関連づけられているサーバノード３４上の実行環境９６は、ダウンロードされたアプリケーションのための実行環境を提供する。この実行環境は、ダウンロードされたアプリケーションのバイトストリームを解釈して、アプリケーションを意味する一連のコマンドを生成する。アプリケーションがＪＡＶＡ（登録商標）解釈型言語で記述されている場合、実行環境は「仮想ＪＡＶＡ（登録商標）マシン」と称されることがある。

いくつかの実施形態では、実行環境はコンパイラを含む。これらのコンパイラは、アプリケーションのバイトストリームを「ネイティブ」コードに変換する。例えば、コンパイラは、ＪＡＶＡ（登録商標）アプリケーション言語で記述されたアプリケーションのバイトストリームを、８０４８６マシンコードに変換し得る。解釈型言語バイトストリームのネイティブコードへの変換は、実行時に各バイトが解釈され実行されなければならない場合よりも、アプリケーションが速く実行することを可能にする。しかしながら、いくつかのコンパイラは、「ジャストインタイム（just in time）と称されることがあり、通常は、コンパイルされたコードの安定したストリームを生成するために実行される現時点実行（currently-executing）命令に先行して、所定の数のバイトを捜す（look）。

図２を参照して説明するように、ダウンロードされたアプリケーションは、サーバノード２４によって解釈されて実行され、アプリケーションの出力はクライアントノードに伝送される。サーバノード３４は、クライアントノード２４からの入力も受け入れる。これにより、クライアントノード２４はダウンロードされたアプリケーションを制御できるか、またはアプリケーションに入力を供給することができる。サーバノード３４は、ダウンロードされたアプリケーションを解釈し実行する個別の実行環境を設定し得る。これらの実施形態では、ダウンロードされたアプリケーションに関連する実行環境は、その出力をｍｕｘ１２１にも送信する。

図６を参照して、アプリケーション６３を伴うサーバ３４に接続されている任意のクライアント２４、２４’、２４”、または、事実上すべてのクライアント（２４で総称する）が、別のサーバ３４’、３４”であり得ることに留意されたい。この様態では、アプリケーション６３によって伝送されたデータは、クライアントノード２４に送られる前に、他のサーバに送られる。このネットワークは扇状に広がっているので、この様態では、アプリケーション６３によって伝送されるデータは、これまで以上に多い数のクライアントノードに伝送される。

各クライアント２４が、サーバ３４との接続を終了すると、各クライアントプロトコルスタック（１０４で総称する）および関連する最小スタック（１０７で総称する）は破壊される。同様に、第１のクライアントプロトコルスタック１０４に関連する最小プロトコルスタック（１０６で総称する）も破壊される。最小１０７および第２の（および後続する）クライアントプロトコルスタック１０４の最後のものが終了したとき、構成は、最初のように、実行環境９６に関連する第１のクライアント通信プロトコルスタック１０４のみを伴う。第２のおよび後続するクライアントプロトコルスタック１０４がすべて終了するまで、たとえ第１のクライアント２４がすでに存在しなくとも、第１のクライアントプロトコルスタック１０４は、破壊され得ないことに留意されたい。

図２に示すように、各実行環境９６は、マルチプレクサ１２１、１２１’、１２１”を介して、各プロトコルスタック１０４と通信する。以下、図６も参照して、本発明によると、例えば、データの伝送をサーバ３４から隠したり監視したりするために、または株式相場アプリケーションなど、同一のデータが実質的同時的に複数のクライアント（２４で総称する）に同報通信または伝送される、特別な同報通信アプリケーションからのデータを同報通信するために、１人以上のクライアントが第１のクライアント２４に伝送されたデータを受け取ることが可能である。

そのような場合、第１のクライアント２４は、特別なアプリケーション６３を実行し、前述のようにクライアント２４にそのデータを伝送する。第２のクライアント２４’が同報通信されたアプリケーション６３へのアクセスを要求するとき、接続マネジャ８０は、第１のクライアント２４を参照して前述したように、第２のクライアント２４’のためのプロトコルスタック１０４’を構築する。しかしながら、アプリケーション６３は同報通信アプリケーションであるので、接続マネジャ８０は、追加の実行環境９６を開始する必要のないことを認識し、代わりに同報通信アプリケーション６３からのデータを第２のクライアント２４’および任意の追加クライアント２４”に送るのに必要な工程を行う。

まず、接続マネジャ８０は、第１のクライアント２４の通信プロトコルスタック１０４に関連づける第１の最小通信プロトコルスタック１０６を生成する。次に、接続マネジャ８０は、第２の最小プロトコルスタック１０７を生成し、それを第２のクライアント２４’の通信プロトコルスタック１０４’に関連づける。各追加のクライアント２４”が同報通信アプリケーション６３へのアクセスを要求するのに従い、別の最小プロトコルスタック１０６’が生成され、第１のクライアントプロトコルスタック１０４に関連づけられて、別の最小プロトコルスタック１０７’およびクライアントプロトコルスタック１０４”が各新規のクライアント２４”のために生成される。第１のクライアントプロトコルスタック１０４と第１のクライアントプロトコルスタック１０４に関連づけられたすべての最小プロトコルスタック１０６、１０６’と、および各対のクライアントプロトコルスタック１０４’、１０４’’と各追加のクライアント２４’、２４’’に関連づけられた最小プロトコルスタック１０７、１０７’とは、マルチプレクサ１２１を介して通信する。

マルチプレクサ１２１が唯一のクライアント２４に対してデータを送受信するとき、マルチプレクサ１２１は、単純な通過デバイスとして機能する。しかしながら、単一のアプ
リケーション６３に対してデータを受信または伝送する一つ以上のクライアント２４、２４’、２４”が存在するとき、各マルチプレクサ（１２１で総称する）は、二つの追加の構成を備える。一つの構成では、マルチプレクサ１２１’が、第１のクライアントプロトコルスタック１０４と関連する最小通信プロトコルスタックスタック１０６、１０６’との両方に対して、アプリケーションデータの送受信をするように構成される。第２の構成では、マルチプレクサ１２１”が、最小プロトコルスタック１０７、１０７’によって受信されたデータを、関連するクライアントプロトコルスタック１０４’、１０４’’それぞれに送信するように構成される。この実施形態では、マルチプレクサ１２１は、各クライアントプロトコルスタック１０４、１０４’、１０４”から直接データを受信し得る。

接続マネジャー８０は、第１のクライアント２４に関連する最小プロトコルスタック１０６、１０６’を、それぞれ第２のクライアント２４’および後続するクライアント２４”の最小プロトコルスタック１０７、１０７’に接続し、アプリケーション６３からの出力を第１のクライアント２４の通信プロトコルスタック１０４およびその最小プロトコルスタック１０６、１０６’に送信するようマルチプレクサ１２１に命令する。また、マルチプレクサ１２１は、接続マネジャー８０によって、各第２および後続のクライアント最小プロトコルスタック１０７、１０７’を、それぞれ関連するクライアントプロトコルスタック１０４、１０４’に接続するように命令を受ける。従って、第１のクライアントプロトコルスタック１０４を介して、第１のクライアント２４に伝送されたデータは、第１のクライアント２４に関連する最小プロトコルスタック１０６、１０６’、ひいては、第２のクライアント２４’および後続のクライアント２４”に、それぞれ関連するプロトコルスタック１０４’、１０４’’およびそれぞれ関連するプロトコルスタック１０７、１０７’を介して伝送される。一つの実施形態では、プロトコルスタックコンテナ（container）は、所与のアプリケーション６３に関連するプロトコルの数およびタイプを格納し
続けるデータ構造を含み得る。

図７を参照して、上述のように、一つのサーバ３４の「クライアント」が別のサーバ３４’および３４”（簡略化のため二つだけを示す）であることが可能である。そうして、第２のサーバ３４’および３４”は、データをクライアント（２４で総称する）または追加のサーバに伝送する。この実施形態では、サーバプロトコルスタック（１０４で総称する）の出力は、二次サーバ３４’、３４”のプロトコルスタック１０７’に接続される。そうして、前述のように、データはプロトコルスタックの間で伝送され、クライアント（２４で総称する）に出力される。この様態では、データが扇状に広がり得、一つのサーバによって相応にサポートされ得るよりも多くのクライアントに配送できる。

本発明を、添付の請求項の詳細な事項で示す。上記の本発明の利点が、さらなる利点と同様、添付の図面と共に以下の説明を参照することにより、よりよく理解され得る。
図１は、本発明を使用する通信システムの一つの実施形態の、大幅に模式化した図である。 図２は、クライアントとサーバとの間の通信中に行われる、図１のサーバのさまざまな構成要素の間の接続を示す、本発明の実施形態のブロック図である。 図３は、複数のクライアントノード接続の維持および管理を行う、本発明の一実施形態のブロック図である。 図４は、HTMLページにアプリケーションを組み込むためのシステムの実施形態のブロック図である。 図５は、クライアントノードの概略図である。 図６は、アプリケーションの同一データを１人以上のクライアントに伝送するためのマルチプレクサの使用を示す、本発明の実施形態のブロック図である。 図７は、ブロードキャスト能力(broadcast capability)が端末増設機構(fanout)により増大した、本発明の実施形態のブロック図である。

Claims (27)

1. クライアントノードにおいて、アプリケーションプログラムに関連付けられたデータを受信するための方法であって、
   該方法は、
   ファイルを要求するステップと、
   ジェネリック内蔵ウィンドウタグを含むファイルを受信するステップと、
   該ジェネリック内蔵ウィンドウタグによって記述される第１のウィンドウを表示するステップと、
   該第１のウィンドウ上にアプリケーション出力ウィンドウを直接的に表示するステップと
   を包含する、方法。
2. 前記ファイルを要求するステップは、特定のＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）アドレスに要求を出すステップを包含する、請求項１に記載の方法。
3. 前記第１のウィンドウは、ブラウザアプリケーションによって表示される、請求項１に記載の方法。
4. 前記アプリケーション出力ウィンドウ表示するステップは、
   パラメータハンドラをインスタンス化するステップと、
   前記第１のウィンドウに関連付けられた前記ジェネリック内蔵ウィンドウタグからのパラメータを該パラメータハンドラにパスするステップと
   を包含する、請求項１に記載の方法。
5. 前記パラメータハンドラは、ブラウザアプリケーションの子プロセスである、請求項４に記載の方法。
6. 前記パラメータハンドラは、ブラウザアプリケーションのピアプロセスである、請求項４に記載の方法。
7. 前記パラメータハンドラは、ブラウザアプリケーションに関連付けられたダイナミックリンクライブラリ（ＤＬＬ）である、請求項４に記載の方法。
8. 前記アプリケーション出力ウィンドウに関連付けられたハンドラを前記パラメータハンドラにパスするステップをさらに包含する、請求項４に記載の方法。
9. 前記アプリケーション出力ウィンドウに関連付けられたハンドラに対してブラウザアプリケーションにクエリするステップをさらに包含する、請求項４に記載の方法。
10. ネットワーク実行部をインスタンス化するステップと、
    アプリケーションウィンドウパラメータを該ネットワーク実行部にパスするステップと
    をさらに包含する、請求項４に記載の方法。
11. 前記ネットワーク実行部は、前記パラメータハンドラの子プロセスである、請求項１０に記載の方法。
12. 前記ネットワーク実行部は、前記パラメータハンドラのピアプロセスである、請求項１０に記載の方法。
13. 前記ネットワーク実行部は、実行されるアプリケーションのＩＤを決定する、請求項１０に記載の方法。
14. 前記ネットワーク実行部は、前記識別されたアプリケーションをホストするサーバのＩＤを決定する、請求項１０に記載の方法。
15. 前記ネットワーク実行部は、マスタネットワーク情報ノードにクエリすることによって前記識別されたアプリケーションをホストするサーバのＩＤを決定する、請求項１４に記載の方法。
16. 特定されていないパラメータに対してデフォルト値を検索するステップをさらに包含する、請求項１０に記載の方法。
17. 前記デフォルト値は、前記ネットワーク実行部においてハードコード化される、請求項１６に記載の方法。
18. 前記デフォルト値は、前記ネットワーク実行部によってアクセスされるファイルに格納されている、請求項１６に記載の方法。
19. アプリケーション出力ウィンドウをインスタンス化するステップと、
    前記第１のウィンドウ上に該アプリケーション出力ウィンドウを直接的に表示するステップと
    をさらに包含する、請求項４に記載の方法。
20. 前記アプリケーション出力ウィンドウは、前記第１のウィンドウの子である、請求項１９に記載の方法。
21. 前記アプリケーション出力ウィンドウは、前記第１のウィンドウの特性を所有する、請求項２０に記載の方法。
22. サーバとの通信チャネルを確立するステップと、
    該通信チャネルを用いて、所望されるアプリケーションの実行を呼び出すステップと
    をさらに包含する、請求項４に記載の方法。
23. 前記パラメータハンドラから受信されるパラメータを前記サーバに伝送することを包含する、請求項２２に記載の方法。
24. 前記サーバによって、デフォルト値を有しない必要なパラメータを要求するステップをさらに包含する、請求項２３に記載の方法。
25. 前記サーバによって、パラメータに対するデフォルト値を提供するステップをさらに包含する、請求項２３に記載の方法。
26. 前記実行アプリケーションからデータを受信するステップと、
    前記アプリケーション出力ウィンドウにおいて該受信されたデータを表示するステップと
    をさらに包含する、請求項２２に記載の方法。
27. 視聴ユーザから入力を受信するステップと、
    該受信された入力を前記実行アプリケーションに提供するさらに包含する、請求項２６に記載の方法。

Images