JP3229237B2 - 通信プロセス・プール内の実行ユニットを動的に管理するための方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般に、コンピュ
ータ・ネットワーク上の通信、ならびにこのような通信
を容易にするコンピュータ・プロトコルに関する。より
具体的には、本発明は、ネットワーク・プロトコル・ア
クセスのためのオブジェクト指向通信インタフェースに
関する。

【０００２】

【従来の技術】非常に初期のコンピュータ・システム
は、ディスプレイやプリンタなどの周辺装置と入力装置
が接続された、スタンドアロン・プロセッサであった。
各コンピュータ・システムは独立しており、コンピュー
タ・システム間の通信はほとんど行われていなかった。
現在、ローカル・エリア・ネットワークや広域ネットワ
ークなどのコンピュータ・ネットワークでは、複数のコ
ンピュータ・システムを相互接続し、ネットワークに結
合された各種コンピュータ・システムから得られるデー
タ、サービス、資源の共有を含む様々な利益を達成する
ことが周知になっている。

【０００３】ネットワークにより各種コンピュータ・シ
ステム間で通信するために、多くの通信プロトコルが開
発された。周知のネットワーク・プロトコルの例として
は、システム・ネットワーク体系（ＳＮＡ）、伝送制御
プロトコル／インターネット・プロトコル（ＴＣＰ／Ｉ
Ｐ）、ネットワーク基本入出力システム（ＮｅｔＢＩＯ
Ｓ）、インターネット・パケット交換／順次パケット交
換（ＩＰＸ／ＳＰＸ）などがある。その他の通信プロト
コルも既知であり、広く使用され、ＩＳＯ、ＩＥＥＥ、
その他の組織の様々な規格に記載されている。コンピュ
ータ・ネットワークの理解を容易にするため、ネットワ
ークの諸機能および関連ソフトウェアは一連の層として
記述されることが多い。ネットワークにより配布された
アプリケーションの１つのコピーとその配布されたアプ
リケーションの別のコピーとの間のデータ転送は、基礎
となる一連の通信層のサービスを使用することによって
行われる。一般に、１つのコンピュータ・システム内の
各層は、それぞれの層がそれぞれの対等層とやりとりす
るように、受信側コンピュータ・システム内に対応層を
備えている。

【０００４】７層の開放型システム間相互接続（ＯＳ
Ｉ）モデルは、ネットワーク通信の説明のうち、最もよ
く知られたものの１つであるが、多くの通信実施態様で
は、１つまたは複数のＯＳＩ層を結合するかまたは省略
している。ＯＳＩの物理層は、ネットワークと直接やり
とりする最下層である。これは、物理的接続部を越えて
実際にビット・ストリームをネットワークに伝送するこ
とを含む。第２の層は、物理層ストリームの多重化とフ
レーム化を行ってメッセージにするデータリンク層であ
る。これは、エラー検出、同期情報、物理チャネル管理
ももたらす。第３の層は、ネットワークによる情報の経
路指定を制御するネットワーク層である。アドレス指
定、ネットワークの初期設定、切替え、セグメント化、
フォーマット化などのサービスはこの層に用意される。
データ送達の肯定応答は、この層で行われる場合もあれ
ば、データリンク層で行われる場合もある。

【０００５】第４の層は、透過データの送達、多重化、
マッピングを制御するトランスポート層である。これよ
り下の諸層で行われる最善の努力とは対照的に、アプリ
ケーションが必要とすれば、信頼性の高い送達がこの層
で行われる。欠落データの再伝送、順不同で送達された
データの再配列、伝送エラーの訂正などのサービスは、
通常、この層で行われる。第５の層は、トランスポート
層からの情報を使用して、セッションと呼ばれるネット
ワーク内の２つのノード間の共通活動として個々のデー
タをグループ化するセッション層である。第６の層は、
セッション層と第７の層であるアプリケーション層との
インタフェースを含むプレゼンテーション層である。プ
レゼンテーション層は、セッション層の整合性を損なわ
ずに、アプリケーション層で使用するための情報を提供
する。また、プレゼンテーション層はデータの解釈とフ
ォーマットおよびコードの変換を行うのに対し、アプリ
ケーション層はユーザ・アプリケーション・インタフェ
ースと管理機能を提供する。

【０００６】もう１つの周知のネットワーク規格はＩＥ
ＥＥ規格である。ＩＥＥＥモデルとＯＳＩとの主な相違
点は、ＯＳＩの第２の層であるデータリンク層が媒体ア
クセス制御（ＭＡＣ）副層と論理リンク制御（ＬＣＣ）
副層という２つの副層に分割されることである。媒体ア
クセス制御は、その制御アクセスにおける通信媒体への
媒体アクセス接続を管理する。論理リンク制御は、関連
するデータ・リンク制御が指定するプロトコルをサポー
トするための状態マシンを提供する。

【０００７】もう１つの周知の技術は、オブジェクトと
いうプログラミング・エンティティにデータとメソッド
をカプセル化するオブジェクト指向プログラミングであ
る。公用インタフェースにより所与のメソッドとデータ
を保護することにより、オブジェクト指向プログラム
は、各コンポーネントを他のコンポーネントに対する変
更から隔離しながら、最小限の再プログラミングによっ
て必要な諸機能を提供することができる。オブジェクト
指向の技術、概念、規則に関する詳細な背景情報につい
ては、グレイディー（Grady Booch）によるObject Orie
nted Design WithApplications (The Benjamin/Cummins
Publishing Company, 1990)およびB. マイヤー（Meye
r）によるObject Oriented Software Construction (Pr
entice Hall, 1988)などの参考文献を参照されたい。

【０００８】マルチプロセッサ・ネットワークにおける
通信プロトコルの一般領域に対してオブジェクト指向技
術を応用しようという試みは、すでにいくつか行われて
きた。以下に示すように、それは依然として本発明の実
り多い分野である。

【０００９】

【発明が解決しようとする課題】サーバ・システム内の
実行ユニットのプールを動的に管理するための方法、シ
ステム、製品であって、そのプールは、クライアント・
プロセスとサーバ・プロセスとの間の通信プロセス専用
である。通信プロセス・プール内に最小数および最大数
の実行ユニットが確立される。最小数の実行ユニット
は、典型的なクライアント・ロードをサポートするのに
必要な数である。最大数の実行ユニットは、サーバ・シ
ステムにとって過負荷にならずにピーク・クライアント
・ロードをサポートするための上限である。クライアン
トによるサービス要求がサーバ・システムによって受信
されると、いくつかの判定が行われる。まず、その要求
に実行ユニットを割り当てると、通信プロセス・プール
内の現行数の実行ユニットが最大数の実行ユニットを上
回ることになるかどうかが判定される。上回る場合、ク
ライアント要求は拒否される。次に、その要求に実行ユ
ニットを割り当てると、その要求を行うクライアント・
タスクに割り当てられた実行ユニットの数がクライアン
ト・タスク用の割り当てられた実行ユニットの数を上回
ることになるかどうかが判定される。上回る場合、クラ
イアント要求は拒否される。判定結果が否定であればク
ライアント要求が許可され、それにより、通信プロセス
・プール内の実行ユニットがクライアント要求に割り当
てられる。

【００１０】

【課題を解決するための手段】システム・パフォーマン
スを改善するために通信プール内の未使用の実行ユニッ
トの数を増減する必要があるかどうかを判定するため、
未使用の実行ユニットの数を定期的に検討する。

【００１１】上記の目的、特徴、および利点は、添付図
面と以下の説明を参照すれば、さらに容易に理解される
だろう。

【００１２】

【発明の実施の形態】本発明は、複数通りのオペレーテ
ィング・システム下で様々なコンピュータまたは複数の
コンピュータの集合で動作することができる。このコン
ピュータは、たとえば、パーソナル・コンピュータ、ミ
ニ・コンピュータ、メインフレーム・コンピュータ、他
のコンピュータからなる分散ネットワークで動作するコ
ンピュータなどにすることができる。コンピュータの具
体的な選択はディスクやディスク記憶装置の要件によっ
てのみ制限されるが、ＩＢＭのＰＣシリーズのコンピュ
ータであれば、本発明に使用できるはずである。ＩＢＭ
のＰＣシリーズのコンピュータの詳細については、IBM
PC 300/700 Series Hardware Maintenance, Publicatio
n No. S83G-7789-03およびUser's Handbook IBM PC Ser
ies 300 and 700,Publication No. S83G-9822-00等を参
照されたい。ＩＢＭのパーソナル・コンピュータが動作
可能なオペレーティング・システムの１つは、ＩＢＭの
OS/2 Warp 3.0である。ＩＢＭのOS/2 Warp 3.0オペレー
ティング・システムの詳細については、OS/2 Warp V3 T
echnical Library, Publication No. GB0F-7116-00等を
参照されたい。

【００１３】代替実施例のコンピュータ・システムは、
ＡＩＸ（ＴＭ）オペレーティング・システム上で動作す
るＩＢＭのＲＩＳＣシステム／６０００（ＴＭ）系列の
コンピュータにすることもできる。ＲＩＳＣシステム／
６０００の様々なモデルについては、RISC System/600
0, 7073 and 7016 POWERstation and POWERserver Hard
ware Technicalという参考文献（資料番号SA23-2644-0
0）など、ＩＢＭの多くの資料に記載されている。ＡＩ
Ｘオペレーティング・システムについては、General Co
ncepts and Procedure -- AIX for RISC System/6000
（資料番号SC23-2202-02）ならびにＩＢＭのその他の資
料に記載されている。

【００１４】図１には、システム・ユニット１１と、キ
ーボード１２と、マウス１３と、ディスプレイ１４とを
含むコンピュータ１０がブロック図形式で示されてい
る。システム・ユニット１１は、１つのシステム・バス
または複数のシステム・バス２１を含み、このシステム
・バスには様々な構成要素が結合され、このシステム・
バスにより様々な構成要素間の通信が行われる。マイク
ロプロセッサ２２は、システム・バス２１に接続され、
同じくシステム・バス２１に接続された読取り専用メモ
リ（ＲＯＭ）２３とランダム・アクセス・メモリ（ＲＡ
Ｍ）２４によってサポートされている。ＩＢＭのＰＳ／
２シリーズのコンピュータに搭載されているマイクロプ
ロセッサは、３８６または４８６マイクロプロセッサを
含む、インテルのマイクロプロセッサ・ファミリーの１
つである。しかし、６８０００、６８０２０、６８０３
０マイクロプロセッサなどのモトローラのマイクロプロ
セッサ・ファミリーや、ＩＢＭ製のＰｏｗｅｒＰＣチッ
プまたはヒューレット・パッカード、サン、モトローラ
などが製造するものなどの様々な縮小命令セット・コン
ピュータ（ＲＩＳＣ）マイクロプロセッサを含み、かつ
これらに限定されないマイクロプロセッサも、特定のコ
ンピュータで使用することができる。

【００１５】ＲＯＭ２３は、数あるコードのうち、やり
とりや、ディスク・ドライブおよびキーボードなどの基
本的なハードウェア操作を制御する、基本入出力システ
ム（ＢＩＯＳ）を含んでいる。ＲＡＭ２４は、オペレー
ティング・システムとアプリケーション・プログラムの
ロード先になるメイン・メモリである。メモリ管理チッ
プ２５は、システム・バス２１に接続され、ＲＡＭ２４
とハード・ディスク・ドライブ２６およびフロッピー・
ディスク・ドライブ２７とのデータの受渡しを含む直接
メモリ・アクセス操作を制御する。同じくシステム・バ
ス２１に結合されたＣＤ−ＲＯＭ３２は、マルチメディ
ア・プログラムまたはプレゼンテーションなどの大量の
データを格納するために使用する。

【００１６】このシステム・バス２１には、様々な入出
力制御装置、すなわち、キーボード制御装置２８、マウ
ス制御装置２９、ビデオ制御装置３０、オーディオ制御
装置３１も接続されている。予想通り、キーボード制御
装置２８はキーボード１２用のハードウェア・インタフ
ェースになり、マウス制御装置２９はマウス１３用のハ
ードウェア・インタフェースになり、ビデオ制御装置３
０はディスプレイ１４用のハードウェア・インタフェー
スであり、オーディオ制御装置３１はスピーカ１５用の
ハードウェア・インタフェースである。トークン・リン
グ・アダプタなどの入出力制御装置４０により、ネット
ワーク４６を介して同様に構成された他のデータ処理シ
ステムへの通信が可能になる。

【００１７】本発明の好ましい実施態様の１つは、上記
のように一般的に構成された１つまたは複数のコンピュ
ータ・システムのランダム・アクセス・メモリ２４に常
駐する複数の命令セット４８〜５２である。コンピュー
タ・システムが要求するまで、命令セットは、ハード・
ディスク・ドライブ２６などの他のコンピュータ・メモ
リ、最終的にＣＤ−ＲＯＭ３２で使用するための光ディ
スクなどの取外し可能メモリ、最終的にフロッピー・デ
ィスク・ドライブ２７で使用するためのフロッピー・デ
ィスクに格納することができる。当業者であれば、この
命令セットを物理的に格納すると、それが電気的、磁気
的、または化学的に格納されている媒体が物理的に変化
し、その媒体上にコンピュータが読取り可能な情報が乗
ることを理解できるはずである。命令、記号、文字など
によって本発明を記述すると便利であるが、これらの表
現および同様の表現はいずれも適切な物理要素に関連付
けられている必要があることに留意されたい。さらに、
本発明は、比較や妥当性検査、あるいは人間の操作員に
関連しうる他の表現によって記述されることも多い。こ
こに記載するいずれの操作でも、本発明の一部を形成す
るような人間の操作員によるアクションは一切不要であ
り、この操作は電気信号を処理して他の電気信号を生成
するためのマシン操作である。

【００１８】このワークステーションが統合されている
ネットワークは、ローカル・エリア・ネットワーク（Ｌ
ＡＮ）または広域ネットワーク（ＷＡＮ）であり、後者
は他のノードまたは既知のコンピュータ・アーキテクチ
ャに基づいて動作するシステムのネットワークへのテレ
プロセシング接続を含む。いずれのノードでも、１つま
たは複数の処理システムが存在可能であり、それぞれの
処理システムはだいたい上記のように構成された単一ユ
ーザ・システムまたは複数ユーザ・システムにすること
ができる。これらの処理システムは、サービスを要求す
るか供給するかに応じて、クライアント・ワークステー
ションまたはサーバ・ワークステーションとして動作す
る。特定の実施態様では、本発明は、様々な通信プロト
コルのうちの１つまたは複数によって通信するネットワ
ークによって相互接続された複数のＩＢＭ互換ワークス
テーション上で動作する。ソフトウェア・アプリケーシ
ョンは、まとめてパッケージ化するか、個別のアプリケ
ーションとして販売することができる。ローカル・エリ
ア・ネットワークの簡単な説明は、ラリーＥ．ジョーダ
ン（Larry E. Jordan）およびブルース・チャーチル（B
ruce Churchill）著Communications and Networking Fo
r The IBM PC（Robert J. Brady発行、A Prentice Hall
Company 1983）等に記載されている。

【００１９】好ましい実施例では、本発明は、オブジェ
クト指向プログラミング技法を使用してＣ＋＋プログラ
ミング言語で実現される。Ｃ＋＋はコンパイル済みの言
語である。プログラムは人間が読取り可能なスクリプト
で作成され、このスクリプトがコンパイラという他のプ
ログラムに供給され、マシンが読取り可能な数字コード
が生成されるが、このコードはコンピュータにロードし
てコンピュータが直接実行できるものである。Ｃ＋＋言
語は、ソフトウェア開発者が他の開発者によって作成さ
れたプログラムを容易に使用できるようにするような所
与の特性を処理しながら、その破壊や不適正使用を防止
するためにプログラムの再使用を大幅に制御する。Ｃ＋
＋言語は周知のものなので、この言語について詳細に記
載した論文やテキストは数多く存在する。

【００２０】当業者には既知のように、オブジェクト指
向プログラミング技法は、「オブジェクト」の定義、作
成、使用、破棄を含む。これらのオブジェクトは、デー
タ要素とルーチン、すなわちデータ要素を操作するメソ
ッドとを含む、ソフトウェア・エンティティである。デ
ータと関連メソッドは、ソフトウェアによってエンティ
ティとして扱われ、そのように作成し、使用し、削除す
ることができる。データと関数により、オブジェクト
は、データ要素により提示可能なその属性と、そのメソ
ッドにより表現可能なその挙動によって、実世界のエン
ティティをモデル化することができる。

【００２１】オブジェクトの定義は、オブジェクトその
ものではないが、実際のオブジェクトを構築する方法を
コンパイラに指示するテンプレートとして機能する「ク
ラス」を作成することによって行う。たとえば、クラス
は、データを操作する関数に含まれるデータ変数とステ
ップの数とタイプを指定することができる。実際にはオ
ブジェクトは、対応するクラス定義と、オブジェクト作
成中に供給される引数などの追加情報とを使用してオブ
ジェクトを構築する、コンストラクタという特殊な関数
を使ってプログラム内に作成される。オブジェクトの破
棄は、デストラクタという特殊な関数によって行われ
る。

【００２２】多くの利点は、オブジェクト指向プログラ
ミング技法の３つの基本的特性、すなわち、カプセル
化、多様性、継承から発生している。オブジェクトは、
内部データ構造および内部関数の全部または一部を隠
す、すなわち、カプセル化するために設計することがで
きる。より具体的には、プログラム設計時にプログラム
開発者は、データ変数の全部または一部と関連メソッド
の全部または一部を「私用」すなわちそのオブジェクト
のみが使用するものと見なしてオブジェクトを定義する
ことができる。他のデータまたはメソッドは、「公用」
すなわち他のプログラムが使用可能なものであると宣言
することができる。他のプログラムによる私用変数およ
びメソッドへのアクセスは、そのオブジェクトの私用デ
ータにアクセスする公用メソッドを定義することによっ
て制御することができる。この公用メソッドは、私用デ
ータと外部プログラムとのインタフェースを形成する。
私用変数に直接アクセスするプログラム・コードを作成
しようと試みると、コンパイラは、プログラムのコンパ
イル時にエラーを発生する。このエラーによって、コン
パイル・プロセスが停止し、プログラムが実行できなく
なる。

【００２３】多様性とは、全体的なフォーマットが同じ
であるが別々のデータで機能する複数のオブジェクトお
よび関数が、別々に機能して一定の結果を生み出せるよ
うにするものである。たとえば、加算メソッドを変数Ａ
プラス変数Ｂ（Ａ＋Ｂ）として定義することができる。
ＡとＢが数字、文字、またはドルとセントであっても、
これと同じフォーマットを使用することができる。しか
し、この加算を実行する実際のプログラム・コードは、
ＡとＢを構成する変数のタイプに応じて、大幅に異なっ
てくる可能性がある。したがって、変数のタイプ（数
字、文字、ドル）ごとに１つずつ、３通りのメソッド定
義を作成することができる。メソッドの定義後、プログ
ラムはその共通フォーマット（Ａ＋Ｂ）によってその加
算メソッドをあとで参照することができ、コンパイル時
にＣ＋＋コンパイラは、その変数タイプを検査すること
によって３つのメソッドのいずれを使用すべきかを判定
する。その後、コンパイラは適切な関数コードを代入す
る。

【００２４】オブジェクト指向プログラミングの第３の
特性は、プログラム開発者が既存のプログラムを再使用
できるようにする継承である。継承により、ソフトウェ
ア開発者は、クラスと、クラス階層によって関連付けら
れるようにそのクラスからあとで作成されるオブジェク
トとを定義することができる。具体的には、クラスは、
他の基本クラスのサブクラスと呼ぶこともできる。サブ
クラスは、その基本クラスの公用関数がサブクラスに含
まれている場合のように、その公用関数のすべてを「継
承」し、そのすべてにアクセスすることができる。ま
た、サブクラスは、同じ形式の新しい関数を定義するこ
とによって、継承した関数の一部または全部を指定変更
したり、修正することもできる。

【００２５】他のクラスの機能性を借用する新しいサブ
クラスを作成すると、ソフトウェア開発者は、その特定
のニーズに合うように既存のコードを容易にカストマイ
ズすることができる。

【００２６】オブジェクト指向プログラミングにより、
他のプログラミングの概念が大幅に改善されるが、特に
修正に使用可能な既存のソフトウェア・プログラムがま
ったくない場合には、依然としてプログラム開発には相
当な時間と労力が必要になる。その結果、いずれも特定
の環境で一般に検出されるタスクの実行向けの１組のオ
ブジェクトと追加の雑ルーチンを作成するために、１組
の事前定義相互接続済みクラスが用意されていることが
ある。このような事前定義クラスとライブラリは、通
常、「フレームワーク」と呼ばれ、本質的に作業アプリ
ケーション用の事前製作構造を提供する。

【００２７】たとえば、ユーザ・インタフェース用のフ
レームワークは、ウィンドウ、スクロール・バー、メニ
ューなどを作成する１組の事前定義グラフィック・イン
タフェース・オブジェクトを提供し、これらのグラフィ
ック・インタフェース・オブジェクト用のサポートと
「デフォルト」挙動を提供する可能性がある。多くのフ
レームワークはオブジェクト指向技法に基づいているの
で、事前定義クラスを基本クラスとして使用することが
でき、組込みデフォルト挙動を開発者定義サブクラスが
継承し、開発者がそのフレームワークを拡張し、特定の
専門分野でカストマイズ済みの解決策を作成できるよう
に修正または指定変更することができる。プログラマは
元のプログラムを変更せず、むしろ元のプログラムの諸
機能を拡張するので、このオブジェクト指向手法は従来
のプログラミングより大幅に優れている。さらに、この
フレームワークは体系的なガイダンスとモデル化を提供
し、同時に、開発者は問題定義域に固有の特定のアクシ
ョンを自由に供給できるようになる。

【００２８】以下に記載する本発明では、コンピュータ
・ネットワーク内の様々なコンピュータ・システムのア
プリケーション用のネットワーク・サービスを提供する
ためにネットワーキング・フレームワークを提供する。

【００２９】プロトコル・インタフェース・モデル ここでは、オブジェクト指向のプロトコル・インタフェ
ース・モデルおよび機構について説明する。このインタ
フェースの一般的な特徴により、ＯＳＩネットワーク・
モデルのすべての層の開発が可能になる。したがって、
すべてのネットワーク層は同様の構文になり、その意味
は特定の層の仕様によって定義される。すなわち、ＯＳ
Ｉネットワーク・モデル内の各種の層を実現するオブジ
ェクトは構文上は同様であるが、そのインプリメンテー
ションは特定の層の責任に応じて異なる可能性がある。
さらに、ＴＣＰ／ＩＰなどの特定のプロトコル用のそれ
ぞれの層を実現するオブジェクトは、ＮｅｔＢＩＯＳな
どの別のプロトコルの同様の層とは、機能およびインプ
リメンテーションの点で異なる可能性がある。というの
は、２つのプロトコルではそれぞれの層の責任が異なる
からである。このモデルは、通信端点を定義し、端点を
再使用し、ネットワーク事象を監視するための機構も提
供する。これは、オブジェクト指向モデルなので、コー
ドの再使用性、保守容易性、クライアント・アプリケー
ションに影響せずにインプリメンテーションを更新する
能力など、オブジェクト指向インプリメンテーションの
特徴をすべて継承している。

【００３０】１．通信端点の作成：通信端点の作成は、
ネットワーク定義オブジェクトにより容易になってい
る。各ネットワーク定義オブジェクトは、クライアント
・インタフェースの定義を含む。これは、クライアント
・プログラムがアクセスを必要とすると思われる各種タ
イプのオブジェクトの抽象概念である。通信端点は、ネ
ットワーク定義クラスから派生したTAccessDefinition
オブジェクトである。

【００３１】図２は、ネットワーク定義オブジェクトの
クラス階層を示している。TNetworkDefinitionクラス１
００は、端点をインスタンス化するためのメソッドInst
antiateDefinitionと、通信端点を破棄するためのメソ
ッドDeinstantiationDefinitionをそれぞれ含んでい
る。TNetworkDefinitionの新しいインスタンスを構築す
るためのメソッドまたは特定のクラス・オブジェクトを
破棄するためのメソッドも用意されているが、これらの
メソッドはすべてのクラスに共通なので、以下の説明で
は繰り返さないことにする。

【００３２】TAccessDefinitionオブジェクト１０１
は、特定のプロトコル・タイプとその諸層を定義するプ
ロトコル・インタフェース・オブジェクトを含んでい
る。TAccessDefinitionオブジェクト１０１は、通信端
点のハンドルとして機能する。さらに、TAccessDefinit
ionオブジェクト１０１は、その親であるTNetworkDefin
itionから継承したメソッドに加え、すでに追加されて
いるものの上にアクセス定義へのインタフェース層を加
えるためのメソッドAddToTopと、一番下にすでに追加さ
れているものにAccessDefinitionへのインタフェース層
を加えるためのメソッドAddToBottomと、最も高いプロ
トコル層インタフェースを獲得するためのメソッドGetT
opOfStackも含んでいる。TEventDefinitionクラス１０
３は、ネットワーク事象を監視するために使用する。TE
ventDefinitionクラス１０３については、以下のNetwor
kEventの項でより詳細に説明する。

【００３３】２．ネットワーク・アドレス・クラス TNetworkAddressクラス１１１は、すべてのプロトコル
・アドレス・クラスとハードウェア・アドレス・クラス
を定義するために使用する基本クラスである。図３は、
プロトコル・アドレス・クラスのクラス階層を示してい
る。TNetworkAddressクラス１１１は、アドレスのタイ
プをテストするためのメソッドIsOfAddressTypeと、グ
ループ・アドレスかどうかをテストするためのメソッド
IsGroupと、同報アドレスかどうかをテストするための
メソッドIsBroadCastと、マルチキャスト・アドレスか
どうかをテストするためのメソッドIsMulticastと、ヌ
ル・アドレスかどうかをテストするためのメソッドIsNu
llAddressとを含んでいる。このクラスは、アドレスの
ワイヤ長を獲得するためのメソッドGetWireLengthと、
アドレスをヘッダにフォーマット化するためのメソッド
AddressToWireと、ヘッダからアドレスを獲得するため
のメソッドWireToAddressも含んでいる。ストリームが
端点に着信するのか、それともストリームが端点から発
信するのかを判定するための演算子も、このクラスの一
部である。各クラスに固有のポインタを獲得するための
メソッドGetClassIdentifierは、このクラスによって提
供される。

【００３４】TProtocolAddressクラス・オブジェクトの
インスタンスは、プロトコル・アドレスを渡すことがで
きるように、通信端点として機能する。TProtocolAddre
ssオブジェクト１１３は、同報アドレスを獲得するため
のメソッドBroadCastAddressと、ヌル・アドレスを獲得
するためのメソッドNullAddressとを加える。THardware
Addressオブジェクト１１５のインスタンスは、必要に
応じてアプリケーションにハードウェア・アドレスを渡
すものである。同様に、THardwareAddressオブジェクト
１１５は、同報アドレスを獲得するためのメソッドBroa
dCastAddressと、ヌル・アドレスを獲得するためのメソ
ッドNullAddressとを加える。また、機能アドレスかど
うかをテストするためのメソッドIsFunctionalも加え
る。TIEEE8023Addressクラスは、ＩＥＥＥＥ８０２．３
というアドレス指定規則に応じてハードウェア・クラス
・アドレスを変更したものである。さらに、これは、グ
ループ・アドレスかどうかをテストするためのメソッド
IsGroupと、グループ・アドレスに設定するためのメソ
ッドSetGroupと、グループ・アドレスをリセットするた
めのメソッドClearGroupとを加える。他のメソッドとし
ては、同報アドレスを獲得するBroadCastAddress、マル
チキャスト・アドレスかどうかをテストするIsMulticas
t、ヌル・アドレスを獲得するNullAddress、標準入力か
らアドレスを獲得するCanonicalAddressなどがある。

【００３５】TTCPAddr１１７とTNBAddr１１９は、それ
ぞれＴＣＰ／ＩＰおよびＮｅｔＢＩＯＳのアドレス指定
の詳細を表す具象アドレス・クラスの例である。同様
に、TIEEE8023Addr１２１とTIEEE8025Addr１２３は、Ｉ
ＥＥＥ８０２．３およびＩＥＥＥ８０２．５のアドレス
指定用の具象ハードウェア・アドレスを表している。

【００３６】３．プロトコル・インタフェース・クラス 本発明は、接続指向のトランザクションと無接続のトラ
ンザクションの両方をサポートする。また、本発明で
は、プロトコルとは無関係のアプリケーションが従う状
態マシンについても説明する。プロトコル・インタフェ
ース・クラスのオブジェクト階層を図４に示す。プロト
コル・インタフェース・クラスは、プロトコルが備えて
いなければならないすべての共通関数用のメソッドを含
む、MProtocolServe１３３という基本クラスから派生し
たものである。TProtocolInterfaceクラス１３５は、ネ
ットワーク機能用の追加メソッドを含んでいる。これら
のメソッドについては、以下の表１と表２に詳しく示
す。ＴＣＰ／ＩＰなどのネットワーク・プロトコルは、
そのTCPIPInterfaceクラスをTProtocolInterfaceから派
生させて、デフォルト・インプリメンテーションを指定
変更し、送信または受信要求上に有効フラグがあるかど
うかという検査などのそれ専用の特定の特徴を追加す
る。TProtocolInterfaceクラスから派生する個別のクラ
スとしては、セッション層用のTSessionInterface１３
７、トランスポート層用のTTransportInterface１３
８、ネットワーク層用のTNetworkInterface１４１、フ
ァミリー層用のTFamilyInterface１４３、データ・リン
ク層用のTDLCInterface１４５が用意されている。オブ
ジェクト階層は図示の通りである。この実施例では、Ｏ
ＳＩネットワーク層が、ネットワーク層と、プロトコル
・ファミリー層という下位層とに分割される。ファミリ
ー層は、経路指定情報など、ＯＳＩネットワーク層の非
複製部分を含んでいる。ネットワーク層は、対等アドレ
スおよびローカルＳＡＰなど、特定の端点に関連する情
報を含んでいる。これは、FamilyLayerオブジェクトな
ど、１つのオブジェクトだけがシステム内に常駐するよ
うにして、すべてのグローバル情報とプロトコルとの関
連を維持するために行われるものである。クライアント
・アプリケーションによって各端点が作成され破棄され
ると、セッション層などの他のプロトコル層オブジェク
トと、トランスポート層オブジェクトと、ネットワーク
層オブジェクトは作成され破棄されるが、ファミリー層
オブジェクトとデータリンク層オブジェクトは常駐した
ままになる。

【００３７】具象クラスは、個々のインタフェース・ク
ラスから派生する。たとえば、以下に説明するように、
プロトコル・スタックを構築するためにＴＣＰ／ＩＰな
どの特定のプロトコル用のトランスポート、ネットワー
ク、ファミリー・インタフェース・クラスのために、具
象クラスが用意されている。

【００３８】表１ 前述のように、MProtocolServiceオブジェクトは、プロ
トコル層定義用の基本クラスとして機能する。MProtoco
lServiceオブジェクトに設けられているメソッドのリス
トを以下に示す。これらのメソッドの大部分は、純粋仮
想関数である。

【００３９】 Bind −ローカル・アドレスを初期設定しバインド する Unbind −ローカル・アドレスをアンバインドする SendRelease −正常解放開始 ReceiveRelease −正常解放開始の肯定応答受信 GetLocalAddress −ローカル・アドレスを獲得する SetLocalAddress −ローカル・アドレスを設定する GetPeerAddress −対等アドレスを獲得する SetPeerAddress −対等アドレスを設定する GetProtocolInfo −プロトコル情報を獲得する SetProtocolInfo −プロトコル情報を設定する GetProtocolOptions −プロトコル・オプションを設定する GetRequestMode −要求モードを獲得する SetRequestMode −要求モードを設定する GetRetry −プロトコル層再試行パラメータを獲得する SetRetry −プロトコル層再試行パラメータを設定する GetTimeout −プロトコル層タイムアウト・パラメータを 獲得する SetTimeout −プロトコル層タイムアウト・パラメータを 設定する GetStatistics −プロトコル層統計情報を獲得する SetStatistics −プロトコル層統計情報を設定する IsSession −プロトコル層がセッション層である場合に 真を返す IsTransport −プロトコル層がトランスポート層である場 合に真を返す IsNetwork −プロトコル層がネットワーク層である場合 に真を返す IsFamily −プロトコル層がファミリー層である場合に 真を返す 演算子<<= −オブジェクトをデータ・ストリームに受信 するための演算子 演算子>>= −オブジェクトをデータ・ストリームに送信 するための演算子

【００４０】表２ TProtocolInterfaceクラスに設けられた関数のリストを
以下に示す。

【００４１】 GetLayerIndex −プロトコル層のインデックスを獲得する CancelRequests −現行未解決要求をすべて取り消す ReceiveEvent −このスタック上の受信事象 GetConnectionInfo −接続情報およびメモりの制約を入手する BorrowMemory −ネットワーク・データ用にシステム・メモ リを借用する ReturnMemory −ネットワーク・データ用のシステム・メモ リを返す GetAccessDefinition −TAccessDefinitionへのポインタを獲得する GetLocalAddress −層のローカル・アドレスを獲得する SetLocalAddress −層のローカル・アドレスを設定する GetPeerAddress −層の対等アドレスを獲得する SetPeerAddress −層の対等アドレスを設定する GetProtocolInfo −層のプロトコル情報を獲得する SetProtocolInfo −層のプロトコル情報を設定する GetProtocolOptions −層のプロトコル・オプションを獲得する SetProtocolOptions −層のプロトコル・オプションを設定する GetRequestMode −層の要求モードを獲得する SetRequestMode −層の要求モードを設定する GetRetry −プロトコル層再試行パラメータを獲得する SetRetry −プロトコル層再試行パラメータを設定する GetStatistics −プロトコル層統計情報を獲得する GetTimeout −プロトコル層タイムアウト・パラメータを 獲得する SetTimeout −プロトコル層タイムアウト・パラメータを 設定する Bind −プロトコル・スタックをバインドする Unbind −プロトコル・スタックをアンバインドする Receive −ネットワーク・データを受信する Send −ネットワーク・データを送信する Connect −接続を確立しようという試みを開始する ReceiveConnection −接続を確立しようという試みを待つ Disconnect −接続を終了する ReceiveDisconnect −切断を待つ AcceptConnection −接続を確立しようという試みを受け入れる RejectConnection −接続を確立しようという試みを拒否する Listen −接続を確立しようという試みを聴取する ListenForConnection −接続を確立しようという試みを聴取する SendRelease −正常解放開始＝＞送信すべきデータはこれ 以上ない ReceiveRelease −正常解放開始の肯定応答受信 演算子<<= −オブジェクトをデータ・ストリームにスト リーム・インするための演算子 演算子>>= −オブジェクトをデータ・ストリームにスト リーム・アウトするための演算子

【００４２】４．プロトコル層インプリメンテーション
・クラス 前述のように、プロトコル・インタフェース・モデル
は、プロトコル層にアクセスするためのオブジェクト・
ベースのＡＰＩとして機能する。ＴＣＰ／ＩＰなどのプ
ロトコル・スタックのインプリメンテーションを階層化
した１組のリンク済みオブジェクトとして実現するに
は、TProtocolLayerクラスを使用する。図５は、プロト
コル層クラスのクラス階層を示している。TProtocolLay
erクラス１５１は、１つのプロトコル・インプリメンテ
ーションのすべての層の基本クラスとして機能する。

【００４３】TProtocolLayerクラス１５１は、各層で実
施されるTransmit、Connect、Receive、Disconnectなど
の関数用のメソッドを含んでいる。これらのメソッドに
ついては、以下の表３に詳しく示す。

【００４４】ＴＣＰ／ＩＰなどのプロトコル用の具象ク
ラスは、これらの層オブジェクトから派生し、その具体
的なプロトコル層の意味を取り入れている。

【００４５】それぞれの子オブジェクト１５３〜１６１
は、これらのメソッドを継承し、特定のプロトコル層に
該当する場合にはそのメソッドを指定変更する。

【００４６】表３ TProtocolLayerクラスの主な関数を以下に示す。

【００４７】 Dispatch −インバウンド・パケットを上位層にディス パッチする Transmit −アウトバウンド・パケットを下位層に伝送 する DispatchEvent −事象を上位層にディスパッチする TransmitEvent −事象を下位層に伝送する ReceiveEvent −事象の報告を可能にする CancelReceiveEvent −事象の報告を取り消す InstantiateInterface −層オブジェクトからインタフェース・オブ ジェクトを作成する GetUpperProtocol −次の上位層へのポインタを獲得する GetLowerProtocol −次の下位層へのポインタを獲得する Bind −プロトコル・スタックをバインドする Unbind −プロトコル・スタックをアンバインドする Connect −接続を確立しようという試みを開始する ReceiveConnection −接続を確立しようという試みを待つ Disconnect −接続を終了する GetPacketQueue −インバウンド・データ・パケットが得られ るパケット待ち行列へのポインタを返す ReceiveDisconnect −切断を待つ AcceptConnection −接続開始を受け入れる RejectConnection −接続を確立しようという試みを拒否する Listen −接続を確立しようという試みを聴取する ListenForConnection −接続を確立しようという試みを聴取する SendRelease −正常解放開始＝＞送信すべきデータはこれ 以上ない ReceiveRelease −正常解放開始の肯定応答受信 演算子<<= −TProtocolLayerオブジェクトをデータ・ス トリームにマーシャルするための演算子 演算子>>= −TProtocolLayerオブジェクトをデータ・ス トリームにアンマーシャルするための演算 子

【００４８】５．プロトコル状態マシン ここでは、接続指向操作と無接続操作の両方について可
能なプロトコル・インタフェース・オブジェクトの状態
について説明する。プロトコル状態マシンを図６および
図７に示す。これらの状態マシンは、プロトコルで典型
的な状態遷移を示しているが、プロトコルのインプリメ
ンテーションによっては異なる選択も可能である。しか
し、この状態マシンは、アプリケーションの可搬性を確
実にし、プロトコルの独立性を可能にする。プロトコル
の独立性を必要とするアプリケーションでは以下に説明
する状態マシンを使用し、プロトコルの独立性をサポー
トするプロトコルによって状態マシンが実現されるはず
である。

【００４９】特定のプロトコル・インタフェース層オブ
ジェクト用のプロトコル端点は、以下に記載する状態の
いずれかになるはずである。これらの状態は通常、アプ
リケーション状態である。層オブジェクトは、特定のプ
ロトコルによって定義される状態マシンに従う。通常、
これらの状態は、ユーザが各種の「端点」状態で行うこ
とができる有効な呼出しと、アプリケーションの作成方
法を示すためのものである。層状態は、層の意味と状態
によって制御される。

【００５０】未初期設定状態２０１は、端点の最終状態
でもある端点の開始状態を定義するものである。これ
は、アクセス定義が作成される前の状態である。

【００５１】TAccessDefinitionオブジェクトが作成さ
れると（２０２）、端点は初期設定済みと呼ばれる。初
期設定済み状態２０３では、Set操作を使用してインタ
フェース・オブジェクトを構築し初期設定できるはずで
ある。Set操作はインタフェース・オブジェクトでロー
カルにキャッシュされるので、設定値の妥当性検査を行
う余地はほとんどない。すなわち、InstantiateDefinit
ionメソッドによりプロトコル層オブジェクトが作成さ
れる前に、インタフェース・オブジェクト上で送信／受
信容量を設定することができる。このような容量への制
限に関する情報は層オブジェクトだけが把握しているの
で、このような値をインタフェース上で妥当性検査する
ことは不可能である。というのは、AccessDefinitionオ
ブジェクト上でInstantiateDefinitionメソッドが呼び
出されるまで、層オブジェクトが存在しないからであ
る。TAccessDefinitionオブジェクト２０４を破棄する
よう要求すると、端点が初期設定済み状態２０３から未
初期設定状態２０１に移行する。

【００５２】TAccessDefinitionオブジェクト上でイン
スタンス化要求２０６を行うと、端点が未結合状態２０
７に移行する。未結合状態２０７は、層オブジェクトが
インスタンス化された直後に発生する状態を定義する。
値を修正するためにGet／Set操作を出すことができる。
このような要求はもはやインタフェース・オブジェクト
にキャッシュされないが、対応する層オブジェクトに送
られて、処理され格納される。TAccessDefinitionオブ
ジェクト上でインスタンス解除要求２０８を行うと、端
点が初期設定済み状態２０３に移行する。

【００５３】ローカル・アドレスをバインドするために
Bind操作２１０が出されると、端点が未結合状態２０７
から結合状態２０９に移行する。無接続モードのデータ
転送の端点は、「結合」状態になるとデータの送受信を
開始することができる。結合状態２０９でスタックに対
してアンバインド要求２１２が出されると、端点が未結
合状態２０７に戻る。

【００５４】Listen要求２１４が出されると、端点が結
合状態２０９から聴取状態２１３に移行する。プロトコ
ル・スタックは、ユーザ指定の待ち行列サイズを使い尽
くすまでそのローカル名に関する着信接続要求を受け入
れる。着信接続２１６により、新しい活動プロトコル・
スタックが作成される。

【００５５】活動端点でConnect要求２２０が出される
と、端点が結合状態２０９から接続（クライアント）状
態２１９に移行する。図７に示すように、無接続モード
のサービスを使用する端点は、接続要求が正常に行われ
た後で「データ転送」状態２２５に入る。受動端点の場
合、着信接続要求を受信すると、プロトコル・スタック
は、層とインタフェース・オブジェクトのコピーと、受
信した接続要求用の新しいTAccessDefinitionを作成す
る。新たに作成された端点は、その後、接続（サーバ）
状態２２１になる。矢印は、聴取状態から接続（サー
バ）状態まで点線上にある。アプリケーションは、接続
を受け入れるか、または接続を拒否するかを選択するこ
とができる。AcceptConnectionでは、端点がデータ転送
状態２２５になるはずである。接続要求２２６が拒否さ
れた場合、端点は非活動状態２２９に移行する。

【００５６】新たに作成したスタックが接続要求２２２
を完了後、端点はデータ転送状態２２５に入る。ローカ
ル・アプリケーションからDisconnect要求２２８を受信
するか、または接続パートナーによって接続が終了され
た後に、接続端点が結合状態２０９に移行する。ただ
し、このような場合、アプリケーションはReceiveDisco
nnect要求を出して終了データを受信できることに留意
されたい。

【００５７】着信接続要求がアプリケーションによって
拒否されると、端点は非活動状態２２９に移行する。次
に、TAccessDefinition破棄操作２３０を出すことによ
って、端点が破棄される。

【００５８】６．例 ここでは、ＴＣＰ／ＩＰなどのネットワーク・プロトコ
ルに本発明のオブジェクト指向モデルを使用する方法の
例を示す。ＴＣＰ／ＩＰインプリメンテーションは、ト
ランスポート層と、ネットワーク層と、ＴＣＰ／ＩＰフ
ァミリー層とを含む。さらに、ネットワーキング・サブ
システムは、システム内に常駐するTDatalink層オブジ
ェクトを含み、ＴＣＰ／ＩＰのFamilyLayerオブジェク
トはTDatalink層にアクセスする手段を備えている。た
だし、この実施例では、TDataLink層オブジェクトはＴ
ＣＰ／ＩＰ、ＳＮＡ、ＮｅｔＢＩＯＳなど、すべてのネ
ットワーク・プロトコル・スタックに共通し、TDatalin
k層オブジェクトはTProtocolLayerクラス・オブジェク
トから派生することに留意されたい。

【００５９】ＴＣＰ／ＩＰインタフェース（ＡＰＩ）ク
ラスは、TProtocolInterfaceクラスから派生している。
図８は、ＴＣＰ／ＩＰインプリメンテーションの一部の
オブジェクトのクラス階層を示している。前述のよう
に、TProtocolInterfaceとTProtocolLayerは、ＡＰＩお
よびプロトコル・インプリメンテーション機能を提供す
るMProtocolServiceクラスの子クラスである。TTCPTINF
２５１と、TTCPNINF２５３と、TTCPFINF２５５の各オブ
ジェクト（まとめてTTCPXINFと呼ぶ）は、ＴＣＰ／ＩＰ
プロトコル用のTTransportInterfaceクラス、TNetworkI
nterfaceクラス、TFamilyInterfaceクラスを表すTProto
colInterfaceの具象クラスの例である。ただし、ＴＣＰ
／ＩＰプロトコルには「セッション」という概念がない
ので、TSessionLayerクラスのインスタンスがないこと
に留意されたい。同様に、TTCPTIMP２５７と、TTCPNIMP
２５９と、TTCPFIMP２６１の各オブジェクト（まとめて
TTCPXIMPと呼ぶ）は、ＴＣＰ／ＩＰプロトコル用のTTra
nsportInterfaceクラス、TNetworkInterfaceクラス、TF
amilyInterfaceクラスのインスタンスである。

【００６０】前述のように、TDatalinkLayer１６１は、
この実施例のすべてのネットワーク・プロトコル用のイ
ンプリメンテーション・オブジェクトであり、TProtoco
lLayerクラス１５１のサブクラスである。

【００６１】また、ＩＰアドレスを渡すことができるよ
うに、アプリケーションにはTTCPProtocolAddressクラ
スが用意されている。TTCPProtocolAddressは、４バイ
トのＩＰアドレスと、２バイトのポート・アドレスとを
含むことになる。

【００６２】ＴＣＰ／ＩＰプロトコルにアクセスするた
めにアプリケーションが必要とするプロセスについて
は、図９を参照して以下に説明する。ほとんど場合、
「アプリケーション」は、ユーザ・レベル・アプリケー
ションがＡＰＩ呼出しを行うＢＳＤソケット・インタフ
ェースなどの通信ＡＰＩ層になる可能性が最も高い。ソ
ケット・インタフェースにより、アプリケーション開発
者は、ネットワーク・プロトコル・オブジェクトの特定
の構文を把握する必要がなくなるはずである。しかし、
「アプリケーション」は、本発明のオブジェクト・モデ
ルの名前に精通したオペレーティング・システム・サー
ビスにもなりうる。以下の例では、アプリケーションが
トランスポート層にアクセスする。アプリケーションは
どの層にもアクセスすることができる。ネットワーク層
に直接送話することも可能である。現在、ユーザ・アプ
リケーションがまったくないことが一般的である。これ
らのステップは、ＴＣＰ／ＩＰプロトコルの手続き上の
インプリメンテーションのものと高レベルで非常によく
似ている。しかし、それは、本発明のプロトコル・イン
タフェース・モデルを使用して、オブジェクト指向のや
り方で実現されている。

【００６３】ステップ３０１では、ＴＣＰ／ＩＰプロト
コルにアクセスするために通信端点が作成される。これ
は、まずTAccessDefinitionオブジェクトを作成するこ
とによって行われる。たとえば、Ｃ＋＋を使用して「新
しいTAccessDefinition」が構築される。次に、TAccess
Definition内のメソッドを使用して、TTCPxINFインタフ
ェース・オブジェクトが作成され、AccessDefinitionに
追加される。その後、TAccessDefinitionオブジェクト
上でInstantiateProtocolメソッドが呼び出され、次に
それによりTTCPxIMP層オブジェクトが作成される。

【００６４】ステップ３０３では、ステップ３０１で作
成された通信端点にアドレスが結合される。これは、用
意されたTTCPProtocolAddressクラス・オブジェクトか
ら必要なＩＰアドレスを備えたTTCPProtocolAddressオ
ブジェクトを作成することによって行われる。次に、そ
のアドレスをバインドするためにTTCPTINF->Bind()メソ
ッドが呼び出される。このステップは、バインドの意味
を含むプロトコル・インプリメンテーション層上でTTCP
IMP->Bind()メソッドを起動することになる。

【００６５】次に、ステップ３０５では、（TTCPTINFオ
ブジェクトで）TTCPTINF->Connect()メソッドを呼び出
して接続要求を開始することによって、アプリケーショ
ンが聴取対等機能に接続する。これにより、（TTCPTIMP
オブジェクトで）TTCPTIMP->Connect()メソッドが起動
され、次にこのメソッドは、下位層、すなわち、TTCPNI
MP->Connect()メソッドとTTCPFIMP->Connectメソッド用
のTTCPNIMPオブジェクトとTTCPFIMPオブジェクトをそれ
ぞれ呼び出すことにより、ＴＣＰ／ＩＰ接続をセットア
ップするための必要なステップを実行する。

【００６６】正常接続後、ステップ３０７では、結果の
プロトコル・スタックによりデータを送受信することが
できる。アプリケーションは、TTCPTINF->Send()メソッ
ドとTTCPTINF->Receive()メソッドを呼び出して、ネッ
トワーク・データを送受信する。TTCPTINF->Send()は次
にTTCPTIMP->Xmit()メソッドを呼び出して、ＴＣＰプロ
トコルのデータ伝送を開始する。データは、各プロトコ
ル層のXmit()関数を使用してプロトコル層オブジェクト
からプロトコル層オブジェクトに渡され、通信アダプタ
によりTDataLinkLayerオブジェクトに送達される。同様
に、受信機能の場合は、TDataLinkLayerが物理層からデ
ータを受信し、それを適切なプロトコル・ファミリー層
に渡し、次にその層が適切なスタックに渡す。しかし、
一実施態様では、クライアントからのデータ受信要求が
行われるまでデータが待ち行列化され、データはデータ
待ち行列からクライアントにコピーされる。

【００６７】ステップ３０９では、所望の通信の完了後
に接続が閉じられる。アプリケーションは、TTCPTINF->
Disconnect()メソッドを呼び出して、接続終了を開始す
る。これにより次にTTCPTIMP->Disconnect()が呼び出さ
れ、このメソッドは特定のインプリメンテーションの場
合にファミリー層までそのメソッドを送信する可能性の
あるTTCPTIMPのＴＣＰ／ＩＰ切断状態マシンを処理す
る。

【００６８】最後に、ステップ３１１では、TAccessDef
initionオブジェクトを削除することによって、端点が
閉じられる。

【００６９】図１０を参照すると、様々なオブジェクト
とネットワーク層との関係を理解するのに役立つだろ
う。同図の左側には、図８および図９に関連して前述し
たＴＣＰ／ＩＰ実施例が示されている。ＴＣＰ／ＩＰア
プリケーション３１３、３１５は、いずれもアプリケー
ション層にあるソケットＡＰＩ３１７を介して、以下の
層のオブジェクト指向プロトコル・スタックに連絡す
る。通信端点を作成するためにソケットＡＰＩが使用す
るTProtocolAddressオブジェクトは図示していない。そ
れぞれのＴＣＰ／ＩＰアプリケーション３１３、３１５
ごとに個別の通信端点、すなわち、個別のTProtocolAdd
ressオブジェクトが必要である。

【００７０】前述のように、ＴＣＰ／ＩＰにはセッショ
ン層という概念がないので、ソケットＡＰＩ３１７はト
ランスポート層内のTTCPTINFオブジェクト２５１によっ
てやりとりする。前述のように、TAccessDefinitionオ
ブジェクト３１８は、トランスポート層、ネットワーク
層、ファミリー層のTTCPxINFオブジェクト２５１、２５
３、２５５を含む。ユーザ・レベル・プロセスがファミ
リー層のネットワークによりプロトコル・スタックに連
絡することは比較的まれなことであるが、主にオペレー
ティング・システム・サービスにより、これらの層に連
絡するためにTTCPNINFオブジェクト２５３とTTCPFINFオ
ブジェクト２５５が提供される。

【００７１】TTCPTINFオブジェクト２５１は、TTCPTINF
-->Connect()メソッドによりTTCPTIMPオブジェクト２５
７に接続する。これにより、TTCPNIMPオブジェクト２５
９に接続するためのTTCPTIMP-->Connect()メソッドと、
TTCPFIMPオブジェクト２６１に接続するためのTTCPNIMP
-->Connect()メソッドが起動される。また、TDataLinkL
ayerオブジェクト１６１に接続するTTCPFIMP-->Connect
()メソッドが起動される。同図に示す通り、TTCPTIMP２
５７、TTCPNIMP２５９、TTCPFIMP２６１、TDatalinkLay
er１６１の各オブジェクトは、それぞれトランスポート
層、ネットワーク層、ファミリー層、データリンク層に
ある。前述のように、送受信メソッドにより、物理層内
の物理アダプタ３１９を介してプロトコル・スタック上
でネットワーク・データを送信することができる。

【００７２】好ましい実施例では、通信端点が作成され
削除されたときに、TDataLinkLayerオブジェクト１６１
とTTCPFIMPオブジェクト２６１は不変であり、単独であ
る。それぞれの活動端点ごとに、残りのオブジェクト
（２５１、２５３、２５５、２５７、２５９、３１８）
のそれぞれの個別のスレッドとインスタンスが必要にな
る。当業者であれば容易に分かるように、何千ものクラ
イアント接続が行われる可能性のあるネットワーク・プ
ロトコル・サーバの場合、このような配置に関連するオ
ーバヘッドによってパフォーマンス上の問題が発生する
可能性がある。以下の動的実行ユニット管理の項で説明
するように、本発明は、パフォーマンスを最大にするた
めに実行スレッドを動的に管理するための手段を提供す
る。

【００７３】同図の右側には、ＮｅｔＢＩＯＳのインプ
リメンテーションが示されている。したがって、本発明
は、システムが複数のネットワーク・プロトコルを実行
する複数のアプリケーションをサポートするマルチプロ
トコル環境を企図するものである。図１０に示すよう
に、ＮｅｔＢＩＯＳアプリケーション３３１、３３３
は、ソケットＡＰＩ３１７または特殊ＮｅｔＢＩＯＳ
ＡＰＩ層３３５のいずれかを介して下位層とやりとりす
ることができる。したがって、本発明は、本発明のオブ
ジェクト指向プロトコル・スタックにアクセス可能な複
数のアプリケーションも企図するものである。このよう
なアプリケーションは、オブジェクト・ベースまたは手
続きベースのユーザ・レベル・アプリケーションまたは
オペレーティング・システム・レベル・プロセスにする
ことができる。

【００７４】前述のように、同様のプロセスを使用して
ＮｅｔＢＩＯＳスタックが確立される。ただし、Ｎｅｔ
ＢＩＯＳにはセッション層という意味がないので、ＡＰ
Ｉ層３１７、３３５はセッション層のTNSINFオブジェク
ト３３７に接続することに留意されたい。ＮｅｔＢＩＯ
Ｓインタフェース・オブジェクトであるTNSINF３３７、
TNTINF３３９、TNNINF３４１、TNFINF３４３と、Ｎｅｔ
ＢＩＯＳプロトコル層オブジェクトであるTNSIMP３４
７、TNTIMP３４９、TNNIMP３５１、TNFIMP３５３が作成
された後、TNSINFオブジェクト３３７によりプロトコル
層オブジェクトを介してTDataLinkLayerオブジェクト１
６１まで通信経路が確立される。ＴＣＰ／ＩＰ実施例の
ように、TDataLinkLayerオブジェクト１６１とTNFIMPオ
ブジェクト３５３は不変かつ単独であり、それぞれの活
動通信端点ごとに残りのオブジェクトのそれぞれの個別
のインスタンスが作成され削除される。

【００７５】本発明では、TDataLinkLayer１６１に結合
された複数のアダプタ３１９、３２１に対処することが
できる。上位層は通信端点までの適切な経路指定を行う
ので、異なるネットワーク・プロトコルに対して同時に
これらのアダプタを使用することができる。さらに、こ
れらのアダプタは、イーサネットとトークン・リングな
ど、異なるタイプのものにすることができるので、サー
バは各種のネットワークからの要求に対応することがで
きる。

【００７６】７．プロトコル・ユーティリティ・クラス このクラスは、TProtocolInterfaceクラスとTProtocolL
ayerクラスが使用するものである。このクラスのほとん
どは、インタフェース・クラスとインプリメンテーショ
ン・クラスの様々なメソッドのパラメータとして機能す
る。このクラスは、提案したモデルの一般的な特徴を強
調するものである。

【００７７】ここでは、プロトコル・インタフェースが
使用する重要なクラスの一部について説明する。

【００７８】ａ．TProtocolInfoクラス このクラスは、サービス・タイプ、最大メッセージ・サ
イズ、優先データ長など、そのプロトコルの様々な特性
を識別するものである。このクラスが提供する重要なメ
ソッドの一部を以下に示す。

【００７９】これらは、端点の作成時に端点の特性を指
定するために使用する。

【００８０】 GetPSDUSize −プロトコル・サービス・データ・ユニット の最大サイズを獲得する SetPSDUSize −プロトコル・サービス・データ・ユニット の最大サイズを設定する GetEPSDUSize −優先プロトコル・サービス・データ・ユニ ットの最大サイズを獲得する PSDUSize −優先プロトコル・サービス・データ・ユニ ットの最大サイズを設定する GetConnectionDataSize −接続データの最大サイズを獲得する SetConnectDataSize −接続データの最大サイズを設定する GetDisconnectDataSize −切断データの最大サイズを獲得する SetDisconnectDataSize −切断データの最大サイズを設定する GetDisconnectDataSize −切断データの最大サイズを獲得する SetDisconnectDataSize −切断データの最大サイズを設定する GetServiceType −接続／無接続などのサービス・タイプを獲 得する SetServiceType −サービス・タイプを設定する SetServiceType −サービス・タイプを設定する SetServiceFlags −サービス・フラグを設定する

【００８１】ｂ．TProtocolOptionsクラス このクラスは、サービス品質を含む、プロトコル固有の
オプションを定義するために使用する。しかし、この基
本クラスは、特定のサービス品質を含んでいない。具象
クラスがTProtocolOptionsから派生し、その固有のオプ
ションを含むものと思われる。

【００８２】 GetLingerTime −プロトコル・リンガ時間を獲得する SetLingerTime −プロトコル・リンガ時間を設定する GetSendbufSize −プロトコル送信バッファ・サイズを獲得する SetSendbufSize −プロトコル送信バッファ・サイズを設定する GetRcvbufSize −プロトコル受信バッファ・サイズを獲得する SetRcvbufSize −プロトコル受信バッファ・サイズを設定する

【００８３】ｃ．TSendModifiersクラス TSendModifiersクラスは、TProtocolInterface::Sendメ
ソッドとTProtocolLayer::Xmit()メソッドにおけるネッ
トワーク送信機能に関連するフラグを修飾するものであ
る。送信タイムアウトのサポートの他に、送信機能を左
右しうる指示は以下の通りである。

【００８４】 kPush −即時処理を要求する kEdnOfMessage −メッセージの終わりをマークする kExpeditedData −データを優先データとして扱う kNotify −クライアント・バッファが使用可能なとき に送信側に通知する kSendAll −「ｎ」バイトがすべてバッファされるまで ブロックする kNoFragmentation −データを断片化しない

【００８５】このクラスでサポートされる重要な関数の
一部を以下に示す。

【００８６】 GetSendModifier −SendModifier用の値を獲得する SetSendModifier −SendModifierをＯＮに設定する ClearSendModifier −SendModifierをＯＦＦに設定する GetTimeout −送信タイムアウトを獲得する SetTimeout −送信タイムアウトを設定する

【００８７】ｄ．TReceiveModifiersクラス このクラスは、TProtocolInterface::Receive()関数内
の受信フラグを定義するために使用する。

【００８８】このクラスは、ネットワーク・データを受
信しながら、フラグとタイムアウトを設定するためのメ
ソッドと定義を含む。以下の通りである。

【００８９】 kPeek −ピーク・ユーザ・データ kExpeditedData −優先データを受信する kReceiveAll −「ｎ」バイトが受信されるまでブロックす る kBroadcastData −同報データグラムを受信する kDiscardBufferOverflow −受信バッファからオーバフローするメッセ ージの一部を破棄する kDatagramAny −通常データグラムまたは同報データグラム のいずれかを受信する

【００９０】このクラスの重要な関数の一部を以下に示
す。

【００９１】 GetReceiveModifier −ReceiveModifier用の値を獲得する SetReceiveModifier −ReceiveModifierをＯＮに設定する ClearReceiveModifier −ReceiveModifierをＯＦＦに設定する GetTimeout −受信タイムアウトを獲得する SetTimeout −受信タイムアウトを設定する

【００９２】ｅ．SendCompletionクラス ネットワーク・データ送信操作に応答してSendCompleti
onオブジェクトが返される。これは、送信機能の状況を
示し、送信バイトの総数も示す。状況指示は以下の通り
である。

【００９３】 kNormal −正常完了 kTimeout −送信タイムアウト kCancelled −アプリケーションが送信要求を取り消した

【００９４】このクラスの重要なメソッドの一部を以下
に示す。

【００９５】 GetSTatus −SendCompletion状況を獲得する SetStatus −SendCompletion状況を設定する GetBytesTransferred −送信するクライアント・データのバイト数 を獲得する SetBytesTransferred −送信するクライアント・データのバイト数 を設定する

【００９６】ｆ．TReceiveCompletionクラス ネットワーク・データ受信要求に応答してReceiveCompl
etionオブジェクトが返される。これは、受信機能の状
況と、データ受信バイトの総数を示す。状況指示は以下
の通りである。

【００９７】 kNormal −正常完了 kPushed −送信側がデータを「プッシュした」 kNoMoreData −ストリームが終了するかまたは受信パイプ が閉じられた kEndOfMessage −メッセージの終わりが検出された kExpeditedData −優先データを受信した kTimeout −受信タイムアウト kMessageTruncated −部分メッセージであり、残りは破棄される kCancelled −取消し要求が処理された kMore −追加データの受信準備ができている

【００９８】このクラスの重要な関数の一部を以下に示
す。

【００９９】 GetStatus −ReceiveCompletion状況を獲得する SetStatus −ReceiveCompletion状況を設定する GetBytesTransferred −受信するクライアント・データのバイト数 を獲得する SetBytesTransferred −受信するクライアント・データのバイト数 を設定する

【０１００】ネットワーク事象管理 ここでは、複数のネットワーク・プロトコル・スタック
上で複数のネットワーク事象にアクセスし、それを様々
なプロトコル層で格納するという問題に対するオブジェ
クト指向の解決策を開示する。本発明では、ＯＳＩネッ
トワーク・プロトコル層モデルに基づくすべてのネット
ワーク事象の単一かつ一貫した１組のクラス定義を提供
する。各総称ＯＳＩ層ごとに事象が定義されているの
で、これらの層の各インプリメンテーションは追加のサ
ブクラスを定義することによって、追加の層固有の事象
を加えることを選択できるはずである。この解決策は、
オブジェクト指向モデルなので、ＯＯ技術で多様性と継
承を完全に利用する。

【０１０１】ＯＳＩ層に基づく事象の分類により、プロ
トコル層で格納され報告される事象が明確にカテゴリー
化される。このカテゴリー化により、アプリケーション
にとって重要であれば、特定の層について事象を取り出
すことができる。このような事象は、データが受信済み
で受信に使用可能である、接続が打ち切られたなど、確
立されているクライアントの通信セッションの条件を記
述することができる。クライアントは、単一の呼出しを
使用して、複数のプロトコル・スタックのいずれのプロ
トコル層上でもこれらの非同期事象を監視することがで
きる。本発明は、アプリケーションが個々の端点事象を
探す必要がなくなるように、ＴＣＰ／ＩＰやＮｅｔＢＩ
ＯＳなどの複数のプロトコルによる事象報告に及ぶ。さ
らに、ネットワーク事象機構により、層オブジェクト間
でネットワーク事象を送受信するためにネットワーク・
プロトコル層間でのやりとりが容易になる。

【０１０２】１．事象の説明 事象は、TProtocolEventという基本クラスを使用して定
義される。図１１は、様々な事象オブジェクト間のクラ
ス階層を示している。図１１は図２に似ているが、TEve
ntDefinitionクラス１０３のサブクラスであるTProtoco
lEventクラス４０１も示している。TProtocolEventクラ
ス４０１は、列挙されたクラスの事象と、すべてのＯＳ
Ｉ層で一般に使用される１組の事象と、個々のプロトコ
ル層事象用の値の予約範囲を含む。TProtocolEventクラ
スは、事象とメンバーシップの質問を設定し獲得するた
めのメソッドを有する。一実施例のネットワーク事象は
ビット・ベクトルとして設定されている。このクラスで
は、GetCntメソッドがこのオブジェクト内に現在ある事
象の数を返す。これは、この場合のオプション事象のリ
ストを指定する典型的な方法であり、一般に使用するも
う１つの方法は、ビット・マスクを使用する方法であ
る。オブジェクト内にすべてのデータを隠すというオブ
ジェクト指向技術の能力のために、単一オブジェクトだ
けが必要であり、そのオブジェクトがそれらを獲得する
ためのメソッドを提供する。

【０１０３】特定のネットワーク・プロトコルによって
は、TProtocolEventクラスで事象値を再定義することに
よって、プロトコル事象を定義することができる。TPro
tocolEventの重要なメソッドの一部は、識別されたイン
デックスの事象を返すGetEventと、リスト内の特定の事
象（メンバーシップ）を探索するHasAと、オブジェクト
内の事象の数を返すGetCntと、端点を示すアクセス定義
を返すGetAccessDefinitionと、端点用のアクセス定義
を設定するSetAccessDefinitionと、TProtocolEventオ
ブジェクト内の単一事象を設定するSetEventである。

【０１０４】２．ＯＳＩ層インプリメンテーションへの
事象インタフェース 上記のプロトコル・インタフェース・モデルの項で述べ
たように、好ましい実施例ではネットワーク・プロトコ
ル層が一連のTProtocolLayerオブジェクトとして実現さ
れ、それぞれが特定のＯＳＩ層を表している。これらの
オブジェクトは互いに連鎖され、プロトコル・スタック
を完成させている。たとえば、ＴＣＰ／ＩＰスタック
は、トランスポート層、ネットワーク層、データリンク
層用のオブジェクトを備えることができる。各プロトコ
ル層オブジェクトは２つの事象インタフェース、すなわ
ち、TProtocolLayerオブジェクトに定義されたReceiveE
ventインタフェースとCancelEventインタフェースとを
有する。これらの層では、上位層のオブジェクトに事象
を渡すためにDispatchEventメソッドを使用し、下位プ
ロトコル層に事象を送信するためにTransmitEventメソ
ッドを使用する。適切な層に事象を格納することは、プ
ロトコル・スタックのインプリメンテーションの責任で
ある。

【０１０５】TProtocolLayerクラスの事象関連メソッド
は、上位層に事象をディスパッチするDispatchEvent
と、下位層に事象要求待ち行列を伝送するTransmitEven
tと、EventRequestQueueにTProtocolEventオブジェクト
を追加することにより事象（複数も可）を報告するRece
iveEventと、EventRequestQueueを無視するCancelRecei
veEventである。

【０１０６】３．アプリケーションによる事象監視 それぞれのネットワーク・プロトコル層にオブジェクト
・ベースのＡＰＩ用の基本クラスを提供するTProtocolI
nterfaceクラス・オブジェクトは、ネットワーク事象を
受信するために端点が使用できる機能を含んでいる。TP
rotocolInterfaceクラスの事象関連機能は、特定の通信
端点用にTProtocolEventオブジェクトに設定された事象
（複数も可）を受信するReceiveEventメソッドである。

【０１０７】アプリケーションが複数の通信端点での事
象の監視を必要とするときは、TEventDefinitionオブジ
ェクトを使用する。TEventDefinitionオブジェクトは、
事象を監視するためのオブジェクト端点として機能す
る。このオブジェクトのインスタンスは、アプリケーシ
ョンの要求に応じて作成され削除される。TEventDefini
tionオブジェクトの主なメソッドは、TEventDefinition
オブジェクトのインスタンスをインスタンス化するInst
antiateDefinitionと、TEventDefinitionオブジェクト
のインスタンスを破棄するDeInstantiateDefinition
と、TProtocolEventオブジェクトのアレイまたは待ち行
列で複数のスタックからの事象を受信するReceiveEvent
Anyと、保留事象要求を取り消すCancelRequestである。

【０１０８】ａ．１つの通信端点での事象の受信 アプリケーションは、特定のネットワーク層用のTProto
colInterfaceクラスのインスタンスでReceiveEventメソ
ッドを使用して、特定の端点で事象を受信することがで
きる。ただし、端点はそのプロトコル用のTProtocolInt
erfaceオブジェクトを使用してプロトコルにアクセスす
ることに留意されたい。アプリケーション・プログラム
は、必要な事象をTProtocolEventオブジェクトに設定
し、次にReceiveEventメソッドを呼び出す。TProtocolI
nterfaceオブジェクトは、事象が発生していればその事
象を含むTProtocolEventオブジェクトを返す。

【０１０９】１つの通信端点で事象を受信するプロセス
を図１２の流れ図に示す。この例では、トランスポート
層が一番上の層であり、事象はネットワーク層に格納さ
れ、アプリケーションからの要求はトランスポート層に
対して行われる。

【０１１０】もう１つの代替方法は、事象を受信するた
めにその層への直接の事象インタフェースをセットアッ
プする方法である。しかし、このプロセスでは、あまり
有利ではない事象についてもすべての層をそのように処
置しなければならなくなる。１つの点から獲得する方が
良好なので、クライアントは選択基準として事象ベクト
ルを使用してすべての層から事象を獲得するように呼出
しを行う。

【０１１１】図１２は、単一端点での事象受信機構を示
している。端点で１つまたは多数の事象を受信するため
の要求は、TProtocolInterface::ReceiveEvent()メソッ
ド４１１を使用してインタフェース・オブジェクトに対
して行われる。結果的に端点から報告されるTProtocolE
ventsを含むProtocolEventQueue４１３が内部で作成さ
れる。次に、TProtocolLayer::ReceiveEvent()メソッド
４１５を使用して対応する層オブジェクトにその要求が
送られる。同図は、層オブジェクト間でどのように要求
が送られるかを示している。TProtocolEventQueueはRec
eiveEvent要求内のパラメータとして送られる。プロト
コル層オブジェクトは、事象が発生するたびに、TProto
colEventQueueを無効にするTProtocolLayer::CancelEve
nt()要求を受信する前に、この待ち行列にTProtocolEve
ntを待ち行列化する。要求された事象に応じて、TxxTra
nsportLayerは、TProtocolLayerクラスのTransmitEvent
()メソッドを使用してTxxNetworkLayerに要求を送るこ
とができる（４１７）。同様に、事象要求が下位層に到
達する必要がある場合には、TxxNetworkLayerは、要求
をTxxFamilyLayerに送ることもできる（４１９）。

【０１１２】事象が非同期に発生する場合、TProtocolL
ayerオブジェクトは、DispatchEvent()を使用してその
事象を上位層に報告することができる（４２１）。次に
ネットワーク層は、この事象をTxxTransportLayerに報
告する（４２３）。TxxTransportLayerは報告された事
象をProtocolEventQueueに待ち行列化する（４１５）。
次に、事象は呼出し側に報告される（４１１）。

【０１１３】ｂ．複数の通信端点での事象の受信 アプリケーションは、TEventDefinitionオブジェクトを
使用することにより、複数の通信端点の事象のための端
点を作成することができる。図１１に示すように、TEve
ntDefinitionクラス１０３はTNetworkDefinitionクラス
１００から派生している。TEventDefinitionオブジェク
ト１０３は、任意のプロトコルで任意の数の端点の事象
を監視するための端点として機能する。アプリケーショ
ン・プログラムにとって関心のある各通信端点ごとに、
必要な数のProtocolEventsがTProtocolEventオブジェク
トに設定される。すなわち、その事象が監視対象となる
すべての端点について、２タプル（端点、プロトコル事
象）の対が形成される。その後、アプリケーションは、
様々な端点から要求された事象の組を渡して、TEventDe
finitionオブジェクトのReceiveEventAny()メソッドへ
の呼出しを行う。ReceiveEventAnyは、TProtocolEvents
の待ち行列に事象を入れて復帰するか、またはタイムア
ウトする。ただし、すべての通信端点はTAccessDefinit
ionクラスを使用して作成されることに留意されたい。

【０１１４】図１３は、複数の端点での事象受信の流れ
を示している。

【０１１５】図１３は、複数の端点での事象受信機構を
示している。アプリケーションは、事象端点として機能
するTEventDefinitionオブジェクトを作成する（４５
１）。次にアプリケーションは、端点当たり１つずつ、
TProtocolEventオブジェクトのアレイを作成する（４５
３）。端点での要求された事象のアレイがパラメータと
してTEventDefinition::ReceiveEventAny()に渡される
（４５５）。ReceiveEventAny()メソッドは、TProtocol
EventQueueを作成し（４５７）、事象が探索されるすべ
ての端点に待ち行列を送る（４６１）。ReceiveEvent要
求を介して要求を受信する（４６３）TxxProtocolLayer
は、それより下の層に事象要求を伝送することができ
る。これは、どの端点についても同じである（４６
５）。TxxProtocolLayerは、事象を非同期に受信する
と、上位層にその事象をディスパッチするか、またはTP
rotocolEventQueueで事象を報告することができる。事
象がTProtocolEventQueueに入ると、すべての関連端点
のTxxProtocolLayerにTxxProtocolLayer::CancelEven
t()が送られる。次に、ReceiveEventAnyメソッド４５５
は、TProtocolEventQueueからすべてのTProtocolEvents
を取り出し（４５９）、それを呼出し側に報告する。報
告する事象がまったくない場合には、待ち行列が空であ
るはずである。

【０１１６】いずれかの端点から応答が受信された後、
すべての端点はCancelEvent要求を受け取り、ProtocolE
ventQueueオブジェクトの寿命が終了したことを示す。
その要求が取り消された場合でも、事象は依然としてプ
ロトコル層に保管される。クライアントは、次に新しい
事象を獲得するときに、別のReceiveEventとともに戻る
ことができる。この実施例では、クライアントからのプ
ル・モデルを使用するが、クライアントにとって便利な
ときにクライアントが事象を獲得することを意味する。
呼出し側には収集された１組のProtocolEventsが返され
る。

【０１１７】動的実行ユニット管理 マルチタスキング・システムでは、ＴＣＰ／ＩＰなどの
ネットワーク・プロトコル・スタックは、クライアント
／サーバ・モデルを使用して効率よく実現することがで
きる。サーバは、多数のクライアントをサポートするた
めにマルチタスキング技法を使用してユーザ・レベル・
タスクにすることができる。多数のクライアントをサポ
ートする際に十分なパフォーマンスを保証するため、固
定した１組のサーバ資源を特定のプロセスに事前割振り
することが必要な場合も多い。重要なサーバ資源の１つ
は、割り振られたサーバ実行ユニットの数である。ＯＳ
／２やWindows NTなどの最新のオペレーティング・シス
テムでは、実行の基本ユニットはスレッドである。現在
の多くのシステムは「軽量」スレッド（高速スレッド切
替えを意味する）を備えているが、残念ながら、スレッ
ド作成／削除は、何千ものクライアントをサポートする
ために拡大したときに本発明が提案するようなネットワ
ーク・プロトコル・サーバのパフォーマンス要件をサポ
ートできるほど十分「軽量」ではない。

【０１１８】さらに、スレッドの数が増すにつれて、シ
ステム、すなわち、サーバのパフォーマンスは大幅に低
下する。スレッド切替えのオーバヘッドは、システム内
に割り振られたフットプリントに加え、スレッドの数が
増すにつれて比例して増加する傾向がある。これは、ネ
ットワーク・セッション下の全二重通信で２つのスレッ
ドに入れてデータの送受信を実行するなど、同じクライ
アントからの複数の同時要求をサポートする必要があり
そうなネットワーク・サーバの場合にさらに複雑にな
る。その結果、複数の同時クライアント対応専用のサー
バ内のスレッドの数は非常に大きくなる可能性がある。
したがって、スレッドなどのサーバ実行ユニットを効率
よく管理することは、十分なパフォーマンスを備えた多
数のクライアントをサポートするサーバの能力にとって
重要なことである。

【０１１９】ここでは、ネットワーク・プロトコル・サ
ーバが実行スレッドの数を動的に管理するための方法を
開示する。この方法は、多数のクライアントに対応する
のに必要なスレッド資源を低減する。個々のクライアン
トがサーバ割振りのスレッド資源をすべて消費してしま
わないように、進入制御が設けられている。同時に、サ
ーバ・スレッド資源を待って特定のクライアントをいつ
までも停止させておくことはない。

【０１２０】１．サーバ実行ユニット管理 サーバ・スレッドは、サーバ・スレッド・プールで作成
され管理される。まずサーバが始動すると、サーバ管理
スレッドが作成される。好ましいオブジェクト指向の実
施例では、これは、以下に記載するクライアント・ポー
ト・プールとネットワーク・サーバ・スレッド・プール
を管理するためのメソッドを含むTNetworkServerクラス
・オブジェクトをインスタンス化することによって行わ
れる。サーバ管理スレッドは、スレッド・プールでのサ
ーバ・スレッドの作成または削除を調整することによ
り、サーバ・スレッド・プールの管理を担当する。サー
バ管理スレッドは通常、休眠状態である。これは、要求
信号とタイマによって定期的に起こされる。

【０１２１】すべてのクライアント要求サービスは、最
初にサーバとのセッションを確立しなければならない。
セッション要求は、session_portという単一のサーバ通
信端点に送られる。サーバとの通信セッションが確立し
た後、各クライアントにはclient_portという固有の通
信端点が割り当てられる。好ましい実施例では、TAcces
sDefinitionオブジェクトとサーバ側で割り当てられた
各client_portとの間に１対１の対応が存在する。

【０１２２】クライアントとサーバは、ＲＰＣ機構を使
用して互いにやりとりすることができる。遠隔プロシー
ジャ呼出し（ＲＰＣ）機構は、後述するように必要な要
求経路指定と進入制御を行う。ＲＰＣ機構は、基礎とな
るオペレーティング・システムの内部プロセス通信の内
部プロシージャ呼出し（ＩＰＣ）サービスの上に構築す
ることができる。サーバ・タスクの位置の特定に加え、
基本ＲＰＣプリミティブは以下の通りである。

【０１２３】クライアント側 ○ SendRequest (server_port(セッションまたはクラ
イアント), request_data, reply_data) サーバ側 ○ ReceiveRequest (request_data) ○ SendReply (reply_data)

【０１２４】すべてのクライアントのclient_portはcli
ent_portプールに収集される。その割当てclient_port
を使用して、クライアントはサーバにネットワーク要求
を出すことができる。サーバは、client_portプールか
らの要求を管理し、スレッド・プール内のスレッドを任
意の数のclient_portプールから受け取ったサービス要
求に割り当てる。図１４は、オブジェクト指向ネットワ
ークの第１の実施例でのclient_portプールとスレッド
・プールの制御及び管理の流れを示しているが、クライ
アントおよびサーバ・アプリケーション・オブジェクト
は対称マルチプロセッサ（ＳＭＰ）などのマルチプロセ
ッサ構成の各種プロセッサに割り振られたメモリ内に常
駐し、両者はオブジェクト指向ＲＰＣインタフェースを
介してやりとりする。

【０１２５】複数のクライアント・マシン５００は、ネ
ットワーク５０５によりサーバ・マシン５０３に連絡す
る。それぞれのクライアント・マシン５００は、それぞ
れがクライアント要求を行うことができる複数のクライ
アント・アプリケーション・オブジェクト５０７を常駐
させておくことができる。図示の通り、クライアント・
オブジェクト５０７は、ＲＰＣ／ＡＰＩ層５０９の適切
なＲＰＣ／ＡＰＩオブジェクトに自分の要求を送り、そ
の層は異なるアドレス空間で動作するＩＰＣオブジェク
ト５１１を使用してサーバへの接続を行う。プロトコル
・スタックは、ネットワーク５０５への通信経路を確立
する。この実施例によれば、クライアント・マシンまた
はクライアント・タスクが要求されたサーバでその許容
量の通信スレッドを超えているかどうかを判定するため
に、以下に詳述するスレッド・カウント・オブジェクト
がプロトコル・スタックに追加されている。超えていな
い場合、通信経路は作成されず、クライアント・プロセ
スは使用可能なスレッドを待つように指示されるか、ま
たはプロトコル・スタックが単にクライアント・プロセ
スへのサービスを拒否することになる。同図にはサーバ
が１つだけ示されているが、スレッド・カウント・オブ
ジェクトは、ネットワーク内の複数のサーバ・マシンで
クライアント口座を追跡することができる。

【０１２６】サーバへの通信経路が確立されると想定し
て、プロトコル・スタック５１３は、サーバ側の通信端
点であるセッション・ポートを割り当てるセッション・
ポート・オブジェクト５１９に送るクライアント要求を
受信する。クライアント要求には、クライアント・プー
ル・オブジェクト５２１からクライアント・ポートが割
り当てられる。クライアント・ポートは、サーバ側のス
レッド・プール５２２に使用可能な十分なスレッドがあ
る場合にクライアント・プロトコル・スタックに返され
るクライアント通信端点である。セッション・ポート割
振りと、クライアント・ポート・プールと、スレッド・
プールとを管理する１組のネットワーク・プロトコル・
サーバ・オブジェクトについては、以下に詳述する。ス
レッドと、クライアント・ポートと、セッション・ポー
トが割り振られると、サーバ・セットのＲＰＣ／ＡＰＩ
オブジェクト５１５と、上方向のサーバ・サービス５１
７への通信を続行することができる。

【０１２７】動的実行ユニット管理は、手続きベースの
システムでも実行することができる。また、図１５に示
すように、この機構は、メモリがクライアント空間５３
１とサーバ空間５３３に分割される単一プロセッサ・マ
シンや、複数のクライアント・タスク５３５、５３７、
５３９がサーバ・タスク５４０と同じマシンで動作する
環境に応用することもできる。クライアント・タスク
は、その要求をクライアント側のＲＰＣライブラリ・イ
ンタフェース５４１を介してサーバ・タスクに送る。要
求はまず、サーバ側のＲＰＣライブラリ５４３によって
サーバ側で処理される。次に、セッション・ポート・プ
ロセス５４５によってセッション・ポートが割り振ら
れ、クライアント・ポート・プール５４７からクライア
ント・ポートが割り振られる。プロトコル・スタック５
５１がネットワーク５５３へのクライアント要求を処理
できるように、スレッド・プール５４９からスレッドが
割り当てられる。

【０１２８】プール内のスレッドの数は、複数のシステ
ム構成変数によって制御される。これらの変数の修正
は、ユーザ構成プログラムを使ってシステム管理者が行
うことができる。

【０１２９】○（MinThreads）−これは、クライアント
要求に対応するために予約されたスレッドの最小数であ
る。この限界は、典型的なサーバ・ロードのクライアン
トをサポートするために使用するスレッドの最小数を維
持するためのものである。

【０１３０】○（MaxThreads）−これは、クライアント
要求に対応するために予約されたスレッドの最大数であ
る。この限界は、サーバ・システムの過負荷にならずに
ピーク・ロードのクライアントの対応専用となるスレッ
ド資源に関する上限として使用するものである。

【０１３１】○（MaxReq）−これは、所与のクライアン
トに割り振られる同時要求の最大数である。

【０１３２】○（TotalThreads）−これは、すべてのク
ライアント要求に対応するために作成されたスレッドの
総数である。この値は、必ずMinThreadsとMaxThreadsと
の間になる。

【０１３３】○（ReservedThreads）−これは、すべて
のクライアント・セッションをサポートするために予約
されたスレッドの総数である。

【０１３４】○（Unusedthreads）−これは、プール内
の未使用スレッドの数である。

【０１３５】○（Clientthreads）−これは、各クライ
アントごとに、サーバが対応する活動要求の数である。

【０１３６】プール内のスレッドの数は、同時に処理さ
れる活動クライアント要求の数に基づいて、動的に増加
または減少する。

【０１３７】スレッドの数を管理するために使用するプ
ロセス、すなわち、オブジェクト指向実施例のメソッド
については、図１６〜１９を参照して以下に詳述する。

【０１３８】図１６を参照すると、ステップ５７５のサ
ーバ初期設定では、＜MinThreads＞個のスレッドが作成
され、スレッド・プールに挿入される。また、このステ
ップでは、（UnusedThreads）と（TotalThreads）が（M
inThreads）に設定され、（ReservedThreads）が０に設
定される。ステップ５７７では、新しいクライアントが
サーバとのセッションを要求する。サーバ側では、クラ
イアント要求を受信後に、（ReservedThreads）＋（Max
Req）＜＝（MinThreads）であるかどうかを判定するた
めにステップ５７９でテストが行われる。この結果が真
であれば、既存のクライアントと新しいクライアントを
サポートするために十分なスレッドが存在するので、ス
レッド・プールを調整するためのアクションは一切行わ
れない。

【０１３９】ステップ５８１では、サーバがクライアン
ト・タスクにclient_portを割り当てて返す。ステップ
５８３では、（ReservedThreads）が（MaxReq）だけ増
分され、新しいクライアントがセッションを要求するま
で待つためにステップ５７７に戻る。

【０１４０】ステップ５７９のテストが否定の場合、ク
ライアント要求が許可された場合に最大数のスレッドを
超えるかどうかを判定するためにステップ５８５でテス
トが行われる。（MinThreads）＜（ReservedThreads）
＋（MaxReq）＜（MaxThreads）かどうかのテストが行わ
れる。この結果が真であれば、スレッド限界を超えてお
らず、プロセスはステップ５８１に移行し、クライアン
ト・タスクにクライアント・ポートを割り当てて返す。
ステップ５８３では、（ReservedThreads）が（MaxRe
q）だけ増分される。後述するように、この図のプロセ
スはこの分岐と上記の分岐の場合に同じように見える
が、管理スレッドは、新しいカウント（ReservedThread
s）に基づいて次に起こされたときにスレッド・プール
内のスレッドを非同期に増加する。

【０１４１】ステップ５８５のテストが肯定の場合、す
なわち、（ReservedThreads）＋（MaxReq）＞（MaxThre
ads）である場合、ステップ５８７でクライアント要求
が拒否される。したがって、サーバは、過負荷の状況を
回避するためにクライアント・セッション進入制御を管
理する。ステップ５８９では、スレッドが他のクライア
ント・タスクから解放されるまで、サーバは待ち状態に
入り、おそらくクライアントに待ち状態を通知するはず
である。あるいは、サーバは、クライアント要求を拒否
し、後でクライアントがもう一度試行できるようにする
だけである。

【０１４２】以下の擬似コードは、このプロセスの実現
例を示している。

【０１４３】 New client request session with server On the server - If (ReservedThreads) + (MaxReq) <= (MinThreads), (ReservedThreads) increment by (MaxReq) Assign and return a client_port to the client If (MinThreads < (ReservedThreads) + (MaxReq) < (MaxThreads) Increment (ReservedThreads) by (MaxReq) Assign and return a client_port to the client If (ReservedThreads) + (MaxReq) > (MaxThreads) Reject the network request

【０１４４】図１７には、クライアント要求の進入制御
を管理するためのクライアント側プロセスが示されてい
る。ステップ６０１では、クライアント・タスクがサー
バに割り当てられたクライアント・ポートを使用して新
しいネットワーク要求を出す。ステップ６０３では、ク
ライアント・タスクがサーバ側の許容数のスレッドのう
ち使用可能な複数のスレッドを備えているかどうかを判
定するためにテストが行われる。これを判定するため
に、（ClientThreads）＜（MaxReq）かどうかのテスト
を使用することができる。備えている場合、ステップ６
０７でクライアント要求はサーバに送られる。ステップ
６０９では、現行クライアント・スレッドの数が増分さ
れる。

【０１４５】サーバ側の許容数のスレッドのすべてが使
用中である場合、ステップ６０５でネットワーク要求が
拒否されるか、またはこのクライアントからの同時要求
の数が（MaxReq）より少なくなるまで待機状態に入る。
待機状態になっているときに、許容スレッドの１つが解
放された場合、プロセスはステップ６０５からステップ
６０７に進むことができる。

【０１４６】図１７には、クライアント要求に対応する
ためにスレッド・プール内のサーバ・スレッドを割り当
て、プール内のスレッドの数を調整するためのサーバ側
のプロセスも示されている。ステップ６１１では、クラ
イアント要求の処理に必要な期間中、サーバ・スレッド
がクライアント要求に割り当てられる。ステップ６１３
では、（UnusedThreads）変数が減分される。ステップ
６１５では、スレッド・プール内のスレッドの数が許容
できるかどうかを判定するためにテストが行われる。
（（UnusedThreads）＜（MinThreads）＆（TotalThread
s）＜（MaxThreads））かどうかのテストは、このステ
ップを実行するためのテストの１つである。スレッド・
プール内の使用可能なスレッドの数が許容できない場合
には、スレッド・プール内のスレッドの数を増加するよ
うに管理スレッドに通知される。プロセスはステップ６
１９で終了する。

【０１４７】以下の擬似コードは、このプロセスの実現
例を示している。

【０１４８】 Client issues network request to the server If (ClientThreads) < (MaxReq), Send the request to the server. Increment (ClientThreads) else Reject the network request

【０１４９】 Assign server thread to service client request Decrement (UnusedThreads) If (UnusedThread)<(MinThread)&(TotalThread)<(MaxThread) Increase threads in the thread pool

【０１５０】図１８には、サーバがクライアント・ネッ
トワーク要求を完了したときにクライアントとサーバが
従うプロセスが示されている。サーバ側では、ステップ
６２５でクライアント要求にどのような処理が必要であ
ってもその処理をサーバが完了している。ステップ６２
７では、プロトコル・スタックを介してクライアント要
求への応答が送られる。次に、ステップ６２９では、サ
ーバ・スレッドがスレッド・プールに返される。次に、
ステップ６３１では、（UnusedThreads）変数が増分さ
れる。

【０１５１】クライアント側では、ステップ６３５でプ
ロトコル・スタックがサーバからの応答を受け取る。ス
テップ６３７では、他のクライアント・タスクが通信ス
レッドのクライアント割振り分を使用できるようにする
ために、（ClientThreads）変数が減分される。ステッ
プ６３９では、（ClientThread）が（MaxReq）限界を上
回っているためにサーバに要求を送るために待機してい
る同じクライアントから任意のスレッドを起こすための
信号が出される。ステップ６４１では、プロセスが図１
７のステップ６０７に移行する。

【０１５２】図１９には、サーバ管理スレッド・プロセ
スが示されている。サーバ管理スレッドは、スレッド・
プール内の未使用スレッドの数がある程度低い限界より
下がったときにスレッド割振りのためにタイマまたは信
号によって起こされる。ステップ６５３では、さらにス
レッドを追加する必要があるかどうかを判定するための
テストが行われる。適当なテストの１つは、（（Unused
Threads）＜（MinThreads）＆（TotalThreads）＜（Max
Threads））かどうかである。そうではない場合、ステ
ップ６５４で管理スレッドが休眠状態に戻る。そうであ
る場合、ステップ６５５で（（UnusedThreads）−（Min
Threads））個のスレッドをプールに加えるという式に
応じて、通信スレッドがスレッド・プールに追加され
る。ステップ６５７では、（UnusedThreads）が（MinTh
reads）と等しくなるように設定される。ただし、Unuse
dThreadsが（MinThreads）限界より下がったときだけ、
ただちにスレッドが追加されることに留意されたい。そ
れ以外の場合は、次のタイマ間隔までスレッドが遅延さ
れる。ステップ６５９では、（TotalThreads）変数が追
加したスレッドの数だけ増分される。管理スレッドはス
テップ６５４の休眠状態に戻る。

【０１５３】図１９では、パフォーマンスを改善するた
めに通信スレッド・プール内の未使用スレッドの数を低
減するためのサーバ管理スレッド方法も示している。ス
テップ６６１では、通信スレッドの割振りまたは割振り
解除のために定期的にスレッドを起こすタイマによっ
て、スレッドが起こされる。ステップ６６３では、スレ
ッド・プール内のスレッドが多すぎるかどうかを判定す
るためのテスト、たとえば、（（ReservedThreads）＜
（MinThreads））＆（（UnusedThread）＞（MinThread
s））かどうかなどが行われる。そうではない場合、ス
テップ６６４で次の間隔までスレッドが休眠する。そう
である場合、ステップ６６５でプール内のスレッドの数
が１だけ低減される。ステップ６６７では、（TotalThr
eads）が１だけ減分される。所定の期間中にまったく活
動が発生しない場合、結果的に（TotalThreads）変数が
（MinThread）に戻ることになる。ステップ６６９で
は、スレッド・プール内の未使用スレッドが少なすぎる
かどうかをテストが判定する。（ReservedThreads）＞
（TotalThreads）＆（（ReservedThreads）＜（MaxThre
ads））かどうかの式を使用することができる。そうで
ある場合、（（ReservedThreads）−（TotalThread
s））を加えるという式に応じて、スレッドがスレッド
・プールに追加される。ステップ６７３では、（TotalT
hreads）変数が（ReservedThreads）に設定される。管
理スレッドはステップ６７４の休眠状態に戻る。

【０１５４】本発明の利点としては、セッションおよび
通常クライアント要求の進入制御がある。さらに、クラ
イアント要求に対応するためのスレッド資源がクライア
ント・タスクに認められた限界まで必ず保証されてい
る。したがって、サーバ・スレッド資源を待ってクライ
アントをいつまでも停止させておくことはない。

【０１５５】すべてのクライアント間で共用可能な事前
割振りスレッドの場合、クライアント要求に対応するス
レッド実行経路でスレッドの作成または削除が行われな
いので、サーバのパフォーマンスによってクライアント
要求への応答時間が改善される。非活動の期間中に割振
り済みスレッドの数を（MinThreads）まで定期的にプル
ーニング・バックすることによって、オーバコミット・
スレッド資源が最小限になる。プール内のサーバ・スレ
ッドの総数は、構成値（MaxThreads）まで拡大すること
ができる。非活動スレッドは最小限に維持されるので、
これによりシステム・オーバヘッドが低減される。

【０１５６】（MaxThreads）と（MinThreads）は構成限
界であり、システム管理者がアクセスできるようにする
ことができるので、本発明によって動的スレッド資源調
整が達成される。これらは、手作業で構成して、導入シ
ステムに最適な最小値に調整することによって調整する
ことができる。あるいは、クライアントと同時クライア
ント要求の数について、１日の様々な時間に統計をとり
続け、これらの統計に基づいて自動的に（MinThreads）
と（MaxThreads）の値を計算し調整することもできる。

【０１５７】マルチスレッド化クライアント／サーバ・
システムではスレッド・プールの概念が一般に使用され
てきたが、クライアントの数とクライアントの使用法に
基づく通信スレッド・プールの動的調整はこれまで行わ
れていない。本発明は、長期または短期で動作するクラ
イアント要求に対応するために同様に適用可能である。
さらに、ユーザ・レベルで動作するネットワーク・プロ
トコル・サーバを実現するためのスレッド・プールの使
い方は、先行技術では実施されていない。

【０１５８】本発明は、サーバがマルチタスキング化さ
れ、多数のクライアントを効率よくサポートしなければ
ならない、いかなるクライアント／サーバ・システムで
も実施することができる。この解決策は、ＩＢＭメイン
フレームＭＶＳや多くのＵＮＩＸベースのシステムな
ど、軽量の実行ユニットを持たないシステムには特に有
用である。

【０１５９】前述のように、上記のアルゴリズムを使用
するネットワーク・プロトコル・サーバは、１組のネッ
トワーク・サーバ・クラスを定義することによって、オ
ブジェクト指向技術を使用して実現することができる。
このようなクラスの定義例を以下に示す。

【０１６０】 クラスTNetworkServer：公用TNetworkThreadHandle { 公用： TNetworkServer−クラス・コンストラクタ 〜TNetworkServer−クラス・デストラクタ AddClientPort−クライアント・ポート・プールにポートを追加する RemoveClientPort−クライアント・ポート・プールからポートを除去す る AddServerThread−ThreadPoolにスレッドを追加する DeleteServerThread−ThreadPoolからスレッドを削除する ExecuteMgmtThread−管理スレッド入口 ExecuteThread−NetworkThread入口点 私用： RegisterNames−クライアントにとって使用可能になるべきサーバ名を 公表する

【０１６１】 ネットワーク・サーバ実行用に使用するネットワーク・スレッド・クラス クラスTNetworkThreadHandle： { 公用： TNetworkThreadHandle−クラス・コンストラクタ TNetworkThreadHandle−クラス・デストラクタ Fork−クラス関数を実行する新しいスレッドを開始する Join−スレッドが完了するまで待つ Release−スレッドがそのオブジェクトを削除できることを示す

【０１６２】 ネットワーク・クライアント／サーバ通信用のＲＰＣクラス class TNWRPCMessage { 公用: virtual TNWRPCMessage(); virtual 〜TNWRPCMessage(); /* クライアント側メソッド: SendRequest() */ virtual kern_return_t SendRequest (const port_t& clientport, void* buffer, int& buflen); // buffer used for inbound/outbound virtual kern_return_t SendRequest (const port_t& sessionport, port_t& clientport, void* buffer, int& buflen); /* サーバ側メソッド: ReceiveRequest() & Reply&Receive() */ virtual kern_return_t ReceiveRequest (const port_t& sessionport void* buffer, int& buflen); virtual kern_return_t ReceiveRequest (const port_t& clientport_pool, void* buffer, int& buflen, port_t& clientport); virtual kern_return_t SendReply (const port_t& newclientport, void* buffer, int& buflen, port_t& sessionport); virtual kern_return_t SendReply (const port_t& clientport, void* buffer, int& buflen); };

【０１６３】クライアント／サーバ環境でのネットワー
ク要求の表現 ここでは、クライアント／サーバ・モデル用のネットワ
ーク・プロトコル要求のオブジェクト指向表現を示す。
プロトコルＡＰＩがオブジェクト指向で、プロトコル・
インプリメンテーションもオブジェクト指向の場合に
は、プロトコル要求のオブジェクト指向表現は重要なも
のになる。ネットワーク・プロトコルにアクセスするた
めのオブジェクト・ベースのクライアント要求がサーバ
に送られ、このサーバがこれらの要求を適切なネットワ
ーク・プロトコル層オブジェクトに送達する。本発明
は、クライアント・ネットワーク要求を転送し、その要
求をサーバ上に常駐する適切なネットワーク・プロトコ
ル層に送達し、要求の結果をクライアント・アプリケー
ションに取り出すための新しい方式を提示する。クライ
アント要求は「ネットワーク操作」オブジェクトで折り
返されるが、そのオブジェクトはサーバがネットワーク
・プロトコル層オブジェクトに要求を提示できるように
必要な情報をすべて含んでいる。

【０１６４】以下のシナリオを検討されたい。クライア
ントＡＰＩは１組のオブジェクト指向ネットワーク・プ
ロトコル・インタフェース要求を含み、プロトコルはオ
ブジェクトのスタックとして実現され、それぞれのオブ
ジェクトは特定のＯＳＩ層を表している。ネットワーク
・プロトコル・スタックは、ネットワーク・サーバ上に
常駐する様々なネットワーク・プロトコルを提供し、ク
ライアントとサーバとの間でやりとりするためにＲＰＣ
またはＩＰＣなどの通信機構が存在する。クライアント
が何らかのデータの送信のようなネットワーク活動を要
求した場合、サーバ上の適切なネットワーク・プロトコ
ル・スタックにその要求を伝送する必要がある。本発明
は、このようなクライアント要求をサーバに転送するた
めの統一方式を提示する。この方式は多様性を利用して
いるので、このような要求を発送し、それをサーバで処
理するプロセスは、どの要求およびプロトコル・スタッ
クについても変わらない。

【０１６５】ネットワーク・プロトコルにアクセスする
ためのクライアント・インタフェースは、主にTProtoco
lInterfaceクラスによる。このプロトコル・インプリメ
ンテーションは、TProtocolLayerクラスに基づいてそれ
ぞれのＯＳＩ層を表している。このネットワーク・サブ
システムは、ＴＣＰ／ＩＰやＳＮＡなどの各プロトコル
用のTFamilyLayerオブジェクトと、TDataLinkLayerオブ
ジェクトから構成され、どちらのオブジェクトもシステ
ム内に常駐している。セッション層、トランスポート
層、ネットワーク層を表すためのTProtocolLayerオブジ
ェクトのスタックはすべてのクライアント端点ごとに作
成され、クライアント通信端点はTAccessDefinitionオ
ブジェクトによって記述される。このような概念、関連
クラス、その機能については、いずれも上記のプロトコ
ル・インタフェース・モデルの項で説明する。

【０１６６】１．ネットワーク操作オブジェクト クライアントからサーバへのネットワーク要求とその逆
のネットワーク要求は、いずれもTNetworkOperationオ
ブジェクトを使用して転送される。TNetworkOperation
オブジェクトは、サーバ内のプロトコル層にクライアン
ト・ネットワーク要求を伝送し、その結果をサーバから
クライアントにリレーするための機構を提供する。

【０１６７】TNetworkOperationクラスは、すべての要
求の基本クラスである。クライアント・インタフェース
がサーバに対して行う各要求ごとに、TNetworkProtocol
からサブクラスが派生している。TProtocolInterfaceメ
ソッドのそれぞれについて、対応する「操作オブジェク
ト」クラスが１つずつ定義されている。図２０は、いく
つかのクライアント要求用のクラス・オブジェクトのク
ラス階層を示している。TNetworkOperationクラス７０
１は階層の一番上に位置する。TConnectOpクラス７０３
と、TSendOpクラス７０５と、TReceiveOpクラス７０７
と、TDisconnectOpクラス７０９と、TBindOpクラス７１
３は、いずれも基本クラスから派生したもので、TProto
colInterfaceクラスの接続操作、送信操作、受信操作、
切断操作、バインド操作にそれぞれ対応する。GetPeerN
ameおよびGetLocalNameなどの獲得および設定要求は、T
GetSetNetworkOpクラス７１１という１つの操作クラス
にバンドルされている。

【０１６８】TNetworkOperationオブジェクトは、ネッ
トワーク・サーバでの対応を必要とする要求を満足する
ためにTProtocolInterfaceによって作成される。TNetwo
rkOperationから派生したクラスは、インタフェースか
らの特定の要求を表す。TNetworkOperationオブジェク
トは、要求が適切なプロトコル層に伝送されるように、
ＲＰＣ／ＩＰＣ機構を使用してネットワーク・サーバに
送られる。ネットワーク・サーバがNetworkOperationオ
ブジェクトを受け取ると、それは操作オブジェクト上で
Execute()メソッドを呼び出し、次に適切なプロトコル
・インプリメンテーション層オブジェクト上で対応する
関数を呼び出す。

【０１６９】したがって、TNetworkOperationオブジェ
クトは、それに対して要求したタスクを実行するために
「組込み知能」を備えている。ネットワーク・サーバ
は、TNetworkOperationオブジェクトを受け取ると、そ
のオブジェクト内のExecute()メソッドを呼び出す。ク
ライアント要求の特徴とは無関係に、サーバ機能は同じ
である。各クライアント要求用のExecute()メソッド
は、クライアント要求を適切なプロトコル層オブジェク
トに伝送するために必要な情報をすべて含んでいる。

【０１７０】TNetworkOperationオブジェクトは、TProt
ocolInterfaceの具象クラスでも作成することができ
る。たとえば、TBindOpのデフォルト・クラスがＴＣＰ
／ＩＰの要求を満足しない場合、ＴＣＰ／ＩＰインタフ
ェースは、TTCPBindOpクラスを作成するようにTBindOp
を指定変更する。その後、クライアントがバインド要求
を行うと、具象ＴＣＰ／ＩＰクライアントＡＰＩを表す
TTCPINFクラスはTTCPBindOpオブジェクトを作成する。
特定のクライアント要求の意味を再定義するか、または
新しい要求とその操作オブジェクトを追加することをTN
etworkOperationクラスから継承できる能力により、こ
の方式は極めて柔軟かつ強力なものになる。

【０１７１】図２１は、特定のクライアント要求を満た
すために作成されるクラス・オブジェクトのクラス階層
を示している。同図のTTCPBindOpオブジェクト７１５
は、クライアント・アプリケーションからのバインド要
求に対応するTTCPTINF::Bind()メソッドによって作成さ
れる。これにより、TProtocolInterface::Bind()メソッ
ドが指定変更される。TTCPNew1Op７１７とTTCPNew2Op７
１９は、いくつかのクライアント要求の場合にＴＣＰ／
ＩＰに固有の２つの新しい操作オブジェクトの例であ
る。

【０１７２】２．TNetworkOperationの関数 TNetworkOperationクラスが提供する重要な関数の一部
を以下に示す。

【０１７３】Classコンストラクタ： この関数は、ク
ライアント・アプリケーションによる要求の対象となる
プロトコル層インデックスを設定するものである。

【０１７４】層インデックスは、その要求をプロトコル
・スタックのトランスポート層、ネットワーク層、ファ
ミリー層のいずれに送るべきかを識別するものである。

【０１７５】Execute()： この関数は、TNetworkOpera
tionオブジェクトを受け取ったときにサーバによって呼
び出される。この関数は、操作オブジェクトから層イン
デックスを獲得し、操作オブジェクトから関連パラメー
タを収集し、スタックの適切なTProtocolLayerオブジェ
クトへの呼出しを行うものである。たとえば、TBindO
p::Execute()は、TTCPProtocolAddressオブジェクトをB
ind()関数へのパラメータとしてTProtocolLayer::Bin
d()を呼び出すはずである。

【０１７６】Get/SetLayerIndex： この関数は、操作
オブジェクトで層インデックスを返す／設定するもので
ある。

【０１７７】SetLocationToClient： デフォルトで
は、操作オブジェクトがその位置をサーバに設定する。
操作オブジェクトは、サーバ上にあるか、クライアント
上にあるかによって、挙動が異なってくる。たとえば、
TProtocolLayer::Bind()関数へのパラメータなので、TB
indOpはTNetworkAddressオブジェクトをサーバに送る必
要がある。しかし、サーバはアドレスをクライアントに
戻す必要はない。位置フラグを使用して、パラメータの
受渡しが制御される。ネットワーク操作オブジェクトが
クライアントによって作成されると、そのオブジェクト
は位置をクライアントに設定する。

【０１７８】Stream-out演算子： この関数は、操作オ
ブジェクトを平坦化し、そのオブジェクトのデータ・メ
ンバーをデータ・ストリームに入れるために使用する。
たとえば、TBindOp用のStream-out演算子は、それがク
ライアントからのオブジェクトを送信する場合にTNetwo
rkAddressオブジェクトを平坦化する。TSendOpは、バッ
ファおよび宛先アドレスをサーバに送るためにバッファ
・アドレスとTNetworkAddressオブジェクトを平坦化す
ることができる。次にサーバはSendOp::Execute()を呼
び出し、次にこれがユーザ・データとともにTProtocolL
ayer::Xmit()メソッドを呼び出して、宛先にデータを送
る。送信が完了すると、サーバはＲＰＣ／ＩＰＣ機構を
使用してTSendCompletionオブジェクトをクライアント
に戻す。TSendOp用のStream-out演算子は、それがサー
バであるかどうかを検査し、TSendCompletionオブジェ
クトをストリームアウトする。

【０１７９】Stream-in演算子： この関数は、オブジ
ェクトが平坦化された場合にデータ・ストリームからオ
ブジェクトを再構築するために使用する。Stream-out演
算子とは逆の操作であることは明らかである。操作オブ
ジェクトは、データ・ストリームにオブジェクトを平坦
化したり、データ・ストリームからオブジェクトを再構
築するために位置フラグを使用する。

【０１８０】３．クライアントサーバ通信 ユーザが作成するどの通信端点についても、プロトコル
層オブジェクトのスタックに端点を関連付けるために維
持しなければならない固有のＩＤが存在していなければ
ならない。プロトコル層オブジェクトは、サーバ・プロ
セス上の端点を表す。ただし、この対応は１対１である
ことに留意されたい。このため、TAccessDefinition::I
nstantiate()メソッドを使用して端点の作成中にTAcces
sOpオブジェクトが作成される。TAccessOpオブジェクト
は、通信のクライアント側を表すClientStackHeadオブ
ジェクトを作成する。次にTAccessOpオブジェクトは平
坦化され、ClientStackHeadによりＲＰＣまたはＩＰＣ
機構を使用してサーバに送られる。次にサーバは、TNet
workOperationのstream-in演算子を使用してデータ・ス
トリームからTAccessOpオブジェクトを再構築し、TAcce
ssOp::Execute()メソッドを呼び出す。この関数は、プ
ロトコル・インタフェース・オブジェクトからプロトコ
ル層オブジェクトを作成するServerStackHeadオブジェ
クトを作成し、TServerStackHeadオブジェクトでこれら
のプロトコル層オブジェクトへのポインタのリストを保
持する。TServerStackHeadポインタはネットワーク・サ
ーバのグローバル・テーブルに格納され、インデックス
はクライアントにストリームアウトされる。TClientSta
ckHeadオブジェクトは、ServerStackHeadIDを格納し、
後続のすべての操作にそれを使用する。したがって、Se
rverStackHeadIDは、クライアントとサーバとの間で固
有のＩＤとして機能する。TBindOpなどの後続の要求
は、サーバによって受け取られると、TBindOpで渡され
るＩＤを使用して、対応するサーバ・スタック・ヘッド
の位置を特定する。

【０１８１】TClientStackHeadとTServerStackHeadは、
所与の端点についてクライアントとサーバとのやりとり
を管理する。これらのオブジェクトは、クライアント端
点のハンドルであるTAccessDefinitionオブジェクト
と、サーバ上の端点を表すTProtocolLayerオブジェクト
の対応スタックとの間をリンクする。また、ClientStac
kHeadとServerStackHeadの対は、クライアントとサーバ
をリンクする内部管理オブジェクトを構成する。

【０１８２】TClientStackHeadの重要な関数の一部を以
下に示す。

【０１８３】１．ProcessOperation： この関数は、TC
lientStackHeadがTNetworkOperationオブジェクトを処
理するために、TProtocolInterfaceまたはTAccessDefin
itionオブジェクトによって呼び出される。この関数
は、TNetworkOperationオブジェクトを平坦化し、シス
テムが提供するＲＰＣ／ＩＰＣ機構を使用して、平坦化
した操作オブジェクトをサーバに送る。また、この関数
は、送られた要求に対してサーバが応答したときにNetw
orkOperationオブジェクトも再構築する。基本的にこの
関数は、サーバとの間でNetworkOperationオブジェクト
を送受信するものである。

【０１８４】２．SaveServerInfo： このメソッドは、
ServerStackHeadIDをClientStackHeadに保管するために
呼び出されるものである。AccessDefinitionがインスタ
ンス化されると、サーバは端点用に作成されたServerSt
ackHead用のＩＤとともにTAccessOpオブジェクトを返
す。その後、サーバに対して要求が送られるときは、必
ずNetworkOperationがこのＩＤを使用する。

【０１８５】３．CancelRequests： この関数は、クラ
イアント・アプリケーションによってTProtocolInterfa
ce::CancelRequestsが呼び出されたとき、またはクライ
アント・アプリケーションが異常終了したときに呼び出
されるものである。ClientStackHeadは、必要な終結処
置を行うようServerStackHeadに通知するCancelRequest
sOp操作オブジェクトを作成する。

【０１８６】ServerStackHeadの重要な関数の一部を以
下に示す。

【０１８７】１．Classコンストラクタ： このコンス
トラクタは、TProtocolInterfaceオブジェクトのスタッ
クを受け取り、対応するTProtocolLayerオブジェクトを
構築する。これは、後続の要求からこれらの層オブジェ
クトを呼び出すためにこれらの層オブジェクトへのポイ
ンタを維持している。

【０１８８】２．ProcessOperation： この関数は、ク
ライアントからNetworkOperationオブジェクトを受け取
ったときにNetworkServerProcessによって呼び出される
ものである。この関数は、適切なProtocolLayerオブジ
ェクトの位置を特定した後、TNetworkOperationオブジ
ェクト上でExecute()メソッドを呼び出す。次にExecute
()メソッドは、ProtocolLayerオブジェクト上で必要な
メソッドを呼び出す。

【０１８９】３．GetProtocolLayer： この関数は、イ
ンデックスが付けられたTProtocolLayerオブジェクトへ
のポインタを返すものである。このインデックスはクラ
イアント・アプリケーションによって渡される。

【０１９０】４．CancelRequests： この関数は、プロ
トコル・スタック上のすべての保留要求を取り消すため
にTCancelRequestsOpを受け取ったときに呼び出される
ものである。これは、TClientStackHeadのCancelReques
tsに対応するサーバ側の関数である。

【０１９１】図２２は、上記のオブジェクトのクラス階
層を示し、Ｂｏｏｃｈの表記法を使用してオブジェクト
・モデルを記述している。TAccessDefinition１０１
は、TNetworkDefinition１００から派生したものであ
る。TAccessDefinition１０１は、端点を構成する様々
なTProtocolInterface１３５オブジェクトを含んでい
る。また、TAccessDefinition１０１は、クライアント
サーバ通信のプリミティブ機能のすべてを実行するTCli
entStackHead７２１も含んでいる。TServerStackHead７
２３は、ClientStackHeadに対応するサーバ側のクラス
である。TClientStackHeadとTServerStackHeadの対は、
プロトコル・インタフェースとプロトコル・インプリメ
ンテーション層オブジェクトとのリンクを表し、したが
って、クライアント・アプリケーションとサーバ上のプ
ロトコル・スタックとをリンクする。TProtocolInterfa
ceクラス１３５とTProtocolLayerクラス１５１はともに
共通基本クラスであるMProtocolService１３３から派生
したものである。クライアントからのネットワーク要求
はいずれもTNetworkOperation７０１オブジェクトで折
り返されるサーバに送られる。すなわち、TProtocolInt
erface内のメソッドが適切なTNetworkOperationオブジ
ェクトを作成し、操作オブジェクトはTClientStackHead
によって平坦化され、サーバに送られる。TNetworkOper
ationオブジェクトは、TClientStackHeadとTServerStac
kHeadの両方を使用する。

【０１９２】図２３は、クライアントからサーバへの要
求とその逆の要求の流れを示している。前述のように、
端点は、クライアント上のTAccessDefinitionオブジェ
クトと、サーバ上のTProtocolLayerオブジェクトのスタ
ックによって表される。クライアントとサーバとのやり
とりは、TClientStackHeadオブジェクトとTServerStack
Headオブジェクトによって管理される。同図は２つの端
点７２５を示している。クライアントからのネットワー
ク要求は、システムのＲＰＣまたはＩＰＣ機構を使用し
てTNetworkOperationオブジェクトとしてServerProcess
/Thread７２７に送られる。ServerProcessは、TNetwork
Operationオブジェクトを再構築し、次に端点１を表すT
ServerStackHeadオブジェクトの位置を特定し、ServerS
tackHead1７２９に要求を経路指定する。サーバ上のこ
の端点を表すServerStackHead2へ端点２から要求を経路
指定する場合も同様の処理が行われる。次に、ServerSt
ack1はTNetworkOperation::Execute()メソッドを呼び出
し、これがスタック１ ７３３のTTransportLayerの適
切なメソッドを呼び出す。TTransportLayerは、要求をT
FamilyLayer７３７に送るTNetworkLayerのメソッドの呼
出しを選ぶこともできる。次にファミリー層は、スタッ
ク１ ７３３のTDataLinkLayerに要求を送る。TTranspo
rtLayerは、要求をTFamilyLayer７３７に送るTNetworkL
ayerのメソッドの呼出しを選ぶこともできる。次にファ
ミリー層は、要求の処理後、アダプタに要求を送ること
ができるTDataLinkLayer７３９に要求を送る。DataLink
Layerは、アダプタを介して何らかのパケットを受信す
ると、そのパケットをファミリー層にディスパッチす
る。TFamilyLayerは、そのパケットを適切なスタックに
経路指定する。呼出しからTTransportLayerに戻ると、T
NetworkOperation::Execute()は応答を収集し、システ
ムのＲＰＣ／ＩＰＣ機構を使用して適切なTClientStack
HeadにTNetworkOperationオブジェクトを戻す。この手
続きは、サーバ上の端点を表す端点２とスタック２ ７
３５上のいかなる要求についても同じである。

【０１９３】図２３は、クライアントとサーバのクラス
・オブジェクト間の関係を示している。以下の例では、
一般的なネットワークのクライアント／サーバ・モデル
を想定している。

【０１９４】３．例 ＴＣＰ／ＩＰトランスポート・インタフェースを表すTT
CPTINFについて検討する。TTCPTINF::Bind()が入力パラ
メータとしてTTCPAddressを取り、TTCPAddressオブジェ
クトを返すものと想定する。ただし、TTCPAddressはTPr
otocolAddressから派生したものであることに留意され
たい。図２４に示すように、TTCPTINF::Bind()メソッド
は以下のように実行する。

【０１９５】ステップ８０１では、TNetworkOperation
オブジェクトであるTTCPBindOpが作成される。

【０１９６】ステップ８０３では、このAccessDefiniti
on用のClientStackHeadオブジェクトを獲得する。

【０１９７】ステップ８０５では、TTCPBindOpオブジェ
クトのTTCPAddressを平坦化し、要求をサーバに送るた
めに、ClientStackHead::ProcessOperation()が呼び出
される。サーバは、ステップ８０７でＲＰＣ／ＩＰＣな
どのメッセージ・ストリームから平坦化したTTCPBindOp
を再構築する。

【０１９８】ステップ８０９では、サーバは、TTCPBind
Opオブジェクトで渡されたスタックＩＤからServerStac
kHeadオブジェクトの位置を特定する。

【０１９９】ステップ８１１では、ServerStackHeadオ
ブジェクトが適切なプロトコル層オブジェクトにTProto
colLayer::Bind()を呼び出す。

【０２００】ステップ８１３では、バインドするための
呼出しがTTCPAddressオブジェクトを返し、サーバがTTC
PBindOpで復帰情報（アドレス）を復元し、それをクラ
イアントにストリームで戻す。ClientStackHeadはメッ
セージ・ストリームからTTCPBindOp()オブジェクトを再
構築する。最後に、ステップ８１７では、TTCPINF::Bin
d()がTTCPBindOpからTTCPAddressを取り出し、それをク
ライアント・プログラムに返す。

【０２０１】特定の実施例に関連して本発明を示し説明
してきたが、当業者であれば、修正を加え他の環境で本
発明を実施できることを理解できるだろう。たとえば、
上記の本発明はソフトウェアによって選択的に再構成ま
たは活動化される汎用コンピュータで都合よく実施する
ことができるが、当業者は、上記の発明を実行するため
に特別に設計された専用装置を含む、ハードウェア、フ
ァームウェア、またはソフトウェアとファームウェアと
ハードウェアの組合せで本発明を実施できることに留意
されたい。したがって、特許請求の範囲に記載する本発
明の精神および範囲を逸脱せずに、形式および細部の変
更を行うことができる。

【０２０２】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０２０３】（１）サーバ・システム内の実行ユニット
の、クライアント・プロセスとサーバ・プロセスとの間
の通信プロセス専用のプールを動的に管理するための方
法において、通信プロセス・プール内に、典型的なクラ
イアント・ロードをサポートするのに必要な数である最
小数、およびサーバ・システムにとって過負荷にならず
にピーク・クライアント・ロードをサポートするための
上限である最大数の実行ユニットを割り振るステップ
と、クライアントによるサービス要求をサーバ・システ
ムが受信するステップとを含み、受信した各クライアン
ト要求ごとに、受信したクライアント要求に実行ユニッ
トを割り当てると、通信プロセス・プール内の現行数の
実行ユニットが最大数の実行ユニットを上回ることにな
るかどうかを判定し、上回る場合にクライアント要求を
拒否するステップと、受信したクライアント要求に実行
ユニットを割り当てると、その要求を行うクライアント
・タスクに割り当てられた現行数の実行ユニットがクラ
イアント・タスク用の割り当てられた実行ユニットの数
を上回ることになるかどうかを判定し、上回る場合にク
ライアント要求を拒否するステップと、判定ステップが
否定であればクライアント要求を許可し、その結果、通
信プロセス・プール内の実行ユニットがクライアント要
求に割り当てられるステップとを含むことを特徴とする
方法。 （２）サーバ・システム内の実行ユニットの、クライア
ント・プロセスとサーバ・プロセスとの間の通信プロセ
ス専用のプールを動的に管理するためのシステムにおい
て、通信プロセス・プール内に、典型的なクライアント
・ロードをサポートするのに必要な数である最小数、お
よびサーバ・システムにとって過負荷にならずにピーク
・クライアント・ロードをサポートするための上限であ
る最大数の実行ユニットを割り振る手段と、クライアン
トによるサービス要求をサーバ・システムが受信する手
段と、受信したクライアント要求に実行ユニットを割り
当てると、通信プロセス・プール内の現行数の実行ユニ
ットが最大数の実行ユニットを上回ることになるかどう
かを判定する手段と、受信したクライアント要求に実行
ユニットを割り当てると、その要求を行うクライアント
・タスクに割り当てられた現行数の実行ユニットがクラ
イアント・タスク用の割り当てられた実行ユニットの数
を上回ることになるかどうかを判定する手段と、通信プ
ロセス・プール内の実行ユニットをクライアント要求に
割り当てることができると判定手段が確認した場合にク
ライアント要求を許可する手段とを含むことを特徴とす
るシステム。 （３）サーバ・システム内の実行ユニットの、クライア
ント・プロセスとサーバ・プロセスとの間の通信プロセ
ス専用のプールを動的に管理するためのコンピュータが
読取り可能な媒体上のコンピュータ・プログラム製品に
おいて、通信プロセス・プール内に、典型的なクライア
ント・ロードをサポートするのに必要な数である最小
数、およびサーバ・システムにとって過負荷にならずに
ピーク・クライアント・ロードをサポートするための上
限である最大数の実行ユニットを割り振るようにシステ
ムに指示する手段と、クライアントによるサービス要求
をサーバ・システムが受信するようにシステムに指示す
る手段と、受信したクライアント要求に実行ユニットを
割り当てると、通信プロセス・プール内の現行数の実行
ユニットが最大数の実行ユニットを上回ることになるか
どうかを判定するようにシステムに指示する手段と、受
信したクライアント要求に実行ユニットを割り当てる
と、その要求を行うクライアント・タスクに割り当てら
れた現行数の実行ユニットがクライアント・タスク用の
割り当てられた実行ユニットの数を上回ることになるか
どうかを判定するようにシステムに指示する手段と、通
信プロセス・プール内の実行ユニットをクライアント要
求に割り当てることができるという判定に応答してクラ
イアント要求を許可するようにシステムに指示する手段
とを含むことを特徴とするコンピュータ・プログラム製
品。

【図面の簡単な説明】

【図１】本発明の教示により構成されたコンピュータ・
システムを示す図である。

【図２】ネットワーク定義オブジェクト用のクラス階層
を示す図である。

【図３】ネットワーク・アドレス・クラス用のクラス階
層を示す図である。

【図４】プロトコル・インタフェース・クラス用のクラ
ス階層を示す図である。

【図５】プロトコル層クラス用のクラス階層を示す図で
ある。

【図６】接続指向遷移の状態図である。

【図７】無接続状態遷移の状態図である。

【図８】本発明のＴＣＰ／ＩＰ実施例のクラス関係を示
す図である。

【図９】本発明によりネットワーク接続をセットアップ
するためのプロセスの流れ図である。

【図１０】図９に示すネットワーク接続プロセスの専用
ネットワーク層にある様々なオブジェクトの体系図であ
る。

【図１１】ネットワーク事象オブジェクト用のクラス階
層を示す図である。

【図１２】単一の通信端点から事象を収集するためのプ
ロセスの流れ図である。

【図１３】複数の通信端点から事象を収集するためのプ
ロセスの流れ図である。

【図１４】ネットワーク・プロトコル・サーバのクライ
アント要求を処理するために通信スレッドのプールを管
理するための第１および第２の実施例の体系図である。

【図１５】ネットワーク・プロトコル・サーバのクライ
アント要求を処理するために通信スレッドのプールを管
理するための第１および第２の実施例の体系図である。

【図１６】通信スレッドのプール用の管理プロセスの流
れ図である。

【図１７】通信スレッドのプール用の管理プロセスの流
れ図である。

【図１８】通信スレッドのプール用の管理プロセスの流
れ図である。

【図１９】通信スレッドのプール用の管理プロセスの流
れ図である。

【図２０】ネットワーク操作オブジェクト用のクラス階
層図である。

【図２１】ネットワーク操作オブジェクト用のクラス階
層図である。

【図２２】本発明の様々なクラス間のクラス関係を示す
図である。

【図２３】本発明によるネットワーク内の様々なオブジ
ェクト間のメッセージの流れを示す図である。

【図２４】ネットワーク操作オブジェクトでネットワー
ク・プロトコル要求を渡すための流れ図である。

【符号の説明】

１１ システム・ユニット １２ キーボード １３ マウス １４ グラフィック・ディスプレイ １５Ａ スピーカ １５Ｂ スピーカ ２１ システム・バス ２２ マイクロプロセッサ ２３ ＲＯＭ ２４ ＲＡＭ ２５ メモリ管理チップ ２６ ハード・ディスク・ドライブ ２７ フロッピー・ディスク・ドライブ ２８ キーボード制御装置 ２９ マウス制御装置 ３０ ビデオ制御装置 ３１ オーディオ制御装置 ３２ ＣＤ−ＲＯＭ ３３ ディジタル信号プロセッサ ４０ 入出力制御装置 ４６ ネットワーク ４８ オペレーティング・システム ４９ クライアント・アプリケーション ５０ クライアント・インタフェース ５１ プロトコル・オブジェクト ５２ サーバ・アプリケーション

───────────────────────────────────────────────────── フロントページの続き (72)発明者 レオ・ユエ・タク・ユング アメリカ合衆国78759 テキサス州オー スチン ディーケイ・ラーンチ・ロード 11714 (56)参考文献 特開 平６−332833（ＪＰ，Ａ) 特開 平８−44576（ＪＰ，Ａ) 特開 平７−160648（ＪＰ，Ａ) 特開 平６−332834（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/46 G06F 15/16 G06F 13/00 351 - 357 G06F 15/00 310 - 330 G06F 1/00 370 ＣＳＤＢ（日本国特許庁)

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】サーバ・システム内の実行ユニットの、ク
   ライアント・プロセスとサーバ・プロセスとの間の通信
   プロセス専用のプールを動的に管理するための方法にお
   いて、 典型的なクライアント・ロードをサポートするのに必要
   な数である最小数を通信プロセス・プール内に設定する
   ステップと、 サーバ・システムにとって過負荷にならずにピーク・ク
   ライアント・ロードをサポートするための上限である実
   行ユニットの最大数を通信プロセス・プール内に設定す
   るステップと、 それぞれのクライアントに割当てることの出来る実行ユ
   ニットの最大割当数を通信プロセス・プール内に設定す
   るステップと、 クライアントによるサービス要求をサーバ・システムに
   より受信するステップと、 通信プール内の未使用の実行ユニットの数が所定の数よ
   り少ないかどうかを判定し、未使用の実行ユニットの数
   が所定の数より少ないならば、未使用の実行ユニットの
   追加により実行ユニットの現行数が実行ユニットの最大
   数を超過しない限り、通信プール内に未使用の実行ユニ
   ットを追加するステップと、 を含み、 受信した各クライアント要求ごとに、 受信したクライアント要求に実行ユニットを割り当てる
   と、通信プロセス・プール内の実行ユニットの現行数が
   実行ユニットの最大数を上回ることになるかどうかを判
   定し、上回る場合にクライアント要求を拒否するステッ
   プと、 受信したクライアント要求に実行ユニットを割り当てる
   と、その要求を行うクライアントに割り当てられた実行
   ユニットの現行数がクライアント用の実行ユニットの最
   大割当数を上回ることになるかどうかを判定し、上回る
   場合にクライアント要求を拒否し、判定ステップが否定
   であればクライアント要求を許可し、その結果、通信プ
   ロセス・プール内の実行ユニットがクライアント要求に
   割り当てられるようにするステップと、 を含むことを特徴とする方法。
2. 【請求項２】サーバ・システム内の実行ユニットの、ク
   ライアント・プロセスとサーバ・プロセスとの間の通信
   プロセス専用のプールを動的に管理するための方法にお
   いて、 典型的なクライアント・ロードをサポートするのに必要
   な数である最小数を通信プロセス・プール内に設定する
   ステップと、 サーバ・システムにとって過負荷にならずにピーク・ク
   ライアント・ロードをサポートするための上限である実
   行ユニットの最大数を通信プロセス・プール内に設定す
   るステップと、 それぞれのクライアントに割当てることの出来る実行ユ
   ニットの最大割当数を通信プロセス・プール内に設定す
   るステップと、 クライアントによるサービス要求をサーバ・システムに
   より受信するステップと、 通信プール内の未使用の実行ユニットの数が所定の数よ
   り多いかどうかを判定し、未使用の実行ユニットの数が
   所定の数より多いならば、通信プール内に未使用の実行
   ユニットを減じるステップと、 を含み、 受信した各クライアント要求ごとに、 受信したクライアント要求に実行ユニットを割り当てる
   と、通信プロセス・プール内の実行ユニットの現行数が
   実行ユニットの最大数を上回ることになるかどうかを判
   定し、上回る場合にクライアント要求を拒否するステッ
   プと、 受信したクライアント要求に実行ユニットを割り当てる
   と、その要求を行うクライアントに割り当てられた実行
   ユニットの現行数がクライアント用の実行ユニットの最
   大割当数を上回ることになるかどうかを判定し、上回る
   場合にクライアント要求を拒否し、判定ステップが否定
   であればクライアント要求を許可し、その結果、通信プ
   ロセス・プール内の実行ユニットがクライアント要求に
   割り当てられるようにするステップと、 を含むことを特徴とする方法。