JP4242835B2 - 高データレートのステートフルプロトコル処理 - Google Patents

Description

本発明は、データ転送処理システムに関する。

データ転送システムは、典型的には、異なるタイプの処理をそれぞれ実行する複数の様々な層（レイヤ）を介してデータを伝送する。異なる層の数及びそれらの属性は、与えられた通信システムの基礎となる概念モデルによって変化する。例としては、国際標準化機構（International Standards Organization：ＩＳＯ）によって定義された開放型システム間相互接続（Open Systems Interconnection：ＯＳＩ）のための７つの階層を有するモデルと、米国規格協会（American National Standards Institute：ＡＮＳＩ）によって定義された「ファイバチャネル」モデルと呼ばれることもある５層モデルとが含まれる。この他にも、様々な数の階層を有し、幾分異なった機能を実行する多数のモデルが提案されている。大部分のデータ通信システムでは、階層（レイヤ）は、データを含む信号が送受信される際に使用される物理層から、高レベルのプログラム及びプロセスが情報を共有する際に使用されるアプリケーション層にまでわたる。この概念的階層モデルの大部分では、これらの最上位層と最下位層との間にトランスポート層が存在する。このようなトランスポート層内では、多様な物理リンクを介して送信されているデータの転送を調整してより高位のプロセスへ分配するために必要とされる機能が実行される。

トランスポート層内では、通信システムは（パケット等の）多数のメッセージを調整し、ここで、上記メッセージは、特定の「フロー」に、又はこのようなメッセージのグループ化されたものにそれぞれ属している。各メッセージは、特定のフロー識別キー（フローキー）に対するそれの関連性によって識別されることが可能であり、上記フロー識別キーは、典型的には、通信の終端（エンドポイント）に関する情報によって定義される。トランスポート層の処理は、一般に、トランスポート層端末装置（transport layer termination：ＴＬＴ）と呼ばれる複数の処理モジュールによって実行され、これらの処理モジュールは、遠隔の複数のＴＬＴから受信される（又は遠隔の複数のＴＬＴへ送信される）データを、各特定フローについて選択されたトランスポート層プロトコル（transport layer protocol：ＴＬＰ）により定義される複数のルールにてなるセットに従って管理する。ＴＬＴは、それが処理する各メッセージを調べて、そのメッセージが属するフローの状態を定義するフロー状態に関連した情報について当該メッセージを処理し、フロー状態を適宜更新し、受信された未処理のデータをこのフロー状態に基づいて再構成してメッセージの宛先にとって適切な形式にする。ここで、メッセージの宛先は典型的には、遠隔のＴＬＴであるか、又はローカルホストであるかのいずれかである。フローは典型的には双方向通信であり、よって、遠隔のＴＬＴから特定のフローに属するメッセージを受信するＴＬＴはまた、一般に、同じフローに属するメッセージをその遠隔のＴＬＴへ送信する。対応する複数のフロー状態を保持することによって選択された複数のＴＬＰに従って複数のフローの全体を管理することは、トランスポート層の処理を、一般には個別のメッセージにのみ関連したリンクレベルの処理から区別する。

ＴＬＰには、ファイバチャネル、ＳＣＴＰ、ＵＤＰ及びＴＣＰ等の多数の公知のものが存在し、将来はさらに多くが開発されるであろう。ＴＬＰは典型的には、失われたか又は損傷を受けたメッセージを検出してその再送信を要求すること、あるフローにおける複数の様々なメッセージを、意図された順序に再組織化すること、及び／又はその通信についての関連した事実を宛先へ提供すること等によって、理解可能かつ正確な情報の伝送を保証するように機能する。伝送制御プロトコル（Transmission Control Protocol：ＴＣＰ）は、おそらくはＴＬＰの最も良く知られた例であり、インターネット及びイーサネットアプリケーション等のネットワークにおいて広範に使用されている。ＴＣＰは接続指向のプロトコルであり、接続の状態に関する情報は、接続がアクティブである間、接続の終端装置（端末装置）において保持される必要がある。接続状態情報は、例えば、輻輳制御情報と、パケットが再送信されるべきか否かを決定するためのタイマと、肯定応答情報と、発信元及び宛先の識別情報及び開閉状態を含む接続識別情報とを含む。従って、アクティブなＴＣＰ接続はそれぞれ、一意的な接続ＩＤと接続状態とを有する。ＴＣＰ「接続」は、本明細書では「フロー」と呼んでいる、より一般的なステートフルプロトコル処理システム（すなわち、状態を保持するプロトコル処理システム。stateful protocol processing system：「ＳＰＰＳ」）の一例であり、ＴＣＰの「接続ＩＤ」及び「接続状態」は、本明細書では各々「フローキー」及び「フロー状態」と呼んでいる、より一般的なＳＰＰＳ概念の例である。ＴＬＰにおけるフローキーは、遠隔のリンク（宛先）のアドレス（典型的にはインターネットプロトコル又は「ＩＰ」アドレス）と、遠隔（宛先）のＴＣＰポート番号と、ローカルなリンク（発信元）のアドレス（同じく典型的にはＩＰアドレス）と、ローカルな（発信元の）ＴＣＰポート番号と場合によっては受信側インターフェースＩＤとの組み合わせによって、一意的に特定されることが可能である。また、何も対処しなければ異なるＴＬＰを用いるにも関わらず同一にアドレス指定されたアドレスを有することになる複数のフローを区別するために、一般的なフローキーの一部としてプロトコル標識情報を含むことが有用な場合もある。

データ通信は、古典的なトランスポート層以外にも多くの階層において生じることが可能である。例えば、ｉＳＣＳＩ通信はトランスポート層より上の階層で生じるが、本通信もやはり、１つのフローに属するステートフルメッセージを含み、よってある意味ではトランスポート層の通信に類似している。

次第に増大する複数のコンピュータがローカルな（例えばローカルエリアネットワークを介した）リンクと広域にわたる（例えばインターネットを介した）リンクとの両方で接続されるとき、データ通信システムのためのデータレートを増大させることに対する要求は絶えず存在する。より速いデータレートを達成するためには、トランスポート層及び他の場所においてステートフルプロトコルに関して相応のより高速な処理が必要である。当然ながら、より高速なハードウェアは速度に比例して処理速度を増大できる場合がある。しかしながら、ハードウェアの速度を増大させるだけでは、プロトコル処理速度を費用について効率的にかつ望みどおりに迅速に増大させることはなく、よって、プロトコル処理システムのアーキテクチャ及び方法により、与えられたハードウェア速度でより高速な処理を可能にするプロトコル処理システムに対する必要性が存在する。

本明細書では、ステートフルプロトコル処理のための方法、システム及び装置について説明する。ステートフルプロトコル処理は、データの「フロー」の状況を追跡するために「状態」を保持することを必然的に伴う。ある特定のフローの状態は、そのフローに属する個別のデータ「メッセージ」の処理を反映するためにしばしば更新され、フロー自体は、そのフローに属する各メッセージに対して明示的又は暗黙的に関連付けられたフローキーによって識別される。各メッセージについて標識により指定されるプロトコルは、フローの現在の状態に鑑みて各メッセージに対して実行されるべき処理ステップを定義する。

ある態様において、本発明は、多数のメッセージフローを処理するように構成されたステートフルプロトコル処理システム（「ＳＰＰＳ」）におけるデータを処理する方法に関する。各フローは、そのようなフローに属する複数のメッセージによって伝送される、一意的に対応するフローキーに関連付けられる。本方法は、ある特定のフローに属する複数のメッセージを受信することを含む。次に、受信された複数のメッセージから、その特定のフローに関連付けられた様々なＳＰＰＳイベントが導出される。本方法はさらに、特定のフローに係る１つ又は複数のイベントをこの特定のフローのステートフルプロトコル（ＳＰ）に従って処理するために第１のプロトコル処理コア（protocol processing core：「ＰＰＣ」）を特定的に割り当てることを含む。さらに、特定のフローに係る１つ又は複数の他のイベントをこの特定のフローのＳＰに従って処理するために異なる第２のＰＰＣが特定的に割り当てられる。

本明細書に記載のＳＰＰＳは多くの方法で実装されることが可能であり、以下、いくつかの例示的な実施形態について詳述する。ある実施形態は、より一般的なクラスのフローからのイベントとは対照的なある特定のフローのイベント（すなわち複数のメッセージから導出された情報）の処理をＰＰＣへ割り当てることを含む方法である。もう１つの実施形態は、イベントが位置した予備的キューメモリに関わりなくフローに係るイベントの処理をＰＰＣへ割り当て、次に、割り当てられたＰＰＣのローカルなキューメモリへそのイベントを転送することを含む方法である。さらにもう１つの実施形態は、メッセージを受信するステップと、受信されたメッセージに基づいてイベントの定義を生成するステップと、フローに係る第１のイベントを第１のＰＰＣへ割り当てるステップと、上記フローに係る第２のイベントを第２のＰＰＣへ割り当てるステップとを含む方法である。

別の実施形態は、データ通信トランスポート層の終端装置（又は端末装置）として動作するシステムであり、フローＩＤをそれぞれ有する複数のメッセージを受信してそこから複数のイベントを導出するように構成されたメッセージ受信機モジュールを含む（イベントは、例えば単に受信されたままのメッセージである場合もあるが、典型的には受信されたメッセージの内容又は形式に対する幾分かの変更を含む）。本実施形態はまたいくつかのＰＰＣモジュールと、ディスパッチャーモジュールとを含み、上記ディスパッチャーモジュールは、イベントを受信することと、同じフローのイベントを処理するためにすでにＰＰＣが割り当てられているか否かを決定することと、割り当てられていなければ、そのイベントに関連付けられたフローＩＤに関係なく、イベントを処理するためにそのイベントに適合する（互換性を有する）ように構成されているＰＰＣを選択することとを実行するように構成される。

さらに別の実施形態は、メッセージを処理するための装置であり、メッセージを受信するための手段と、フロー情報のステートフルプロトコル（ＳＰ）処理のための２つ以上の手段と、フローＩＤに関わりなく特定のフローの情報を処理するＰＰＣを選択するための手段とを含む。もう１つの実施形態は、２つ以上のＰＰＣマイクロプロセッサを含む装置であって、上記ＰＰＣマイクロプロセッサの各々が、割り当てられたフローに属する複数のメッセージについてＳＰ処理を実行するように構成され、このような割り当てられたフローのフロー状態を保持するローカルメモリを有する装置である。この実施形態はまた、メッセージ情報を受信し、１つのメッセージの少なくともフロー状態に関連した部分を第１のＰＰＣマイクロプロセッサへ転送し、もう１つのメッセージの少なくともフロー状態に関連した部分を第２のＰＰＣマイクロプロセッサへ転送するディスパッチャーを有する。

また、新規なサブシステムについて、それらのサブシステムを使用可能なＳＰＰＳのコンテキストにおいて説明する。一例はデータディスパッチャーサブシステムであり、もう１つの例はイベント導出システムである。これらのサブシステムの各々もまたさらなる複数のサブシステムを有することが可能であり、例えばデータディスパッチャーサブシステムは、複数のフローに係るフロー情報、特にＰＰＣにより現在処理されているのではない複数のフローに係るフロー情報を追跡するためのルックアップサブシステムを含み、及び／又は、ＰＰＣにより現在処理されている情報を追跡し続けるためのコア稼働状況マネージャサブシステムを含むことが可能である。データディスパッチャーサブシステムは、分配されるべき単一のフローに属する複数のデータイベントを、ＰＰＣの負荷状態に基づいて複数の並列なプロトコルプロセッサコアへ方向付けることが可能であり、また、特定のフローに係るデータイベントをどのプロトコルプロセッサコアも処理していないときには、その特定のフローに係るフロー状態を独立して保持することが可能である。

添付の図面及び下記の説明において、実施形態の詳細及びいくつかの代替例について述べる。本発明のすべての実施形態を本明細書において無理なく網羅することは不可能であるので、説明する実施形態は、本発明を限定するものとしてではなく、例示的なものとして理解されなければならない。

各図面における同様の参照番号及び名称は、全体を通して同様の構成要素を示す。

本説明を通じて、実施形態及び変形例は、本発明の用途及び実装の例示を目的として説明されている。例示的な説明は、本発明の範囲を限定するものとしてではなく、本発明の例を提示するものとして理解されるべきである。

ステートフルプロトコル処理は、識別可能かつ区別可能な装置に到来するデータであって、本明細書では「メッセージ」と称するデータを処理することを必然的に伴う。１つの「フロー」には多数のメッセージが属し、「フロー」は、当該フローを一意的に識別する「フローキー」にそれぞれ関連付けられた複数のメッセージにてなるグループである。ステートフルプロトコル処理に関して本明細書で説明する方法及び装置は、多数の異なるフローが同時にアクティブである場合に最も有用である。フローは、さらなるメッセージが予想される限り、そのフローのメッセージが現在処理されているか否かに関わらず「アクティブ」であり、その特定のフローに属するメッセージのさらなる処理が予想されないときに「非アクティブ」になる。

「ステートフルプロトコル」は、あるフローに属する複数のメッセージを、そのフローの状況を反映するために保持されている「状態」に従って処理するためのプロトコルを定義する。あるフローに属するメッセージのうちの少なくともいくつか（典型的にはその多数）は、そのフローの状態に影響を与え、よって、ステートフルプロトコル処理は、着信する複数のメッセージがそれらの属するフローに対して与える効果についてチェックすることと、それに従ってそのフローの状態（又は「フロー状態」）を更新することと、メッセージを、そのメッセージが属するフローの現在の状態に鑑みて適用可能なプロトコルの指示通りに処理することとを含む。

ＴＣＰ（伝送制御プロトコル）に従ってデータ通信を処理することは、ステートフルプロトコル処理の一例である。ＴＣＰフローは典型的には「接続」と呼ばれ、メッセージはパケットである。各パケットに関連付けられたフローキーは、主として終端アドレス（例えば発信元及び宛先の「ソケットアドレス」）からなる。フロー状態はアクティブな各接続（又はフロー）について保持され、処理されるフローの各パケットを反映するように更新される。データの実際の処理は、フロー状態とＴＣＰ処理ルールとに従って実行される。

ＴＣＰは、ＴＬＴ（トランスポート層端末）システムにおいて一般的に使用されるプロトコルである。典型的なＴＬＴはメッセージをパケットで受け入れ、パケットのヘッダ内に含まれる情報から、そのメッセージが属するフローと、メッセージを処理する際に使用すべきプロトコルとを識別する。しかしながら、メッセージが属するフローとメッセージを処理する際に使用すべきプロトコルとに対して当該メッセージを関連付けるために必要な情報は他の方法で提供されてもよく、例えば、それが関連付けられた別のメッセージから、もしくはそれが導出される特定のソースによって間接的又は暗黙的に提供されることが可能である（例えば、ある特定のホストが、アクティブなフローを一度に１つだけ有するということが知られている場合、暗黙的に、そのホストからの各メッセージは、そのホストに関してアクティブであるフローに属する）。

さらに、ここで説明するステートフルプロトコル処理は、ＴＬＴシステムとは異なる環境において利用されることも可能であり、その場合、フロー及びプロトコルに関する情報は、着信パケットのヘッダ以外の場所で適切に提供されてもよい。例えば、着信するＴＣＰパケットは、全く異なるプロトコルによって処理されるべきデータを、処理の異なる「階層」にカプセル化してもよい。従って、ここで説明しているＴＬＴシステムのコンテキストにおいて実行されるステートフルプロトコル処理は、一般的なステートフルプロトコル処理システム（「ＳＰＰＳ」）の特別な例を提供する。あるステートフルプロトコルフローに属するメッセージは、例えば、ある別個のステートフルプロトコルに属するメッセージ内にカプセル化されてもよい。「ＳＣＳＩ」と呼ばれる公知の通信プロトコルは、トランスポート層とは異なる階層におけるデータ通信の例を提供する。ＳＣＳＩの一般的な用途は、ホストと、ディスクドライブ等の周辺装置との間に存在する。ＳＣＳＩ通信はＳＣＳＩ通信専用の特殊目的の接続を介して実行されてもよく、又は、ＳＣＳＩ通信はカプセル化されて異なる階層を介して伝送されてもよい。ＳＣＳＩは、ファイバチャネル及びＴＣＰ等の、いくつかのトランスポート層プロトコルのメッセージ内にカプセル化されてもよい。「ＦＣＰ」は、ＳＣＳＩメッセージをファイバチャネルプロトコルのメッセージにカプセル化する際に使用されるプロトコルであり、「ｉＳＣＳＩ」は、ＳＣＳＩメッセージをＴＣＰメッセージにカプセル化する際に使用されるプロトコルである。ＦＣＰ及びｉＳＣＳＩは各々、ステートフルプロトコルである。

このようなカプセル化の一例は、ローカルネットワークを介して伝送されるｉＳＣＳＩフロー等の第１のステートフルフローに属する情報が、ＴＣＰ接続等の別個の第２のステートフルフローに属するメッセージ内にあるということを含む。第１のＳＰＰＳは、カプセル化するＴＣＰ接続（フロー）の状態を追跡し続けることができる。この同じＳＰＰＳ又は異なる第２のＳＰＰＳは、カプセル化フローによって伝送されるメッセージの中には、カプセル化されたｉＳＣＳＩフローに属するより高位のメッセージを形成するものがあるということを決定してもよい。カプセル化されたｉＳＣＳＩフローのフローキーは、カプセル化された各メッセージ内に含まれていてもよく、又はそれは、情報を伝送しかつカプセル化するＴＣＰ／ＩＰパケットのフローキーから暗黙的に決定されてもよい。カプセル化されたフローのフローキーと、カプセル化されたフローを処理する際に使用されるべきプロトコル（ｉＳＣＳＩ）とについての知識が与えられれば、ＳＰＰＳはｉＳＣＳＩフローの状態を保持することが可能であり、また、そのフローに関連付けられたメッセージを識別し、指定されたプロトコル（本例ではｉＳＣＳＩ）に従ってそのメッセージを処理することが可能である。

このように、トランスポート層端末システムはＳＰＰＳ（ステートフルプロトコル処理システム）の優れた一例を提供することが可能である。実際、ＴＬＴは少なくとも何らかのステートフル処理を含むことが見込まれ、よってＳＰＰＳとしての資格を備えている。しかしながら、ＳＰＰＳは、他のデータ通信の階層にも利用可能であり、ＳＰＰＳはまた、多数のメッセージが属するフローのフロー状態を更新することを含む処理に関する限り、それらのメッセージに関して定義されるステートフルプロトコルに従った他のタイプの処理にも利用可能である。従って、本発明は主としてＴＬＴシステムに関連して説明されているが、本発明がＴＬＴシステムに限定されるという不適当な推論がされないように注意が必要である。

図１Ａは、ＳＰＰＳ１００へのインターフェース接続を示す。ＳＰＰＳのパケット入力処理ブロック１０２は、任意個数の発信元からデータをパケットで受け入れることが可能である。これらの発信元は、典型的には、「ホスト１」１０４等のホスト接続と、「ネットワーク１」１０６等のネットワーク接続とを含むが、単一のシステムで、「ホストＮ」１０８及び「ネットワークＭ」１１０で表されるような他の任意個数のホスト接続及び／又はネットワーク接続が使用されてもよい。プロトコル処理ブロック１１２は、各データフローにつき適切な複数のルール（すなわち、そのようなステートフルプロトコルに従った処理が指定されているステートフルメッセージのための、公知のＴＣＰによって定義されたもののようなステートフルプロトコルの複数のルール）に従って着信データを処理する。フローは一般に双方向通信を含み、よって、データは典型的には、各ホスト接続及び／又はネットワーク接続との間で双方向に伝送される。最終的には、パケット出力処理ブロック１１４が、データを、典型的にはパケット入力処理ブロック１０２がデータを受信する際に用いたものと同じ接続にてなるセット（「ホスト１」１０４乃至「ホストＮ」１０８及び「ネットワーク１」１０６乃至「ネットワークＭ」１１０）へ伝送する。

図１Ｂは、コンピューティングシステム１５２内に実装されたときの、簡単なＳＰＰＳの一例を提供するＴＬＴＳ１５０への接続の概要を示す。単一のホストシステム１５４は、公知のＳＰＩ−４プロトコルを使用する接続１５６を介してＴＬＴＳ１５０へ接続される。ホスト１５４は、図１Ａに示したホスト１０４乃至１０８のうちの任意のものとして動作し、ＴＬＴＳ１５０にメッセージを送信し、またＴＬＴＳ１５０からメッセージを受信する。ＴＬＴＳ１５０は、もう１つのＳＰＩ−４プロトコルの接続１６０を介して媒体アクセス制御（Media Access Control：「ＭＡＣ」）装置１５８へ接続される。ＭＡＣ１５８は、適切な接続１６４を介してネットワーク１６２へ接続される。ＭＡＣは、ＴＬＴＳ用のデータ（この場合はＳＰＩ−４フォーマットにおけるデータ）と、ネットワーク１６２に対する接続１６４によって使用される物理的信号との間での変換を行う。ネットワーク１６２は内部に複数の接続及び複数の分岐を有していてもよく、「発信元／宛先システム１」１７０、「発信元／宛先システム２」１８０及び「発信元／宛先システム３」１９０で例示される遠隔の通信に係る発信元及び／又は宛先との間でデータを送受信して通信する。特定のネットワークを介して、通信に係る任意個数の発信元／宛先にアクセスすることが可能である。発信元／宛先システムは、コンピューティングシステム１５２に類似したものであってよい。さらに複雑な発信元／宛先システムは、図１Ａに示したもののような複数のホスト及びネットワーク接続を有していてもよい。従って、発信元／宛先システムの中には、様々な異なるネットワークを互いに効果的に接続するものがあってもよい。

図２は、例示的なＳＰＰＳ２００に係る複数のモジュールを示すブロック図である。ある実施形態では、「システムパケットインターフェースレベル４（ＳＰＩ−４）フェーズ２：物理層及びリンク層装置のためのＯＣ−１９２システムインターフェース．実施協定ＯＩＦ−ＳＰＩ４−０２．０，オプティカルインターネットワーキングフォーラム，カリフォルニア州フリーモント，２００１年１月（"System Packet Interface Level 4 (SPI-4) Phase 2: OC-192 System Interface for Physical and Link Layer Devices. Implementation Agreement OIF-SPI4-02.0," Optical Internetworking Forum, Fremont, CA, January 2001）（又は最新版）」に従う標準的なＳＰＩ−４の１６ビットバスをそれぞれ介して、２つのＳＰＩ−４ Ｒｘインターフェース装置２０２及び２０４がデータを受信する。接続の数は、それがシステムに必要な全体的処理能力に影響する限りにおいて重要であり、１つ乃至多数のインターフェースが接続可能である。個別のインターフェースはそれぞれ、任意個数のネットワーク及び／又はホストの発信元への通信を処理することが可能であり、別個の物理的なホスト及びネットワーク接続は必要ではないが、概念的及び物理的には便利である。さらに、ある実施形態では便宜上ＳＰＩ−４が使用されても、他の実施形態では、物理層に対するインターフェースのための他の任意の技術（例えばＰＣＩ−Ｘ）が、（２０２，２０４等の対応する入力ブロックにおける処理を準拠させることにより）代替としてか又は追加で使用されてもよい。

メッセージの分割．
同じく図２を参照すると、インターフェース２０２及び２０４によって受信されたデータは、処理のためにそれぞれメッセージスプリッタモジュール２０６及び２０８へ転送される。この転送は、典型的には、サイズ「Ｂ」のバス上で行われる。本明細書を通じて、「Ｂ」は、速度及びレイアウトに関する拘束条件を満たすように工学上の便宜に鑑みて選択可能なバスサイズを示すために使用するものであり、単一の値を表すものではないが、典型的には１６乃至１２８ビットの範囲内である。メッセージスプリッタモジュール２０６及び２０８は、複数のサービスの組み合わせを実行可能である。例えば、これらは、断片的にバーストで受信される複数の着信メッセージ（典型的にはパケット）を再組織化することが可能であり、その発信元及びコンテンツからパケットのタイプを識別して、後段の処理に係るタイプ識別を簡単化するためにメッセージへ何らかのデータを追加することが可能である。これらはまた、着信するメッセージを「ペイロード」データと「プロトコルイベント」（以後、単に「イベント」という。）データとに分割することが可能である。

ＳＰＩ−４インターフェースからデータが到来すると、２０６又は２０８等のメッセージスプリッタモジュールは、都合のよい幅Ｂを有するバスを介してデータのすべてをスクラッチパッドメモリ２１０における既知のロケーションへ移動させることが可能である。それに代わって、これは、ペイロードデータのみを、又はメッセージ全体の他のサブセットをスクラッチパッドに送ってもよい。スクラッチパッド２１０は様々な方法で構成されることが可能であり、例えばこれは、公知の先入れ先出し（first-in, first-out：ＦＩＦＯ）バッファとして機能することが可能である。さらに精巧な例では、スクラッチパッド２１０は、限定されてはいるが有用な個数の複数のページに組織化されていてもよい。各ページは、そのようなページで始まるスクラッチパッドに格納されているペイロード（又はメッセージ）が位置決めされる際に使用可能な、比較的短いスクラッチパッド参照ＩＤを有していてもよい。ペイロードが１つのページを超過すると、そのページの終わりには、続きとして次のページが認識されるように指示情報が提供されてもよく、このようにして、１つ又は複数のページからなるブロックに、第１のページの参照ＩＤによって識別可能な任意長のペイロード（又はメッセージ）が収容されることが可能である。ペイロード長は通常、受信されるメッセージのヘッダ情報の一部である。スクラッチパッド参照ＩＤはベースアドレスを提供してもよく、ペイロードは、予め決められた方法でベースアドレスを参照したメモリに配置されてもよい。ペイロードはペイロード長の終わりで暗黙的に終了し、よって、ヘッダにおいて示されたペイロード長と比較して検証するために、スクラッチパッドにより受信されたバイトのバイト数を独立に追跡することが有用な場合がある。スクラッチパッドがまたメッセージのヘッダも受信する場合には、そのヘッダは、スクラッチパッド参照ＩＤを参照することによって同様にアクセスされることが可能である。当然ながらこの場合、ペイロード長の検証はスクラッチパッドメモリモジュール２１０内で容易に実行可能であるが、このような検証は一般に、データ処理の観点での便宜上、発信元メッセージスプリッタ（２０６，２０８）内、ディスパッチャー２１２内、又はＰＰＣ２１６乃至２２２内のような、他の多くの場所で実行されることが可能である。

イベントの導出．
メッセージスプリッタ２０６及び２０８の典型的な機能は、着信するメッセージから、そのメッセージのステートフル処理に最も関連のある情報を導出し、このような情報が導出されたもとのメッセージと同じフローに関連する１つの「イベント」に当該情報をフォーマットして配置することである。例えば、多くのトランスポート層プロトコルによれば、フロー識別、ハンドシェイキング、長さ、パケットの順序、及びプロトコル識別を含む「状態に関連した」データは、パケットヘッダ内の既知の場所に配置される。各ステートフルプロトコルメッセージは、それが属するフローの状態に関連する情報を有し、このような状態に関連した情報は、それを識別できる場所に配置される。（ステートフルプロトコル処理を実行するシステムは、ステートレスメッセージ（すなわち状態を保持しないプロトコルのメッセージ）も処理できるという点に留意されたい。ＴＬＰは、例えば典型的には、アドレス要求プロトコル（Address Request Protocol）又はＡＲＰパケットのような、確立されたフローに関連付けられておらず従ってフロー状態に影響を与えることのないパケットも処理する。このような「ステートレス」パケットは、ここで説明している実施形態に適合する任意の技術によって処理されることが可能である。しかしながら、中心となることがらは、メッセージフローに係るフロー状態に実際に影響するステートフルメッセージの処理にあるので、本明細書ではこれらの技術についてこれ以上論じない。）

２０６又は２０８等のメッセージスプリッタモジュールによって着信メッセージから導出されるイベントは、広範な形態をとってもよい。最も簡単な例では、いくつかの実施形態においてこれはメッセージ全体である場合がある。より典型的には、イベントは、ＳＰ処理に必要な決定を下すためには必要とされない、いくつかの情報を除外することが可能である。例えば、ペイロードは多くの場合除外されて別に処理されてもよく、よって、イベントは単に、受信されたままのメッセージのヘッダになってもよい。しかしながら、実施形態によっては情報がヘッダに追加されるか、又はヘッダから除去されてもよく、その結果が再フォーマットされてＳＰＰＳにおける処理に便利な導出されたイベントが生成されてもよい。

イベントタイプの分類．
受信されたメッセージは、例えば、インターフェース（２０２，２０４）又はメッセージスプリッタ（２０６，２０８）モジュールによってある程度検査されてもよく、このような検査の結果は、そのイベントの「タイプ」を導出するために使用可能である。例えば、パケットが属するフローで呼び出されたプロトコルによるエラーチェックにおいて当該パケットに異常が存在しなければ、このようなパッケージから導出されるイベントは、そのメッセージのプロトコル及び明らかな有効性を反映するイベントの「タイプ」フィールドによって識別されることが可能である。従ってＳＰＰＳによって処理される異なる各プロトコルは、特定の「タイプ」を有してもよく、この情報はイベントに包含されて後続の処理に関する決定が簡単化されることが可能である。その他、メッセージの断片であるタイプが定義される場合もあり、このような断片は一般に、そのメッセージの残りが到来するまで、処理されずに保持される必要がある。メッセージの断片は、イベントのプロトコルに従ったサブタイプを有してもよいが、このことは必須ではない。さらなるイベントタイプが、エラーを有するメッセージとして定義される場合もある。イベントの「タイプ」は、後続するイベントの処理を方向付ける（制御する）ために有用な場合があるので、異なる処理が必要なエラーを有するメッセージは、一般的なエラーのサブタイプとして識別されることが可能である。一例として、エラータイプのイベントは、そのイベントのＳＰを反映するサブタイプによって識別されることが可能である。

後続の処理に影響を与えるメッセージ（又は導出されたイベント）に係る任意の特徴は、イベントタイプの分類のための候補となりうる。従って、イベントタイプの分類は、工学上の観点からＳＰＰＳの実施形態に適合させて、非常に簡単なものであってもよく又は複雑であってもよい。イベントタイプの分類は、イベントを導出する際に、受信されたメッセージ情報に対して実行されてもよい増補の一例である。他の増補には、チェックサムを改訂したり又は追加したりすること、もしくは受信されたメッセージの有効性に関して実行された様々なチェックの成功又は失敗を示す情報を提供することが含まれてもよい。また、スクラッチパッドメモリ２１０内でメッセージ情報を発見できる場所を示すスクラッチパッドロケーションのような、関連したロケーションが追加されてもよい。ただし、ホスト等の、ＳＰＰＳを用いるメッセージの発信元が、ＳＰＰＳまで伝送されるメッセージ（例えばヘッダ）内のこのような「増補する」情報の一部又はすべてを提供するように設計されている場合、そのメッセージスプリッタは、その情報を実際に追加して「増補された」イベントを取得する必要はないということに留意されたい。

メッセージ情報を増補することに加えて、イベントの導出は、ＳＰＰＳによるイベントのより便利な操作を許容するようにイベント情報を再フォーマットすることを含んでもよい。例えば、処理は、所定のタイプのイベント（システムによってはＴＣＰイベント等）に合わせて最適化されてもよく、他のタイプのイベントを導出することは、このような最適化された処理を適応させるように再フォーマットすることを含んでもよい。従って一般に、イベントは、受信されたメッセージに対して何も実行することなく導出されてもよく、又は、後の処理ステップの手助けとなるように、メッセージの情報、特に状態に関連した情報を増補したり、及び／又は再フォーマットしたりすることによって導出されてもよい。例えばＴＣＰの場合、結果的に導出されるイベントは、主として、不必要な情報が除去されかつコピーされる先のスクラッチパッドのロケーションを反映して情報が追加されたパケットの最初の２５６バイトと、エラーチェックの結果と、イベントタイプの分類とからなってもよい。ホストが、便利な形式でデータを作成するように設定されている場合、メッセージスプリッタから発行される結果的なホストイベントは、ほとんど変更されていないか又は全く変更されていないメッセージの最初のバイト（例えば最初の２５６バイト）であることが可能である。

メッセージスプリッタ機能の実装は、装置の設計を変更する必要なしにそれ自体の再プログラミングを支援する、マイクロコードを実行する組み込み型プロセッサを使用して行うことが便利な場合がある。しかしながら、メッセージスプリッタ機能は代替として、汎用プロセッサで実行されるソフトウェアを用いて、又は特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）において、もしくは他の任意の適切な方法で実装されてもよい。

２０６及び２０８等のメッセージスプリッタモジュールによって実行される複数の処理ステップにてなる特定のセットには、多くの代替例が可能である。例えば、フローＩＤの「ローカルプロキシ（ローカルな代理）」（すなわち、ＳＰＰＳ内のフローを識別するのに十分であり、かつローカルな処理のためにより有用である、メッセージのフローＩＤを表す数字）が決定され、上記ローカルプロキシが、図示した実施形態では後の処理ブロックの間に実行されるステップである、メッセージスプリッタにおけるイベントに追加される場合もある。また、着信するメッセージが分割される必要性は全くない。代わりに、着信する複数のメッセージは一緒に保持されてもよく、例えば、これらのメッセージは、システムの多数の部分により利用可能であるようにそのまま完全にスクラッチパッドメモリ内に格納されてもよく、又は、これらのメッセージは、その全体がイベントディスパッチャー２１２へ直接転送されて、そこから、詳細後述するプロトコル処理コア（ＰＰＣ）２１６乃至２２２へと転送されることが可能である。着信するメッセージが分割されない場合には、これらのモジュール２０６，２０８は、混乱を減らすために例えば「パケットプリプロセッサ」と改名されてもよい。当業者は、複雑なシステム内でどのモジュールが任意の特定の動作を実行するのかを多くの場合に主として設計上の便宜が決定するということを理解するであろう。

イベントディスパッチャー．
図２に示すように、メッセージスプリッタ２０６，２０８によって作成された複数のイベントは、イベントディスパッチャーモジュール２１２へ転送され、ここでそれらのイベントはキューメモリに入力されることが可能である。イベントディスパッチャーモジュール２１２（又は単にディスパッチャー）は、メッセージとともに到来するフロー識別「キー」に基づいて、ローカルフローＩＤプロキシの検索を開始することにより、着信するイベントの処理を開始できる。

ローカルフローＩＤプロキシ．
フロー識別キー（又は単に「フローキー」）は、フローによって使用されるＳＰ（例えばＴＬＰ）に従って、メッセージが属するフローを一意的に識別する。フローキーは非常に大きなものであってもよく（典型的には、ＴＣＰの場合で１１６ビット）、それ自体では、特定のフローに関連した、ＳＰＰＳによって保持された情報の位置決めのために便利なフォーマットではない場合がある。この目的で、代わりにローカルフローＩＤプロキシが使用可能である。ローカルフローＩＤプロキシ（又は単に「ローカルプロキシＩＤ」、「ローカルフローＩＤ」又は「プロキシＩＤ」）は一般に、ＳＰＰＳ内部の特定のフローを一意的に識別するのに十分な情報を含み、特定のフローに関連する情報をＳＰＰＳ内において位置決めするためにさらに有用にされることも可能である。例えば、ローカルフローＩＤプロキシは、ＳＰＰＳ内に保持されている特定のフローに関する情報（フロー状態等）を位置決めするための、フロー状態メモリ２１４へのインデックスとして機能するように選択されることが可能である。ローカルフローＩＤプロキシは、ＳＰＰＳを目的とするフローのより便利な代表となってもよいだけでなく、典型的にはより小さいものにもなる。

ローカルフローＩＤプロキシは、ディスパッチャーモジュール内で決定されてもよく、又は、前述のようなメッセージスプリッタモジュール２０６，２０８内のような他の場所で決定されてもよい。例えば複数の大規模なＴＬＴＳ（トランスポート層端末システム）において、保持される必要のある非常に多くの個数のローカルフローＩＤプロキシが与えられているものとすれば、プロキシＩＤを決定することが重要なタスクであってもよい。そうであれば、工学的観点からは、後述するようにこのような決定を別個の「ルックアップ」モジュールによって行なうことが好都合であってもよい。実施形態によっては、このようなルックアップモジュールは，メッセージスプリッタモジュール２０６，２０８のサブモジュールである場合もあり、又はこれはディスパッチャーモジュールのサブモジュールである場合もあり、又はこれは独立したものであってかつ他の様々なモジュールからアクセス可能なものとして最も良好に設計される場合もある。

ネットワーク上のフローメッセージに付随する通常のＳＰフローキーではなく（又はこれに加えて）ローカルフローＩＤプロキシを含むように構成されている、ホストから受信されたイベントに関しては、ローカルフローＩＤプロキシの検索が簡単化されてもよく、又は除外されさえしてもよい。このようなホスト構成は、どのようなモジュールであれ（例えばディスパッチャー）、当該ホスト構成を採用していなかった場合には当該モジュールがローカルフローＩＤプロキシを決定するという動作上の負荷を削減することができる。ローカルフローＩＤプロキシを照合する（ルックアップする）負荷を削減するためのもう１つの方法は、使用された最新のフローＩＤ及びこれらに関連付けられたプロキシの「クイックリスト」を保持して、メッセージ又はイベントが到来する毎にまずこのリストをチェックするというものが可能である。

ローカルフローＩＤプロキシ又はフロー状態のうちで対応した既知のものが存在しないフローに属するメッセージが到来すると、ディスパッチャー２１２は新たなローカルフロープロキシＩＤを生成することができる。多くの場合、ディスパッチャー（又はルックアップサブモジュール）は次に、このような新たなフローのフロー状態を初期化することができる。このようなプロキシＩＤは、このような新規なフローのフロー状態をフロー状態メモリ２１４等の都合のよいメモリに格納するために使用可能なメモリへのテーブルエントリとして機能する値として選択されることが有用な場合がある。このようなメモリは、大規模システムでは非常に大きなものであってもよく、このことは特殊な管理を必要とする。

メモリ．
本明細書に記述しているスクラッチパッドメモリ２１０及びフロー状態メモリ２１４等の別個の「メモリ」は各々、典型的には、メモリ単体だけでなく適切なメモリコントローラ装置も含む。しかしながら、メモリコントローラの機能は一般には本明細書における説明の要となるものではなく、ここでは単に、メモリが要求に応答して特定のデータブロックを格納すること、又は返すことのいずれかを必要としている。本明細書に記載したＳＰＰＳは、数百万のアクティブなフローを同時に処理できるように作成されてもよい（もしくは、数千又はさらに少ない数のアクティブなフローを処理することに制限されてもよい）ので、また、典型的なフロー状態は約５１２バイトであってもよく、それ故、図２のＳＰＰＳを実装するためには１ＧＢの何倍ものメモリが必要とされてもよい。このような大規模メモリを実装する技術は既知であって常に発展しており、このような既知の、又は今後開発される技術の任意のものは、そのようなメモリによって十分な性能が達成される限り、図２のＳＰＰＳを形成するために任意のタイプのメモリとともに使用可能である。複数のメモリは、それらが実質的に独立した方法で機能すれば、別個のメモリとして互いに区別される。例えば、１つのメモリに格納されたデータ項目をアドレス指定することが、別個のメモリにおける無関係の項目を同時にアドレス指定することを妨げないように、複数の別個のメモリは独立してアドレス指定されることが可能である。また、１つのメモリにおけるある項目へアクセスすることが、別個のメモリにおける無関係の項目へ同時にアクセスすることを妨げないように、複数の別個のメモリは独立してアクセスされることが可能である。このような独立性に起因して、複数の別個のメモリは、場合によって、複数の共通（又は共用）メモリに困難をもたらすデータアクセス上のボトルネックを除去することが可能である。

ルックアップサブモジュール．
図２に示したディスパッチャーモジュール２１２は、ディスパッチャーの複数のタスクのうちの特定のサブセットを実行する複数のサブモジュールを含んでもよい。例えば、到来するイベントに含まれているフローキーに基づいてローカルフローＩＤプロキシを照合する機能を実行する別個の「ルックアップ」モジュールを組み込むことが有用な場合がある。ディスパッチャー２１２のもう１つの機能は、各フローに関連付けられた特定のＳＰによって必要とされる場合があるように、複数のアクティブなフローのための複数のフロータイマを確立して維持することであってもよい。ローカルフローＩＤプロキシによってインデックスが付与されるこのような複数のフロータイマをメモリ内に維持することが好都合である場合、ルックアップモジュールはまた、これらのフロータイマをモニタリングする機能を便宜的に実行してもよい。またディスパッチャー２１２は、フローに係るイベントを処理するためにＰＰＣを割り当てる際に、フロー状態を当該ＰＰＣへ提供してもよい。このフロー状態が、メモリにおいて、ローカルフローＩＤプロキシによって付与されたインデックスを有するロケーションに同様に保持される場合、これは、ルックアップモジュールによって便宜的に実行されることが可能な別の機能になってもよい。このようなルックアップモジュールは独立したものであってもよく、又は本質的にディスパッチャーのサブモジュールであってもよい。ルックアップモジュールはまた、主としてシステムの他の複数のセクションに関連付けられてもよい。例えばこれは、ルックアップタスクが実行される場所がメッセージスプリッタモジュール２０６，２０８であれば主としてそのメッセージスプリッタモジュール２０６，２０８に（又はそのサブモジュールにも）関連付けられてもよく、ルックアップタスクが主にＰＰＣ２１６乃至２２２で実行されるのであれば主としてそのＰＰＣ２１６乃至２２２に関連付けられてもよい。

ルックアップ処理は、そのままのフロー識別情報又は「フローキー」に基づいてローカルフローＩＤプロキシを選択したり又は決定したりするために、ハッシュルックアップ手順等の大規模な処理を必要としてもよい。従って、ルックアップモジュール（又はサブモジュール）は、それ自体のマイクロプロセッサシステム及びサポート用ハードウェアを伴って実装されてもよい。フローＩＤプロキシの決定がルックアップモジュール（又はサブモジュール）によって実行される場合、ディスパッチャーは、決定が完了されるのを待機することなくＰＰＣへイベントを割り当てて転送することが可能であり、ルックアップモジュールは、ディスパッチャーとさらなる対話を行うことなく、割り当てられたＰＰＣへ（ローカルフローＩＤプロキシの使用により取得される）フロー情報を後で転送することが可能である。

「ルックアップ」サブモジュール又は他のサブモジュールが別個のエンティティとしていったん確立されると、それは、設計の便宜上、ディスパッチャー（もしくは、それが位置している他のモジュール、又はそれに関連付けられた他のモジュール）に帰属するタスクのうちの任意のものを実行するように構成されることが可能であり、実際に多くの場合、本明細書においてはメッセージスプリッタモジュール等の他の複数のモジュールに帰属した複数のタスクを実行することが可能である。異なる複数の機能モジュール間で機能を移動させる能力は、複合的な処理システムに共通する機能であり、当業者には、モジュール間で機能を移動することは一般にシステムを大幅に異なるものにするわけではないということが理解されるであろう。

その他、多くの機能がディスパッチャー２１２によって、又はそのサブモジュールによって実行されることが可能である。例えばディスパッチャーは、メッセージのペイロードを反映するスクラッチパッドメモリ２１０からのチェックサムを要求し、それを、イベントに変換されるメッセージの部分をカバーしかつイベントとともに含まれるチェックサムと組み合わせ、組み合わされたチェックサムをイベントに組み込むことが可能である。ディスパッチャー２１２と他の処理ブロックとの間には、この目的を達成するのに十分な適度のサイズのバスが図示されている。多くのディスパッチャー機能の場合と同様に、この機能は、メッセージスプリッタブロック２０６，２０８等の他の場所で実行されることも、又は後の処理の間に実行されることも可能である。

指示器サブモジュール．
ディスパッチャーに係る意志決定のうちの一部又はすべてを実行するために、もう１つのモジュール、又はディスパッチャーサブモジュールが生成されてもよい。「指示器（ダイレクタ）」と呼ばれるこのようなサブモジュールは、フローに係る特定のイベントを処理する特定のＰＰＣを選択することに関わるステップと、ＳＰＰＳ（ステートフルプロトコル処理システム）全体に関して、複数の様々なＰＰＣにおけるアクティブなフロー処理の状態を追跡することに関わるステップとを実行することが可能である。

指示器サブモジュールによって保持される「フロー処理状態」は、例えば、フローに係る他のイベントが現在所定のＰＰＣによって処理されていることを表してもよく、又は、ＰＰＣが（フローに係る）以前のイベントを処理した後で生じた新規なフロー状態が、現在フロー状態メモリへ書き込まれていることを表してもよい。これはまた、フローが分解されつつあるか否かを表してもよく、又はタイマイベントがそのフローに関して保留中であることを表してもよい。このようなフロー処理状態情報は、例えば、あるフローのフロー状態がＰＰＣからフロー状態メモリへ書き込まれつつあることを当該フローのフロー処理状態が示している間はフロー状態を上書きすることを防止する場合のような適切な場合には、指示器サブモジュールに、ＰＰＣへのイベントの転送を遅延させるように使用されてもよい。フロー状態メモリの更新がいったん完了すると、このことはフロー処理状態によって反映され、新規なイベントはＰＰＣへ転送されることが可能になる。

指示器サブモジュールのフロー処理状態情報はまた、例えば、フローがＰＰＣによって処理されている間にタイマの満了を示す信号が不適切に発行されることを防止するために使用されてもよい。イベントを処理する動作そのものがそのようなタイマの満了をキャンセルさせる場合には、このようなタイマイベントは発行されるべきでない。指示器サブモジュールは、タイマイベントがＰＰＣへ発行されることを許容する前にフロー処理状態情報を参照することが可能であり、よって、このようなタイマイベントは、そのフローに対してアクティブである他のイベントが存在しないときのみ発行される。ルックアップサブモジュールの場合と同様に、別個のモジュールとしての指示器の組織化された構成は、ディスパッチャーが着信するイベントを単に指示器へ伝送する（ハンドオフする）ことを可能にすることができる。

プロトコル処理コア及びバス−構造上の導入説明．
メッセージに対してローカルフローＩＤプロキシを確立すると、ディスパッチャー２１２は、フローに関連付けられたＳＰに従ってメッセージイベント（又は、メッセージとイベントとが分割されていなければメッセージ全体）がどこで処理されるべきかを決定する。実施形態によっては、大量のこのようなＳＰ処理が１つのプロトコル処理コア（「ＰＰＣ」）によって実行される。所定個数のＰＰＣを有するクラスタはＰＰＣ２１６乃至２１８で表されるとともに、ＰＰＣ２２０及び２２２は複数のＰＰＣにてなるもう１つのクラスタを表す。図示されているＰＰＣクラスタは２つであるが、任意個数のこのようなＰＰＣクラスタの使用が可能である。例えば、一実施形態に係るＴＬＴＳは単一のＰＰＣクラスタのみを備える場合がある一方、複雑な実施形態に係るＳＰＰＳは数百ものクラスタを含む場合がある。図２では１つのクラスタ内のＰＰＣのうちの２つが示されているが、与えられた任意のクラスタにおいて２つ以上のＰＰＣが使用されてもよく、典型的には１つのクラスタにつき５つのＰＰＣが存在する。設計の対称性にとって好都合であるが、各クラスタ内のＰＰＣの個数が同一である必要はない。複数のクラスタ内に複数のＰＰＣを特定的に組織化した構成は、部分的には、バスの輻輳を緩和することによってデータ転送を促進するように選択される。各クラスタは、各クラスタに係る複数のＰＰＣを相互接続するクラスタ内コア間バス２２４（又は２２６）を利用可能であり、各クラスタは、典型的には、バス２３０又は２３２によってバスネットワーク及び制御装置ブロック２２８に接続される。ディスパッチャー２１２と複数のＰＰＣとの間のデータは、バスネットワーク及び制御装置ブロック２２８によって組織化されることが可能である。バスネットワーク及び制御装置ブロック２２８は、後に詳述するように、複数の様々なモジュール間の通信を促進する「クロスバー」スイッチとして主に機能する。

複数のＰＰＣ（例えば２１６乃至２２２）は、典型的には、ＰＰＣに実行依頼されたイベントを当該ＰＰＣが処理できるようにするプロセッサコア及びマイクロコード（すなわち、プロセッサコアに対する何らかの形式の逐次的な命令）を含む。これらはまた、典型的には、ＰＰＣが他のＰＰＣに干渉することなくアクセス可能なローカルメモリであって、ＰＰＣによって処理されているフローに係る関連したフロー状態データを保持するのに十分なローカルメモリを含む。典型的には、特定のフローに係るフロー状態の多くの部分又はすべてを、そのフローに関するメッセージイベントを処理するＰＰＣのローカルメモリ内に保持することが好都合である。ＰＰＣのローカルメモリは、フロー状態をそれぞれ保持する能力を有する多数のブロック又は「ワークスペース」へと組織化されてもよい。ＰＰＣは、典型的には、着信するイベントのためのキューメモリと、ＰＰＣによって同時に処理されている上記キューメモリ内の複数のイベントを有する、いくつかの異なるフローのためのワークスペースとを有する。

本明細書に示したバスは、本質的に双方向性であるものとして説明されている。しかしながら、好都合であれば、バスは２つの一方向バスとして実装されてもよく、これらのバスは場合によっては両方の方向で異なるビット幅を有する。従って、Ｂビットの幅を有するものとして示されたバスは、特定の実装において便宜上選択されることが可能なバス幅であって、かつ方向に関して非対称であってもよいバス幅を表す。バスのサイズに関しては、物理的なレイアウトに係る空間的及びドライバに関する拘束条件と、特定の性能目標を達成するために必要な要求されるトラフィックとを含む、考慮すべき典型的な事項が適用される。バスは網羅的に図示されたわけではなく、例えば、ＴＰＴＳのすべての物理的な部品の間にはメッセージバスが（例えばデイジーチェーンで接続することによって）有用であるように接続されることが可能であるが、図２にはこのようなバスは明示されていない。さらに、ＳＰＰＳが、マイクロプロセッサをそれぞれ組み込んだ複数のＡＳＩＣを用いた典型的な実装においてではなく、汎用処理システム上で実行されるソフトウェア又はファームウェアにおいて複数のプログラムモジュールとして実装される場合には、図２に示されたバスは、ハードウェア信号ではなく、ソフトウェアモジュール間のデータ転送を表してもよい。

ＰＰＣへのイベントの割り当て．
本発明のいくつかの実施形態では、ディスパッチャー２１２は、特定のフローに関連付けられた複数のイベントを処理する特定のＰＰＣを選択する。このような割り当てに関しては、多数の考慮すべき事項が存在する。まず、ＰＰＣは、問題となっているタイプに属するイベントに適合し、又はそのイベントを処理するように構成されているＰＰＣのうちの１つである必要がある。このような適合性（互換性）は、ディスパッチャーにおいてか又はディスパッチャーのフロー処理状態サブシステムにおいて、ＰＰＣが適合するイベントタイプ又はプロトコルを示すＰＰＣテーブルにより決定されることが可能であり、次にこれは、着信するイベントのプロトコル又はイベントタイプの必要条件と比較されることが可能である。実施形態によっては、イベントは、別の処理段において、例えばメッセージスプリッタモジュールにおいてその「タイプ」を示す情報によりマーキングされる。従ってディスパッチャーは、予め決められたイベントの「タイプ」に基づいて、適合性のあるＰＰＣを選択するだけでよい。典型的には、イベントタイプは、特定のフローの状態に関連した情報を有するすべてのメッセージもまた同じイベントタイプを有しかつ上記すべてのメッセージが同じＰＰＣにより処理されることが可能であるように定義される。従ってＰＰＣは、指示されたイベントタイプを処理できるＰＰＣにてなるグループから選択される。

ＰＰＣは、例えばＰＰＣの負荷状態を比較して最小負荷のＰＰＣを発見することが可能なアルゴリズムに従って、もしくはラウンドロビン型でＰＰＣを選択可能なアルゴリズム又はランダムにＰＰＣを選択可能なアルゴリズムに従って、複数の適合したＰＰＣにてなる上記グループから選択される。典型的には、各フローに係る複数のイベントは、１つのＰＰＣへと特定的に方向付けられるのであって、複数のフローにてなるクラスの一要素として１つのＰＰＣへ方向付けられるのではない。各フローに係るこのような個別化された処理は、複数のフローにてなるクラスの属性に関わりのない負荷分散を可能にする。所定の特徴を備えた１つのフローＩＤ（又はフローキー）を共有するクラスのような、１つのクラスの要素として複数のフローが割り当てられる場合、多数のそのようなクラスが同時に処理される必要があって１つのＰＰＣの容量を圧倒しているが別のＰＰＣはロードされていないという状況が生じる。このことの影響は、多数の要素を有するクラスとして複数のフローがＰＰＣに割り当てられる場合にさらに悪化する場合がある。多くの実施形態は各フローを（サイズ１のクラスで）一意的に割り当てるが、実施形態によっては、複数のフローを複数のクラスに割り当てること、特に、複数の小さなクラスに割り当てること、又は変更可能な要素を有する複数のクラスであって、それによって負荷状態をバランス化させることが可能な複数のクラスに割り当てることが効果的である場合がある。

特定のフローを特定のＰＰＣへの割り当てから解放する機構が提供されていれば、複数のフローが１つの大規模なクラスに割り当てられているとしても、負荷分散に対して同様の効果を達成可能である。多くの実施形態では、ＰＰＣへのフローの割り当て及び解放の両方は、個別のフロー又は特定のフローに関して実行される。最終的には、ＰＰＣへの複数のフローの割り当てと、ＰＰＣからの複数のフローの解放との両方が、複数のフローにてなるクラスに対して実行されるとしても、負荷状態をバランス化させるように複数のクラスを柔軟に再割り当て可能にすることにより同等の効果を達成可能である。すなわち、ＰＰＣへ割り当てられるクラスが特定のフローのレベルで変更されることが可能であれば、負荷状態は大きな柔軟性をもってバランス化されることが可能である。いずれの場合でも、フローＩＤを特定の値にハッシュする特性等の任意の固定的なクラス属性とは本質的に関わりなく、また同様に、そのＰＰＣ（又は別のＰＰＣ）へ割り当てられる他のフローに関わりなく、１つのフローが最終的に１つのＰＰＣへと割り当てられるように、ＰＰＣへ割り当てられるフローを、単一のフローを単位として変更することが可能である。

あるＰＰＣを選択した後、ディスパッチャー２１２は、イベントを、フロー状態の「ワークスペース」に関する命令とともにそのＰＰＣへ転送する。先に述べたように、ＰＰＣを選択する決定は、ディスパッチャー内の指示器サブモジュールにおいて実行される場合がある。ある典型的な実施形態では、ディスパッチャー２１２はまず、着信するイベントが、すでにイベントを特定のＰＰＣへ割り当てているフローに属するか否かを決定する。実施形態によっては、ＰＰＣの稼働状況（アクティビティ）を追跡するコア稼働状況マネージャ（Core Activity Manager）等のサブモジュールがこの決定を実行してもよく、他の実施形態では指示器サブモジュールがこれらの機能を実行してもよい。着信するイベントのフローに係るイベントに関してＰＰＣがすでに割り当てられている場合、着信するイベントは典型的には同じＰＰＣへ転送され、このとき、上記ＰＰＣは、そのローカルメモリ内に存在しているフロー状態をすでに有していてもよい。

しかしながら、現時点でフローにＰＰＣが割り当てられていない場合には、ディスパッチャーは、着信するイベントを処理する特定のＰＰＣ、例えばＰＰＣ２１６を選択する（又はそのフローを特定のＰＰＣへ割り当てる）。選択は、様々な（互換性のある）複数のＰＰＣ上の負荷状態をバランス化させるために使用可能な稼働状態を保持する、コア稼働状況マネージャの情報に基づくことが可能である。実際の割り当て及びバランス化の決定は指示器サブモジュールによって行われてもよく、実施形態によっては、指示器とコア稼働状況マネージャとは、実質的に、これらのタスクを実行するための専用のプロセッサ及びプログラムコードを有する単一のサブモジュールである。割り当ては、単に、適合したＰＰＣであって最も新しくイベントを受信したＰＰＣに対する「ラウンドロビン」型であってもよく、あるいは、ＰＰＣのキューメモリの空き状況を基準とするもの又はその他であってもよい。

着信するイベントを処理するＰＰＣ２１６が割り当てられた後、ＰＰＣ２１６のローカルメモリにおいてワークスペースが選択され、選択されたワークスペースにおいて、着信するイベントのフローに係る現在のフロー状態が確立される。ワークスペースの選択は、ディスパッチャーモジュールによって（例えばその指示器サブモジュールによって）実行されてもよく、又はさもなければ利用可能な順で次のＰＰＣによる、等によって実行されてもよい。フロー状態は、選択されたワークスペースにおいて任意の好都合な方法で確立されることが可能である。例えば、ディスパッチャーは、ディスパッチャーを介して（例えばルックアップサブモジュールの動作として）フロー状態をＰＰＣへ送ることが可能であり、又は、ＰＰＣ自体がメモリ（例えばフロー状態メモリ２１４）からフロー状態を要求することも可能である。イベントは、典型的には、ディスパッチャー２１２からＰＰＣ２１６の入力キューメモリへ送られ、選択されたワークスペースに関連付けられる。また、スクラッチパッドメモリ（もしあれば）内のデータペイロードのサイズ及びロケーションも、別個に、又はイベントの一部として、典型的にはＰＰＣ２１６へ伝送される。この情報を有する場合、ＰＰＣ２１６は、イベントがキューメモリに到達した時点でこれを処理することが可能になるが、この点については後に詳述する。ＰＰＣ２１６は、特定のイベントの処理を終了すると、実施形態によっては「完了」メッセージをディスパッチャー２１２へ送信し、そのため、ディスパッチャーはこのＰＰＣの稼働状況を追跡することができる。当然ながら、コア稼働状況モジュール又は指示器のようなサブモジュールがこのような追跡を実行してもよい。

アクティブなフロー処理を追跡するイベントのカウント処理．
選択されたＰＰＣ（２１６）にイベントを送信すると、ディスパッチャー２１２は、フローに関連付けられた（従ってＰＰＣ２１６に関連付けられた）ロケーションにおいてイベントカウンタをインクリメントする。イベントカウンタは、現在のＰＰＣ処理に関するこうした情報のために予約され、ローカルフローＩＤプロキシに関連付けられたローカルメモリブロック内（例えば、ディスパッチャー内のコア稼働状況マネージャ内）に保持されることが可能であり、又は他の好都合なロケーションに保持されることが可能である。イベントカウンタは、イベントがそのＰＰＣへ送信される毎にインクリメントされ、ＰＰＣがそのフローに関する「完了」メッセージを返信する毎にデクリメントされる。イベントカウンタが非ゼロである限り、ＰＰＣは、関連付けられたフローに関するイベントをその時点で処理している。イベントカウンタが特定のフローに関してゼロに到達すると、ＰＰＣ（２１６）はもはやその特定のフローに関して処理すべきイベントを持たず、そのリソースのうちの当該特定のフローを処理するために割り当てられていたものは、他のフローを処理するために解放されることが可能である。ただし、ＰＰＣ２１６は他のフローのイベントを処理している場合があり、この特定のフローを処理することからのその解放は、このような他のフローとは関わりなく実行可能であるということに留意されたい。

ディスパッチャー２１２に到来するイベントのフローに関連付けられたイベントカウンタがゼロでなければ、その到来するイベントを同じＰＰＣへ割り当てて転送することが好適である。実施形態によっては、ＰＰＣがあるイベントをすでに処理中である場合には、フロー状態のグローバルな（すなわちフロー状態メモリ２１４の）バージョンはもはや無効であり、ＰＰＣワークスペースにおけるフロー状態のみが有効である。このような実施形態では、現在のＰＰＣワークスペースにおける有効なフロー状態は、続いて選択されるＰＰＣにとって利用可能とされる必要があるが、このことは、現在のＰＰＣがイベントの処理を終了した後でのみ実行される必要がある。従って、少なくともこのような実施形態では、ＰＰＣが、選択されたフローに関わるすべての実行中のイベントを完了させるまでは、その選択されたフローに属する到来するイベントを処理するために同じＰＰＣを割り当てることが、一般的にはより好都合となるであろう。

ディスパッチャー２１２へ到来するイベントであって、あるＰＰＣにすでに割り当てられている特定のフローに関するイベントは、時として、異なるＰＰＣへ転送されたり又は割り当てられたりすることが必要な場合がある。こうした場合には、現在のＰＰＣが、割り当てられているすべてのイベントの処理を完了するまで、イベントをディスパッチャー２１２内に保持しておくことが好都合である。ディスパッチャー２１２内にイベントを保持しておくことは、特定のフローに係るフロー状態を同時に更新している２つのＰＰＣを調整する必要性を除去する。またこのようなハンドオーバー処理が発生する前に、ＰＰＣがそのワークスペース（現在のフロー状態を反映するメモリ）を新規なＰＰＣの割り当ての前にフローメモリへ「チェックイン」できるようにすることが好都合である。それに代わって、ワークスペースは、現在のＰＰＣのキューメモリに係るすべてのイベントが処理された後に、現在のＰＰＣから新規なＰＰＣへ直接転送されることも可能である。

アクティブであるフローに関連してディスパッチャーにイベントが到来したが、ディスパッチャー２１２にイベントが到来した時点で関連のイベントカウンタがゼロであれば（その時点でフローに割り当てられたＰＰＣが存在しないことを示す）、ディスパッチャー（又はその指示器サブモジュール）は、そのイベントタイプを処理するために利用可能なＰＰＣを選択する。この選択は典型的には先行した処理とは独立したものであり、負荷の共有や、イベントタイプ処理の能力のような、様々な因子に基づくことが可能である。従って、次に選択されるＰＰＣは、そのフローに属するイベントを以前に処理したＰＰＣとはおそらく異なるであろう。しかしながら、ＰＰＣが実際に有用な状態情報を保持している場合のようないくつかの実施形態では、特定のＰＰＣによる特定のフローに係る先行した処理に対して考慮が払われてもよい。いったんＰＰＣの選択が実行されると、前述のように処理は継続され、イベントは新規なＰＰＣへ伝送され、フロー状態は、ＰＰＣ内において選択されたローカルなワークスペース内に配置される。ディスパッチャー２１２は、現在のフロー状態を新規なＰＰＣへ転送するか、フロー状態メモリ２１４内のどこに現在のフロー状態が発見されるかということを示すかのいずれかを行う。

イベントカウンタは、特定のＰＰＣがその時点で同じフローの先行したイベントを処理しているか否かを決定するために使用可能な一手段にすぎない。代替として、例えば、あるフローに係るあるイベントをその時点で処理しているＰＰＣは、アクティブなワークスペースに関連付けられたその入力キューメモリ内にイベントを発見しない場合に、ディスパッチャー２１２に対してフラグを発行してもよい。その他、ＰＰＣがその時点で特定のフローの処理に割り当てられているか否かの決定には、任意の適切な手順が使用されてもよい。

フロー状態の更新とＰＰＣの解放．
ＰＰＣは、関連付けられたイベントカウンタがゼロに到達した後で、特定のフローに係るイベントを処理する責務から解放されることが可能である。よって、一般にワークスペースはフリーにされるので、このような解放は、ＰＰＣが異なるフローに係るイベントの処理に割り当てられてもよいということを意味する。一般に、ＰＰＣは同時に別のフローを処理していてもよく、上記解放は、このような他のフローに対するＰＰＣの責務に影響することはない。特定のフローに係るイベントが処理のために別のＰＰＣへ再割り当てされてもよいということをイベントカウンタ（又は他の指示情報）が示す典型的な状況では、ＳＰＰＳは、（そのフローに係るイベントタイプを処理できるＰＰＣのうちの）異なる複数のＰＰＣの間で、上記複数のＰＰＣによって処理されている他のフローとは独立に特定の個々のフローをシフトすることにより、ＰＰＣ処理の負荷をバランス化させることが可能にされる。複数のフローにてなるクラス（所定の特性を有するフローキーをそれぞれ備えた複数のフローにてなるクラス等）に係るイベントを複数のＰＰＣに処理させる技術に比べて、このような独立したフロー割り当ては、１つ又は複数のＰＰＣがアイドル状態であって別のＰＰＣは継続的にイベントを処理しているということの統計的確率を低下させてもよい。

ＰＰＣが解放される前に、ＰＰＣ（２１６）によって更新されているフローメモリは、後に同じフローを処理するために選択される異なるＰＰＣにとって利用可能になる場所に格納される。このことは、任意の適切な方法によって達成可能であり、例えば、関連したＰＰＣワークスペースのコンテンツをディスパッチャー２１２へ転送し、かつそこからフロー状態メモリ２１４へ転送することによって達成可能である。それに代わって、ＰＰＣ（２１６）は、ディスパッチャー２１２と協働してフロー状態情報をフロー状態メモリ２１４内の既知のロケーションへ転送することが可能であり、そのため、ディスパッチャーは、フロー状態が更新されていて将来のアクセスのために準備完了しているということを認識する。フロー状態は、バスネットワーク及び制御装置ブロック２２８からのバス２３４等を介して、ＰＰＣ（２１６）からフロー状態メモリ２１４へ、より直接的に伝送されることが可能である。バス２３４は、フロー状態メモリ２１４からＰＰＣへのフロー状態の「チェックアウト」のため、又はＰＰＣからフロー状態メモリ２１４への更新されたフロー状態の「チェックイン」のためのいずれかに使用可能である。イベントカウンタがゼロに到達し、フロー状態がフロー状態メモリ２１４へチェックインされたとき、その時点でのＰＰＣは解放されることが可能であり、フローは、その時点でそれに割り当てられたＰＰＣが存在しないことを反映する状態に戻る。ＰＰＣ内部では、フロー状態のワークスペースがフリーであると示されてもよい。

実施形態によっては、フロー状態をフロー状態メモリ２１４内に格納するために代替の方法が使用されてもよい。ＰＰＣにおいてローカルに設けられた十分なメモリが提供されているＳＰＰＳの場合、フロー状態は、それが別のＰＰＣ等の他の場所で必要とされるようなときまで、それを処理した最後のＰＰＣのワークスペース内に保持されてもよい。このような実施形態では、フロー状態は、２２４又は２２６等のクラスタ内バスを介して新規なＰＰＣ内の適切なワークスペースへ転送されることが可能である。このことは、限られた個数の同時的なフローを処理する小規模なＳＰＰＳの場合において、実際的な代替方法としてさらにふさわしい。

ソケットメモリと出力処理．
例えばＴＣＰのような、メッセージの配信を保証するＴＬＰアプリケーションにおいては、送信されたメッセージが正しく受信されたことの確認が１つの必要条件である。これらのＴＬＰでは、メッセージが正しく受信されなければ、そのメッセージは再送信される必要がある。再送信の要求が到着するにはしばらく時間がかかる場合があるので、送信されたメッセージは、所定時間期間だけメモリ（例えば「送信バッファ」）内に保持される必要がある。送信バッファを使用することは、最初の送信より前であっても要求される場合があり、例えば出力宛先（例えば図２のホスト１ １０４又はネットワーク１ １０６）においてデータの受け入れ準備ができていないときに要求される。同様に、「受信バッファ」もしばしば必要とされる。例えば、複数のメッセージは、本来とは異なる順序で受信され又は断片的に受信される場合があるが、これらは、メッセージを完成させてそれらメッセージを正しい順序にすることを必要とするＴＣＰのルールに従うために、所定時間期間だけ保存される必要がある。メッセージは、簡単にスクラッチパッドメモリ２１０に格納されることも可能ではあるが、大型の送受信バッファを伴う大規模システムの場合には、別個の「ソケットメモリ」２３６を確立して大量のデータを幾分延長された期間に渡って格納することがより好都合である。このようなソケットメモリ２３６は、図２に示すようにバス２３８を介してスクラッチパッドメモリ２１０とインターフェースをとり、もう１つのバス２４０を介してバスネットワーク及びＰＰＣクラスタ制御装置２２８とインターフェースをとることが可能である。（多大なトラフィックに起因して、実施形態によっては、バス２４０は実際にはいくつかの個々のバス構造を備えてもよい。）

ソケットメモリ２３６は、出力するためのデータを、バス２４６及び２４８を介して出力プロセッサ及びＳＰＩ−４インターフェース２４２，２４４へ提供することが可能である。しかしながら、出力されるべきデータがまだスクラッチパッドメモリ２１０内に存在しているとき、場合によってはそのデータをバス２５０，２５２を介して出力プロセッサ２４２，２４４へ直接提供する方が速い。出力処理は、メッセージのヘッダを主としてイベントデータから準備すること、チェックサムを計算すること、及び完成された出力メッセージをアセンブルすること（「再アセンブル」すること）等のタスクを含んでもよい。イベントは、典型的には何らかのタイプのＳＰ又はイベントタイプ識別情報を保持し、出力プロセッサはこの情報を用いて、ヘッダ、巡回冗長検査（cyclic redundancy checks：ＣＲＣ）及び他のＳＰ記帳（ブックキーピング）情報の適切なフォーマットを決定することが可能である。出力プロセッサによってメッセージが再アセンブルされた後、出力装置２４２及び２４４のＳＰＩ−４部分は、データがＳＰＰＳへの入力の際に受信された接続と同じ接続（例えば「ホスト１」１０４及び「ネットワーク１」１０６）へデータが出力されることが可能であるように、ＳＰＩ−４（又は他の選択された）インターフェースプロトコルに従ってメッセージをフォーマットする。

プロトコルプロセッサコアの機能．
ＰＰＣは、適正なタイプのイベントを受信して任意のペイロードのサイズ及びロケーションを反映した情報をいったん有すると、使用されているＳＰに従ったメッセージ全体の処理を管理することが可能である。ＰＰＣは、例えば再送信を要求することや、以前に送信されたメッセージを再送信することなどの、イベントが属するフローに関する動作を管理することが可能であり、かつそのフローのフロー状態を適宜更新することが可能である。実施形態によっては、ＰＰＣが物理的にメッセージを出力プロセッサ（２４２，２４４）へ直接転送せず、単に他の回路を制御することによって出力プロセッサ２４２，２４４における再アセンブルのためにメッセージを転送させるならば、トラフィックの輻輳を削減することが可能である。

発信するメッセージの中には、肯定応答又は再送信要求等の情報をほとんど含まない（例えば、ヘッダ以外に、ほとんど何も含まないか又は全く含まない）ものがある。このような場合、イベントを処理しているＰＰＣ（例えばＰＰＣ２１６）は、イベント情報に基づいてヘッダを形成し、これをソケットメモリ２３６へ転送してもよい。次いでソケットメモリ２３６は、ヘッダ情報に対してほとんど何も実行することなく、又は何も実行することなく、これを出力プロセッサ２４２，２４４のうちの一方へ転送する。発信する他のメッセージは、例えば、着信するメッセージとともに受信されてスクラッチパッドメモリ２１０に格納されていてもよい、実質的なペイロードを含む。ＰＰＣは、このようなペイロードを、スクラッチパッドメモリ２１０からソケットメモリ２３６へ移動されるように方向付けることが可能であり、また、このようなペイロードのうちの１つを、例えば出力プロセッサ２４２，２４４の一方において、ＰＰＣにより形成された適切なヘッダと縦続接続されるように別個に方向付けることが可能である。コンピュータアーキテクチャの分野の当業者には、ＰＰＣは出力メッセージ及びフロー状態情報を多くの方法で制御できるということが認識されるであろう。

ＰＰＣは、その機能と矛盾しない任意の方法で実装されることが可能である。例えば、マイクロプログラマブルプロセッサは、変化する通信上のニーズを処理する際にあるレベルの柔軟性をもたらす。それに代わって、いくつかのＰＰＣ又はすべてのＰＰＣは、固定状態マシンとしてハードウェアで実装されてもよく、回路サイズは縮小され、及び／又は処理速度は増大される。またさらに、いくつかのＰＰＣ又はすべてのＰＰＣは、ＳＰＰＳがアクティブである間であっても、「オン・ザ・フライ」で変更可能なプログラムメモリに基づいて動作可能な組み込み型マイクロプロセッサを備えることが可能である。このような実装は、特定のタイプのイベントを処理できるＰＰＣの個数を調整して、さらなる負荷分散の柔軟性を追加することを可能にする。ＰＰＣは、いくつかのステートフルプロトコルを処理し、その他は処理しないように構成されてもよく、この構成は固定されたものであっても、又は可変であってもよい。例えば、マイクロプログラマブルプロセッサに基づくＰＰＣでは、マイクロプログラム（又はソフトウェア）は、典型的には、ＰＰＣがどのイベントタイプ又はプロトコルを処理するように構成されるかを決定する。ＰＰＣが、このようなイベントタイプを処理するように、又はこのようなプロトコルに従ってメッセージ（イベント）を処理するように構成されている場合、このＰＰＣは特定のイベントタイプ又はプロトコルに「適合する（互換性を有する）」。

バスネットワーク及びＰＰＣクラスタ制御装置．
図３は、図２のバスネットワーク及びＰＰＣクラスタ制御装置２２８の例示的なアーキテクチャを示す。この実施形態では、複数のＰＰＣ（２１６乃至２１８）にてなるクラスタは、クラスタバスインターフェース３０２を介して部分的に制御される。命令は、典型的にはＲＡＭを用いて実装された命令メモリ３０４から、クラスタバスインターフェース３０２を介して、クラスタ内のすべてのＰＰＣ（２１６乃至２１８）によって利用されることが可能である。クラスタバスインターフェース３０２はまた、クラスタ内のすべてのＰＰＣに、ルーティング制御テーブル３０６へのアクセスを提供することが可能である。クラスタのＤＭＡコントローラ３０８（「Ｃ ＤＭＡ」）が提供されることも可能であり、これは、ＤＭＡコントローラ３０８のＦＩＦＯからクラスタバスインターフェース３０２へデータを伝送するとともに、上記ＦＩＦＯからクラスタのＰＰＣ２１６乃至２１８の各々のデュアルポートメモリ（例えばＤＰＭＥＭ３１０，３１２）における一方の側へデータを伝送する出力バスを有することが可能である。ＤＰＭＥＭ３１０，３１２は、ＤＭＡコントローラとは異なる側においてその対応するプロセッサにアクセス可能であり、ＤＰＭＥＭ３１０，３１２は、ＰＰＣ２１６，２１８の一部として上記対応するプロセッサと関連付けられている。図３に示すように、ＤＭＡコントローラ３０８は別個の入力バスを有することが可能であり、ＦＩＦＯは、上記入力バスによって、デュアルポートメモリ（例えばＤＰＭＥＭ３１０，３１２）とクラスタバスインターフェース３０２とからデータを受信する。ＤＭＡコントローラ３０８は、例えば、ＰＰＣのローカルメモリとフロー状態メモリ２１４との間でフロー状態を転送するために使用可能である。図３に示すように、クラスタバスインターフェース３０２はまた、双方向バス接続をメッセージバス３１４へ提供し、さらなる双方向バス接続２４０ｂをソケットメモリ２３６へ提供する。ＰＰＣのローカルメモリのうちの一部又は実質的な全体は、ＤＰＭＥＭ３１０等のＤＰＭＥＭであることが可能であるが、設計及び製造上の都合により、任意の適切なローカルメモリが代わりに使用されてもよい。

図３には、ソケットメモリ２３６とバスネットワーク及びＰＰＣクラスタ制御装置２２８とを相互接続するバス２４０が、３つの別個の双方向バス、すなわちソケットメモリ２３６とメッセージバス３１４とを相互接続するバス２４０ａ、上述のバス２４０ｂ、及びさらなるクラスタバスインターフェース３１６に至るバス２４０ｃによって実装されたものとして示されている。クラスタバスインターフェース３１６は、ＰＰＣ２２０乃至２２２にてなるクラスタに関連してクラスタバスインターフェース３０２と相似的に、複数のＰＰＣとメッセージバス３１４及びソケットメモリ２３６との間の通信を促進するクロスバースイッチであって、共通の命令メモリ３１８及びルーティングテーブル３２０へのアクセスを提供するクロスバースイッチとして動作する。さらなるクラスタＤＭＡ３２２は、ＰＰＣ２２０乃至２２２のデュアルポートメモリとクラスタバスインターフェース３１６との間のデータフローを同様に管理する。当然ながら、さらなる類似した複数のモジュールにてなるセット（ルーティング、命令、クラスタバスインターフェース、及びクラスタＤＭＡ）が提供されて、同様に相互接続されることも可能である。

コンピュータアーキテクチャの分野の当業者には、バスネットワーク及びＰＰＣクラスタ制御装置２２８について示した接続を実装するために、適切な任意のバス制御を使用可能であるということが認識されるであろう。例えば、ルーティング及び命令の情報は、個別のＰＰＣ内に保持されることが可能である。さらに、ＰＰＣメモリはデュアルポートである必要はなく、３０８又は３２２等のＤＭＡコントローラも必要ではない。さほど複雑でない実施形態では、クラスタバスインターフェース３０２，３１６は単にメッセージバス３１４の一部であってもよく、あるいはインターフェースは完全に省かれていてもよい。反対に、いくつかの実施形態ではその速度及びパワーを増大させるために、さらに精巧なバスアーキテクチャを使用してもよい。

代替のプロトコルコアを用いたフロー処理．
図４は、一般に複数のＰＰＣ（プロトコル処理コア）を交代させる、すなわち異なるときに異なるＰＰＣを使用する、あるフローに属するメッセージのステートフルプロトコル処理を実行するために例示的なＳＰＰＳによって実行されることが可能な動作を示すフローチャートである。図４に示すように、ステップ４０２でメッセージが受信される。このステップは、パケットの断片から完全なメッセージを再構成すること、有効性のチェックを実行すること、及び／又はチェックサムを確立すること等の様々なサブステップを含んでもよい。次に、ステップ４０４において、メッセージのペイロードはスクラッチパッドメモリへ移動されることが可能である。ステップ４０４が、メッセージを分割することと、特に入力処理装置及び出力処理装置の両方にとって利用可能な一時的メモリロケーションにメッセージの一部を格納することとを示す限り、このステップ４０４はオプションである。代替として、例えば、メッセージは一緒に保持されてもよく、及び／又は、より永久的なメモリロケーションに直接移動されてもよい。

ステップ４０６へ進むと、メッセージのイベント部分の定義が生成されることが可能である。イベントの定義は、典型的にはメッセージの状態に関連した部分を含み、また、先に詳述したように、イベントのさらなる処理を促進するために、メッセージのヘッダを再フォーマットすることと、チェックサム及びイベントタイプを示し情報等の、情報を追加することとを伴ってもよい。メッセージが分割されない場合には、「イベント」はペイロード情報を含んでもよく、実質的に受信されたままの着信メッセージでありさえしてもよい。イベントの処理はステップ４０８へ進み、ここでは、イベント内に含まれてフローを一意的に識別するデータ（「フローキー」）が検査され、フロー状態情報のロケーション及びローカルフローＩＤプロキシを決定する処理が開始される。決定ステップ４１０は、同じフローのイベントをＰＰＣがアクティブに処理しているか否かをチェックする。このチェックは、ローカルな「アクティブフロー」テーブルにおいてフローキーを検索することにより実行可能である。「アクティブフロー」テーブル内にフローキーが発見された場合、ＰＰＣはその時点で同じフローに属する別のイベントを処理しており、処理は決定ステップ４１０から「ｙｅｓ」の分岐に進む。フローがアクティブでない場合には（例えば「アクティブフロー」テーブル内にそのフローのフローキーが発見されない場合には）、処理は決定ステップ４１２に進んで継続される。ステップ４１０では、そのフローキーに関連付けられたイベントがその時点で任意のＰＰＣによって処理されているか否かを決定するために、その時点で１つのＰＰＣ（例えば、ディスパッチャーのコア稼働状況管理サブモジュール内）によって処理されているメッセージフローの状態のために予約されたメモリのエリアを探索することのような、他の技術が使用されてもよい。それに代わって、例えば、あるＰＰＣにおいて処理が進行中であることを示す情報（例えばフラグ）を求めて、単一のフロー状態ロケーションが検査される場合もある。ＰＰＣがフローをアクティブに処理しているか否かを決定するためのさらなる技術及び基準については、決定ステップ４２８を参照して後述する。

決定ステップ４１２では、そのフローキーに関連付けられたフローがＳＰＰＳにおいてアクティブであるか否かについてチェックが行われる。これは、その時点でフローのイベントを処理しているＰＰＣが存在しない場合にアクティブなフローのフロー状態を保持するフローメモリ内の有効なフローロケーションをチェックすることによって実行されることが可能である。（アクティブなフローの個数は非常に大きなものになる場合があるので、フローメモリは典型的には別個のものであり、別々にアクセス可能なものであり、かつその時点でＰＰＣによって処理されているフローに使用されるローカルフローテーブルよりずっと大きなものである。）このステップは、典型的には、そのフローキーに関連したローカルフローＩＤプロキシを決定する「ルックアップ」タスク、ハッシュアルゴリズムに従ってフローキー情報を処理することに関わりのあるタスクを含む。ローカルフローＩＤプロキシがいったん決定されると、これは一般に、そのフローキーに対応したフローに係る既存のフロー状態を位置決めするために使用可能である。有効なフロー状態が単に存在していることは、決定ステップ４１２において肯定的結果をもたらす。

一般的なフロー状態メモリにも、またフローをアクティブに処理しているＰＰＣにも有効なフロー状態が存在しないような、フローが全くアクティブでない場合には、処理は初期化ステップ４１４へ進んで、フロー状態メモリ内に有効なフロー状態エリアを生成して初期化する。ただし、フローに属さないイベントであり、かつイベントに対して生成される必要のあるフローが存在しないイベントである、アドレス解決プロトコル（Address Resolution Protocol：ＡＲＰ）イベントのような、フロー状態を要求しないいくつかのステートレス「イベント」が存在するということに留意されたい。ＡＲＰ及び他のこのような「ステートレス」イベントは、主として「ステートフル」イベントに関連する図４の処理ステップとは独立して処理されることが可能である。

アクティブなフローがいったん確立されると（決定ステップ４１２で位置決めされたか、又は初期化ステップ４１４で初期化されたかには関わらない）、本方法は、割り当てステップ４１６に進んで、イベントを処理するＰＰＣを割り当てることが可能である。このステップは、そのイベントを処理するためにはどのＰＰＣが適合し（すなわち該当するタイプのイベントを処理する能力があり）かつ利用可能である（例えばそのキューメモリに余地がある）かを決定して識別すること等の、いくつかのサブステップを含むことが可能である。ＰＰＣは、上記基準の両方を満たすものの中から、ラウンドロビン型による方法、又は最も空きの多いＰＰＣのローカルキューメモリを選択する方法、又はランダムな方法、もしくは他の負荷分散アルゴリズムによる方法等の多くの方法で選択されることが可能である。ＰＰＣはそのイベントを処理するために新たに割り当てられたばかりであるので、ステップ４１８においてＰＰＣはフロー状態を利用できるようになる。フロー状態は、先に述べたようにディスパッチャー（又はサブモジュール）によって配信されることが可能であり、もしくは、グローバルなフロー状態メモリが、割り当てられたＰＰＣと共用されている場合には、このステップは、フロー状態メモリのロケーションの識別情報をＰＰＣに提供することを含んでもよい。ステップ４１８はまた、典型的には、処理中にＰＰＣがフロー状態にアクセスすることができる「ワークスペース」のロケーションを識別することを含む。このようなワークスペースは、典型的にはＰＰＣにおいてローカルに保持されるが、実施形態によっては、よりグローバルに保持されることも可能であり、ローカル及びグローバルの両方に分割される場合もある。

ステップ４１８の後（又は肯定ステップ４１０の後）に生じるように、いったんＰＰＣの割り当てが完了しかつＰＰＣが有効なフロー状態を有すると、処理はステップ４２０及び４２２へ進む。ステップ４２０は、フローを処理するＰＰＣの稼働状況を追跡する。本発明の一実施形態では、ステップ４２０は、フローを処理するＰＰＣの割り当てに関連付けられたイベントカウンタをインクリメントすることを含むが、以下、決定ステップ４２８に関連して代替例について説明する。

ステップ４２２では、割り当てられたＰＰＣへイベントのコンテンツが提供される。これは、イベントのコンテンツをＰＰＣのローカルメモリ内のキューメモリへ物理的にコピーすることによって達成されることが可能であり、又は代替例として、イベントデータのロケーションの識別情報をＰＰＣへ提供することによって達成されることが可能である。このようなキューメモリは、異なる複数のフローからのイベントを含むことが可能であり、例えば対応するフロー状態に関してワークスペース記憶装置が利用可能であるだけの個数の異なるフローからのイベントを含むことが可能である。互換ＰＰＣにおいて（又は互換ＰＰＣにとって）イベントのキューメモリ又はフロー状態のワークスペースのいずれかが利用可能でなければ、ディスパッチャーは一時的に、ＰＰＣへのイベント／ワークスペース転送の一部又はすべての実行を保留することが可能である。

いったん転送が完了すると、割り当てられたＰＰＣは、そのフローのフロー状態へのアクセスと、典型的にはそのイベントに関連付けられたペイロードのサイズ及びロケーションに関する情報を含む、イベントデータへのアクセスとを有する。ステップ４２４において、ＰＰＣは、イベントに関連付けられたメッセージに関するトランスポート層プロトコルの処理のうちの多くを実行することが可能である。本プロトコルは、このような処理が達成しなければならない最終的な効果を定義しているが、当然ながらこの効果は、このようなトランスポート層の処理に関して現在実施されている方法か又は後に開発される方法かのいずれか任意の方法で達成可能である。ＰＰＣによるアクションは、例として、フロー状態を更新すること、出力されるべきメッセージのヘッダを生成すること、以前に送信されたメッセージの再送信を管理すること、又はエラーを含んで受信されたメッセージの再送信要求を送信することを含むことが可能である。ＰＰＣによるアクションはまた、ＰＰＣが構成するヘッダを、受信されたペイロードに再構成することと、フローの他端でネットワークに接続された異なるＴＬＴＳへ送信すること、又はローカルホストへ送信することとを管理することを含んでもよい。イベントが完了した時点で、ステップ４２６において完了ステートメントがアサートされる。ある実施形態では、完了ステートメントは、ＰＰＣの稼働状況の追跡に使用されるグローバルなディスパッチャーへ返信される。

アクティブなＰＰＣの解放．
ＰＰＣが現時点のイベントの処理を完了した後、決定ステップ４２８では、イベントの属するフローに関するすべての処理をＰＰＣが完了したか否かについての決定が行われる。ある実施形態では、このような決定は、「完了」ステートメントに応答してＰＰＣに関連付けられたイベントカウンタをデクリメントしかつイベントカウンタがゼロに到達したと決定するディスパッチャーモジュールによって行われることが可能である。しかしながら、異なる実施形態では、そのフローに関してＰＰＣが完了されることを確立するための多くの代替方法が適切となる。例えば、ＰＰＣのキューメモリ内に存在するフローの最後のイベントの処理を完了した時点で、ＰＰＣは、そのフローに関して「完了」したものとされてもよい。別の例として、ＰＰＣのローカルメモリ内のフロー状態が、別のＰＰＣにおける処理によって上書きされたり又は無効化されたりした時点で、ＰＰＣはそのフローに関して完了したものとされてもよい。「完了」に係るこれらの定義、又は他の定義は、ＰＰＣ自体の内部等の様々な場所のうちの１つ（又はそれ以上）において、もしくはディスパッチャー等のよりグローバルなモジュールにおいて（例えばコア稼働状況マネージャサブモジュール内で）追跡されることが可能である。

決定ステップ４２８において、ＰＰＣがフローをアクティブに処理していると決定されれば、ＰＰＣにおいてローカルなフロー状態は更新されていてかつグローバルなフロー状態は必ずしも更新される必要はないので、本方法は最終ステップ４３０へ進むことが可能であり、さらなる処理を実行しない。しかしながら、フローの処理をＰＰＣが完了したと決定されると、ステップ４３２において、ＰＰＣで更新されたローカルフロー状態が、よりグローバルなフロー状態のロケーションへ転送され、それによってＰＰＣワークスペースは、異なるフローのイベントを処理するために利用可能になる。そしてこれに続いて、グローバルなフロー状態へのアクセスが、そのフローに属するさらなるイベントが到来した時点で可能になる。ＰＰＣは、ディスパッチャーによって決定されるか、サブモジュール又は他のモジュールによって決定されるか、もしくはＰＰＣ自体によって決定される、そのフローに関するイベント処理の完了に基づいて、「完了」であるとされることが可能である。「完了」であると指定することはまた、そのフローからの全イベントの処理が完了した後に延期されてもよく、例えばＰＰＣが他に新たなフロー及びイベントのための余地を持たなくなるまで延期されてもよい。ＰＰＣは、ステップ４３４でいったん「完了」であるとされると、フローを処理することへの「割り当て」から解放されることが可能であるが、このことは例えば、ＰＰＣにおけるフロー状態メモリがもはや有効でないことを示すか、又は異なるフロー状態のさらなる格納に利用可能であることを示すフラグを設定することを含んでもよい。ステップ４３４の後、ＰＰＣは、そのイベントと、そのイベントが属するフローとから解放されたものとして扱われる。

決定ステップ４３６は、典型的には、ＰＰＣによって処理された最後のイベントが、フローが完全に閉じられることを可能にするか否かを決定するために所定の時点で発生する。フローを終了させるこのような決定は、フロー状態をメモリに書き込むことの必要性を除去する場合があるので、この決定ステップ４３６は、決定ステップ４２８が行われるよりも前に、もしくはステップ４３２及び／又は４３４より前に実行されることも可能である。またこのような決定は、そのフローに関してＰＰＣが「完了」したという決定を包含することも可能である。しかしながら、処理上の都合により、この終了の決定は図４に示したシーケンスにおいて行われるとされてもよい。ＰＰＣ自体は、典型的には、そのＳＰ処理デューティの一部として最後のイベントがそのフローを完了したか否か（例えば、フロー状態が「接続が閉じられた」状態まで進められているか否か）を決定する。しかしながら、そのフローを実際に閉じる決定は、ディスパッチャー（又はサブモジュール）等において、よりグローバルに行われてもよい。決定ステップ４３６において、フローを終了しないと決定されると、システムは一般にメッセージを処理するように動作させられ、完了ステップ４３０へ進む。しかしながら、ステップ４３６においてフローを終了すると決定されれば、ローカルフローＩＤプロキシ及びフロー状態メモリロケーションは、その時点で他の使用のために解放されることが可能である。ＰＰＣは、他のフローが（少なくとも複数の互換ＰＰＣによって形成される世界の中で）どこに割り当てられるかということには大抵の場合に無関係に、一般的には、特定のフローに係るレベルにおけるフローに属するイベントの処理に割り当てられ、またその処理から解放されるので、ＰＰＣは別のＰＰＣによって以前に処理されたフローに属するイベント（又はメッセージ）の処理に割り当てられる場合があり、実際かなり高い確率で可能である。このようなフローとＰＰＣとの再割り当ては、かなり頻繁に発生してもよく、いくつかの状況下では、フローの各イベント毎に発生してもよい。

ディスパッチャー処理．
図５は、例示的なＳＰＰＳ内の「ディスパッチャー」モジュールにより、あるフローに属するイベントを異なる時間において異なるＰＰＣに対してディスパッチ処理するために行われてもよい動作を示すフローチャートである。図５は、一般にはディスパッチャーモジュール（及び複数のサブモジュール）に帰属されてもよい動作である、着信するイベントの分配を実行する動作に焦点を当てたものである。従って、図５のステップは実質的に、図４に示したもののようなＳＰＰＳ全体に係るステップのサブセットであってもよいが、図５のステップはディスパッチャーモジュールの視点からのものであり、図４に示したもの以外の異なる詳細事項を含んでもよい。ディスパッチャーモジュールは、当該ディスパッチャーモジュールがイベントをディスパッチ処理する対象であるＰＰＣとも、当該ディスパッチャーモジュールによって受信されるイベントが到来してくる入力処理とも概念上は別個のものであり、図２におけるディスパッチャー２１２と同様にＳＰＰＳ内に接続されることも可能であれば、又は他の方法で接続されることも可能である。ディスパッチャーモジュールはまた、概念的にも、又は物理的にさえも、さらに分割されることが可能であり、例えば、ローカルフローＩＤプロキシ（及び／又はフロー状態）の「ルックアップ」モジュールや、指示器コア稼働状況マネージャを参照すると、これらは各々、概念的にか又は物理的にかのいずれかで、ディスパッチャーモジュールのサブモジュールであったり、又はディスパッチャーに関連付けられた補助モジュールであったりしてもよい。

図５に示すように、ステップ５０２において入力発信元からイベントが受信される。イベントは、典型的には、ＳＰＰＳによって処理されているメッセージの「状態に関連した」部分のみを含む。すなわち、イベントは典型的に、メッセージのペイロードではなくメッセージに関連付けられたフローのフロー状態の保全をＰＰＣ（プロトコル処理コア）が制御するために必要な情報のみを含む。しかしながら、実施形態によっては、ペイロード又はその一部が、状態に関連したデータとともに保持される場合もある。ディスパッチャーは、イベント内に含まれた「フローキー」であって、そのイベントが属するフローを一意的に識別する「フローキー」を検査する。ステップ５０４において、ディスパッチャーは、ＰＰＣがそのフローに関連したイベントをアクティブに処理していたことを示す、コア稼働状況マネージャ（Core Activity Manager：又は「ＣＡＭ」）におけるフローキーとの一致の有無を検索する。（ディスパッチャーとは物理的又は概念的に別個のものであってもよい）ＣＡＭ内に一致が見つからない場合には、この例示的実施形態においては、フローに係るイベントをアクティブに処理しているＰＰＣが存在しないということが推測され、ステップ５０６において、そのイベントを処理するために割り当てられたＰＰＣの稼働状況を追跡するために、ＣＡＭのエントリが初期化される。

ステップ５０８において、ディスパッチャーは、フローキーに対応するローカルフローＩＤプロキシを検索する。多数のフローを処理するＳＰＰＳの場合、この検索は別個のルックアップモジュールによって実行されることが可能であり、当該ルックアップモジュールは、例えば、ローカルフローＩＤプロキシを可能な限り迅速に位置決めするためにハッシュの照合（ルックアップ）を実行してもよい。決定ステップ５１０は、フローキーに一致するローカルフローＩＤプロキシが発見されたか否かに依存する。発見されていなければ、ＳＰＰＳは、まだフローからのいかなるデータも処理していない場合があり、よってステップ５１２において、そのイベントのフローキーによって一意的に識別されるフローに関連付けられたフロー状態ＩＤが選択されることが可能である。その後（又は、ローカルフローＩＤプロキシが発見されかつステップ５１０における決定が「ｙｅｓ」である場合）、処理はステップ５１４へ進むことが可能である。

ステップ５１４では、イベントを処理するＰＰＣが選択される。このステップは、処理されているイベントのタイプを決定するサブステップを含むことが可能であるが、実施形態によっては、このサブステップは、先行する処理モジュール（例えば、図２の２０６又は２０８等のメッセージスプリッタ）によって実行される。各ＰＰＣに関してディスパッチャー内に保持された「イベントタイプマスク」は、イベントのタイプを示すビットと比較されることが可能であり、これにより、そのイベントタイプにどのＰＰＣが適合するかということが決定される。別のサブステップとして、そのイベントタイプを処理するように構成されたＰＰＣの相対的な稼働状況レベルを検査することが含まれてもよい。空き時間が最も多いＰＰＣが選択されてもよく、又は、それの入力キューメモリ内に任意の余地を有する次のＰＰＣが、ラウンドロビン型に選択されてもよい。さらなる例として、ローカルなワークスペースを割り当てることを含む最近のＰＰＣの稼働状況に関するデータが（例えばコア稼働状況マネージャサブモジュール内に）保持されてもよく、また、他の状況ではそのフローに関して「完了」とされる場合でも、イベントのフローに関してそれのフロー状態メモリがまだ上書きされていないＰＰＣが選択されてもよい。コア稼働状況マネージャ（ＣＡＭ）サブモジュールと組み合わされているか、又は上記ＣＡＭサブモジュールの一部であるかのいずれかである指示器サブモジュールが、これらの動作を実行することが可能である。（複数の互換ＰＰＣによって形成される世界における）１つのＰＰＣの選択は、一般に、（それのフローキーの特性等に起因して）そのフローが属する当該フローに係る先験的なクラスに関わりなく、着信する各イベントのフローについて特定的に行われる。このような個別的な割り当て技術の結果として、フローに係る特定のイベントを処理するために選択されたＰＰＣは、（別途説明の通り、その特定のフローが、現時点で、あるＰＰＣにおいてアクティブでない限り）同じフローに係る以前のイベントを処理したＰＰＣとは相違する場合が多い。

フロー状態がステップ５１２において初期化されたか又はステップ５０８乃至５１０において位置決めされ、ＰＰＣがステップ５１４において選択されたので、フロー状態は次に、ステップ５１６においてＰＰＣへ転送されることが可能である。実施形態によっては、このような転送は「仮想的」であってもよく、ＰＰＣがアクセスできるようにフロー状態がメモリ内のどこに存在するかを示す情報が単に提供される。次に、処理はステップ５１８へ進むことができる。この同じステップへは、ステップ５０４における決定が「ｙｅｓ」であれば、同じフローに属する先行するイベントをＰＰＣがすでに処理しているので、決定ステップ５０４から直接到達される場合もある。このようなアクティブなＰＰＣは、（多くの実施形態において）そのフローにとって最も妥当なフロー状態をすでに有し、その場合は一般に現時点のイベントを処理するために選択される。従って、ステップ５１８では、イベント自体が、選択されたＰＰＣの入力エリア又はキューメモリへ転送されることが可能である。ステップ５１８に加えて、イベントカウンタはステップ５２０においてインクリメントされることが可能である。イベントカウンタは、現時点のイベントのフローに係る別のイベントをＰＰＣがアクティブに処理しているのがいつであるのかを決定するための一方法であるが、特定のフローに係る現時点のすべてのイベントの処理が完了している示す情報をＰＰＣが生成するのを待機するような、他の方法が使用されることもある。ディスパッチャーの受信処理は、これで終了である。

図６は、ディスパッチャー（又はその複数のサブモジュール）がＰＰＣからのフィードバックに応答して実行可能ないくつかのステップを示すフローチャートである。図５の場合と同様に、図６のステップは、おおまかには、ＳＰＰＳ全体によって行われるステップのサブセットであるが、これらのステップはディスパッチャーの視点から説明され、ＳＰＰＳ全体に関して図４に示したステップにはないステップ、又はそれら図４に示したステップとは異なるステップを含んでもよい。

図６に示した応答動作はステップ６０２で開始され、ディスパッチャーはその間に、ＰＰＣが特定のフローに係るイベントの処理を完了したことを示す「完了ステートメント」又は他の情報を受信する。ディスパッチャーは次に、そのフローに関するイベントカウンタをデクリメントすることが可能である（図５のステップ５２０に関連してすでに論じた）。決定ステップ６０６において、イベントカウンタがゼロに到達していることが発見された場合、もしくはさもなければ、ＰＰＣによって複数のイベントにてなる「バースト」が完了されたことを示す情報が生成された場合、ディスパッチャーは、ＰＰＣによって更新された状態のフロー状態をより永久的なメモリへ格納させ、ＰＰＣのメモリを解放することが可能である。（ただし、メモリを処理しているＰＰＣが存在しない場合と同じメモリが処理中にＰＰＣによって使用される実施形態では、このステップは必要とされないことに留意されたい。起こりうる状況としては、例えば、フロー状態が常に同じグローバルロケーションに保持され、しかも、当該フロー状態が、そのフローを処理するＰＰＣによって必要なときにアクセスされるだけである場合がある。）次に、ＰＰＣに格納されたフロー状態がもはや有効でないことを示すフラグ又は他の指示情報が、ＣＡＭに含まれるか、又はＰＰＣへ送信されることが可能である。次にステップ６１２で、ＰＰＣは、それが処理していた特定のフローを取り扱うことから解放されることが可能である。これで特定のフローに係るイベントを処理するアクティブなＰＰＣは存在しなくなるので、ステップ６１４では、ＰＰＣの稼働状況が保持されていたＣＡＭブロックが解放されることも可能である。

「解放する」ことは、ＰＰＣ（又はＣＡＭメモリブロック）が利用可能であることを示すフラグを単に設定するということに帰着できる。このようなフラグは利用可能性を示してもよいが、本質的なデータが上書きされているのではない限り、ＰＰＣは、どの点から見ても、このような情報を提示した後もなおフローに係るイベントをアクティブに処理しているかのように扱われてもよい。この場合、データブロックが実際に上書きされ従って破壊されるまで、決定ステップ６０６は「ｎｏ」を返す。いずれにしても、決定ステップ６０６が「ｎｏ」を返す場合には、ステップ６０８乃至６１４は一般に当該イベントにおいて不要であるので、処理が完了される。そうでなければ、ステップ６１４においてＣＡＭブロックが解放された後に処理が完了される。

カプセル化されたステートフルフロー処理．
本明細書に記載したようなＳＰＰＳ（ステートフルプロトコル処理システム）がトランスポート層以外の階層のフローを処理できる一つの方法は、カプセル化されたメッセージを抽出し、抽出されたメッセージをさらなる処理のために再循環させるというものである。このようなさらなる処理は、カプセル化されるメッセージのための適切なプロトコルに従って実行可能であるが、これは典型的には、メッセージをカプセル化する場合に使用されるプロトコル（典型的にはＴＬＰ）とは異なる。

カプセル化されたステートフルメッセージが検索して読み出され、再フォーマットされかつＳＰＰＳへ入力（非トランスポート層入力）として提供された後、１つ又は複数のＰＰＣが特定のプロトコル（例えばｉＳＣＳＩ）によって必要とされるステップにより構成される限り、ＳＰＰＳは適切なプロトコルに従ってメッセージを処理することができる。従って、単にＳＰＰＳを使用して非トランスポート層を処理すれば簡単である。

カプセル化されたデータが再循環を要求していることについてＳＰＰＳが通知されることが可能な方法は、数多く存在する。通知は、例えば処理されるすべてのデータが再循環を要求する場合には、暗黙的であってもよい。代替として、カプセル化するメッセージのヘッダ又はペイロードの一部又は複数の部分が、このような再循環の必要性を示す情報を含んでもよい。ＳＰＰＳは、カプセル化された情報を再循環させることを示す情報を各ペイロードにおいて調べてもよく、ヘッダに所定の情報が提供されている場合に限ってペイロードを調べてもよい。従ってＳＰＰＳは、カプセル化するメッセージのヘッダ及び／又はペイロードにおける暗黙的情報及び明示的情報の任意の組み合わせによって、ペイロードが検査されるべきか否かということと、それがさらなる処理を必要としているか否かということと、このようなさらなる処理はどのようなプロトコルによって実行されるべきかということとに関する命令を受信することが可能である。

「再循環」プロトコルはまず、カプセル化するメッセージのペイロード（及び／又はヘッダの一部）がセグメント化され、かつカプセル化されたフローに関するメッセージとして再アセンブルされるように、呼び出されることが可能である。ただし、カプセル化する単一のメッセージが、複数のカプセル化されたメッセージのすべて又は一部を含む場合もあれば、逆に、単一のカプセル化されたメッセージが、伝送されるべきカプセル化する複数のメッセージを要求する場合もある（例えば、大きいメッセージが、ＡＴＭパケット等の複数の小さいパケットにカプセル化される場合）ことに留意されたい。再循環プロトコルは、カプセル化されたメッセージの適切な再アセンブルを定義し、またそれがさらなる処理のためにＳＰＰＳの入力へ返信されるように管理する。このような再循環プロトコルは、ローカルフローＩＤプロキシと、イベントタイプと、他の既知の有用な情報とを指定すること等によって、再循環されるメッセージを特に効率的な形式にフォーマットすることが可能である。このようにして、ＳＰＰＳ再循環プロトコルに係る（複数の）プロセッサは、ＳＰＰＳと密に連携して動作するホストと同様に機能する。このようなホストは、ＳＰＰＳへのメッセージにとって理想的な形式を認識していて、メッセージをこのような理想的な形式にフォーマットすることにより処理速度を増大させることが可能である。

また、再アセンブリ装置又は「出力プロセッサ」２４２及び／又は２４４が、カプセル化されかつ再アセンブルされたメッセージを、再循環には不要な場合のある２４２，２４４，２０２及び２０４におけるＳＰＩ−４インターフェース等のインターフェースを介して伝送する代わりに、メッセージスプリッタ２０６又は２０８へ直接に転送して戻すように、再循環は、変更された通信経路によって実行されてもよいということも留意されるべきである。実際、再循環されるメッセージは、そうでなければメッセージスプリッタ２０６又は２０８によって実行される方法で予め完全にフォーマットされていてもよい。カプセル化するメッセージを処理する選択されたＰＰＣ（又は関連のプロセッサ）は、このような前置フォーマット化処理を実行することと、配信されるべき情報を２４２／２４４における再アセンブリプロセッサからスクラッチパッドメモリ２１０及びディスパッチャー２１２へ直接に方向付けることとが可能であり、こうしてメッセージスプリッタは完全にバイパスされる。

再循環がいったん実行されると、カプセル化された情報のさらなる処理は、先に述べた通りに、すなわちＴＬＰメッセージが処理される場合と実質的に同じ方法で実行されることが可能である。関心が持たれている場合では、カプセル化された情報はステートフルであってかつ１つのフローに属し、よって、メッセージに係る状態に関連した部分を反映するイベントが生成されてもよく、フローキーのローカルプロキシが決定され、フローの状態が生成されるか又は位置決めされ、プロトコルに適合するＰＰＣ（プロトコル処理コア）が（予めカプセル化されて現時点で再循環されている）メッセージから導出されるイベントを処理するために割り当てられる。これらのステップは、再循環されたメッセージに関してだけでなく、トランスポート層であるか否かに関わらずＳＰＰＳの入力へ提供される任意のフローのメッセージに関して実行されてもよい。

非トランスポート層のメッセージを処理することは、当然ながら、情報がさらなるサブシステムへ送信されることを必要とする場合がある。例えば、カプセル化されたメッセージ内のデータは、ホストへの配信を必要とする場合がある。割り当てられたＰＰＣは、宛先となるホストにとって受容可能な方法で情報が再アセンブルされるように指示し、次に再アセンブルされたメッセージが宛先となるホストへ転送されるように指示することによって、このような送信を実行することが可能である。ある代替例では、カプセル化されたメッセージをネットワーク接続へ送信することは、発信するメッセージが再度カプセル化されてＴＬＰメッセージにされること（典型的には、ＴＣＰ等の、カプセル化する元のメッセージに使用されたものと同じＴＬＰであるが、必ずしもこれでなくともよい）を必要としてもよい。従って、この時点では、このようなメッセージを再度カプセル化するためにさらなる再循環が必要とされてもよい。少なくとも理論上、メッセージは、任意回数の一連のカプセル化によって「ネスト」されている（入れ子状態にされている）が、これは、最も内側のステートフルメッセージが処理され得るまでにはぎ取られる（カプセル化が解除される）必要がある。同様に、このような最も内側のステートフルメッセージを処理することは、メッセージの対称的な再カプセル化を必要としてもよい。実際には効率上の観点から、過剰なカプセル化は回避される。

以上、本発明に係る多数の実施形態について説明した。しかしながら、本発明の範囲を逸脱することなく様々な変更を行うことが可能であるということは理解されるであろう。例えば、本発明に係る方法は、ソフトウェア又はハードウェアにおいて、もしくはハードウェア及びソフトウェアの実施形態の組み合わせにおいて実施されることが可能である。別の例として、あるモジュールの部分として説明された機能は、一般には別のモジュールにおいて等しく実行可能であるということは理解される必要がある。さらに別の例として、特定のシーケンスで示された、又は説明されたステップ又は動作は、一般には、指定されたステップ順序を含むクレームに記載されている実施形態を除いて、異なる順序で実行されてもよい。

従って本発明は、説明した特定の実施形態によって限定されるべきものではなく、添付の請求の範囲によってのみ限定されることは理解されるべきである。本明細書の説明は、請求の範囲に列挙されたものと類似した特徴を有する例を提示しているが、こうした同一性が請求の範囲を理解する上で不可欠でない限り、このような類似した特徴が請求の範囲に記載されたものと同一であるという想定はされるべきでない。場合によっては、わずかに異なる用語を使用することにより、請求の範囲に記載された特徴と明細書で説明された特徴との意図された対照性が強調されている。

ステートフルプロトコル処理システムへの一般的なインターフェース接続を示すブロック図である。 典型的なコンピュータシステム内のトランスポート層端末システムのブロック図である。 図１に示したもの等のステートフルプロトコル処理システムのさらに詳細なブロック図である。 図２のステートフルプロトコル処理システムに係る特徴機能のうちのいくつかをさらに詳細に示すブロック図である。 フローを処理するために選択されるプロトコルコアを変更する際に使用される動作のフローチャートである。 あるフローに属するイベントの受信に応答してディスパッチャーモジュールにより実行される動作のフローチャートである。 あるプロトコルコアからの「完了ステートメント」の受信に応答してディスパッチャーモジュールにより実行される動作のフローチャートである。

Claims (49)

1. 複数のメッセージにてなる複数のフローを処理するステートフルプロトコル処理システム（「ＳＰＰＳ」）においてデータを処理する方法であって、各フローは、このようなフローに属する複数のメッセージによって伝送される一意的に対応したフロー識別情報（「ＦＩＤ」）に関連付けられ、
   上記方法は、
   ａ）特定のフローに属する複数のメッセージを受信することと、
   ｂ）上記複数のメッセージから上記特定のフローに関連付けられた複数のイベントを導出することと、
   ｃ）上記特定のフローのステートフルプロトコル（ＳＰ）に従って上記イベントのうちの１つ又は複数を処理する第１のプロトコル処理コア（「ＰＰＣ」）を特定的に割り当てることと、
   ｄ）上記特定のフローのＳＰに従って上記イベントのうちの他の１つ又は複数を処理する異なる第２のＰＰＣを特定的に割り当てることとを含む方法。
2. ステップｃ）及びｄ）においてＰＰＣを割り当てることは、異なる複数のＰＰＣ間で負荷状態をバランス化させるアルゴリズムに従うことをさらに含む請求項１記載の方法。
3. 上記異なる複数のＰＰＣ間で負荷状態をバランス化させるアルゴリズムは、複数のＰＰＣにてなるセット間におけるラウンドロビン型分配を含む請求項２記載の方法。
4. ｅ）各ＰＰＣのローカルキューメモリにいくつかのイベントを格納することと、
   ｆ）複数のＰＰＣにてなる関連したグループ内における低負荷のＰＰＣであって、上記関連したグループ内の異なるＰＰＣのキューメモリに格納されたイベントより少ないイベントが当該低負荷のＰＰＣのローカルキューメモリに格納されている低負荷のＰＰＣを識別することとをさらに含み、
   ｇ）上記異なる複数のＰＰＣ間で負荷状態をバランス化させるアルゴリズムは、ＰＰＣに割り当てられたイベントを現在持たないフローに係るイベントを処理するために上記低負荷のＰＰＣを割り当てることを含む請求項２記載の方法。
5. ｅ）異なる複数のフローの組み合わせに係る複数のイベントを同時に上記第１のＰＰＣへ割り当てることと、
   ｆ）上記異なる複数のフローの組み合わせのうちの１つに係る後続のイベントを上記第２のＰＰＣへ割り当る一方、上記第１のＰＰＣは、上記異なる複数のフローの組み合わせのうちのもう１つのものに係るイベントの処理を継続することとをさらに含む請求項１記載の方法。
6. ｅ）異なる複数のフローの組み合わせに係る複数のイベントを同時に上記第１のＰＰＣへ割り当てることと、
   ｆ）上記異なる複数のフローの組み合わせのうちの１つに係るイベントを処理することに対する第１のＰＰＣの割り当てを明示的に解放する一方、上記第１のＰＰＣは、上記異なる複数のフローの組み合わせのうちのもう１つのものに係るイベントの処理を引き続き割り当てられることとをさらに含む請求項１記載の方法。
7. ｅ）現在どのＰＰＣにもイベントの処理が割り当てられていない、割り当てられていないフローのメッセージを受信することをさらに含み、上記割り当てられていないフローは、対応するＦＩＤを有し、
   ｆ）上記割り当てられていないフローに係る一般的なタイプのイベントのうちのイベントを処理するように構成された複数の互換ＰＰＣを識別することと、
   ｇ）上記割り当てられていないフローに対応するＦＩＤに関わりなく、上記複数の互換ＰＰＣの間から、上記割り当てられていないフローに係る１つ又は複数のイベントを処理するＰＰＣを選択することとをさらに含む請求項１記載の方法。
8. ｅ）現在どのＰＰＣにもイベントの処理が割り当てられていない、割り当てられていないフローのメッセージを受信することと、
   ｆ）上記複数の互換ＰＰＣによって処理されるために現在キューメモリに格納されているフローのＦＩＤに関わりなく、このようなイベントに適合する複数のＰＰＣの間から、上記割り当てられていないフローに係る１つ又は複数のイベントを処理するＰＰＣを選択することとをさらに含む請求項１記載の方法。
9. 特定のイベントを処理するＰＰＣを選択する前に、上記特定のイベントが、現在ＰＰＣが割り当てられているフローに属するか否かを明示的に決定することをさらに含む請求項１記載の方法。
10. 以前に選択されたＰＰＣが、対応するフローに現在割り当てられていると決定されたとき、上記以前に選択されたＰＰＣを用いて、上記対応するフローの状態に影響を与えるすべての着信イベントを処理することをさらに含む請求項９記載の方法。
11. いかなるフローのＦＩＤにも関わりなく、特定のフローに係るイベントを処理するＰＰＣの以前の割り当てを解放することをさらに含む請求項９記載の方法。
12. 第１のフローの状態に影響することに関連したイベントであって、かつ現在処理されているイベントが存在しないことを示す情報に基づいて、上記第１のフローに係るイベントを処理するＰＰＣの以前の割り当てを解放することをさらに含む請求項１記載の方法。
13. 上記第１のフローに関連したイベントであってかつ現在処理されているイベントが存在しないことを示す情報は、上記第１のフローに関連したイベントの導入及び完了をカウントするカウンタに基づく請求項１２記載の方法。
14. イベントを処理するＰＰＣを選択する前に、上記イベントのタイプを決定することをさらに含む請求項１記載の方法。
15. ｅ）ＰＰＣを選択することに先行して、複数の様々なフローに属する受信されたメッセージから導出される所定個数のイベントについてイベントタイプを決定することをさらに含み、決定される複数の別個のイベントタイプは、少なくとも、
    ｉ）第１のステートフルプロトコル（「ＳＰ」）を用いるフローに係る良好なイベントと、
    ｉｉ）異なる第２のＳＰを用いるフローに係る良好なイベントと、
    ｉｉｉ）エラーを有すると決定され、上記第１のＳＰを用いるフローに係るイベントとを含む請求項１記載の方法。
16. 上記決定される複数の別個のイベントタイプはさらに、ｉｖ）パケットの断片を含む請求項１５記載の方法。
17. 上記ＳＰＰＳ内のステートフルプロトコル処理のための第１のメッセージ内にカプセル化された情報を、第２のステートフルプロトコルメッセージとして再循環することをさらに含む請求項１記載の方法。
18. 複数のデータ通信メッセージにてなる複数のフローを処理するデータ通信ステートフルプロトコル処理システムにおいてデータを処理する方法であって、各フローは、このようなフローに属する複数のメッセージによって伝送される一意的に対応したフロー識別情報（「ＦＩＤ」）に関連付けられ、
    上記方法は、
    ａ）特定のフローに属するメッセージと、他のフローに属するメッセージとを受信することと、
    ｂ）上記受信されたメッセージから、上記特定のフローに関連付けられたイベントと上記他のフローに関連付けられたイベントとを含む、イベントが導出されるメッセージのＦＩＤによって示されたフローに関連付けられたイベントを導出することと、
    ｃ）各イベントを１つ又は複数の予備処理キューメモリからなるグループの１つに配置することと、
    ｄ）上記特定のフローに係る第１のイベントを処理する第１のプロトコルプロセッサコア（「ＰＰＣ」）を、上記第１のイベントが位置した上記予備処理キューメモリに関わりなく割り当て、続いて上記割り当てられた第１のＰＰＣのローカルキューメモリへ上記第１のイベントを転送することと、
    ｅ）上記特定のフローに係る異なる第２のイベントを処理する異なる第２のＰＰＣを、上記第２のイベントが位置した上記予備処理キューメモリに関わりなく割り当て、続いて上記割り当てられた第２のＰＰＣのローカルキューメモリへ上記第２のイベントを転送することとを含む方法。
19. 上記第１及び第２のＰＰＣは、実質的に、ステートフルプロトコルメッセージの処理を実行するために設けられる請求項１８記載の方法。
20. ステップｂ）は、上記導出されるイベントから、上記受信されたメッセージのペイロードデータを実質的に除外することをさらに含む請求項１８記載の方法。
21. ステップｂ）は、イベントタイプを示す情報を含まないイベント内に、イベントタイプを示す情報を配置することをさらに含む請求項２０記載の方法。
22. ｆ）上記イベントをＰＰＣに転送することに先行して、イベントの完全性を検証することをさらに含む請求項１８記載の方法。
23. すべてのステートフルプロトコルＰＰＣとは物理的に別個のパケットプロセッサにおいてステップｂ）を実行することをさらに含む請求項１８記載の方法。
24. ｆ）ＰＰＣによる処理のために現在割り当てられていないフローに係るイベントのローカルプロキシＩＤを、上記パケットプロセッサによって実行されずかつ上記ＰＰＣによって実行されないプログラムステップを実行するルックアッププロセッサの動作を用いて決定することをさらに含む請求項２３記載の方法。
25. ｆ）上記ローカルプロキシＩＤに依存してメモリアドレスにおいてフロー状態にアクセスすることをさらに含み、上記フロー状態は、ＰＰＣによる処理のために現在割り当てられていないフローに関して予め格納されている請求項２４記載の方法。
26. ｆ）少なくとも特定のＰＰＣによる処理のために現在割り当てられていないフローに属するイベントに関するローカルフロープロキシＩＤを、専用のルックアップハードウェアの動作を用いて決定することをさらに含む請求項１８記載の方法。
27. 上記専用のルックアップハードウェアはマイクロプロセッサを含む請求項２６記載の方法。
28. ｆ）上記第１のイベントのデータと、関連付けられたフロー状態のデータとを、上記第１のＰＰＣに一意的に関連付けられた第１のメモリに保持することと、
    ｇ）異なるフローに係るイベントのデータと、上記異なるフローの対応するフロー状態とを、上記第１のＰＰＣによる上記第１のメモリのアクセスに関わりなく異なるＰＰＣによりアクセス可能なメモリに同時に保持することとをさらに含む請求項１８記載の方法。
29. イベントデータ及び対応するフロー状態データの両方を、このようなイベントの処理を割り当てられたＰＰＣのローカルなメモリに、上記割り当てられたＰＰＣによるこのようなイベントの処理が完了するまで保持することをさらに含む請求項２８記載の方法。
30. 複数のイベントを処理する複数のＰＰＣを、異なる複数のＰＰＣ間で負荷状態をバランス化させるアルゴリズムに基づいて割り当てることをさらに含む請求項１８記載の方法。
31. 複数のメッセージにてなる複数のフローを処理するステートフルプロトコル処理システム（「ＳＰＰＳ」）においてデータを処理する方法であって、各フローは、このようなフローに属する複数のメッセージによって伝送される一意的に対応したフロー識別情報（「ＦＩＤ」）に関連付けられ、
    上記方法は、
    ａ）特定のフローに属する複数のメッセージの受信を実行するステップと、
    ｂ）上記複数のメッセージに基づいてイベントの定義を生成するステップと、
    ｃ）ステートフルプロトコル（「ＳＰ」）処理のために、第１のプロトコルプロセッサコア（「ＰＰＣ」）への、特定のフローに係る第１のイベントの割り当てを実行するステップと、
    ｄ）ＳＰ処理のために、異なる第２のＰＰＣへの、上記特定のフローに係る第２のイベントの割り当てを実行するステップとを含む方法。
32. 新規なイベントのＦＩＤに関連付けられたフローに係るイベントを、任意のＰＰＣが現在処理しているか否かを決定するステップをさらに含む請求項３１記載の方法。
33. 特定のＦＩＤに関連付けられて存在するすべてのイベントについて処理がいつ完了したかを決定するステップをさらに含む請求項３１記載の方法。
34. データ通信のトランスポート層の終端として動作するシステムであって、
    ａ）メッセージ受信機モジュールを備え、上記メッセージ受信機モジュールは、
    ｉ）多数のデータ通信メッセージを受信するように構成され、上記各メッセージは、上記メッセージのフロー識別情報（「ＦＩＤ」）によって一意的に識別されるフローに関連付けられ、かつ、
    ｉｉ）上記受信された複数のメッセージから複数のイベントを導出するように構成され、各イベントは、当該イベントが導出されるメッセージに関連付けられたフローに関連付けられ、
    上記システムは
    ｂ）イベントのフローのステートフルプロトコルに従って当該イベントを処理するように構成された複数のプロトコルプロセッサコア（「ＰＰＣ」）モジュールと、
    ｃ）上記複数のＰＰＣモジュールの間において複数のイベントをディスパッチ処理するイベントディスパッチ処理モジュールとを備え、上記イベントディスパッチ処理モジュールは、
    ｉｖ）上記メッセージ受信機モジュールから複数のイベントを受信し、
    ｖ）受信された各イベントについて、上記受信されたイベントのフローに係るイベントを処理するために現在ＰＰＣモジュールが割り当てられているか否かを決定し、かつ、
    ｖｉ）受信された特定のイベントのフローのＦＩＤに関わりなく、複数の互換ＰＰＣモジュールの中から、受信されたイベントであってかつステップｉｉ）で処理のために現在割り当てられているＰＰＣモジュールを持たないと決定されたイベントを処理するＰＰＣモジュールを選択するように構成されたシステム。
35. 上記イベントディスパッチ処理モジュールはさらに、受信されたイベントであってかつステップｉｉ）で処理のために現在割り当てられたＰＰＣモジュールを持たないと決定されたイベントのフローのローカルプロキシ識別情報を決定するように構成されたルックアップサブモジュールを備えた請求項３４記載のシステム。
36. 上記イベントディスパッチ処理モジュールはさらに、
    ｄ）イベント追跡サブモジュールを備え、上記イベント追跡サブモジュールは、
    ｉ）特定のフローに係るイベントを処理するＰＰＣモジュールが現在割り当てられているか否かを決定するように、複数のＰＰＣモジュールに対してディスパッチ処理される複数のイベントに関するフロー処理状態情報を格納するように構成された請求項３４記載のシステム。
37. （ｄ）上記イベント追跡サブモジュールはさらに、
    ｉｉ）イベントのフローに従って上記イベントのカウント値を保持し、かつ、
    ｉｉｉ）特定のフローに係るイベントが、上記フローに割り当てられたＰＰＣモジュールに対してディスパッチ処理されるとき、上記特定のフローのカウント値を増大させ、
    ｉｖ）上記特定のフローに係るイベントの処理を上記割り当てられたＰＰＣが完了したことを示す情報に応答して、上記特定のフローのカウント値を減少させるように構成された請求項３６記載のシステム。
38. ｅ）メッセージから導出されたイベントから分離された、上記メッセージのペイロードデータを格納するように構成されたスクラッチパッドメモリをさらに備えた請求項３４記載のシステム。
39. ｅ）出力メッセージのフローを処理するＰＰＣモジュールからの命令に従って当該出力メッセージをアセンブルするように構成されたメッセージ出力処理モジュールをさらに備えた請求項３４記載のシステム。
40. 上記メッセージ受信機モジュールはさらに、イベント内にイベントタイプフィールドを確立するように構成されたプロセッサを備えた請求項３４記載のシステム。
41. データ通信ステートフルプロトコルに従ってメッセージを処理する装置であって、
    ａ）物理層から複数のメッセージを受信する手段を備え、上記メッセージは１つ又は複数の通信フローに対応し、
    ｂ）上記１つ又は複数の通信フローのうちの特定の通信フローに係る情報のステートフルプロトコル（ＳＰ）処理を実行する複数の手段と、
    ｃ）上記特定の通信フローのメッセージにおいて提供されるフロー識別情報（「ＦＩＤ」）データに関わらずプロセッサの負荷状態をバランス化させるように、上記複数のＳＰ処理手段の中から上記特定の通信フローの情報を処理する１つのＳＰ処理手段を選択する手段とを備えた装置。
42. ｃ）上記選択する手段は、
    ｉ）上記特定の通信フローの情報を処理するための特定のＳＰ処理手段を割り当てる手段と、
    ｉｉ）上記割り当てられたＳＰ処理手段を他の任意の通信フローの情報を処理することから解放する必要なしに、上記割り当てられたＳＰ処理手段を上記特定の通信フローの情報を処理することから解放する手段とを備えた請求項４１記載の装置。
43. ｄ）対応するフローの受信されたメッセージから当該対応するフローに係るイベントを導出する手段をさらに備えた請求項４２記載の装置。
44. ｃ）上記選択する手段は、割り当てられたＳＰ処理手段へ転送されているフローに係るすべてのイベントについていつ処理が完了されるかを決定する手段をさらに備えた請求項４３記載の装置。
45. ａ）２つ以上のプロトコル処理コア（「ＰＰＣ」）マイクロプロセッサと、ｂ）ディスパッチャーとを備えたステートフルプロトコル処理装置であって、
    各ＰＰＣマイクロプロセッサは、
    ｉ）他のＰＰＣに干渉することなく上記ＰＰＣによりアクセス可能なフロー状態を実質的に格納するのに十分なローカルメモリと、
    ｉｉ）当該装置の動作中に、受信されたデータメッセージを適切なステートフルプロトコル（ＳＰ）に従ってマイクロプロセッサに処理させるのに十分な命令コードを含むように構成されたプログラムメモリとを含み、上記命令コードは、上記受信されたデータメッセージ内の状態に関連した情報に応答してローカルメモリに格納された関連付けられたフロー状態を更新することを含み、
    上記ディスパッチャーは、複数のデータメッセージを受信するための入力と、処理回路とを含み、上記処理回路は、少なくとも当該装置の動作中に、
    ｉｖ）特定のフローに関連付けられた第１の受信されたデータメッセージの情報を、ＳＰ処理のために第１のＰＰＣへ転送し、
    ｖ）上記特定のフローに関連付けられた少なくとも１つの異なる第２のメッセージの情報を、ＳＰ処理のために異なる第２のＰＰＣへ転送するように構成された装置。
46. 各ＰＰＣはさらにデュアルポートローカルメモリを備えた請求項４５記載の装置。
47. データ通信システム内において、対応する複数の通信フローに属する複数の通信イベントを、互換性のある複数のプロトコルプロセッサ間に分配する方法であって、
    ａ）分配のために第１のフローに属する第１のイベントをキューメモリにおいて受信することと、
    ｂ）第１のイベントに適合する複数のプロトコルプロセッサの中から上記第１のイベントを処理する第１のプロトコルプロセッサを選択することと、
    ｃ）上記第１のイベントを上記キューメモリから上記第１のプロトコルプロセッサへ転送することと、
    ｄ）他のフローに属する他のイベントを上記キューメモリから上記第１のプロトコルプロセッサへ転送することと、
    ｅ）上記特定のフローに属する第２のイベントを上記キューメモリにおいて受信することと、
    ｆ）上記互換性のある複数のプロトコルプロセッサの中から上記第２のイベントを処理する異なる第２のプロトコルプロセッサを選択することと、
    ｇ）上記第２のイベントを上記キューメモリから上記第２のプロトコルプロセッサへ転送する一方、上記第１のプロトコルプロセッサは上記キューメモリからの他のイベントの処理を継続することとを含む方法。
48. 上記第１のプロトコルプロセッサへ転送されていた上記第１のフローに係るすべてのイベントが上記第１のプロトコルプロセッサによって完了されたことに応答して、上記第１のプロトコルプロセッサを、上記第１のフローに係るイベントを処理することから解放することをさらに含む請求項４７記載の方法。
49. ｈ）ステップｃ）の後であってかつ上記第１のプロトコルプロセッサが上記第１のイベントの処理を完了する前に、上記特定のフローに係る第３のイベントを受信することと、
    ｉ）結果的に、上記特定のフローに係る上記第３のイベントを処理するために上記第１のプロトコルプロセッサを選択することとをさらに含む請求項４７記載の方法。

Images