JP4929371B2

JP4929371B2 - 二方向的なプロセス対プロセスのバイトストリームのプロトコル

Info

Publication number: JP4929371B2
Application number: JP2010100888A
Authority: JP
Inventors: ディー．ディクソン，マイケル
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1998-06-09
Filing date: 2010-04-26
Publication date: 2012-05-09
Anticipated expiration: 2019-06-09
Also published as: AU4558699A; HK1039189A1; JP2002517857A; DE69937762D1; EP1125207B1; US6289461B1; ATE381193T1; DE69937762T2; CA2334971C; ATE400847T1; US7103799B2; JP4537579B2; EP1633109B1; US20010056547A1; DE69939067D1; EP1125207A4; EP1125207A1; JP2010250834A; EP1633109A1; CA2334971A1

Description

本発明は、分散されたコンピュータのプログラムの分野に関する。より詳しくは、本発明は二方向的なプロセス対プロセスのバイトストリームのプロトコルに関する。

コンピュータ技術の進歩とインターネットの出現によって、コンピュータ・ユーザは世界中に分散したポイントからコンピュータ・プログラムを集合的に実行できるようになった。分散型プログラムの例には、コンピュータ・チャットルーム、会議プログラム、およびゲーム・プログラムが含まれ、ここでは複数のコンピュータ・ユーザがリアルタイムに情報のインタラクティブな交換が可能である。例えば、コンピュータによるチャット（ｃｈａｔ）のルームによって多数の分散したユーザが個々の分散ユーザの1人がタイプするのと同時に会話テキストを見ることができ、会議アプリケーションでは分散ユーザが集合的に1つのテキスト文書の草案を作成したり編集したりすることができ、ゲーム・プログラムでは分散ユーザが仮想ゲームの環境で競争または協力することができる。

分散型プログラムを実行するためには、2つの個別プロセスが両方向バイト・ストリームを維持する必要がある。プロセスとは、コンピュテーションのアクティブな実行を指し、広くタスク、ジョブ、またはスレッドとも呼ばれる。分散型プログラミングはしばしばクライアント・サーバ・パラダイムに基づき、ここではクライアント・システムで実行するプロセスはサーバ・システムで実行するプロセスと通信しなければならない。

クライアント・サーバのパラダイムにおいては、クライアント・システムはサーバ・プロセスへのアクセスとサーバ・プロセスからの情報を要求する。クライアント・プロセスおよびサーバ・プロセスは同じコンピュータ・システムで実行することもでき、別個の通信的に接続されたシステムで実行することもできる。サーバ・システムがインターネットのようなネットワークによってアクセス可能な場合、世界各地の多数のクライアント・システムがサーバ・システムに要求することができる。

クライアントとサーバの間の通信はしばしば各種ネットワーク内あるいはその間の各種メディアによるデータの伝送が関与する。このような通信メディアはしばしば信頼性が低い。例えば、インターネットはスケールがグローバルで、無数の個々のコンピュータおよび接続に依存している。インターネットのいずれかの部分の故障は予測または防止が不可能で、インターネットを本質的に信頼性の低いものにしている。転送制御プロトコル/インターネット・プロトコル（TCP/IP）は、インターネットの本質的な低信頼性に拘らず、サーバを信頼性高く転送するよう設計された多数の通信プロトコルから構成される。一般的に、TCP/IPはデータの到着を検証し、到着しないセグメントを自動的に再転送する。インターネットで通信する大半の分散型プログラムは信頼性を確保するためTCP/IPフォーマット化されたメッセージを利用している。

信頼性に加えて、ネットワーク・ユーザにとってセキュリティが大きな問題である。多くのシステムがある種のネットワーク通信を選択的にブロックするためファイアウォールを使っている。例えば、ほとんどのファイアウォールはTCP/IP通信を防ぎ、分散型プログラミングに広く使われる両方向バイト・ストリームをブロックする。

そのため、分散型プログラミングを利用するには、ファイアウォールを通過し、ファイアウォールの提供するセキュリティレベルを維持し、本質的低信頼性メディアで信頼できる通信を提供することができる両方向プロセス・トゥ・プロセス・バイト・ストリーム・プロトコルが必要である。

クライアント・システムはメッセージを保存し、サーバ・システムにメッセージを送信する。メッセージはファイアウォールを通過できるプロトコルに従ってフォーマット化された要求に含まれる。そして、クライアント・システムはサーバ・システムからの応答を待つ。応答もファイアウォールを通過できるプロトコルに従ってフォーマット化される。応答は、最後の要求でサーバ・システムがクライアント・システムからどのメッセージを受けたかの表示も含む。クライアント・システムに一定数のメッセージが蓄積されるか、応答受信までに一定の時間が経過すると、クライアント・システムは第2の要求を送信する。

サーバ・システムもメッセージを保存し、クライアント・システムにメッセージを送信する。サーバ・システムはクライアント・システムからの第1の要求と第2の要求を待つ。第1の要求を受け取り、特定の数のメッセージがサーバ・システムに蓄積されると、サーバ・システムは第1の要求に対応する応答を送る。第2の要求を受け取ると、サーバ・システムはメッセージが蓄積されていなくとも、第1の要求に対応する応答を送る。応答は蓄積されたあらゆるメッセージを含む。次回、クライアント・システムが要求を送るとき、要求はクライアント・システムが最後の応答でサーバ・システムからどのメッセージを受けたかの表示を含む。

図1は、コンピュータ・ネットワークの一実施例を示す。図2は、クライアント・システムの一実施例を示す。図3は、サーバ・システムの一実施例を示す。図4は、HTTPフォーマット化された要求の一実施例を示す。図5は、HTTPフォーマット化された応答の一実施例を示す。図6は、クライアント・システムの一実施例のプロセスを示す。図7は、サーバ・システムの一実施例のプロセスを示す。図8は、クライアント・システムまたはサーバ・システムの機能を実行するハードウェア・システム・オペラティブの一実施例を示す。

以下の詳細な説明では、本発明を完全に理解するため多数の特定の詳細を記載する。しかしながら、本発明はこれら特定の詳細なしに実行でき、本発明は数々の別の実施例で実行できることが当業者には理解される。他の場合、周知の方法、手順、コンポーネントおよび回路は詳細には説明しない。

図1は、ファイアウォールが分散型コンピュータ・プログラムの実行と干渉するコンピュータ・ネットワークを示す。クライアント・システム110で実行するプログラムは転送制御プロトコル/インターネット・プロトコル（TCP/IP）160フォーマット化された通信を使ってサーバ・システム120で実行するプロセスとの通信を妨害される。しかしながら、以下に詳細に述べるように、本発明は、ファイアウォールを通過できるTCP/IPタイプ通信を作成するため、大半のファイアウォールに共通するループホールを利用する。

分散型プログラミングはほぼあらゆる種類のクライアント・サーバ・インタラクションを含む。例えば、プロセスはサーバ・システムで実行される別のプロセスと通信するクライアント・システムで実行できる。あるアプリケーションでは、クライアント・プロセスはアプレットと呼ばれ、サーバ・プロセスはサーブレットと呼ばれる。2つのプロセスの間の通信は、分散型プログラミングからなる。複数のクライアント・プロセスが1つのサーバ・プロセスと同時にインタラクトできる。

図示の例では、クライアント・システム110およびクライアント・システム・145はインターネット130に接続される。インターネット130はサーバ・システム120を含む。ある実施例では、クライアント・システム110、クライアント・システム145、およびサーバ・システム120は集合的に分散型コンピュータ・プログラムを実行し、ここでプログラムの一部はサーバ・システム120で実行され、プログラムの一部はクライアント・システムのそれぞれで実行される。本発明の教示を除き、クライアント・システム110、サーバ・システム120、およびクライアント・システム145は当業で周知のあらゆる数の分散型システムを表す。

メッセージはクライアント・システムのそれぞれおよびサーバ・システム120にインターネット130の幅広い接続によって送受信される。本発明の教示を除き、インターネット130による通信は当業で周知の多数の方法のいずれかで実施される。分散型プログラムはあらゆる数の分散型プログラムでよく、コンピュータ・チャットルーム、会議プログラム、およびゲーム・プログラムを含む。

クライアント・システム110はファイアウォール140に保護され、これはTCP/IP160フォーマット化された通信を含む通信を選択的にブロックし、大半の分散型プログラムの実行を不可能にする。しかしながら、しばしば発生することだが、ファイアウォール140はクライアント・システム110のユーザがインターネット130のウェブ・ページをブラウジングできるようにする。このためにループホール150が設けられ、ハイパーテキスト・トランスファー・プロトコル（HTTP）フォーマット化されたトランザクションがファイアウォール140を通過できるようにする。HTTPトランザクションを用いてインターネット130のウェブページにアクセスする。1回のHTTPトランザクションは2部に分かれる。トランザクションの第1部はHTTP要求で、これはクライアントしか開始できない。クライアント・システムはHTTP要求を送信してウェブ・ページへのアクセスを要求する。トランザクションの第2部はHTTP応答である。サーバ・システムにあるウェブ・ページがHTTP応答を送り返す。

ループホール150があっても、ファイアウォール140は一定量のセキュリティをクライアント・システム110に提供する。すなわち、HTTPトランザクションはクライアント・システムしか開始できず、ファイアウォール140は外向きHTTP要求のみ許し、外向きHTTP要求に対応する内向きHTTP応答のみ許すよう設計できる。
あらゆる数の周知のHTTPループホール付きファイアウォール・セキュリティ・システムを本発明を使って通過することができる。

以下に詳細に述べるように、本発明はループホール150を利用してHTTPフォーマット化された要求としてメッセージを送信し、HTTPフォーマット化された応答としてメッセージを送り返すことで、クライアント・システム110とサーバ・システム120との間にTCP/IPのような接続を作成する。このように、本発明はファイアウォール140が提供するセキュリティレベルを維持しながらTCP/IPタイプ接続を提供する。

図2は、クライアント・システム110とファイアウォール140の1つの実施例を示す。クライアント・システム110は図示のように接続されたクライアント・プロセス210、バッファ220、およびHTTPゲートウェイ230を含む。HTTPゲートウェイ230は当業で周知の多数のHTTPゲートウェイのいずれかを表し、クライアント・システム110がインターネット・ウェブ・ブラウジングに用いる。クライアント・プロセス210は、クライアント・システム110で実行される分散型プログラムの一部である。ファイアウォール140がないと、クライアント・プロセス210はTCP/IP160を使ってサーバ・システム120と通信することができる。例えば、上記引用の特許出願に説明する分散型プログラムは非同期TCP/IPプロトコルを利用し、ここではメッセージはクライアント・システム110またはサーバ・システム120から開始することができる。しかしながら、図示の例では、ファイアウォール140はTCP/IP通信を妨害する。この場合、クライアント・システム110はHTTPループホール150を介した通信に切り換えることができる。

クライアント・システム110は複数の異なる方法のいずれかで自動的にファイアウォール140を認識することができる。例えば、クライアント・システム110はTCP/IPフォーマット化された要求をサーバ・システム120に送り、サーバ・システム120からの応答を求めることができる。一定のタイムフレーム内に応答を受け取らないと、クライアント・システム110はタイムアウトになり、ループホール150を介してHTTPフォーマット化された要求を送ろうとする。

図3は、サーバ・システム120の1つの実施例を示す。サーバ・システム120は、図示のように接続されたサーバ・プロセス310、バッファ320、およびHTTPサーバ330を含む。1つの実施例では、HTTPサーバ330はHTTPサーバの役割を演じる専用ソフトウェアからなるが、特に当業で周知のHTTPサーバのオーバヘッドなしに転送にメッセージを含むよう設計される。あるいは、HTTPサーバ330はコモン・ゲートウェイ・インターフェース（CGI）を持つ当業で周知の多数のHTTPサーバのいずれかを表すことができる。ソフトウェアはCGIを使って本発明の教示に従いHTTPトランザクションを修正することができる。

サーバ・プロセス310はサーバ・システム120で実行する分散型プログラムの一部である。サーバ・プロセス310はTCP/IP通信を使ってあらゆる数のクライアント・システム145と通信することができる。しかしながら、ファイアウォール140はサーバ・プロセス310がTCP/IP160を使ってクライアント・システム110と通信することを妨害する。クライアント・システム110同様、サーバ・システム120は複数の異なる方法のいずれかでファイアウォール140を検出することができる。しかしながらサーバ・システム120はHTTPトランザクションを開始できないため、クライアント・システム110からのHTTP要求を待つ。

HTTPトランザクションは必然的にクライアントが開始する2部トランザクションであるため、HTTP通信は大半のTCP/IPフォーマット化通信よりやや遅く、面倒になる傾向がある。そのため、分散型プログラムはTCP/IP接続をまず試すことが多い。これに失敗すると、クライアント・システム110およびサーバ・システム120はTCP/IPメッセージをバッファし、メッセージのグループをバンドルで送り、HTTPトランザクションの頻度を減らし、これによってスループットをほぼTCP/IP接続のものまで増やす。また。インターネット接続は本質的に信頼性が低いため、クライアント・システム110およびサーバ・システム120は送信した後もメッセージを保存し続け、信頼性を確保する。メッセージは相手システムからのメッセージが正しく受信されたという通知を受けて初めてそれぞれのバッファから削除される。

図2で、クライアント・システム110はクライアント・プロセス210からのメッセージをバッファ220でバッファすることによってこれら機能を実行する。そこから、メッセージを1つのバンドルにグループ化し、HTTPゲートウェイ230、ファイアウォール140のHTTPループホール150を介してサーバ・システム120に送出する。対応するHTTP応答をサーバ・システム120から受けると、応答はループホール150を介してHTTPゲートウェイ230、ひいてはクライアント・プロセス210に戻る。

図3で、サーバ・システム120はサーバ・プロセス310からのメッセージをバッファ320でバッファする。要求が入った後、サーバ・システム120はバッファ320に保存されたメッセージを1つのバンドルにグループ化し、これらをHTTPサーバ330を介してHTTPフォーマット化応答に含める。要求と共に到着したメッセージはサーバ・プロセス310に与えられる。

各HTTPトランザクションは要求と対応する応答からなり、HTTPトランザクションはクライアント・システムが開始するため、両システムは通信の回線を開いておくため互いのシステムに依存する。すなわち、サーバ・システム120は要求を受け取った後にのみ応答できる。HTTP接続が両方向TCP/IP接続と同様に動作して、クライアント・システム110とサーバ・システム120の両方が転送を開始できるようにするには、クライアント・システム110とサーバ・システム120が協力して要求をそのままにしておかなければならない。

ある実施例では、クライアント・システム110はバッファ220に最大バンドルサイズまで保存されたあらゆるメッセージを含む第1の要求を送る。しかしながら、クライアント・システム110はサーバ・システム120からの応答を単に待っているのではない。その代わり、クライアント・システム110は追加メッセージがあれば保存を続け、3つのイベントのうち1つが発生すると別の要求を送る。

まず、一定量の追加メッセージがバッファ220に蓄積されると、クライアント・システム110は追加メッセージを含む第2の要求を送る。例えば、最大バンドルサイズを10個のメッセージとして、追加メッセージが蓄積するとすぐ、クライアント・システム110はこの10個の追加メッセージを含む第2の要求を送ることができる。

第2に、応答を受信せずに一定の時間が経過すると、クライアント・システム110はあらゆる保存メッセージを含む追加メッセージが蓄積されていなくとも、第2の要求を送る。例えば、信頼性の低いネットワークで要求が失われると、応答は受信されることはない。クライアント・システム110は例えば1秒でタイムアウトになり、エラーが発生したと想定する。第1の要求に5個のメッセージが含まれており、クライアント・システム110がタイムアウトになる前にさらに3個のメッセージが蓄積された場合、クライアント・システム110は8個のメッセージ全てを含む第2の要求を送る。

第3に、クライアント・システム110がサーバ・システム120から応答を受けると、クライアント・システム110は第2の要求を送る。この第3の場合、利用できる帯域や蓄積された追加メッセージの数により、クライアント・システム110はサーバ・システム120から応答を受け次第、第2の要求を送ることができ、またはクライアント・システム110は短期間遅延してさらにメッセージを蓄積することができる。

トランザクションのサーバ側では、サーバ・システム120は第1の要求の受信を待たなければならない。サーバ・システム120は待っている間、外向きのメッセージを保存する。サーバ・システム120が第1の要求を受信すると、サーバ・システム120は直ちに応答しないことがある。まず、一定数のメッセージが蓄積されている場合、あるいは第1の要求を受けた後のあるポイントで一定数のメッセージが蓄積されている場合、サーバ・システム120は応答を送る。例えば、最大バンドルサイズが10個のメッセージで、サーバ・システム120が第1の要求を受けたときに10個のメッセージを保存していると、サーバ・システム120は直ちに応答する。しかしながら、メッセージの数が一定数のメッセージより少ない場合、サーバ・システム120はさらにメッセージが蓄積されるのを待つか、第2の要求が到着するのを待つ。第2の要求を受信すると、サーバ・システム120は第1の要求に対応する応答を送り、メッセージが蓄積されていなくとも、蓄積されているメッセージがあれば最大バンドルサイズまで含める。クライアント・システム110同様、利用可能な帯域および蓄積されたメッセージの数により、サーバ・システム120は第2の要求受信直後に応答することができ、あるいはサーバ・システム120は短期間遅延してさらにメッセージを蓄積することができる。

オペレーションでは、一連のエラーフリー・トランスファーが次のように進む。クライアント・システム110は第1の要求を送る。サーバ・システム120は第1の要求を受信するが、応答しない。短時間後、クライアント・システム110は第2の要求を送る。サーバ・システム120は第2の要求受信後に第1の要求に応答する。クライアント・システム110はさらに要求を送り続け、新しい要求の度に、サーバ・システム120は前の要求に応答する。このように、クライアント・システム110およびサーバ・システム120は協力してサーバ・システム120で1つの要求をそのままにしておき、サーバ・システム120が常に応答できるようにする。

各種実施例において、遅延とバンドル中のメッセージの最大数は、スループットを増やしTCP/IP接続のスループットに近似するよう最適化できる。インプリメンテーションは、クライアント・プロセス210およびサーバ・プロセス310などのさらに高いレベルのアプリケーションに対してトランスペアレントにできる。例えば、クライアント・システム110とサーバ・システム120との間の直接TCP/IP接続を想定して書かれたアプリケーションは、アプリケーションのコードや行動を変更せず、パフォーマンスが無視できる劣化を示すのみでHTTPプロトコルを使って切り替え可能である。

別の実施例では、サーバ・システム120は1個以上の要求をそのままにしておき、例えばサーバ・システム120が大きなデータブロックを取り扱えるようクローズ・サクセッションで複数の応答を送ることができる。しかしながら、サーバ・システム120がそのままにしておく要求の数はクライアント・システム110のバッファ220のサイズ、クライアント・システム110がタイムアウトするまでの時間、最大バンドルサイズなどの要因によって限定される。例えば、メッセージが受信されたとの通知によって初めてメッセージがバッファから削除されるため、応答が受信されないとメッセージはバッファ220に蓄積される。また、クライアント・システム120がタイムアウトし、エラーが発生したと想定するとメッセージを再送信する。蓄積されたメッセージの数が最大バンドル数を超えると、クライアント・システム110が送る要求の数は急激に増加し、不要に帯域を無駄にする。

図4は、HTTP要求の1つの実施例をさらに詳細に示す。HTTP要求は、HTTP要求であることを識別し、要求の宛先を指定し、各種追加特性を指定するヘッダ情報を含む。ヘッダの後には、あらゆる形式のデータが来ることができる。実施例では、データはクライアント・システム110がサーバ・システム120からの最後の応答でメッセージを受け取っていればどのメッセージかを示す接頭辞を含む。ここで、接頭辞はクライアント・システム110が最後の応答で1からNまでのメッセージを受け取ったことを示す。接頭辞の後に、要求はバッファ220に保存された1からMまでのメッセージすべてのコピーを含む。要求をサーバ・システム120が受け取ると、サーバ・システム120はサーバ・プロセス310に1からMまでのメッセージを与える。サーバ・システム120はまた、バッファ320に保存されたメッセージから1からNのメッセージを削除し、次の応答に残るメッセージがあればこれのみ送る。

図5は、HTTP応答の1つの実施例を示す。要求同様、応答はこれが特定のHTTP要求に対応するHTTP応答であることを識別し、宛先を指定し、応答の各種追加特性を指定するヘッダ情報を含む。ヘッダの後には、あらゆる形式のデータが来ることができる。図示の実施例では、データは最後の要求でサーバ・システム120が受け取ったメッセージがあればどのメッセージか示す接頭辞を含む。ここで、接頭辞はサーバ・システム120が最後の要求で1からMまでのメッセージを受け取ったことを示す。接頭辞の後、応答はバッファ320に保存された1からNまでのメッセージのコピーも含む。応答をクライアント・システム110が受け取ると、クライアント・システム110はクライアント・プロセス210に1からNのメッセージを与え、バッファ220に保存されたメッセージから1からMのメッセージを削除し、次の要求に残るメッセージがあればこれのみ送信する。

いずれのシステムもメッセージを受信したとの表示を受け取る前にそのバッファからメッセージを削除しない。また、上述のように、クライアント・システム110は、一定時間内に応答を受信しないと要求を送る。例えば、要求が何らかの理由でサーバ・システム120に届かない場合、クライアント・システム110は同じメッセージと蓄積されていた追加メッセージがあればこれを含む別の要求を送る。同様に、応答が到着しないと、クライアント・システム110は別の要求を送り、サーバ・システム120は同じメッセージと蓄積されていた追加メッセージがあればこれを含む別の応答を送る。さらに、要求または応答を受けたが、メッセージが読めない場合、対応して返された接頭辞はメッセージが読めなかったことと、メッセージを再送信することを示す。このように、本発明は本質的に信頼できない通信メディアで信頼できるメッセージ転送を行う。

図6は、クライアントシステム110の一実施例によって実行される手順を示す。ブロック610において、クライアントシステム110はHTTPリクエストを送り出すが、これには、バッファ220の中に保存された何らかのメッセージのコピー、ならびに、そのメッセージのインジケータとして、クライアントシステム110が最後のレスポンスにおいて受け取ったメッセージ（それがある場合）も含まれる。リクエストが第1のリクエストであって、最後のレスポンスがいかなるメッセージも含んでいなかった場合、または、最後のリクエストからのメッセージが読み取り不能であった場合、インジケータは、ゼロメッセージが受け取られたことを示すことになる。クライアントシステム110がレスポンスを受け取るのを待つ間、追加の出力メッセージ（それがある場合）がバッファ220、ブロック620および630の中に保存される。ある程度の数のメッセージが蓄積されると、クライアントシステム110は、ブロック640へと進むことになる。レスポンスが受け取られなかったので、ブロック640ではいかなる動作も起こらず、クライアントシステム110がブロック610に戻り、追加のメッセージを含む別のリクエストを送り出すことになる。例えば、最大バンドルサイズが10メッセージで、10の追加メッセージが貯まった場合、10のメッセージを含む別のリクエストが送られることになる。

ブロック630において、ある程度の数のメッセージが貯まる前にレスポンスが受け取られると、プロセスは、再びブロック640へと進むことになる。レスポンスが受け取られると、そのレスポンスは、プリフィックスと、サーバシステム120から送られた何らかのメッセージを含むことになる。プリフィックスは、サーバシステム120が最後のリクエストにおいてどんなメッセージを受け取ったかを指示することになる。リクエストがメッセージを含んでいなかった場合、またはエラーがあって、メッセージが読み取り不能であった場合、プリフィックスはゼロメッセージを指示することになる。クライアントシステム110は、指示された何らかのメッセージをブロック640においてバッファ220から除去することになる。レスポンスに何らかのメッセージが含まれていた場合には、そのメッセージもクライアントプロセス210に提供されることになる。すると、手順はブロック610に戻り、プリフィックスと保存されていた何らかのメッセージを含む新たなリクエストが送られる。

上に述べた通り、有効帯域幅や保存されたメッセージの数などのファクターに応じて、クライアントシステム110は、レスポンスを受け取り次第直ちにリクエストを送ることもあれば、もっと多くのメッセージを貯めさせるために時間を遅らせることもある。

クライアントシステム110は、レスポンスが受け取られるか、1バンドル分の追加メッセージが貯まるかする前に、ブロック630においてタイムアウトすることがある。例えば、最大バンドルサイズが10メッセージで、3つしかメッセージが貯まっていない場合でも、ある程度時間が経過した後にクライアントシステム110はタイムアウトすることがある。エラーが生じたのかもしれないし、サーバシステム120が第2のリクエストを待っているのかもしれない。いずれにしても、クライアントシステム110はブロック640へと進むことになる。レスポンスが受け取られなかったのであるから、メッセージが指定されなかったし、メッセージが受け取られなったわけで、結局、ブロック640において一切アクションが起こされないことになる。代わりに、クライアントシステム110はブロック610へと進み、第1のリクエストで送られたメッセージを含めて保存されていた何らかのメッセージを最大バンドルサイズまで送り出すことになる。貯まったメッセージの数が最大バンドルサイズを超えると、クライアントシステム110は、2つ以上のリクエストを送ることがある。その上、クライアントシステム110は、レスポンスを受け取ることなくある程度の数のリクエストが送られた後に接続が切断されたことを指示することがある。

図7は、サーバシステム120の一実施例によって実行される手順を示す。ブロック710において、サーバシステム120は、出力メッセージがある場合には、これを保存し、ブロック720において第1のリクエストを待つ。第1のリクエストが受け取られると、そのリクエストは、クライアントシステムが最後のレスポンスにおいて受け取ったメッセージ（それがある場合）を指示するプリフィックスを含むことになる。最後のレスポンスがいかなるメッセージも含んでいなかった場合、またはエラーがあって、メッセージが読み取り不能であった場合、プリフィックスは、ゼロメッセージが受け取られたことを指示することになる。リクエストはまた、クライアントシステム110から送られた何らかのメッセージを含むことにもなる。ブロック730において、サーバシステム120は、指示された何らかのメッセージを、バッファ320の中に保存されたメッセージから除去し、何らかの入力メッセージをサーバプロセス310に提供することになる。

次に、サーバシステム120は、第2のリクエストがブロック740で受け取られるまで、またはある程度の数のメッセージがブロック741および745の中に貯まるまで、第1のリクエストを保持することになる。例えば、最大バンドルサイズが10メッセージで、10のメッセージが貯まった場合、サーバシステム120は、第2のリクエストを受け取らなかったとしても、ブロック741からブロック744へと進むことになる。ブロック744において、サーバシステム120は、保存されていたメッセージを含めて第1のリクエストに対応するレスポンスを送り、ブロック710に戻って別の第1のリクエストを待つことになる。

ブロック740において第2のリクエストが受け取られると、サーバシステム120は、メッセージが貯まっていなくても、ブロック750へと進むことになる。ブロック750において、指示された何らかのメッセージがバッファ320から削除され、何らかの入力メッセージがサーバプロセス310に提供されることになる。ブロック760において、保存されていたメッセージを含めて第1のリクエストに対応するレスポンスが送り出される。サーバシステム120は、ブロック740に戻って別のリクエストまたは丸々1バンドル分のメッセージを待つことになる。別のリクエストが受け取られると、クライアントシステム120はすでに1つのリクエストを保持しているので、新たなリクエストは第2のリクエストのように処理され、クライアントシステム120は、ブロック750を通過し、ブロック760において別のレスポンスを送り出すことになる。その上、1つのリクエストがブロック740で保持されている限り、いつでも1バンドル分のメッセージが貯まっていき、サーバシステム120は、保持されたリクエストに対応するレスポンスを出すことができる。

上に述べた通り、有効帯域幅や保存されたメッセージの数などのファクターに応じて、サーバシステム120は、第2のリクエストを受け取り次第直ちにレスポンスを送ることもあれば、もっと多くのメッセージを貯めさせるために時間を遅らせることもある。また、別の実施例では、サーバシステム120は、ある程度の時間枠の中でリクエストが受け取られなかった場合にタイムアウトすることになり、そうなった場合、サーバシステム120は、接続が切断されたことを指示することがある。

クライアントシステム110とサーバシステム120の間でひとたびHTTP接続が確立されれば、どちらかのシステムは、多数の方法のどれかで接続を終わらせることができる。例えばリクエストまたはレスポンスが所定の終了メッセージを含むこともあり得よう。

代替の実施例では、適当な情報が提供され、その情報が適当なシステムによって識別できる限り、最後の伝送においてどんなメッセージが受け取られたかを指示するインジケータを何らかの仕方で提供することができる。例えばサフィックスを使用することができるであろうし、あるいは、メッセージが、ある範囲の中で指定されたというよりむしろ個別に数字であることもあり得るし、従って、個別に失われたメッセージを識別することもできよう。

クライアントシステム110またはサーバシステム120の機能を実行するためにハードウェアシステムをどんな数でも使用することができる。各システムは、従来公知の広いカテゴリのコンピュータシステム、例えば、Intel Corporation（カリフォルニア州サンタクララ）が製造、市販するPentium（登録商標）プロセッサ、Pentium（登録商標）プロ・プロセッサ、Pentium（登録商標）IIプロセッサ、またはDigital Equipment Corporation（マサチューセッツ州メイナード）が製造するAlpha（登録商標）プロセッサなどの高性能マイクロプロセッサを搭載したコンピュータシステムによって表してよい。

図8は、適当なハードウェアシステム800の一実施例を示す。図示された実施例では、ハードウェアシステム800は、高性能バス805に結合したマイクロプロセッサ810を包含し、高性能バス805の方は、バスブリッジ830を通して入出力（I/O）バス815に結合している。テンポラリメモリ820がバス805に結合している。パーマネントメモリ840がバス815に結合している。ディスプレイ装置870、キーボード880、通信インタフェース850および汎用I/O860がすべて、バス815に結合している。通信インタフェース850は、ハードウェアシステム800をインターネット130に結合させることができる。汎用I/O860は、ハードウェアシステム800を多数の外部装置のどれかに結合させることができる。

実施例の中には、追加コンポーネントを包含してよい実施例、上記コンポーネントのすべてを必要としなくてよい実施例、または2つ以上のコンポーネントを組み合わせてよい実施例もある。例えばテンポラリメモリ820が、マイクロプロセッサ810を備えたオンチップであってよい。あるいは、パーマネントメモリ840が無くしてあってよく、テンポラリメモリ820の代わりに、電気的消去可能なプログラマブル・リード・オンリー・メモリ（EEPROM）、例えばソフトウェアルーチンがEEPROMから適当な場所で実行されるフラッシュ・メモリなどが使用してあってよい。実施態様によっては、すべてのコンポーネントが結合する単一のバスを使用しても、多数の追加バスを使用してもよい。また、従来公知のプロセッサ、CD-ROMなどの記憶装置、メモリ、その他の周辺機器などの追加コンポーネントがハードウェアシステムに含まれていてもよい。

一実施例では、上に述べた通りのクライアントシステム110またはサーバシステム120が、ハードウェアシステム800によって実行されるソフトウェアルーチンのシリーズとして実現している。かかるソフトウェアルーチンは、マイクロプロセッサ810などの、ハードウェアシステム内のマイクロプロセッサによって実行される複数の、または一連の命令からなる。最初、一連の命令は、パーマネントメモリ840などの記憶装置に保存しておくことができる。それでも、一連の命令は、ディスケット、CD-ROM、磁気テープ、ディジタルビデオディスク、DVD、レーザーディスク、ROM、フラッシュ・メモリなどの従来の記憶媒体のどれを使っても保存できることを認識しなければならない。また、一連の命令は、ローカルメモリに保存する必要がなく、多数のネットワークのどれかにおける別のサーバシステム、CD-ROMデバイス、フロッピディスクなどの遠隔記憶装置から受け取ることができることも認識しなければならない。命令は、記憶装置からテンポラリメモリ820にコピーし、そこでアクセスし、マイクロプロセッサ810によって実行してよい。一実施態様では、かかるハードウェアルーチンは、JAVA（登録商標)プログラミング言語で書かれている。それでも、かかるルーチンは、多種多様なプログラミング言語のそれででも実行できることを認識すべきである。

代替の実施例では、クライアントシステム110またはサーバシステム120が、離散型のハードウェアまたはファームウェアの形で実現している。例えば1つ以上の特定用途向け集積回路（ASIC）を、上に述べたクライアントシステム110またはサーバシステム120の機能を使ってプログラムすることができよう。別の例では、クライアントシステム110またはサーバシステム120を追加回路板上の1つ以上のASICの形で実現させ、回路板をハードウェアシステム800に挿入することができよう。

本発明は、広範囲の用途を有する。例えば、仮想分散させられた何らかのプログラムによって、HTTPフォーマットによるトランザクションを許す何らかのファイアウォールを仮想横断するのに使用することができる。その上、本発明は、ファイアウォール背後から双方向通信を始めることを許されたどんなプロトコルフォーマットも使用することができる。HTTP/1.0は、まさしくそのようなフォーマットの1つである。HTTP/1.1および他のそのようなフォーマットも使用することができる。

本発明は、イントラネットを含む多種多様なネットワークで実行される多種多様な分散形プログラムに適用してよい。その上、本発明は、多重クライアントシステムによって同時に、多重ファイアウォールを通して1つ以上のサーバにアクセスするのに使用することができる。それゆえ、本特許の目的のためには、クライアントシステムは、他の何らかのシステムにリクエストを出すどんなシステムにも当てはまる。同様に、サーバシステムは、リクエストを受けるどんなシステムにも当てはまる。1つのシステムが同時にクライアントシステムとサーバシステムの両方であり得る。

以上、分散形プログラムにファイアウォールを横断させるための方法および装置について述べた。当業者であれば、上の説明を読んだ後、本発明に変更や改良を加えた多くの態様のあることを理解されるであろうが、同時に、本発明が図に則して述べた特殊な実施例だけに制限されるものでは決してないことを理解すべきである。よって、特殊な実施例の詳細に言及することは、請求の範囲を制限することを意図するものでない。

Claims

クライアントシステムとサーバシステムとの間の二方向通信を維持する方法であって、
前記クライアントシステムから前記サーバシステムへファイアウォールを通過する少なくとも２つのリクエストを送信するステップを含み、該送信するステップは、
前記クライアントシステムにおいて前記サーバシステムから前に受信したメッセージのインジケーションを含み、対応するレスポンスを要求する第１のリクエストを、前記ファイアウォールを通じて前記クライアントシステムから前記サーバシステムに送信することと、
前記クライアントシステムにおいて、前記ファイアウォールを通過して前記サーバシステムから送信される前記第１のリクエストに対応する第１のレスポンスを待つことと、
前記第１のリクエストを送信した後に、対応するレスポンスを要求する第２のリクエストを、前記ファイアウォールを通じて前記クライアントシステムから前記サーバシステムに送信することと
を含み、
前記サーバシステムは、前記クライアントシステムからのリクエストのうち少なくとも１つのリクエストに対応するレスポンスを前記クライアントシステムに送信せずに前記少なくとも１つのリクエストを前記サーバシステム上に保持しておくことにより、前記クライアントシステムとのオープン通信リンクを維持するように構成されていて、前記ファイアウォールは前記サーバシステムにより開始されたデータトラフィックが前記クライアントシステムへアクセスすることを防止するように構成されていることを特徴とする方法。
前記送信するステップがさらに、
前記第１のリクエストを送信する前に前記クライアントシステムにおいて第１のメッセージのセットを記憶することを含み、前記第１のリクエストはさらに前記第１のメッセージのセットのコピーを含む、請求項１記載の方法。
前記送信するステップがさらに、
前記第１のレスポンスを待つ間に、前記クライアントシステムにおいて追加のメッセージを記憶することを含み、
前記第２のリクエストの送信は、前記クライアントシステムにおいて特定の数の前記追加のメッセージが蓄積された場合に実行され、前記第２のリクエストは前記追加のメッセージのコピーを含む、請求項２記載の方法。
前記送信するステップがさらに、
前記第１のレスポンスを待つ間に、前記クライアントシステムにおいて追加のメッセージを記憶することを含み、
前記第２のリクエストの送信は、前記クライアントシステムにおいて前記第１のレスポンスを受信するまでに特定の時間が経過した場合に実行され、前記第２のリクエストは前記第１のメッセージのセットのコピー及び前記追加のメッセージのコピーを含む、請求項２記載の方法。
前記送信するステップがさらに、
前記第１のレスポンスを待つ間に、前記クライアントシステムにおいて追加のメッセージを記憶することを含み、
前記第２のリクエストの送信は、
前記クライアントシステムにおいて、前記第１のリクエストに対応する前記第１のレスポンスであって、前記第１のリクエストによりに前記サーバシステムが受信した前記第１のメッセージのセットのインジケーションを含む前記第１のレスポンスを、前記サーバシステムから受信することと、
前記クライアントシステムにおいて記憶しているメッセージから、前記第１のレスポンスの前記インジケーションにより指示された前記第１のメッセージのセットを取り除くことと
が行われた後に実行され、前記第２のリクエストは、前記第１のレスポンスの受信に基づいて送信され、前記クライアントシステムにおいて記憶されているメッセージのコピーを含む、請求項２記載の方法。
前記第１のリクエストに含まれる前記前に受信したメッセージのインジケーションは、前のレスポンスにて前記サーバシステムから前記クライアントシステムが前に受信したメッセージを指示する、請求項２記載の方法。
前記第１のリクエストが送信された後に、
前記サーバシステムにおいて第２のメッセージのセットを記憶するステップと、
前記ファイアウォールを通過して前記クライアントシステムからの前記第２のリクエストの受信を前記サーバシステムにおいて待つステップと、
前記サーバシステムにおいて前記クライアントシステムから前記第２のリクエストを受信したとき、または前記サーバシステムにおいて特定の数のメッセージが蓄積されたとき、前記ファイアウォールを通過して前記クライアントシステムへ前記サーバシステムから前記第１のリクエストに対応する前記第１のレスポンスを送信するステップと
をさらに含み、
前記第１のレスポンスは、前記第２のメッセージのセットのコピー、及び前記第１のリクエストにより前記サーバシステムが前記クライアントシステムから受信した前記第１のメッセージのセットのインジケーションを含む、請求項１記載の方法。
前記第１のリクエストが送信される前に、
前記サーバシステムにおいてメッセージを記憶するステップと、
前記クライアントシステムからの前記第１のリクエストの受信を前記サーバシステムにおいて待つステップと、
前記第１のリクエストが送信された後に、
前記サーバシステムにおいて記憶しているメッセージから、前記第１のリクエスト内の前記インジケーションにより指示された前記前に受信したメッセージを取り除くステップと、
前記ファイアウォールを通過して前記クライアントシステムへ前記サーバシステムから前記第１のリクエストに対応する前記第１のレスポンスを送信するステップと
をさらに含み、
前記第１のレスポンスは、前記サーバシステムにおいて記憶されているメッセージのコピーを含む、請求項１記載の方法。
クライアントシステムとサーバシステムとの間の二方向通信を維持するためのシステムにおいて、
ファイアウォールを通過する少なくとも２つのリクエストを第２のネットワークデバイスへ送信する、プログラムを含んだメモリを持った第１のネットワークデバイスであって、前記第２のネットワークデバイスから前に受信したメッセージのインジケーションを含み、対応するレスポンスを要求する第１のリクエストと、該第１のリクエストの後に送信され、対応するレスポンスを要求する第２のリクエストとを含む、少なくとも２つのリクエストを送信する第１のネットワークデバイスと、
前記第１のネットワークデバイスに結合されていて、前記第１のネットワークデバイスから送信されたリクエストのうち少なくとも１つのリクエストに対するレスポンスを前記第１のネットワークデバイスに送信せずに前記少なくとも１つのリクエストを保持しておくことにより、前記第１のネットワークデバイスとの間のデータトラフィックを維持するように構成されている、第２のネットワークデバイスと
を備え、前記ファイアウォールは、前記ファイアウォールのサーバ側にある前記第２のネットワークデバイスで開始されたデータトラフィックが、前記ファイアウォールのクライアント側にある前記第１のネットワークデバイスにアクセスすることを防止するように構成されていることを特徴とするシステム。
機械実行可能命令を記憶した機械可読記憶媒体であって、前記機械実行可能命令は実行されると、クライアントシステムとサーバシステムとの間の二方向通信を維持する方法を実施するものであって、前記方法は、
前記クライアントシステムから前記サーバシステムへファイアウォールを通過する少なくとも２つのリクエストを送信するステップを含み、該送信するステップは、
前記クライアントシステムにおいて前記サーバシステムから前に受信したメッセージのインジケーションを含み、対応するレスポンスを要求する第１のリクエストを、前記ファイアウォールを通じて前記クライアントシステムから前記サーバシステムに送信することと、
前記クライアントシステムにおいて、前記ファイアウォールを通過して前記サーバシステムから送信される前記第１のリクエストに対応する第１のレスポンスを待つことと、
前記第１のリクエストを送信した後に、対応するレスポンスを要求する第２のリクエストを、前記ファイアウォールを通じて前記クライアントシステムから前記サーバシステムに送信することと
を含み、
前記サーバシステムは、前記クライアントシステムからのリクエストのうち少なくとも１つのリクエストに対応するレスポンスを前記クライアントシステムに送信せずに前記少なくとも１つのリクエストを前記サーバシステム上に保持しておくことにより、前記クライアントシステムとのオープン通信リンクを維持するように構成されていて、前記ファイアウォールは前記サーバシステムにより開始されたデータトラフィックが前記クライアントシステムへアクセスすることを防止するように構成されていることを特徴とする機械可読記憶媒体。