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

Abstract

(57)【要約】 クライアント（１０９）とネットワークサーバ（１０６）間の接続を管理するためのアダプタカード（１０８）は、サーバ（１０６）から接続管理の負担を取り除く。アダプタカード（１０８）は、埋込みプロキシアプリケーション（１３２）および通信プロトコルスタック（１３４）を備えたメモリ（１２４）、アプリケーションコードを実行するための処理ユニット（１２６）、内部ネットワーク（１０２）とインターフェース接続するためのネットワークコントローラ（１２９）、ならびにネットワークサーバ（１０６）の内部バス（１２０）とインターフェース接続するためのバスプロトコルブリッジ（１２８）を備える。プロキシアプリケーション（１３２）は、比較的に遅く、信頼度が低いネットワーク接続を介して、サーバ（１０６）の代わりに、クライアントリクエストを受信し、高速で、信頼できるバス接続を介して、サーバにそのリクエストを提示する。

Description

【発明の詳細な説明】

【０００１】 （発明の背景） （発明の分野） 本発明は、概して、ネットワークサーバに関し、より詳細には、多数のクライ
アント接続をホストするサーバに関する。さらに詳細には、本発明は、多数の比
較的遅いクライアント接続をホストするサーバ（例えば、インターネットウェブ
サーバ）に関する。

【０００２】 （背景技術の説明） インターネットウェブサーバなどのネットワークファイルサーバが、多数の比
較的遅いクライアント接続を管理することは一般的である。多数のオープン接続
は、オープン接続を管理するだけで、サーバ中央処理装置（ＣＰＵ）に実質的な
負担をかける。例えば、負荷が与えられたサーバ上のオープン接続の管理は、Ｃ
ＰＵの稼動能力を３０％〜４０％以上消費し得る。この負担は、実質的に、サー
バの一次機能（すなわち、クライアントにデータを提供する）を実行可能なＣＰ
Ｕサイクルのパーセンテージを減少させる。

【０００３】 サーバＣＰＵへの接続管理負担は、サーバソフトウェアルーチンの性能を劣化
させ、同時にオープンであり得るクライアント接続の最大数を減少させる。結果
として、ウェブを管理する会社は、数的に増加したクライアントを提供するため
に、別の冗長なサーバを提供する必要がある。別のウェブサーバを獲得および維
持するためのコストは、相当な金額である。

【０００４】 プロキシサーバは、いくつかのクライアント接続管理機能を実行し、当該分野
で公知である。しかし、このようなプロキシサーバは、サーバから離れて収納さ
れる必要があり、従って、サーバが管理する必要がある比較的遅くてエラーを起
こしやすいネットワーク接続を介してサーバと通信する必要があるということは
、当該分野で周知であり、一般的に受け入れられている。例えば、Ａｒｉ Ｌｕ
ｏｔｏｎｅｎの「Ｗｅｂ Ｐｒｏｘｙ Ｓｅｒｖｅｒｓ」（Ｐｒｅｎｔｉｃｅ
Ｈａｌｌ、１９９７）を参照のこと。本明細書中、本文献を参考として援用する
。

【０００５】 従って、必要なものは、サーバＣＰＵを接続管理負担から救済するシステムお
よび方法であり、従って、サーバが、数的に増加したクライアントをより効率的
に管理することを可能にすることである。

【０００６】 （要旨） 本発明は、複数のクライアントとサーバとの間の接続を管理するシステムおよ
び方法を提供することにより、従来技術に関連する問題を克服する。本発明は、
ホストＣＰＵから、ネットワークとホストバスとの間に置かれるアダプタカード
に、接続管理負担を肩代わりさせることを促進する。

【０００７】 アダプタカードは、ネットワークコントローラ、メモリデバイス、処理装置、
およびプロトコルアダプタを含む。メモリデバイスは、データおよびコードの格
納を提供する。コードは、ネットワークコントローラを介してネットワーク上の
クライアントと通信し、サーババスに直接結合されているプロトコルアダプタを
介してサーバと通信するプロキシアプリケーションを含む。

【０００８】 処理装置によって実行されると、プロキシアプリケーションは、ネットワーク
を介してプロキシアプリケーションとクライアントとの間にネットワーク接続を
確立することにより、そして、サーババスを介してプロキシアプリケーションと
サーバとの間にバス接続を確立することにより、クライアント接続を管理する。
さらに、メモリデバイスは、比較的少ないバス接続がサーバに対してオープンで
ある一方で、多くのネットワーク接続がクライアントに対してオープンになるこ
とを可能にするデータバッファリングを提供する。特別な実施形態において、プ
ロキシは、多数の遅いクライアント接続からバッファ内にクライアントデータを
累積し、次いで、早いバス接続を介してサーバにクライアントデータを提示する
。逆に、プロキシは、早いバス接続を介してサーバデータを受信し、サーバデー
タを一時的に格納し、次いで、遅いクライアント接続を介してクライアントにサ
ーバデータを転送する。

【０００９】 より特別な実施形態において、コードは、クライアントおよびサーバと通信す
るためにアプリケーションプロキシによって使用される通信プロトコルスタック
を含む。さらに特別な実施形態において、通信プロトコルスタックは、送信制御
プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）スタックである。

【００１０】 一実施形態において、サーバ接続は、プロキシが完全なクライアントリクエス
トを受信したことを判定して初めてオープンになる。サーバ接続は、次いで、プ
ロキシが、サーバからのクライアントリクエストに対する応答を受信した後で、
クローズになる。オプションとして、所定の数の永続的なサーバ接続がシステム
起動時にオープンになり、プロキシは、これらの永続的な接続を使用して、サー
バと通信する。

【００１１】 プロキシアプリケーションは、オプションとして、多数のアプリケーション特
有のプロキシを含み、ＨＴＴＰプロキシ、安全プロキシ、および／またはパスス
ループロキシを含むが、これらに限定されない。特定の実施形態において、プロ
キシのマスタープロセスモジュールは、クライアントデータからアプリケーショ
ン識別子（例えば、周知のポート数）を識別し、識別子の値に応じて、アプリケ
ーション特有のプロキシを１つ以上呼び出す。

【００１２】 本発明は、下記の図面を参照して説明され、ここで、同様の参照番号は、実質
的に同様の要素を指す。

【００１３】 （詳細な説明） 本発明は、異なる処理ユニット上で実行されるプロキシアプリケーションを用
いて、サーバのメインプロセッサの接続管理に関する負担の多くを軽減すること
によって、従来技術に関連する問題を克服する。以下の説明において、多くの特
定の詳細を記載し（例えば、特定の通信プロトコル、特定のソフトウェアおよび
データ構造など）、本発明の完全な理解を提供する。しかし、当業者であれば、
これらの特定の詳細から離れて、本発明を実行し得ることを理解する。他の例に
おいて、本発明を不必要に不明瞭にしないように、周知のネットワークコンポー
ネントおよびプログラミングの実施の詳細（例えば、通信プロトコルスタックを
介して接続を確立すること）は省略する。

【００１４】 図１は、物理ネットワーク媒体１０４を介して、インターネットワーク１０２
に接続されているシステム１００を示すブロック図である。特定の実施において
、システム１００は、インターネットウェブサーバであり、インターネットワー
ク１０２は、インターネットであるが、当業者であれば、本発明を、任意の種類
のネットワークサーバで実施し得ることを理解する。

【００１５】 システム１００は、ファイルサーバ（例えば、ＨＴＴＰウェブサーバ）１０６
およびアダプタカード１０８を含む。ファイルサーバ１０６は、アダプタカード
１０８を介して、インターネットワーク１０２上のクライアント１０９（１−ｎ
）に、データを提供し、かつ、このクライアント１０９（１−ｎ）からデータを
受信する。アダプタカード１０８は、クライアント１０９（１−ｎ）とアダプタ
カード１０８との間にネットワーク接続を確立、かつこれを維持し、サーバ１０
６とアダプタカード１０８との間にバス接続を確立する。したがって、このバス
が接続された後、アダプタカード１０８は、サーバ１０６の代わりに、クライア
ント１０９（１−ｎ）から通信を受信し、通信をサーバ１０６に転送し、クライ
アント１０９の代わりに、サーバ１０６から応答を受信し、この応答をクライア
ント１０９に転送する。

【００１６】 サーバ１０６は、不揮発性メモリ１１０、作業メモリ１１２、サーバ大容量デ
ータ記憶装置１１４、処理ユニット１１６および１つ以上のユーザ入力／出力（
Ｉ／Ｏ）デバイス１１８を含み、これらすべては、サーババス１２０（例えば、
ＰＣＩバス）を介して相互通信する。不揮発性メモリ１１０（例えば、リードオ
ンリーメモリおよび／または１つ以上のハードディスクドライブ）は、サーバ１
０６がパワーダウンした場合でさえも保持されるデータおよびコード用の記憶装
置を提供する。作業メモリ１１２（例えば、ランダムアクセスメモリ）は、サー
バ１０６用の動作メモリを提供し、かつ、起動の間、作業メモリ１１２内にロー
ドされる実行可能なコード（例えば、オペレーティングシステム）を含む。数あ
るプログラムの中でも、作業メモリ１１２は、サーバアプリケーション１２１お
よび通信プロトコルスタック１２２を含む。サーバアプリケーション１２１は、
サーバ１０６がネットワークサーバとして機能することを可能にする、ネットワ
ークソフトウェアアプリケーション（例えば、ＦＴＰ、ＨＴＴＰなど）を含む。
通信プロトコルスタック１２２は、インターネットワーク上において他のマシー
ンとの通信を容易にする標準のプロトコルスタック（例えば、ＴＣＰ／ＩＰ）で
ある。標準のプロトコルスタックは、当該分野において周知である。例えば、Ｗ
．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓの「ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ
、Ｖｏｌ．１」（Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、１９９４年）を参照されたい
。同文献は、本明細書中に参考として援用する。サーバ大容量データ記憶装置１
１４は、サーバが、インターネットワーク１０２に取り付けられたクライアント
１０９（１−ｎ）に提供するデータ（例えば、ＨＴＭＬページ、グラフィクスフ
ァイルなど）用のデータ記憶装置（例えば、１つ以上のハードディスクドライブ
）を提供する。処理ユニット１１６は、作業メモリ１１２内で命令を実行し、こ
れにより、サーバ１０６は、その主な機能（例えば、クライアントにデータを提
供し、クライアントからデータを受信する機能）を実行する。Ｉ／Ｏデバイス１
１８は通常、キーボード、モニタ、および／またはサーバ１０６とのユーザ双方
向通信を容易にする他のデバイスを含む。上述のコンポーネントのそれぞれは通
常、インターネットウェブサーバなどのネットワークサーバ内に見られる。

【００１７】 アダプタカード１０８は、不揮発性メモリ１２３、作業メモリ１２４、処理ユ
ニット１２６、バスプロトコルブリッジ１２８、ネットワークコントローラ１２
９を含み、これらすべては、アダプタバス１３０を介して相互通信する。不発揮
性メモリ１２３は、アダプタ１０８がパワーダウンした場合でさえも保持される
データおよびコード（例えば、起動コード）用の記憶装置を提供する。処理ユニ
ット１２６は、作業メモリ１２４内にあるコードを実行することによって、アダ
プタカード１０８に機能性を付与する。バスプロトコルブリッジ１２８は、アダ
プタバス１３０とサーババス１２０との間にインターフェースを提供し、ネット
ワークコントローラ１２９は、アダプタバス１３０とネットワーク媒体１０４と
の間にインターフェースを提供する。

【００１８】 作業メモリ１２４は、アダプタ１０８用の動作メモリを提供し、プロキシアプ
リケーション１３２および通信プロトコルスタック１３４を含む。プロキシ１３
２およびプロトコルスタック１３４は、起動時に、不揮発性メモリ１２３から作
業メモリ１２４内にロードされる。必要に応じて、プロキシ１３２およびプロト
コルスタック１３４を、サーバ１０６の不揮発性メモリ１１０またはサーバ大容
量データ記憶装置１１４を含む（ただし、これらに限定されない）１つ以上の別
のソースからロードしてもよい。プロキシ１３２が処理ユニット１２６によって
実行された場合、プロキシ１３２は、アダプタ１０８とサーバ１０６との間、お
よびアダプタ１０８とクライアント１０９との間に上述の接続を確立、かつ、管
理する。

【００１９】 本発明のこの特定の実施形態において、プロトコルスタック１２２および１３
４は、標準（例えば、ＴＣＰ／ＩＰ）のプロトコルスタックである。アダプタ１
０８内に標準の通信プロトコルスタックを採用すると、広範囲にわたった、大多
数のネットワークサーバにおいてすでに存在する標準の通信ソフトウェア（例え
ば、プロトコルスタック１２２）を用いることが容易になる。しかし、当業者で
あれば、この特定の要素（他の記載した用途（明示的に記述しない場合も含む）
）が本発明に必須要素ではないことを理解する。例えば、本発明は、サーバ１０
６およびアダプタ１０８の両方で、カスタム通信ソフトウェア（例えば、サーバ
アプリケーション１２１と、プロトコルスタック１３４またはプロキシ１３２の
いずれかとの間の直接通信）を用いて、実行し得る。さらに、本発明の特定の実
施形態において、サーバ１０６のリソース（例えば、サーバ大容量データ記憶装
置１１４）への直接アクセスをプロキシ１３２に提供することによって、この要
素を省略することが可能である。

【００２０】 バス接続１３６を介して、バスプロトコルブリッジ１２６とサーババス１２０
との間のサーバ１０６に、アダプタカード１０８を接続する。この特定の実施形
態において、バス接続１３６は、通常のバス拡張スロット（例えば、ＰＣＩスロ
ット）である。しかし、当業者であれば、ＩＳＡスロット、ＵＳＢポート、シリ
アルポートまたはパラレルポートを含む（ただし、これらに限定されない）他の
種類のバス接続によって、本発明を実施し得ることを理解する。バス接続１３６
によって、高速、大きなパケットサイズ、プロキシ１３２とサーバアプリケーシ
ョン１２１との間の比較的にエラーのない（ネットワーク接続と比較した場合）
通信が促進され、サーバ１０６の処理ユニット１１６にかかる接続管理の負担が
軽減される。要するに、プロキシ１３２（処理ユニット１１６上で実行される）
は、遅く、エラーを生じがちなネットワーク接続上でクライアント１０９と通信
して、次いで、高速バス接続１３６上で、クライアント１０９の代わりにサーバ
アプリケーション１２１と通信する。

【００２１】 図２は、プロキシ１３２およびプロトコルスタック１３４を詳細に示す作業メ
モリ１２４のブロック図である。当業者であれば、プロキシ１３２の種々のソフ
トウェアモジュールが、相互接続された機能ブロックとして図示され、一方、ソ
フトウェアモジュールは実際、ソフトウェアモジュールが処理ユニット１２６（
図１）によって実行された場合に、相互に通信し得る作業メモリ１２４内に格納
される、実行可能なコードのブロックであることを理解する。

【００２２】 プロキシ１３２は、マスタープロセスモジュール２０２、複数のクライアント
プロセスモジュール２０４（１−ｎ）、データバッファ２０６およびアプリケー
ションプロキシモジュール２０８を含む。マスタープロセスモジュールは、プロ
キシ１３２の種々のモジュールの全体制御および調整を提供する。インターネッ
トワーク１０２（図１）上のクライアント１０９からの接続リクエストに応答し
て、マスタープロセス２０２は、接続リクエストを受け取り、データバッファ２
０６内のこのクライアント接続用にデータ構造を初期化し、新規の別々のクライ
アント接続プロセス２０４を開始して接続を処理し、次いで、特定のクライアン
ト接続が確立されたことをアプリケーションプロキシ２０８に通知する。各クラ
イアントプロセス２０４は、このようなクライアント接続を処理する。アプリケ
ーションプロキシ２０８は、サーバ１０６とのバス接続を確立、かつ管理する。
データバッファ２０６は、クライアント１０９から受信され、サーバ１０６向け
のデータ、サーバ１０６から受信され、クライアント１０９向けのデータ、確立
されたクライアントおよび／またはサーバ接続に関する接続データ用の記憶装置
を提供する。

【００２３】 通信プロトコルスタック１３４は、ソケット層２１０、ＴＣＰ層２１２、ＩＰ
層２１４、ネットワークドライバ２１６およびサーババスドライバ２１８含むデ
バイス層を含むＴＣＰ／ＩＰスタックである。プロトコルスタック１３４の個々
の層のそれぞれの機能性は、当該技術において周知である。したがって、本明細
書において、詳細には説明しない。プロキシ１３２の種々のモジュールとサーバ
アプリケーション１２１との間の接続は、ソケット層２１０、ＴＣＰ層２１２、
ＩＰ層２１４およびサーババスドライバ２１８を介して確立される。プロキシ１
３２の種々のモジュール間の接続は、ソケット層２１０、ＴＣＰ層２１２、ＩＰ
層２１４およびネットワークドライバ２１６を介して、クライアント１０９によ
って接続が確立される。

【００２４】 図３は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）プロキシ２０８（１）
、パス−スループロキシ２０８（２）、セキュリティプロキシ２０８（３）およ
び「他の」のプロキシ２０８（ｆ）を含む複数のアプリケーション指定プロキシ
２０８（１〜ｆ）を含む、アプリケーションプロキシモジュール２０８を示すブ
ロック図である。マスタープロセス２０２は、クライアント接続を機能させる、
１つ以上のアプリケーション指定プロキシ２０８（１〜ｆ）を構築することによ
って、アプリケーションプロキシ２０８に確立されたクライアント接続を通知す
る。アプリケーション指定プロキシ（例えば、ＨＴＴＰプロキシ２０８（１））
を構築する一つの手段は、アプリケーション指定プロキシのキューを処理する際
に、クライアントプロセス識別子を入力することである。

【００２５】 マスタープロセス２０２は、クライアント接続リクエストに含まれるポート番
号から、特定のクライアントプロセス用にいずれのアプリケーション指定プロキ
シを実行するかを判定する。特定のネットワークアプリケーションおよび／また
はプロトコル（例えば、ファイル転送プロトコル（ＦＴＰ）、ＨＴＴＰなど）を
識別するために、周知のポート番号を用いることが標準的な実施である。例えば
、ポート番号８０は、ＨＴＴＰ接続リクエストに対応する。したがって、マスタ
ープロセス２０２は、接続リクエストがポート８０を示したことに応答して開始
される、すべてのクライアントプロセス２０４を、ＨＴＴＰプロキシ２０８（１
）に通知する。

【００２６】 ＨＴＴＰプロキシ２０８（１）は、通知されたクライアントプロセスのそれぞ
れをモニタリングする。クライアントプロセス（例えば、２０４（ｎ））によっ
て、完全なＨＴＴＰリクエストがデータバッファ２０６内に受信および格納され
たことを、ＨＴＴＰプロキシ２０８（１）が判定すると、ＨＴＴＰプロキシ２０
８（１）は、サーバへの接続を開始し、リクエストをサーバに伝送し、サーバか
ら応答を受信し、データバッファ２０６内に応答を格納し、次いでサーバ接続を
終了する。次いで、サーバ応答を、関連するクライアントプロセス２０４（ｎ）
によって、クライアント１０９（ｎ）に伝送する。

【００２７】 マスタープロセス２０２が、他のアプリケーション指定プロキシのいずれとも
対応しないポート番号を有する接続リクエストを受信すると、マスタープロセス
２０２は、パス−スループロキシ２０８（２）に通知する。パス−スループロキ
シ２０８（２）は単に、サーバ接続を開始し、データバッファ２０６からサーバ
１０６に、関連するクライアントプロセス２０４から受信されたデータを転送し
、次いでサーバ接続を終了する。

【００２８】 マスタープロセス２０２は、関連するポート番号にかかわらず、すべてのクラ
イアント接続を、いくつかのアプリケーション指定プロキシに通知し得る。例え
ば、セキュリティプロキシ２０８（３）は、例えば、他のアプリケーション指定
プロキシのうちの一つを実施する前に、認定表示のない接続リクエストに応答し
て開始される任意のクライアントプロセスを終了することによって、すべてのク
ライアント接続リクエストをスクリーニングするために動作する。

【００２９】 図３に「他」のプロキシ２０８（ｆ）を含み、アプリケーションプロキシ２０
８が、キャッシュ（ｃａｃｈｉｎｇ）ＨＴＴＰプロキシアプリケーション、電子
メールアプリケーションおよびファイル転送アプリケーションを含む（ただし、
これらに限定されない）特定のアプリケーションに所望である、任意の現在公知
のプロキシ、または将来開発されるプロキシを含み得ることを示す。

【００３０】 図４は、データスループロキシ１３２の伝送に影響を与えるように、データバ
ッファ２０６内に実施される、クライアントデータ構造４０２（１−ｎ）および
プロキシデータ構造４０４（１−ｆ）の例を示す。マスタープロセス２０２は、
アプリケーションプロキシ２０８内で、各クライアントプロセス２０４用に一つ
のクライアントデータ構造４０２および各アプリケーション指定プロキシ用に一
つのプロキシデータ構造４０４を作成および初期化する。

【００３１】 各クライアントデータ構造４０２は、クライアントソケット４０６、サーバソ
ケット４０８、接続状態４１０、入力キュー４１２、出力キュー４１４およびア
プリケーションプロキシデータ４１６を含む。各クライアント接続（例えば、接
続（ｎ））に関して、クライアントソケット４０６（ｎ）およびサーバソケット
４０８（ｎ）はそれぞれ、クライアント１０９（ｎ）およびサーバ１０６のＩＰ
アドレスおよびポート番号を含み、したがって、クライアントプロセス２０４（
ｎ）のうちの一つと、各クライアントデータ構造４０２（ｎ）が一意的に関連付
けられる。接続状態４１０（ｎ）は、接続（ｎ）の現在の状態（例えば、受信さ
れた完全なリクエスト、受信された応答など）を示す。特定のデータ構造４０２
（ｎ）と関連付けられたクライアントプロセス２０４（ｎ）によって、クライア
ント１０９（ｎ）から受信されたデータを格納および蓄積するために、入力キュ
ー４１２（ｎ）を用いる。クライアントプロセス２０４（ｎ）によって、クライ
アント１０９（ｎ）に転送されるべきアプリケーションプロキシ２０８からデー
タを格納するために、出力キュー４１４（ｎ）を用いる。特定のアプリケーショ
ンプロキシ（例えば、フラグなど）に特定の任意の情報を格納するために、アプ
リケーションプロキシデータ４１６（ｎ）を提供する。

【００３２】 各プロキシデータ構造（例えば、４０４（ｆ））は、クライアントキュー４１
８（ｆ）、クライアント準備キュー４２０（ｆ）および読み出し保留キュー４２
２（ｆ）を含む。クライアントキュー４１８（ｆ）は、プロキシデータ構造４０
４（ｆ）が対応する、特定のアプリケーションプロキシ（ｆ）と関連する各クラ
イアントプロセス２０４用のクライアントプロセス記述子（例えば、関連するク
ライアントデータ構造４０２のポインタ）を含む。クライアント準備キュー４２
０（ｆ）は、関連するアプリケーションプロキシ（ｆ）によって処理する（例え
ば、サーバ１０６に伝送する）準備が整った入力キュー４１２内にデータを有す
る、各クライアントデータ構造４０２用のクライアントプロセス記述子を含む。

【００３３】 当業者であれば、上述のクライアントデータ構造４０２およびプロキシデータ
構造４０４は本質的には例示であり、本発明によって、他のデータ構造を採用し
得ることを理解する。このような別のデータ構造の構成は必然的に、採用される
特定のアプリケーション指定プロキシの機能および構造に依存する。

【００３４】 図５は、本発明による、クライアントとサーバとの間の接続を管理する特定の
方法５００をまとめたフローチャートである。プロキシ１３２は、第１の工程５
０２において、クライアント１０９とのネットワーク接続を確立し、次いで第２
の工程５０４において、ネットワーク接続を介して、クライアント１０９から通
信（例えば、ＨＴＴＰリクエスト）を受信する。次に、プロキシ１３２は、第３
の工程５０６において、サーバ１０６とのバス接続を確立し、次いで第４の工程
５０８において、バス接続を介して、サーバ１０６に、受信したクライアント通
信を転送する。次いで、プロキシ１３２は、第５の工程５１０において、サーバ
１０６から、クライアント通信への応答（例えば、ＨＴＭＬデータ）を受信し、
第６の工程５１２において、クライアントネットワーク接続を介してクライアン
ト１０９に応答を伝送する。最後に、プロキシ１３２は、第７の工程５１４にお
いて、終了すべき（例えば、シャットダウンすべき）信号があるか否かを判定し
、終了すべき信号がある場合には、方法５００は終了する。第７の工程５１４に
おいて、終了すべき信号がない場合には、方法５００は、第１の工程５０２に戻
り、別のクライアント１０９とのネットワーク接続を確立する。

【００３５】 図６は、方法５００の第１の工程５０２を実行する（クライアントとのネット
ワーク接続を確立する）一つの特定の方法６００をまとめたフローチャートであ
る。第１の工程において、マスタープロセス２０２は、インターネットワーク１
０２に接続する。次いで、第２の工程６０４において、マスタープロセス２０２
は、インターネットワーク１０２上のトラフィックを聞き、クライアント１０９
から接続リクエストがあるか否かを判定する。クライアントの接続リクエストが
ない場合には、方法６００は終了する。クライアント１０９（ｎ）から接続リク
エストがある場合には、第３の工程６０６において、マスタープロセス２０２は
、クライアント１０９（ｎ）から接続リクエストを受け取り、クライアントプロ
セス２０４（ｎ）を開始し、接続を処理し、データバッファ２０６内のクライア
ントデータ構造４０２（ｎ）を初期化する。次に、第４の工程６０８において、
マスタープロセス２０２は、クライアント接続リクエストからプロキシアプリケ
ーション識別子（例えば、ポート番号）を区別し、識別子の値に応じて、各プロ
キシデータ構造４０４のクライアントキュー４１８内に、クライアントプロセス
記述子（例えば、クライアントデータ構造４０２（ｎ）のポインタ）を書き込む
ことによって、一つ以上のアプリケーションプロキシ２０８（１〜ｆ）に通知す
る。最後に、第５の工程６１０において、マスタープロセス２０２は、最大許容
数のクライアント接続がオープンであるか否かを判定する。最大数のクライアン
ト接続がオープンである場合には、方法６００は終了する。最大数のクライアン
ト接続がオープンでない場合には、方法６００は、第２の工程６０４に戻り、別
の接続リクエストを聞く。

【００３６】 図７は、方法５００の（クライアント１０９からの通信を受ける）第２の工程
５０４を実行する方法７００を概説するフローチャートである。第１の工程７０
２で、マスタープロセス２０２は、データを受信するために処理されるべきクラ
イアントプロセス２０４が存在するどうかを判断する。マスタープロセス２０２
がクライアントプロセス２０４（１−ｎ）の全てをすでに処理している場合、方
法７００は終了する。処理していない場合、第２の工程７０４で、マスタープロ
セス２０２が第１のクライアントプロセス２０４（１）を呼ぶ。次いで、第３の
工程７０６で、クライアントプロセス２０４（１）は、クライアント１０９（１
）からデータが入来しているかどうかを判断するために、クライアント接続（例
えば、ＴＣＰバッファ）をチェックする。第１のクライアントプロセス２０４（
１）に対する入来データがない場合、方法７００は、残りのクライアントプロセ
ス２０４（２−ｎ）を処理するために、第１の工程７０２に戻る。第３の工程７
０６で、クライアントプロセス２０４（１）が、クライアント１０９（１）から
の入来データが存在すると判断した場合、第４の工程７０８で、クライアントプ
ロセス２０４（１）は、入力キュー４１２（１）がクライアントデータを受信す
るために利用可能であるかを判断するために、クライアントデータ構造４０２（
１）をチェックする。入力キュー４１２（１）が利用可能でない場合、方法７０
０は、残りのクライアントプロセス２０４（２−ｎ）を処理するために、第１の
工程７０２に戻る。第４の工程７０８で、クライアントプロセス２０４（１）は
、入力キュー４１２（１）がデータの受信のために利用可能であると判断した場
合、次いで、第５の工程７１０で、クライアントプロセス２０４（１）は、入来
するクライアントデータを入力キュー４１２（１）に転送する。次いで、第６の
工程７１２で、クライアントプロセス２０４（１）は、入力キューに蓄積された
データが完全なリクエスト（すなわち、サーバ１０６への転送準備が完了したデ
ータ、例えば、完全なＨＴＴＰリクエスト）を構成しているかどうかを判断する
。データが完全なリクエストを構成していない場合、方法７００は、残りのクラ
イアントプロセス２０４（２−ｎ）を処理するために、第１の工程７０２に戻る
。しかしながら、クライアントプロセス２０４（１）は、第６の工程７１２で、
入力キュー４１２（１）内のデータが完全なリクエストを構成していると判断し
た場合、第７の工程７１４で、クライアントプロセスは、例えば、完全なリクエ
ストが存在することを示すように接続状態４１０（１）を設定することにより、
完全なリクエストが存在することをプロキシアプリケーション２０８に通知する
。次いで、方法７００は、処理すべきクライアントプロセス２０４（２−ｎ）が
さらに存在するかどうかを判断するために、第１の工程７０２に戻る。

【００３７】 図８は、方法５００の（サーバ１０６とのバス接続を確立する）第３の工程５
０６を実行する方法８００を概説するフローチャートである。第１の工程８０２
で、１つ目のアプリケーションプロキシ２０８（１）が、プロキシデータ構造４
０４（１）のクライアントキュー４１８（１）から、第１のクライアント記述子
を引き出す。次いで、第２の工程８０４で、プロキシ２０８（１）は、第１のク
ライアントがその入力キュー４１２内に完全なリクエストを有するかどうかを判
断するために、第１のクライアント記述子により特定されるクライアントデータ
構造４０２の接続状態４１２をチェックする。接続状態４１２が完全なリクエス
トを示す場合、第３の工程８０６で、プロキシ２０８（１）は、クライアント準
備完了キュー４２０（１）にクライアント記述子を加える。次に、第４の工程８
０８で、プロキシ２０８（１）は、サーバ１０６に対して、最大数の接続が開か
れているかどうかを判断する。最大数のサーバ接続がすでに開かれている場合、
方法８００は終了する。最大数のサーバ接続がまだ開かれていない場合、第５の
工程８１０で、プロキシ２０８（１）は、サーバ１０６とのバス接続を開き、関
連づけられたクライアントデータ構造４０２のサーバソケット４０８に接続情報
を書き込む。次に、第６の工程８１２で、プロキシ２０８（１）は、クライアン
トキュー４１８（１）内の最後の記述子をチェックしたかどうかを判断する。最
後の記述子がチェックされている場合、方法８００は終了する。最後の記述子が
チェックされていなければ、方法８００は、クライアントキュー４１８（１）内
の次の記述子を引き出すために、第１の工程８０２に戻る。第２の工程８０４で
、プロキシ２０８（１）が、完全なクライアントリクエストが受信されていない
と判断した場合、方法８００は、直接、第６の工程８１２に進む。一旦、プロキ
シデータ構造４０４（１）のクライアントキュー４１８（１）内の記述子の全て
が処理されると、方法８００または同様の方法が、他のアプリケーションプロキ
シ２０８（２−ｆ）の各々に対して繰り返される。

【００３８】 図９は、方法５００の（サーバ１０６にクライアント通信を転送する）第４の
工程５０８を実行する方法９００を概説するフローチャートである。第１の工程
９０２で、プロキシ２０８（１）は、プロキシデータ構造４０４（１）のクライ
アント準備完了キュー４２０（１）から、第１のクライアント記述子を引き出す
。次いで、第２の工程９０４で、プロキシ２０８（１）は、サーバ接続が開いて
いるかどうかを判断するために、第１のクライアントのデータ構造４０２のサー
バソケット４０８をチェックする。サーバ接続が開いている場合、第３の工程９
０６で、プロキシ２０８（１）は、開いたサーバ接続を介して、クライアント入
力キュー４１２からサーバ１０６にクライアントデータ（例えば、ＨＴＴＰリク
エスト）を転送する。次に、第４の工程９０８で、プロキシ２０８（１）は、ク
ライアント準備完了キュー４２０（１）から読み出し保留キュー４２２（１）に
クライアント記述子を移動する。次いで、第５の工程９１０で、プロキシ２０８
（１）は、クライアント準備完了キュー４２０（１）内の最後のクライアントが
チェックされたかどうかを判断する。チェックされていない場合、方法９００は
、クライアント準備完了キュー４２０（１）内の次のクライアントをチェックす
るために、第１の工程９０２に戻る。最後のクライアントがチェックされている
場合、方法９００は終了する。第２の工程９０４で、プロキシ２０８（１）が、
特定のクライアントのために開いたサーバ接続が存在しないと判断した場合、方
法９００は、クライアント準備完了キュー４２０（１）内の最後のクライアント
がチェックされたかどうかを判断するために、直接、第５の工程９１０に進む。
一旦、プロキシデータ構造４０４（１）のクライアント準備完了キュー４２０（
１）内の記述子の全てが処理されると、方法９００または同様の方法が、他のア
プリケーションプロキシ２０８（２−ｆ）の各々に対して繰り返される。

【００３９】 図１０は、方法５００の（サーバ１０６から応答を受信する）第５の工程５１
０を実行する方法１０００を概説するフローチャートである。第１の工程１００
２で、プロキシ２０８（１）は、読み出し保留キュー４２２（１）が空であるか
どうかを判断し、空である場合、方法１０００が終了する。読み出し保留キュー
４２２（１）が空でない場合、第２の工程１００４で、プロキシ２０８（１）が
、読み出し保留キューから第１のクライアント記述子を引き出す。次に、第３の
工程１００６で、プロキシ２０８（１）が、第１のクライアント記述子により特
定されるクライアントデータ構造４０２のサーバソケット４０８内で特定された
、開いたサーバ接続上に入来サーバデータ（すなわち、クライアントリクエスト
への応答）が存在するかどうかを判断するために、その接続をチェックする。そ
の接続上に入来サーバデータが存在しない場合、方法１０００は、読み出し保留
キュー内の次のクライアントをチェックするために、第２の工程１００４に戻る
。入来サーバデータが存在する場合、第４の工程１００８で、プロキシ２０８（
１）は、クライアント記述子により特定されるクライアントデータ構造４０２の
出力キュー４１４が利用可能であるかどうかを判断するためのチェックを行う。
出力キュー４１４が利用可能でない場合、方法１０００は、読み出し保留キュー
４２２（１）内の次のクライアント記述子をチェックするために、第２の工程１
００４に戻る。出力キュー４１４が利用可能である場合、第５の工程１０１０で
、プロキシ２０８（１）は、クライアントデータ構造４０２の出力キュー４１４
に、入来サーバデータを移動する。次に、第６の工程１０１２で、プロキシ２０
８（１）は、サーバデータが「ファイルの終わり」インジケータを含むかどうか
を判断する。含んでいない場合、第７の工程１０１４で、プロキシ２０８（１）
は、読み出し保留キュー４２２（１）内の最後のクライアント記述子が処理され
たかどうかを判断するためのチェックを行う。処理されている場合、方法１００
０は終了する。処理されていない場合、方法１０００は、読み出し保留キュー４
２２（１）から次のクライアント記述子を読み出すために、工程１００４に戻る
。

【００４０】 第６の工程１０１２で、プロキシ２０８（１）が、サーバデータが「ファイル
の終わり」インジケータを含むと判断した場合、方法１０００は、プロキシ２０
８（１）が読み出し保留キューからクライアント記述子を取り除く、第８の工程
１０１６に進み、次いで、第９の工程１０１８で、サーバ接続を閉じる。第９の
工程１０１８の後、方法１０００は、第７の工程１０１４に戻る。一旦、プロキ
シデータ構造４０４（１）の読み出し保留キュー４２２（１）内の記述子の全て
が処理されると、方法１０００または同様の方法が、他のアプリケーションプロ
キシ２０８（２−ｆ）の各々に対して繰り返される。

【００４１】 図１１は、方法５００の（クライアント１０９にデータを送信する）第６の工
程５１２を実行する方法１１００を概説するフローチャートである。第１の工程
１１０２で、マスタープロセス２０２は、第１のクライアントプロセス２０４（
１）を呼ぶ。次いで、第２の工程１１０４で、第１のクライアントプロセス２０
４（１）は、クライアントデータ構造４０２（１）の出力キュー４１４（１）内
にデータが存在するかどうかを判断する。出力キュー４１４（１）内にデータが
存在しない場合、方法１１００は、マスタープロセス２０２が残りのクライアン
トプロセス２０４（２−ｎ）のうちの次のクライアントプロセスを呼ぶ、第１の
工程１１０２に戻る。しかしながら、第２の工程１１０４で、クライアントプロ
セス２０４（１）が、出力キュー４１４（１）内にデータが存在すると判断した
場合、第３の工程１１０６で、クライアントプロセス２０４（１）は、クライア
ントネットワーク接続がデータを受信する準備が完了しているかどうかを判断す
る。クライアントネットワーク接続が準備完了していない場合、方法１１００は
第１の工程１１０２に戻る。クライアントネットワーク接続が準備完了している
場合、第４の工程１１０８で、クライアントプロセス２０４（１）は、クライア
ント接続（例えば、ＴＣＰ出力バッファ）に、出力キュー４１４（１）内のデー
タの少なくとも一部を移動する。次に、第５の工程１１１０で、マスタープロセ
ス２０２は、最後のクライアントプロセスが呼ばれたかどうかを判断する。呼ば
れている場合、方法１１００は終了する。呼ばれていない場合、方法１１００は
、残りのクライアントプロセス２０３（２−ｎ）のうちの次のクライアントプロ
セスを呼ぶために、第１の工程１１０２に戻る。

【００４２】 これで、本発明の特定の実施形態の説明を終える。説明した特徴の多くは、本
発明の範囲を逸脱することなく、置換、変更、または省略され得る。例えば、ア
ダプタ１０８の機能素子（例えば、処理ユニット１２６およびプロキシ１３２）
は、着脱可能アダプタカードに設けられる代わりに、サーバに直接組み入れられ
得る。さらに、代替的なデータ構造が、提供された例示的なデータ構造と置き換
えられ得る。また、本明細書中において開示された方法およびルーチンの特定の
順序は、本発明の必要不可欠な要素であるとは見なされない。さらに別の例とし
て、マスタープロセス２０２は、起動時に、サーバ１０６との好適な数の持続的
バス接続を開き、アプリケーションプロキシ２０８（１−ｆ）によるこれらの接
続の使用を管理するように構成され得るため、サーバ１０６がバス接続を繰り返
し開閉する必要がなくなる。示された特定の実施形態からのこれらおよび他の逸
脱は、特に、前述の開示より当業者には明らかである。

【図面の簡単な説明】

【図１】 図１は、本発明によるサーバおよびアダプタカードのブロック図である。

【図２】 図２は、図１のアダプタカードの作業メモリのブロック図であり、プロキシモ
ジュールをより詳細に示す。

【図３】 図３は、図２のアプリケーションプロキシモジュールをより詳細に示すブロッ
ク図である。

【図４】 図４は、図２のデータバッファ内に格納されているデータの少なくともいくつ
かに関する例示的なデータ構造を示すブロック図である。

【図５】 図５は、本発明によるクライアントとサーバとの間の接続を管理する１つの方
法を要約するフローチャートである。

【図６】 図６は、図５の方法の第１のステップを実行する１つの方法を要約するフロー
チャートである。

【図７】 図７は、図５の方法の第２のステップを実行する１つの方法を要約するフロー
チャートである。

【図８】 図８は、図５の方法の第３のステップを実行する１つの方法を要約するフロー
チャートである。

【図９】 図９は、図５の方法の第４のステップを実行する１つの方法を要約するフロー
チャートである。

【図１０】 図１０は、図５の方法の第５のステップを実行する１つの方法を要約するフロ
ーチャートである。

【図１１】 図１１は、図５の方法の第６のステップを実行する１つの方法を要約するフロ
ーチャートである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ， ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ， ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ， ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，Ｋ Ｒ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ， ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，Ｓ Ｉ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 ウォーリー， ダブリュー． スペンサー ザ サード アメリカ合衆国 カリフォルニア 94019， ハーフ ムーン ベイ， コリアス ア ベニュー 311 (72)発明者 マクドネル， エオイン ビー． アメリカ合衆国 カリフォルニア 94087， サニーベイル， ヨークタウン ドライ ブ 1057 (72)発明者 ヴァスタノ， ジョン エイ． アメリカ合衆国 カリフォルニア 95051， サンタ クララ， カブリロ アベニュ ー 3497 (72)発明者 ウェザーフォード， ウィリアム ティ ー． アメリカ合衆国 カリフォルニア 94402， サン マテオ， フォージ ロード 1556 Ｆターム(参考） 5B085 BA06 BG02 BG07 5B089 GA11 GA21 JA35

Claims (47)

【特許請求の範囲】
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. 【請求項２７】 電子デバイスに請求項８に記載の工程を実行させるコード
    を内部に組み込んだ、コンピュータ読み出し可能媒体。
28. 【請求項２８】 電子デバイスに請求項９に記載の工程を実行させるコード
    を内部に組み込んだ、コンピュータ読み出し可能媒体。
29. 【請求項２９】 電子デバイスに請求項１０に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
30. 【請求項３０】 電子デバイスに請求項１１に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
31. 【請求項３１】 電子デバイスに請求項１２に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
32. 【請求項３２】 電子デバイスに請求項１３に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
33. 【請求項３３】 電子デバイスに請求項１４に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
34. 【請求項３４】 電子デバイスに請求項１５に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
35. 【請求項３５】 電子デバイスに請求項１６に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
36. 【請求項３６】 電子デバイスに請求項１７に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
37. 【請求項３７】 電子デバイスに請求項１８に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
38. 【請求項３８】 電子デバイスに請求項１９に記載の工程を実行させるコー
    ドを内部に組み込んだ、コンピュータ読み出し可能媒体。
39. 【請求項３９】 内部バスを備えたサーバをネットワークに結合するための
    アダプタカードであって、該アダプタカードは、 該ネットワーク上のクライアントと通信するためのネットワークコントローラ
    と、 データおよびコードを格納するためのメモリデバイスであって、該コードはプ
    ロキシアプリケーションを含む、メモリデバイスと、 該メモリデバイスと結合された、該コードを実行するための処理ユニットと、 該処理ユニットに結合され、かつ該内部バスに結合するように適合された、該
    サーバと通信するためのプロトコルアダプタと を備える、アダプタカード。
40. 【請求項４０】 前記コードは、通信プロトコルスタックをさらに含む、請
    求項３９に記載のアダプタカード。
41. 【請求項４１】 前記通信プロトコルスタックは、標準ＴＣＰ／ＩＰプロト
    コルスタックを含む、請求項４０に記載のアダプタ。
42. 【請求項４２】 前記プロキシアプリケーションは、セキュリティプロキシ
    を含む、請求項３９に記載のアダプタカード。
43. 【請求項４３】 前記プロキシアプリケーションは、パススループロキシを
    含む、請求項３９に記載のアダプタカード。
44. 【請求項４４】 前記プロキシアプリケーションは、ＨＴＴＰプロキシを含
    む、請求項３９に記載のアダプタカード。
45. 【請求項４５】 前記クライアントから受信したデータを格納するためのデ
    ータバッファをさらに備える、請求項３９に記載のアダプタカード。
46. 【請求項４６】 前記プロキシアプリケーションは、前記クライアントのう
    ちの１つから受信した接続リクエストに応答し、かつ該クライアントとの接続を
    確立して、該確立された接続を維持するために、新たなクライアントプロセスモ
    ジュールを開始するように動作する、マスタープロセスモジュールを含む、請求
    項３９に記載のアダプタカード。
47. 【請求項４７】 前記マスタープロセスモジュールは、さらに、前記確立さ
    れた接続を前記プロキシアプリケーションに通知するように動作する、請求項４
    ６に記載のアダプタカード。