我需要为FAST协议实现Feed仲裁。问题很常见，甚至有hardware solutions因为问题众所周知我认为至少应该有一些如何实现的一般性建议（我应该使用多少查询，有多少环形缓冲区，有多少读者，什么时候丢包等）可能有人可以指点我一些实现。对于那些不熟悉FAST的人，我添加了一些描述：
所有UDP源中的数据在两个不同的多播IP上的两个相同的源（A和B）中传播。强烈建议客户端因可能的UDP数据包丢失而接收和处理这两个源。处理两个相同的馈送允许统计上降低分组丢失的可能性。 未在第一次显示消息的特定馈送（A或B）中指定。要仲裁这些订阅源，应使用在Preamble或标签34-MsgSeqNum中找到的消息序列号。利用前导码允许在不解码FAST消息的情况下确定消息序列号。 应使用以下算法处理来自Feed A和B的消息：
如果之前已经处理了具有相同序列号的消息，则忽略该消息。
// tcp recover algorithm进一步
所以我认为解决方案应该是这样的：
对于两个Feed中的每一个创建专用线程和专用缓冲区。在数据到达时将数据添加到缓冲区。 （它应该是环缓冲区还是队列还是什么？）
创建“旋转”的“阅读器”并检查两个线程的最后一个可用的“序列号”。只要“序列号”可用，就需要处理下一个数据包，然后两个线程都应该丢弃它。
有关如何实现算法本身以及可能建议使用哪种结构的任何建议都是受欢迎的。特别是可能有人可以建议无锁队列/环缓冲区实现。
答案 0 :(得分：0)
FAST协议通常用于市场数据流，因此数据以UDP数据包形式到达，通常是多播。这些数据包排序，因此如果您需要在两个冗余源之间进行仲裁，您只需处理从您首先收到的任何频道的下一个预期数据包。你迟到的傻瓜包只是摔倒了。仲裁不仅可以降低丢失数据包的可能性（您必须在两个通道中丢失它），还可以减少延迟，因为如果其中一个数据源变慢，您总是有第二个选项。
您应该更关心解码FAST位。这可能很耗时。检查CoralFIX以获取如何从交换XML模板生成FAST解码源代码的示例。
免责声明：我是CoralFIX的开发者之一。