Как реализовать арбитраж на фиде A и фиде B в финансовом протоколе FAST?

Мне нужно реализовать арбитраж каналов для БЫСТРО протокол. Проблема довольно распространенная и есть даже аппаратные решения Поскольку проблема широко известна, я думаю, что должны быть как минимум общие предложения о том, как ее реализовать (сколько запросов я должен использовать, сколько кольцевых буферов, сколько считывателей, когда отбрасывать пакеты и т. Д.) И, возможно, кто-то может указать меня к некоторой реализации. Для тех, кто не знаком с FAST, я добавлю описание:

Данные во всех каналах UDP распространяются в двух идентичных каналах (A и B) на двух разных IP-адресах многоадресной рассылки. Настоятельно рекомендуется, чтобы клиент получал и обрабатывал оба канала из-за возможной потери пакетов UDP. Обработка двух одинаковых каналов позволяет статистически снизить вероятность потери пакетов.
Не указано, в каком конкретном фиде (A или B) сообщение появляется впервые. Для арбитража этих каналов следует использовать порядковый номер сообщения, найденный в преамбуле или в теге 34-MsgSeqNum. Использование Преамбулы позволяет определить порядковый номер сообщения без декодирования сообщения FAST.
Обработка сообщений из каналов A и B должна выполняться по следующему алгоритму:

1. Слушайте каналы A и B
2. Обрабатывать сообщения в соответствии с их порядковыми номерами.

3. Игнорировать сообщение, если оно уже было обработано с таким же порядковым номером.

   // алгоритм восстановления TCP

Поэтому я думаю, что решение должно быть таким:

1. Для каждого из двух каналов создается выделенный поток и выделенный буфер. Добавить данные в буфер по мере поступления данных. (это должен быть кольцевой буфер или очередь или что?)

2. Создайте «ридер», который «раскручивает» и проверяет оба потока на наличие последнего доступного «порядкового номера». Как только «порядковый номер» становится доступным, следующий пакет должен быть обработан, и оба потока должны отбросить его после этого.

Любые предложения о том, как реализовать сам алгоритм и, возможно, предложения о том, какие структуры использовать, приветствуются. В частности, возможно, кто-то может предложить реализацию без блокировки очереди / кольцевого буфера.