JP4245296B2 - サーバ用フェデレイテッドオペレーティングシステム - Google Patents
サーバ用フェデレイテッドオペレーティングシステム Download PDFInfo
- Publication number
- JP4245296B2 JP4245296B2 JP2001545964A JP2001545964A JP4245296B2 JP 4245296 B2 JP4245296 B2 JP 4245296B2 JP 2001545964 A JP2001545964 A JP 2001545964A JP 2001545964 A JP2001545964 A JP 2001545964A JP 4245296 B2 JP4245296 B2 JP 4245296B2
- Authority
- JP
- Japan
- Prior art keywords
- operating system
- server
- class
- cpu
- responder
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Communication Control (AREA)
- Curing Cements, Concrete, And Artificial Stone (AREA)
- Polymers With Sulfur, Phosphorus Or Metals In The Main Chain (AREA)
- Glass Compositions (AREA)
Description
【０００１】
発明の背景
１． 発明の分野
本発明は、ディジタルコンピュータシステム用の分散型オペレーティングシステムに関連するものである。より具体的には、本発明は、複数のオペレーティングシステムを実行する複数のプロセッサに、サーバの状態マシーンの機能が分散している、高速サーバに関するものである。
【０００２】
２． 関連技術の説明
ワールドワイドウェブが世界のインターネットで爆発的に使われるようになったことから、より高速、より高度の信頼性を持って、大きなウェブサイトのホストとなる能力のあるサーバの必要性が、相応に生じた。例えば音声、データ、ビデオなどあらゆる形のディジタルコンテンツを、ギガビットのデータ速度（すぐテラビットのデータ速度になる）でグローバルに運ぶ光ファイバケーブルと高速のスイッチとルータを、インターネットは使っている。インターネットでは、1台のサーバがサポートしなければならない最大ユーザ数の予測が不可能で、範囲が広く、一握りのユーザから何百万のユーザに及び得、最大ユーザ数が比較的少ないローカルエリアネットワーク（LANS）と対照的である。したがい、多数のユーザをサポートでき、テラビットのデータ速度で動作できるインターネット用サーバの需要がある。
【０００３】
大型のウェブサイトを運用するための一般的な方法は、サーバファームを構築することである。サーバファームを構築することは、単一のより強力なシステムを近似するための、各種のネットワーク構成内容を持つ多数の（多分何百かの）サーバを相互接続することになる。サーバファームには専用の冷却設備および電源設備のある広いスペースが必要であるため、サーバファームを構築するのは、一般的には多額の費用が必要な仕事である。その上、サーバファームには普通保守要員が必要である。一般的に、サーバファームは複雑であり、ダウンタイムが多すぎて信頼できないのが普通である。サーバファームのもう一つの欠点は、大型でさらに大きくなるウェブサイトには、よく必要になる強力さと規模伸縮能力がない点である。
【０００４】
対称型多元処理（SMP）サーバが、サーバファームに代わる既知のものである。しかし、SMPの規模伸縮能力に限界があるため、大規模ウェブサイトの必要には普通適合しない。SMPサーバとサーバファームは、ストレスが多く急成長のウェブ環境を取り扱えないことが多い。たとえば、ｅコマースに必要なセキュリティ付きのトランザクションが、ＳＭＰサーバやサーバファームを、しばしば停滞させることが知られている。
【０００５】
インターネットにまたがるなど、長距離間のネットワークを形成しているコンピュータでは、クライアントとサーバ間の地理的な距離のために、反応時間が延びることが頻繁にある。クライアントの要求に応えるのに、サーバが要する時間を短縮するために、クライアントにより近い一個所または複数個所でウェブサーバを重複させることがある。たとえば、日本のクライアントがシアトルにあるｅコマースウェブサイトのホストになっているサーバに接続しようとしたとき、ワシントン州シアトルにある主サーバでなく、東京にある副サーバに接続されてもよい。これによって、データの所在がユーザにより近くなる。しかし、重複するサーバが提供するデータ間の同一性を維持するのは難しく、とくにコンテンツの作成が動的な場合、そうである。たとえば、ある顧客があるウェブサーバのオンライン注文機能を使い、その後副サーバで注文の状況をチェックしようとしたとき、正確な情報を得るとはかぎらない。副サーバを使うとき、広告の目的で、あるウェブサイトへのヒット数を正確に追うことも困難である。
【０００６】
インターネットサーバの先行技術では、TCP/IＰの状態ダイアグラム全体を、一つのマシーンが履行する（実行する）ことが多く、その結果動作が遅くなることがしばしばある。機能をクラスタ化ソフトウェアで分散したシステムでは、分散させた機能は、オペレーティングシステム、たとえばLinuxやWindows NT、の上のレイヤにされるのが普通であり、一般的には同一の機能を果たす。したがい、計算はアプリケーションレベルで分散され、しばしば反応時間その他の難点を生じる。
【０００７】
したがって、速度、セキュリティ、信頼性、規模伸縮能力、容量、低原価の点でより優れ、設置面積、電力と冷却の必要度もより低減され、保守と運用費用も低減されたサーバの需要がある。
【０００８】
本発明の各態様は、Federated Operating System（ＴＭ）（Federated OS（ＴＭ））と呼ぶ分散型、大容量、高速のオペレーティングシステムを使用するためのサーバ、方法、ソフトウェアに関係する。（「Federated Operating System（ＴＭ）」と「Federated OS （ＴＭ）」はThunder River Technologies, Inc.の商標である。（以下、「フェデレイテッドオペレーティングシステム」及び「フェデレイテッドＯＳ」と訳す。））
【０００９】
本発明の一つの実施例は、メンバクラスに分類した複数のメンバで作成する、ウェブサーバに関するものである。メンバの種類（クラス）各個には、その機能のために最適化した独特専用のオペレーティングシステムがある。オペレーティングシステムの各クラスは独特のものであるものの、ほとんどのメンバクラスというかすべてのメンバクラスには、共通の親クラスから継承した共通の特性がある。メンバすべてのオペレーティングシステムが合わさって、フェデレイテッド オペレーティングシステムになる。一つの実施例では、少なくとも一つの受信（レシーバ）メンバ、少なくとも一つの発信（ディスパッチャ）メンバ、少なくとも一つの応答（レスポンダ）メンバがある。各メンバには、メンバ間の通信に使う内部ネットワークに結合するための、内部ネットワークインターフェースがある。内部ネットワークは、例えば一つのバックプレーン、一つのクロスバスイッチ、一つのLAN、一つのWANまたは一つの無線リンク（衛星リンクを含めてもよい）を使って作成できる。レシーバメンバとレスポンダメンバには、インターネットのような外部ネットワークに結合するための、外部ネットワークインターフェースもある。外部ネットワークも、たとえばLAN，ＷＡＮまたは無線ネットワーク（衛星リンクを含んでもよい）でよい。
【００１０】
レシーバメンバは外部ネットワークを通じて、クライアントから要求を受信し、内部ネットワークを通じてディスパッチャメンバに、要求のデータを流す。特定の接続に使われるディスパッチャメンバは、内部ネットワークを使って、情報をレスポンダメンバに送り、クライアントから要求のあったデータを、外部ネットワークを通じてクライアントに送るよう指示する。
【００１１】
メンバは、少なくとも一つのCPU、RAM、ROM、一つの内部ネットワークインターフェース、一つの外部ネットワークインターフェースを含むことが望ましい、メンバハードウェアユニットで作成することが望ましい。（別の方法として、メンバは一つのユニプロセッサまたはSMP（対称型多元処理）システム上の、別々の処理またはスレッドとして、作成することが出来る。）負荷の平均化または故障したメンバハードウェアユニットの交換のために、サーバの運転中にメンバハードウェアユニットの構成替えができるように、メンバハードウェアユニットは、どのメンバクラスとしても動作するような、構成変更が可能であることが望ましい。
【００１２】
本発明の望ましい実施例では、エントリが多数あるデータベースを検索するときでも、一定時間内に実行するアドレス、ポート、ホストの探索アルゴリズムを使う。例えば、HTTP（ハイパーテキストトランスファープロトコル）では、IP（インターネットプロトコル）アドレスとTCP（伝送制御プロトコル）ポート番号が入った大型データベースも、ホスト名が入った大型データベースも、一定時間内に検索できる。これによって、多数の接続を同時に扱っている間でも、サーバはリアルタイムで動作できる。
【００１３】
同じ外筐内に異なるメンバを設置することも、メンバを短距離または長距離はなして分けることもできる。例えば、レシーバメンバとディスパッチャメンバをワシントン州シアトルに設置し、日本のクライアントに早く応答するよう、同じサーバのレスポンダメンバを日本の東京に設置することもできる。
【００１４】
本発明は、速度、容量、信頼性、規模伸縮性、性能、安全性、管理の容易さの各面での改善という、多くの有利さをユーザに提供する。フェデレイテッド OSを使用したサーバは、暗号化・復号化（例えばｅコマースに使うシキュアソケットレイヤ（SSL）トランザクション）を含む、極度に大量のウェブトラフィックを扱えるように、性能劣化なしに大規模化できる。さらに、フェデレイテッド OSを実施したサーバは、特別の電力と冷却設備を必要とせず、小型の外筐に収納でき、簡単な訓練を受けた技能者一名が操作卓を使って、管理および構成を行うことが出来る。本発明は、以下の説明から明白な、他の有利さと有益性も提供する。
【００１５】
望ましい実施の詳細説明
定義：
分散： 機能が多数のサブシステム内に分割されているというシステムの特長であり、サブシステムの各個が機能の一部を実施し、理想的には同時に動作することによって、与えられた仕事を全体としてより早く完了できる。
【００１６】
リアルタイム： 与えられた仕事を完了するのに、既知の、一定時間以上にはかからないという、システムの特長
サーバ： データの提供および(または)データの受信および(または)データの処理を行うコンピュータシステム
クライアント： サーバに要求とデータを送り、要求に応えるデータを受信する装置。クライアントは、クライアントの要求に応えて送られたのではないサーバからのデータを、受信することも出来る。
【００１７】
VME： モトロラが開発し、VMEbusの当初仕様（IEEE-1014-1987）およびVME64（ANSI/VITA1-1994）、VME64x、VME320など、その後の改訂版に定義されている、コンピュータアーキテクチャ「VERSAmodule Eurocard」を指す。
【００１８】
本書でいう「望ましい」および「望ましくは」とは、要件ではないが、含めることが望ましい要素、行動、構造、材料または特性をいう。
【００１９】
本書で使う「例えば」という用語は、例として明記された要素、行動、構造、材料または特性は要件ではなく、別の要素、行動、構造、材料または特性を使用、実行または包含できることをいう。
【００２０】
本発明のいくつかの態様の概要
本発明は以下の態様を含むが、これらに限らない。本発明の一つの態様としては、フェデレイテッド オペレーティングシステム（ＴＭ）を使ったディジタルコンピュータシステムの作成がある。本発明の他の態様としては、フェデレイテッド オペレーティングシステム（ＴＭ）を使ったサーバの作成がある。本発明の他の態様として、分散型TCP/IP状態マシーンを使ったサーバの作成がある。本発明の他の態様は外部ネットワークを通じて受信した要求に応える方法である。本発明の他の態様は（外部ネットワークを通じて受信する必要がない）要求に応える方法である。本発明の他の態様はサーバ（またはディジタルコンピュータシステム）を初期化する方法である。本発明の他の態様には、分散型サーバを作成するために、ディジタル処理装置が実行できる、機械語を実際に保持した信号保持媒体の作成がある。本発明の他の態様には、要求に応えるための方法を実行するために、ディジタル処理装置が実行できる、機械語の命令で構成されたプログラムを実際に保持した信号保持媒体の作成がある。本発明のその他の態様も本書で説明している。
【００２１】
フェデレイテッド オペレーティングシステムの概要
フェデレイテッド オペレーティングシステム（OS）は、本発明の全体的なアーキテクチャである。フェデレイテッド オペレーティングシステムは、メンバクラスに分類される複数のメンバで作成された、分散型オペレーティングシステムである。各メンバは一つのメンバクラスの一インスタンスであり、一つのノードと呼ぶことができる。各メンバクラスには、その機能のために最適化された独特の専用オペレーティングシステム（オペレーティングシステムカーネルと呼ぶことができる）がある。メンバのオペレーティングシステムが合わさって、フェデレイテッドＯＳになる。フェデレイテッド OSのメンバは、サーバの機能を実行するために協調して動作する。このように、このシステムは多数のオペレーティングシステムを統合したものであり、したがってメンバの連邦と呼ぶことが出来る。各メンバはその機能を実行するため、単独で働くことも可能だが、フェデレイテッド OSのメンバは、サーバを具現化するために、協力して働くことが望ましい。
【００２２】
各メンバにより具現化される個別のオペレーティングシステムの特性は、その特定のメンバを作成するために使われる、個別のハードウェア、ファームウェアおよび(または)ソフトウェアの組合せで決まる。このように、メンバの固有性は、ハードウェア、ファームウェアおよび(または)ソフトウェアの相違による。要件ではないが望ましくは、（構成担当のコンフィギュレータメンバを除いて）全メンバが（オブジェクト指向の継承を使って）共通の親メンバから継承した共通の特性を持つことである。他のメンバクラスがそこから由来することが望ましい親（元）メンバクラスは、内部ネットワークを通じたメンバ間の同期通信のために必要な機能を持っており、イベントで駆動される処理ループも持っていることが望ましい。
【００２３】
メンバクラスには、例えば次のクラスがある： レシーバ、ディスパッチャ、レスポンダ、コンフィギュレータ（構成担当）、ガーディアン（保護担当）、パーシステントストーレジ（持続性記憶）、システムアドミニストレータノーティファイア（システム管理者通知担当）、デコーダ、ルーティングマネージャ、およびブータブルがあり、抽象的クラスとしてプロトクラスと外部ネットワークメンバクラスが加わる。（「レスポンダ」という用語には、静的レスポンダクラスと動的レスポンダクラスが含まれる。）その他のクラスも使うことができる。異なるクラスのメンバは異なる機能を実行する。フェデレイテッド OSを使うサーバには、少なくとも一つのレシーバメンバ、少なくとも一つのディスパッチャメンバ、少なくとも一つのレスポンダメンバがあるのが望ましい（さらに他のメンバクラスのメンバが一つ以上あるのが望ましい）。別の実施例では、ディスパッチャメンバが含まれず、ディスパッチャメンバの機能は、レシーバメンバおよび(または)レスポンダメンバで行われる（かまたは、別のメンバクラスのメンバで行ってもよい）。外部ネットワークに接続される実施例には、外部ネットワークに接続されるメンバが、少なくとも一つ含まれる（望ましくは、外部ネットワークに接続される少なくとも一つのレシーバと少なくとも一つのレスポンダが含まれる）。外部ネットワークに接続されない実施例では、レシーバメンバおよび(または)レスポンダメンバを含む必要がない。サーバ中のメンバの数とサーバ中のメンバのクラスは、サーバが提供するサービス、システムにかかる負荷、人による介入その他の要素で決まる。
【００２４】
各メンバには、オペレーティングシステムを含むハードウェアおよび(または)ソフトウェアの組み合わせがあり、オペレーティングシステムは他のクラスのメンバのオペレーティングシステムとは異なる。例えば、レシーバメンバの使うオペレーティングシステムは同じだが、ディスパッチャメンバは、レシーバオペレーティングシステムとは異なるディスパッチャオペレーティングシステムを使う。フェデレイテッド OSでは、各メンバクラスの独特の特性は、オペレーティングシステムのレベルに含まれる。このように、レシーバ、ディスパッチャ、レスポンダ、その他のクラスのオペレーティングシステムは、すべてそれぞれ異なる（すべてが共通の継承特性を持っていることが望ましいが）。これが先行技術と違う所で、先行技術では分散型コンピューティングはソフトウェアをクラスタ化し、基本的に同一のサービスを提供するオペレーティングシステムの上で動作することになることが多い。既存のメンバクラスから新しいメンバクラスをクラス分けできる。新しいメンバクラスは、親になったメンバクラスの全機能を持ち、新しい機能をいくつか持つことになるだろう。例えば、動的レスポンダを静的レスポンダからクラス分けできる。図９Ａの実施例に示すとおり、動的レスポンダは親の静的レスポンダの全機能を継承し、動的データの作成に関する追加的機能を加えている。要件ではないが、望ましくは、フェデレイテッド OSはＣ++プログラム言語で作成する。これによって、メンバのオペレーティングシステムの継承系統の作成が容易になる。
【００２５】
フェデレイテッド OSはTCP/IP（伝送制御プロトコル／インターネットプロトコル）の使用に限らず、たとえばNetware、VINES、AppleTalk、DECNET、SNA、OSI、ATM、netBIOS、IP-over-SONETのような任意の通信プロトコルの使用もできる。他の通信プロトコルも使えるだろう。また、フェデレイテッド OSはパケット使用の通信システムと、通信に専用回線を使う回線方式の通信システムの両方に使える。フェデレイテッド OSは、例えば着脱可能な媒体から受け取るデータを処理するシステムのように、外部ネットワークがないシステムでも、使うことができる。説明の都合上であり、これに限定する意図はないが、本書ではTCP/IPでのフェデレイテッド OSの実施を説明することが多い。
【００２６】
使用している通信プロトコルの状態ダイアグラム全体を、一つのマシーンが実行する先行技術と異なり、フェデレイテッド OSでは、タスクが複数のメンバにあるプロセッサに分散される。したがって、フェデレイテッド OSのTCP/IPへの実施例では、TCP/IPの状態マシーンは複数のメンバに分散される。言い換えると、TCP/IPのタスクは分割され、TCP/IPの状態ダイアグラム上の状態は異なるメンバに割り当てられる。したがって、単一のIPアドレスのサービスは（同じ外筐にも、別の外筐にも設置できる）複数のメンバのネットワークインターフェースに配分される。TCP/IP以外の通信プロトコルを使う実施例では、そのプロトコルの状態マシーンもメンバ間に配分される。このようにして、応答の作成と一つまたはそれ以上のクライアントへのデータ配送は、多数のメンバが並行して処理する。TCP/IPへの実施例では、多数のIPアドレスをサポートする能力を限定するのは、一般には、利用できるメモリの量だけである。このことから、何百万以上のIPアドレスをサポートする規模にすることができる。TCP/IPへの実施例では、サポートできるTCP/IPの同時接続数も、一般的には、利用できるメモリの量だけが制約原因になる。したがって、何百万以上のTCP/IP同時接続をサポートする規模にできる。このようにして、TCP/IPへの実施では、例えば同時に接続された何十万またはそれ以上のインターネットユーザに、大量のデータを届けることができる。
【００２７】
フェデレイテッド OSの場合、多数スレッドの分散型システムは、多数の（望ましくは）単一スレッドのメンバで実現される。フェデレイテッド OSのメンバの個々は、多数タスク処理を行わないのが普通である。（しかし、メンバの多数タスク処理は可能である。）各メンバは他のメンバと並行して働くので、フェデレイテッド OSは全体として並列処理を行う。例えば、TCP/IPへの実施例では、各メンバが特定部分のTCP/IPプロトコルを、他のメンバと並列して実行するので、フェデレイテッド OSがインターネットプロトコルの並列処理を実施する。したがって、インターネットの中核機能の処理が加速される。同様に、OSI（オープンシステムインター接続）への実施では、フェデレイテッド OSはオープンシステムインター接続（OSI）の７レイヤスタックの、異なるレイヤの並列処理を実施する。
【００２８】
フェデレイテッド OSを使ったサーバは、多くの高性能サービスに好適である。例えば、ｅコマース、ウェブのホスト、マルチメディア配信（オンデマンドのビデオとオーディオ）、特殊軍事計画、無線インフラ構造、インターネット使用のゲームなどの大規模なインターネット／イントラネット利用サービスの配備である。インターネットで使う以外に、フェデレイテッド OSは、他の方式のブロードバンド、パケット使用の公衆通信網に使うことができよう。
【００２９】
上記のように、各メンバが実現する個別のオペレーティングシステムの特性は、その特定のメンバを作成するのに使う、個別のハードウェア、ファームウェア（例えばROM）および(または)ソフトウェアの組合せによって決まる。フェデレイテッド OSのメンバは、それぞれのメンバのハードウェアユニット（ノードと呼ばれることがある）に組み込まれるが、それは色々な方法で実現できる。フェデレイテッド OSのいくつかの実施例では、各メンバ（インスタンス）は別々のハードウェアモジュールで実現される。このようにして、これらの実施例では各メンバのハードウェアユニットは、メンバハードウェアモジュールとして作成される。図1Aはメンバハードウェアモジュール105の実施例のブロック図である。メンバハードウェアモジュール105には、最低一つのCPU 110a （中央処理装置）、一つの内部ネットワークインターフェース 115、一つの外部ネットワークインターフェース 120、ランダムアクセスメモリ （RAM）125、フェデレイテッド OSカーネルの後続インスタンスをロードするのに使う、初期プログラムイメージを蓄積するための、少量の不揮発性メモリ（ROM）130を含む。メンバハードウェアユニットは、同じかまたは異なるCPU、同じかまたは異なる量のメモリ、同じかまたは異なる形式のネットワークインターフェースを使って、実現できる。メンバハードウェアユニット中の内部インターフェースと外部インターフェースは、どちらも双方向通信（データその他の信号を入出力する）用に構成されていることが望ましい。外部ネットワークとの通信に使われないメンバについては、外部ネットワークインターフェース120を設ける必要はないが、必要な場合各モジュールにレシーバかレスポンダのどちらにも機能する能力が備わるように、どのメンバハードウェアユニットも、外部ネットワークインターフェースを持つのが望ましい。内部ネットワークインターフェースは、内部ネットワークを通じてのメンバハードウェアユニット間の通信に使われ、外部ネットワークインターフェースは外部ネットワークを通じてのクライアントとの通信に使われる。希望する場合、外部ネットワークインターフェースは、ハードウェアの障害その他の障害の際、通信路を提供することによって、メンバハードウェアユニット間の内部通信にも使用できる。要件ではないが、性能を上げるために、メンバが通信をする相手のメンバにメッセージを送るのに使う、ネットワークルーティングの必要情報を、そのメンバが知っている形で、各メンバが内部ネットワークメッセージ情報を保持することが望ましい。
【００３０】
あるメンバハードウェアユニットに一つ以上のCPUがある場合、そのメンバハードウェアユニットのCPUは相互に接続されていることが望ましい。要件ではないが、各CPUがそのメンバハードウェアユニットの各ネットワークインターフェースに結合されており、RAMとROMが各CPUに結合されていることが望ましい。一つのメンバに、実際に結合できる数の任意の数のCPUを使うことができる。例えば、各メンバハードウェアユニットには、２つのCPU 110aと110bがある。
【００３１】
異種のCPUハードウェアをサポートするポータブルなソースコードを使って、フェデレイテッド OSを作成することが望ましく、そうすることで、異なるプロセッサや異なる販売業者から選択する自由が得られる。このポータブル性が、個別の機能についてメンバを最適化する助けになる。例えば、SSL（セキュアソケットレイヤ）その他のセキュリティプロトコルをサポートするために、DSP（ディジタル信号処理）に基づく暗号化／復号化エンジンを使って、メンバの作成を最適化できる。プロセッサの本来のバイト数、語の大きさなどに依存する部分は、プロセッサの種類毎に、最小限のコードモジュールにまとめることが望ましい。各CPUはどんな形式のディジタル処理装置でもよいが、各CPUは高速のディジタル処理装置であることが望ましい。あるモジュールに複数のCPUがある場合、モジュール内のCPUが同じメーカーまたは同じ機種である必要はない。CPU 110aがPowerPCで、CPU 110bがCPU 110aに使われたPowerPCと同じ、PowerPCであることが望ましい。別の方法として、CPUはテキサスインスツルメンツ製の高速ディジタル信号プロセッサ（DSP）x86プロセッサまたは（ディジタル処理装置と呼べる）どんな他のプロセッサでもよい。
【００３２】
フェデレイテッド OS中のプロセッサは、複数のプロセッサで出来た、一つの統合されたコンピュータシステムとして動作する。プロセッサの数は、２から３個から数百（またはそれ以上）になり得るが、プロセッサの数は、メンバの数とメンバを作成するに使われるプロセッサの数による。フェデレイテッド OSを使ったサーバに、プロセッサの能力を追加することは、先行技術であるUnixやNTを使ったサーバファームで一般に必要となる、大掛かりなLANとソフトウェアの構成なしに、システムにメンバハードウェアユニットを追加することによって、簡単にできる。
【００３３】
フェデレイテッド OSを一つの外筐に組み入れた独立型サーバの一例では、何列かのメンバハードウェアモジュールとそのためのバックプレーン、メンバハードウェアモジュールの列を相互接続するための一つのネットワーククロスバスイッチ、外部ネットワークインターフェースに結合したネットワークスイッチ、ネットワークスイッチ間の接続部、電力調節型DC電源、関連充電回路のある予備電池（希望ある場合）、およびデータメモリ部がある。メンバが物理的に分離されている実施例では、分割したメンバを収納している外筐は、短距離または長距離のネットワークリンクで相互に接続されており、これによって地理的に分散したシステムを実現できる。
【００３４】
サポートされるメンバハードウェアユニット（およびCPU）の数という点で、規模の伸縮ができるように、メンバハードウェアユニットの物理的なまとめ方と内部ネットワークの配置を、設計することが望ましい。例えば、図1Bで示す実施例では、メンバハードウェアモジュール105a、105bの電力消費は少なく、一列あたり普通１０から５０のモジュールである一定数のモジュールを、横並びに取り付け、いくつかの列を縦に本棚形式に積み重ねられるような形状になっている（形状比がある）。この実施例では、任意の列のモジュールは一枚のバックプレーン（例えばバックプレーン155と160）に差し込まれており、このバックプレーンは各モジュールの電源とネットワークインターフェースの接続をすべて行う。バックプレーンには一列のモジュール間のネットワーク構築に必要な相互接続部分もあり、一つ以上および追加される列との相互接続に使われる、一つ以上のネットワーク接続部165a、165bも準備している。各バックプレーンに使う相互接続部は、モジュールの多数の対が同時に通信できるような、広帯域、応答時間の短いクロスバ（「スイッチドファブリック」）であることが望ましい。多数のバックプレーンを使う実施例では、バックプレーン間のインターフェースは、モジュールを相互接続するのに使うのと同様の、スイッチドファブリックであることが望ましい。
【００３５】
メンバハードウェアユニット（およびバックプレーン）は、物理的に互いに近接させて配置しても、長距離へだてて結合させてもよい。例えば、メンバハードウェアユニットを同じ外筐に入れても、同じ建物内の別々の外筐に入れても、たとえば1キロメートル以上または何千キロメートルも離してもよい。バックプレーンを内部ネットワークの他のモジュールまたはバックプレーンに結合するリンクには、例えば約１センチから数十キロの長さの光ファイバケーブルを使え、地球の反対側まで延長することさえ可能である。いくつかのメンバハードウェアユニットを、他のメンバハードウェアユニットから遠くに配置する実施例は、セキュリティのかかったメッセージの暗号化と複合化を担当するメンバが、フェデレイテッド OSの他のモジュールから離れた、セキュリティ度の高い物理的外筐に配置されている場合である。フェデレイテッド OSは、小型の外筐内で多数（数百）のCPUを使って実施されるのが、望ましい。
【００３６】
図1Cに示す「ワンチップ上のシステム」と呼ばれる別の実施例では、一つのメンバハードウェアユニットのCPU、ネットワークインターフェース、RAM、ROMが単一の集積回路（IC）に集積されている。この実施例では、これらの要素を入れたIC 175a、175bと内部ネットワーク相互接続ハードウェアが一つの回路基板180に取り付けられている。この実施例では、回路基板を上記で説明したメンバハードウェアモジュールと同じ物理的形状にし、同じバックプレーンに差し込めるのが、望ましい。ワンチップのシステムでは、内部ネットワーク183が、基板上のCPUの全部を相互接続する。内部ネットワークインターフェース回路基板185と外部ネットワークインターフェース187回路基板は、基板の外での接続用に準備されている。この実施例の別の形では、一つ以上のICのそれぞれに、多数のメンバハードウェアユニット（CPU/ネットワークインターフェース/RAM/ROMの組合せ）があり、各ICの内部でそれらが相互に接続されており、またチップの外で、基板上の内部ネットワークおよび外部ネットワークとインターフェースしている。このように、単一のICの中に、多数のメンバハードウェアユニットが組み込まれている。また、多数のプロセッサモジュールと一つのネットワークスイッチを含む単一のチップ上に、複数のサブシステムを組み込める。
【００３７】
内部ネットワークと外部ネットワーク
上で説明したように、フェデレイテッド OSは複数のメンバを含む。図2で示すとおり、フェデレイテッド OS 205のメンバは、内部ネットワーク210を通じて、相互に通信するが、この内部ネットワークは例えばバックプレーン、クロスバスイッチネットワーク、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）または他の適切な形式の有線または無線のネットワークのどれでもよい。内部ネットワークは、広帯域で応答時間が短いのが望ましい。希望すれば、内部ネットワークを、たとえばバックプレーン内部に統合されている複数のネットワークで構成することもできる。内部ネットワークの実施例としては、VME64またはCompactPCIのようなバックプレーン、Race++、SCI（伸縮可能コヒーレントインタフェース）、Myrinetのようなクロスバスイッチネットワーク、特注専用のネットワークインターフェース、EthernetのようなLAN、SONETやATMのようなWANがある。WANにはどんな種類の高速伝送システムでも使える。内部ネットワークは、高性能のパケット通信と交換技術であるSCIで作成するのが望ましい。他の方法としては、ファイバチャネルとスカイチャネルがあり、メンバ間の通信を設定するどんな他の方法も可能性がある。内部ネットワークを、InfiniBandのような新規の相互接続標準と共に使うように、適応させることも可能だろう。各メンバの内部ネットワークインターフェース115（図１）は、内部ネットワークに結合されている。したがって、メンバのすべてが内部ネットワークに結合しており、内部ネットワークを通じて、互いに通信できる。フェデレイテッド OSを使ったサーバの別の実施例では、外部ネットワークへの接続がない。
【００３８】
例えば、着脱可能の媒体または物理的センサ、化学的センサ、光学的センサおよび(または)音響センサからデータを受け取る計算エンジンサーバは、外部ネットワークと結合する必要がない。最低一つのレシーバ225と一つのレスポンダ 220が、外部ネットワーク 215と結合しているのが望ましい。各メンバハードウェアモジュール105の内部ネットワークインターフェース115は、内部ネットワーク210に結合するためのものであり、各メンバハードウェアモジュール105の外部ネットワークインターフェース120は、外部ネットワーク215と結合するためのものである。上記のように、外部ネットワークと結合しないメンバが、外部ネットワークインターフェースを持つ必要はないが、全てのメンバが外部ネットワークインターフェースを持つことが望ましい。外部ネットワークと結合するメンバは、例えばEthernet接続部またはATMと結合できる。外部ネットワークは、任意の種類のLANおよび(または)WANでよく、任意の種類の有線または無線のネットワークでよい。フェデレイテッド OSは、インターネットのような大規模な外部ネットワークに向けて最適化してあるが、小規模のWANまたはLANとも使用できるだろう。
【００３９】
図2では、外部ネットワークに結合したメンバが、全部外部ネットワークの同じ場所に結合しているが、これは要件ではない。言い換えれば、外部ネットワークの異なる場所で、メンバを外部ネットワークに結合してもよい。また、一つまたはそれ以上のメンバの外部インターフェースを、インターネットのバックボーンへの直接接続によって、インターネットに結合してよく、これはそれぞれのネットワークインターフェースを、インターネットバックボーンの一つまたはそれ以上の主要プロバイダに、直接接続することによってできる。
【００４０】
リアルタイム、分散型及びオブジェクト志向
フェデレイテッド OSメンバ(望ましくは)は、夫々が既知の、制限された実行時間を有する固定数の割込みによってだけ、各メンバが(望ましくは)先取することができる単一タスクとして作動するが故に、リアルタイムである。フェデレイテッド OSは、サービス及びプロトコルアルゴリズム(望ましくは)がすべてリアルタイムで実行されるが故に、全体としては(望ましくは)リアルタイムである。例えば、TCP/IPの実施例において、レシーバメンバ処理は、望ましくはTCP/IP パケットをリアルタイムで受け取る。更なる事例として、TCP/IPの実施例において、IP アドレス探索及びホスト名探索は、望ましくはリアルタイムで達成される。
【００４１】
フェデレイテッド OSは、OSサービス(TCP/IPの実施例におけるTCP/IPプロトコルのように)が、メンバのOS(それは、内部ネットワーク上に結合される)中に分配され、かつ、フェデレイテッド OSが異なるメンバ間の分配機能性をサポートするが故に、分散される。
【００４２】
フェデレイテッド OSは、(望ましくは)オブジェクト志向である。その理由は、(1) メンバ(望ましくは)は、親クラスから引き出され、親クラスからの行動を受け継ぎ、そしてそのメンバは受け継いだものへと拡大する。また、(2) (望ましくは)、そのシステムはオブジェクト志向ツールで造られる、ためである。
【００４３】
リアルタイムアドレス探索及びホスト探索
TCP/IPの実施例において、HTTP(ハイパーテキスト伝送プロトコル)に対して、クライアントはIP アドレス、ポートナンバ及びホスト名を含んだ情報パケットを、そのクライアントがアクセスすることを望んでいるサーバによって準備されたサービスを定義するために、サーバに送る。同一のIPアドレスでサポートされる多数のホスト名をもつことが可能であり、逆に、単一のホスト名に符号する多数のIPアドレスをもつことも可能である。IPアドレスは、インターネットプロトコル(IP)に関連し、そのポートは、伝送制御プロトコル(TCP)に関連する、そして、ホスト名はハイパーテキスト伝送プロトコル(HTTP)に関連する。
【００４４】
一般的に、当該技術内で知られるサーバにおいて、OS及び/又はアプリケーションは、入ってくるメッセージ内のIPアドレス、TCPポート番号及びホスト名のような他のデータとの一致を検索しなければならない。入ってくるメッセージ内のIPアドレスとホスト名は、サーバにアクセス可能な夫々のデータベースに貯えられた(恐らく)膨大なIP アドレスと(恐らく)膨大なホスト名と比較される。典型的にOSのネットワーキングコードは、そのパケットが新しい接続に属するのか、又は既存の接続に属するのかを判定するために、また、データを送るべき適切なアプリケーションを判定するために、入ってくるパケットのIP アドレスとTCP ポート番号を処理する責任がある。メッセージ内の他のデータ(例えば、ホスト名)は、入ってくるパケットを処理するために、アプリケーション(例えば、HTTPウェブサーバ)によって探られる必要があるかも知れない。
【００４５】
フェデレイテッド OS(望ましくは)のTCP/IPの実施形態は、迅速にかつ決定論的に、多数のIPアドレス同士と多数のホスト名同士の一致を検索するために、その検索アルゴリズムで「トゥリー」（“Trie”）データ構造を用いる。トゥリーデータ構造を用いるアルゴリズムは、一般的に検索されるべきデータベースのサイズに拘らず同一量の検索時間を要する。このタイプのアルゴリズムは、各タイプの検索に対する検索時間が一定で、検索されるべきプールのサイズに依存しないので、決定性であるとして引用される。対照的に、先行技術のサーバは、検索されるべきプールのサイズが十分に小さい場合にだけ、決定性機能を近似するアルゴリズム(例えば、ハッシュテーブル)を典型的に用いる。このアプローチは、検索アルゴリズムによって必要とされるデータ構造を保存するために必要とされるメモリ量を最少化するために、先行技術で用いられ、限定数の同時進行セッションだけがサポートされる必要があるという仮定に基づいている。データベースに付加的アドレスが追加されると、先行技術検索法に必要とされる検索時間が一般的に増加し、その結果、先行技術システムは、一般的にリアルタイムで動作することができない。対照的に、可能ならどこでも、フェデレイテッド OSは、検索されるべきデータ構造の数によって影響されない実行時間を有するトゥリーデータ構造によるアルゴリズムを用いる。決定性検索アルゴリズムを使用する結果として、フェデレイテッド OSは、たくさんのセッションをサポートしている場合でも、それぞれの入ってくるパケットを処理するのに一定量の時間でよい。決定性アルゴリズムの使用は、フェデレイテッド OS がリアルタイムで動作することを許容する。何故なら、すべての検索が同一の固定量の短時間で完結するからであり、そして、固定量の時間がそのシステムがリアルタイムで動作することを許容するに十分に短いからである。TCP/IPの実施例において、フェデレイテッド OSは、リアルタイムTCP/IP状態マシーンを有するということができる。リアルタイム状態マシーンは、フェデレイテッド OSの非TCP/IPの実施例でもまた、実現され得る。決定性アルゴリズムの使用は、機能を著しく改善し、好ましいけれども、フェデレイテッド OSでの決定性検索アルゴリズムの使用は必要とされない。
【００４６】
好ましいTCP/IPの実施例において、フェデレイテッド OS は数百万の同時に起こるTCP/IP接続をサポートすることができ、かつ、少なくとも数千のIP アドレスの数百と、数千のホスト名の数百を機能劣化なしに、ホストすることができる。これは、デザインアプローチと用いられるアルゴリズムに依るものであり、いかに多くの他の有効接続が保持されていても、既知の量の時間で、入ってくるパケットを処理する能力の結果である。先行技術TCP/IPサーバは、これに反して、たくさんの接続を保持しようとしているとき、又は、たくさんのIP アドレスをサポートしようとしているとき、大部分のそれらの接続が使用されていないときにさえも、しばしば重要な機能劣化又は停止さえも経験する。
【００４７】
イベント/ネットワーク駆動
要求されないが、望ましくはフェデレイテッド OSは、イベント駆動/ネットワーク駆動である。言い換えれば、ネットワークプロトコル機能性は、アクティブであり、実行されるべきデータがあるときだけ、適切なサービスを実施する。(TCP/IPの実施例において、イベントは、ウェブページのハイパーリンクをユーザがクリックすることで生じるTCP/IPパケットの受信である)。対照的に、従来のサーバにおいては、データが有効になるまで、そのアプリケーションがネットワーク及びブロックからデータを読み込むように、アプリケーションがプロトコルスタックを駆動する。
【００４８】
多数の外部ネットワーク
要求されないが、フェデレイテッド OSは、一つ以上の外部ネットワークに結合されることができる。例えば、フェデレイテッド OSを実行するレシーバとサーバのレスポンダは、第一の外部ネットワークに結合されることができ、そして、他のレシーバとサーバのレスポンダは、他の外部ネットワークに結合されることができる。一つ以上の外部ネットワークに結合されるフェデレイテッド OSを実行するサーバは、異なる外部ネットワーク間のデータ伝送を防ぐために配列されることができる、又は、任意の二つの外部ネットワーク間に任意のデータを通すためのルーティング機能を実行するために、 若しくは、ファイアウォールを実行するために、二つの外部ネットワーク間にデータを選択的に通すことによって、配列されることができる。ルーティングは、ルーティングマネージャメンバ(例えば、図9A に示すようにルーティングマネージャメンバ920)で実行されることができる。同様に、ファイアウォールマネージャメンバ(例えば、図9Aに示されるファイアウォールマネージャメンバ928)は、ある外部ネットワークから他の外部ネットワークへ許容されたデータを選択的に通すのに用いられることができる。
【００４９】
防護の特徴
フェデレイテッド OS防護を増強する幾つかの特徴を有している。例えば、クライアントは外部ネットワークに接続されるが、内部ネットワークには接続されない、そして外部ネットワークは、クライアントへの及びクライアントからのデータを伝送するためにだけ用いられる。"サービス拒否"攻撃は、入ってくるパケットをネットワーク速度で処理するメンバの能力によって緩和される(望ましい実施例において)。望ましくは、すべてのクライアントデータは、安全なコンテナオブジェクトを経由して通され、かつ、境界線チェックが強制され、それによってバッファオーバフロー攻撃を緩和する。また、暗号化/復号化が、物理的に安全な場所に地理的に分離されたメンバに委任されることができる。ファイアウォール保護は、例えば、多数の外部ネットワークに結合されるシステムの防護を装備するために、容易に実現されることができる。
【００５０】
メンバクラス
上に述べたように、各メンバクラスは、特定の機能のために最適化された明確な専用のOSを有している。例えば、各レシーバメンバはレシーバOSを有し、各ディスパッチャメンバはディスパッチャOSを有し、各レスポンダメンバはレスポンダOSを有している。異なるメンバクラスは、プロトクラスとして引用される親クラスの異なる一意なサブクラスである。例外は、コンフィギュレータクラスであり、それは、プロトクラスのサブクラスであっても、そうでなくてもよい。メンバクラスの事例は、レシーバ225、ディスパッチャ230、レスポンダ220、コンフィギュレータ235、ガーディアン240、持続性ストレージ245、システムアドミニストレータノーティファイア250、デコーダ255及びブータブルクラスに加えて、ルーティングマネージャ260クラス (図2に図解されている)である。付加的に、メンバとして実行されないアブストラクトクラスであるが、メンバに対する親クラスであるプロトメンバ及び外部ネットワークメンバクラスがある。フェデレイテッド OSを実現するサーバの一つの説明的実施例は、一つのレシーバメンバ、一つのディスパッチャメンバ及び八つのレスポンダメンバ(そして、望ましくはガーディアンメンバをも含む)を含む。フェデレイテッド OSは、メンバが希望によって付加又は削除され得る意味で拡張性がある。たくさんのレスポンダ、例えば400のレスポンダを含むことが可能であり、かつ、より多くのレスポンダでさえも用いられ得る。各レスポンダが、例えば、毎秒2.5ギガバイトでデータを伝送するならば、 そして、例えば、レスポンダが400あるならば、フェデレイテッド OSは、１テラビット(毎秒240 ビット)のデータを配信する能力を有するであろう。各レスポンダは、例えば、毎秒2.5ギガビットでデータを伝送するためOC-48接続に結合され得る。
【００５１】
要求されないけれども、望ましくは、どのメンバハードウェアユニットも、任意の非アブストラクトメンバの機能を実現するために、作動中("進行中")に劇的に再構成される能力を有する。換言すれば、メンバのCPUは、望ましくは、任意のメンバの機能を劇的に割り付けられることができる。例えば、もしディスパッチャが動作不能になったなら、例えばレスポンダ又はレシーバが、ディスパッチャとして機能するために、サーバの作動中に劇的に再構成され得よう。この能力はまた、動的負荷バランスを許容する。動的に再構成するメンバハードウェアユニットは、サービスロスなしに障害回復を許容する。このように、フェデレイテッド OS を実現するサーバは、故障メンバハードウェアユニット(又は、故障メンバIC)から離れたサービスを再配置することができる耐障害分散システムである。
【００５２】
望ましくは、すべてのメンバは、望ましくはプロトメンバから引き出されるブータブルメンバから引き出される。その代わりに、メンバは、 他のメンバから引き出されることなしに実現されることができる。その場合、そのようなメンバは、メンバ内通信機能性を実現しなければならない。
【００５３】
メンバクラスは、次のように記述される。
【００５４】
- レシーバメンバ:
望ましくは、一つ以上のレシーバがフェデレイテッド OSに含まれる。
【００５５】
本節では"レシーバ"の用語で記述しているが、一つ以上のレシーバがあり得る。
【００５６】
望ましくは、レシーバは、外部ネットワークメンバから引き出される。
【００５７】
レシーバを含む実施例において、レシーバは外部ネットワークに結合される。
【００５８】
レシーバは、クライアント接続マネージメントを扱う。例えば、 クライアントからの接続要求に呼応して、レシーバは、クライアントとサーバとの間の接続を確立する。例えば、TCP/IPの実施例において、レシーバは、クライアントとTCP接続を確立する。接続の確立は通常、クライアントデータの伝送を伴わない。
【００５９】
レシーバは、望ましくは、遠隔クライアントが伝送できる特定のサーバのネットワークインターフェースだけである。
【００６０】
レシーバは、外部ネットワークによってデータを受信したり、又は送信したりできる。しかし、TCP/IPの実施例において、レシーバは、一般にヘッダデータ、例えば、接続を確立するためにハンドシェークだけを伝送する。
【００６１】
レシーバとディスパッチャを含む実施例において、一旦クライアントとサーバとの間に接続が確立され、かつ、データが受信されたら、 レシーバはディスパッチャにデータを手渡す。例えば、TCP/IPの実施例において、データはHTTP要求であろう。
【００６２】
TCP/IPの実施例において、レシーバはIPとTCPを処理し、 そして、望ましくは、ARP(アドレス分析プロトコル)及びICMP(インターネットコントロールメッセージプロトコル)もまた処理する。
【００６３】
TCP/IPの実施例において、要求されないけれども、レシーバは、望ましくは、部分的TCP/IP状態マシーンだけを有する。
【００６４】
TCP/IPの実施例において、レシーバは、望ましくは、IP断片再組成を管理する。
【００６５】
TCP/IPの実施例において、レシーバは、望ましくは、幾つかのTCP状態情報を保持する。
【００６６】
- ディスパッチャメンバ:
望ましくは、一つ以上のディスパッチャがフェデレイテッド OSに含まれる。
【００６７】
本節で"ディスパッチャ"の用語が記述されているが、一つ以上の ディスパッチャがあり得る。
【００６８】
防護を増強するディスパッチャ外部ネットワークに結合される必要はない。
【００６９】
ディスパッチャは、望ましくは、例えば、各クライアント要求に応答するためにどのレスポンダを割り付けるかを判定し、資源配分を管理する。要求に応答するために必要とされるデータは、一つ以上のレスポンダにわたって拡大されることができる。
【００７０】
TCP/IPの実施例において、ディスパッチャは、望ましくは、有効接続管理と、例えば、HTTPセッションマネージメント、メールセッションマネージメント及びFTPを含むサービス管理を実現する。
【００７１】
TCP/IPの実施例において、ディスパッチャは、データを伝送することが許される状態にある接続を処理する。ディスパッチャは、望ましくは、ディスパッチャが処理している各接続状態の記録を保持する。 状態情報には、フェデレイテッド OS(例えば、どのレスポンダと応答識別子が与えられた接続に関与しているか)によって要求される情報はもとより、 TCP仕様(例えば、シーケンスナンバ)によって要求される項目を含む。例えば、接続は特定のサービスに関係し、サービスコードは、接続のレスポンスオブジェクトに関係する。応答識別子は、レスポンスオブジェクトを識別するディスパッチャ内に保存される状態情報であり、かつ、例えば、ディスパッチャが、レスポンダが正しい応答情報を識別することを許容するレスポンダに手渡す指標として有用な整数である。接続に関する他の状態情報は、望ましくは、他のメンバによって保持される。
【００７２】
- レスポンダメンバ:
望ましくは、一つ以上のレスポンダがフェデレイテッド OSに含まれる。
【００７３】
本節では、時には"レスポンダ"の用語で記述しているけれども、一つ以上のレスポンダがあり得、望ましくは、サーバに多くのレスポンダがある。
【００７４】
望ましくは、レスポンダは外部ネットワークメンバから引き出される。
【００７５】
レスポンダを含む実施例において、レスポンダは、外部ネットワークに結合される。
【００７６】
レスポンダは、データを伝送する。
【００７７】
レスポンダは、望ましくは、静的データを管理し、伝送することができ、及び/又は動的データを作成、管理及び伝送することができる。
【００７８】
レスポンダは、特定のクライアントに要求されるデータを送る機能を遂行する。
【００７９】
TCP/IPの実施例において、レスポンダは、HTTP データ、メールデータ及び／又は他のサービスのためのデータを伝送する。
【００８０】
要求されていないけれども、望ましくは、少なくとも一つのフェデレイテッド OSのメンバは、非リアルタイムレイヤを含む。例えば、レスポンダは、非リアルタイムプログラム(例えば Java)を走らすために、非リアルタイムレイヤを含むことができる。望ましくは、非リアルタイムレイヤはLinuxである。その代わりに、非リアルタイムレイヤは、FreeBSD、又はOpenBSDのようなオープンソース非リアルタイムレイヤ 、若しくは、AIX又はSolarisのような非オープンソース非リアルタイムレイヤ、あるいは、任意の他のオープンソース又は非オープンソース非リアルタイムレイヤであり得る。フェデレイテッド OSは、非リアルタイムレイヤへのインターフェースがなくても、オペレーショナルサーバを実行するために用いられることができるが、その場合には、サーバは非リアルタイムプログラムを走らせることはできない。非リアルタイムレイヤ、例えばLinuxは、 フェデレイテッド OSのメンバ上でタスクとして動作する。
【００８１】
望ましくは、レスポンダに主となる二つの動作がある: (1)レスポンダに貯えられた静的データを伝送する、及び/又は、静的データをレスポンダ上にロードする; (2)例えば、レスポンダの非リアルタイムレイヤ内で走っているJava仮想マシーン上で走っているアプリケーションにレスポンスを生成することによって、動的データ要求をサービスする。
【００８２】
TCP/IPの実施例において、望ましくは、レスポンダは、二つのグループに分割され、それは、(1) 静的レスポンダメンバ、そして、(2) 動的レスポンダメンバ、を含む。静的レスポンダメンバは、例えば、 HTTP、FTP、メール及び他のサービスのため、静的データをマネージし、そして、伝送する。
【００８３】
動的データは、フェデレイテッド OSの任意のメンバによって、リアルタイムレイヤ又は非リアルタイムレイヤのどちらかで、生成されることができる。例えば、動的レスポンダメンバは、持続性ストレージメンバ(例えば図4Bにおける持続性ストレージメンバ475)からデータを要求することができ、随意的にそのデータを他のデータ(例えば、HTTPヘッダ)と束ね、束ねたデータをクライアントに伝送することができる。他の事例において、動的レスポンダメンバは、外部データベースサーバ(例えば、図4Bにおける外部データベースサーバ485)からデータを要求することができ、随意的に、そのデータを他のデータと一緒にし、一緒にしたデータをクライアントに伝送することができる。動的レスポンダ が、非リアルタイムレイヤをもつ必要はない。もし、動的レスポンダが非リアルタイムレイヤをもつならば、次に動的レスポンダは、非リアルタイムレイヤスケジューリング、及び非リアルタイムレイヤメッセージングインタフェース(例えば、Linux又はSolarisへ)を実行する。動的レスポンダメンバは、クライアントに動的データを伝送する。望ましくは、動的レスポンダメンバは、静的レスポンダメンバから引き出される。
【００８４】
- コンフィギュレータメンバ:
コンフィギュレータは、再構築されたフェデレイテッド OSの実施例において、必要とされない。
【００８５】
本節では"コンフィギュレータ"の用語で記述されているが、サーバに一つ以上のコンフィギュレータがあることができる。しかしながら、望ましくは、サーバに只一つのコンフィギュレータがある。
【００８６】
コンフィギュレータは、オーバオールシステムコンフィグレーションをロード、修正及び保存するためにユーザインタフェースを有している。望ましくは、コンフィギュレータはまた、ユーザにそのシステムの最新構造についてシステムに問うこと、及びその動作を監視することを許容する。望ましくは、コンフィギュレータは、言語を中立に符号化し、おびただしい言語(例えば、英語、日本語、ドイツ語など)がユーザインタフェースで完全にサポートされる。望ましくは、ユーザインタフェースは、グラフィカルユーザインタフェースで、それが、モニタ、マウス及びキーボードなどと一緒に用いられる。
【００８７】
図3に示すように、フェデレイテッド OSを実現するサーバ300の一つの説明的実施例は、メンバハードウェアユニットと内部ネットワーク(例えば、図2に示すメンバハードウェアモジュール及び内部ネットワーク)を含むサーバハウジング305を含む。サーバは一つ以上の場所で、外部ネットワークに結合される。このサーバの説明的実施例は、望ましくは、コンフィギュレータメンバに結合されるモニタ310、マウス315及びキーボード320をも含んでいる。
【００８８】
TCP/IPの実施例のHTTPサービスにおいて、システムコンフィグレーションは、IP アドレス及びリスンするTCPポートのようなアイテムを含む。コンフィギュレータは、全体システムの集中化したコンフィグレーションを提供し、それは、TCP/IPの実施例において、望ましくは、例えば、HTTPサービス、FTPサービス、IMAP eメールサービス及びPOP3 eメールサービスのような、すべてのコアインターネットサービスを含む。
【００８９】
システムを構築するとき、コンフィギュレータは、他のメンバに符号を伝送するか、又は、他のメンバに符号の位置、（それは、与えられたコンフィグレーションに必要とされる特定のメンバのクラスの場合になるために、他のメンバが作動する）を通知する。このコードは、ROM、持続性ストレージメンバ、又は他のストレージデバイスに保存することができる。
【００９０】
コンフィギュレータメンバは、コンフィギュレータメンバがサーバのリアルタイム動作に参画する必要がないが故に、プロトメンバのサブクラスでなければならなくはない。望ましくは、コンフィギュレータは、プロトメンバのサブクラスでなく、かつ、リアルタイムメンバでもない。もし、コンフィギュレータがプロトメンバのサブクラスとして実現されないならば,コンフィギュレータメンバは、コンフィギュレータメンバがリアルタイムメンバと交信できるように、依然としてプロトメンバと同じメッセージングプロトコルを実現しなければならない。コンフィギュレータは、例えば、非リアルタイムOS(例えば、MacOS又はLinux)上の標準処理として、サーバの内部ネットワークと交信することを必要とするデバイスドライバと共に、実現されてよい。
【００９１】
- ガーディアンメンバ:
一つ以上のガーディアンメンバがフェデレイテッド OSに随意的に含まれてもよい。
【００９２】
本節では"ガーディアン"の用語で記述されているが、一つ以上のガーディアンがあり得る。
【００９３】
ガーディアンメンバは、他のメンバに周期的質問を発することによってはもとより、他のメンバから周期的なステータスメッセージを受け取ることによって、システムのヘルスを監視する。それ故に、ガーディアンは、周期的に、例えば、毎秒１回(又は他の任意の時間周期)、内部ネットワークでメンバからデータを受け取る。望ましくは、ガーディアンは、ハードウェア、ソフトウェアの双方を監視する。システムは、一つ以上のガーディアンが一つ以上の他のガーディアンを監視するように構成することができる。
【００９４】
ガーディアンを介して、サーバは、機能不全メンバを検出し、それぞれ個々の機能不全メンバの機能を実現するために、他のメンバハードウェアユニットを割り付けることによって、機能不全メンバと作動中のシステムを動的に再構築することができる。ガーディアンは、未達メンバが責任を負っていたデータを、未達メンバと同じクラスの他のメンバのハードウェアユニットにロードすることによって、かつ次にその変更をメンバに通知することによって、これを達成することができる。例えば、未達レスポンダの未達レスポンスデータは、他のレスポンダ上にロードされ、影響を受けるディスパッチャは、影響を受けた応答の新しい位置を知らされる。未達メンバと同じクラスの他のメンバがまったくないか、又は、既存のメンバが再配置された機能性を受け入れることができないならば、既存メンバのクラスは、既存のメンバハードウェアユニット(それは、依然として他のメンバのハードウェアユニットへそのメンバの機能性を再配置することを要するかも知れない)を再スタートさせることによって、未達メンバのクラスに変更されてよい。このように、アーキテクチャは自己監視であり、自己治療的である。
【００９５】
もしCPUが損傷したら、その損傷はガーディアンによって検出され、そして、未達メンバタスクが他のメンバの他のプロセッサに明白に再配置され、かつ、他のメンバへの警告が内部ネットワーク上に公表される。メンバ内のCPUは損傷していないが、メンバ内の内部通信チャネル がハードウェア又はソフトウェア損傷のために利用できないならば、望ましくは、未達メンバは自動的にいかなるサービスロスもなしに、メッセージを再ルートする。これが可能でないならば、損傷はガーディアンによって検出され、CPU損傷の場合のように回復が進むであろう。
【００９６】
負荷バランス: フェデレイテッド OS のアーキテクチャは、その負荷が本質的にメンバ内に分配されるが故に、本質的に負荷バランスを実行する。例えば、TCP/IPの実施例において、TCP/IP状態マシーンは、複数のメンバ内で分配される。望ましくは、フェデレイテッド OSもまた、変化するユーザ要求に合わせるために動的に資源を割り付けるための、 インテリジェント負荷バランスを含む。動的負荷バランスは、例えば、ディスパッチャが最も軽い負荷であると判定するレスポンダにディスパッチャ割付タスクをもたすことによって、実現されることができる。その代わりに、又は、ディスパッチャによって制御される動的負荷バランスに加えて、動的負荷バランスは、レスポンダに、いつそれらが利用中であるかを判定させることによって、実現されることができる。ディスパッチャ及び/又はレスポンダが、一つ以上のレスポンダが軽い負荷であると判定するとき、二つ以上のレスポンダの機能性は、より少数のレスポンダ (未達のメンバを回復するのに用いられる方法に類似した方法で)に統合することができる。結果的に未使用メンバのクラスは、より大きな負荷を経験しているメンバクラスのメンバとして、例えば、レシーバ、未使用メンバを再スタートさせることによって変更することができる。静的負荷バランスは、データをレスポンダ間に分割することによって単純に実現することができる。負荷バランスに対する他のアプローチは、地理的アルゴリズムであり、それでは、要求しているクライアントに地理的に最も近いレスポンダが選択される。更に負荷バランスに対する他のアプローチは、ネットワークトポロジアルゴリズムであり、それでは、ネットワークトポロジの用語でクライアントに一番近いレスポンダが選択される。レスポンダの負荷は、各レスポンダの能力に基づいて分配することもできる。例えば、暗号化能力を要するレスポンダは、暗号化能力を有するレスポンダに割り付けられる。負荷バランスは、自動化されることができるか、又は人間の介在を必要とすることができる。
【００９７】
- 持続性ストレージメンバ:
一つ以上の持続性ストレージメンバが随意的にフェデレイテッド OSに含まれるてもよい。持続性ストレージメンバは、その他のメンバクラスに関して一意であり、一つ以上のデータ蓄積デバイスへの直接インターフェースを有する。したがって、持続性ストレージメンバを実現するのに用いられるハードウェアは、一つ以上のデータ蓄積デバイスに結合するためのインターフェースをもたなければならない。持続性ストレージメンバは、他のメンバへの及び他のメンバからの生データを取り扱うことに対し責任がある。これは、メンバのプロセッサが大量のストレージ、好ましくは、テラバイトの高速(毎秒ギガビット)冗長ファイバチャネルRAID(Redundant Array of Independent Disks)ストレージ、を共有するのを許容する。他のいかなるタイプ及びサイズのストレージ、例えば、従来のハードドライブ、光ディスク、ROMなどもまた用いられ得る。随意的に、持続性ストレージメンバは、メモリ常駐データベースにデータを貯えるのに用いられる大量の高速RAMを含んでよい。随意的に、持続性ストレージメンバは、ファイルシステムをエミュレートしてよい。
【００９８】
-システムアドミニストレータノーティフィアメンバ:
一つ以上のシステムアドミニストレータノーティフィアメンバがフェデレイテッド OSに随意に含まれてもよい。電源又はテレフォンサービス停止のような中断事故において、システムアドミニストレータ要員に、例えばページャー又は携帯電話によって、事故基準遠隔警報を通報する。システムアドミニストレータノーティフィアは、中断自体を検知するか、又は、他のメンバによって中断を連絡されて、それからシステムアドミニストレータノーティフィアは、中断事故を通知するために、システムアドミニストレータ要員に接触を試みる。 随意的に、システムアドミニストレータノーティフィアメンバの機能性は、ガーディアンメンバに含まれることができる。
【００９９】
- デコーダメンバ:
１つ以上のデコーダがフェデレイテッド OSに随意に含まれてもよい。
【０１００】
デコーダは、暗号化/解読又は認証機能、例えば、TCP/IPの実施例において、SSL(Secure Sockets Layer)セッション管理を扱うことに特に最適化したメンバである。デコーダメンバの一つの実例となる実施例は、与えられた接続に対し、各CPUは同時に暗号化/解読の集中的局面の演算を扱う、多数の専用化したCPU(例えばRISCプロセッサ, 又はディジタルシグナルプリセッサ)を含んでいる。
【０１０１】
-ルーティングマネージャメンバ:
一つ以上のルーティングマネージャがフェデレイテッド OSに随意に含まれてもよい。ルーティングマネージャは、アドレスルーティング表を保持している。例えば、TCP/IPの実施例において、ルーティングマネージャメンバは IPルーティング表を保持している。
【０１０２】
-ファイアウォールマネージャメンバ:
一つ以上のファイアウォールマネージャメンバが、フェデレイテッド OSに随意に含まれてもよい。ファイアウォールマネージャメンバは、どのデータが、ある外部ネットワークから他のネットワークに転送されるべきかを判定する。
【０１０３】
-プロトメンバ:
プロトメンバは、他のリアルタイムメンバクラスの親クラスである。むしろ、すべてのリアルタイムメンバクラスはプロトメンバの資産を継承する。 (上に述べたように、コンフィギュレータメンバは、プロトメンバのサブクラスである必要はない)
【０１０４】
プロトメンバクラスは、概念上のクラスである。即ち、プロトメンバだけ生成するメンバの場合があるのではなく、むしろ各リアルタイムメンバがむしろプロトメンバクラスから引き出されるサブクラスの一つの場合であるということを意味する。
【０１０５】
プロトメンバ機能性には、例えば、メモリ管理、自己ヘルス監視、メンバ間通信及びユーティリティ機能が含まれる。自己ヘルス監視は、そのメンバが そのパフォーマンスと負荷を測定する能力、及び、そのメンバを構成するハードウェア、ファームウェア及びソフトウェアコンポーネントの状態を判定することによってその"ヘルス"を判定する能力を有することを意味している。プロトメンバは、あるメンバに問題があり、その上支援を要求するときを判定する能力を含むことができる, 及び／又は、そのデータを分析し、問題があるかどうかを判定する他のメンバとデータを共有する能力を含むことができる。メンバ間通信機能性は、他のメンバからのメッセージを送り、応答する機能性である。例えば, プロトメンバは、どのクラスのメンバ、例えばレシーバ、がそうであるかをそのメンバに通知するコンフィギュレータからのメッセージに応答する機能性を含む。プロトメンバはむしろ、指定されたメンバクラスをあるメンバに割り当てる権限を与えるコードを受信し、ローディングする機能性をも含む。言い換えれば、望ましくは、どのメンバも(恐らくコンフィギュレータメンバを除き) それ自身そのOSの新しい例であるメッセージを受信する能力を有している。例えば, メッセージの内容はブータブルメンバを、例えばレシーバに変換するOSコードであり得る。上で議論したように、メンバは、他のメンバのクラス、 例えばディスパッチャにその後変換されることができる。
【０１０６】
-外部ネットワークメンバ:
外部ネットワークメンバは、むしろブータブルメンバのサブクラスであり、かつ、レシーバ及びレスポンダメンバの親クラスでもある。 外部ネットワークメンバ916の一事例を図9Aに示す。レシーバ及びレスポンダメンバは、むしろ外部ネットワークメンバから、外部ネットワークインターフェース能力及び生プロトコルサポートのような資産を受け継ぐ。TCP/IPの実施例における生プロトコルサポートの一事例は、 IP 及びTCPパケットの解剖及び生成である。外部ネットワークメンバクラスは、むしろアブストラクトクラスである。即ち、外部ネットワークメンバだけ生成するメンバの場合があるのではなく、むしろ各レシーバ及びレスポンダメンバがむしろ外部ネットワークメンバクラスから引き出されるサブクラスの場合であることを意味する。多分、各外部ネットワークインターフェース、例えばMyrinet、Ethernet及びATM、に用いられる異なる外部ネットワークメンバがある。その代わりとして、大多数の外部ネットワークインターフェースをサポートする単一の外部ネットワークメンバがある。
【０１０７】
-ブータブルメンバ:
ブータブルメンバは、プロトメンバのサブクラスである。このように、ブータブルメンバは、プロトメンバの機能性を受け継ぐ。しかしながら、ブータブルメンバは、その機能性を実現するに必要なCPU特有コードを定義しなければならない。ブータブルメンバは、フェデレイテッド OSリアルタイムメンバの骨格例である。ブータブルメンバがCPU固有コードを有するが故に、ブータブルメンバは、必ずしも同一である必要はない。このように、X86、PowerPC及びDSPプロセッサに対するブータブルメンバは、互いに異なっている。CPU固有コードは、例えば、固有バイト順及びワードサイズを含むことができる。典型的には、ブータブルメンバに対する実行形式コードは、パワーがそのメンバに与えられたとき、そのメンバがブータブルメンバの場合になるように、メンバ(ノード)のファームウェア(非揮発性メモリ)の部分である。
【０１０８】
各メンバクラスは、(あるいはコンフィギュレータクラス及び プロトクラスを除き)むしろブータブルメンバのチャイルドクラスである。ブータブルメンバは、メンバに割り当てられた指名されたメンバクラスを実現するために、実行形式コードを受信及びロードする能力を有する。換言すれば、各ブータブルメンバ又はブータブルメンバのサブクラスは、オペレーティングシステムの新しい依頼を含むメッセージを受信する能力を有する。例えば、そのメッセージは、ブータブルメンバを、例えば、レシーバに変換するため、オペレーティングシステムコードを含み得る。上に論じたように、メンバは続いてメンバの他のクラスに変換されることができる。
【０１０９】
図4A は、フェデレイテッド OSの実例となる実施例において、プロトメンバ405、ブータブルメンバ410、レシーバメンバ415、ディスパッチャメンバ420及びレスポンダメンバ425間の階層関係を図解している。図4Aは、ブータブルメンバがむしろプロトメンバの場合であり、かつ、フェデレイテッド OSのノードとして操作しているメンバクラスがむしろブータブルメンバの場合である(ブータブルメンバは同一である必要はないが)ことを図解している。図4Bは、その実施環境におけるサーバ440のブロック図であり、フェデレイテッド OSの実例となる実施例を実現している。図4Bは、レシーバ445、ディスパッチャ450、レスポンダ455、コンフィギュレータ460、ガーディアン465、デコーダ470、持続性ストレージメンバ(データサーバ)475、ガーディアン480、外部データベースサーバ485、内部ネットワーク490、 外部ネットワーク492及びクライアント495を図解している。図4Bに示す外部データベースサーバは、フェデレイテッド OSを実現するサーバの内部ネットワークに随意につなげる従来型サーバである。
【０１１０】
内部ネットワークモジュール
プロトメンバとコンフィギュレータメンバは内部ネットワークモジュールを含むことが望ましい。（例えば、図 9Aの内部ネットワークモジュール902 ）
【０１１１】
内部ネットワークモジュールは内部ネットワークにおける簡易通信に使用される、例えば、内部ネットワークインターフェース、メッセージデータ構造、メッセージプロトコルを含む。内部ネットワークモジュールは特殊なインターネットプロトコルのためのものである。例えば、内部ネットワークに使われるプロトコルにより、次のモジュールのうち一つが使われる：Myrinetなどの切替構造クロスバー、VMEやSONETなどのバスバックプレーン。
【０１１２】
内部ネットワークモジュールはメンバクラスではない。
【０１１３】
メンバの地理的分散による実施例
フェデレイテッド OSの実施例のひとつは、少なくとも一つのメンバが他のメンバと異なる地域にいることである。 フェデレイテッド OSにおいては、メンバ(またはプロセッサー)にとって、物理的に近接または接触している必要はないから 可能なことである。メンバは同一の構内や同一の部屋、同一の大陸にでさえある必要はない。言い換えると、メンバは内部ネットワークで交信できる限り、どこに散在していることも、どこにいることでもできる。例えば、内部ネットワークはバスバックプレーンよりもSONET通信方式を使用したWANによって実行できる、（SONET以外の通信方式も使用可能）例えば、一つまたは数個のレスポンダが異なった場所にいることはフェデレイテッド OSの状況よりも有効である。 例えば、レシーバとディスパッチャをワシントン州シアトルに配置したまま、日本にいるクライアントの近くにデータを置くため、レスポンダを東京に配置し、日本のクライアントからの要求に対して迅速にサービスが可能となるであろう。フェデレイテッド OSの他のメンバはデータを遠隔的に配置することができるが、他の実施例同様、この実施例でも１クライアントに１セッションということのみが要求される。このように、この実施例では、サーバ全体を複写する必要性もなく、さらに過剰なトラフィックの生成や、サイトへのヒット数の追跡困難性など、サーバ複写に伴う好ましくない結果も生じずに、レスポンダをクライアントの近くに配置することができる。
【０１１４】
このメンバ地理的分散のもう一つの実現は、同一のフェデレイテッド OSの多くのレスポンダを地球のどこにでも配置できることである。例えば、一つまたは数個のレスポンダを例えば、ニューヨーク、ロンドン、ベルリン、ホンコン、東京に配置するときに、一つ又は数個のレシーバやディスパッチャ、望ましくは他のメンバを主たる事業所、例えばワシントン州シアトルに配置することができる。例えば、百個または数百個のレスポンダを一つのフェデレイテッド OSのメンバとして世界のあらゆるところに配置することが可能である。レスポンダはサテライトにいることも可能である。
【０１１５】
内部ネットワーク 510によるSONET通信システムを使用したサーバ505のメンバ地理的分散の実施例が図5の図である。これによると一つのレスポンダ515をニューヨークに、二つのレスポンダ 520と525を東京に配置し、レスポンダ 530と残りのメンバ535をシアトルに配置する。レスポンダがシアトルにある必要はない。メンバが地理的分散になっているとき、実施例は、メンバのどれもが内部ネットワークを通して互いに通信できている限り、メンバは他のメンバとどんなに遠隔地でも配置することができる。このように、この実施例はレスポンダが他のメンバから遠くに配置されるという制限をするわけではない。例えば、一つのレシーバ、または一つのレシーバと一つのレスポンダを、フェデレイテッド OSの残りのメンバから遠くに配置することが可能である。
【０１１６】
地理的分散の実施例はインターネットアプリケーションにとって特に興味深い。というのはインターネットアプリケーションは、望ましくはフェデレイテッド OSのサンダー OS実施例により実現されるからである。
【０１１７】
直接インターネットバックボーン接続の実施例
もう一つの発明の実施例によるサーバ 605 が 図 6に示されている。これによると、一つ又は数個のレシーバ 610 と レスポンダ 615 が インターネットバックボーン620（外部ネットワーク）に直接接続されている。これによりホップの数を減少させ、スピードを早める。
【０１１８】
直接インターネットバックボーン接続と遠隔データ保存の実施例
もう一つの実施例の示されている図７は 上記の実施例として、一つまたは数個のレシーバとレスポンダがインターネットバックボーン710(外部ネットワーク) に直接接続されている。この例では、ディスパッチャ720が安全な専用接続 730を通してディスパッチャ725に接続されている。ディスパッチャ725 は SSL(Secure sockets Layer) を実行し、一つ又は数個のデコーダ735（エンコーダとデコーダ）と一つ又は数個のレスポンダ740 に接続される。レスポンダ740は外部ネットワークに接続される。レスポンダ740はデコーダ735にも接続される。ディスパッチャ725、デコーダ735、レスポンダ740はセキュアーサイト(これは典型的にレシーバ745、ディスパッチャ720、レスポンダ750と地理的に遠隔にある。)にある。例えば、銀行や会社はレスポンダ740のデータの維持管理が必要である。例えば、この実施例は インターネットを介してデータを利用したい会社または銀行が、データ保存を管理下におきながら、さらに、バックバーンに直接接続されたレシーバとレスポンダに超高速を維持しながら使用できる。この実施例では、クライアントが符号化したメッセージをレシーバ745に送る。それはレシーバからディスパッチャ720へ転送され、さらにディスパッチャ720から専用接続730を通してディスパッチャ725に送られる。さらにディスパッチャ725はメッセージをデコーダ735の一つに送る。デコーダ735はメッセージを復号化し復号化されたメッセージをディスパッチャ725に返送する。ディスパッチャ725はメッセージを要望されたレスポンダ740の一つの場所を認識しながら発送する。データはデコーダ735の一つに送られ、そこで復号化されて、レスポンダ740の一つに返送される。さらに復号化されたデータはインターネットを通じてクライアントに発送される。
【０１１９】
対称と非対称の実施例
発明のある実施例は非対称用法に関連する。発明のウェッブサーバへの応用は典型的な非対称による実施例の一つの例になる。これらの実施例は非対称に関連する。なぜならば、サーバで受信するデータの量はサーバから出力されるデータ量より通常は極端に少ないからである。(しかしながら、サーバで受信するデータ量が出力されるデータ量より多い状況では データの流れは他方向については非対称にすることは可能である。例えば、修復されない多くのメールを受信するメールサーバーにおいて。) 発明の他の実施例は、対称であるといえる。メールサーバ(ここからメールは通常回収される)は、典型的な対称の実施例のサンプルである。典型的対称の他の実施例はIPパケットがボイスデータを運んでいるような電話での実施例である。これらの実施例は対称状況にある。なぜならばサーバによって受信されたデータ量と、サーバによって出力されるデータの量がおおよそ同じである。発明の実施例では非対称と対称性能の両方が可能である。例えば、サーバが典型的なインターネットデータサーバーとして機能でき、メールサーバー及び／またはボイスデータサーバとしても機能できたときである。
【０１２０】
Thunder Operating System（ＴＭ）(Thunder OS（ＴＭ）)
(Thunder Operating System（ＴＭ） と Thunder OS（ＴＭ）はThunder River Technologies, Inc.の商標である。（以下、「サンダーオペレーティングシステム」及び「サンダーOS 」と訳す。）
【０１２１】
サンダー OS はフェデレイテッド OSの多くの実施可能例の一つであり、インターネットサーバとして満足されるフェデレイテッド OSの特有の例であり、フェデレイテッド OS の効果的実施例である。サンダー OSは分散しており、フェデレイテッドOS のスケーラブルTCP/IPの実施である。フェデレイテッド OS(サンダー OSのいろいろな実施例を含み得る)のサンダー OS 実施例では、メンバはサンダー OS を立ち上げると一緒にオペレーティングシステムを実行する。一般的フェデレイテッド OSとしては、サンダー OSで各メンバクラスがそれぞれのオペレーティングシステムを実行する。サンダー OSは分散型TCP/IP状態マシーンを含んでいる。サンダー OSはインターネット用としてとても有効なインターネットサーバーソフトとTCP/IPを統合する。サンダー OSはメンバのオペレーティングシステムの相続階層を実行させるC++プログラム言語を実行させる。速度を上げるために、サンダー OSは主なインターネットサービスとプロトコルが分散されたオペレーティングシステムの一部として直接実行されるように実行される。これらの主なインターネットソフトウエアサービスとプロトコルはつぎを含む：
【０１２２】
― HTTP(ハイパーテキストトランスファープロトコル)；
― FTP(ファイルトランスファープロトコル)；
― IMAP(インターネットメッセージアクセスプロトコル)；
― POP3(ポストオフィスプロトコル3)
加えて、これらのキーインターネットソフトウエアサービスとプロトコルに対して、TCP/IP, DNS(Domain Name Server), ARP(Address Resolution Protocol), UDP(User Datagram Protocol), ICMP(Internet Control Message Protocol) などのオペレーティングシステム によくある他の低レベルのネットワークプロトコルはサンダー OSにも含まれることが望まれる。サンダー OSはWAP(Wireless Application Protocol) , SSL(Secure Sockets Layer), 及び他のサービスやプロトコルをも含むことが望ましい。これらのサービスやプロトコルは必要な処理を配送する複数のメンバクラスを実現する配信された方式により実行される。サンダー OSでは、これらのサービスやプロトコルの実行は入ってくるネットワークパケットに関してリアルタイム行う。この方法は多くの有効な関係のサーバがメインテナンスされているにも拘わらず入ってきたパケットは時間の量を束ねてそれぞれ実行される。対称のメッセージをすることはリアルタイムデッドラインを強化することに使われ、リアルタイムのTCP/IPの状態マシーンは定時アルゴリズムで実行される。サンダー OS 805の説明的実施例が図 8 にあるが、TCP/IP(Transmission control Protocol/Internet Protocol), HTTP(Hyper Text Transfer Protocol), FTP(File Transfer Protocol), IMAP(Internet Messaging Access Protocol), DNS(Domain Name Service) などが含まれる。
【０１２３】
図8に示すように、フェデレイテッド OSのサンダー OSの実施例において、好ましくは、フェデレイテッド OSは、動的コンテンツ、例えば Java, Python, PERL,FastCGI, CGI, Smalltalk, PHP, Erlang, C++, 他、を発生するためのツールをサポートするために、指定されたプロセッサ又はメンバ上の非リアルタイムレイヤを動作させる。したがって、これらの言語または環境でかかれたオプションのエンドユーザーアプリケーションは非リアルタイムレイヤを動作させることができる。サンダー OS のメンバはリアルタイム処理が休んでいるときにはしることができる非リアルタイムシステムへのインターフェースするためのオプショナルサポートにより単一スレッドのリアルタイムの処理として実行される。非リアルタイムレイヤはマルチプルプロセッサーまた実施のスレッドでマルチタスクのサポートすることができる。非リアルタイムレイヤは望ましくはLinux kernel であり、さらにその他の非リアルタイムシステムもサポートされることができる。サンダー OS上のLinux レイヤのオペレイテイングは現存するLinux のアプリケーションが今のままで動作することを確実にする。リアルタイムのインターネットサービスやスタンダードベースのオープンインターフェースLinuxに供給することをサンダー OSで管理することで、フェデレイテッド OS の本実施例でサーバに実施することで大きな動的なウエッブサイトのための強力なプラットフォームを供給する。動的コンテンツはリアルタイムレイヤに起動されることができ、またはアプリケーションによって非リアルタイムレイヤで動作する。例えば、非リアルタイムレイヤでは、Java virtual machine がJava アプリケーションのために供給される。またPerl 翻訳はPerlで書かれたアプリケーションに供給される。これらのアプリケーションは要求への応答の動的データを作り出すが、要求したクライアントにデータを如何に返送するかを明らかにする必要はない。 図９Aはメンバとサンダー OS の関係をブロック図に書いたものである。図 9Aは内部ネットワークモジュール902、コンフィギュレータメンバ904、 プロトメンバ906、ブータブルメンバ908、持続性ストレージメンバ910、 ガーディアンメンバ912、ディスパッチャメンバ914、 外部ネットワークメンバ916、 エンコーダ/デコーダメンバ918、(デコーダメンバとしても関連している)、ルーテイングマネージングメンバ920、 レシーバメンバ922、静的レスポンダメンバ924、動的レスポンダメンバ926、ファイアウォールマネージャメンバ928が含まれている。サンダー OSは中立に符号化された言語 つまり図9Aの箱で囲ってあるコンフィギュレータメンバの904とプロトメンバ906で実行される。つまり多種多様な言語が英語に加えてサポートされる。図 9Bはサンダー OSのブータブルメンバ908 の 機能と相互作用をブロック図で示している。図 9Cはサンダー OS の レシーバメンバ922の機能と相互作用をブロック図で示している。図 9Dはサンダー OS のデイスパッチメンバ914の機能と相互作用をブロック図で示している。図 9Ｅはサンダー OS の静的レスポンダメンバ924の機能と相互作用をブロック図で示している。図 9Ｆはサンダー OS の動的レスポンダメンバ926の機能と相互作用をブロック図で示している。サンダー OS では、レスポンダメンバは静的レスポンダメンバか動的レスポンダメンバである。
【０１２４】
サンダー OS (サンダー TCPを参照) の実行としてのTCPは、TCP接続のサービス強化のためのフェデレイテッド OS の分散された性能を実現する。TCPの性能(一体となったComments(RFC) 793のためのインターネット要求) は 11の状態の状態マシーンを現す。しかしながら、ほんのわずかのこれらの状態に実際のデータ転送が含まれている。これら状態の状態はサンダー OS などの分散された実行によりTCP自体の効果を増加する。サンダー OS によるサーバの実行は必要な状態情報を維持するための接続方法を使用して分散された状態マシーンとして実行される。
【０１２５】
サンダー OS の実行の供給は図 10にあり、次のようである。 接続の創設(TCPのthree way handshake) はサービスへの依存がある。与えられたポートの番号でサービスを組み入れる知識しか要求されない。このTCP 状態マシーンの一部はレシーバ番号1005という別々の番号に効果的に分散される。このレシーバメンバは多数の接続ができ、サービス固有処理で一般的に負担を負わない。一度接続が完成したら、接続の目標はディスパッチャメンバ1010につくられ、この目標は現行のTCP ポートで組み込まれる。ディスパッチャ(1) は確認と再転送のようなTCP 機能のデータ転送部分のさまざまな機能を管理し (2)適切なサービスを要請する。サービスはディスパッチャメンバ、そして/または異なったメンバ(または複数のメンバ) に機能的に行われる。ディスパッチャメンバと少なくとも他のクラスのメンバ双方に代表的に分散される。代表的にサービスの方法としてのデータの発生と転送はレスポンダメンバにもたらされ処理と同じくらいディスパッチャメンバを休ませる。
【０１２６】
チェーンの最後はレスポンダメンバ1015である。レスポンダは発送者による最低の通信を要求する。この通信はレスポンダがどのデータが送られたか、いつデータがおくられたか、どのくらいのデータが送られたか(または時間がきれたときは再発送)を知るために場所をとる。 レスポンダは呼び出しの間、いかなる持続的状態情報も維持することは必要としない。なぜならディスパッチャは各呼び出しのレスポンダに必要な接続状態を供給するからである。複数のレスポンダメンバは特定のディスパッチャに関連づけられる。それにより許された複数の接続が平行してサービスされる。加えて、複数のディスパッチャを特定のレシーバメンバに関連付けられる。
【０１２７】
サンダー OS で、クライアントとサーバのIPアドレスおよびTCPポートを、接続目標と特定のサービスに関連付けるデータ構造を、一定区間の時間に探索できる。それは、探索できる時間が、現在の有効接続またはサービスの数から独立しているからである。探索はクライアントとサーバのIPアドレスおよびTCPポート番号により、定義された接続を関連付ける現在の接続状態情報を入れている記録をみつけることができる。ホスト探索は時間の一定区間でまたできあがる。このアプローチは慣習的TCP実行の多くの制限を消滅する。可能で有効なメモリは有効接続サポートの数の唯一の制限である。先行技術のサーバーソフトは各接続を使用するサーバ処理の分離した場合を要請することにより複数のクライアントの同時使用にしばしば使われる。従って、多くの数のクライアントが低速ネットワークインターフェースを使用して大量のシステムリソースを相対的に要求できる。実際のクライアントのサービスが接続の低いバンド幅によってつまらないものになっていてもである。一方、サンダー OSは、単一スレッドイベント駆動型アプローチを出て行くデータの発生と転送のための分散された併行実施で入ってくるパケットを管理するために使用する。このアプローチはシステムを早く十分にリアルタイムに事象(入ってくるネットワークパケット)への応答をさせる。さらに、データの複数のメンバでの発生と転送を分散することはシステムの絵をかくことができる。このアプローチはもっと大きなクライアントの数を管理するための単一サーバをつくる。
【０１２８】
状態情報
クライアントからのサービス依頼のために、各接続のための状態情報は維持されねばならない。サンダー OSでのこの状態情報はレシーバ及び/またはディスパッチャにより維持される。異なったメンバが異なった時間に状態情報の一部を維持できる。各メンバは包括的状態の一部だけを維持する。そして全体の状態はメンバの複数を交差して保存される。TCPポートは(1) クライアントからの交信のためのリスニング、または(2)接続を確立することのどちらかを性格づける。接続の不在は閉ざされた状態(本当の状態ではない)として関連し、これは状態マシーンへの加入ポイントである。図 11はレシーバTCP接続状態マシーン1105の説明図である。図 12はサンダー OSのためのディスパッチャTCP接続状態マシーン1205である。これらの状態マシーンは次章で説明される。
【０１２９】
レシーバTCP接続状態マシーン
サンダー OS の実施例のレシーバ状態マシーン1105は図 11に描かれている。クライアントにより新たな接続が創作されたとき、クライアントはTCPヘッダのSYNフラッグ設定と共にTCPパケット(パケット１)を送る。レシーバが終点IPアドレスとTCPポートと共にこれらのパケットを受けたとき、レシーバは聴くために形作られる。さらにレシーバはこの接続(起点と終点IPアドレスとTCPポート番号両者による定義づけ)のためにデータ構造をまだ配置していない。レシーバは接続のための状態情報を維持するための新しいデータ構造を創造する。レシーバ接続トゥリーデータ構造はこの新しくつくられた構造により更新される。そこで将来同じIPアドレスとTCPポートとパケットが受け取られたとき、現存のデータ構造は発見される。あたらしく作られたデータ構造はSYN RCVD状態の接続を示すために初期化される。そこでレシーバはクライアントにパケットを受けた認識を返すためにパケット(パケット２)を送る。このパケットはACKフラグと同じSYNフラグもまた持つ。同時にレシーバがパケット(パケット3)を受けたときパケット2の認識はDISPACHER RELAY 状態への移送とディスパッチャが新接続状態記録を作るための必要な情報と共にディスパッチャに送る。この交換の完成はTCPの3方向ハンドシェークとして知られている。
【０１３０】
接続がDISPATCHER RELAY状態にあるとき、レシーバで受けられたいかなるパケットからの適切なデータはディスパッチャへ単純に送られる。ディスパッチャは接続がDISPATCHER RELAY状態に残っているべきか、ＦIN WAIT２状態へ転送すべきか、終了すべきかをレシーバに連絡する。ディスパッチャはまた如何なる最終知識またはレセットがクライアントに返送されるべきか、TCP ポートがTIME WAIT 状態へのマークをすべきかをレシーバへ連絡する。FIN WAIT2 状態の接続のため、もしFINフラグが入力パケットにセットされたら、接続は終了され、ポートはTIME WAIT 状態にマークされる。従来のTCP機能において、TIME WAIT状態は状態マシーンの実質状態であることに注意すること。サンダー TCP機能では、TIME WAITは状態マシーンの外で状態マシーンが要請される前にチェックを受けたデータ構造に示される。レシーバで接続が終了されたとき、接続状態情報のために設置されたデータ構造は解放される。状態SYN RCVDと状態FIN WAIT2状態は、TCP仕様書(RFC 793)に含まれる状態図の対応状態に相当する。状態DISPATCHER RELAYは接続がディスパッチャにより操作されているひとつの状態に接続されていることを示している。すべてのデータ転送はこの状態で起こり、レシーバは状態の接続のための非常に小さい処理を行うことを必要とする。サーバーサービスのため、これらのHTTPはクライアントへの接続を消さないし、SYN SENTの追加の状態は使用されない。
【０１３１】
ディスパッチャTCP接続状態マシーン
サンダー OS の実施例のディスパッチャ状態マシーン1205は図12に示めされている。ディスパッチャがレシーバから新しい接続状態を受けたときに、接続状態情報を維持するため新しいデータ構造をつくる。そしてレシーバへつくられた構造の識別子を返送する。この識別子は接続とともに将来のメッセージをつくるためにレシーバにより使用される。接続の状態はESTABLISHEDにセットされ状態に初期化された接続のためとして継続して進行される。
【０１３２】
ESTABLISHEDまたはCLOSE WAIT 状態での接続する場合、サービス用のコードが決められる。クライアントからデータを受けたとき及びクライアントにデータを送ったときの認識にレスポンダが使用する。サービス用コードはレスポンダに応答データを送るよう指示するためのものである。クライアントに必要なTCP認識を返送することも同じである。もし応答データが直ぐになかったら、必要であれば認識だけでも送られる。クライアントに送られるデータの量はTCP認識のシークエンス番号と各TCPパケットのクライアントにより送られるウィンドウサイズで制限もされる。ESTABLISHED、FIN WAIT １ またはFIN WAIT 2状態での接続のために、クライアントから受けた如何なるデータは接続に(サービス用処理はディスパッチャ自身にも起り得るし または 他のメンバと交差して供給され得る) 関連つけたサービスに送られる。ESTABLISHED状態での接続の場合、 もしクライアントが接続の端末を終了したら、接続状態はCLOSE WAIT にセットされる。 もしサービスが接続のサーバのエンドを終了したら、状態はFIN WAIT １にセットされる。
【０１３３】
CLOSE WAIT状態に接続する場合、サービスが接続のサーバーエンドで終了されたら、状態はLAST ACKにセットされる。
【０１３４】
LAST ACK状態に接続する場合、もしクライアントが全てのサーバーデータを認識していたら、接続状態データ構造は割当解除されるし、レシーバは接続を終了すると告げられる。FIN WAIT 1の接続のためには、もしクライアントが接続のエンドを終了し 全てのサーバーデータの認識がなかったなら、状態はCLOSINGにセットされる。もしクライアントが接続のエンドを終了しサーバのデータの全てを認識していたら接続状態データ構造は割当解除されレシーバは最終認識を送りTIME WAITにあるよう接続のマークをするよう指示される。もしクライアントが接続のエンドを終了しサーバのデータのすべての認識をもっていてサービスはサーバーエンドを終了したあとのデータクライアントのデータに同意していると、状態はFIN WAIT 2 にセットされる。もしクライアントが接続のエンドを終了しサーバーデータのすべての認識を持ちサービスが接続のエンドが終了になったあとのクライアントデータに同意していないときは接続状態データ構造は割当解除されレシーバは接続状態をFIN WAIT 2にセットするよういわれる。FIN WAIT 2 状態の接続のために、もしクライアントが接続のエンドを終了したら、接続状態構造は割当解除されレシーバは最終認識を送るようとTIME WAITでの接続をマークするようをいわれる。
【０１３５】
CLOSING状態での接続の場合、もしクライアントがサーバーデータの全ての認識を持ってたら 接続状態データ構造を割当解除し、レシーバはTIME WAIT に接続のマークをするよういわれる。TCP機能によれば、データが転送されたとき、タイマーが始動する。もしタイマーがクライアントによるデータ転送前に消えたら適当なレスポンダは必要なデータを再転送するよう指示される。認識の時間切れとTCPリセットメッセイジは接続の終了される原因となる。
【０１３６】
サンダー OS での分散されたTCP /IP実施例
分散型TCP/IP実行のサンダー OS実施例は複数のメンバによるもので彼らが使用しているIPアドレスの強調的サービスのための外部ネットワークインターフェースを許容する。特にTCP/IP状態マシーンは一つのレシーバと一つまたは複数のレスポンダ(好ましくは一つもしくは複数のディスパッチャ)にわたって供給される。それでIPアドレスはレシーバと一つまたは多くのレスポンダ(好ましくは一つもしくは複数のディスパッチャ)によりサービスされる。複数のレスポンダの存在は彼らの使用している外部ネットワークインターフェースと共に、単一外部ネットワークの容量を伸ばすためにあるレートでのデータ転送のために分散型TCP/IPの実行のサンダー OS の実例を行う。サーバに対する追加のレスポンダはサービスまたは決められたIPアドレスで管理されたサービスのデータを転送してサーバの容量を増加させる。
【０１３７】
他の分散型TCP/IP実施例
分散型TCP/IP実施の他の実施例は図 13に示されている。フェデレイテッド OSは必要としていないが一つまたは複数のCPUの1305と単体コンピュータ1302、外部ネットワークインターフェース1310a-1310e、オペレーティングシステムで実施されている。この例では、ひとつまたは複数のレシーバ1315、ディスパッチャ 1320、レスポンダ1325がコンピュータ上の処理またはスレッド実行が実現される。なぜならば、これらのコンピュータ上の処理またはスレッド実行は内部ネットワークの必要性なしで互いに通信ができるからである。この通信は共有メモリ、メッセージ待ち行列、他の処理間またはスレッド間通信方法の分担を通じて可能になる。この実施例のレシーバ、ディスパッチャ、レスポンダ処理またはスレッドは供給されたTCP/IPの実行のサンダー OSの実施で描かれたメンバのレシーバ、ディスパッチャ、レスポンダメンバと近い性能である。これらのサーバの初期化の方法、異なった実施の要求のための応答の方法はサンダー OS実施の類似的に実行される。特に、単一IPアドレスのサービスはレシーバ処理またはスレッド、一つまたは複数のディスパッチャ処理、一つまたは複数のレスポンダ処理またはスレッドにわたって分散される。確かな外部ネットワークインターフェースはレシーバ処理またはスレッドに連結されている。一つまたは複数のの外部ネットワークインターフェースは各レスポンダに連結されている。強調して、これらのプロセッサまたはスレッドはそれらの確実な外部ネットワークインターフェースとともに、一つまたは複数のIPアドレスのためのサービスを提供する。単一IPアドレスのサービスは単一外部ネットワークインターフェースによって提供されないが、複数の外部ネットワークインターフェースの中で提供される。単一レシーバは一つまたは複数のIPアドレスをサービスできる。望ましくはレシーバは単一外部ネットワークインターフェースに連結されていし、複数外部ネットワークインターフェースは単一レシーバに連結される。
【０１３８】
分散型TCP/IP実行の実施例の過程の変化はフェデレイテッド OS を要求しないが複数のコンピュータで実行され得る。各コンピュータはオペレーティングシステムがあってもなくても動作可能である。各コンピュータに、内部インターフェースと外部インターフェースは共有された単一インターフェースではないが、分離された明確なインターフェースである。 この実施例は一つまたは複数のレシーバ、一つまたは複数のディスパッチャ、一つまたは複数のレスポンダが各コンピュータの処理またはスレッドの制作として実行される。これらの処理またはスレッドはインターネットネットワークを使用して自身のなかで通信する。内部ネットワークは有線、無線、光、その他のネットワークシステムになり得る。これらは例えばコンピュータ、Ethernet, Gigabit Ethernet, Token Ring, Fibre Channel, InfiniBand などに接続できる。実施例のレシーバ、ディスパッチャ、レスポンダプロセッサまたはスレッドは、同様に分散型TCP/IP実行のサンダー OSの実施例と同様に、レシーバ、ディスパッチャ、レスポンダメンバの機能をする。これらのサーバの初期化の方法、異なった実施の要求のための応答の方法はサンダー OS実施の類似的に実行される。特に、単一IPアドレスのサービスはレシーバ処理またはスレッド、一つまたは複数のディスパッチャ処理、一つまたは複数のレスポンダ処理またはスレッドにわたって分散される。確かな外部ネットワークインターフェースはレシーバ処理またはスレッドに連結されている。一つまたは複数の外部ネットワークインターフェースは各レスポンダに連結されている。集合としてこれらのプロセッサまたはスレッドはそれらの確実な外部ネットワークインターフェースとともに一つまたは複数のIPアドレスのためのサービスを提供する。単一IPアドレスのサービスは単一外部ネットワークインターフェースによって提供されないが複数の外部ネットワークインターフェースの中で提供される。単一レシーバは一つまたは複数のIPアドレスをサービスできる。望ましくはレシーバは単一外部ネットワークインターフェースに連結されていし、複数外部ネットワークインターフェースは単一レシーバに連結される。
【０１３９】
別の分散型TCP/IP実施例には、ディスパッチャ処理またはスレッドを含む必要はない。レシーバまたはレスポンダ処理又はスレッドのディスパッチャの性能で実行できる。
【０１４０】
コンフィギュレーションの方法と動作
クライアントからの要求を処理する前に、サーバはコンフィギュレータによりコンフィギュレーションされる。コンフィギュレータによるコンフィギュレーションは自動的に行われるが、一般にはオペレータの入力へ答える形で、コンフィギュレータによりコンフィギュレーションが実行される。オペレータはコンフィギュレーションデータをマニュアルでも入れられるし、以前に保存されたコンフィギュレータをロードすることでできる。サーバに対するコンフィギュレータのローディングがオペレータを始められる。OSメンバOSインスタンスが各参加しているメンバのハードウェアユニットにロードされる。
【０１４１】
サーバのコンフィギュレーテイングの代表例は下記の通りである。
【０１４２】
レシーバ、ディスパッチャ、多くのレスポンダは明示されている。いくつかの異なった実施例では、ディスパッチャは明示されてない。ディスパッチャはレシーバ及び/またはレスポンダに機能的に実行される。これらの異なった実施例ではディスパッチャにより機能される行為を一つまたは複数のレシーバ及び/またはレスポンダにより機能する。メンバが明示されたあと、適切な実施され得るコードがこれらのメンバのハードウェアにダウンロードされ有効かされる。レシーバはどんなIPアドレスか告げられ、TCPポート番号は接続にアクセプトされる。ディスパッチャはIPのアドレス/TCPポートのペアを関連付けるサービスがどんなものかを指示される。HTTPサービスのため、ディスパッチャはどのホストの名前が要求のために承認されるか示される。応答データはレスポンダにロードされる。これは生の静的データで動的データを動かすために確立したコードを作り得る。各応答がロードされて、ディスパッチャは場所を知らされる。応答の場所をディスパッチャが知らされて直ぐに、応答に使われたデータ構造は更新される。それでサーバは次回のクライアントの要求への応答もサーブも準備できた。図 14はサーバの初期化の方法を書いてある。 図 14bは 発明の他の実施例の サーバの初期化方法が書かれている。
【０１４３】
図15は、サンダー OSの実施例において、クライアントからの要求に対するサービスを行うときの、クライアント1505と、レシーバ1510、ディスパッチャ1515、レスポンダ1520の間のデータフローを示す。クライアントとサーバの間の典型的なトランザクションは、次のように行われる。まず、クライアントは、接続の要求を開始する。接続は、クライアントとサーバのレシーバメンバの間で、複数のTCPパケットを交換することで確立する。レシーバは各パケットを受信する毎に、受信したパケットに含まれるIPアドレスとTCPポートを探索し、既存の接続と一致するかどうかを確認しなければならない。探索の実現にあたっては、トゥリーデータ構造を用いて、レシーバが維持する有効接続の数に関係なく決定的実行時間を提供することが好ましい。
【０１４４】
接続が正常に”確立”状態に達すると、クライアントは実際の要求情報を含んだデータを送信できる。レシーバは、受信データからヘッダを引き抜き、そしてペイロードを引き抜いて、そのペイロードをそのままディスパッチャに送る。HTTP要求では、データ（ペイロード）は、HTTPヘッダ（指定したURLからデータを取得しろ、という命令などを含む）を含み、さらにHTTPペイロードデータがあればそれを含む。レシーバはこのデータを含むパケットを受信すると、そのデータをディスパッチャに送信する。ディスパッチャは、新しい接続を要求するデータを受信すると、データ構造を割り当ててその接続状態を保持し、レシーバに対して識別子を返す。この識別子により、レシーバは以後のデータをこの接続にディスパッチャ上で関連づけることができる。レシーバは、受信した識別子をこの接続に関連するデータ構造内に保存する。
【０１４５】
次に、ディスパッチャは要求データを処理し、どの応答を送信するかを決定する。この処理の過程では、トゥリーデータ構造を用いて応答の正しい位置を効率的に検索することが好ましい。この検索によるデータ記録に基づき、ディスパッチャは適切なレスポンダに対してメッセージを送信し、クライアントにデータの一部を送り返すことを指示する。（クライアントが送信するいずれのTCPパケットにも、クライアントが受信準備しているデータ量と、クライアントが既に受信済みのデータが何かを示すアクノレッジメントが、情報の一部として含まれている。）レスポンダは、ディスパッチャに対して識別子を使用して応答し、この接続に関する応答の一意なインスタンスを識別する。この識別子を用いた応答は、動的なデータにとっては不可欠である。動的なデータでは、同一の要求に対して、それぞれの接続毎に返されるデータが異なる可能性があるからである。また、レスポンダはディスパッチャに対して、応答データのサイズが分かっている場合には、そのサイズを送信する。これによりディスパッチャは、全応答がいつ送信されたかを確認することができる。ディスパッチャは、応答データのサイズを使用して、次のシーケンス番号を算出する。レスポンダは、応答データをクライアントに送信する。
【０１４６】
クライアントは応答データパケットを受信すると、レシーバに対してアクノレッジメントパケットを返して、クライアントがどのようなデータを正常に受信したか、またどれだけのデータをこれから受信したいかを示す。レシーバはこのアクノレッジメントパケットを受信すると、IPアドレスとTCPポートを再び探索し、受信したパケットが既に確立されている接続に属するものであることを確認する。次にレシーバは、アクノレッジメントパケット内の必要な情報を、保存しておいたこの接続の接続識別子と共に、ディスパッチャに送信する。ディスパッチャはこのメッセージを受信すると、接続識別子を使用して、適切な接続状態情報の位置を検索する。次にディスパッチャは、アクノレッジメントの情報と保存してある接続状態情報を使用して、現在、データのどの部分を送信できるかを確認する。ディスパッチャ内のシーケンス番号は、送信したバイト数によってインクリメントされる。次にディスパッチャは、適切なレスポンダに対してメッセージを送信する。このメッセージは、前に保存した応答識別子と、どの部分のデータを送信するかを示す情報を含む。また、ディスパッチャは、タイマの保守も行う。ディスパッチャはこのタイマを使用して、適切な時間内にデータの受信が確認されなかったときには、そのデータの再送をレスポンダに要求する。クライアントは、再びこのデータを受信し、次のアクノレッジメントを送信する。
【０１４７】
このサイクルは、レスポンダが全ての応答データを送信し、クライアントがそのデータに全て肯定応答するまで続く。このとき、ディスパッチャはレシーバに対して、接続が終了することを通知する。また、ディスパッチャは、レスポンダに対しては、この接続に対する応答の一意なインスタンスが、もはや不要になったことを通知する。ディスパッチャは最後に、この接続状態の情報を含んでいるデータ構造の割り当てを解除する。接続終了の最終段階では、クライアントとレシーバの間で、さらに2、3のパケットが交換され、その後にレシーバは、接続状態の情報を含んでいるデータ構造の割り当てを解除する。エラー状態やキャンセルされた要求なども、上記に加えて処理される。図16Aは、本発明の実施例に従った、外部ネットワークを通じて受信した要求に対する応答方法のフローチャートである。図16Bは、本発明の別の実施例に従った、外部ネットワークを通じて受信した要求に対する応答方法のフローチャートである。図16Cは、本発明の別の実施例に従った、外部ネットワークを通じて受信した要求に対する応答方法のフローチャートである。図16Dは、本発明の別の実施例に従った、外部ネットワークを通じて受信した要求に対する応答方法のフローチャートである。
【０１４８】
信号保持媒体
本発明の別の点は、ここで解説したサーバまたはディジタルコンピュータシステムの実施例を実現するための、ディジタル処理機器によって実行される機械可読コードを実質的に収録する信号保持媒体である。本発明の別の点は、ここで解説した方法を実行するための、ディジタル処理機器によって実行される機械可読な命令のプログラムを実質的に収録する信号保持媒体である。この方法は、例えば、外部ネットワークを通じて受信した要求に対する応答方法、要求に対する応答方法（この要求は必ずしも外部ネットワークを通じたものでなくてもよい）、またはサーバの初期化などである。本発明の実施例では、機械可読コードはソフトウェアオブジェクトコードを有する。
【０１４９】
コードは、ひとつかそれ以上の様々な形式の信号保持媒体内に存在することがある。例えば、コードは、図17に示す光ディスク1705のような信号保持媒体内に、存在することがある。光ディスクは、どのような形式の信号保持媒体であってもよい。例えば、CD-ROMや、CD-R（CD-ROMドライブで読むことのできる、書き込み可能なCD-ROM）、CD-RW（何度も書き込むことのできるCD）、CD-E（書き込みと消去が可能なCD）、DVD（ディジタルビデオディスク）があり、典型的なのはCD-ROMであろう。あるいは、代わりに、もしくは光ディスクに加えて、信号保持媒体は次にあげるものを含むこともある。磁気記憶ディスク（フロッピーディスク）、ZIPディスク、DASD記憶装置（例えば、従来のハードドライブやRAIDアレイ）、磁気テープ、RAM、電子リードオンリメモリ（例えば、ROMや、EPROM、EEPROM）、紙のパンチカード、ディジタルやアナログの通信リンクなどの送信媒体、などである。
【０１５０】
擬似コード
下記の疑似コードで、説明されるフェデレイテッド OSのTCP/IP実施例の実現を記述する。ここにはサンダー OSと説明されるメンバクラスを含む。
【０１５１】
【表１】
【表２】
【表３】
【表４】
【表５】
【表６】
【表７】
【表８】
【表９】
【表１０】
当該技術に熟練した人にとって、請求項で定義されるこの発明の請求範囲から離れることなく、ここで説明される発明の実施例にさまざまな変更や修正を行えることができるのは明白である。
【図面の簡単な説明】
【図１Ａ】図１Ａは本発明の実施例によるもので、メンバハードウェアモジュールのブロック図である。
【図１Ｂ】図１Ｂは本発明の実施例によるもので、メンバハードウェアモジュールとバックプレーンの透視図である。
【図１Ｃ】図１Ｃは本発明の実施例によるもので、ICと回路基板の平面図である。
【図２】図２は本発明の実施例によるもので、動作環境下にある、フェデレイテッド OSを使用したサーバのブロック図である。
【図３】図3は本発明の実施例によるもので、フェデレイテッド OSを使用したサーバのブロック図である。
【図４Ａ】図４Ａは本発明の実施例によるもので、フェデレイテッド OSのいくつかのメンバ間の関係を例示する図である。
【図４Ｂ】図４Ｂは本発明の実施例によるもので、動作環境下にある、フェデレイテッド OS使用のサーバの構成部分のブロック図である。
【図５】図５は、本発明の実施例によるもので、メンバを地理的に分散した、動作環境にあるサーバのブロック図である。
【図６】図６は、本発明の実施例によるもので、いくつかのメンバがインターネットバックボーンに直接接続されている、動作環境下にあるサーバのブロック図である。
【図７】図７は、本発明の実施例によるもので、いくつかのメンバがインターネットバックボーンに直接接続されており、動作環境下にあり、遠隔のデータ蓄積のあるサーバのブロック図である。
【図８】図８は、本発明の実施例によるもので、サンダー OSを含む、フェデレイテッド OSの構成部分の図である。
【図９Ａ】図９Ａは、本発明の実施例によるもので、サンダー OSのメンバ間の関係を例示するブロック図である。
【図９Ｂ】図９Ｂは、本発明の実施例によるもので、サンダー OSのブート可能なメンバ内の機能と相互作用を例示するブロック図である。
【図９Ｃ】図９Ｃは、本発明の実施例によるもので、サンダー OS中のレシーバメンバ内の機能と相互作用を例示するブロック図である。
【図９Ｄ】図９Ｄは、本発明の実施例によるもので、サンダー OS中のディスパッチャメンバ内の機能と相互作用を例示するブロック図である。
【図９Ｅ】図９Ｅは、本発明の実施例によるもので、サンダー OS中の静的レスポンダメンバ内の機能と相互作用を例示するブロック図である。
【図９Ｆ】図９Ｆは、本発明の実施例によるもので、サンダー OS中の動的レスポンダメンバ内の機能と相互作用を例示するブロック図である。
【図１０】図10は、本発明の実施例によるもので、レシーバ、ディスパッチャおよびレスポンダの各メンバへの機能の配分を例示するブロック図である。
【図１１】図11は、本発明の実施例によるもので、レシーバのTCP接続状態マシーンの図である。
【図１２】図12は、本発明の実施例によるもので、ディスパッチャのTCP接続状態マシーンの図である。
【図１３】図13は、本発明の実施例によるもので、分散型TCP/IP計算システムを例示するブロック図である。
【図１４Ａ】図14Aは、本発明の実施例によるもので、サーバを初期化する方法を例示するフローチャートである。
【図１４Ｂ】図14Bは、本発明のもう一つの実施例によるもので、サーバを初期化する方法を例示するフローチャートである。
【図１５】図15は、本発明の実施例によるもので、クライアントの要求に応えるための、クライアント、レシーバ、ディスパッチャ、レスポンダ間のデータの流れを例示する図である。
【図１６Ａ】図16Aは、本発明の実施例によるもので、外部ネットワークを通じて受け取った要求に応えるための方法を、例示するフローチャートである。
【図１６Ｂ】図16Bは、本発明のもう一つの実施例によるもので、外部ネットワークを通じて受信した要求に応える方法を、例示したフローチャートである。
【図１６Ｃ】図１６Ｃは、本発明のもう一つの実施例によるもので、外部ネットワークを通じて受信した要求に応える方法を、例示したフローチャートである。
【図１６Ｄ】図１６Ｄは、本発明のもう一つの実施例によるもので、外部ネットワークを通じて受信した要求に応える方法を、例示したフローチャートである。
【図１７】図１７は、本発明の実施例によるもので、信号を保持する光ディスクの平面図である。
発明の背景
１． 発明の分野
本発明は、ディジタルコンピュータシステム用の分散型オペレーティングシステムに関連するものである。より具体的には、本発明は、複数のオペレーティングシステムを実行する複数のプロセッサに、サーバの状態マシーンの機能が分散している、高速サーバに関するものである。
【０００２】
２． 関連技術の説明
ワールドワイドウェブが世界のインターネットで爆発的に使われるようになったことから、より高速、より高度の信頼性を持って、大きなウェブサイトのホストとなる能力のあるサーバの必要性が、相応に生じた。例えば音声、データ、ビデオなどあらゆる形のディジタルコンテンツを、ギガビットのデータ速度（すぐテラビットのデータ速度になる）でグローバルに運ぶ光ファイバケーブルと高速のスイッチとルータを、インターネットは使っている。インターネットでは、1台のサーバがサポートしなければならない最大ユーザ数の予測が不可能で、範囲が広く、一握りのユーザから何百万のユーザに及び得、最大ユーザ数が比較的少ないローカルエリアネットワーク（LANS）と対照的である。したがい、多数のユーザをサポートでき、テラビットのデータ速度で動作できるインターネット用サーバの需要がある。
【０００３】
大型のウェブサイトを運用するための一般的な方法は、サーバファームを構築することである。サーバファームを構築することは、単一のより強力なシステムを近似するための、各種のネットワーク構成内容を持つ多数の（多分何百かの）サーバを相互接続することになる。サーバファームには専用の冷却設備および電源設備のある広いスペースが必要であるため、サーバファームを構築するのは、一般的には多額の費用が必要な仕事である。その上、サーバファームには普通保守要員が必要である。一般的に、サーバファームは複雑であり、ダウンタイムが多すぎて信頼できないのが普通である。サーバファームのもう一つの欠点は、大型でさらに大きくなるウェブサイトには、よく必要になる強力さと規模伸縮能力がない点である。
【０００４】
対称型多元処理（SMP）サーバが、サーバファームに代わる既知のものである。しかし、SMPの規模伸縮能力に限界があるため、大規模ウェブサイトの必要には普通適合しない。SMPサーバとサーバファームは、ストレスが多く急成長のウェブ環境を取り扱えないことが多い。たとえば、ｅコマースに必要なセキュリティ付きのトランザクションが、ＳＭＰサーバやサーバファームを、しばしば停滞させることが知られている。
【０００５】
インターネットにまたがるなど、長距離間のネットワークを形成しているコンピュータでは、クライアントとサーバ間の地理的な距離のために、反応時間が延びることが頻繁にある。クライアントの要求に応えるのに、サーバが要する時間を短縮するために、クライアントにより近い一個所または複数個所でウェブサーバを重複させることがある。たとえば、日本のクライアントがシアトルにあるｅコマースウェブサイトのホストになっているサーバに接続しようとしたとき、ワシントン州シアトルにある主サーバでなく、東京にある副サーバに接続されてもよい。これによって、データの所在がユーザにより近くなる。しかし、重複するサーバが提供するデータ間の同一性を維持するのは難しく、とくにコンテンツの作成が動的な場合、そうである。たとえば、ある顧客があるウェブサーバのオンライン注文機能を使い、その後副サーバで注文の状況をチェックしようとしたとき、正確な情報を得るとはかぎらない。副サーバを使うとき、広告の目的で、あるウェブサイトへのヒット数を正確に追うことも困難である。
【０００６】
インターネットサーバの先行技術では、TCP/IＰの状態ダイアグラム全体を、一つのマシーンが履行する（実行する）ことが多く、その結果動作が遅くなることがしばしばある。機能をクラスタ化ソフトウェアで分散したシステムでは、分散させた機能は、オペレーティングシステム、たとえばLinuxやWindows NT、の上のレイヤにされるのが普通であり、一般的には同一の機能を果たす。したがい、計算はアプリケーションレベルで分散され、しばしば反応時間その他の難点を生じる。
【０００７】
したがって、速度、セキュリティ、信頼性、規模伸縮能力、容量、低原価の点でより優れ、設置面積、電力と冷却の必要度もより低減され、保守と運用費用も低減されたサーバの需要がある。
【０００８】
本発明の各態様は、Federated Operating System（ＴＭ）（Federated OS（ＴＭ））と呼ぶ分散型、大容量、高速のオペレーティングシステムを使用するためのサーバ、方法、ソフトウェアに関係する。（「Federated Operating System（ＴＭ）」と「Federated OS （ＴＭ）」はThunder River Technologies, Inc.の商標である。（以下、「フェデレイテッドオペレーティングシステム」及び「フェデレイテッドＯＳ」と訳す。））
【０００９】
本発明の一つの実施例は、メンバクラスに分類した複数のメンバで作成する、ウェブサーバに関するものである。メンバの種類（クラス）各個には、その機能のために最適化した独特専用のオペレーティングシステムがある。オペレーティングシステムの各クラスは独特のものであるものの、ほとんどのメンバクラスというかすべてのメンバクラスには、共通の親クラスから継承した共通の特性がある。メンバすべてのオペレーティングシステムが合わさって、フェデレイテッド オペレーティングシステムになる。一つの実施例では、少なくとも一つの受信（レシーバ）メンバ、少なくとも一つの発信（ディスパッチャ）メンバ、少なくとも一つの応答（レスポンダ）メンバがある。各メンバには、メンバ間の通信に使う内部ネットワークに結合するための、内部ネットワークインターフェースがある。内部ネットワークは、例えば一つのバックプレーン、一つのクロスバスイッチ、一つのLAN、一つのWANまたは一つの無線リンク（衛星リンクを含めてもよい）を使って作成できる。レシーバメンバとレスポンダメンバには、インターネットのような外部ネットワークに結合するための、外部ネットワークインターフェースもある。外部ネットワークも、たとえばLAN，ＷＡＮまたは無線ネットワーク（衛星リンクを含んでもよい）でよい。
【００１０】
レシーバメンバは外部ネットワークを通じて、クライアントから要求を受信し、内部ネットワークを通じてディスパッチャメンバに、要求のデータを流す。特定の接続に使われるディスパッチャメンバは、内部ネットワークを使って、情報をレスポンダメンバに送り、クライアントから要求のあったデータを、外部ネットワークを通じてクライアントに送るよう指示する。
【００１１】
メンバは、少なくとも一つのCPU、RAM、ROM、一つの内部ネットワークインターフェース、一つの外部ネットワークインターフェースを含むことが望ましい、メンバハードウェアユニットで作成することが望ましい。（別の方法として、メンバは一つのユニプロセッサまたはSMP（対称型多元処理）システム上の、別々の処理またはスレッドとして、作成することが出来る。）負荷の平均化または故障したメンバハードウェアユニットの交換のために、サーバの運転中にメンバハードウェアユニットの構成替えができるように、メンバハードウェアユニットは、どのメンバクラスとしても動作するような、構成変更が可能であることが望ましい。
【００１２】
本発明の望ましい実施例では、エントリが多数あるデータベースを検索するときでも、一定時間内に実行するアドレス、ポート、ホストの探索アルゴリズムを使う。例えば、HTTP（ハイパーテキストトランスファープロトコル）では、IP（インターネットプロトコル）アドレスとTCP（伝送制御プロトコル）ポート番号が入った大型データベースも、ホスト名が入った大型データベースも、一定時間内に検索できる。これによって、多数の接続を同時に扱っている間でも、サーバはリアルタイムで動作できる。
【００１３】
同じ外筐内に異なるメンバを設置することも、メンバを短距離または長距離はなして分けることもできる。例えば、レシーバメンバとディスパッチャメンバをワシントン州シアトルに設置し、日本のクライアントに早く応答するよう、同じサーバのレスポンダメンバを日本の東京に設置することもできる。
【００１４】
本発明は、速度、容量、信頼性、規模伸縮性、性能、安全性、管理の容易さの各面での改善という、多くの有利さをユーザに提供する。フェデレイテッド OSを使用したサーバは、暗号化・復号化（例えばｅコマースに使うシキュアソケットレイヤ（SSL）トランザクション）を含む、極度に大量のウェブトラフィックを扱えるように、性能劣化なしに大規模化できる。さらに、フェデレイテッド OSを実施したサーバは、特別の電力と冷却設備を必要とせず、小型の外筐に収納でき、簡単な訓練を受けた技能者一名が操作卓を使って、管理および構成を行うことが出来る。本発明は、以下の説明から明白な、他の有利さと有益性も提供する。
【００１５】
望ましい実施の詳細説明
定義：
分散： 機能が多数のサブシステム内に分割されているというシステムの特長であり、サブシステムの各個が機能の一部を実施し、理想的には同時に動作することによって、与えられた仕事を全体としてより早く完了できる。
【００１６】
リアルタイム： 与えられた仕事を完了するのに、既知の、一定時間以上にはかからないという、システムの特長
サーバ： データの提供および(または)データの受信および(または)データの処理を行うコンピュータシステム
クライアント： サーバに要求とデータを送り、要求に応えるデータを受信する装置。クライアントは、クライアントの要求に応えて送られたのではないサーバからのデータを、受信することも出来る。
【００１７】
VME： モトロラが開発し、VMEbusの当初仕様（IEEE-1014-1987）およびVME64（ANSI/VITA1-1994）、VME64x、VME320など、その後の改訂版に定義されている、コンピュータアーキテクチャ「VERSAmodule Eurocard」を指す。
【００１８】
本書でいう「望ましい」および「望ましくは」とは、要件ではないが、含めることが望ましい要素、行動、構造、材料または特性をいう。
【００１９】
本書で使う「例えば」という用語は、例として明記された要素、行動、構造、材料または特性は要件ではなく、別の要素、行動、構造、材料または特性を使用、実行または包含できることをいう。
【００２０】
本発明のいくつかの態様の概要
本発明は以下の態様を含むが、これらに限らない。本発明の一つの態様としては、フェデレイテッド オペレーティングシステム（ＴＭ）を使ったディジタルコンピュータシステムの作成がある。本発明の他の態様としては、フェデレイテッド オペレーティングシステム（ＴＭ）を使ったサーバの作成がある。本発明の他の態様として、分散型TCP/IP状態マシーンを使ったサーバの作成がある。本発明の他の態様は外部ネットワークを通じて受信した要求に応える方法である。本発明の他の態様は（外部ネットワークを通じて受信する必要がない）要求に応える方法である。本発明の他の態様はサーバ（またはディジタルコンピュータシステム）を初期化する方法である。本発明の他の態様には、分散型サーバを作成するために、ディジタル処理装置が実行できる、機械語を実際に保持した信号保持媒体の作成がある。本発明の他の態様には、要求に応えるための方法を実行するために、ディジタル処理装置が実行できる、機械語の命令で構成されたプログラムを実際に保持した信号保持媒体の作成がある。本発明のその他の態様も本書で説明している。
【００２１】
フェデレイテッド オペレーティングシステムの概要
フェデレイテッド オペレーティングシステム（OS）は、本発明の全体的なアーキテクチャである。フェデレイテッド オペレーティングシステムは、メンバクラスに分類される複数のメンバで作成された、分散型オペレーティングシステムである。各メンバは一つのメンバクラスの一インスタンスであり、一つのノードと呼ぶことができる。各メンバクラスには、その機能のために最適化された独特の専用オペレーティングシステム（オペレーティングシステムカーネルと呼ぶことができる）がある。メンバのオペレーティングシステムが合わさって、フェデレイテッドＯＳになる。フェデレイテッド OSのメンバは、サーバの機能を実行するために協調して動作する。このように、このシステムは多数のオペレーティングシステムを統合したものであり、したがってメンバの連邦と呼ぶことが出来る。各メンバはその機能を実行するため、単独で働くことも可能だが、フェデレイテッド OSのメンバは、サーバを具現化するために、協力して働くことが望ましい。
【００２２】
各メンバにより具現化される個別のオペレーティングシステムの特性は、その特定のメンバを作成するために使われる、個別のハードウェア、ファームウェアおよび(または)ソフトウェアの組合せで決まる。このように、メンバの固有性は、ハードウェア、ファームウェアおよび(または)ソフトウェアの相違による。要件ではないが望ましくは、（構成担当のコンフィギュレータメンバを除いて）全メンバが（オブジェクト指向の継承を使って）共通の親メンバから継承した共通の特性を持つことである。他のメンバクラスがそこから由来することが望ましい親（元）メンバクラスは、内部ネットワークを通じたメンバ間の同期通信のために必要な機能を持っており、イベントで駆動される処理ループも持っていることが望ましい。
【００２３】
メンバクラスには、例えば次のクラスがある： レシーバ、ディスパッチャ、レスポンダ、コンフィギュレータ（構成担当）、ガーディアン（保護担当）、パーシステントストーレジ（持続性記憶）、システムアドミニストレータノーティファイア（システム管理者通知担当）、デコーダ、ルーティングマネージャ、およびブータブルがあり、抽象的クラスとしてプロトクラスと外部ネットワークメンバクラスが加わる。（「レスポンダ」という用語には、静的レスポンダクラスと動的レスポンダクラスが含まれる。）その他のクラスも使うことができる。異なるクラスのメンバは異なる機能を実行する。フェデレイテッド OSを使うサーバには、少なくとも一つのレシーバメンバ、少なくとも一つのディスパッチャメンバ、少なくとも一つのレスポンダメンバがあるのが望ましい（さらに他のメンバクラスのメンバが一つ以上あるのが望ましい）。別の実施例では、ディスパッチャメンバが含まれず、ディスパッチャメンバの機能は、レシーバメンバおよび(または)レスポンダメンバで行われる（かまたは、別のメンバクラスのメンバで行ってもよい）。外部ネットワークに接続される実施例には、外部ネットワークに接続されるメンバが、少なくとも一つ含まれる（望ましくは、外部ネットワークに接続される少なくとも一つのレシーバと少なくとも一つのレスポンダが含まれる）。外部ネットワークに接続されない実施例では、レシーバメンバおよび(または)レスポンダメンバを含む必要がない。サーバ中のメンバの数とサーバ中のメンバのクラスは、サーバが提供するサービス、システムにかかる負荷、人による介入その他の要素で決まる。
【００２４】
各メンバには、オペレーティングシステムを含むハードウェアおよび(または)ソフトウェアの組み合わせがあり、オペレーティングシステムは他のクラスのメンバのオペレーティングシステムとは異なる。例えば、レシーバメンバの使うオペレーティングシステムは同じだが、ディスパッチャメンバは、レシーバオペレーティングシステムとは異なるディスパッチャオペレーティングシステムを使う。フェデレイテッド OSでは、各メンバクラスの独特の特性は、オペレーティングシステムのレベルに含まれる。このように、レシーバ、ディスパッチャ、レスポンダ、その他のクラスのオペレーティングシステムは、すべてそれぞれ異なる（すべてが共通の継承特性を持っていることが望ましいが）。これが先行技術と違う所で、先行技術では分散型コンピューティングはソフトウェアをクラスタ化し、基本的に同一のサービスを提供するオペレーティングシステムの上で動作することになることが多い。既存のメンバクラスから新しいメンバクラスをクラス分けできる。新しいメンバクラスは、親になったメンバクラスの全機能を持ち、新しい機能をいくつか持つことになるだろう。例えば、動的レスポンダを静的レスポンダからクラス分けできる。図９Ａの実施例に示すとおり、動的レスポンダは親の静的レスポンダの全機能を継承し、動的データの作成に関する追加的機能を加えている。要件ではないが、望ましくは、フェデレイテッド OSはＣ++プログラム言語で作成する。これによって、メンバのオペレーティングシステムの継承系統の作成が容易になる。
【００２５】
フェデレイテッド OSはTCP/IP（伝送制御プロトコル／インターネットプロトコル）の使用に限らず、たとえばNetware、VINES、AppleTalk、DECNET、SNA、OSI、ATM、netBIOS、IP-over-SONETのような任意の通信プロトコルの使用もできる。他の通信プロトコルも使えるだろう。また、フェデレイテッド OSはパケット使用の通信システムと、通信に専用回線を使う回線方式の通信システムの両方に使える。フェデレイテッド OSは、例えば着脱可能な媒体から受け取るデータを処理するシステムのように、外部ネットワークがないシステムでも、使うことができる。説明の都合上であり、これに限定する意図はないが、本書ではTCP/IPでのフェデレイテッド OSの実施を説明することが多い。
【００２６】
使用している通信プロトコルの状態ダイアグラム全体を、一つのマシーンが実行する先行技術と異なり、フェデレイテッド OSでは、タスクが複数のメンバにあるプロセッサに分散される。したがって、フェデレイテッド OSのTCP/IPへの実施例では、TCP/IPの状態マシーンは複数のメンバに分散される。言い換えると、TCP/IPのタスクは分割され、TCP/IPの状態ダイアグラム上の状態は異なるメンバに割り当てられる。したがって、単一のIPアドレスのサービスは（同じ外筐にも、別の外筐にも設置できる）複数のメンバのネットワークインターフェースに配分される。TCP/IP以外の通信プロトコルを使う実施例では、そのプロトコルの状態マシーンもメンバ間に配分される。このようにして、応答の作成と一つまたはそれ以上のクライアントへのデータ配送は、多数のメンバが並行して処理する。TCP/IPへの実施例では、多数のIPアドレスをサポートする能力を限定するのは、一般には、利用できるメモリの量だけである。このことから、何百万以上のIPアドレスをサポートする規模にすることができる。TCP/IPへの実施例では、サポートできるTCP/IPの同時接続数も、一般的には、利用できるメモリの量だけが制約原因になる。したがって、何百万以上のTCP/IP同時接続をサポートする規模にできる。このようにして、TCP/IPへの実施では、例えば同時に接続された何十万またはそれ以上のインターネットユーザに、大量のデータを届けることができる。
【００２７】
フェデレイテッド OSの場合、多数スレッドの分散型システムは、多数の（望ましくは）単一スレッドのメンバで実現される。フェデレイテッド OSのメンバの個々は、多数タスク処理を行わないのが普通である。（しかし、メンバの多数タスク処理は可能である。）各メンバは他のメンバと並行して働くので、フェデレイテッド OSは全体として並列処理を行う。例えば、TCP/IPへの実施例では、各メンバが特定部分のTCP/IPプロトコルを、他のメンバと並列して実行するので、フェデレイテッド OSがインターネットプロトコルの並列処理を実施する。したがって、インターネットの中核機能の処理が加速される。同様に、OSI（オープンシステムインター接続）への実施では、フェデレイテッド OSはオープンシステムインター接続（OSI）の７レイヤスタックの、異なるレイヤの並列処理を実施する。
【００２８】
フェデレイテッド OSを使ったサーバは、多くの高性能サービスに好適である。例えば、ｅコマース、ウェブのホスト、マルチメディア配信（オンデマンドのビデオとオーディオ）、特殊軍事計画、無線インフラ構造、インターネット使用のゲームなどの大規模なインターネット／イントラネット利用サービスの配備である。インターネットで使う以外に、フェデレイテッド OSは、他の方式のブロードバンド、パケット使用の公衆通信網に使うことができよう。
【００２９】
上記のように、各メンバが実現する個別のオペレーティングシステムの特性は、その特定のメンバを作成するのに使う、個別のハードウェア、ファームウェア（例えばROM）および(または)ソフトウェアの組合せによって決まる。フェデレイテッド OSのメンバは、それぞれのメンバのハードウェアユニット（ノードと呼ばれることがある）に組み込まれるが、それは色々な方法で実現できる。フェデレイテッド OSのいくつかの実施例では、各メンバ（インスタンス）は別々のハードウェアモジュールで実現される。このようにして、これらの実施例では各メンバのハードウェアユニットは、メンバハードウェアモジュールとして作成される。図1Aはメンバハードウェアモジュール105の実施例のブロック図である。メンバハードウェアモジュール105には、最低一つのCPU 110a （中央処理装置）、一つの内部ネットワークインターフェース 115、一つの外部ネットワークインターフェース 120、ランダムアクセスメモリ （RAM）125、フェデレイテッド OSカーネルの後続インスタンスをロードするのに使う、初期プログラムイメージを蓄積するための、少量の不揮発性メモリ（ROM）130を含む。メンバハードウェアユニットは、同じかまたは異なるCPU、同じかまたは異なる量のメモリ、同じかまたは異なる形式のネットワークインターフェースを使って、実現できる。メンバハードウェアユニット中の内部インターフェースと外部インターフェースは、どちらも双方向通信（データその他の信号を入出力する）用に構成されていることが望ましい。外部ネットワークとの通信に使われないメンバについては、外部ネットワークインターフェース120を設ける必要はないが、必要な場合各モジュールにレシーバかレスポンダのどちらにも機能する能力が備わるように、どのメンバハードウェアユニットも、外部ネットワークインターフェースを持つのが望ましい。内部ネットワークインターフェースは、内部ネットワークを通じてのメンバハードウェアユニット間の通信に使われ、外部ネットワークインターフェースは外部ネットワークを通じてのクライアントとの通信に使われる。希望する場合、外部ネットワークインターフェースは、ハードウェアの障害その他の障害の際、通信路を提供することによって、メンバハードウェアユニット間の内部通信にも使用できる。要件ではないが、性能を上げるために、メンバが通信をする相手のメンバにメッセージを送るのに使う、ネットワークルーティングの必要情報を、そのメンバが知っている形で、各メンバが内部ネットワークメッセージ情報を保持することが望ましい。
【００３０】
あるメンバハードウェアユニットに一つ以上のCPUがある場合、そのメンバハードウェアユニットのCPUは相互に接続されていることが望ましい。要件ではないが、各CPUがそのメンバハードウェアユニットの各ネットワークインターフェースに結合されており、RAMとROMが各CPUに結合されていることが望ましい。一つのメンバに、実際に結合できる数の任意の数のCPUを使うことができる。例えば、各メンバハードウェアユニットには、２つのCPU 110aと110bがある。
【００３１】
異種のCPUハードウェアをサポートするポータブルなソースコードを使って、フェデレイテッド OSを作成することが望ましく、そうすることで、異なるプロセッサや異なる販売業者から選択する自由が得られる。このポータブル性が、個別の機能についてメンバを最適化する助けになる。例えば、SSL（セキュアソケットレイヤ）その他のセキュリティプロトコルをサポートするために、DSP（ディジタル信号処理）に基づく暗号化／復号化エンジンを使って、メンバの作成を最適化できる。プロセッサの本来のバイト数、語の大きさなどに依存する部分は、プロセッサの種類毎に、最小限のコードモジュールにまとめることが望ましい。各CPUはどんな形式のディジタル処理装置でもよいが、各CPUは高速のディジタル処理装置であることが望ましい。あるモジュールに複数のCPUがある場合、モジュール内のCPUが同じメーカーまたは同じ機種である必要はない。CPU 110aがPowerPCで、CPU 110bがCPU 110aに使われたPowerPCと同じ、PowerPCであることが望ましい。別の方法として、CPUはテキサスインスツルメンツ製の高速ディジタル信号プロセッサ（DSP）x86プロセッサまたは（ディジタル処理装置と呼べる）どんな他のプロセッサでもよい。
【００３２】
フェデレイテッド OS中のプロセッサは、複数のプロセッサで出来た、一つの統合されたコンピュータシステムとして動作する。プロセッサの数は、２から３個から数百（またはそれ以上）になり得るが、プロセッサの数は、メンバの数とメンバを作成するに使われるプロセッサの数による。フェデレイテッド OSを使ったサーバに、プロセッサの能力を追加することは、先行技術であるUnixやNTを使ったサーバファームで一般に必要となる、大掛かりなLANとソフトウェアの構成なしに、システムにメンバハードウェアユニットを追加することによって、簡単にできる。
【００３３】
フェデレイテッド OSを一つの外筐に組み入れた独立型サーバの一例では、何列かのメンバハードウェアモジュールとそのためのバックプレーン、メンバハードウェアモジュールの列を相互接続するための一つのネットワーククロスバスイッチ、外部ネットワークインターフェースに結合したネットワークスイッチ、ネットワークスイッチ間の接続部、電力調節型DC電源、関連充電回路のある予備電池（希望ある場合）、およびデータメモリ部がある。メンバが物理的に分離されている実施例では、分割したメンバを収納している外筐は、短距離または長距離のネットワークリンクで相互に接続されており、これによって地理的に分散したシステムを実現できる。
【００３４】
サポートされるメンバハードウェアユニット（およびCPU）の数という点で、規模の伸縮ができるように、メンバハードウェアユニットの物理的なまとめ方と内部ネットワークの配置を、設計することが望ましい。例えば、図1Bで示す実施例では、メンバハードウェアモジュール105a、105bの電力消費は少なく、一列あたり普通１０から５０のモジュールである一定数のモジュールを、横並びに取り付け、いくつかの列を縦に本棚形式に積み重ねられるような形状になっている（形状比がある）。この実施例では、任意の列のモジュールは一枚のバックプレーン（例えばバックプレーン155と160）に差し込まれており、このバックプレーンは各モジュールの電源とネットワークインターフェースの接続をすべて行う。バックプレーンには一列のモジュール間のネットワーク構築に必要な相互接続部分もあり、一つ以上および追加される列との相互接続に使われる、一つ以上のネットワーク接続部165a、165bも準備している。各バックプレーンに使う相互接続部は、モジュールの多数の対が同時に通信できるような、広帯域、応答時間の短いクロスバ（「スイッチドファブリック」）であることが望ましい。多数のバックプレーンを使う実施例では、バックプレーン間のインターフェースは、モジュールを相互接続するのに使うのと同様の、スイッチドファブリックであることが望ましい。
【００３５】
メンバハードウェアユニット（およびバックプレーン）は、物理的に互いに近接させて配置しても、長距離へだてて結合させてもよい。例えば、メンバハードウェアユニットを同じ外筐に入れても、同じ建物内の別々の外筐に入れても、たとえば1キロメートル以上または何千キロメートルも離してもよい。バックプレーンを内部ネットワークの他のモジュールまたはバックプレーンに結合するリンクには、例えば約１センチから数十キロの長さの光ファイバケーブルを使え、地球の反対側まで延長することさえ可能である。いくつかのメンバハードウェアユニットを、他のメンバハードウェアユニットから遠くに配置する実施例は、セキュリティのかかったメッセージの暗号化と複合化を担当するメンバが、フェデレイテッド OSの他のモジュールから離れた、セキュリティ度の高い物理的外筐に配置されている場合である。フェデレイテッド OSは、小型の外筐内で多数（数百）のCPUを使って実施されるのが、望ましい。
【００３６】
図1Cに示す「ワンチップ上のシステム」と呼ばれる別の実施例では、一つのメンバハードウェアユニットのCPU、ネットワークインターフェース、RAM、ROMが単一の集積回路（IC）に集積されている。この実施例では、これらの要素を入れたIC 175a、175bと内部ネットワーク相互接続ハードウェアが一つの回路基板180に取り付けられている。この実施例では、回路基板を上記で説明したメンバハードウェアモジュールと同じ物理的形状にし、同じバックプレーンに差し込めるのが、望ましい。ワンチップのシステムでは、内部ネットワーク183が、基板上のCPUの全部を相互接続する。内部ネットワークインターフェース回路基板185と外部ネットワークインターフェース187回路基板は、基板の外での接続用に準備されている。この実施例の別の形では、一つ以上のICのそれぞれに、多数のメンバハードウェアユニット（CPU/ネットワークインターフェース/RAM/ROMの組合せ）があり、各ICの内部でそれらが相互に接続されており、またチップの外で、基板上の内部ネットワークおよび外部ネットワークとインターフェースしている。このように、単一のICの中に、多数のメンバハードウェアユニットが組み込まれている。また、多数のプロセッサモジュールと一つのネットワークスイッチを含む単一のチップ上に、複数のサブシステムを組み込める。
【００３７】
内部ネットワークと外部ネットワーク
上で説明したように、フェデレイテッド OSは複数のメンバを含む。図2で示すとおり、フェデレイテッド OS 205のメンバは、内部ネットワーク210を通じて、相互に通信するが、この内部ネットワークは例えばバックプレーン、クロスバスイッチネットワーク、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）または他の適切な形式の有線または無線のネットワークのどれでもよい。内部ネットワークは、広帯域で応答時間が短いのが望ましい。希望すれば、内部ネットワークを、たとえばバックプレーン内部に統合されている複数のネットワークで構成することもできる。内部ネットワークの実施例としては、VME64またはCompactPCIのようなバックプレーン、Race++、SCI（伸縮可能コヒーレントインタフェース）、Myrinetのようなクロスバスイッチネットワーク、特注専用のネットワークインターフェース、EthernetのようなLAN、SONETやATMのようなWANがある。WANにはどんな種類の高速伝送システムでも使える。内部ネットワークは、高性能のパケット通信と交換技術であるSCIで作成するのが望ましい。他の方法としては、ファイバチャネルとスカイチャネルがあり、メンバ間の通信を設定するどんな他の方法も可能性がある。内部ネットワークを、InfiniBandのような新規の相互接続標準と共に使うように、適応させることも可能だろう。各メンバの内部ネットワークインターフェース115（図１）は、内部ネットワークに結合されている。したがって、メンバのすべてが内部ネットワークに結合しており、内部ネットワークを通じて、互いに通信できる。フェデレイテッド OSを使ったサーバの別の実施例では、外部ネットワークへの接続がない。
【００３８】
例えば、着脱可能の媒体または物理的センサ、化学的センサ、光学的センサおよび(または)音響センサからデータを受け取る計算エンジンサーバは、外部ネットワークと結合する必要がない。最低一つのレシーバ225と一つのレスポンダ 220が、外部ネットワーク 215と結合しているのが望ましい。各メンバハードウェアモジュール105の内部ネットワークインターフェース115は、内部ネットワーク210に結合するためのものであり、各メンバハードウェアモジュール105の外部ネットワークインターフェース120は、外部ネットワーク215と結合するためのものである。上記のように、外部ネットワークと結合しないメンバが、外部ネットワークインターフェースを持つ必要はないが、全てのメンバが外部ネットワークインターフェースを持つことが望ましい。外部ネットワークと結合するメンバは、例えばEthernet接続部またはATMと結合できる。外部ネットワークは、任意の種類のLANおよび(または)WANでよく、任意の種類の有線または無線のネットワークでよい。フェデレイテッド OSは、インターネットのような大規模な外部ネットワークに向けて最適化してあるが、小規模のWANまたはLANとも使用できるだろう。
【００３９】
図2では、外部ネットワークに結合したメンバが、全部外部ネットワークの同じ場所に結合しているが、これは要件ではない。言い換えれば、外部ネットワークの異なる場所で、メンバを外部ネットワークに結合してもよい。また、一つまたはそれ以上のメンバの外部インターフェースを、インターネットのバックボーンへの直接接続によって、インターネットに結合してよく、これはそれぞれのネットワークインターフェースを、インターネットバックボーンの一つまたはそれ以上の主要プロバイダに、直接接続することによってできる。
【００４０】
リアルタイム、分散型及びオブジェクト志向
フェデレイテッド OSメンバ(望ましくは)は、夫々が既知の、制限された実行時間を有する固定数の割込みによってだけ、各メンバが(望ましくは)先取することができる単一タスクとして作動するが故に、リアルタイムである。フェデレイテッド OSは、サービス及びプロトコルアルゴリズム(望ましくは)がすべてリアルタイムで実行されるが故に、全体としては(望ましくは)リアルタイムである。例えば、TCP/IPの実施例において、レシーバメンバ処理は、望ましくはTCP/IP パケットをリアルタイムで受け取る。更なる事例として、TCP/IPの実施例において、IP アドレス探索及びホスト名探索は、望ましくはリアルタイムで達成される。
【００４１】
フェデレイテッド OSは、OSサービス(TCP/IPの実施例におけるTCP/IPプロトコルのように)が、メンバのOS(それは、内部ネットワーク上に結合される)中に分配され、かつ、フェデレイテッド OSが異なるメンバ間の分配機能性をサポートするが故に、分散される。
【００４２】
フェデレイテッド OSは、(望ましくは)オブジェクト志向である。その理由は、(1) メンバ(望ましくは)は、親クラスから引き出され、親クラスからの行動を受け継ぎ、そしてそのメンバは受け継いだものへと拡大する。また、(2) (望ましくは)、そのシステムはオブジェクト志向ツールで造られる、ためである。
【００４３】
リアルタイムアドレス探索及びホスト探索
TCP/IPの実施例において、HTTP(ハイパーテキスト伝送プロトコル)に対して、クライアントはIP アドレス、ポートナンバ及びホスト名を含んだ情報パケットを、そのクライアントがアクセスすることを望んでいるサーバによって準備されたサービスを定義するために、サーバに送る。同一のIPアドレスでサポートされる多数のホスト名をもつことが可能であり、逆に、単一のホスト名に符号する多数のIPアドレスをもつことも可能である。IPアドレスは、インターネットプロトコル(IP)に関連し、そのポートは、伝送制御プロトコル(TCP)に関連する、そして、ホスト名はハイパーテキスト伝送プロトコル(HTTP)に関連する。
【００４４】
一般的に、当該技術内で知られるサーバにおいて、OS及び/又はアプリケーションは、入ってくるメッセージ内のIPアドレス、TCPポート番号及びホスト名のような他のデータとの一致を検索しなければならない。入ってくるメッセージ内のIPアドレスとホスト名は、サーバにアクセス可能な夫々のデータベースに貯えられた(恐らく)膨大なIP アドレスと(恐らく)膨大なホスト名と比較される。典型的にOSのネットワーキングコードは、そのパケットが新しい接続に属するのか、又は既存の接続に属するのかを判定するために、また、データを送るべき適切なアプリケーションを判定するために、入ってくるパケットのIP アドレスとTCP ポート番号を処理する責任がある。メッセージ内の他のデータ(例えば、ホスト名)は、入ってくるパケットを処理するために、アプリケーション(例えば、HTTPウェブサーバ)によって探られる必要があるかも知れない。
【００４５】
フェデレイテッド OS(望ましくは)のTCP/IPの実施形態は、迅速にかつ決定論的に、多数のIPアドレス同士と多数のホスト名同士の一致を検索するために、その検索アルゴリズムで「トゥリー」（“Trie”）データ構造を用いる。トゥリーデータ構造を用いるアルゴリズムは、一般的に検索されるべきデータベースのサイズに拘らず同一量の検索時間を要する。このタイプのアルゴリズムは、各タイプの検索に対する検索時間が一定で、検索されるべきプールのサイズに依存しないので、決定性であるとして引用される。対照的に、先行技術のサーバは、検索されるべきプールのサイズが十分に小さい場合にだけ、決定性機能を近似するアルゴリズム(例えば、ハッシュテーブル)を典型的に用いる。このアプローチは、検索アルゴリズムによって必要とされるデータ構造を保存するために必要とされるメモリ量を最少化するために、先行技術で用いられ、限定数の同時進行セッションだけがサポートされる必要があるという仮定に基づいている。データベースに付加的アドレスが追加されると、先行技術検索法に必要とされる検索時間が一般的に増加し、その結果、先行技術システムは、一般的にリアルタイムで動作することができない。対照的に、可能ならどこでも、フェデレイテッド OSは、検索されるべきデータ構造の数によって影響されない実行時間を有するトゥリーデータ構造によるアルゴリズムを用いる。決定性検索アルゴリズムを使用する結果として、フェデレイテッド OSは、たくさんのセッションをサポートしている場合でも、それぞれの入ってくるパケットを処理するのに一定量の時間でよい。決定性アルゴリズムの使用は、フェデレイテッド OS がリアルタイムで動作することを許容する。何故なら、すべての検索が同一の固定量の短時間で完結するからであり、そして、固定量の時間がそのシステムがリアルタイムで動作することを許容するに十分に短いからである。TCP/IPの実施例において、フェデレイテッド OSは、リアルタイムTCP/IP状態マシーンを有するということができる。リアルタイム状態マシーンは、フェデレイテッド OSの非TCP/IPの実施例でもまた、実現され得る。決定性アルゴリズムの使用は、機能を著しく改善し、好ましいけれども、フェデレイテッド OSでの決定性検索アルゴリズムの使用は必要とされない。
【００４６】
好ましいTCP/IPの実施例において、フェデレイテッド OS は数百万の同時に起こるTCP/IP接続をサポートすることができ、かつ、少なくとも数千のIP アドレスの数百と、数千のホスト名の数百を機能劣化なしに、ホストすることができる。これは、デザインアプローチと用いられるアルゴリズムに依るものであり、いかに多くの他の有効接続が保持されていても、既知の量の時間で、入ってくるパケットを処理する能力の結果である。先行技術TCP/IPサーバは、これに反して、たくさんの接続を保持しようとしているとき、又は、たくさんのIP アドレスをサポートしようとしているとき、大部分のそれらの接続が使用されていないときにさえも、しばしば重要な機能劣化又は停止さえも経験する。
【００４７】
イベント/ネットワーク駆動
要求されないが、望ましくはフェデレイテッド OSは、イベント駆動/ネットワーク駆動である。言い換えれば、ネットワークプロトコル機能性は、アクティブであり、実行されるべきデータがあるときだけ、適切なサービスを実施する。(TCP/IPの実施例において、イベントは、ウェブページのハイパーリンクをユーザがクリックすることで生じるTCP/IPパケットの受信である)。対照的に、従来のサーバにおいては、データが有効になるまで、そのアプリケーションがネットワーク及びブロックからデータを読み込むように、アプリケーションがプロトコルスタックを駆動する。
【００４８】
多数の外部ネットワーク
要求されないが、フェデレイテッド OSは、一つ以上の外部ネットワークに結合されることができる。例えば、フェデレイテッド OSを実行するレシーバとサーバのレスポンダは、第一の外部ネットワークに結合されることができ、そして、他のレシーバとサーバのレスポンダは、他の外部ネットワークに結合されることができる。一つ以上の外部ネットワークに結合されるフェデレイテッド OSを実行するサーバは、異なる外部ネットワーク間のデータ伝送を防ぐために配列されることができる、又は、任意の二つの外部ネットワーク間に任意のデータを通すためのルーティング機能を実行するために、 若しくは、ファイアウォールを実行するために、二つの外部ネットワーク間にデータを選択的に通すことによって、配列されることができる。ルーティングは、ルーティングマネージャメンバ(例えば、図9A に示すようにルーティングマネージャメンバ920)で実行されることができる。同様に、ファイアウォールマネージャメンバ(例えば、図9Aに示されるファイアウォールマネージャメンバ928)は、ある外部ネットワークから他の外部ネットワークへ許容されたデータを選択的に通すのに用いられることができる。
【００４９】
防護の特徴
フェデレイテッド OS防護を増強する幾つかの特徴を有している。例えば、クライアントは外部ネットワークに接続されるが、内部ネットワークには接続されない、そして外部ネットワークは、クライアントへの及びクライアントからのデータを伝送するためにだけ用いられる。"サービス拒否"攻撃は、入ってくるパケットをネットワーク速度で処理するメンバの能力によって緩和される(望ましい実施例において)。望ましくは、すべてのクライアントデータは、安全なコンテナオブジェクトを経由して通され、かつ、境界線チェックが強制され、それによってバッファオーバフロー攻撃を緩和する。また、暗号化/復号化が、物理的に安全な場所に地理的に分離されたメンバに委任されることができる。ファイアウォール保護は、例えば、多数の外部ネットワークに結合されるシステムの防護を装備するために、容易に実現されることができる。
【００５０】
メンバクラス
上に述べたように、各メンバクラスは、特定の機能のために最適化された明確な専用のOSを有している。例えば、各レシーバメンバはレシーバOSを有し、各ディスパッチャメンバはディスパッチャOSを有し、各レスポンダメンバはレスポンダOSを有している。異なるメンバクラスは、プロトクラスとして引用される親クラスの異なる一意なサブクラスである。例外は、コンフィギュレータクラスであり、それは、プロトクラスのサブクラスであっても、そうでなくてもよい。メンバクラスの事例は、レシーバ225、ディスパッチャ230、レスポンダ220、コンフィギュレータ235、ガーディアン240、持続性ストレージ245、システムアドミニストレータノーティファイア250、デコーダ255及びブータブルクラスに加えて、ルーティングマネージャ260クラス (図2に図解されている)である。付加的に、メンバとして実行されないアブストラクトクラスであるが、メンバに対する親クラスであるプロトメンバ及び外部ネットワークメンバクラスがある。フェデレイテッド OSを実現するサーバの一つの説明的実施例は、一つのレシーバメンバ、一つのディスパッチャメンバ及び八つのレスポンダメンバ(そして、望ましくはガーディアンメンバをも含む)を含む。フェデレイテッド OSは、メンバが希望によって付加又は削除され得る意味で拡張性がある。たくさんのレスポンダ、例えば400のレスポンダを含むことが可能であり、かつ、より多くのレスポンダでさえも用いられ得る。各レスポンダが、例えば、毎秒2.5ギガバイトでデータを伝送するならば、 そして、例えば、レスポンダが400あるならば、フェデレイテッド OSは、１テラビット(毎秒240 ビット)のデータを配信する能力を有するであろう。各レスポンダは、例えば、毎秒2.5ギガビットでデータを伝送するためOC-48接続に結合され得る。
【００５１】
要求されないけれども、望ましくは、どのメンバハードウェアユニットも、任意の非アブストラクトメンバの機能を実現するために、作動中("進行中")に劇的に再構成される能力を有する。換言すれば、メンバのCPUは、望ましくは、任意のメンバの機能を劇的に割り付けられることができる。例えば、もしディスパッチャが動作不能になったなら、例えばレスポンダ又はレシーバが、ディスパッチャとして機能するために、サーバの作動中に劇的に再構成され得よう。この能力はまた、動的負荷バランスを許容する。動的に再構成するメンバハードウェアユニットは、サービスロスなしに障害回復を許容する。このように、フェデレイテッド OS を実現するサーバは、故障メンバハードウェアユニット(又は、故障メンバIC)から離れたサービスを再配置することができる耐障害分散システムである。
【００５２】
望ましくは、すべてのメンバは、望ましくはプロトメンバから引き出されるブータブルメンバから引き出される。その代わりに、メンバは、 他のメンバから引き出されることなしに実現されることができる。その場合、そのようなメンバは、メンバ内通信機能性を実現しなければならない。
【００５３】
メンバクラスは、次のように記述される。
【００５４】
- レシーバメンバ:
望ましくは、一つ以上のレシーバがフェデレイテッド OSに含まれる。
【００５５】
本節では"レシーバ"の用語で記述しているが、一つ以上のレシーバがあり得る。
【００５６】
望ましくは、レシーバは、外部ネットワークメンバから引き出される。
【００５７】
レシーバを含む実施例において、レシーバは外部ネットワークに結合される。
【００５８】
レシーバは、クライアント接続マネージメントを扱う。例えば、 クライアントからの接続要求に呼応して、レシーバは、クライアントとサーバとの間の接続を確立する。例えば、TCP/IPの実施例において、レシーバは、クライアントとTCP接続を確立する。接続の確立は通常、クライアントデータの伝送を伴わない。
【００５９】
レシーバは、望ましくは、遠隔クライアントが伝送できる特定のサーバのネットワークインターフェースだけである。
【００６０】
レシーバは、外部ネットワークによってデータを受信したり、又は送信したりできる。しかし、TCP/IPの実施例において、レシーバは、一般にヘッダデータ、例えば、接続を確立するためにハンドシェークだけを伝送する。
【００６１】
レシーバとディスパッチャを含む実施例において、一旦クライアントとサーバとの間に接続が確立され、かつ、データが受信されたら、 レシーバはディスパッチャにデータを手渡す。例えば、TCP/IPの実施例において、データはHTTP要求であろう。
【００６２】
TCP/IPの実施例において、レシーバはIPとTCPを処理し、 そして、望ましくは、ARP(アドレス分析プロトコル)及びICMP(インターネットコントロールメッセージプロトコル)もまた処理する。
【００６３】
TCP/IPの実施例において、要求されないけれども、レシーバは、望ましくは、部分的TCP/IP状態マシーンだけを有する。
【００６４】
TCP/IPの実施例において、レシーバは、望ましくは、IP断片再組成を管理する。
【００６５】
TCP/IPの実施例において、レシーバは、望ましくは、幾つかのTCP状態情報を保持する。
【００６６】
- ディスパッチャメンバ:
望ましくは、一つ以上のディスパッチャがフェデレイテッド OSに含まれる。
【００６７】
本節で"ディスパッチャ"の用語が記述されているが、一つ以上の ディスパッチャがあり得る。
【００６８】
防護を増強するディスパッチャ外部ネットワークに結合される必要はない。
【００６９】
ディスパッチャは、望ましくは、例えば、各クライアント要求に応答するためにどのレスポンダを割り付けるかを判定し、資源配分を管理する。要求に応答するために必要とされるデータは、一つ以上のレスポンダにわたって拡大されることができる。
【００７０】
TCP/IPの実施例において、ディスパッチャは、望ましくは、有効接続管理と、例えば、HTTPセッションマネージメント、メールセッションマネージメント及びFTPを含むサービス管理を実現する。
【００７１】
TCP/IPの実施例において、ディスパッチャは、データを伝送することが許される状態にある接続を処理する。ディスパッチャは、望ましくは、ディスパッチャが処理している各接続状態の記録を保持する。 状態情報には、フェデレイテッド OS(例えば、どのレスポンダと応答識別子が与えられた接続に関与しているか)によって要求される情報はもとより、 TCP仕様(例えば、シーケンスナンバ)によって要求される項目を含む。例えば、接続は特定のサービスに関係し、サービスコードは、接続のレスポンスオブジェクトに関係する。応答識別子は、レスポンスオブジェクトを識別するディスパッチャ内に保存される状態情報であり、かつ、例えば、ディスパッチャが、レスポンダが正しい応答情報を識別することを許容するレスポンダに手渡す指標として有用な整数である。接続に関する他の状態情報は、望ましくは、他のメンバによって保持される。
【００７２】
- レスポンダメンバ:
望ましくは、一つ以上のレスポンダがフェデレイテッド OSに含まれる。
【００７３】
本節では、時には"レスポンダ"の用語で記述しているけれども、一つ以上のレスポンダがあり得、望ましくは、サーバに多くのレスポンダがある。
【００７４】
望ましくは、レスポンダは外部ネットワークメンバから引き出される。
【００７５】
レスポンダを含む実施例において、レスポンダは、外部ネットワークに結合される。
【００７６】
レスポンダは、データを伝送する。
【００７７】
レスポンダは、望ましくは、静的データを管理し、伝送することができ、及び/又は動的データを作成、管理及び伝送することができる。
【００７８】
レスポンダは、特定のクライアントに要求されるデータを送る機能を遂行する。
【００７９】
TCP/IPの実施例において、レスポンダは、HTTP データ、メールデータ及び／又は他のサービスのためのデータを伝送する。
【００８０】
要求されていないけれども、望ましくは、少なくとも一つのフェデレイテッド OSのメンバは、非リアルタイムレイヤを含む。例えば、レスポンダは、非リアルタイムプログラム(例えば Java)を走らすために、非リアルタイムレイヤを含むことができる。望ましくは、非リアルタイムレイヤはLinuxである。その代わりに、非リアルタイムレイヤは、FreeBSD、又はOpenBSDのようなオープンソース非リアルタイムレイヤ 、若しくは、AIX又はSolarisのような非オープンソース非リアルタイムレイヤ、あるいは、任意の他のオープンソース又は非オープンソース非リアルタイムレイヤであり得る。フェデレイテッド OSは、非リアルタイムレイヤへのインターフェースがなくても、オペレーショナルサーバを実行するために用いられることができるが、その場合には、サーバは非リアルタイムプログラムを走らせることはできない。非リアルタイムレイヤ、例えばLinuxは、 フェデレイテッド OSのメンバ上でタスクとして動作する。
【００８１】
望ましくは、レスポンダに主となる二つの動作がある: (1)レスポンダに貯えられた静的データを伝送する、及び/又は、静的データをレスポンダ上にロードする; (2)例えば、レスポンダの非リアルタイムレイヤ内で走っているJava仮想マシーン上で走っているアプリケーションにレスポンスを生成することによって、動的データ要求をサービスする。
【００８２】
TCP/IPの実施例において、望ましくは、レスポンダは、二つのグループに分割され、それは、(1) 静的レスポンダメンバ、そして、(2) 動的レスポンダメンバ、を含む。静的レスポンダメンバは、例えば、 HTTP、FTP、メール及び他のサービスのため、静的データをマネージし、そして、伝送する。
【００８３】
動的データは、フェデレイテッド OSの任意のメンバによって、リアルタイムレイヤ又は非リアルタイムレイヤのどちらかで、生成されることができる。例えば、動的レスポンダメンバは、持続性ストレージメンバ(例えば図4Bにおける持続性ストレージメンバ475)からデータを要求することができ、随意的にそのデータを他のデータ(例えば、HTTPヘッダ)と束ね、束ねたデータをクライアントに伝送することができる。他の事例において、動的レスポンダメンバは、外部データベースサーバ(例えば、図4Bにおける外部データベースサーバ485)からデータを要求することができ、随意的に、そのデータを他のデータと一緒にし、一緒にしたデータをクライアントに伝送することができる。動的レスポンダ が、非リアルタイムレイヤをもつ必要はない。もし、動的レスポンダが非リアルタイムレイヤをもつならば、次に動的レスポンダは、非リアルタイムレイヤスケジューリング、及び非リアルタイムレイヤメッセージングインタフェース(例えば、Linux又はSolarisへ)を実行する。動的レスポンダメンバは、クライアントに動的データを伝送する。望ましくは、動的レスポンダメンバは、静的レスポンダメンバから引き出される。
【００８４】
- コンフィギュレータメンバ:
コンフィギュレータは、再構築されたフェデレイテッド OSの実施例において、必要とされない。
【００８５】
本節では"コンフィギュレータ"の用語で記述されているが、サーバに一つ以上のコンフィギュレータがあることができる。しかしながら、望ましくは、サーバに只一つのコンフィギュレータがある。
【００８６】
コンフィギュレータは、オーバオールシステムコンフィグレーションをロード、修正及び保存するためにユーザインタフェースを有している。望ましくは、コンフィギュレータはまた、ユーザにそのシステムの最新構造についてシステムに問うこと、及びその動作を監視することを許容する。望ましくは、コンフィギュレータは、言語を中立に符号化し、おびただしい言語(例えば、英語、日本語、ドイツ語など)がユーザインタフェースで完全にサポートされる。望ましくは、ユーザインタフェースは、グラフィカルユーザインタフェースで、それが、モニタ、マウス及びキーボードなどと一緒に用いられる。
【００８７】
図3に示すように、フェデレイテッド OSを実現するサーバ300の一つの説明的実施例は、メンバハードウェアユニットと内部ネットワーク(例えば、図2に示すメンバハードウェアモジュール及び内部ネットワーク)を含むサーバハウジング305を含む。サーバは一つ以上の場所で、外部ネットワークに結合される。このサーバの説明的実施例は、望ましくは、コンフィギュレータメンバに結合されるモニタ310、マウス315及びキーボード320をも含んでいる。
【００８８】
TCP/IPの実施例のHTTPサービスにおいて、システムコンフィグレーションは、IP アドレス及びリスンするTCPポートのようなアイテムを含む。コンフィギュレータは、全体システムの集中化したコンフィグレーションを提供し、それは、TCP/IPの実施例において、望ましくは、例えば、HTTPサービス、FTPサービス、IMAP eメールサービス及びPOP3 eメールサービスのような、すべてのコアインターネットサービスを含む。
【００８９】
システムを構築するとき、コンフィギュレータは、他のメンバに符号を伝送するか、又は、他のメンバに符号の位置、（それは、与えられたコンフィグレーションに必要とされる特定のメンバのクラスの場合になるために、他のメンバが作動する）を通知する。このコードは、ROM、持続性ストレージメンバ、又は他のストレージデバイスに保存することができる。
【００９０】
コンフィギュレータメンバは、コンフィギュレータメンバがサーバのリアルタイム動作に参画する必要がないが故に、プロトメンバのサブクラスでなければならなくはない。望ましくは、コンフィギュレータは、プロトメンバのサブクラスでなく、かつ、リアルタイムメンバでもない。もし、コンフィギュレータがプロトメンバのサブクラスとして実現されないならば,コンフィギュレータメンバは、コンフィギュレータメンバがリアルタイムメンバと交信できるように、依然としてプロトメンバと同じメッセージングプロトコルを実現しなければならない。コンフィギュレータは、例えば、非リアルタイムOS(例えば、MacOS又はLinux)上の標準処理として、サーバの内部ネットワークと交信することを必要とするデバイスドライバと共に、実現されてよい。
【００９１】
- ガーディアンメンバ:
一つ以上のガーディアンメンバがフェデレイテッド OSに随意的に含まれてもよい。
【００９２】
本節では"ガーディアン"の用語で記述されているが、一つ以上のガーディアンがあり得る。
【００９３】
ガーディアンメンバは、他のメンバに周期的質問を発することによってはもとより、他のメンバから周期的なステータスメッセージを受け取ることによって、システムのヘルスを監視する。それ故に、ガーディアンは、周期的に、例えば、毎秒１回(又は他の任意の時間周期)、内部ネットワークでメンバからデータを受け取る。望ましくは、ガーディアンは、ハードウェア、ソフトウェアの双方を監視する。システムは、一つ以上のガーディアンが一つ以上の他のガーディアンを監視するように構成することができる。
【００９４】
ガーディアンを介して、サーバは、機能不全メンバを検出し、それぞれ個々の機能不全メンバの機能を実現するために、他のメンバハードウェアユニットを割り付けることによって、機能不全メンバと作動中のシステムを動的に再構築することができる。ガーディアンは、未達メンバが責任を負っていたデータを、未達メンバと同じクラスの他のメンバのハードウェアユニットにロードすることによって、かつ次にその変更をメンバに通知することによって、これを達成することができる。例えば、未達レスポンダの未達レスポンスデータは、他のレスポンダ上にロードされ、影響を受けるディスパッチャは、影響を受けた応答の新しい位置を知らされる。未達メンバと同じクラスの他のメンバがまったくないか、又は、既存のメンバが再配置された機能性を受け入れることができないならば、既存メンバのクラスは、既存のメンバハードウェアユニット(それは、依然として他のメンバのハードウェアユニットへそのメンバの機能性を再配置することを要するかも知れない)を再スタートさせることによって、未達メンバのクラスに変更されてよい。このように、アーキテクチャは自己監視であり、自己治療的である。
【００９５】
もしCPUが損傷したら、その損傷はガーディアンによって検出され、そして、未達メンバタスクが他のメンバの他のプロセッサに明白に再配置され、かつ、他のメンバへの警告が内部ネットワーク上に公表される。メンバ内のCPUは損傷していないが、メンバ内の内部通信チャネル がハードウェア又はソフトウェア損傷のために利用できないならば、望ましくは、未達メンバは自動的にいかなるサービスロスもなしに、メッセージを再ルートする。これが可能でないならば、損傷はガーディアンによって検出され、CPU損傷の場合のように回復が進むであろう。
【００９６】
負荷バランス: フェデレイテッド OS のアーキテクチャは、その負荷が本質的にメンバ内に分配されるが故に、本質的に負荷バランスを実行する。例えば、TCP/IPの実施例において、TCP/IP状態マシーンは、複数のメンバ内で分配される。望ましくは、フェデレイテッド OSもまた、変化するユーザ要求に合わせるために動的に資源を割り付けるための、 インテリジェント負荷バランスを含む。動的負荷バランスは、例えば、ディスパッチャが最も軽い負荷であると判定するレスポンダにディスパッチャ割付タスクをもたすことによって、実現されることができる。その代わりに、又は、ディスパッチャによって制御される動的負荷バランスに加えて、動的負荷バランスは、レスポンダに、いつそれらが利用中であるかを判定させることによって、実現されることができる。ディスパッチャ及び/又はレスポンダが、一つ以上のレスポンダが軽い負荷であると判定するとき、二つ以上のレスポンダの機能性は、より少数のレスポンダ (未達のメンバを回復するのに用いられる方法に類似した方法で)に統合することができる。結果的に未使用メンバのクラスは、より大きな負荷を経験しているメンバクラスのメンバとして、例えば、レシーバ、未使用メンバを再スタートさせることによって変更することができる。静的負荷バランスは、データをレスポンダ間に分割することによって単純に実現することができる。負荷バランスに対する他のアプローチは、地理的アルゴリズムであり、それでは、要求しているクライアントに地理的に最も近いレスポンダが選択される。更に負荷バランスに対する他のアプローチは、ネットワークトポロジアルゴリズムであり、それでは、ネットワークトポロジの用語でクライアントに一番近いレスポンダが選択される。レスポンダの負荷は、各レスポンダの能力に基づいて分配することもできる。例えば、暗号化能力を要するレスポンダは、暗号化能力を有するレスポンダに割り付けられる。負荷バランスは、自動化されることができるか、又は人間の介在を必要とすることができる。
【００９７】
- 持続性ストレージメンバ:
一つ以上の持続性ストレージメンバが随意的にフェデレイテッド OSに含まれるてもよい。持続性ストレージメンバは、その他のメンバクラスに関して一意であり、一つ以上のデータ蓄積デバイスへの直接インターフェースを有する。したがって、持続性ストレージメンバを実現するのに用いられるハードウェアは、一つ以上のデータ蓄積デバイスに結合するためのインターフェースをもたなければならない。持続性ストレージメンバは、他のメンバへの及び他のメンバからの生データを取り扱うことに対し責任がある。これは、メンバのプロセッサが大量のストレージ、好ましくは、テラバイトの高速(毎秒ギガビット)冗長ファイバチャネルRAID(Redundant Array of Independent Disks)ストレージ、を共有するのを許容する。他のいかなるタイプ及びサイズのストレージ、例えば、従来のハードドライブ、光ディスク、ROMなどもまた用いられ得る。随意的に、持続性ストレージメンバは、メモリ常駐データベースにデータを貯えるのに用いられる大量の高速RAMを含んでよい。随意的に、持続性ストレージメンバは、ファイルシステムをエミュレートしてよい。
【００９８】
-システムアドミニストレータノーティフィアメンバ:
一つ以上のシステムアドミニストレータノーティフィアメンバがフェデレイテッド OSに随意に含まれてもよい。電源又はテレフォンサービス停止のような中断事故において、システムアドミニストレータ要員に、例えばページャー又は携帯電話によって、事故基準遠隔警報を通報する。システムアドミニストレータノーティフィアは、中断自体を検知するか、又は、他のメンバによって中断を連絡されて、それからシステムアドミニストレータノーティフィアは、中断事故を通知するために、システムアドミニストレータ要員に接触を試みる。 随意的に、システムアドミニストレータノーティフィアメンバの機能性は、ガーディアンメンバに含まれることができる。
【００９９】
- デコーダメンバ:
１つ以上のデコーダがフェデレイテッド OSに随意に含まれてもよい。
【０１００】
デコーダは、暗号化/解読又は認証機能、例えば、TCP/IPの実施例において、SSL(Secure Sockets Layer)セッション管理を扱うことに特に最適化したメンバである。デコーダメンバの一つの実例となる実施例は、与えられた接続に対し、各CPUは同時に暗号化/解読の集中的局面の演算を扱う、多数の専用化したCPU(例えばRISCプロセッサ, 又はディジタルシグナルプリセッサ)を含んでいる。
【０１０１】
-ルーティングマネージャメンバ:
一つ以上のルーティングマネージャがフェデレイテッド OSに随意に含まれてもよい。ルーティングマネージャは、アドレスルーティング表を保持している。例えば、TCP/IPの実施例において、ルーティングマネージャメンバは IPルーティング表を保持している。
【０１０２】
-ファイアウォールマネージャメンバ:
一つ以上のファイアウォールマネージャメンバが、フェデレイテッド OSに随意に含まれてもよい。ファイアウォールマネージャメンバは、どのデータが、ある外部ネットワークから他のネットワークに転送されるべきかを判定する。
【０１０３】
-プロトメンバ:
プロトメンバは、他のリアルタイムメンバクラスの親クラスである。むしろ、すべてのリアルタイムメンバクラスはプロトメンバの資産を継承する。 (上に述べたように、コンフィギュレータメンバは、プロトメンバのサブクラスである必要はない)
【０１０４】
プロトメンバクラスは、概念上のクラスである。即ち、プロトメンバだけ生成するメンバの場合があるのではなく、むしろ各リアルタイムメンバがむしろプロトメンバクラスから引き出されるサブクラスの一つの場合であるということを意味する。
【０１０５】
プロトメンバ機能性には、例えば、メモリ管理、自己ヘルス監視、メンバ間通信及びユーティリティ機能が含まれる。自己ヘルス監視は、そのメンバが そのパフォーマンスと負荷を測定する能力、及び、そのメンバを構成するハードウェア、ファームウェア及びソフトウェアコンポーネントの状態を判定することによってその"ヘルス"を判定する能力を有することを意味している。プロトメンバは、あるメンバに問題があり、その上支援を要求するときを判定する能力を含むことができる, 及び／又は、そのデータを分析し、問題があるかどうかを判定する他のメンバとデータを共有する能力を含むことができる。メンバ間通信機能性は、他のメンバからのメッセージを送り、応答する機能性である。例えば, プロトメンバは、どのクラスのメンバ、例えばレシーバ、がそうであるかをそのメンバに通知するコンフィギュレータからのメッセージに応答する機能性を含む。プロトメンバはむしろ、指定されたメンバクラスをあるメンバに割り当てる権限を与えるコードを受信し、ローディングする機能性をも含む。言い換えれば、望ましくは、どのメンバも(恐らくコンフィギュレータメンバを除き) それ自身そのOSの新しい例であるメッセージを受信する能力を有している。例えば, メッセージの内容はブータブルメンバを、例えばレシーバに変換するOSコードであり得る。上で議論したように、メンバは、他のメンバのクラス、 例えばディスパッチャにその後変換されることができる。
【０１０６】
-外部ネットワークメンバ:
外部ネットワークメンバは、むしろブータブルメンバのサブクラスであり、かつ、レシーバ及びレスポンダメンバの親クラスでもある。 外部ネットワークメンバ916の一事例を図9Aに示す。レシーバ及びレスポンダメンバは、むしろ外部ネットワークメンバから、外部ネットワークインターフェース能力及び生プロトコルサポートのような資産を受け継ぐ。TCP/IPの実施例における生プロトコルサポートの一事例は、 IP 及びTCPパケットの解剖及び生成である。外部ネットワークメンバクラスは、むしろアブストラクトクラスである。即ち、外部ネットワークメンバだけ生成するメンバの場合があるのではなく、むしろ各レシーバ及びレスポンダメンバがむしろ外部ネットワークメンバクラスから引き出されるサブクラスの場合であることを意味する。多分、各外部ネットワークインターフェース、例えばMyrinet、Ethernet及びATM、に用いられる異なる外部ネットワークメンバがある。その代わりとして、大多数の外部ネットワークインターフェースをサポートする単一の外部ネットワークメンバがある。
【０１０７】
-ブータブルメンバ:
ブータブルメンバは、プロトメンバのサブクラスである。このように、ブータブルメンバは、プロトメンバの機能性を受け継ぐ。しかしながら、ブータブルメンバは、その機能性を実現するに必要なCPU特有コードを定義しなければならない。ブータブルメンバは、フェデレイテッド OSリアルタイムメンバの骨格例である。ブータブルメンバがCPU固有コードを有するが故に、ブータブルメンバは、必ずしも同一である必要はない。このように、X86、PowerPC及びDSPプロセッサに対するブータブルメンバは、互いに異なっている。CPU固有コードは、例えば、固有バイト順及びワードサイズを含むことができる。典型的には、ブータブルメンバに対する実行形式コードは、パワーがそのメンバに与えられたとき、そのメンバがブータブルメンバの場合になるように、メンバ(ノード)のファームウェア(非揮発性メモリ)の部分である。
【０１０８】
各メンバクラスは、(あるいはコンフィギュレータクラス及び プロトクラスを除き)むしろブータブルメンバのチャイルドクラスである。ブータブルメンバは、メンバに割り当てられた指名されたメンバクラスを実現するために、実行形式コードを受信及びロードする能力を有する。換言すれば、各ブータブルメンバ又はブータブルメンバのサブクラスは、オペレーティングシステムの新しい依頼を含むメッセージを受信する能力を有する。例えば、そのメッセージは、ブータブルメンバを、例えば、レシーバに変換するため、オペレーティングシステムコードを含み得る。上に論じたように、メンバは続いてメンバの他のクラスに変換されることができる。
【０１０９】
図4A は、フェデレイテッド OSの実例となる実施例において、プロトメンバ405、ブータブルメンバ410、レシーバメンバ415、ディスパッチャメンバ420及びレスポンダメンバ425間の階層関係を図解している。図4Aは、ブータブルメンバがむしろプロトメンバの場合であり、かつ、フェデレイテッド OSのノードとして操作しているメンバクラスがむしろブータブルメンバの場合である(ブータブルメンバは同一である必要はないが)ことを図解している。図4Bは、その実施環境におけるサーバ440のブロック図であり、フェデレイテッド OSの実例となる実施例を実現している。図4Bは、レシーバ445、ディスパッチャ450、レスポンダ455、コンフィギュレータ460、ガーディアン465、デコーダ470、持続性ストレージメンバ(データサーバ)475、ガーディアン480、外部データベースサーバ485、内部ネットワーク490、 外部ネットワーク492及びクライアント495を図解している。図4Bに示す外部データベースサーバは、フェデレイテッド OSを実現するサーバの内部ネットワークに随意につなげる従来型サーバである。
【０１１０】
内部ネットワークモジュール
プロトメンバとコンフィギュレータメンバは内部ネットワークモジュールを含むことが望ましい。（例えば、図 9Aの内部ネットワークモジュール902 ）
【０１１１】
内部ネットワークモジュールは内部ネットワークにおける簡易通信に使用される、例えば、内部ネットワークインターフェース、メッセージデータ構造、メッセージプロトコルを含む。内部ネットワークモジュールは特殊なインターネットプロトコルのためのものである。例えば、内部ネットワークに使われるプロトコルにより、次のモジュールのうち一つが使われる：Myrinetなどの切替構造クロスバー、VMEやSONETなどのバスバックプレーン。
【０１１２】
内部ネットワークモジュールはメンバクラスではない。
【０１１３】
メンバの地理的分散による実施例
フェデレイテッド OSの実施例のひとつは、少なくとも一つのメンバが他のメンバと異なる地域にいることである。 フェデレイテッド OSにおいては、メンバ(またはプロセッサー)にとって、物理的に近接または接触している必要はないから 可能なことである。メンバは同一の構内や同一の部屋、同一の大陸にでさえある必要はない。言い換えると、メンバは内部ネットワークで交信できる限り、どこに散在していることも、どこにいることでもできる。例えば、内部ネットワークはバスバックプレーンよりもSONET通信方式を使用したWANによって実行できる、（SONET以外の通信方式も使用可能）例えば、一つまたは数個のレスポンダが異なった場所にいることはフェデレイテッド OSの状況よりも有効である。 例えば、レシーバとディスパッチャをワシントン州シアトルに配置したまま、日本にいるクライアントの近くにデータを置くため、レスポンダを東京に配置し、日本のクライアントからの要求に対して迅速にサービスが可能となるであろう。フェデレイテッド OSの他のメンバはデータを遠隔的に配置することができるが、他の実施例同様、この実施例でも１クライアントに１セッションということのみが要求される。このように、この実施例では、サーバ全体を複写する必要性もなく、さらに過剰なトラフィックの生成や、サイトへのヒット数の追跡困難性など、サーバ複写に伴う好ましくない結果も生じずに、レスポンダをクライアントの近くに配置することができる。
【０１１４】
このメンバ地理的分散のもう一つの実現は、同一のフェデレイテッド OSの多くのレスポンダを地球のどこにでも配置できることである。例えば、一つまたは数個のレスポンダを例えば、ニューヨーク、ロンドン、ベルリン、ホンコン、東京に配置するときに、一つ又は数個のレシーバやディスパッチャ、望ましくは他のメンバを主たる事業所、例えばワシントン州シアトルに配置することができる。例えば、百個または数百個のレスポンダを一つのフェデレイテッド OSのメンバとして世界のあらゆるところに配置することが可能である。レスポンダはサテライトにいることも可能である。
【０１１５】
内部ネットワーク 510によるSONET通信システムを使用したサーバ505のメンバ地理的分散の実施例が図5の図である。これによると一つのレスポンダ515をニューヨークに、二つのレスポンダ 520と525を東京に配置し、レスポンダ 530と残りのメンバ535をシアトルに配置する。レスポンダがシアトルにある必要はない。メンバが地理的分散になっているとき、実施例は、メンバのどれもが内部ネットワークを通して互いに通信できている限り、メンバは他のメンバとどんなに遠隔地でも配置することができる。このように、この実施例はレスポンダが他のメンバから遠くに配置されるという制限をするわけではない。例えば、一つのレシーバ、または一つのレシーバと一つのレスポンダを、フェデレイテッド OSの残りのメンバから遠くに配置することが可能である。
【０１１６】
地理的分散の実施例はインターネットアプリケーションにとって特に興味深い。というのはインターネットアプリケーションは、望ましくはフェデレイテッド OSのサンダー OS実施例により実現されるからである。
【０１１７】
直接インターネットバックボーン接続の実施例
もう一つの発明の実施例によるサーバ 605 が 図 6に示されている。これによると、一つ又は数個のレシーバ 610 と レスポンダ 615 が インターネットバックボーン620（外部ネットワーク）に直接接続されている。これによりホップの数を減少させ、スピードを早める。
【０１１８】
直接インターネットバックボーン接続と遠隔データ保存の実施例
もう一つの実施例の示されている図７は 上記の実施例として、一つまたは数個のレシーバとレスポンダがインターネットバックボーン710(外部ネットワーク) に直接接続されている。この例では、ディスパッチャ720が安全な専用接続 730を通してディスパッチャ725に接続されている。ディスパッチャ725 は SSL(Secure sockets Layer) を実行し、一つ又は数個のデコーダ735（エンコーダとデコーダ）と一つ又は数個のレスポンダ740 に接続される。レスポンダ740は外部ネットワークに接続される。レスポンダ740はデコーダ735にも接続される。ディスパッチャ725、デコーダ735、レスポンダ740はセキュアーサイト(これは典型的にレシーバ745、ディスパッチャ720、レスポンダ750と地理的に遠隔にある。)にある。例えば、銀行や会社はレスポンダ740のデータの維持管理が必要である。例えば、この実施例は インターネットを介してデータを利用したい会社または銀行が、データ保存を管理下におきながら、さらに、バックバーンに直接接続されたレシーバとレスポンダに超高速を維持しながら使用できる。この実施例では、クライアントが符号化したメッセージをレシーバ745に送る。それはレシーバからディスパッチャ720へ転送され、さらにディスパッチャ720から専用接続730を通してディスパッチャ725に送られる。さらにディスパッチャ725はメッセージをデコーダ735の一つに送る。デコーダ735はメッセージを復号化し復号化されたメッセージをディスパッチャ725に返送する。ディスパッチャ725はメッセージを要望されたレスポンダ740の一つの場所を認識しながら発送する。データはデコーダ735の一つに送られ、そこで復号化されて、レスポンダ740の一つに返送される。さらに復号化されたデータはインターネットを通じてクライアントに発送される。
【０１１９】
対称と非対称の実施例
発明のある実施例は非対称用法に関連する。発明のウェッブサーバへの応用は典型的な非対称による実施例の一つの例になる。これらの実施例は非対称に関連する。なぜならば、サーバで受信するデータの量はサーバから出力されるデータ量より通常は極端に少ないからである。(しかしながら、サーバで受信するデータ量が出力されるデータ量より多い状況では データの流れは他方向については非対称にすることは可能である。例えば、修復されない多くのメールを受信するメールサーバーにおいて。) 発明の他の実施例は、対称であるといえる。メールサーバ(ここからメールは通常回収される)は、典型的な対称の実施例のサンプルである。典型的対称の他の実施例はIPパケットがボイスデータを運んでいるような電話での実施例である。これらの実施例は対称状況にある。なぜならばサーバによって受信されたデータ量と、サーバによって出力されるデータの量がおおよそ同じである。発明の実施例では非対称と対称性能の両方が可能である。例えば、サーバが典型的なインターネットデータサーバーとして機能でき、メールサーバー及び／またはボイスデータサーバとしても機能できたときである。
【０１２０】
Thunder Operating System（ＴＭ）(Thunder OS（ＴＭ）)
(Thunder Operating System（ＴＭ） と Thunder OS（ＴＭ）はThunder River Technologies, Inc.の商標である。（以下、「サンダーオペレーティングシステム」及び「サンダーOS 」と訳す。）
【０１２１】
サンダー OS はフェデレイテッド OSの多くの実施可能例の一つであり、インターネットサーバとして満足されるフェデレイテッド OSの特有の例であり、フェデレイテッド OS の効果的実施例である。サンダー OSは分散しており、フェデレイテッドOS のスケーラブルTCP/IPの実施である。フェデレイテッド OS(サンダー OSのいろいろな実施例を含み得る)のサンダー OS 実施例では、メンバはサンダー OS を立ち上げると一緒にオペレーティングシステムを実行する。一般的フェデレイテッド OSとしては、サンダー OSで各メンバクラスがそれぞれのオペレーティングシステムを実行する。サンダー OSは分散型TCP/IP状態マシーンを含んでいる。サンダー OSはインターネット用としてとても有効なインターネットサーバーソフトとTCP/IPを統合する。サンダー OSはメンバのオペレーティングシステムの相続階層を実行させるC++プログラム言語を実行させる。速度を上げるために、サンダー OSは主なインターネットサービスとプロトコルが分散されたオペレーティングシステムの一部として直接実行されるように実行される。これらの主なインターネットソフトウエアサービスとプロトコルはつぎを含む：
【０１２２】
― HTTP(ハイパーテキストトランスファープロトコル)；
― FTP(ファイルトランスファープロトコル)；
― IMAP(インターネットメッセージアクセスプロトコル)；
― POP3(ポストオフィスプロトコル3)
加えて、これらのキーインターネットソフトウエアサービスとプロトコルに対して、TCP/IP, DNS(Domain Name Server), ARP(Address Resolution Protocol), UDP(User Datagram Protocol), ICMP(Internet Control Message Protocol) などのオペレーティングシステム によくある他の低レベルのネットワークプロトコルはサンダー OSにも含まれることが望まれる。サンダー OSはWAP(Wireless Application Protocol) , SSL(Secure Sockets Layer), 及び他のサービスやプロトコルをも含むことが望ましい。これらのサービスやプロトコルは必要な処理を配送する複数のメンバクラスを実現する配信された方式により実行される。サンダー OSでは、これらのサービスやプロトコルの実行は入ってくるネットワークパケットに関してリアルタイム行う。この方法は多くの有効な関係のサーバがメインテナンスされているにも拘わらず入ってきたパケットは時間の量を束ねてそれぞれ実行される。対称のメッセージをすることはリアルタイムデッドラインを強化することに使われ、リアルタイムのTCP/IPの状態マシーンは定時アルゴリズムで実行される。サンダー OS 805の説明的実施例が図 8 にあるが、TCP/IP(Transmission control Protocol/Internet Protocol), HTTP(Hyper Text Transfer Protocol), FTP(File Transfer Protocol), IMAP(Internet Messaging Access Protocol), DNS(Domain Name Service) などが含まれる。
【０１２３】
図8に示すように、フェデレイテッド OSのサンダー OSの実施例において、好ましくは、フェデレイテッド OSは、動的コンテンツ、例えば Java, Python, PERL,FastCGI, CGI, Smalltalk, PHP, Erlang, C++, 他、を発生するためのツールをサポートするために、指定されたプロセッサ又はメンバ上の非リアルタイムレイヤを動作させる。したがって、これらの言語または環境でかかれたオプションのエンドユーザーアプリケーションは非リアルタイムレイヤを動作させることができる。サンダー OS のメンバはリアルタイム処理が休んでいるときにはしることができる非リアルタイムシステムへのインターフェースするためのオプショナルサポートにより単一スレッドのリアルタイムの処理として実行される。非リアルタイムレイヤはマルチプルプロセッサーまた実施のスレッドでマルチタスクのサポートすることができる。非リアルタイムレイヤは望ましくはLinux kernel であり、さらにその他の非リアルタイムシステムもサポートされることができる。サンダー OS上のLinux レイヤのオペレイテイングは現存するLinux のアプリケーションが今のままで動作することを確実にする。リアルタイムのインターネットサービスやスタンダードベースのオープンインターフェースLinuxに供給することをサンダー OSで管理することで、フェデレイテッド OS の本実施例でサーバに実施することで大きな動的なウエッブサイトのための強力なプラットフォームを供給する。動的コンテンツはリアルタイムレイヤに起動されることができ、またはアプリケーションによって非リアルタイムレイヤで動作する。例えば、非リアルタイムレイヤでは、Java virtual machine がJava アプリケーションのために供給される。またPerl 翻訳はPerlで書かれたアプリケーションに供給される。これらのアプリケーションは要求への応答の動的データを作り出すが、要求したクライアントにデータを如何に返送するかを明らかにする必要はない。 図９Aはメンバとサンダー OS の関係をブロック図に書いたものである。図 9Aは内部ネットワークモジュール902、コンフィギュレータメンバ904、 プロトメンバ906、ブータブルメンバ908、持続性ストレージメンバ910、 ガーディアンメンバ912、ディスパッチャメンバ914、 外部ネットワークメンバ916、 エンコーダ/デコーダメンバ918、(デコーダメンバとしても関連している)、ルーテイングマネージングメンバ920、 レシーバメンバ922、静的レスポンダメンバ924、動的レスポンダメンバ926、ファイアウォールマネージャメンバ928が含まれている。サンダー OSは中立に符号化された言語 つまり図9Aの箱で囲ってあるコンフィギュレータメンバの904とプロトメンバ906で実行される。つまり多種多様な言語が英語に加えてサポートされる。図 9Bはサンダー OSのブータブルメンバ908 の 機能と相互作用をブロック図で示している。図 9Cはサンダー OS の レシーバメンバ922の機能と相互作用をブロック図で示している。図 9Dはサンダー OS のデイスパッチメンバ914の機能と相互作用をブロック図で示している。図 9Ｅはサンダー OS の静的レスポンダメンバ924の機能と相互作用をブロック図で示している。図 9Ｆはサンダー OS の動的レスポンダメンバ926の機能と相互作用をブロック図で示している。サンダー OS では、レスポンダメンバは静的レスポンダメンバか動的レスポンダメンバである。
【０１２４】
サンダー OS (サンダー TCPを参照) の実行としてのTCPは、TCP接続のサービス強化のためのフェデレイテッド OS の分散された性能を実現する。TCPの性能(一体となったComments(RFC) 793のためのインターネット要求) は 11の状態の状態マシーンを現す。しかしながら、ほんのわずかのこれらの状態に実際のデータ転送が含まれている。これら状態の状態はサンダー OS などの分散された実行によりTCP自体の効果を増加する。サンダー OS によるサーバの実行は必要な状態情報を維持するための接続方法を使用して分散された状態マシーンとして実行される。
【０１２５】
サンダー OS の実行の供給は図 10にあり、次のようである。 接続の創設(TCPのthree way handshake) はサービスへの依存がある。与えられたポートの番号でサービスを組み入れる知識しか要求されない。このTCP 状態マシーンの一部はレシーバ番号1005という別々の番号に効果的に分散される。このレシーバメンバは多数の接続ができ、サービス固有処理で一般的に負担を負わない。一度接続が完成したら、接続の目標はディスパッチャメンバ1010につくられ、この目標は現行のTCP ポートで組み込まれる。ディスパッチャ(1) は確認と再転送のようなTCP 機能のデータ転送部分のさまざまな機能を管理し (2)適切なサービスを要請する。サービスはディスパッチャメンバ、そして/または異なったメンバ(または複数のメンバ) に機能的に行われる。ディスパッチャメンバと少なくとも他のクラスのメンバ双方に代表的に分散される。代表的にサービスの方法としてのデータの発生と転送はレスポンダメンバにもたらされ処理と同じくらいディスパッチャメンバを休ませる。
【０１２６】
チェーンの最後はレスポンダメンバ1015である。レスポンダは発送者による最低の通信を要求する。この通信はレスポンダがどのデータが送られたか、いつデータがおくられたか、どのくらいのデータが送られたか(または時間がきれたときは再発送)を知るために場所をとる。 レスポンダは呼び出しの間、いかなる持続的状態情報も維持することは必要としない。なぜならディスパッチャは各呼び出しのレスポンダに必要な接続状態を供給するからである。複数のレスポンダメンバは特定のディスパッチャに関連づけられる。それにより許された複数の接続が平行してサービスされる。加えて、複数のディスパッチャを特定のレシーバメンバに関連付けられる。
【０１２７】
サンダー OS で、クライアントとサーバのIPアドレスおよびTCPポートを、接続目標と特定のサービスに関連付けるデータ構造を、一定区間の時間に探索できる。それは、探索できる時間が、現在の有効接続またはサービスの数から独立しているからである。探索はクライアントとサーバのIPアドレスおよびTCPポート番号により、定義された接続を関連付ける現在の接続状態情報を入れている記録をみつけることができる。ホスト探索は時間の一定区間でまたできあがる。このアプローチは慣習的TCP実行の多くの制限を消滅する。可能で有効なメモリは有効接続サポートの数の唯一の制限である。先行技術のサーバーソフトは各接続を使用するサーバ処理の分離した場合を要請することにより複数のクライアントの同時使用にしばしば使われる。従って、多くの数のクライアントが低速ネットワークインターフェースを使用して大量のシステムリソースを相対的に要求できる。実際のクライアントのサービスが接続の低いバンド幅によってつまらないものになっていてもである。一方、サンダー OSは、単一スレッドイベント駆動型アプローチを出て行くデータの発生と転送のための分散された併行実施で入ってくるパケットを管理するために使用する。このアプローチはシステムを早く十分にリアルタイムに事象(入ってくるネットワークパケット)への応答をさせる。さらに、データの複数のメンバでの発生と転送を分散することはシステムの絵をかくことができる。このアプローチはもっと大きなクライアントの数を管理するための単一サーバをつくる。
【０１２８】
状態情報
クライアントからのサービス依頼のために、各接続のための状態情報は維持されねばならない。サンダー OSでのこの状態情報はレシーバ及び/またはディスパッチャにより維持される。異なったメンバが異なった時間に状態情報の一部を維持できる。各メンバは包括的状態の一部だけを維持する。そして全体の状態はメンバの複数を交差して保存される。TCPポートは(1) クライアントからの交信のためのリスニング、または(2)接続を確立することのどちらかを性格づける。接続の不在は閉ざされた状態(本当の状態ではない)として関連し、これは状態マシーンへの加入ポイントである。図 11はレシーバTCP接続状態マシーン1105の説明図である。図 12はサンダー OSのためのディスパッチャTCP接続状態マシーン1205である。これらの状態マシーンは次章で説明される。
【０１２９】
レシーバTCP接続状態マシーン
サンダー OS の実施例のレシーバ状態マシーン1105は図 11に描かれている。クライアントにより新たな接続が創作されたとき、クライアントはTCPヘッダのSYNフラッグ設定と共にTCPパケット(パケット１)を送る。レシーバが終点IPアドレスとTCPポートと共にこれらのパケットを受けたとき、レシーバは聴くために形作られる。さらにレシーバはこの接続(起点と終点IPアドレスとTCPポート番号両者による定義づけ)のためにデータ構造をまだ配置していない。レシーバは接続のための状態情報を維持するための新しいデータ構造を創造する。レシーバ接続トゥリーデータ構造はこの新しくつくられた構造により更新される。そこで将来同じIPアドレスとTCPポートとパケットが受け取られたとき、現存のデータ構造は発見される。あたらしく作られたデータ構造はSYN RCVD状態の接続を示すために初期化される。そこでレシーバはクライアントにパケットを受けた認識を返すためにパケット(パケット２)を送る。このパケットはACKフラグと同じSYNフラグもまた持つ。同時にレシーバがパケット(パケット3)を受けたときパケット2の認識はDISPACHER RELAY 状態への移送とディスパッチャが新接続状態記録を作るための必要な情報と共にディスパッチャに送る。この交換の完成はTCPの3方向ハンドシェークとして知られている。
【０１３０】
接続がDISPATCHER RELAY状態にあるとき、レシーバで受けられたいかなるパケットからの適切なデータはディスパッチャへ単純に送られる。ディスパッチャは接続がDISPATCHER RELAY状態に残っているべきか、ＦIN WAIT２状態へ転送すべきか、終了すべきかをレシーバに連絡する。ディスパッチャはまた如何なる最終知識またはレセットがクライアントに返送されるべきか、TCP ポートがTIME WAIT 状態へのマークをすべきかをレシーバへ連絡する。FIN WAIT2 状態の接続のため、もしFINフラグが入力パケットにセットされたら、接続は終了され、ポートはTIME WAIT 状態にマークされる。従来のTCP機能において、TIME WAIT状態は状態マシーンの実質状態であることに注意すること。サンダー TCP機能では、TIME WAITは状態マシーンの外で状態マシーンが要請される前にチェックを受けたデータ構造に示される。レシーバで接続が終了されたとき、接続状態情報のために設置されたデータ構造は解放される。状態SYN RCVDと状態FIN WAIT2状態は、TCP仕様書(RFC 793)に含まれる状態図の対応状態に相当する。状態DISPATCHER RELAYは接続がディスパッチャにより操作されているひとつの状態に接続されていることを示している。すべてのデータ転送はこの状態で起こり、レシーバは状態の接続のための非常に小さい処理を行うことを必要とする。サーバーサービスのため、これらのHTTPはクライアントへの接続を消さないし、SYN SENTの追加の状態は使用されない。
【０１３１】
ディスパッチャTCP接続状態マシーン
サンダー OS の実施例のディスパッチャ状態マシーン1205は図12に示めされている。ディスパッチャがレシーバから新しい接続状態を受けたときに、接続状態情報を維持するため新しいデータ構造をつくる。そしてレシーバへつくられた構造の識別子を返送する。この識別子は接続とともに将来のメッセージをつくるためにレシーバにより使用される。接続の状態はESTABLISHEDにセットされ状態に初期化された接続のためとして継続して進行される。
【０１３２】
ESTABLISHEDまたはCLOSE WAIT 状態での接続する場合、サービス用のコードが決められる。クライアントからデータを受けたとき及びクライアントにデータを送ったときの認識にレスポンダが使用する。サービス用コードはレスポンダに応答データを送るよう指示するためのものである。クライアントに必要なTCP認識を返送することも同じである。もし応答データが直ぐになかったら、必要であれば認識だけでも送られる。クライアントに送られるデータの量はTCP認識のシークエンス番号と各TCPパケットのクライアントにより送られるウィンドウサイズで制限もされる。ESTABLISHED、FIN WAIT １ またはFIN WAIT 2状態での接続のために、クライアントから受けた如何なるデータは接続に(サービス用処理はディスパッチャ自身にも起り得るし または 他のメンバと交差して供給され得る) 関連つけたサービスに送られる。ESTABLISHED状態での接続の場合、 もしクライアントが接続の端末を終了したら、接続状態はCLOSE WAIT にセットされる。 もしサービスが接続のサーバのエンドを終了したら、状態はFIN WAIT １にセットされる。
【０１３３】
CLOSE WAIT状態に接続する場合、サービスが接続のサーバーエンドで終了されたら、状態はLAST ACKにセットされる。
【０１３４】
LAST ACK状態に接続する場合、もしクライアントが全てのサーバーデータを認識していたら、接続状態データ構造は割当解除されるし、レシーバは接続を終了すると告げられる。FIN WAIT 1の接続のためには、もしクライアントが接続のエンドを終了し 全てのサーバーデータの認識がなかったなら、状態はCLOSINGにセットされる。もしクライアントが接続のエンドを終了しサーバのデータの全てを認識していたら接続状態データ構造は割当解除されレシーバは最終認識を送りTIME WAITにあるよう接続のマークをするよう指示される。もしクライアントが接続のエンドを終了しサーバのデータのすべての認識をもっていてサービスはサーバーエンドを終了したあとのデータクライアントのデータに同意していると、状態はFIN WAIT 2 にセットされる。もしクライアントが接続のエンドを終了しサーバーデータのすべての認識を持ちサービスが接続のエンドが終了になったあとのクライアントデータに同意していないときは接続状態データ構造は割当解除されレシーバは接続状態をFIN WAIT 2にセットするよういわれる。FIN WAIT 2 状態の接続のために、もしクライアントが接続のエンドを終了したら、接続状態構造は割当解除されレシーバは最終認識を送るようとTIME WAITでの接続をマークするようをいわれる。
【０１３５】
CLOSING状態での接続の場合、もしクライアントがサーバーデータの全ての認識を持ってたら 接続状態データ構造を割当解除し、レシーバはTIME WAIT に接続のマークをするよういわれる。TCP機能によれば、データが転送されたとき、タイマーが始動する。もしタイマーがクライアントによるデータ転送前に消えたら適当なレスポンダは必要なデータを再転送するよう指示される。認識の時間切れとTCPリセットメッセイジは接続の終了される原因となる。
【０１３６】
サンダー OS での分散されたTCP /IP実施例
分散型TCP/IP実行のサンダー OS実施例は複数のメンバによるもので彼らが使用しているIPアドレスの強調的サービスのための外部ネットワークインターフェースを許容する。特にTCP/IP状態マシーンは一つのレシーバと一つまたは複数のレスポンダ(好ましくは一つもしくは複数のディスパッチャ)にわたって供給される。それでIPアドレスはレシーバと一つまたは多くのレスポンダ(好ましくは一つもしくは複数のディスパッチャ)によりサービスされる。複数のレスポンダの存在は彼らの使用している外部ネットワークインターフェースと共に、単一外部ネットワークの容量を伸ばすためにあるレートでのデータ転送のために分散型TCP/IPの実行のサンダー OS の実例を行う。サーバに対する追加のレスポンダはサービスまたは決められたIPアドレスで管理されたサービスのデータを転送してサーバの容量を増加させる。
【０１３７】
他の分散型TCP/IP実施例
分散型TCP/IP実施の他の実施例は図 13に示されている。フェデレイテッド OSは必要としていないが一つまたは複数のCPUの1305と単体コンピュータ1302、外部ネットワークインターフェース1310a-1310e、オペレーティングシステムで実施されている。この例では、ひとつまたは複数のレシーバ1315、ディスパッチャ 1320、レスポンダ1325がコンピュータ上の処理またはスレッド実行が実現される。なぜならば、これらのコンピュータ上の処理またはスレッド実行は内部ネットワークの必要性なしで互いに通信ができるからである。この通信は共有メモリ、メッセージ待ち行列、他の処理間またはスレッド間通信方法の分担を通じて可能になる。この実施例のレシーバ、ディスパッチャ、レスポンダ処理またはスレッドは供給されたTCP/IPの実行のサンダー OSの実施で描かれたメンバのレシーバ、ディスパッチャ、レスポンダメンバと近い性能である。これらのサーバの初期化の方法、異なった実施の要求のための応答の方法はサンダー OS実施の類似的に実行される。特に、単一IPアドレスのサービスはレシーバ処理またはスレッド、一つまたは複数のディスパッチャ処理、一つまたは複数のレスポンダ処理またはスレッドにわたって分散される。確かな外部ネットワークインターフェースはレシーバ処理またはスレッドに連結されている。一つまたは複数のの外部ネットワークインターフェースは各レスポンダに連結されている。強調して、これらのプロセッサまたはスレッドはそれらの確実な外部ネットワークインターフェースとともに、一つまたは複数のIPアドレスのためのサービスを提供する。単一IPアドレスのサービスは単一外部ネットワークインターフェースによって提供されないが、複数の外部ネットワークインターフェースの中で提供される。単一レシーバは一つまたは複数のIPアドレスをサービスできる。望ましくはレシーバは単一外部ネットワークインターフェースに連結されていし、複数外部ネットワークインターフェースは単一レシーバに連結される。
【０１３８】
分散型TCP/IP実行の実施例の過程の変化はフェデレイテッド OS を要求しないが複数のコンピュータで実行され得る。各コンピュータはオペレーティングシステムがあってもなくても動作可能である。各コンピュータに、内部インターフェースと外部インターフェースは共有された単一インターフェースではないが、分離された明確なインターフェースである。 この実施例は一つまたは複数のレシーバ、一つまたは複数のディスパッチャ、一つまたは複数のレスポンダが各コンピュータの処理またはスレッドの制作として実行される。これらの処理またはスレッドはインターネットネットワークを使用して自身のなかで通信する。内部ネットワークは有線、無線、光、その他のネットワークシステムになり得る。これらは例えばコンピュータ、Ethernet, Gigabit Ethernet, Token Ring, Fibre Channel, InfiniBand などに接続できる。実施例のレシーバ、ディスパッチャ、レスポンダプロセッサまたはスレッドは、同様に分散型TCP/IP実行のサンダー OSの実施例と同様に、レシーバ、ディスパッチャ、レスポンダメンバの機能をする。これらのサーバの初期化の方法、異なった実施の要求のための応答の方法はサンダー OS実施の類似的に実行される。特に、単一IPアドレスのサービスはレシーバ処理またはスレッド、一つまたは複数のディスパッチャ処理、一つまたは複数のレスポンダ処理またはスレッドにわたって分散される。確かな外部ネットワークインターフェースはレシーバ処理またはスレッドに連結されている。一つまたは複数の外部ネットワークインターフェースは各レスポンダに連結されている。集合としてこれらのプロセッサまたはスレッドはそれらの確実な外部ネットワークインターフェースとともに一つまたは複数のIPアドレスのためのサービスを提供する。単一IPアドレスのサービスは単一外部ネットワークインターフェースによって提供されないが複数の外部ネットワークインターフェースの中で提供される。単一レシーバは一つまたは複数のIPアドレスをサービスできる。望ましくはレシーバは単一外部ネットワークインターフェースに連結されていし、複数外部ネットワークインターフェースは単一レシーバに連結される。
【０１３９】
別の分散型TCP/IP実施例には、ディスパッチャ処理またはスレッドを含む必要はない。レシーバまたはレスポンダ処理又はスレッドのディスパッチャの性能で実行できる。
【０１４０】
コンフィギュレーションの方法と動作
クライアントからの要求を処理する前に、サーバはコンフィギュレータによりコンフィギュレーションされる。コンフィギュレータによるコンフィギュレーションは自動的に行われるが、一般にはオペレータの入力へ答える形で、コンフィギュレータによりコンフィギュレーションが実行される。オペレータはコンフィギュレーションデータをマニュアルでも入れられるし、以前に保存されたコンフィギュレータをロードすることでできる。サーバに対するコンフィギュレータのローディングがオペレータを始められる。OSメンバOSインスタンスが各参加しているメンバのハードウェアユニットにロードされる。
【０１４１】
サーバのコンフィギュレーテイングの代表例は下記の通りである。
【０１４２】
レシーバ、ディスパッチャ、多くのレスポンダは明示されている。いくつかの異なった実施例では、ディスパッチャは明示されてない。ディスパッチャはレシーバ及び/またはレスポンダに機能的に実行される。これらの異なった実施例ではディスパッチャにより機能される行為を一つまたは複数のレシーバ及び/またはレスポンダにより機能する。メンバが明示されたあと、適切な実施され得るコードがこれらのメンバのハードウェアにダウンロードされ有効かされる。レシーバはどんなIPアドレスか告げられ、TCPポート番号は接続にアクセプトされる。ディスパッチャはIPのアドレス/TCPポートのペアを関連付けるサービスがどんなものかを指示される。HTTPサービスのため、ディスパッチャはどのホストの名前が要求のために承認されるか示される。応答データはレスポンダにロードされる。これは生の静的データで動的データを動かすために確立したコードを作り得る。各応答がロードされて、ディスパッチャは場所を知らされる。応答の場所をディスパッチャが知らされて直ぐに、応答に使われたデータ構造は更新される。それでサーバは次回のクライアントの要求への応答もサーブも準備できた。図 14はサーバの初期化の方法を書いてある。 図 14bは 発明の他の実施例の サーバの初期化方法が書かれている。
【０１４３】
図15は、サンダー OSの実施例において、クライアントからの要求に対するサービスを行うときの、クライアント1505と、レシーバ1510、ディスパッチャ1515、レスポンダ1520の間のデータフローを示す。クライアントとサーバの間の典型的なトランザクションは、次のように行われる。まず、クライアントは、接続の要求を開始する。接続は、クライアントとサーバのレシーバメンバの間で、複数のTCPパケットを交換することで確立する。レシーバは各パケットを受信する毎に、受信したパケットに含まれるIPアドレスとTCPポートを探索し、既存の接続と一致するかどうかを確認しなければならない。探索の実現にあたっては、トゥリーデータ構造を用いて、レシーバが維持する有効接続の数に関係なく決定的実行時間を提供することが好ましい。
【０１４４】
接続が正常に”確立”状態に達すると、クライアントは実際の要求情報を含んだデータを送信できる。レシーバは、受信データからヘッダを引き抜き、そしてペイロードを引き抜いて、そのペイロードをそのままディスパッチャに送る。HTTP要求では、データ（ペイロード）は、HTTPヘッダ（指定したURLからデータを取得しろ、という命令などを含む）を含み、さらにHTTPペイロードデータがあればそれを含む。レシーバはこのデータを含むパケットを受信すると、そのデータをディスパッチャに送信する。ディスパッチャは、新しい接続を要求するデータを受信すると、データ構造を割り当ててその接続状態を保持し、レシーバに対して識別子を返す。この識別子により、レシーバは以後のデータをこの接続にディスパッチャ上で関連づけることができる。レシーバは、受信した識別子をこの接続に関連するデータ構造内に保存する。
【０１４５】
次に、ディスパッチャは要求データを処理し、どの応答を送信するかを決定する。この処理の過程では、トゥリーデータ構造を用いて応答の正しい位置を効率的に検索することが好ましい。この検索によるデータ記録に基づき、ディスパッチャは適切なレスポンダに対してメッセージを送信し、クライアントにデータの一部を送り返すことを指示する。（クライアントが送信するいずれのTCPパケットにも、クライアントが受信準備しているデータ量と、クライアントが既に受信済みのデータが何かを示すアクノレッジメントが、情報の一部として含まれている。）レスポンダは、ディスパッチャに対して識別子を使用して応答し、この接続に関する応答の一意なインスタンスを識別する。この識別子を用いた応答は、動的なデータにとっては不可欠である。動的なデータでは、同一の要求に対して、それぞれの接続毎に返されるデータが異なる可能性があるからである。また、レスポンダはディスパッチャに対して、応答データのサイズが分かっている場合には、そのサイズを送信する。これによりディスパッチャは、全応答がいつ送信されたかを確認することができる。ディスパッチャは、応答データのサイズを使用して、次のシーケンス番号を算出する。レスポンダは、応答データをクライアントに送信する。
【０１４６】
クライアントは応答データパケットを受信すると、レシーバに対してアクノレッジメントパケットを返して、クライアントがどのようなデータを正常に受信したか、またどれだけのデータをこれから受信したいかを示す。レシーバはこのアクノレッジメントパケットを受信すると、IPアドレスとTCPポートを再び探索し、受信したパケットが既に確立されている接続に属するものであることを確認する。次にレシーバは、アクノレッジメントパケット内の必要な情報を、保存しておいたこの接続の接続識別子と共に、ディスパッチャに送信する。ディスパッチャはこのメッセージを受信すると、接続識別子を使用して、適切な接続状態情報の位置を検索する。次にディスパッチャは、アクノレッジメントの情報と保存してある接続状態情報を使用して、現在、データのどの部分を送信できるかを確認する。ディスパッチャ内のシーケンス番号は、送信したバイト数によってインクリメントされる。次にディスパッチャは、適切なレスポンダに対してメッセージを送信する。このメッセージは、前に保存した応答識別子と、どの部分のデータを送信するかを示す情報を含む。また、ディスパッチャは、タイマの保守も行う。ディスパッチャはこのタイマを使用して、適切な時間内にデータの受信が確認されなかったときには、そのデータの再送をレスポンダに要求する。クライアントは、再びこのデータを受信し、次のアクノレッジメントを送信する。
【０１４７】
このサイクルは、レスポンダが全ての応答データを送信し、クライアントがそのデータに全て肯定応答するまで続く。このとき、ディスパッチャはレシーバに対して、接続が終了することを通知する。また、ディスパッチャは、レスポンダに対しては、この接続に対する応答の一意なインスタンスが、もはや不要になったことを通知する。ディスパッチャは最後に、この接続状態の情報を含んでいるデータ構造の割り当てを解除する。接続終了の最終段階では、クライアントとレシーバの間で、さらに2、3のパケットが交換され、その後にレシーバは、接続状態の情報を含んでいるデータ構造の割り当てを解除する。エラー状態やキャンセルされた要求なども、上記に加えて処理される。図16Aは、本発明の実施例に従った、外部ネットワークを通じて受信した要求に対する応答方法のフローチャートである。図16Bは、本発明の別の実施例に従った、外部ネットワークを通じて受信した要求に対する応答方法のフローチャートである。図16Cは、本発明の別の実施例に従った、外部ネットワークを通じて受信した要求に対する応答方法のフローチャートである。図16Dは、本発明の別の実施例に従った、外部ネットワークを通じて受信した要求に対する応答方法のフローチャートである。
【０１４８】
信号保持媒体
本発明の別の点は、ここで解説したサーバまたはディジタルコンピュータシステムの実施例を実現するための、ディジタル処理機器によって実行される機械可読コードを実質的に収録する信号保持媒体である。本発明の別の点は、ここで解説した方法を実行するための、ディジタル処理機器によって実行される機械可読な命令のプログラムを実質的に収録する信号保持媒体である。この方法は、例えば、外部ネットワークを通じて受信した要求に対する応答方法、要求に対する応答方法（この要求は必ずしも外部ネットワークを通じたものでなくてもよい）、またはサーバの初期化などである。本発明の実施例では、機械可読コードはソフトウェアオブジェクトコードを有する。
【０１４９】
コードは、ひとつかそれ以上の様々な形式の信号保持媒体内に存在することがある。例えば、コードは、図17に示す光ディスク1705のような信号保持媒体内に、存在することがある。光ディスクは、どのような形式の信号保持媒体であってもよい。例えば、CD-ROMや、CD-R（CD-ROMドライブで読むことのできる、書き込み可能なCD-ROM）、CD-RW（何度も書き込むことのできるCD）、CD-E（書き込みと消去が可能なCD）、DVD（ディジタルビデオディスク）があり、典型的なのはCD-ROMであろう。あるいは、代わりに、もしくは光ディスクに加えて、信号保持媒体は次にあげるものを含むこともある。磁気記憶ディスク（フロッピーディスク）、ZIPディスク、DASD記憶装置（例えば、従来のハードドライブやRAIDアレイ）、磁気テープ、RAM、電子リードオンリメモリ（例えば、ROMや、EPROM、EEPROM）、紙のパンチカード、ディジタルやアナログの通信リンクなどの送信媒体、などである。
【０１５０】
擬似コード
下記の疑似コードで、説明されるフェデレイテッド OSのTCP/IP実施例の実現を記述する。ここにはサンダー OSと説明されるメンバクラスを含む。
【０１５１】
【表１】
【図面の簡単な説明】
【図１Ａ】図１Ａは本発明の実施例によるもので、メンバハードウェアモジュールのブロック図である。
【図１Ｂ】図１Ｂは本発明の実施例によるもので、メンバハードウェアモジュールとバックプレーンの透視図である。
【図１Ｃ】図１Ｃは本発明の実施例によるもので、ICと回路基板の平面図である。
【図２】図２は本発明の実施例によるもので、動作環境下にある、フェデレイテッド OSを使用したサーバのブロック図である。
【図３】図3は本発明の実施例によるもので、フェデレイテッド OSを使用したサーバのブロック図である。
【図４Ａ】図４Ａは本発明の実施例によるもので、フェデレイテッド OSのいくつかのメンバ間の関係を例示する図である。
【図４Ｂ】図４Ｂは本発明の実施例によるもので、動作環境下にある、フェデレイテッド OS使用のサーバの構成部分のブロック図である。
【図５】図５は、本発明の実施例によるもので、メンバを地理的に分散した、動作環境にあるサーバのブロック図である。
【図６】図６は、本発明の実施例によるもので、いくつかのメンバがインターネットバックボーンに直接接続されている、動作環境下にあるサーバのブロック図である。
【図７】図７は、本発明の実施例によるもので、いくつかのメンバがインターネットバックボーンに直接接続されており、動作環境下にあり、遠隔のデータ蓄積のあるサーバのブロック図である。
【図８】図８は、本発明の実施例によるもので、サンダー OSを含む、フェデレイテッド OSの構成部分の図である。
【図９Ａ】図９Ａは、本発明の実施例によるもので、サンダー OSのメンバ間の関係を例示するブロック図である。
【図９Ｂ】図９Ｂは、本発明の実施例によるもので、サンダー OSのブート可能なメンバ内の機能と相互作用を例示するブロック図である。
【図９Ｃ】図９Ｃは、本発明の実施例によるもので、サンダー OS中のレシーバメンバ内の機能と相互作用を例示するブロック図である。
【図９Ｄ】図９Ｄは、本発明の実施例によるもので、サンダー OS中のディスパッチャメンバ内の機能と相互作用を例示するブロック図である。
【図９Ｅ】図９Ｅは、本発明の実施例によるもので、サンダー OS中の静的レスポンダメンバ内の機能と相互作用を例示するブロック図である。
【図９Ｆ】図９Ｆは、本発明の実施例によるもので、サンダー OS中の動的レスポンダメンバ内の機能と相互作用を例示するブロック図である。
【図１０】図10は、本発明の実施例によるもので、レシーバ、ディスパッチャおよびレスポンダの各メンバへの機能の配分を例示するブロック図である。
【図１１】図11は、本発明の実施例によるもので、レシーバのTCP接続状態マシーンの図である。
【図１２】図12は、本発明の実施例によるもので、ディスパッチャのTCP接続状態マシーンの図である。
【図１３】図13は、本発明の実施例によるもので、分散型TCP/IP計算システムを例示するブロック図である。
【図１４Ａ】図14Aは、本発明の実施例によるもので、サーバを初期化する方法を例示するフローチャートである。
【図１４Ｂ】図14Bは、本発明のもう一つの実施例によるもので、サーバを初期化する方法を例示するフローチャートである。
【図１５】図15は、本発明の実施例によるもので、クライアントの要求に応えるための、クライアント、レシーバ、ディスパッチャ、レスポンダ間のデータの流れを例示する図である。
【図１６Ａ】図16Aは、本発明の実施例によるもので、外部ネットワークを通じて受け取った要求に応えるための方法を、例示するフローチャートである。
【図１６Ｂ】図16Bは、本発明のもう一つの実施例によるもので、外部ネットワークを通じて受信した要求に応える方法を、例示したフローチャートである。
【図１６Ｃ】図１６Ｃは、本発明のもう一つの実施例によるもので、外部ネットワークを通じて受信した要求に応える方法を、例示したフローチャートである。
【図１６Ｄ】図１６Ｄは、本発明のもう一つの実施例によるもので、外部ネットワークを通じて受信した要求に応える方法を、例示したフローチャートである。
【図１７】図１７は、本発明の実施例によるもので、信号を保持する光ディスクの平面図である。
Claims (42)
- 特定の機能に最適化された第１のクラスのオペレーティングシステムを実行し、分散型ネットワークプロトコル状態マシンの全状態の一部である第１の特定の状態の維持及び処理を行う第１のＣＰＵ（１１０ａ、１３０５）と、
前記第１のＣＰＵと接続され、内部ネットワーク（１８３、２０５、２１０、４９０、９０２）に接続する第１の内部ネットワークインターフェース（１１５）と、
特定の機能に最適化された第２のクラスのオペレーティングシステムを実行し、前記分散型ネットワークプロトコル状態マシンの全状態の一部である第２の特定の状態の維持及び処理を行う第２のＣＰＵ（１１０ｂ、１３０５）と、
前記第２のＣＰＵと接続され、前記内部ネットワーク（１８３、２０５、２１０、４９０、９０２）に接続する第２の内部ネットワークインターフェース（１１５）と、
を備え、
前記第１のクラス及び第２のクラスは共通の親クラスから継承されたものであり、
前記第１及び第２のクラスのオペレーティングシステムがそれぞれ前記分散型ネットワークプロトコル状態マシンの前記第１及び第２の特定の状態の維持及び処理を行い、前記第１及び第２のクラスのオペレーティングシステムによる状態維持及び処理が単一の完成した前記分散型ネットワークプロトコル状態マシンを構成し、
前記第１および第２のクラスのオペレーティングシステムが、各々の機能に応じた異なる特性と内部ネットワークを介した通信に必要な機能を提供する共通の特性とを有し、前記第１および第２のクラスのオペレーティングシステムが共同でフェデレイテッドオペレーティングシステムを形成することを特徴とするディジタルコンピュータシステム。 - 請求項１に記載のディジタルコンピュータシステムにおいて、
前記第１のＣＰＵ（１１０ａ、１３０５）に第１の外部ネットワークインターフェース（１２０）が接続され、前記第２のＣＰＵ（１１０ｂ、１３０５）に第２の外部ネットワークインターフェース（１２０）が接続され、ＴＣＰ接続に関するある状態情報が前記第１のクラスのオペレーティングシステムにより維持され、ＴＣＰ接続に関するある状態情報が前記第２のクラスのオペレーティングシステムにより維持されることを特徴とするディジタルコンピュータシステム。 - 請求項２に記載のディジタルコンピュータシステムにおいて、
前記第１及び第２のクラスのオペレーティングシステムが互いに異なる機能に最適化されて前記第１及び第２の特定の状態の維持及び処理を行うことと、ＴＣＰ接続に関する状態情報が前記第１及び第２のクラスのオペレーティングシステムによりそれぞれ維持されることにより、前記第１のクラスのオペレーティングシステムと前記第２のクラスのオペレーティングシステムが共同して少なくとも一つの共通ＩＰアドレスでサービスを実施することを特徴とするディジタルコンピュータシステム。 - 請求項１に記載のディジタルコンピュータシステムにおいて、さらに、
第３のクラスのオペレーティングシステムを実行し、分散型ネットワークプロトコル状態マシンの全状態の一部である第３の特定の状態の維持及び処理を行う第３のＣＰＵと、
前記第３のＣＰＵと接続され、前記内部ネットワーク（１８３、２０５、２１０、４９０、９０２）に接続する第３の内部ネットワークインターフェースと、
を備え、
前記第１、第２および第３のクラスのオペレーティングシステムは異なる特性と共通の特性を有し、
前記第１のクラスのオペレーティングシステムがレシーバオペレーティングシステムであり、
前記第２のクラスのオペレーティングシステムがレスポンダオペレーティングシステムであり、
前記第３のクラスのオペレーティングシステムがディスパッチャオペレーティングシステムであり、
前記第１、第２および第３のクラスのオペレーティングシステムが前記共通の親クラスのオペレーティングシステムから受け継ぐ共通の特性を有し、
前記第１、第２及び第３のクラスのオペレーティングシステムがそれぞれ前記分散型ネットワークプロトコル状態マシンの前記第１、第２及び第３の特定の状態の維持及び処理を行い、前記第１、第２及び第３のクラスのオペレーティングシステムによる状態維持及び処理が単一の完成した前記分散型ネットワークプロトコル状態マシンを構成することを特徴とするディジタルコンピュータシステム。 - 請求項４に記載のディジタルコンピュータシステムにおいて、
前記第１のＣＰＵ（１１０ａ、１３０５）に第１の外部ネットワークインターフェース（１２０）が接続され、前記第２のＣＰＵ（１１０ｂ、１３０５）に第２の外部ネットワークインターフェース（１２０）が接続され、前記第１のクラスのオペレーティングシステムと前記第２のクラスのオペレーティングシステムが共同して少なくとも一つの共通ＩＰアドレスでサービスを実施することを特徴とするディジタルコンピュータシステム。 - 請求項４または５に記載のディジタルコンピュータシステムにおいて、
前記第１、第２および第３の内部ネットワークインターフェース（１１５）に接続される前記内部ネットワーク（１８３、２０５、２１０、４９０、９０２）がさらに設けられていることを特徴とするディジタルコンピュータシステム。 - 請求項４〜６のいずれかに記載のディジタルコンピュータシステムにおいて、
ＴＣＰ接続に関するある状態情報が前記第１のクラスのオペレーティングシステムにより維持され、ＴＣＰ接続に関するある状態情報が前記第３のクラスのオペレーティングシステムにより維持され、
前記第１のクラスのオペレーティングシステムが少なくともＩＰアドレスとＴＣＰポートを探索し、ＴＣＰ接続を確立するように構成され、
前記第２のクラスのオペレーティングシステムが少なくとも応答データを送信するように構成され、
前記第３のクラスのオペレーティングシステムが少なくとも接続状態情報を維持し、送信すべき応答を決定するように構成されていることを特徴とするディジタルコンピュータシステム。 - 請求項１に記載のディジタルコンピュータシステムで構成されたサーバ（３００、４４０、５０５、６０５）であって、
前記第１のＣＰＵ（１１０ａ）を含み、前記第１のクラスのオペレーティングシステムを保持する第１のメンバハードウエアユニットメモリＲＡＭ（１２５）を有する第１のメンバハードウエアユニット（１０５ａ）と、
前記第２のＣＰＵ（１１０ｂ）を含み、第２のクラスのオペレーティングシステムを保持する第２のメンバハードウエアユニットメモリＲＡＭ（１２５）を有し、前記内部ネットワーク（１８３、２０５、２１０、４９０、９０２）に接続する内部ネットワークインターフェース（１１５）を有する第２のメンバハードウエアユニット（１０５ｂ）と、
を備え、
前記第１および第２のクラスのオペレーティングシステムが異なる特性を有し、ＴＣＰ接続に関するある状態情報が前記第１のメンバハードウエアユニット（１０５ａ）上に維持され、ＴＣＰ接続に関するある状態情報が前記第２のメンバハードウエアユニット（１０５ｂ）上に維持され、
前記第１のクラスのオペレーティングシステムと前記第２のクラスのオペレーティングシステムが共同して少なくとも一つの共通ＩＰアドレスでサービスを実施し、さらに前記内部ネットワーク（１８３、２０５、２１０、４９０、９０２）が前記サーバに設けられ、
前記内部ネットワーク（１８３、２０５、２１０、４９０、９０２）が前記第１おおび第２のメンバハードウエアユニット（１０５ａ、１０５ｂ）の内部ネットワークインターフェース（１０５）に接続されることを特徴とするサーバ。 - 請求項８に記載のサーバ（３００、４４０、５０５、６０５）において、
前記第１のクラスのオペレーティングシステムが、少なくともレシーバオペレーティングシステムの特性を有し、
前記第２のクラスのオペレーティングシステムが、少なくともレスポンダオペレーティングシステムの特性を有し、
前記第１のメンバハードウエアユニット（１０５）が、外部ネットワーク（２１５、４９２、６２０、７１０、９１６）に接続する外部ネットワークインターフェース（１２０）を有し、
前記第２のメンバハードウエアユニット（１０５ｂ）が、前記外部ネットワーク（２１５、４９２、６２０、７１０、９１６）に接続する外部ネットワークインターフェース（１２０）を有することを特徴とするサーバ。 - 請求項８に記載のサーバ（３００、４４０、５０５、６０５）において、さらに、
特定の機能に最適化された第３のクラスのオペレーティングシステムを実行し、分散型ネットワークプロトコル状態マシンの全状態の一部である第１の特定の状態の維持及び処理を行う第３のＣＰＵを含み、前記第３のクラスのオペレーティングシステムを保持する第３のメンバハードウエアユニットメモリＲＡＭを有し、前記内部ネットワーク（１８３、２０５、２１０、４９０、９０２）に接続する内部ネットワークインターフェース（１１５）を有する第３のメンバハードウエアユニットを備え、
前記第１、第２及び第３のクラスは共通の親クラスから継承されたものであり、
前記第１、第２及び第３のクラスのオペレーティングシステムがそれぞれ前記分散型ネットワークプロトコル状態マシンの前記第１、第２及び第３の特定の状態の維持及び処理を行い、前記第１、第２及び第３のクラスのオペレーティングシステムによる状態維持及び処理が単一の完成した前記分散型ネットワークプロトコル状態マシンを構成し、
前記第１、第２および第３のクラスのオペレーティングシステムは異なる特性を有し、
ＴＣＰ接続に関するある状態情報が前記第１のメンバハードウエアユニット（１０５ａ）上に維持され、ＴＣＰ接続に関するある状態情報が前記第３のメンバハードウエアユニット上に維持され、
複数の前記メンバハードウエアユニット（１０５ａ、１０５ｂ）上に集合的にリアルタイムＴＣＰ／ＩＰ状態マシーンが実現されることを特徴とするサーバ。 - 請求項１０に記載のサーバ（３００、４４０、５０５、６０５）において、
ＴＣＰ接続に関する状態情報が前記第１のメンバハードウエアユニット（１０５ａ）および前記第３のメンバハードウエアユニット上に維持され、前記第１のメンバハードウエアユニット（１０５ａ）上に維持される状態情報の少なくとも一部が、前記第３のメンバハードウエアユニット上に維持される状態情報と異なり、
前記第１のクラスのオペレーティングシステムが少なくともＩＰアドレスとＴＣＰポートを探索し、ＴＣＰ接続を確立するように構成され、
前記第２のクラスのオペレーティングシステムが少なくとも応答データを送信するように構成され、
前記第３のクラスのオペレーティングシステムが少なくとも接続状態情報を維持し、送信すべき応答を決定するように構成され、
前記第１のクラスのオペレーティングシステムと前記第２のクラスのオペレーティングシステムが共同して少なくとも一つの共通ＩＰアドレスでサービスを実施し、
前記第１のクラスのオペレーティングシステムがレシーバオペレーティングシステムであり、
前記第２のクラスのオペレーティングシステムがレスポンダオペレーティングシステムであり、
前記第３のクラスのオペレーティングシステムがディスパッチャオペレーティングシステムであり、
前記第１のメンバハードウエアユニット（１０５ａ）が、外部ネットワーク（２１５、４９２、６２０、７１０、９１６）に接続する外部ネットワークインターフェース（１２０）を有し、
前記第２のメンバハードウエアユニット（１０５ｂ）が、前記外部ネットワーク（２１５、４９２、６２０、７１０、９１６）に接続する外部ネットワークインターフェース（１２０）を有することを特徴とするサーバ。 - 請求項１０に記載のサーバ（３００、４４０、５０５、６０５）において、
前記第１、第２および第３のクラスのオペレーティングシステムが共通の親から受け継ぐ共通の特性を有することを特徴とするサーバ。 - 請求項１１に記載のサーバ（３００、４４０、５０５、６０５）において、
前記第１のクラスのオペレーティングシステムがＨＴＴＰサーバの一部を含み、
前記第２のクラスのオペレーティングシステムがＨＴＴＰサーバの一部を含み、
前記第３のクラスのオペレーティングシステムがＨＴＴＰサーバの一部を含み、
前記第１、第２および第３のクラスのオペレーティングシステムにあるＨＴＴＰサーバの複数部分が一緒にＨＴＴＰサーバを形成することを特徴とするサーバ。 - 請求項１１に記載のサーバ（３００、４４０、５０５、６０５）において、
前記第１のクラスのオペレーティングシステムがＦＴＰサーバの一部を含み、
前記第２のクラスのオペレーティングシステムがＦＴＰサーバの一部を含み、
前記第３のクラスのオペレーティングシステムがＦＴＰサーバの一部を含み、
前記第１、第２および第３のクラスのオペレーティングシステムにあるＦＴＰサーバの複数部分が一緒にＦＴＰサーバを形成することを特徴とするサーバ。 - 請求項１０に記載のサーバ（３００、４４０、５０５、６０５）において、
前記第１のメンバハードウエアユニットメモリは、ブータブルメンバを保持する第１のメンバハードウエアユニットメモリＲＯＭを含み、
前記第２のメンバハードウエアユニットメモリは、ブータブルメンバを保持する第２のメンバハードウエアユニットメモリＲＯＭを含み、
前記第３のメンバハードウエアユニットメモリは、ブータブルメンバを保持する第３のメンバハードウエアユニットメモリＲＯＭを含むことを特徴とするサーバ。 - 請求項１０に記載のサーバ（３００、４４０、５０５、６０５）において、
前記第１のメンバハードウエアユニット（１０５ａ）は、ＩＰアドレス探索をリアルタイムで行い、
前記第１のメンバハードウエアユニット（１０５ａ）は、トゥリーデータ構造を用いるＩＰアドレス探索アルゴリズムを使用し、
前記第３のメンバハードウエアユニット（１０５ａ、１０５ｂ）は、ホスト名探索をリアルタイムで行い、
前記メンバハードウエアユニットはクライアントからの要求をリアルタイムで処理することを特徴とするサーバ。 - 請求項１０に記載のサーバ（３００、４４０、５０５、６０５）において、
少なくとも一つのメンバハードウエアユニットが、非リアルタイムレイヤーとリアルタイムレイヤーを実行することを特徴とするサーバ。 - 請求項１０に記載のサーバ（３００、４４０、５０５、６０５）において、
少なくとも一つのメンバハードウエアユニット（１０５ａ）が、少なくとも一つの他のメンバハードウエアユニット（１０５ｂ）とは別の筐体に配置されることを特徴とするサーバ。 - 請求項１０または１８に記載のサーバ（３００、４４０、５０５、６０５）において、
少なくとも一つのメンバハードウエアユニット（１０５ａ）が、少なくとも一つの他のメンバハードウエアユニット（１０５ｂ）から少なくとも１キロメートル離れたところに配置されていることを特徴とするサーバ。 - 請求項２に記載のディジタルコンピュータシステムにおいて、
各々のクラスのオペレーティングシステムを実行する複数のＣＰＵ（１１０ａ、１１０ｂ、１３０５）が設けられ、前記複数のＣＰＵ（１１０ａ、１１０ｂ、１３０５）上に集合的にＴＣＰ／ＩＰ状態マシーンが実現されることを特徴とするディジタルコンピュータシステム。 - 請求項９に記載のサーバ（３００、４４０、５０５、６０５）において、
少なくとも一つのレスポンダメンバが、少なくとも一つのレシーバメンバと異なる筐体に配置されることを特徴とするサーバ。 - 請求項９または２１に記載のサーバ（３００、４４０、５０５、６０５）において、
少なくとも一つのレスポンダメンバが、少なくとも一つのレシーバメンバから少なくとも１キロメートル離れたところに配置されることを特徴とするサーバ。 - 請求項９、２１または２２に記載のサーバ（３００、４４０、５０５、６０５）において、
少なくとも一つのレスポンダメンバと少なくとも一つのレシーバメンバの前記外部ネットワークインターフェースが、前記外部ネットワーク上で少なくとも１キロメートル離れた異なる位置で前記外部ネットワークに接続されることを特徴とするサーバ。 - 請求項９、２１〜２３のいずれかに記載のサーバ（３００、４４０、５０５、６０５）において、
少なくとも二つのレスポンダメンバの前記外部ネットワークインターフェースが、前記外部ネットワーク上の異なる位置で前記外部ネットワークに接続されることを特徴とするサーバ。 - 請求項９、２１〜２４のいずれかに記載のサーバ（３００、４４０、５０５、６０５）において、
少なくとも一つのメンバの前記外部ネットワークインターフェースが、インターネットバックボーン（６２０、７２０）に直接接続されていることを特徴とするサーバ。 - 請求項９、２１〜２５のいずれかに記載のサーバ（３００、４４０、５０５、６０５）において、
ＨＴＴＰサーバの異なる複数の部分が、複数の異なるメンバのクラスのオペレーティングシステムに設けられることを特徴とするサーバ。 - 請求項９、２１〜２６のいずれかに記載のサーバ（３００、４４０、５０５、６０５）において、
ＦＴＰサーバの異なる複数の部分が、複数の異なるメンバのクラスのオペレーティングシステムに設けられることを特徴とするサーバ。 - 請求項９、２１〜２７のいずれかに記載のサーバ（３００、４４０、５０５、６０５）において、
さらに、前記内部ネットワークに接続するための内部ネットワークインターフェースを持つ少なくとも一つのコンフィギュレータメンバ（２３５）を有することを特徴とするサーバ。 - 請求項９、２１〜２８のいずれかに記載のサーバ（３００、４４０、５０５、６０５）において、
さらに、前記内部ネットワークに接続するための内部ネットワークインターフェースを持つ少なくとも一つのガーディアンメンバ（２４０）を有することを特徴とするサーバ。 - 請求項９、２１〜２９のいずれかに記載のサーバ（３００、４４０、５０５、６０５）において、
さらに、前記内部ネットワークに接続するための内部ネットワークインターフェースを持つ少なくとも一つの持続性ストレージメンバ（２４５）を有することを特徴とするサーバ。 - 請求項９、２１〜３０のいずれかに記載のサーバ（３００、４４０、５０５、６０５）において、
さらに、前記内部ネットワークに接続するための内部ネットワークインターフェースを持つ少なくとも一つのデコーダメンバ（２５５）を有することを特徴とするサーバ。 - 請求項９、２１〜３１のいずれかに記載のサーバ（３００、４４０、５０５、６０５）において、
さらに、前記内部ネットワークに接続するための内部ネットワークインターフェースを持つ少なくとも一つのシステムアドミニストレータノーティフィアメンバ（２５０）を有することを特徴とするサーバ。 - 外部ネットワーク（２１５、４９２、６２０、７１０、９１６）から受信される要求への応答方法であって、
少なくともレシーバオペレーティングシステムを第１のＣＰＵで実行し、
少なくともレスポンダオペレーティングシステムを第２のＣＰＵで実行し、
前記外部ネットワークから送信された要求を前記第１のＣＰＵ（１１０ｂ、１３０５）で受信し、
前記第１のＣＰＵ（１１０ａ）から前記第２のＣＰＵ（１１０ｂ）へメッセージを内部ネットワーク（１８３、２０５、２１０、４９０、９０２）を介して送信し、
前記第２のＣＰＵ（１１０ｂ）から前記外部ネットワーク（２１５、４９２、６２０、７１０、９１６）へ応答データを送信する方法であり、
さらに、前記要求に対する正しい応答を識別し、さらに前記レシーバオペレーティングシステムおよび前記レスポンダオペレーティングシステムをサーバの異なる複数部分で実行してサーバを分散型ネットワークプロトコル状態マシンとして機能させ、
前記レシーバオペレーテイングシステムが特定の機能に最適化された第１のクラスのオペレーティングシステムであり、前記第１のＣＰＵが該第１のクラスのオペレーティングシステムを実行し、前記分散型ネットワークプロトコル状態マシンの全状態の一部である第１の特定の状態の維持及び処理を行い、
前記レスポンダオペレーティングシステムが特定の機能に最適化された第２のクラスのオペレーティングシステムであり、前記第２のＣＰＵが該第２のクラスのオペレーティングシステムを実行し、前記分散型ネットワークプロトコル状態マシンの全状態の一部である第２の特定の状態の維持及び処理を行い、
前記第１のクラス及び第２のクラスは共通の親クラスから継承されたものであり、
前記第１及び第２のクラスのオペレーティングシステムがそれぞれ前記分散型ネットワークプロトコル状態マシンの前記第１及び第２の特定の状態の維持及び処理を行い、前記第１及び第２のクラスのオペレーティングシステムによる状態維持及び処理が単一の完成した前記分散型ネットワークプロトコル状態マシンを構成し、
前記第１および第２のクラスのオペレーティングシステムが、各々の機能に応じた異なる特性と内部ネットワークを介した通信に必要な機能を提供する共通の特性とを有し、前記第１および第２のクラスのオペレーティングシステムが共同でフェデレイテッドオペレーティングシステムを形成することを特徴とする方法。 - 請求項３３に記載の方法において、
少なくともディスパッチャオペレーティングシステムを第３のＣＰＵで実行し、前記ディスパッチャオペレーテイングシステムが特定の機能に最適化された第３のクラスのオペレーティングシステムであり、前記第３のＣＰＵが該第３のクラスのオペレーティングシステムを実行し、前記分散型ネットワークプロトコル状態マシンの全状態の一部である第３の特定の状態の維持及び処理を行い、前記第１、第２及び第３のクラスは共通の親クラスから継承されたものであり、前記第１、第２及び第３のクラスのオペレーティングシステムがそれぞれ前記分散型ネットワークプロトコル状態マシンの前記第１、第２及び第３の特定の状態の維持及び処理を行い、前記第１、第２及び第３のクラスのオペレーティングシステムによる状態維持及び処理が単一の完成した前記分散型ネットワークプロトコル状態マシンを構成し、
前記レシーバオペレーティングシステムを使用して、前記外部ネットワーク（２１５、４９２、６２０、７１０、９１６）から受信されたＩＰアドレスとＴＣＰまたはＵＤＰポートを探索し、
探索で見つかった前記ＩＰアドレスとＴＣＰまたはＵＤＰポートに関連付けられた前記ディスパッチャオペレーティングシステムを有する前記第３のＣＰＵを識別し、
前記レシーバオペレーティングシステムから前記ディスパッチャオペレーティングシステムへ要求データを転送し、
前記レシーバオペレーティングシステムおよび前記ディスパッチャオペレーティングシステムを使用して状態情報を維持し、
前記ディスパッチャオペレーティングシステムを使用して、応答データと、前記第２のＣＰＵ上にあって対応する少なくとも一つのレスポンダオペレーティングシステムとを識別し、
前記ディスパッチャオペレーティングシステムを使用して、前記応答データを特定すると共に前記応答データを送信するようレスポンダオペレーティングシステムに命令するメッセージを送信し、
前記レスポンダオペレーティングシステムを使用して、前記要求データを前記外部ネットワーク（２１５、４９２、６２０、７１０、９１６）へ送信する方法であり、
前記レシーバ、ディスパッチャおよびレスポンダオペレーティングシステムは異なるクラスのオペレーティングシステムであり、
さらに、レシーバオペレーティングシステムを使用して、ＴＣＰ要求が受信されるとＴＣＰ接続を確立することを特徴とする方法。 - 請求項３３または３４に記載の方法において、さらに、
前記レシーバオペレーティングシステムを使用して、外部ネットワーク（２１５、４９２、６２０、７１０、９１６）から受信されたメッセージからＨＴＴＰヘッダを抽出し、前記ＨＴＴＰヘッダを含むメッセージを送信することを特徴とする方法。 - 請求項１〜４のいずれかに記載のディジタルコンピュータシステムにおいて、
第２のＣＰＵ（１１０ｂ）が複数個設けられており、各々の第２ＣＰＵがその機能に最適化された第２のクラスのオペレーティングシステムを実行することを特徴とするディジタルコンピュータシステム。 - 請求項１〜４のいずれかに記載のディジタルコンピュータシステムにおいて、
複数の更なるＣＰＵ（１３０５）が設けられており、各々のＣＰＵがその機能に最適化された各々のクラスのオペレーティングシステムを実行することを特徴とするディジタルコンピュータシステム。 - 請求項３７に記載のディジタルコンピュータシステムにおいて、
前記更なるＣＰＵがファイアウォール機能（９２８）を実現することを特徴とするディジタルコンピュータシステム。 - 請求項３７に記載のディジタルコンピュータシステムにおいて、
前記更なるＣＰＵがガーディアン機能（９０２）を実現することを特徴とするディジタルコンピュータシステム。 - 請求項３７に記載のディジタルコンピュータシステムにおいて、
前記更なるＣＰＵがビデオおよび／またはオーディオ伝送機能を実現することを特徴とするディジタルコンピュータシステム。 - 請求項１に記載のディジタルコンピュータシステムにおいて、
前記複数のＣＰＵの一つが、少なくとも一つのパケットベース通信プロトコルと回路ベース通信プロトコルを機能させることを特徴とするディジタルコンピュータシステム。 - 請求項１に記載のディジタルコンピュータシステムにおいて、
前記第１および第２のＣＰＵ（１１０ａ、１１０ｂ）がチップ（１０５）上のシステムとして実現されることを特徴とするディジタルコンピュータシステム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/464,945 US6799202B1 (en) | 1999-12-16 | 1999-12-16 | Federated operating system for a server |
| US09/464,945 | 1999-12-16 | ||
| PCT/US2000/033323 WO2001044938A2 (en) | 1999-12-16 | 2000-12-08 | Federated operating system for a server |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003528371A JP2003528371A (ja) | 2003-09-24 |
| JP2003528371A5 JP2003528371A5 (ja) | 2006-01-05 |
| JP4245296B2 true JP4245296B2 (ja) | 2009-03-25 |
Family
ID=23845897
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001545964A Expired - Lifetime JP4245296B2 (ja) | 1999-12-16 | 2000-12-08 | サーバ用フェデレイテッドオペレーティングシステム |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US6799202B1 (ja) |
| EP (1) | EP1242882B1 (ja) |
| JP (1) | JP4245296B2 (ja) |
| AT (1) | ATE293809T1 (ja) |
| AU (1) | AU1955301A (ja) |
| DE (1) | DE60019640T2 (ja) |
| WO (1) | WO2001044938A2 (ja) |
Families Citing this family (71)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE60135127D1 (de) * | 2000-05-24 | 2008-09-11 | Voltaire Ltd | Gefilterte kommunikation von anwendung zu anwendung |
| EP1305931B1 (en) * | 2000-08-04 | 2006-06-28 | Avaya Technology Corp. | Method and system for demand driven recognition of connection oriented transactions |
| US7421505B2 (en) * | 2000-12-21 | 2008-09-02 | Noatak Software Llc | Method and system for executing protocol stack instructions to form a packet for causing a computing device to perform an operation |
| US7287090B1 (en) * | 2000-12-21 | 2007-10-23 | Noatak Software, Llc | Method and system for identifying a computing device in response to a request packet |
| US20020116605A1 (en) * | 2000-12-21 | 2002-08-22 | Berg Mitchell T. | Method and system for initiating execution of software in response to a state |
| US7512686B2 (en) * | 2000-12-21 | 2009-03-31 | Berg Mitchell T | Method and system for establishing a data structure of a connection with a client |
| US7546369B2 (en) * | 2000-12-21 | 2009-06-09 | Berg Mitchell T | Method and system for communicating a request packet in response to a state |
| US20020116532A1 (en) * | 2000-12-21 | 2002-08-22 | Berg Mitchell T. | Method and system for communicating an information packet and identifying a data structure |
| US20020116397A1 (en) * | 2000-12-21 | 2002-08-22 | Berg Mitchell T. | Method and system for communicating an information packet through multiple router devices |
| US7418522B2 (en) * | 2000-12-21 | 2008-08-26 | Noatak Software Llc | Method and system for communicating an information packet through multiple networks |
| DE10109196B4 (de) * | 2001-02-26 | 2005-04-28 | Viessmann Werke Kg | Vorrichtung und Verfahren zur Fernüberwachung und Parametrierung von Einrichtungen, insbesondere von Heizungsanlagen |
| US6971044B2 (en) * | 2001-04-20 | 2005-11-29 | Egenera, Inc. | Service clusters and method in a processing system with failover capability |
| US7231430B2 (en) * | 2001-04-20 | 2007-06-12 | Egenera, Inc. | Reconfigurable, virtual processing system, cluster, network and method |
| US20020188700A1 (en) * | 2001-06-08 | 2002-12-12 | Todd Steitle | System and method of interactive network system design |
| US7149892B2 (en) | 2001-07-06 | 2006-12-12 | Juniper Networks, Inc. | Secure sockets layer proxy architecture |
| US7908472B2 (en) * | 2001-07-06 | 2011-03-15 | Juniper Networks, Inc. | Secure sockets layer cut through architecture |
| US7228412B2 (en) * | 2001-07-06 | 2007-06-05 | Juniper Networks, Inc. | Bufferless secure sockets layer architecture |
| US7853781B2 (en) * | 2001-07-06 | 2010-12-14 | Juniper Networks, Inc. | Load balancing secure sockets layer accelerator |
| US7207061B2 (en) * | 2001-08-31 | 2007-04-17 | International Business Machines Corporation | State machine for accessing a stealth firewall |
| GB0211286D0 (en) * | 2002-05-16 | 2002-06-26 | Nokia Corp | Routing data packets through a wireless network |
| US7424741B1 (en) * | 2002-05-20 | 2008-09-09 | Cisco Technology, Inc. | Method and system for prevention of network denial-of-service attacks |
| US7539183B2 (en) * | 2002-06-24 | 2009-05-26 | Emerson Network Power - Embedded Computing, Inc. | Multi-service platform system and method |
| US7441114B2 (en) * | 2002-09-10 | 2008-10-21 | Ge Fanuc Automation North America, Inc. | Methods and systems for management and control of an automation control module |
| US20040177129A1 (en) * | 2003-03-06 | 2004-09-09 | International Business Machines Corporation, Armonk, New York | Method and apparatus for distributing logical units in a grid |
| US9003048B2 (en) * | 2003-04-01 | 2015-04-07 | Microsoft Technology Licensing, Llc | Network zones |
| US20040210663A1 (en) * | 2003-04-15 | 2004-10-21 | Paul Phillips | Object-aware transport-layer network processing engine |
| GB2412755A (en) * | 2004-03-30 | 2005-10-05 | Hewlett Packard Development Co | Coordination of lifecycle state changes in software components |
| US20050289107A1 (en) * | 2004-06-25 | 2005-12-29 | Yan Arrouye | Methods and systems for managing data |
| US8161184B2 (en) * | 2004-06-25 | 2012-04-17 | Apple Inc. | Method and apparatus for facilitating long-lived DNS queries |
| US8131674B2 (en) | 2004-06-25 | 2012-03-06 | Apple Inc. | Methods and systems for managing data |
| US8150837B2 (en) * | 2004-06-25 | 2012-04-03 | Apple Inc. | Methods and systems for managing data |
| US7593930B2 (en) * | 2004-12-14 | 2009-09-22 | Sap Ag | Fast channel architecture |
| US7600217B2 (en) | 2004-12-14 | 2009-10-06 | Sap Ag | Socket-like communication API for Java |
| US7580915B2 (en) * | 2004-12-14 | 2009-08-25 | Sap Ag | Socket-like communication API for C |
| US7971001B2 (en) | 2004-12-28 | 2011-06-28 | Sap Ag | Least recently used eviction implementation |
| US8204931B2 (en) | 2004-12-28 | 2012-06-19 | Sap Ag | Session management within a multi-tiered enterprise network |
| US7672949B2 (en) * | 2004-12-28 | 2010-03-02 | Sap Ag | Connection manager having a common dispatcher for heterogeneous software suites |
| US7539821B2 (en) | 2004-12-28 | 2009-05-26 | Sap Ag | First in first out eviction implementation |
| US7694065B2 (en) | 2004-12-28 | 2010-04-06 | Sap Ag | Distributed cache architecture |
| US7933947B2 (en) * | 2004-12-28 | 2011-04-26 | Sap Ag | Connection manager that supports failover protection |
| US20060143256A1 (en) | 2004-12-28 | 2006-06-29 | Galin Galchev | Cache region concept |
| KR100645537B1 (ko) * | 2005-02-07 | 2006-11-14 | 삼성전자주식회사 | 안정적인 패킷 포워딩을 위한 동적인 큐 관리방법 및 이를위한 네트워크 프로세서의 구성요소 |
| US8589562B2 (en) | 2005-04-29 | 2013-11-19 | Sap Ag | Flexible failover configuration |
| US20060271395A1 (en) * | 2005-05-25 | 2006-11-30 | Harris Steven T | Distributed object identity in a virtual machine cluster |
| US7689660B2 (en) * | 2005-06-09 | 2010-03-30 | Sap Ag | Application server architecture |
| CN101258719B (zh) * | 2005-07-17 | 2012-12-12 | 黑曜石研究有限公司 | 延长InfiniBand网络的实时到达的方法 |
| US20070033301A1 (en) * | 2005-07-18 | 2007-02-08 | Eliezer Aloni | Method and system for transparent TCP offload with dynamic zero copy sending |
| US7966412B2 (en) | 2005-07-19 | 2011-06-21 | Sap Ag | System and method for a pluggable protocol handler |
| US20070118664A1 (en) * | 2005-10-24 | 2007-05-24 | International Business Machines Corporation | Mail dispatch system |
| US20070156907A1 (en) * | 2005-12-30 | 2007-07-05 | Galin Galchev | Session handling based on shared session information |
| US8707323B2 (en) | 2005-12-30 | 2014-04-22 | Sap Ag | Load balancing algorithm for servicing client requests |
| US7490110B2 (en) * | 2006-03-24 | 2009-02-10 | International Business Machines Corporation | Predictable query execution through early materialization |
| US7877381B2 (en) * | 2006-03-24 | 2011-01-25 | International Business Machines Corporation | Progressive refinement of a federated query plan during query execution |
| US8250134B2 (en) * | 2006-12-27 | 2012-08-21 | International Business Machines Corporation | Processing multiple requests by a statically identified user server prior to user server termination |
| US8103628B2 (en) * | 2008-04-09 | 2012-01-24 | Harmonic Inc. | Directed placement of data in a redundant data storage system |
| US9021071B2 (en) | 2008-06-09 | 2015-04-28 | International Business Machines Corporation | Methods of federating applications providing modular data |
| US8271659B2 (en) * | 2008-09-04 | 2012-09-18 | Oracle International Corporation | Methods and systems for automatic removal and replacement of connections in a pool rendered stale by a firewall |
| US9384042B2 (en) * | 2008-12-16 | 2016-07-05 | International Business Machines Corporation | Techniques for dynamically assigning jobs to processors in a cluster based on inter-thread communications |
| US8122132B2 (en) * | 2008-12-16 | 2012-02-21 | International Business Machines Corporation | Techniques for dynamically assigning jobs to processors in a cluster based on broadcast information |
| US8239524B2 (en) | 2008-12-16 | 2012-08-07 | International Business Machines Corporation | Techniques for dynamically assigning jobs to processors in a cluster based on processor workload |
| US9396021B2 (en) * | 2008-12-16 | 2016-07-19 | International Business Machines Corporation | Techniques for dynamically assigning jobs to processors in a cluster using local job tables |
| US9923995B1 (en) | 2010-02-27 | 2018-03-20 | Sitting Man, Llc | Methods, systems, and computer program products for sharing information for detecting an idle TCP connection |
| US20140082258A1 (en) * | 2012-09-19 | 2014-03-20 | Lsi Corporation | Multi-server aggregated flash storage appliance |
| TWI544337B (zh) * | 2012-10-25 | 2016-08-01 | 緯創資通股份有限公司 | 共用通用串列匯流排（ｕｓｂ）裝置之雙作業系統架構，以及雙作業系統架構共用通用串列匯流排（ｕｓｂ）裝置之方法 |
| SG11201703834SA (en) * | 2014-11-14 | 2017-06-29 | Fujitsu Ltd | Recording medium, data verification method, and data verification device |
| US11240334B2 (en) | 2015-10-01 | 2022-02-01 | TidalScale, Inc. | Network attached memory using selective resource migration |
| US11023135B2 (en) | 2017-06-27 | 2021-06-01 | TidalScale, Inc. | Handling frequently accessed pages |
| US10817347B2 (en) | 2017-08-31 | 2020-10-27 | TidalScale, Inc. | Entanglement of pages and guest threads |
| US11175927B2 (en) | 2017-11-14 | 2021-11-16 | TidalScale, Inc. | Fast boot |
| CN110971680B (zh) * | 2019-11-22 | 2022-01-28 | 拉扎斯网络科技（上海）有限公司 | 通信方法、装置、系统、电子设备及可读存储介质 |
| US11425224B2 (en) * | 2020-02-25 | 2022-08-23 | Level 3 Communications, Llc | Disaggregated and distributed composable infrastructure |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6185619B1 (en) | 1996-12-09 | 2001-02-06 | Genuity Inc. | Method and apparatus for balancing the process load on network servers according to network and serve based policies |
| US5634053A (en) | 1995-08-29 | 1997-05-27 | Hughes Aircraft Company | Federated information management (FIM) system and method for providing data site filtering and translation for heterogeneous databases |
| US5940074A (en) | 1996-06-03 | 1999-08-17 | Webtv Networks, Inc. | Remote upgrade of software over a network |
| US5818448A (en) | 1996-07-02 | 1998-10-06 | Sun Microsystems, Inc. | Apparatus and method for identifying server computer aggregation topologies |
| US6182139B1 (en) * | 1996-08-05 | 2001-01-30 | Resonate Inc. | Client-side resource-based load-balancing with delayed-resource-binding using TCP state migration to WWW server farm |
| US5774660A (en) | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
| US6003079A (en) * | 1997-02-27 | 1999-12-14 | Hewlett Packard Company | System and method for continuously measuring quality of service in a federated application environment |
| US6393483B1 (en) * | 1997-06-30 | 2002-05-21 | Adaptec, Inc. | Method and apparatus for network interface card load balancing and port aggregation |
| SE511972C2 (sv) | 1997-09-09 | 2000-01-10 | Sics Swedish Inst Of Computers | Uppslagningsanordning och förfarande för att klassificera och vidarebefordra datapaket |
| US6141759A (en) * | 1997-12-10 | 2000-10-31 | Bmc Software, Inc. | System and architecture for distributing, monitoring, and managing information requests on a computer network |
| US6195680B1 (en) * | 1998-07-23 | 2001-02-27 | International Business Machines Corporation | Client-based dynamic switching of streaming servers for fault-tolerance and load balancing |
| US6438652B1 (en) * | 1998-10-09 | 2002-08-20 | International Business Machines Corporation | Load balancing cooperating cache servers by shifting forwarded request |
| US6564251B2 (en) * | 1998-12-03 | 2003-05-13 | Microsoft Corporation | Scalable computing system for presenting customized aggregation of information |
| US6502103B1 (en) * | 1999-06-14 | 2002-12-31 | International Business Machines Corporation | Providing composed containers and data objects to support multiple resources |
-
1999
- 1999-12-16 US US09/464,945 patent/US6799202B1/en not_active Expired - Lifetime
-
2000
- 2000-12-08 AU AU19553/01A patent/AU1955301A/en not_active Abandoned
- 2000-12-08 WO PCT/US2000/033323 patent/WO2001044938A2/en active IP Right Grant
- 2000-12-08 DE DE60019640T patent/DE60019640T2/de not_active Expired - Lifetime
- 2000-12-08 AT AT00982533T patent/ATE293809T1/de not_active IP Right Cessation
- 2000-12-08 EP EP00982533A patent/EP1242882B1/en not_active Expired - Lifetime
- 2000-12-08 JP JP2001545964A patent/JP4245296B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| ATE293809T1 (de) | 2005-05-15 |
| EP1242882B1 (en) | 2005-04-20 |
| WO2001044938A3 (en) | 2002-01-03 |
| US6799202B1 (en) | 2004-09-28 |
| DE60019640D1 (de) | 2005-05-25 |
| EP1242882A2 (en) | 2002-09-25 |
| WO2001044938A2 (en) | 2001-06-21 |
| JP2003528371A (ja) | 2003-09-24 |
| AU1955301A (en) | 2001-06-25 |
| DE60019640T2 (de) | 2006-03-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4245296B2 (ja) | サーバ用フェデレイテッドオペレーティングシステム | |
| US11997143B2 (en) | Managing communications among virtual machine nodes of a network service provider | |
| US9467513B2 (en) | Method and apparatus for web based storage on-demand | |
| CN101371237B (zh) | 在网络元件中代表应用执行消息有效载荷处理功能 | |
| US7277913B2 (en) | Persistent queuing for distributed file systems | |
| US8645542B2 (en) | Distributed intelligent virtual server | |
| CN101124565B (zh) | 基于应用层消息的数据流量负载平衡 | |
| CN101099345B (zh) | 利用采样和试探在网络元件处解释应用消息的方法和设备 | |
| US7289509B2 (en) | Apparatus and method of splitting a data stream over multiple transport control protocol/internet protocol (TCP/IP) connections | |
| CN111600936B (zh) | 一种适用于泛在电力物联网边缘终端的基于多容器的非对称处理系统 | |
| CN104052789A (zh) | 用于虚拟联网系统的负载平衡 | |
| JP2005539298A (ja) | サーバを遠隔かつ動的に構成する方法およびシステム | |
| JPH11102299A (ja) | 高信頼リモート・オブジェクト参照管理の方法とシステム | |
| US20130198265A1 (en) | Connection management in a computer networking environment | |
| US6950873B2 (en) | Apparatus and method for port sharing a plurality of server processes | |
| KR20050002604A (ko) | 데이터 전송 관리 시스템 및 방법 | |
| EP1706962B1 (en) | Method and apparatus for supporting transactions | |
| US7627650B2 (en) | Short-cut response for distributed services | |
| WO2002025435A1 (en) | Method, system, and computer program product for a data propagation platform | |
| US7206977B2 (en) | Intelligent self-configurable adapter | |
| US20060095561A1 (en) | Method and apparatus to correlate system management information using instant messaging facilities | |
| US20050188070A1 (en) | Vertical perimeter framework for providing application services | |
| Davies et al. | Websphere mq v6 fundamentals | |
| US20070055788A1 (en) | Method for forwarding network file system requests and responses between network segments | |
| Cappa-Banda et al. | Experimenting with a load-aware communication middleware for CPS domains |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20050810 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050810 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050926 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051026 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081014 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081119 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20081216 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090106 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4245296 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120116 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130116 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130116 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130116 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140116 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |