JP2020523950A - 変更通知ありのｔｃｐストリーム動的処理 - Google Patents

Abstract

【課題】ネットワーク接続された装置、詳細には、インラインコンテンツ検査を提供する。【解決手段】第１のエンドポイントと第２のエンドポイントとの間に確立された双方向ネットワーク化セッション中に、パケットのストリームを検査する過程と、第１のエンドポイントから送信された所与のパケット内のメッセージが変更されるべきであると判断すると、所与のパケット内のメッセージを変更して変更後パケットを生成する過程と、メッセージの変更を考慮して変更後のシーケンス番号を決定する過程と、変更後パケットを第２のエンドポイントに送信する過程と、返信メッセージを第１のエンドポイントに送信し、元のメッセージが変更されたことを知らせる過程と、を備える方法。【選択図】図１

Description

関連出願

本願は、2017年6月8日付出願の同時係属中の米国仮特許出願第62/516,753号である“Dynamic TCP Stream Processing（ＴＣＰストリーム動的処理）”の優先権を主張する。上記出願の全内容は、参照をもって本明細書に取り入れたものとする。

本特許出願は、ネットワーク接続された装置、詳細には、インラインコンテンツ検査に関する。

コンテンツ検査は、ネットワーク化されたデータ処理システムにより様々な理由で頻繁に用いられる技術である。データパケットが検査ポイントを通過する際に当該データパケットが検査されて、ウイルス、スパム、機微な又は敏感な又は影響の受けやすい（sensitive）データ、キーワード、またはコンテンツレベルの他の判断基準事項（criteria）が探し出される。コンテンツ検査は、個々のパケットのヘッダやその他のルーティング挙動に注目するのではなく、実際のメッセージペイロードが何を含んでいるのかを見る。コンテンツ検査は、ネットワーク通過中のデータパケットをキャプチャ（採取）し、コンテンツが敏感な内容（sensitivity）であるか否かを分析することで機能する。これは、既知のデータ構造（例えば、クレジットカード番号に使われるパターン等）や、敏感な内容（sensitivity）を示唆するキーワード（例えば、「秘（confidential）」等）や、スパムやウイルスのシグネチャを特定することを伴い得る。コンテンツ検査は、データを分類又は類別するのに利用されることもでき、予め設定されたルールを適用して、ペイメントカードインダストリーデータ（ＰＣＩ）や，個人を特定できる情報（ＰＩＩ）や、保護された健康情報（ＰＨＩ）や、証券取引ルールや、その他の基準に準拠しているか否かを確認又は保証する（ensure）ことが可能である。

特許文献１（Amicangioli）に記載されたアプローチは、高頻度電子証券取引ネットワークにおいて極めて有用な、カットスルー方式の透過的なロジックデバイスとリアルタイムパケットプロセッサとを用いたインラインネットワーク・トラフィックキャプチャ・システムである。このシステムは、第１のインターフェースを介して（証券会社、取引業者や仲介業者、又はその他の顧客により操作され得る）１つ以上のクライアントマシンから、取引要求を含むメッセージを受信する。取引情報は、１つ以上の取引リスクルールに準拠しているか否かを判断するために検査された後、第２のインターフェースを介して（証券取引所により操作され得る）１つ以上の市場サーバへと送信される。これらのインターフェースは、カットスルー方式の固定ロジックを介して互いに接続されており、かつ、互いに独立して動作する。このカットスルー方式の固定ロジックは、第１のポートで受信した取引情報を第２のポートへとそのまま（directly）転送する２ポートデバイスであり、クライアントマシン及び市場サーバのどちらとも通信コネクションを切断しないまま、クライアントから取引に関する情報を全て受け取り終えるのを待たずに、その取引情報の一部の送信を市場サーバに対して開始することができる。取引がルールに違反している場合には、取引情報メッセージの全体が市場サーバに送り届けられる前に、当該メッセージに対して修正又は変更が施される。

米国特許第９６０７３０７号明細書

（従来の解決手段の問題点）
既存のコンテンツ検査技術は、一部の用途において問題となる。一例として、多数のクライアント装置が市場装置に対して証券売買（取引）注文を送信する高頻度証券取引ネットワークを取り上げたい。売買注文は、メッセージとして形成され、パケット内で他のメッセージと合体させられたものであり得る。この環境では、多数の（a number of）ルールに準拠していない売買注文については拒絶されなければならず、つまり、クライアントから市場へと（Ｃ２Ｍ）移動できないようにされなければならない。

この環境でのコンテンツ検査の実装又は実現には、典型的に、「Ｏｎｅ ａｎｄ Ｄｏｎｅ」と「Ｇａｐ Ｆｉｌｌ Ｏｖｅｒｗｒｉｔｅ」の２種類のメッセージ拒絶方法が用いられてきた。これらの方法のいずれも、市場コンプライアンスに関してリスクがあったり、自身の注文の状態を知りたいクライアントにとって分かり難かったり、取引セッションからの完全な切断が必要になったりするという点で不十分である。

例えば、Ｏｎｅ ａｎｄ Ｄｏｎｅは、クライアント装置をセッションから強制的に切断させるところ、これは、高速・低レイテンシ取引システムの世界において非理想的な戦略である。また、Ｏｎｅ ａｎｄ Ｄｏｎｅにより切断が引き起こされると、注文の喪失や、クライアント側アルゴリズムの混乱や、再接続の困難性も招かれ得る。

Ｇａｐ Ｆｉｌｌ Ｏｖｅｒｗｒｉｔｅは、「ＺＶＺＺＴ」のような検査記号を用いてメッセージを上書きするもので、これは現在、様々な取引所でますます規制されつつある方法である。この規制のため、Ｇａｐ Ｆｉｌｌ Ｏｖｅｒｗｒｉｔｅでは、システムが潜在的なコンプライアンスの問題に引っ掛かる可能性がある。また、この上書きは、その上書きされたメッセージに対して市場が確認応答（ＡＣＫ）で応答することを前提としている（relies on）。このＡＣＫがないと、クライアントはメッセージの拒絶について知らされず、自身の注文が通った（done for the day）のか、それとも取引所で未決済（open）のままなのかを知ることができない。実際に、このような問題が原因で「キャンセルの嵐」が起こることが確認されている。

（好適な実施形態の概要）
本文献では、コンテンツ検査のための、分散型かつ透過的なインラインリスク管理及びトラフィックキャプチャシステムの改良について説明する。本明細書で説明するアプローチは、パケットがリアルタイムで検査デバイスに送り通されるなか、拒絶を受けたメッセージを変更したり、さらには、パケットから当該メッセージを除去したりする解決手段を提供する。除去したバイトを各セッションに基づいて追跡することにより、シーケンス番号の振当て（sequence numbering）が維持される。メッセージが変更された場合には、通知がメッセージ発信元に返されて変更が知らされる。

一実施形態では、ネットワークセッションに対応するパケットが、第１のネットワークエンドポイントと第２のネットワークエンドポイントとの間を移動する際に検査される。所与の（selected）パケット内のメッセージが変更されるべきであると判断されると（例えば、当該メッセージがコンテンツルールに準拠していない場合等）、拒絶されたコンテンツを除去又は変更した変更後パケットが決定される。さらに、当該変更後パケットの変更後のシーケンス番号も、前記所与のパケットのシーケンス番号を調節することによって決定される。そして、この変更後パケットが、前記所与のパケットに代えて前記第２のエンドポイントへと送信される。さらに、返信メッセージが前記第１のエンドポイントに返されて、前記所与のパケット内の元のメッセージが変更されたことが知らされる。

前記変更後のシーケンス番号は、アキュムレータ値を維持することにより、かつ、元のパケットと前記変更後パケットとのバイト数の差分を表すデルタ値により決定され得る。前記第２のエンドポイントからの前記変更後パケットの確認応答が検出されると、前記デルタ値が前記アキュムレータ値に加算され得る。

また、受信した後続のパケットのシーケンス番号が前記シーケンスマーカー値を上回る場合、前記第１のエンドポイントから受信した後続のパケットのシーケンス番号が前記アキュムレータ値だけ変更され得る。

また、前記第２のエンドポイントから受信した別のパケットの確認応答シーケンス番号が、前記アキュムレータ値に基づいて調節され得る。

一部の実施態様では、前記第１のエンドポイントが取引業者に対応付けられたクライアント装置であり得て、前記第２のエンドポイントが証券取引システムに対応付けられた市場装置であり得て、前記メッセージが証券を売買する注文である。これらの実施態様では、前記返信メッセージが、注文を拒絶した理由を含み得る。

また、実施形態では、前記第２のエンドポイントから返信メッセージの確認応答を受信したか否かが判断され得る。この確認応答を受信していない限りは、タイムアウト時間を過ぎて（after）前記セッションが切断されるまで前記変更後パケットが繰返し再送され得る。

一部の実施態様では、前記返信メッセージの確認応答を受信したか否かを判断することが、前記デルタ値を定期的にポーリングすることを含み得る。

前記変更後パケットの確認応答を未だ受信しておらず、かつ、後続のパケットについても変更して第２の変更後パケットを生成する必要がある場合、前記変更後パケットの前記確認応答を受信するまで前記第２の変更後パケットをストールするのが有利であり得る。

好適な一部の実施態様において、通信は、前記第１のエンドポイントと第２のエンドポイントとの間でメッセージ及び（必要に応じて）変更後のシーケンス番号が付いた当該メッセージの確認応答が双方向に同時に送信され得る双方向通信（duplex）である。これにより、一方向においてコンテンツ検査及びメッセージ変更をオンザフライで（on the fly）行うと同時に、反対方向において同時に通知返信メッセージを注入することも可能になる。

以降の説明は、添付の図面を参照しながら行う。

例示的な一実施形態を示す高次の図である。 検査デバイスの詳細図である。 証券取引システムでの一実施態様を示す図である。 より一般的なパケットフィルタリングの一実施態様を示す図である。 カットスルー方式の固定ロジックデバイスの詳細図である。 シーケンス番号を変更するのに実行される一連のステップの前半を示す図である。 シーケンス番号を変更するのに実行される一連のステップの後半を示す図である。 取引前リスクソフトウェア（ＰＴＲＳ）の詳細図である。 タイミング図である。 他のタイミング図である。 クライアント→市場（Ｃ２Ｍ）方向のパケットをトリミングする際の詳細なシーケンス図である。 市場→クライアント（Ｍ２Ｃ）方向のパケットを注入する際の詳細なシーケンス図である。 パケットが廃棄されるシナリオを示す図である。 パケットを変更するときに発生し得る問題を示す図である。 図１２に示した問題に対して可能な解決策を講じた場合のシナリオを示す図である。 パケットを変更するときに発生し得る別の問題を表したシナリオを示す図である。

前述したように、本発明の実施形態は、インラインコンテンツ検査・変更を提供するように構成されている。後述の方法や装置を実現するデバイスは、典型的に、第１および第２のネットワークエンドポイント間に位置したコンピュータネットワーキングデバイスにおいて実現される。後述する好適な実施形態についての詳細な説明の多くは、高頻度証券取引システムにおいて成行注文（market order）を含んだメッセージを監視するための検査デバイスの文脈で行うものとする。しかしながら、検査デバイスの実施形態は、データストリームのコンテンツを最小限のレイテンシで監視するための他の用途でも配備されることが可能である。これらには、機微なデータを検出する用途や、データ完全性や順序付けが重要となる用途（例えば、データベースシステム等）や、健康記録（health records）処理システムや、ブロックチェーンシステムや、より一般的に言えばパケットフィルタリングデバイスが含まれ得る。

例示的な一実施態様として、図１に示す高頻度証券取引ネットワークを取り上げたい。（証券会社により操作され得る）１つ以上のクライアント装置１２０，１２２が、（証券取引所により操作され得る）１つ以上の市場装置１３０，１３２とのネットワーキングセッション１４０，１４２を確立し、証券売買注文をこれらの市場装置１３０，１３２に送信する。売買注文は、メッセージとして形成され、パケット内で他のメッセージと合体させられたものであり得る。これらのメッセージは、アプリケーションレベルプロトコル（例えば、ＮＡＳＤＡＱ ＯＵＣＨ等）に準拠してやり取りされ得る。検査デバイス１１０は、前記クライアント装置と前記市場装置との間でネットワーキングセッション１４０，１４２を介して送信されるメッセージのコンテンツを検査する。好ましくは、検査デバイス１１０はカットスルー方式のデバイスであり、前記ネットワーク上での当該検査デバイス１１０の存在は、前記クライアント装置及び市場装置にとって不透明または見えないようになっている。このようなカットスルー方式の実施形態では、検査デバイス１１０でネットワークが途切れることなく、ネットワーキングセッション１４０，１４２が当該検査デバイス１１０をそのまま（straight）流れ通り得る。一部の実施形態において、ネットワークセッション１４０，１４２は、ＴＣＰ、Ｉｎｆｉｎｉｂａｎｄなどのシーケンス化（sequenced）トランスポートレベルプロトコルに準拠して確立される。

この実施形態において、検査デバイス１１０は、「不合格の（bad）」売買注文が確実に拒絶されるように機能し、つまり、クライアント→市場方向（Ｃ２Ｍ）に流れるメッセージを、幾つかのルールに準拠していない際には対応する（respective）市場装置に到達させないように機能する。検査デバイス１１０は、クライアント装置１２０から送信された、不合格の（badly formed）又は準拠していないメッセージが市場装置１３０に到達するのを防ぐために、この準拠していないメッセージに変更を施し、場合によっては当該メッセージのサイズを調節し得る。前記ネットワークセッションがＴＣＰなどのシーケンス化トランスポートプロトコルに準拠したものである環境では、検査デバイス１１０が、パケット内の準拠していないアプリケーションレベルメッセージを変更したことによるバイト数（bytes）の増減を考慮して、同じセッション（that session）内のＣ２Ｍ方向に届く後続のパケットのトランスポートプロトコルシーケンス番号（およびＭ２Ｃ方向に届く後続のパケットの確認応答シーケンス番号）を調節し得る。

また、好適な一実施形態において、検査デバイス１１０は、準拠していないメッセージが変更されたことを知らせる返信メッセージを生成し、その準拠していないメッセージを発信した前記クライアント装置へと、この返信メッセージを送信する。一部の実施形態において、前記返信メッセージは、検査デバイス１１０により前記ネットワークセッションへと「注入」されたものであり得て、かつ、前記準拠していないメッセージの意図された受信先である市場装置から発信されたかの如く見え得る。前記クライアント装置と前記市場装置との間に確立された前記ネットワークセッションがＴＣＰなどのシーケンス化トランスポートプロトコルに準拠したものであるときに、当該ネットワークセッションへと前記返信メッセージを注入する場合には、当該セッションにおいて市場→クライアント方向（Ｍ２Ｃ）に送信されるパケットのトランスポートプロトコルシーケンス番号の、当該返信メッセージのサイズを考慮した調節も含み得る。

図２に、検査デバイス１１０の例示的な一実施形態の詳細を示す。この例では検査デバイス１１０の機能がハードウェアとソフトウェアとの両方にわたって分散しているが、検査デバイス１１０は、ハードウェアだけの実現（実装）やソフトウェアだけの実現（実装）を含め、ハードウェアとソフトウェアとのあらゆる適切な組合せで実現されてもよい。例えばこの実施形態では、低レベルのレイテンシ（潜在または待ち）を達成するために、一部の機能がカットスルー方式の固定ロジックデバイス１１０によりハードウェアで実現されると同時に、他の機能はデバイスドライバ２５０及び取引前リスクソフトウェアアプリケーション２２０によりソフトウェアで実現される。カットスルー方式の固定ロジックデバイス２１０は、特定用途向け集積回路（ＡＳＩＣ）やフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含め、あらゆる適切な様式で実現されてもよい。取引前リスクソフトウェアアプリケーション２２０及びデバイスドライバ２５０は、コンピューティングコア（ＣＰＵ）などの少なくとも１つのプログラマブルなデータプロセッサで実行される命令として実現され得る。

（ファイバーケーブルや銅ケーブルを介したＩｎｆｉｎｉｂａｎｄやイーサネット（登録商標）を含め）あらゆる適切な物理ネットワーク層を用いることもできるが、この例における検査デバイス１１０は、クライアント装置、市場装置に各自接続され得る、２つのギガビットイーサネットＳＦＰ＋コネクタ（インターフェース）２３１，２３２を具備している。この例では、これらのコネクタ２３１，２３２が、１０ＧｉｇＥ（ギガビットイーサネット）ＭＡＣコア２１１，２１２に各自電子的に接続されている。この実施形態では、１０ＧｉｇＥ ＭＡＣコア２１１，２１２が、カットスルー方式の固定ロジックデバイス２１０により実現されている。

一部の実施形態では、カットスルー方式の固定ロジックデバイス２１０が、さらに、他のコンポーネントを含み得る。図２の例では、カットスルー方式の固定ロジックデバイス２１０が、さらに、後で詳述するパケット検査、シーケンス番号変更などの機能を実現し得る固定ロジック２１３コンポーネントを含む。固定ロジック２１３も、（後述するように）ＦＰＧＡ２１３により実現され得る。カットスルー方式の固定ロジックデバイス２１０は、さらに、ＰＣＩ Ｅｘｐｒｅｓｓ機能を実現し得るＰＣＩ−Ｅコア２１４を含む。この例において、ＰＣＩ Ｅｘｐｒｅｓｓは、ハードウェアとソフトウェアとの間で（より具体的には、カットスルー方式の固定ロジックデバイス２１０と取引前リスクソフトウェアアプリケーション２２０との間で）ＰＣＩ Ｅｘｐｒｅｓｓバス２４０を介してデバイスドライバ２５０を通じてデータを転送するための導管機構として使用される。しかしながら、ハードウェアとソフトウェアとの間では、ダイレクトメモリアクセス（ＤＭＡ）や（リングバッファ形式で配置され得る）共有メモリバッファやメモリマッピングを含め、あらゆる適切なデータ転送メカニズムが用いられてよい。

（検査デバイス１１０により実行される機能）
図３Ａは、取引ネットワークにおいて検査デバイス１１０がストリーム動的変更（ＤＳＭ）を実現しうる様子の一例を示す図である。ステップ３０１にて、クライアント装置１２０が、証券を売買する注文であるメッセージを含んだ元の又は本来の（original）パケットを生成する。当該元のパケットは、クライアント装置１２０と市場装置１３０との間でのセッション１４０コネクションを介して市場装置１３０へと宛てられたパケットである。ただし、このパケットは、まず、セッション１４０を監視することも可能な検査デバイス１１０を通過する（travels through）。この例において、前記元のパケットは、クライアントから市場への注文（ＯＣＭ）として、キャタピラー社（ＣＡＴ）の株を購入する第１のＯＣＭ、アップルコンピュータ社（ＡＰＰＬ）を売却する第２の注文、グーグル社（ＧＯＯＧ）を購入する第３の注文、およびテスラ社（ＴＳＬＡ）を売却する第４の注文の４つを含んでいる。

検査ノード１１０は、これらのメッセージのコンテンツが取引ルールに準拠しているか否かを検査する。例えば、それらのルールは、前記注文をチェックして、数量や価格が想定範囲内であるか否かや、制限付き株式についての取引、空売り又は明らかに誤りのある取引であるか否かを判断するものであり得る。また、ルールのチェックは、アカウント毎の数量、価格及び価値限度についての検査や、信用限度、集中限度、繰返し注文、エクスポージャー、仲介業者又は証券会社（broker）アカウント、およびセッションディセーブル（session disable）についての検査を含み得る。前記メッセージを検査するのに用いられる具体的なルールには数多くの種類のものがあり得て、どのようなルールであるのかは本実施形態にとって重要でない。

重要なのは、ステップ３０２にて検査デバイス１１０が、前記第３のメッセージ（グーグル社の株の注文）が不合格のメッセージであり、当該メッセージの全体を市場装置１３０に到達させるべきでないと判断するという点である。結果として、市場装置に送信される変更後パケットにはその不合格のメッセージが含まれず、ステップ３０３にて通知メッセージがクライアント１２０へと送り返される（例えば、セッション１４０へと「注入」される）。好適な一実施形態において、当該通知メッセージは、注文が拒絶された理由が入るフィールドを含む。

前述したように、本明細書で説明するストリーム動的変更（ＤＳＭ）の概念は、他のコンテンツ検査用途にも適用可能であることを理解されたい。図３Ｂに、この状況をさらに一般化したものを示す。ここでは、第１のエンドポイント３２０が第２のエンドポイント３３０とのセッションを確立している。ステップ３５１にて、前記第１のエンドポイントから、メッセージｍ１，ｍ２，ｍＮ，…ｍＫを含む元の（本来の）パケットが送信される。ステップ３５２にて、検査エンジン３１０は、そのうちの一つのメッセージｍＮが変更される必要があると判断し、変更後メッセージｍＮ’を生成する。そして、メッセージｍ１，ｍ２，ｍＮ’，…ｍＫを含む変更後パケットが、第２のエンドポイント３３０へと移動させられる。ステップ３５３にて、通知メッセージが第１のエンドポイント３２０へと返されて、前記元のパケット内のメッセージの一つが変更されたことを第１のエンドポイント３２０に知らせる。

（ストリーム動的変更）
好ましくは、前述のように検査デバイス１１０が、Ｃ２Ｍ ＴＣＰストリームのパケットから不合格のメッセージを除去してＭ２Ｃ ＴＣＰストリームのパケットにエラーメッセージを追加する手段としてのストリーム動的変更（ＤＳＭ）を実現する。検査デバイス１１０は、ＴＣＰセッションを妨害することなくこれを実行するために、ａ）Ｃ２Ｍ方向において除去された全バイトを追跡し、ｂ）ＴＣＰシーケンス番号をオンザフライで（on the fly）変更することによってそれを行う。

ＤＳＭでは、好ましくは各セッション・各方向毎に、例えば以下のような数種類のデータ値が維持される：

アキュムレータ：ＴＣＰストリームが続くあいだ（throughout the life of）除去／挿入された総バイト数を指す。好ましくは、これは、パケットのＴＣＰシーケンス番号を変更するのに利用されるハードウェアレジスタ（つまり、カットスルー方式の固定ロジックデバイス２１０内に維持されている）である。全ての変更バイトを追跡することにより、パケットのＴＣＰシーケンスをオンザフライで変更することが可能になる。ただし、このレジスタは、パケットのバイトが変更された場合であっても、当該パケットのＡＣＫを受信してからでしか更新されないものとされるのが好ましい。

デルタ：シーケンスマーカーを設定した最後のパケット（最新の変更後パケット）において除去／挿入されたバイト数を指す。好ましくは、デルタは、この最後のパケットで除去されたバイト数の一時的記憶部として機能するハードウェアレジスタである。デルタは、このパケットのＡＣＫが受信されるとアキュムレータに加算される。

シーケンスマーカー：バイトが除去／挿入された最後のパケット（すなわち、最新の変更後パケット、つまり、キル又は注入された最新のパケット）のシーケンス番号に基づいた数値を指す。例えば、パケットに開始シーケンス番号やＡＣＫシーケンス番号が付くＴＣＰを使った実施形態では、シーケンスマーカーが、最新の変更後パケットの（開始）シーケンス番号と当該最新の変更後パケットの（変更後の）バイト長との合計に基づいた数値とされ得る。ＴＣＰでは、この数値が、さらに、同じセッション内で同じ方向に移動する後続のパケットに対しての、次に予想される開始シーケンス番号とも等価又は同一になる。変更の一環としてパケットが完全に除去された場合、この除去したパケットの長さは変更後にゼロになることから、当該除去したパケットに対応するシーケンスマーカーは、当該除去したパケットの開始ＴＣＰシーケンス番号と同一になり得る。ＴＣＰを用いた場合には、シーケンスマーカー値が、さらに、（最新の変更後パケットが変更の結果として完全に除去されていないことが前提になるが）当該最新の変更後パケットを確認応答するＡＣＫシーケンス番号とも同一になる。このＡＣＫシーケンス番号は、反対方向に送信された、変更後パケットの受信を確認応答するためのパケット内に存在する。

なお、シーケンスマーカーよりも小さいシーケンス番号を持つパケットは、ＴＣＰシーケンスがアキュムレータぶんだけ変更される。シーケンスマーカー以上のシーケンス番号を持つパケットの場合には、ＴＣＰシーケンスがアキュムレータにデルタを足したぶん変更される。最新の変更後パケットのＡＣＫが受信されると、シーケンスマーカーがクリアされる。一部の実施形態では、最新のものまでの複数の変更後パケット（the last several modified packets）に対応する複数のシーケンスマーカー値が記憶され得る。これにより、確認応答が未だ済んでいない変更後パケットが複数存在する場合であっても、パケットのシーケンス値の調節を行うことが可能になる。

ＣＯＮＮ＿ＭＯＤ＿ＰＥＮＤＩＮＧ：変更に対してＡＣＫを未だ受信していないことを示すための、（ＰＴＲＳアプリケーションソフトウェア２２０で設定され得る）ブーリアン値を指す。変更後パケットがＤＭＡされると、このブーリアンが設定される。変更後パケットがＡＣＫされると、このブーリアンがクリアされる。このブーリアンは、変更後パケットが当該パケットの意図される宛先に到達したことを確認するために用いられる。データの変更は双方向で同時に発生する場合もある（典型的にそうである）ので、ＣＯＮＮ＿Ｃ２Ｍ＿ＭＯＤ＿ＰＥＮＤＩＮＧとＣＯＮＮ＿Ｍ２Ｃ＿ＭＯＤ＿ＰＥＮＤＩＮＧとが存在する。

以下の機能は、検査デバイス１１０により、ストリーム動的変更の一環として実行され得る：

不合格のメッセージの除去：ＤＳＭは、Ｃ２Ｍパケットストリームのパケットから不合格のメッセージを除去すると共に、Ｍ２Ｃパケットストリームのパケットにエラーメッセージを追加する。ＤＳＭは、コネクションを妨害することなくこれを実行するために、ａ）除去された全バイトを追跡し、ｂ）ＴＣＰシーケンス番号をオンザフライで変更する必要がある。ＤＳＭは、これを行うにあたって、各セッション毎にアキュムレータ、シーケンスマーカーおよびデルタを含む数種類の数値を維持する（後の欄で詳述する）。

Ｃ２Ｍ（クライアント→市場）変更パケット構築・送信・到達保証：検査デバイス１１０は、拒絶したＣ２Ｍパケットを、不合格のメッセージを除去することによって変更し得る。次に、これらの変更後パケットが、市場装置へと送信される。遅延ＡＣＫ検出とポーリングと繰返し再送との組合せを用いることにより、それら変更後パケットの送信成功が保証され得る。Ｃ２Ｍ変更後パケットの、市場への到達が保証される。

Ｍ２Ｃ（市場→クライアント）エラーパケット構築・送信・（送信者への）送戻し・到達保証：検査デバイス１１０は、メッセージが拒絶されたことをクライアントに知らせるためにＭ２Ｃエラーパケットを構築し得る。

ＴＣＰ機能障害／切断の回避：ＤＳＭは、ＴＣＰ機能障害を回避して、ＴＣＰストリームでデータを整然に（cleanly）除去／追加し得る。また、ＤＳＭは、ＴＣＰフラグメンテーション（断片化）の最中であっても変更後メッセージの送信実行（attempts）を処理し得る。セッションの切断は、必要のない限り避けられるべきである。

データ挿入／エラー注入：Ｃ２Ｍ方向で変更が行われると、データ挿入／エラー注入を用いて拒絶がクライアントに知らされ得る。１）ヘッダおよび２）各プロトコル固有の（protocol specific）拒絶メッセージを含むメッセージが連結してなるパケットが、Ｍ２Ｃ ＴＣＰストリームへと注入される。これにより、クライアントは、自身の注文の状態を知ることができ、不要なキャンセルの嵐やアルゴリズムの混乱が回避される。このエラー注入は市場側から完全に隠れており、バイトが注入されてもＴＣＰコネクションはアクティブのまま維持される。

ＡＣＫ検出／到達保証：好ましくは、検査デバイス１１０は、クライアント方向及び市場方向のいずれに変更後パケットが送信された場合にも、当該パケットの到達を保証するものであるのが望ましい。この到達保証は、１）変更後パケットが送信された方向と反対方向に届いたパケットのＡＣＫシーケンスをチェックしたり、２）固定ロジック（ＦＰＧＡ）２１３からデルタレジスタを読み出すことで、当該デルタレジスタがゼロになったか否か（シーケンスマーカーに相当するＡＣＫが届いたことを示唆する）を確認したりすることによって実行され得る。ＡＣＫ検出は、これら両方の方法を用いて、パケットが意図される宛先に到達したか否かをチェックする。ＡＣＫが一定の時間枠内に検出されなかった場合には、変更後パケットが再送される。これは、検査デバイス１１０が諦めてセッションを切断するまで続けられる。

データ除去／変更：検査デバイス１１０は、キルされたパケットからバイトを除去することにより、メッセージの拒絶方法としてのＧａｐ Ｆｉｌｌ ＯｖｅｒｗｒｉｔｅやＯｎｅ ａｎｄ Ｄｏｎｅを避けることができる。このデータ除去は市場側から完全に隠れており、ＴＣＰコネクションがアクティブのまま維持される。

（カットスルー方式の固定ロジックデバイス２１０）
ＤＳＭは、Ｃ２Ｍ ＴＣＰストリームのパケットから不合格のメッセージを除去すると共に、Ｍ２Ｃ ＴＣＰストリームのパケットにエラーメッセージを追加する。ＤＳＭは、コネクションを妨害することなくこれを実行するために、ａ）除去された全バイトを追跡し、ｂ）ＴＣＰシーケンス番号をオンザフライで変更する必要がある。ＤＳＭがこれを行うにあたって使用する３種類の数値については、先述のリストアップどおりである（アキュムレータ、シーケンスマーカーおよびデルタ）。

図４は、最初に図２で図示したカットスルー方式の固定ロジックデバイス２１０の一実施形態の詳細図である。カットスルー方式の固定ロジックデバイス２１０は、（クライアント側と市場側とで一つずつの）２つの１０ＧｉｇＥ ＭＡＣコア２１１，２１２、固定ロジック（ＦＰＧＡ）２１３、ＰＣＩ ｅｘｐｒｅｓｓコア２１４、およびメッセージ変更データストア４４０を含む。

一部の実施形態において、固定ロジック２１３は、パケット検査エンジン（ＰＩＥ）コンポーネント４２０、およびシーケンス番号変更ロジックコンポーネント４３０を含み得る。パケット検査エンジン４２０は、クライアントと市場装置との間のネットワーキングセッションで送信された、アプリケーションレベルメッセージを含むネットワーク化パケットを検査し、クライアントから発信されたメッセージのうち、所与のメッセージが準拠しており市場装置へと到達させてよいものなのか、それとも、当該メッセージが変更の必要があるものなのかを判断し得る。一部の実施形態では、メッセージが変更されると、シーケンス番号変更ロジック４３０により、同じセッションにおける後続のパケットのトランスポートプロトコルシーケンス番号が変更され得る。

この例では、カットスルー方式の固定ロジックデバイス２１３が、さらに、メッセージ変更データストア４４０も含んでいる。メッセージ変更データストア４４０は、メッセージの変更やシーケンス番号の変更に関連して使用される状態情報を記憶し得る。メッセージ変更データストア４４０は、各セッション・各方向毎（Ｃ２ＭとＭ２Ｃの両方）に維持され得る。この例ではメッセージ変更データ４４０がカットスルー方式の固定ロジックデバイス１１０自身内に存在しているものとして描かれているが、当該メッセージ変更データはカットスルー方式の固定ロジックデバイス２１０内の任意の他の適切な記憶コンポーネント、またはカットスルー方式の固定ロジックデバイス２１０にアクセス可能である任意の他の適切な記憶コンポーネント内に存在しているものとされてもよい。

メッセージ変更データ４４０は、累積値を追跡するのに各々用いられ得る少なくとも１つのハードウェアアキュムレータ４４１を含み得る。所与のセッション内で所与の方向に流れるパケットのシーケンス番号は、当該セッション・方向での少なくとも１つの先行する（prior）パケットの変更の結果として、その累積値だけ変更され得る。所与のセッションのプロトコルとして、受信側エンドポイントにより確認応答されたパケットのシーケンス番号を含む確認応答（ＡＣＫ）パケットが含まれている実施形態では、ハードウェアアキュムレータ３４１が、同じセッション（that session）内で反対方向に流れるＡＣＫパケットのＡＣＫシーケンス番号を変更するのにも使用され得る。一部の実施形態では、少なくとも１つのデルタレジスタ４４２を維持するのが有用であり得る。デルタレジスタ４４２は、ＡＣＫパケットでの確認応答が未だ済んでいない、新たに変更されたばかりのパケットのサイズが変化したこと（a difference in size）によるシーケンス番号の差分を追跡するのに用いられ得る。デルタレジスタ４４２の数値は、前記検査デバイス内の、ハードウェアレジスタまたは任意の他の適切な揮発型もしくは不揮発型のメモリもしくはストレージに記憶され得る。メッセージ変更データ４４０は、さらに、少なくとも１つのシーケンス番号マーカー４４４を含み得る。シーケンス番号マーカー４４４は、パケットのシーケンス番号に基づいて処理（action）を行う際の少なくとも１つの閾値として利用され得る。例えば、一部の実施形態において、シーケンス番号マーカー４４３は、新たに送信されたばかりの変更後パケットの予想ＡＣＫシーケンス番号を表すものとして用いられ得る。そして、シーケンス番号マーカー４４３に記憶された数値と一致するＡＣＫシーケンス番号を持つパケットを受信すると、デルタレジスタ４４２の数値がハードウェアアキュムレータ４４１に適用され得る。

一部の実施形態では、準拠していないパケットが未だ検査デバイス１１０による変更過程にある場合、この変更中のパケットと同じセッションかつ同じ方向で受信した後続のパケットの送信を、当該変更中のパケットが完全に処理されるまで先送り（delay）するのが望ましくあり得る。この先送りは、変更が必要なパケットの後に同じセッション内で送り出された準拠している（変更が必要でない）パケットが、その変更中のメッセージよりも先に宛先の市場装置に到達してしまうという状況を防ぐのに望ましくあり得る。このような実施形態では、パケットスキップ阻止インジケータ４４６をイネーブルする（有効にする）ことによって変更を必要とするメッセージが検出されたことを示し得ると共に、未だ変更過程にあるそのようなパケットのシーケンス番号の数値が最新シーケンス番号４４４にも記憶され得る。この例では、パケットスキップ阻止インジケータ４４６がイネーブルされている間は、後続のパケットの送信が先送りされ得る。一部の実施形態では、さらに変更中のパケットが完全に処理され、かつ、パケットスキップ阻止がイネーブルされた結果として先送りされていた後続のパケットが完全に処理されると、パケットスキップインジケータ４４６がクリアされ得る。一部の実施形態では、これに加えて又はこれに代えて、パケットスキップ阻止インジケータ４４６をクリアするか否かの判断が、変更後パケットのシーケンス番号と最新シーケンス番号４４４の数値とを比較することを含み得る。パケットスキップ阻止インジケータ４４６がクリアされた後に検査デバイス１１０に届いたパケットは、通常の方法で処理されることになり得る。そして、準拠しているパケットは、前記検査デバイスをそのまま（directly）通って、意図される受信先システム（すなわち、クライアント装置１２０又は市場装置１３０）へと向かい得る。

同様に、一部の実施形態では、Ｃ２Ｍ方向のメッセージの変更が必要であり、かつ、対応する返信メッセージを同じセッション（that session）のＭ２Ｃ方向に注入してもよいと判断された場合、コネクションストールモードインジケータ４４８を用いて、Ｍ２Ｃ方向に入って来たパケットの送信が先送りされ得る。一部の実施形態では、Ｃ２Ｍパケットの変更が必要かもしれないことが検出されるとコネクションストールモードインジケータ４４８がイネーブルされ得て、Ｍ２Ｃ返信メッセージが完全に構築又は注入されると当該コネクションストールモードインジケータ４４８がディセーブルされ（無効にされ）得る。このような実施形態では、コネクションストールモードインジケータ４４８がイネーブルされている間は、同じセッション（that session）のＭ２Ｃ方向で受信した後続のメッセージが先送りされ得る。パケットスキップ阻止インジケータ４４６で示されるＣ２Ｍ方向の先送り、およびコネクションストールモードインジケータ４４８で示されるＭ２Ｃ方向の先送りのどちらの場合の先送りも、あらゆる適切な方法で実現されてよい。例えば、一部の実施形態では、前記インジケータがイネーブルされている間、対応する方向（that direction）のメッセージを処理するＣＰＵコアがストールされ得る。他の実施形態では、送られてきた後続のメッセージが、後で処理できるように（for later processing）キューに格納され得る。

（通知ありのメッセージ変更のための一連の処理の一例）
図５及び図６は、シーケンス動的変更を実現するために検査エンジン１１０により実行され得る一連の処理を表した具体例である。

これらの図には、アキュムレータ、デルタおよびシーケンスマーカーを用いて、ＴＣＰコネクションの一方の側（Ｃ２Ｍストリーム）を維持しながら、当該コネクションを切断又は中断せずにパケットからバイト（さらにはメッセージ全体）を除去しうる様子が描かれている。

図５を参照すると、時刻ｔ０（ステップ５００）にて、アキュムレータおよびデルタが「０」などの初期値に設定される。時刻ｔ１（ステップ５０１）では、パケットを「キル」する必要がある（つまり、パケット内の少なくとも１つのメッセージが変更される必要がある）場合、除去したバイト数がデルタレジスタに記憶される。この例では、シーケンス番号７０から始まる１０個のバイトがキルされて、デルタレジスタの数値が「−１０」に設定された。これに応じて、シーケンスマーカーの数値は「７０」に設定された。そのパケットのＡＣＫが届くと、デルタのバイト数がアキュムレータに加算される。キルされたパケットから除去されたバイト数は、当該パケットの送信後直ぐにアキュムレータへと加算されるわけではない。というのも、先ほどのＡＣＫが、キルされたパケットの前に送信されたパケットの確認応答である可能性もあるからである。キルされたパケットの前に送信されたそのようなパケットのＡＣＫが間違った数値にならないよう確実にするために、アキュムレータへのデルタの加算は時刻ｔ２まで先延ばしされる（ステップ５０２）。

時刻ｔ２では、シーケンスマーカー値、アキュムレータ値、およびデルタレジスタ値を用いて、Ｍ２Ｃ方向に移動するＡＣＫパケットのＡＣＫシーケンス番号が調節される。

時刻ｔ３に受信した第２のＣ２Ｍパケット（ステップ５０３）は、開始シーケンス番号が８０で、パケット長が２０である。このパケットは、不合格のメッセージを含んでおらず、キルされる必要がなく、市場へと渡されてよいものである。ただし、このパケットは、アキュムレータ値を用いて当該パケットのシーケンス番号が調節されてから、市場へと引き継がれる。

時刻ｔ４にて、前記第２のＣ２ＭパケットのＡＣＫを受信する（ステップ５０４）。このＡＣＫも、再びアキュムレータ値を用いてシーケンス番号が調節されてからクライアントに渡される。

続いて図６を参照すると、時刻ｔ５にて受信した第３のＣ２Ｍパケット（ステップ５０５）は、シーケンス番号が１００で、パケット長が２０である。第３のＣ２Ｍパケットも、アキュムレータ値によってシーケンス番号が調節されてから市場側に渡される。

時刻ｔ６（ステップ５０６）にて、前記第３のＣ２ＭパケットのＡＣＫを市場から受信する前に、シーケンス番号が１２０で、パケット長が２０である第４のＣ２Ｍパケットを受信する。この第４のパケットは、バイトが除去又は「キル」される必要がある。時刻ｔ７（ステップ５０７）では、この（previous）パケットのＡＣＫを未だ受信していないので、Ｍ２Ｃ確認応答シーケンス番号からアキュムレータだけが減算される。ｔ８（ステップ５０８）にて、ＡＣＫを受信すると、アキュムレータへのデルタの加算が可能となる。

時刻ｔ９（ステップ５０９）にて、シーケンス番号が１４０で、パケット長が２０である第５のＣ２Ｍパケットを受信する。これまでと同じく、アキュムレータ値がシーケンス番号に加算されて（added to arrive at）変更後パケットとなる（use for the modified packet）。時刻ｔ１０（ステップ５１０）にて受信したさらなる（another）ＡＣＫも、アキュムレータ値だけ調節される。

前述したように、ＤＳＭのこの実施態様では、Ｃ２Ｍ側のアーキテクチャとＭ２Ｃ側のアーキテクチャとが互いにパラレルとされる。よって、好ましくは、Ｃ２Ｍ方向とＭ２Ｃ方向とで、かつ、各セッション毎に、別々のアキュムレータ、デルタおよびシーケンスマーカーが存在する。結果として、Ｍ２Ｃ ＴＣＰストリームへと通知メッセージ用にバイトが追加される際（エラー注入の場合）には、正のデルタが使用され得る。結果として、Ｍ２Ｃ側でデルタがアキュムレータに加算されると、バイトの加算を表す正の変化が見られる。Ｍ２ＣメカニズムとＣ２Ｍメカニズムとのこのような二重性は、好適なＤＳＭアーキテクチャの重要な側面である。

後述の詳細な説明からも理解できるように、一部の実施態様では、固定ロジック２１３（ＦＰＧＡ）ハードウェアのアキュムレータ及びデルタレジスタの数とＰＴＲＳソフトウェア２２０のアキュムレータ及びデルタレジスタの数とが異なるものとされ得る。例えば、ＰＴＲＳソフトウェア２２０はアキュムレータとデルタとのセットを２セット（各フローでのＣ２ＭとＭ２Ｃとの各方向に１セットずつ）を使用し得るのに対し、固定ロジックハードウェア２１３はアキュムレータとデルタとのセットを４セット使用し得る。ここで、ハードウェアアキュムレータ／デルタの最初の２セットは、各セッション（フロー）の各方向（Ｃ２Ｍ及びＭ２Ｃ）における通常シーケンス番号を追跡するのに用いられる。残りの（second）２セットは、各セッションの各方向（Ｃ２Ｍ及びＭ２Ｃ）におけるＡＣＫシーケンス番号を追跡するのに用いられる。以上の考え方に沿ったアキュムレータ／デルタのモデルについては、後で詳細に述べる。

図７は、検査デバイス１１０内における取引前リスクソフトウェア２２０のコンポーネント（構成要素）であって、モジュール分解（Modular Decomposition）、Ｃ２Ｍ不合格メッセージ変更およびＣ２Ｍ変更送信を含む、一部のＤＳＭ機能を実現するコンポーネントを示す図である。

取引前リスクソフトウェア２２０は、メッセージ変更データストア７７０を含み得る。メッセージ変更データストア７７０は、取引前リスクソフトウェア２２０によってメッセージ変更に関連して利用され得る。カットスルー方式の固定ロジックデバイス２１０との関連で説明したメッセージ変更データ４４０と同じく、メッセージ変更データ７７０は、各セッション・各方向（すなわち、Ｃ２ＭとＭ２Ｃの両方）毎に記憶される状態情報であり得る。メッセージ変更データ７７０は、取引前リスクソフトウェア２２０により任意の適切な方法で記憶・アクセスされ得る。メッセージ変更データ７７０は、ハードウェアアキュムレータ４４１と同様の概念である少なくとも１つのソフトウェアアキュムレータ７７１、およびデルタレジスタ４４２と同様の概念である少なくとも１つのデルタ値７７２を含み得る。メッセージ変更データ７７０は、さらに、メッセージペンディングインジケータ７７５（本明細書では、Ｃ２Ｍ方向がＣＯＮＮ＿Ｃ２Ｍ＿ＭＯＤ＿ＰＥＮＤＩＮＧ、Ｍ２Ｃ方向がＣＯＮＮ＿Ｍ２Ｃ＿ＭＯＤ＿ＰＥＮＤＩＮＧと称される場合もある）を含み得る。一部の実施形態では、これらのメッセージ変更ペンディングインジケータが、変更後パケットのＡＣＫを未だ受信していないことを示すのに用いられ得る。

図７には、さらに、検査デバイス１１０を流れ通るパケットを処理して且つメッセージ変更データ７７０を利用する、コンポーネント７１０〜７４６（以下で詳細に説明する）が描かれている。この例では、コネクションマネージャ７１０が、例えば発信ＩＰアドレス／ポートや宛先ＩＰアドレス／ポートに基づいてセッションを特定し、かつ、ＡＣＫ及びＳＹＮ ＡＣＫの状態を維持するなどしてクライアント側と市場側との両方のコネクション状態のモデルを実現し得る。また、コネクションマネージャ７１０は、遅延ＡＣＫ検出モジュール７２０をコールし得る。遅延ＡＣＫ検出モジュール７２０は、メッセージ変更データ４７０を利用して市場による変更後パケットの受信やクライアントによる注入メッセージの受信が確実に成功するようにさせるためのロジックを有し得る。遅延ＡＣＫ検出モジュール７２０は、変更後パケット又は注入パケットのＡＣＫを受信側で受信するまで当該パケットを定期的に再送することによりそれを実行し得る。

また、ＴＣＰなどといった、順番どおりの送達（in-order delivery）を保証するシーケンス化されたネットワークセッションを用いた実施形態において、コネクションマネージャ７１０は、パケットが当該パケットのシーケンス番号に従った適切な順番で検査デバイス１１０により処理されるよう確実にし得て、パケットの重複処理を回避し得る。

前述したように、パケットは典型的に１つ以上のメッセージを含み得る。よって、パケット内の各メッセージは、個別にコンポーネント７３２，７３４，７３６により処理され得る。様々なアプリケーションプロトコルに準拠したメッセージが送信され得る実施形態では、プロトコル抽象化レイヤ７３２がアプリケーションプロトコル毎の処理を実行し得る。

次に、Ｃ２Ｍデータ変更パケット構築モジュール７３４により、変更が必要なメッセージが処理され得る。Ｃ２Ｍデータ変更パケット構築モジュール７３４は、準拠していないメッセージに変更を施し得る。また、Ｃ２Ｍデータ変更パケット構築モジュール７３４は、変更後のメッセージのサイズが元の変更前のメッセージのサイズから変化した（different）場合に、（他の箇所で説明するように）セッションに対応したＣ２Ｍ方向のソフトウェアアキュムレータ７７１および／またはデルタ値７７２の新しい数値を算出し得る。同様に、Ｍ２Ｃデータ挿入パケット構築モジュール７３６が、その変更後のメッセージと同じセッションのＭ２Ｃ方向に注入すべき返信メッセージを構築し得て、かつ、当該セッションに対応したＭ２Ｃ方向のソフトウェアアキュムレータ７７１および／またはデルタ値７７２の新しい数値も算出し得る。

図７の例では、Ｃ２Ｍデータ変更パケット構築モジュール７３４が、次に、この変更後パケットを市場へと送信するためのロジックを実行し得る。一部の実施形態では、Ｃ２Ｍデータ変更パケット構築モジュール７３４が、カットスルー方式の固定ロジックデバイス２１０への変更後パケットのデータ転送を実行して当該変更後パケットを市場装置１３０へと送信し得る。Ｃ２Ｍデータ変更パケット構築モジュール７３４は、さらに、Ｃ２Ｍ方向のソフトウェアアキュムレータ７７１および／またはデルタ値７７２の対応する数値もカットスルー方式の固定ロジックデバイス２１０に転送し得る。

同様に、Ｍ２Ｃデータ挿入パケット構築モジュール７３６が、クライアント１２０へと送信すべき返信メッセージをセッションに注入するためのロジックを実行し得る。一部の実施形態では、Ｍ２Ｃデータ挿入パケット構築モジュール７３６が、返信メッセージを含む新たに構築されたパケットの、カットスルー方式の固定ロジックデバイス２１０へのデータ転送を実行して当該パケットを送信し得る。Ｍ２Ｃデータ挿入パケット構築モジュール７３６は、さらに、Ｍ２Ｃ方向のソフトウェアアキュムレータ４７１および／またはデルタ値４７２の対応する数値もカットスルー方式の固定ロジックデバイス２１０に転送し得る。

ＰＴＲＳアプリケーションソフトウェア２２０の上記コンポーネントにより制御されるＤＳＭデータフローの一例は、以下のようになり得る：

キルされたメッセージを含むパケットがデータパスに（例えばコネクションマネージャ７１０に）到達すると、当該パケットは（例えばプロトコル抽象化レイヤ７３２により）パースされてから、Ｃ２Ｍデータ変更パケット構築７３４にて変更が施されるように送り出される。

そして、Ｍ２Ｃデータ挿入パケット構築７３６により、キルされた各メッセージ毎にＭ２Ｃエラーパケットが生成される。このパケットは、拒絶をクライアントに知らせるのに使用される。

これらのメッセージが生成された後、送信機能（例えばＣ２Ｍデータ変更７４４及びＭ２Ｃデータ挿入７４６）がコールされる。キルされた変更後Ｃ２ＭパケットとＭ２Ｃエラーパケットの両方が送信される。

これらのパケットが送信された後、当該パケットシーケンスのＡＣＫが遅延ＡＣＫ検出モジュール７２０において検出される。到達を保証するために、パケットは例えば１０ｍｓ（ミリ秒）毎に合計１００ｍｓになるまで定期的に再送され得る。１００ｍｓの時点で、ＡＣＫが届いていなければセッションが切断される。

ＣＰＭ（近接変更［Close Proximity Modification］）検出、コアストール（core stalling）などの他の機能も、送信モジュール７４４，７４６で実行され得る。ＣＰＭは、先に（first）キルされたパケットのＡＣＫが届く前に次の（second）キルされたパケットがソフトウェアに届いた場合に起こる。この場合については、後述の欄で詳細に説明する。

好ましくは、Ｃ２Ｍ方向のデータ変更は、あらゆる数の不合格メッセージをアクティブＴＣＰストリームにおいて除去又は変更するということが、アクティブＴＣＰセッションのシーケンス順序（sequencing）を維持しながら出来るように実現される。つまり、モジュール７４４でのＴＣＰパケットの変更は、クライアント側ＴＣＰスタック及び市場側ＴＣＰスタックから見えない（hidden）ようになされるのが望ましい（ただし、クライアントに対しては、メッセージが除去されたことが前述のように通知される必要がある）。

一部の実施態様では、不合格のメッセージが、ハートビートなどの何らかの種類の新たなメッセージに置き換えられる。すなわち、一部の実施態様ではＣ２Ｍデータ変更７４４が、不合格のメッセージを除去する際に必ず当該不合格のメッセージを他の何かに置き換える。これにより、メッセージの変更が単純化されると共に、少なくとも幾つかのペイロードが送信されることが可能となる（すなわち、パケットは、完全に上書きされて０バイトのペイロードになるようなことがなくなる）。

一部の実施形態では、メッセージ変更機能の少なくとも一部が、プロトコル抽象化レイヤ７３２のロジックにより実現され得る。これは、必要となる変更の種類が、所与のセッションを確立したときの市場プロトコルが具体的に何であるのかに左右され得るからである。例えば、ＮＡＳＤＡＱ ＯＵＣＨアプリケーションプロトコルに準拠したものである場合、パケットからメッセージ全体が除去されてもよい。しかし、ＴＳＥアプリケーションプロトコルに準拠してメッセージをやり取りする場合には、市場とクライアントとの間のアプリケーションレベルのシーケンス順序を維持するために、キルされたメッセージがハートビートに置き換えられるのが望ましい。

一部の実施形態では、Ｃ２Ｍデータ変更送信（再送）が、例えば他にも以下のような機能を実行し得る：

−パケットのＩＰヘッダ長を再計算して、除去されたバイトが含まれていないことを確認する；

−ＤＭＡを用いて変更後パケットをカットスルー方式の固定デバイス２１０に転送し返す際に、必要な（例えばＤＭＡヘッダ内やＤＭＡコール等の）数値／ビットを設定する。これらの数値には、下記のものが含まれ得る：

ＤＭＡヘッダ内のＲａｗ（未変更）／Ｔｒａｎｓｆｏｒｍ（変更）ビット：このＤＭＡヘッダビットを「１」に設定することにより、ハードウェアはＴＣＰチェックサム、ＣＲＣおよびＴＣＰシーケンスを再計算する。

ＤＭＡヘッダ内の符号付き１２ビットデルタ：ＤＭＡヘッダ内のこのデルタを設定することにより、パケット内の変更されたバイト数を伝える（正のデルタ信号バイトは加算されたことを指し、負の信号バイトは減算されたことを指す）。固定ロジック２１３は、この数値を用いて当該固定ロジック２１３のハードウェアデルタレジスタを更新する。

符号なし３２ビットシーケンスマーカー：これは、シーケンスマーカーを、転送対象の変更後パケットの開始ＴＣＰシーケンスに基づく数値に設定する。これは、変更後パケットのＡＣＫを受信した際に「仕掛け」を発動させる（spring the “mousetrap”）のに用いられる。

符号なし３２ビットＣＡＭエントリー：これは、ＤＭＡするパケットの連想メモリ（ＣＡＭ）値を設定する。これは、ａ）パケット修正（touches up）時に用いる適切なＴＣＰシーケンス；および、ｂ）新しい数値で更新すべきデルタ／アキュムレータ；を固定ロジック２１３に伝えるのに用いられ得る。

変更後パケットの送信後、前述したＣＯＮＮ＿Ｃ２Ｍ＿ＭＯＤ＿ＰＥＮＤＩＮＧブーリアンを設定し得る。

（遅延ＡＣＫチェックのタイミング）
図８Ａ及び図８Ｂは、Ｃ２Ｍ遅延（Lazy）ＡＣＫチェック機能を詳細に説明したタイミング図である。

遅延ＡＣＫチェックは、１）市場への変更後パケットの到達を保証し、２）（後述の欄で説明する）ＣＰＭを回避するのに用いられる。変更後パケットは、検査デバイス１１０と市場との間で廃棄されてしまう可能性がある。このリスクのため、再送してパケットの到達を保証するためのシステムが用意されているのが望ましい。

遅延ＡＣＫチェック機能は、ＣＯＮＮ＿Ｃ２Ｍ＿ＭＯＤ＿ＰＥＮＤＩＮＧブーリアンが設定されたときにイネーブルされ得て、以下のように動作する：

パケット（ただし、当該パケットは、シーケンスマーカー以上のシーケンス番号を持つものであるとする）に対してのＡＣＫを受信したか否かを確認するために、対応するセッションの全てのＭ２Ｃパケットが調べられる。このパケットのＡＣＫを受信すると、ＣＯＮＮ＿Ｃ２Ｍ＿ＭＯＤ＿ＰＥＮＤＩＮＧブーリアンがクリアされる。

固定ハードウェア２１３のデルタレジスタが、１００ｍｓ以下の間隔（市場との間でのほぼ１往復（ｒｔｔ）の間隔）でポーリングされる。好ましくは、このレジスタは、１０ｍｓ毎に１回以下の間隔でポーリングされる。というのも、これは、時間計算量の観点からみて量の大きいコールだからである。このレジスタがクリアされていれば、（デルタがアキュムレータに加算されているので）変更後パケットのＡＣＫを受信したということであり、ＣＯＮＮ＿Ｃ２Ｍ＿ＭＯＤ＿ＰＥＮＤＩＮＧブーリアンがクリアされ得る。

デルタがクリアされていなければ、変更後パケットが再送される。Ｂｕｚｚｓａｗでのパケット再送時には、ＦＰＧＡがデルタを適用したことによってシーケンスが不正確とならないように、シーケンス番号を調節する必要がある。この時点では（still）ＦＰＧＡのデルタがクリアされていない（waiting to be cleared）ため、再送されるパケットのシーケンスにこのデルタ値が誤って適用されてしまうのである。結果として、この調節を打ち消すために、再送前にソフトウェアがＴＣＰシーケンス番号を調節する必要がある。

１００ｍｓになると、セッションがタイムアウトして切断される。市場との間での４ｒｔｔのあいだＡＣＫが確認できない場合、ＡＣＫを受信することはないと予想され、セッションを切断するのが最善であるとされる。

ＡＣＫを受信した場合には、ＣＯＮＮ＿Ｃ２Ｍ＿ＭＯＤ＿ＰＥＮＤＩＮＧブーリアンがクリアされて、このコネクション内での遅延ＡＣＫチェックシステムが非アクティブとされる。

遅延ＡＣＫチェックは、相異なる２つのモジュールにより実現され得る。一方のモジュールは、コネクションマネージャ７１０内のＣＯＮＮ＿ＡＣＴＩＶＥ状態の上位で実行される（occurs at the top of）（図７）。ＣＯＮＮ＿ＡＣＴＩＶＥ状態は、フレーム方向、ＣＯＮＮ＿ＭＯＤ＿ＰＥＮＤＩＮＧブーリアン、およびＴＣＰシーケンスのＡＣＫをチェックする。他方のモジュールは、１０ｍｓ再送時間をチェックするところ、これはコネクションマネージャ７１０内での別のプロセス又はスレッドで追跡され得る。

キルされたパケットの到達を保証するためのＣ２Ｍパケット再送は、必ずしも必要でない。というのも、クライアントが、キルされたパケットを代わりに（for us）再送するからである。しかし、ＣＰＭ（詳細については他の箇所でのＣＰＭの説明を参照されたい）を回避するのに再送が必要となるため、Ｃ２Ｍ側の自動再送は維持され得る。

（Ｍ２Ｃデータフロー：データ挿入の概要）
データ挿入は、Ｃ２Ｍメッセージが拒絶されたことに応答してエラーメッセージを注入するために意図されたＭ２Ｃ機能である。クライアント側サーバは市場に送信した注文の状態を把握する必要があるので、メッセージが拒絶されたことをクライアントに通知することは重要な機能である。クライアントに注文についての通知が行かない（fails to receive）と、クライアント側でキャンセルの嵐やアルゴリズムの混乱が典型的に起こり得る。

Ｍ２Ｃエラー注入パケットは、当該パケットがＭ２Ｃ通知メッセージを含んでいることを特定するための複数のフィールド、および／または、拒絶を受けた（applied）メッセージの識別子（例えばクライアント注文ＩＤ等）、および／または、メッセージが拒絶された理由を示すエラーマスク、および／または、クライアントと市場装置との間で使用される上位プロトコルに依存する各市場プロトコル（例えばＦＩＸ等）固有のフィールドを含み得る。

Ｍ２Ｃエラー挿入モジュールは、Ｃ２Ｍデータ削除が実行された後にコールされる。Ｍ２Ｃエラー挿入は、Ｍ２Ｃエラーメッセージをペイロードに追加する。このＭ２Ｃエラーメッセージは、拒絶されたクライアント注文ＩＤを各市場プロトコル固有のメッセージ拒絶中に使用することで、どの特定のメッセージが拒絶されたのかをクライアントに知らせる。

各拒絶毎に、一つのＭ２Ｃエラーメッセージが生成されるのが望ましい。一つのパケットが複数の拒絶を受けている場合、Ｍ２Ｃエラーパケットは各拒絶毎に一つのエラーメッセージを含むことになる。好ましくは、各エラーメッセージの長さは、キルされたメッセージのサイズよりも小さいのが望ましい。これにより、複数のＭ２Ｃエラーメッセージを連結して一つのパケットにすることができるので、１ＭＴＵよりも大きいＭ２Ｃエラーパケットが生成されるリスクが避けられる。結果として、キルされた各パケットにつき、Ｍ２Ｃエラーパケットを一つ送信するだけで済むことになる。

再び図７を参照する。以下では、Ｍ２Ｃデータ挿入パケット構築モジュールの機能を詳細に説明する。

変更後Ｃ２Ｍパケットが送信された直後に、Ｍ２Ｃエラー送信機能がコールされる。この機能は、以下のとおりである：

パケットのＩＰヘッダ長を再計算して、注入されたバイトが含まれていることを確認する。

新しいＩＰヘッダＩＤを設定する。このＩＤは、フラグメント化（断片化）されたパケットをＴＣＰスタックで識別するのを支援するものである。ランダムなＩＤを挿入することにより、このエラー注入がフラグメント化されたパケットの一部であると受信側のロジックが解釈してしまう可能性が避けられる。

ＤＭＡヘッダ内やＤＭＡコールの必要な数値／ビットを設定する。数値の説明については、下記の内容を参照されたい。

ＤＭＡヘッダ内のＲａｗ（未変更）／Ｔｒａｎｓｆｏｒｍ（変更）ビット：このＤＭＡヘッダビットを「１」に設定することにより、ハードウェアはＴＣＰチェックサム、ＣＲＣおよびＴＣＰシーケンスを再計算する。

ＤＭＡヘッダ内の符号付き１２ビットデルタ：ＤＭＡヘッダ内のこのデルタを設定することにより、パケット内の変更されたバイト数を伝える（正のデルタ信号バイトは加算されたことを指し、負の信号バイトは減算されたことを指す）。ＦＰＧＡは、この数値を用いて、特定されたＣＡＭでの当該ＦＰＧＡのハードウェアデルタレジスタを更新する。

符号なし３２ビットシーケンスマーカー：これは、シーケンスマーカーを、転送対象の変更後パケットの開始ＴＣＰシーケンスに基づく数値に設定する。これは、変更後パケットのＡＣＫを受信した際に「仕掛け」を発動させる（spring the “mousetrap”）のに用いられる。

符号なし３２ビットＣＡＭエントリー：これは、ＤＭＡするパケットのＣＡＭ値を設定する。これにより、ａ）パケット修正（touches up）時に用いる適切なＴＣＰシーケンス；および、ｂ）新しい数値で更新すべきデルタ／アキュムレータ；がＦＰＧＡに伝えられる。

ＤＭＡヘッダ内のＭ２Ｃコネクションストールクリアビット：このＤＭＡヘッダビットを「１」に設定することにより、Ｍ２Ｃコネクションストールがクリアされる。キルされたメッセージが最初にＣ２Ｍデータ削除モジュールで検出されると、Ｍ２Ｃ方向がコネクションストールモードに移行させられる。

Ｍ２Ｃフラグメント化状態のトラック：パケットがキルされると、ソフトウェアはＭ２Ｃ方向をコネクションストールモードに設定する。そして、ソフトウェアは、Ｍ２Ｃ方向がフラグメント化状態でなくなったことを検出するまで、コネクションストールされたＭ２Ｃパケットを処理し続ける。当該コネクションのＭ２Ｃ方向がフラグメント化された２つのパケットの間であるとき、Ｍ２ＣエラーパケットはＴＣＰストリームに注入されることができない。結果として、フラグメント化状態でなくなるまで、Ｍ２Ｃエラー送信機能はＭ２Ｃパケットを処理し続けるのが望ましい。Ｍ２Ｃエラーパケットは、全てキューに格納される。Ｍ２Ｃ方向がフラグメント化状態でなくなったことが確認されると、そのキュー内の全パケットが送信され得る。

パケットの送信後、ＣＯＮＮ＿Ｍ２Ｃ＿ＭＯＤ＿ＰＥＮＤＩＮＧブーリアンを設定する。

（Ｍ２Ｃエラー再生）
Ｍ２Ｃエラーパケットがクライアントに送信されている最中にクライアントがセッションから切断されると、クライアントが注入メッセージを見逃す可能性がある。遅延ＡＣＫチェックは、同じコネクション内でしかパケットを再送しない。クライアントが再接続した際に、失われたＭ２Ｃエラーメッセージを前記検査デバイスから再生する方法が必要となる。

これを行うために、毎回の（any）新たなコネクションの開始時に、これまでの過去（last）１０００個などといった複数のＭ２Ｃエラー注入がクライアントに対して再生され得る。これらの注入は、ログイン承認がクライアントへとＤＭＡされて且つＣＡＭが精緻化された直後に送信される。Ｍ２Ｃパケットは、全ての注入が再生されるまでストールされたままとなる。クライアントがＭ２Ｃエラー注入を見逃すのは切断時と考えられる（should）ので、Ｍ２Ｃエラー再生は再接続後のログイン時にのみ行われる。

この機能は、アカウントレベルの「再生オフ」許可を「真」に設定することでディセーブルされ得る。

なお、Ｍ２Ｃエラー再生は市場再生とは異なるものである。市場再生とは、市場からクライアントに送信されるメッセージの再生のことである。Ｍ２Ｃエラー再生とは、前記検査デバイスによりＭ２Ｃ ＴＣＰストリームに注入されたメッセージの再生のことである。

（送信者へのＭ２Ｃ送戻し）
（送信者への）Ｍ２Ｃ送戻しモードとは、Ｍ２Ｃエラーパケットが前記ＦＰＧＡによってリングバッファ（ring）に再配備される機能である。Ｍ２Ｃエラーパケットが送信された後、前記ＦＰＧＡが当該パケットを前記リングバッファにコピーする。これにより、データパスは、当該パケットをパースし、当該パケットがＭ２Ｃ ＴＣＰストリームへとどのシーケンスで挿入されたのかを決定し、メッセージ拒絶をログに報告することができる。

（Ｍ２Ｃ遅延ＡＣＫチェック）
Ｍ２Ｃ遅延ＡＣＫチェックは、Ｃ２Ｍ遅延ＡＣＫチェックと同じアーキテクチャで設計されている。これには、２つのモジュールが存在する：

一方のモジュールは、注入されたＭ２ＣエラーパケットのＡＣＫを受信したか否かを確認するために、Ｃ２ＭのＡＣＫをチェックする。このチェックは、ＣＯＮＮ＿Ｍ２Ｃ＿ＭＯＤ＿ＰＥＮＤＩＮＧブーリアンが設定されている場合に、ＣＯＮＮ＿ＡＣＴＩＶＥ状態のコネクション状態マシンで行われる。

他方の（second）モジュールは、それ自体が独立したプロセス又はスレッドである。この独立したプロセス又はスレッドは、ＣＯＮＮ＿Ｍ２Ｃ＿ＭＯＤ＿ＰＥＮＤＩＮＧが設定されている場合に、全てのコネクションオブジェクトについて１０ｍｓのタイムアウトを追跡する。１０ｍｓになると、Ｍ２Ｃエラーパケットが再送される。１００ｍｓになると、セッションが切断される。

（Ｃ２Ｍ ＤＳＭハードウェアの詳細およびＰＴＲＳソフトウェアとのインターフェース）
図９に、固定ロジック（ＦＰＧＡ）２１３ハードウェア、ならびに当該固定ロジック（ＦＰＧＡ）２１３ハードウェアの、データパス及びＰＴＲＳアプリケーション２２０ソフトウェアとの処理を示す。図９には、クライアントが誤りのあるパケットを送り出した状況に対処する際のさらなる詳細が描かれている。前述したように、このパケットはパケット検査エンジンにより処理されて、当該パケット検査エンジンによりエラーが検出されると共に、当該パケット検査エンジンによりこのパケットは拒絶されたパケットとしてマークされる。そして、このパケットは、ＰＴＲＳソフトウェア２２０へと送られて追加の処理を受けたり再送されたりする。

クライアント→市場（Ｃ２Ｍ）方向の場合の処理は、以下のようになる：

（１ａ）パケット検査エンジン（ＰＩＥ）４２０が、各パケットのＴＣＰ／ＩＰヘッダを処理し、（例えば各パケットのソースＩＰアドレス及びポートならびに宛先ＩＰアドレス及びポートを用いる等して）各パケットのセッションを特定し、各パケットのＴＣＰシーケンス番号を抽出する。特定された各セッションの最大ＴＣＰシーケンス値を追跡するのに用いられる、特定された各セッション用の最新シーケンス番号（ｌａｔｅｓｔ＿ｓｅｑ＿ｎｕｍ）レジスタが更新される。

（１ｂ）前記ＰＩＥがパケットを拒絶し、当該パケットがＦＰＧＡ２１３のカットスルーパスを完全に通過して（completing）市場１３０へと向かおうとするのを阻止する。このパケットは、適切なキルの理由がＤＭＡヘッダ内にマークされた状態で（例えばリングバッファを介して）ＰＴＲＳアプリケーション２２０ソフトウェアへと転送される。

（１ｃ）拒絶されたパケットに対応するセッションについて、各セッション用のパケットスキップ阻止モードが設定される。当該パケットスキップモードがクリアされるまで、この特定のセッションの後続のあらゆるパケットは、ＦＰＧＡ２１３を通過しないように阻止されると共に、後で送信できるように（for transmission）ソフトウェア２２０へと送られる。これは、例えば、パケットに関連付けられた情報を処理キュー、リングバッファ、またはＦＰＧＡ２１３とソフトウェア２２０との間で共有されたその他の適切なメモリもしくはストレージに送信することを含み得る。一部の実施形態では、パケットスキップ阻止モードが原因でソフトウェア２２０へとパケットが送られるたびにカウンタがインクリメントされ得る。パケットスキップ阻止モードが設定されていることが原因でソフトウェア２２０へと送られたパケットに関連付けられた情報をソフトウェア２２０が処理するたびに、当該ソフトウェア２２０は前記カウンタをデクリメントし得る。なお、パケットに関連付けられた情報を処理するとは、そのパケット（あるいは、元のパケットがルールに準拠しておらず変更が必要である場合には変更対象パケット）を送信することを含み得る。好適な実施態様では、パケットがソフトウェア２２０に送られることに対応した前記カウンタがクリアされたときに、パケットスキップ阻止モードがクリアされ得る。他の実施形態では、ソフトウェア２２０へと送られたパケットに関連付けられた全ての情報が処理されたか否かが、他の適切な方法で判断され得る。例えば、一部の実施形態では、カウンタではなく一対のポインタ又はインデックスが使用され得る。

（１ｄ）ソフトウェアが、前記拒絶されたパケットを処理し、拒絶されたコンテンツをトリミングする（切り取る）。次に、当該パケットのうちの拒絶されていない残りのコンテンツが前記ＦＰＧＡへとＤＭＡにより送り返される。ＤＭＡ処理は、まずパケットペイロードを共有メモリに書き込んでから、次にＦＰＧＡ２１３の特定のレジスタをプログラムすることで構成され得る。これにより、前記ＦＰＧＡは、前記共有メモリに読出しを実行し、市場に送信すべき前記ペイロードを取り出す。ＤＭＡコマンドレジスタは、変更された（トリミングされた）コンテンツのサイズに相当する「デルタ」という新たなフィールドを含み得る。

（１ｅ）ＦＰＧＡ２１３で、ＤＭＡされたパケットのＴＣＰシーケンス番号（ｓｅｑ）が抽出される。このＴＣＰシーケンス番号は、対応するセッションについてパケットスキップモードをクリアすべきか否かを判断するのに利用される。

（１ｆ）前記ＤＭＡコマンドレジスタに書き込まれたデルタ値を、Ｃ２ＭトラフィックのＴＣＰシーケンス番号を調節するのに用いられる各フロー用のＴＣＰアキュムレータ、およびＭ２ＣトラフィックのＴＣＰ ＡＣＫ番号を調節するのに用いられる各フロー用のＡＣＫアキュムレータ（ａｃｋ＿ａｃｃｕｍｕｌａｔｏｒ）に適用する準備が整う。ただし、どちらのアキュムレータの状態も、影響を及ぼすパケットがパスを通過し終える（passes through）までは元の状態のままであるのが望ましい。

（１ｇ）前記影響を及ぼすパケットのＴＣＰシーケンス設定（sequencing）が、（デルタでアキュムレータが調節される前の）アキュムレータに保持された数値に従って調節される。変更後パケットが、当該パケットのネットワーク宛先に送信される。

（１ｈ）ＤＭＡされたパケットについてペンディングＡＣＫ番号が算出されて、Ｍ２ＣパスのＡＣＫシーケンスマーカー（ａｃｋ＿ｓｅｑ＿ｍａｒｋｅｒ）へとコピーされる。Ｍ２Ｃパスでは、ＡＣＫシーケンスマーカーが、ＡＣＫアキュムレータへのＡＣＫデルタ（ａｃｋ＿ｄｅｌｔａ）の適用をトリガする役割を果たす。

（１ｉ）前記パケットが市場に送信された後、デルタがアキュムレータに適用される。

なお、上記はＦＰＧＡ２１３（固定ロジック）ハードウェアの例示的な実施態様の一つに過ぎず、変形例も可能であることを理解されたい。例えば、２つのアキュムレータ（Ｃ２ＭパスのアキュムレータとＭ２ＣパスのＡＣＫアキュムレータ）が図示されているが、これら２つのアキュムレータは単一のアキュムレータに置き換えられてもよい。一例として、アキュムレータへのデルタレジスタの数値の適用を、市場による変更後パケットの確認応答を受信するまで遅らせることにより、一方の（second）アキュムレータ及びデルタレジスタを省略することが可能である。よって、Ｃ２Ｍ方向に移動する後続のパケットのシーケンス番号の調節時には、アキュムレータの数値だけでなくデルタレジスタの数値も含めることになる。

市場→クライアント（Ｍ２Ｃ）方向に流れるメッセージの場合の処理は、以下のようになる：

（２ａ）届けられた各パケットの受信ＡＣＫシーケンス（ｒｅｃｖ＿ａｃｋ＿ｓｅｑ）番号が抽出されて、各パケットのセッションが特定される。この特定のパケットのフローにペンディングＡＣＫシーケンスマーカー（ａｃｋ＿ｓｅｑ＿ｍａｒｋｅｒ）が存在し、かつ、受信ＡＣＫシーケンスが当該ＡＣＫシーケンスマーカー以上である場合には、各フロー用のペンディングＡＣＫデルタがＡＣＫアキュムレータに適用される。

（２ｂ）ＡＣＫアキュムレータを用いて、通過するＭ２ＣパケットのＡＣＫ番号が調節される。

（ハードウェアでのＭ２Ｃ ＤＳＭ）
図１０には、Ｍ２Ｃ拒絶メッセージの処理の様子が描かれている。ＰＴＲＳアプリケーション２２０ソフトウェアがメッセージを拒絶したばかりであるとして、好ましくは、次に当該ＰＴＲＳアプリケーション２２０ソフトウェアが、対応する通知メッセージをクライアントに戻す向きで注入し、このイベントを（場合によっては、拒絶の理由も）当該クライアントに知らせる。これを整然に行うには、ソフトウェア２２０が影響中のセッションをＭ２Ｃコネクションストールモードに設定して、そのセッションのどのトラフィックもＦＰＧＡ２１３を通過しないように阻止する。ソフトウェア２２０は、インターセプトしたトラフィックをＤＭＡで市場１３０へと送信すると共に、拒絶メッセージを自然な（clean）境界で注入する。

（１ａ）まず、ＰＴＲＳアプリケーション２２０ソフトウェアが、拒絶メッセージを注入したいセッション（フロー）についてＭ２Ｃコネクションストールモードを設定する。

（１ｂ）ＦＰＧＡ２１３で、市場１３０から受信したパケットが処理されて、（例えば当該パケットのソースＩＰアドレス及びポートならびに宛先ＩＰアドレス及びポートを用いる等して）当該パケットのセッションが特定される。コネクションストールモードに設定されたセッションにそのパケットが属していると特定されると、ＦＰＧＡ２１３は、当該パケットがカットスルーパスを介してクライアントに到達しないように当該パケットを拒絶し、当該パケットを後からソフトウェアによって送信できるように（for software transmission）リングバッファに送る。

（１ｃ）ＰＴＲＳアプリケーション２２０ソフトウェアが、前記リングバッファに入って来たＭ２Ｃトラフィックを処理する。当該ソフトウェアは、コネクションストールの原因である（for）キルされたパケットを処理すると、懸案中の（pending）拒絶メッセージをパケットに注入して当該パケットをＦＰＧＡ２１３を介して外部に（out）ＤＭＡする。ＰＴＲＳソフトウェア２２０は、影響中のセッションのコネクションストールモードをクリアする（ｂｈ＿ｃｌｅａｒビット）。

（１ｄ）外部にＤＭＡされるパケットの送信時に、コネクションストールモードがクリアされる。

（１ｅ）ＤＭＡ＿ＣＭＤに書き込まれたデルタ値を、Ｍ２ＣトラフィックのＴＣＰシーケンス番号を調節するのに用いられる各フロー用のＴＣＰアキュムレータ、およびＣ２ＭトラフィックのＴＣＰ ＡＣＫ番号を調節するのに用いられる各フロー用のＡＣＫアキュムレータ（ａｃｋ＿ａｃｃｕｍｕｌａｔｏｒ）に適用する準備が整う。ただし、どちらのアキュムレータの状態も、影響を及ぼすパケットがパスを通過し終える（passes through）までは元の状態のままであるのが望ましい。

（１ｆ）注入されたメッセージを含む変更後パケットが、前記リングバッファ（又は他のバッファ）に送られる。これは、拒絶メッセージをＭ２Ｃリングバッファに残しておいて後から再生できるように（for replays）するためである。

（１ｇ）前記変更後パケットのＴＣＰシーケンス設定（sequencing）が、（デルタを用いてアキュムレータに調節を行う前の）アキュムレータに保持された数値に従って調節される。この変更後イーサネットパケットが、当該パケットのネットワーク宛先に送信される。

（１ｈ）ＤＭＡされたパケットについてペンディングＡＣＫ番号が算出されて、Ｃ２ＭパスのＡＣＫシーケンスマーカー（ａｃｋ＿ｓｅｑ＿ｍａｒｋｅｒ）へとコピーされる。Ｃ２Ｍパスでは、ＡＣＫシーケンスマーカーが、ＡＣＫアキュムレータへのＡＣＫデルタ（ａｃｋ＿ｄｅｌｔａ）の適用をトリガする役割を果たす。

（１ｉ）前記パケットが市場１３０に送信された後、デルタがアキュムレータに適用される。

２．クライアント１２０が市場１３０に対してトラフィックを送信する。

（２ａ）届けられた各パケットの受信ＡＣＫシーケンス（ｒｅｃｖ＿ａｃｋ＿ｓｅｑ）番号が抽出されて、各パケットのセッションが特定される。この特定のパケットのセッションにペンディングＡＣＫシーケンスマーカー（ａｃｋ＿ｓｅｑ＿ｍａｒｋｅｒ）が存在し、かつ、受信ＡＣＫシーケンス（ｒｅｃｖ＿ａｃｋ＿ｓｅｑ）が当該ＡＣＫシーケンスマーカー以上である場合には、各フロー用のペンディングＡＣＫデルタがＡＣＫアキュムレータに適用される。

（２ｂ）ＡＣＫアキュムレータを用いて、通過するＣ２ＭパケットのＡＣＫ番号が調節される。

（変更前−過去パケットモード）
変更前−過去パケットとは、クライアント側又は市場側により再送されたパケットであって、ＴＣＰシーケンスを前記ＦＰＧＡによる通常の方法で更新することができないパケットのことである。これは、その再送がかなり前のＴＣＰシーケンスのものである場合に起こり得て、最新のアキュムレータやデルタではシーケンスの適切な変更を正確に反映することができない。結果として、ＴＣＰ機能障害を防ぐための措置が講じられる必要がある。

図１１は、変更前−過去パケット状態の問題を表した一例を示す図である。

この問題の背景（setup）として、時刻ｔ０にて、第１の合格パケットが市場に送信される。しかし、時刻ｔ１では、第１の合格パケットのＡＣＫが検査デバイス１１０とクライアント１２０との間で廃棄されてしまい、クライアント１２０が予想時間枠内に第１の合格パケットのＡＣＫを受信できない様子が見て取れる。時刻ｔ２では、次のＣ２Ｍパケットである第１のキルパケットが検査デバイス１１０によりキルされて、かつ、バイト数の変化を考慮してデルタ値が「０」以外の数値（この例では「−１０」）に設定される。時刻ｔ３では、第１のキルパケットのＡＣＫが検査デバイス１１０により確認されるものの、第１の合格パケットのＡＣＫと同じく、第１のキルパケットのＡＣＫも検査デバイス１１０とクライアントとの間で廃棄されてしまう。第１のキルパケットのＡＣＫが検査デバイス１１０によって既に確認済みであることから、デルタ値の「−１０」がアキュムレータに加算されてしまう。

ステップｔ４にて、前記予想時間枠内に第１の合格パケットのＡＣＫを受信しなかったクライアントが当該第１の合格パケットを市場に対して再送したときに、問題が露わになる。というのも、アキュムレータがこのシーケンスにとって間違った数値に設定されているからである。このため、再送された第１の合格パケットのシーケンス番号がその間違ったアキュムレータ値で変更されてしまい、市場側でＴＣＰ機能障害が発生する可能性がある。つまり、パケットがキルされると、後続のパケットのシーケンス番号はアキュムレータによって調節されるのであるが、この例からも分かるように、キルすべきパケットが届いてから、当該キルすべきパケットよりも小さいシーケンス番号を持つ古いパケットが、検査デバイス１１０に後から届くという可能性がある。

変更前−過去パケットは、クライアント側でも市場側でも起こり得る。この状態の検出は、コネクション状態マシンで行われる。この状態が原因で生じ得るＴＣＰ機能障害を回避するために、１）このパケットのＴＣＰシーケンス番号が最新シーケンスマーカー（ＣＯＮＮ＿ＳＥＱ＿ＭＡＲＫＥＲ）よりも小さく、かつ、２）ＭＯＤ＿ＰＥＮＤＩＮＧブーリアンが設定されていない場合に、変更前−過去パケット状態が検出され得る。

変更前−過去パケットが検出された場合に取るべき考えられ得る（possible）対策の一つは、セッションを切断することである。変更前−過去パケット（つまり、最新シーケンスマーカーよりも小さいシーケンス番号を持つ後から届いたパケット）を適切に処理する別の方法として、ＦＰＧＡ２１３が、デルタ値、アキュムレータ値及びシーケンス番号マーカー値の履歴テーブルを保持することが考えられる（may）。これにより、後から届いたパケットの正確なシーケンス番号が、当該後から届いたパケットの適切なシーケンスマーカー値に対応する、アキュムレータ及び／又はデルタの該当値（relevant values）を、前記履歴テーブルから適用することによって決定されることが可能になる。

Ｍ２Ｃエラー注入フラグメント：一実施形態において、ＰＴＲＳソフトウェア２２０は、Ｍ２Ｃ方向がフラグメント化状態でなくなったことが確認できるまでＭ２Ｃエラー注入を保存する。ただし、フラグメント化されたＭ２Ｃパケットを均等なメッセージ境界で分割することでＭ２Ｃ方向をストールする必要性をなくすことが可能な、他の実施形態も考えられ得る（possible）。エラー注入時にＭ２Ｃフラグメントを除去することにより、エラーパケットの迅速な送信を実行することができる。

（ＴＣＰシーケンスマーカーと相互作用するＴＣＰシーケンス番号）
一部の実施形態では、新しいメッセージが届いた際に、固定ロジック２１３がこの新しいメッセージのＴＣＰシーケンス番号をシーケンスマーカーレジスタの数値と比較し得る。この最新メッセージのＴＣＰシーケンス番号がシーケンスマーカーの数値よりも小さい場合、当該メッセージは変更されずに送信される。この最新のメッセージのＴＣＰシーケンス番号がシーケンスマーカーの数値以上である場合には、当該メッセージのＴＣＰシーケンス番号にアキュムレータレジスタの数値が加算される。

（パケットスキップ阻止および高速パス−対−低速パスの使用）
パケットがキルされると、ＣＡＭ（より広義的には検査デバイス１１０）がパケットスキップ阻止モードに設定される。パケットスキップ阻止モードは、全てのクライアント→市場（Ｃ２Ｍ）パケットを、初めに固定ハードウェア２１３で処理することなくソフトウェアへと送る。

これにより、一部の稀な（race）状態が回避される。図１２に、このような稀な状態の一つを示す。

図１２に示すケースでは、時刻ｔ０にて、第１のキルパケット（ｋ１）が送信される。しかし、後の時刻ｔ１では、第１のキルパケット（ｋ１）を処理するための時間をソフトウェア（ＰＴＲＳアプリケーション２２０）が確保する前に、第１の合格パケット（ｇ１）がハードウェア（ＦＰＧＡ）を通過する（この場合、第１の合格パケット（ｇ１）も、ＰＴＲＳアプリケーションソフトウェア２２０による処理を必要とする）。これは、第１のキルパケット（ｋ１）を上書きするための時間が確保される前に、第１の合格パケット（ｇ１）が市場に到達し得ることを意味する。さらに、第１の合格パケットのシーケンス番号は、第１のキルパケットを完全に処理するために必要な変更を正確に反映していないため、不正確となり得る。

このような稀な状態を回避するために、パケットスキップ阻止モードでは、全てのパケットがソフトウェアに送られるのだが、ソフトウェアに送られた最後のパケットが送信され終わるまでこれが続けられる。つまり、時刻ｔ２にて、パケットスキップ機能がイネーブルされていれば、前記ＦＰＧＡが単独で且つ自動的にパケットのスキップを実行する。これは、ソフトウェアでオン・オフされる必要がない。

図１３に、これの一例を示す。時刻ｔ０にて、第１のパケットｋ１がキルされると、時刻ｔ１や時刻ｔ２で受信するパケットのように、後続の全てのパケットが前記ＦＰＧＡではなくＰＴＲＳソフトウェアへと送られる。これは、ソフトウェアに送られた最後の合格パケットｇ２が時刻ｔ３にて送信されるまで続く。その後、パケットスキップモードがオフにされて、時刻ｔ４では、合格パケットｇ３が先程まで（as previously）とは違ってソフトウェアに入らずともハードウェアを通過して送信されることが可能となる。

（近接変更（ＣＰＭ））
近接変更（ＣＰＭ）とは、キルされたパケットのＡＣＫを市場から未だ受信していないにもかかわらず、別のキルされたパケットが送信を待っているときに起こる稀な状態のことである。この場合、デルタは最初にキルされたパケットから除去された総バイト数を未だ記憶していて、このパケットのＡＣＫが届くまでは当該バイト数をアキュムレータに加算したりクリアしたりすることができない。ＣＰＭが発生すると、その次の（second）キルされたパケットは、送信可能となるまでストールされる必要がある。最初にキルされたパケットのＡＣＫを受信すれば、前記その次のキルされたパケットが送信可能となる。一部の実施形態では、キルされた後続のパケットをストールするのに代えて、キューに格納することが可能であり得る。

図１４に、近接変更（ＣＰＭ）のシナリオを示す。

ＣＯＮＮ＿Ｃ２Ｍ＿ＭＯＤ＿ＰＥＮＤＩＮＧブーリアンが（時刻ｔ０にて）既に設定されているうえで、キルされたＣ２Ｍパケットを送信する場合、Ｃ２Ｍ送信モジュールが以下のことを行う：

１）上記状態が検出されると、時刻ｔ２のようにコア全体をストールする。ここでは、受信した後続の第２のキルパケットが前記検査デバイスでストールされる（なお、時刻ｔ２にて第２のキルパケットを第１のキルパケットと近接して（すなわち、第１のキルパケットのＡＣＫを受信する前に）受信したときに、近接状態が検出される。時刻ｔ１の第１の合格パケットはハードウェアにより処理されて市場に送信されるのに対し、後続のパケットは第１のキルパケットのＡＣＫを受信するまでストールされる必要がある）。

２）ＣＰＭが発生したセッションのデルタレジスタを継続的にポーリングする：
時刻ｔ３にてデルタレジスタが「０」になると、第１のキルパケットのＡＣＫを受信したということである。この時点で前記ストールが解除され得て、時刻ｔ４にて第２のキルパケットが送信され得る。デルタレジスタが未だ「０」でなければ、最後に変更したパケット（例えば、この例では第１のキルパケット）を決まった間隔で（例えば、１０ｍｓ毎に）再送する。最後に変更したパケットのＡＣＫをタイムアウト時間（例えば、１００ｍｓ）を過ぎても未だ受信できなければ、セッションを切断する。

現在、検査デバイス１１０で取引がアクティブになっている最中にＣＰＭが発生することは極めて稀なケースであると考えられる。この理由から、ＣＰＭの検出時にコア全体をストールすることが可能である。

重要なのは、ＣＰＭの数がハードウェアのシーケンスマーカーレジスタの数を上回った場合に、前述したＣＰＭの処理方法がソフトウェアを利用するという点である。一部の実施形態では、ハードウェアパスにて複数のＣＰＭに対処できるように、シーケンスマーカーレジスタ、デルタレジスタ及びアキュムレータレジスタが複数存在し得る。例えば、シーケンスマーカーレジスタ、デルタレジスタ及びアキュムレータレジスタのセットを３セット有する一実施形態では、確認応答が済んでいない変更後パケットに一度に３つ対処することができる。例示的なこのような実施形態では、第１の変更後パケットの確認応答を未だ受信していないにもかかわらず第２のパケットを変更する必要がある場合に、この第２の変更対象パケットに対応するデルタ値及び／又はシーケンスマーカー及び／又はアキュムレータ値が、第２のセットのレジスタに記憶され得る。同様に、先行する（first）２つの変更後パケットが確認応答される前に第３のパケットの変更が必要となった場合、第３のセットのレジスタにデルタ値及び／又はシーケンスマーカー及び／又はアキュムレータ値が記憶され得る。そして、先行する（prior）３つの変更後パケットが確認応答される前に第４のパケットの変更が必要となった場合、当該第４のパケットはソフトウェアで処理され得るか、あるいは前述のようにストールされ得る。つまり、このような実施形態では、変更が必要なパケットが届いたとしても、変更が必要なこの新たに届いたパケットと対応させるのに利用可能なシーケンスマーカーレジスタ及び／又はデルタレジスタ及び／又はアキュムレータレジスタのセットが残っている限り、ストールを回避することができる。所与のセットのシーケンスマーカーレジスタ及び／又はデルタレジスタ及び／又はアキュムレータレジスタと対応させた変更パケットの確認応答を受信すると、確認応答を受けた当該変更後パケットに対応付けられたこれらのレジスタの数値がクリアされ得て、変更が必要な別の流入パケットにより再利用できるように（for reuse）使用可能な状態となり得る。

（ハードウェアメカニズムの、各双方向セッション毎のインスタンス）
本文献で説明するハードウェアメカニズムには、各セッション毎に個別のインスタンスペアが存在する。当該ペア内の一方のインスタンスはＴＣＰセッションのＣ２Ｍ方向を処理し、他方のインスタンスは同じＴＣＰセッション（the TCP session）のＭ２Ｃ方向を処理する。典型的なＦＰＧＡは、実際１２８個のセッション（このメカニズムの２５６個のインスタンス）をサポートするが、現実的な数はその時々（arbitrary）であり、ＦＰＧＡチップ上のメモリのみに限られる。

（ＴＣＰパケットの変更の選択肢）
本文献で説明する技術により、Ｃ２Ｍ方向やＭ２Ｃ方向で、確立されたＴＣＰストリームからメッセージを完全に除去したり、既存のメッセージである「インフライト（in-flight）」メッセージを別のサイズのメッセージに置き換えたり、追加のメッセージを注入したりする、カットスルー方式の超低レイテンシな装置を提供することが可能となる。

（市場拒絶メッセージの合成）
本文献で説明する技術により、既存のＴＣＰストリームでのメッセージの除去、追加及び変更が可能となる（accommodate）。これらの低次メカニズムは、リスクチェックに合格しなかった取引イベントメッセージを除去するのに用いられ、データが宛先の取引所に到達するのを防ぐ。そして、取引メッセージが拒絶されたクライアントには、自身のメッセージが取引所により受信されなかったことを把握できるように拒絶通知が必要となる。本技術は、既に取引所プロトコルに合わせてコーディングされたクライアント取引サーバがその拒絶をシームレスに解釈できるように、各プロトコル固有の拒絶メッセージを合成する。取引クライアントにとっては、取引所がメッセージを取引前リスクコントロールの違反で拒絶したかの如く見える。さらに、システムは、元々の取引メッセージが拒絶された確かな理由をクライアントが理解（interpret）できるように、特定の拒絶理由に関する追加情報を付け足す。

（ＦＰＧＡリングバッファ）
一部の実施態様では、ＦＰＧＡ（固定ハードウェア）２１３とＰＴＲＳソフトウェア２２０との間の主要な通信メカニズムの一つが、リングバッファであり得る。このリングバッファは、ヘッドポインタとテールポインタとの２つのポインタにより維持される。ＦＰＧＡ２１３は、全データを当該バッファへと、前記テールポインタの位置を開始位置として書き込む。ＦＰＧＡ２１３がデータの書込みを完了すると、当該ＦＰＧＡ２１３は最後に書き込んだバイトのメモリ位置へと前記テールポインタを進める。ソフトウェアが当該バッファから読出しを行った際には、最後に読み出されたバイトの位置へと前記ヘッドポインタが進められる。これにより、メモリをＦＰＧＡ２１３によって安全に上書きすることが可能となる。有効データの開始メモリ位置を追跡する前記ヘッドポインタ、および当該有効データの終了メモリ位置を追跡する前記テールポインタは、当該リングバッファのベースアドレスから当該ベースアドレスにバッファサイズを足したアドレスにかけて「一周」することで、「環状リング」を形成する。ＦＰＧＡ２１３が当該リングバッファをオーバーフローさせて、「一周」事象の発生を経た、前記テールポインタが前記ヘッドポインタを越えて上書きするようなことが起こらないための配慮が講じられる。

（他の用途例）
これまでに述べたアーキテクチャは、他の用途に利用されてもよい。例えば、当該アーキテクチャは、ネットワーク上を流れるデータストリームを監視したり、パケットをキャプチャ（採取）したり、パケットの生データを復号化したり、証券売買注文を検査する以外の理由によりリアルタイムでパケットコンテンツを解析したりするのに利用され得ることも可能である。

（実装（実現）のさらなる選択肢）
なお、これまでに述べた例示的な実施形態は、数多くの様々な方法で実現され得ることを理解されたい。一部の例では、各種「データプロセッサ」が、それぞれ、中央演算処理装置、メモリ、ディスク又は他の大容量記憶装置、少なくとも１つの通信インターフェース、少なくとも１つの入出力（Ｉ／Ｏ）装置、および他の周辺装置を備えた物理的又は仮想的な汎用コンピュータにより実現され得る。当該汎用コンピュータは、プロセッサへと変換して考えることで、これまでに述べたプロセスを実行する。これは、例えば、ソフトウェア命令を当該プロセッサにロードした後、当該命令を実行して前述の機能を実現すること等により行われる。

当該技術分野で知られているように、そのようなコンピュータは、コンピュータ又は処理システムの構成要素（components）間でのデータ伝送に利用される一連のハードウェアラインであるシステムバスを備え得る。当該バスは、本質的に、コンピュータシステムの相異なる構成要素（例えば、プロセッサ、ディスクストレージ、メモリ、入出力ポート、ネットワークポート等）同士を接続して当該構成要素間での情報の伝送を可能にする共有の導管である。当該システムバスには、コンピュータ命令を実行する少なくとも１つの中央演算処理装置が取り付けられている。当該システムバスには、さらに、様々な入出力装置を接続するための入出力装置インターフェースが典型的に取り付けられている。少なくとも１つのネットワークインターフェースが、ネットワークに取り付けられた様々な他の装置へと接続することを可能にする。メモリは、一実施形態を実現するように用いられるコンピュータソフトウェア命令及びデータを記憶する揮発性の記憶部である。ディスク又は他の大容量記憶装置は、例えば本明細書に記載された様々なプロシージャ（手続き）を実現するように用いられるコンピュータソフトウェア命令及びデータを記憶する不揮発性の記憶部である。

つまり、実施形態は、典型的に、ハードウェア、カスタム設計された半導体ロジック、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ファームウェア、ソフトウェア、またはこれらの組合せで実現され得る。

一部の実施形態において、本明細書に記載されたプロシージャ、装置およびプロセスは、コンピュータプログラムプロダクトである。当該コンピュータプログラムプロダクトは、システム用のソフトウェア命令の少なくとも一部を提供するコンピュータ読取り可能媒体（例えば、少なくとも１つのＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ、ディスケット、テープなどの取外し可能な記憶媒体等）を含む。このようなコンピュータプログラムプロダクトは、当該技術分野において周知である任意の適切なソフトウェアインストール方法によってインストールされることが可能なものであり得る。また、他の実施形態では、前記ソフトウェア命令の少なくとも一部が、ケーブルおよび／または通信および／または無線接続を介してダウンロードされるものであり得る。

また、実施形態は、非過渡的な機械読取り可能媒体に記憶された、少なくとも１つのプロシージャにより読出し・実行され得る命令としても実現され得る。非過渡的な機械読取り可能媒体には、情報を機械（例えば、コンピューティングデバイス等）が読取り可能な形態で記憶したり送信したりするあらゆるメカニズムが含まれ得る。例えば、非過渡的な機械読取り可能媒体は、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体を含むストレージ、光記憶媒体、フラッシュメモリ装置などを含み得る。

また、本明細書では、ファームウェア、ソフトウェア、ルーチンまたは命令が、特定の処理および／または機能を実行するかの如く述べられているかもしれない。しかしながら、本明細書に含まれるこのような説明は便宜上のものに過ぎず、実際のところこのような処理が、コンピューティングデバイス、プロセッサ、コントローラ叉はその他の装置がファームウェア、ソフトウェア、ルーチン、命令などを実行することで生じているという点を理解されたい。

また、ブロック図やネットワーク図は、構成要素が追加されても省略されてもよいし、配置が変えられてもよいし、表現（実現）の仕方が別のものに変えられてもよい。ただし、実現の形態によってはブロック図やネットワーク図が決まっている場合があり、実施形態の実行を表すブロック図やネットワーク図の数が特定の様式で実現されることになるという点も理解されたい。

よって、実施形態は、その他にも、多種多様なコンピュータアーキテクチャ及び／又は物理的なコンピュータ及び／又は仮想的なコンピュータ及び／又はクラウドコンピュータ及び／又はこれらの数種類の組合せで実現されてもよい。つまり、本明細書で説明したコンピュータシステムは、例示目的のものに過ぎず、実施形態を限定するものではない。

このように、本発明を例示的な実施形態を参照しながら具体的に図示・説明してきたが、当業者であれば、添付の特許請求の範囲に包含される本発明の範囲を逸脱しない範疇で、形態や細部に様々な変更が施されてもよいことを理解するであろう。

Claims (22)

1. 第１のエンドポイントと第２のエンドポイントとの間に確立された双方向ネットワークセッション中に、
   パケットのストリームを検査する過程と、
   前記第１のエンドポイントから送信された所与のパケット内のメッセージが変更されるべきであると判断すると、
   前記所与のパケット内の前記メッセージを変更して変更後パケットを生成する過程と、
   前記メッセージの変更を考慮して変更後のシーケンス番号を決定する過程と、
   前記変更後パケットを前記第２のエンドポイントに送信する過程と、
   返信メッセージを前記第１のエンドポイントに送信し、元のメッセージが変更されたことを知らせる過程と、
   を備える、方法。
2. 請求項１に記載の方法において、変更後のシーケンス番号を決定する前記過程が、
   変更された前記パケットのシーケンス番号に基づいてシーケンスマーカー値を決定すること、
   アキュムレータ値を維持すること、
   元の前記所与のパケットと前記変更後パケットとのバイト数の差分を表すデルタ値を記憶すること、
   前記第２のエンドポイントからの前記変更後パケットの確認応答を検出すること、および
   前記デルタ値を前記アキュムレータ値に加算すること、
   を含む、方法。
3. 請求項２に記載の方法において、さらに、
   受信した後続のパケットのシーケンス番号が前記シーケンスマーカー値以上である場合、
   前記第１のエンドポイントから受信した後続のパケットのシーケンス番号を前記アキュムレータ値だけ変更する過程、
   を備える、方法。
4. 請求項３に記載の方法において、さらに、
   前記第２のエンドポイントから受信した別のパケットの確認応答シーケンス番号を前記アキュムレータ値に基づいて調節する過程、
   を備える、方法。
5. 請求項１に記載の方法において、前記所与のパケット内の前記メッセージを変更する過程が、当該パケット内の当該メッセージを、異なる長さの第２のメッセージに置き換えることを含む、方法。
6. 請求項５に記載の方法において、前記第２のメッセージが、ハートビートメッセージ、テストメッセージ、またはシーケンスフィルタメッセージを含む、方法。
7. 請求項１に記載の方法において、前記所与のパケット内の前記メッセージを変更する過程が、当該パケットから当該メッセージを除去することを含む、方法。
8. 請求項１に記載の方法において、前記第１のエンドポイントが取引業者に対応付けられたクライアント装置であり、前記第２のエンドポイントが証券取引システムに対応付けられた市場装置であり、前記メッセージが証券を売買する注文である、方法。
9. 請求項８に記載の方法において、前記返信メッセージが、前記メッセージを変更した理由を含む、方法。
10. 請求項８に記載の方法において、前記メッセージを変更した前記理由が、取引ルールへの準拠、セキュリティリスク又は証券リスク、及びパケットコンテンツフィルタリングのうちの少なくとも一つに関する、方法。
11. 請求項２に記載の方法において、さらに、
    前記第２のエンドポイントから前記変更後パケットのＡＣＫを受信したか否かを判断する過程と、
    前記変更後パケットのＡＣＫを受信していないと判断した場合、
    前記変更後パケットを再送する過程と、
    タイムアウト時間後に前記セッションを切断する過程と、
    を備える、方法。
12. 請求項１１に記載の方法において、前記変更後パケットのＡＣＫを受信したか否かを判断する過程が、一定間隔で実行される、方法。
13. 請求項１１に記載の方法において、さらに、
    前記第２のエンドポイントから受信した前記ＡＣＫのシーケンス番号が前記シーケンスマーカー以上である場合、
    変更ペンディング値をクリアする過程、
    を備える、方法。
14. 請求項１１に記載の方法において、変更された前記メッセージのＡＣＫを受信したか否かを判断する過程が、前記デルタ値を定期的にポーリングすることを含む、方法。
15. 請求項１に記載の方法において、さらに、
    前記変更後パケットのＡＣＫを未だ受信しておらず、かつ、後続のパケットについても変更して第２の変更後パケットを生成する必要がある場合、
    前記変更後パケットの前記ＡＣＫを受信するまで前記第２の変更後パケットをストールする過程、
    を備える、方法。
16. 請求項１５に記載の方法において、さらに、
    前記デルタ値をポーリングして、前記変更後パケットの前記ＡＣＫをいつ受信したかを判断する過程と、
    所定の時間間隔で前記変更後パケットを再送する過程と、
    前記変更後パケットの前記ＡＣＫを受信することなく所定の時間が経過すると、前記セッションを切断する過程と、
    を備える、方法。
17. 第１のＴＣＰエンドポイントと第２のＴＣＰエンドポイントとの間に確立された双方向ＴＣＰセッション中に、
    前記第１のＴＣＰエンドポイントから受信したＴＣＰパケットを検査する過程と、
    所与のＴＣＰパケットからＴＣＰシーケンス番号を抽出する過程と、
    前記所与のＴＣＰパケットに対応するＴＣＰセッションを特定する過程と、
    前記所与のＴＣＰパケット内のコンテンツがルールに準拠しているか否かを判断する過程と、
    前記所与のＴＣＰパケットが前記ルールに準拠している場合、
    前記所与のＴＣＰパケットを前記第２のＴＣＰエンドポイントに到達させる過程と、
    前記所与のＴＣＰパケットが前記ルールに準拠していない場合、
    拒絶理由データ値を決定する過程と、
    前記所与のＴＣＰパケットの少なくとも一部が前記第２のＴＣＰポイントに到達するのを阻止する過程と、
    前記所与のＴＣＰパケットの少なくとも一部を除去して変更後ＴＣＰパケットを形成する過程と、
    デルタ値を、そのようにして除去された前記一部のサイズに依存する数値に設定する過程と、
    前記デルタ値を、前記ＴＣＰセッションに対応付けられた各セッション用のＴＣＰアキュムレータに適用する過程と、
    前記変更後ＴＣＰパケットのＴＣＰシーケンス番号を、前記各セッション用のＴＣＰアキュムレータのサイズに依存する数値だけ調節する過程と、
    前記変更後ＴＣＰパケットを前記第２のＴＣＰエンドポイントに送信する過程と、
    前記拒絶の理由を表す数値を有する返信パケットを生成する過程と、
    前記返信パケットを前記第１のＴＣＰエンドポイントに送信する過程と、
    を備える、方法。
18. 互いに独立して動作する第１のネットワークインターフェース及び第２のネットワークインターフェースを有するカットスルー方式の固定ロジックデバイスであって、１つ又は複数のＴＣＰパケットストリームが前記第１および第２のネットワークインターフェース間を移動することのできる、カットスルー方式の固定ロジックデバイスと、
    前記ＴＣＰパケットストリームを検査するパケット検査デバイスであって、
    所与のＴＣＰパケットからＴＣＰシーケンス番号を抽出し、
    前記所与のＴＣＰパケットに対応するセッションを特定し、
    前記所与のＴＣＰパケットが、ルールに準拠していないコンテンツを含んでいるか否かを判断し、
    前記所与のＴＣＰパケットが準拠していない場合、
    前記所与のＴＣＰパケットの少なくとも一部が前記第２のネットワークインターフェースに到達するのを阻止する、
    パケット検査デバイスと、
    固定ロジック及び少なくとも１つのプログラマブルなデータプロセッサを含むコントローラであって、
    前記パケット検査デバイスから前記所与のＴＣＰパケット及び拒絶理由データ値を受け取り、
    前記所与のＴＣＰパケットの前記シーケンス番号に基づく数値を、各セッション用のＴＣＰシーケンスマーカーとして記憶し、
    前記ＴＣＰパケットから、拒絶された前記コンテンツをトリミングして、変更後ＴＣＰパケットを形成し、
    前記変更後パケットを前記第２のネットワークインターフェースを介して送信できるように、当該変更後パケットを、前記カットスルー方式の固定デバイスと共有するメモリに書き込み、
    各セッション用のデルタ値を、トリミングされた前記コンテンツのサイズに依存する数値に設定し、
    前記変更後ＴＣＰパケットの前記ＴＣＰシーケンス番号を、各セッション用のＴＣＰアキュムレータの数値に従って調節し、
    前記第２のネットワークインターフェースを介して届いた後続のＴＣＰパケットの、シーケンス番号及びセッション識別子を抽出し、
    前記第２のネットワークインターフェースを介して届いた後続のＴＣＰパケットのＡＣＫシーケンス番号が、前記対応するセッションのＴＣＰシーケンスマーカー以上である場合、各セッション用の対応付けられた前記デルタ値を、当該セッションに対応付けられた前記ＴＣＰアキュムレータに適用し、
    前記第２のネットワークインターフェースを介して届いた前記後続のパケットの前記ＡＣＫシーケンス番号を、前記セッションに対応付けられた前記ＴＣＰアキュムレータの数値だけ調節し、
    前記拒絶の理由を表す数値を含む、前記第１のネットワークインターフェースを介して送信する返信パケットを生成する、
    コントローラと、
    を備える、装置。
19. 請求項１８に記載の装置において、前記コントローラが、さらに、
    ルールに準拠していない前記所与のパケットに対応する前記セッションについて、コネクションストールモードを設定し、
    前記第２のネットワークインターフェースから受信した後続のパケットが、前記コネクションストールモードを設定した前記セッションに属するものである場合、
    生成された前記返信パケットを前記第１のインターフェースに転送し、
    前記生成された返信パケットを前記第１のインターフェースに転送した後、前記後続のパケットを前記第１のインターフェースに転送し、
    前記セッションの前記コネクションストールモードをクリアする、装置。
20. 請求項１８に記載の装置において、前記コントローラの前記固定ロジックが、
    前記パケット検査デバイスから前記所与のＴＣＰパケット及び拒絶理由データ値を受け取る手順、
    前記所与のＴＣＰパケットの前記シーケンス番号に基づく数値を、各セッション用のＴＣＰシーケンスマーカーとして記憶する手順、
    前記変更後ＴＣＰパケットの前記ＴＣＰシーケンス番号を、各セッション用のＴＣＰアキュムレータの数値に従って調節する手順、
    前記第２のネットワークインターフェースを介して届いた後続のＴＣＰパケットの、シーケンス番号及びセッション識別子を抽出する手順、
    前記第２のネットワークインターフェースを介して届いた後続のＴＣＰパケットのＡＣＫシーケンス番号が、前記対応するセッションのＴＣＰシーケンスマーカー以上である場合、各セッション用の対応付けられた前記デルタ値を、当該セッションに対応付けられた前記ＴＣＰアキュムレータに適用する手順、ならびに
    前記第２のネットワークインターフェースを介して届いた前記後続のパケットの前記ＡＣＫシーケンス番号を、前記セッションに対応付けられた前記ＴＣＰアキュムレータの数値だけ調節する手順、
    のうちの少なくとも一つを実行する、装置。
21. 請求項２０に記載の装置において、前記プログラマブルなデータプロセッサが、プログラムコードを実行して、
    前記ＴＣＰパケットから、拒絶された前記コンテンツをトリミングして、変更後ＴＣＰパケットを形成する手順、
    前記変更後パケットを、前記カットスルー方式の固定デバイスと共有するメモリに書き込む手順、
    各セッション用のデルタ値を、トリミングされた前記コンテンツのサイズに依存する数値に設定する手順、
    前記第２のネットワークインターフェースを介して届いた後続のＴＣＰパケットの、シーケンス番号及びセッション識別子を抽出する手順、ならびに
    前記拒絶の理由を表す数値を含む、前記第１のネットワークインターフェースを介して送信する返信パケットを生成する手順、
    のうちの少なくとも一つを実行する、装置。
22. 請求項１８に記載の装置において、前記コントローラが、さらに、
    ルールに準拠していない前記所与のＴＣＰパケットに対応する前記セッションについて、阻止モードインジケータ値を設定し、
    前記第１のネットワークインターフェースを介して届いた後続のパケットに関連付けられている情報を、処理キューに格納し、
    前記処理キュー内の、前記パケットに関連付けられている前記情報が処理されたか否かを判断し、
    前記処理キュー内の、前記パケットに関連付けられている前記情報が処理されたと判断すると、前記阻止モードインジケータをクリアする、装置。

Images