FASTプロトコルのフィード アービトレーションを実装する必要があります。問題はかなり一般的で、ハードウェアの解決策もあります問題は広く知られているので、それを実装する方法について少なくとも一般的な提案が必要だと思います (使用するクエリの数、リングバッファの数、リーダーの数、いつ実行するか)パケットをドロップするなど）、おそらく誰かが実装を教えてくれるでしょう。FAST に慣れていない人のために、説明を追加します。
すべての UDP フィードのデータは、2 つの異なるマルチキャスト IP 上の 2 つの同一のフィード (A と B) で配布されます。UDP パケット損失の可能性があるため、クライアントが両方のフィードを受信して処理することを強くお勧めします。2 つの同一のフィードを処理することで、統計的にパケット損失の可能性を減らすことができます。どの特定のフィード (A または B) でメッセージが最初に表示されるかは指定されていません。これらのフィードを調停するには、プリアンブルまたはタグ 34-MsgSeqNum にあるメッセージ シーケンス番号を使用する必要があります。プリアンブルを利用すると、FAST メッセージをデコードせずにメッセージ シーケンス番号を決定できます。フィード A および B からのメッセージの処理は、次のアルゴリズムを使用して実行する必要があります。
- フィード A と B を聞く
- シーケンス番号に従ってメッセージを処理します。
同じシーケンス番号を持つメッセージが以前に処理された場合、メッセージを無視します。
// tcp 回復アルゴリズムの詳細
だから私はその解決策は次のようになるべきだと思います：
2 つのフィードのそれぞれについて、専用スレッドと専用バッファーを作成します。データが到着すると、バッファにデータを追加します。（リングバッファかキューか、それとも何ですか？）
「スピン」する「リーダー」を作成し、最後の利用可能な「シーケンス番号」について両方のスレッドをチェックします。「シーケンス番号」が利用可能になるとすぐに、次のパケットを処理する必要があり、その後両方のスレッドがそれをドロップする必要があります。
アルゴリズム自体を実装する方法の提案と、おそらくどの構造を使用するかの提案を歓迎します。特に、おそらく誰かがロックフリー キュー/リング バッファの実装を提案できます。