問題タブ [fast-protocol]

何人かのプログラマーと話したところ、修正/高速メッセージをエンコード/デコードするための基本的なエンジンを作成するのは非常に簡単で、修正に 3 日、高速に 1 週​​間で済むとのことでした。私はそのようなものを探しています。

QuickFix はかなり大きく、少し「遅い」複雑なプロジェクトのように見えます。必要のない機能がたくさん含まれていると思います (ただし、パフォーマンスに影響を与える可能性があります)。

これまでのところ、マルチキャスト udp を介して fast-fix から引用を受信し、引用が欠落している場合は回復するだけで済みます。

だから私は、一般的な機能のみを提供するオープンソース エンジンを探しています。基本的には、高速/修正メッセージのエンコード/デコードです。何を提案できますか？

私は必要です：

• シンプルさ
• 速度

必要ない

• 特徴

すぐに使用できる完全なソリューションは必要ありません。便利でシンプルで高速なものが必要で、残りは自分でコーディングできます。

データをエンコードするためのFASTのようなプロトコルは、送信する必要のあるデータの量を最小限に抑えるのに非常に賢いです。基本的に、char *を取得し、最初の数バイトを整数として読み取ると、残りのバイトをデコードする方法の指示を示すID番号が得られます（つまり、残りのバイトは、たとえば、int、文字列、unsigned int、別のunsigned int、ネストされたメッセージなど）と次の数バイトは、後続のフィールドが存在するかどうかを（各ビットで）示します。すべてのバイトの8番目のビットは、データ間の境界を示すために予約されています。

このようなプロトコルのデコードは、ビット操作（and、ors、shifts、ビットチェック）の線形トラバーサルなしでは実行できないようです...これをより高速に実行する方法はありますか？

FASTプロトコルのフィード アービトレーションを実装する必要があります。問題はかなり一般的で、ハードウェアの解決策もあります問題は広く知られているので、それを実装する方法について少なくとも一般的な提案が必要だと思います (使用するクエリの数、リングバッファの数、リーダーの数、いつ実行するか)パケットをドロップするなど）、おそらく誰かが実装を教えてくれるでしょう。FAST に慣れていない人のために、説明を追加します。

すべての UDP フィードのデータは、2 つの異なるマルチキャスト IP 上の 2 つの同一のフィード (A と B) で配布されます。UDP パケット損失の可能性があるため、クライアントが両方のフィードを受信して​​処理することを強くお勧めします。2 つの同一のフィードを処理することで、統計的にパケット損失の可能性を減らすことができます。どの特定のフィード (A または B) でメッセージが最初に表示されるかは指定されていません。これらのフィードを調停するには、プリアンブルまたはタグ 34-MsgSeqNum にあるメッセージ シーケンス番号を使用する必要があります。プリアンブルを利用すると、FAST メッセージをデコードせずにメッセージ シーケンス番号を決定できます。フィード A および B からのメッセージの処理は、次のアルゴリズムを使用して実行する必要があります。

1. フィード A と B を聞く
2. シーケンス番号に従ってメッセージを処理します。

3. 同じシーケンス番号を持つメッセージが以前に処理された場合、メッセージを無視します。

   // tcp 回復アルゴリズムの詳細

だから私はその解決策は次のようになるべきだと思います：

1. 2 つのフィードのそれぞれについて、専用スレッドと専用バッファーを作成します。データが到着すると、バッファにデータを追加します。（リングバッファかキューか、それとも何ですか？）

2. 「スピン」する「リーダー」を作成し、最後の利用可能な「シーケンス番号」について両方のスレッドをチェックします。「シーケンス番号」が利用可能になるとすぐに、次のパケットを処理する必要があり、その後両方のスレッドがそれをドロップする必要があります。

アルゴリズム自体を実装する方法の提案と、おそらくどの構造を使用するかの提案を歓迎します。特に、おそらく誰かがロックフリー キュー/リング バッファの実装を提案できます。

FAST メッセージのシーケンスに問題があります
。たとえば、次のテンプレート xml があります。

最初にテンプレートの PMap を取得し、次のステップでテンプレート ID を取得します。その後、バイトを 1 つずつ読み取り、すべて正常に動作しますが、シーケンス「MDEntries」を取得すると、バイトのシーケンスが壊れるため、データが正しくなくなります。

FAST Message 構造の次の図を見て、シーケンスと長さ 'NoMDEntries' の PMap を読み取ってから、バイトを 1 つずつ読み取る必要があると思いますが、正しいですか? 以前は、バイトを 1 つずつ読み取り、ストップ ビットを削除するだけでよいと考えていました。

「シーケンス」を正しく解析する方法を教えてください