Как я могу получить QuickFix для обработки сообщений, поступающих из запроса на повторную отправку?

Question

Я пишу приложение-акцептор и использую постоянный сеанс FIX. Я пытаюсь написать режим восстановления, например, если я перехожу в автономный режим или моя программа перезапускается, при повторном подключении я хочу повторно обработать все сообщения, отправленные мне в течение дня, чтобы вернуться в текущее состояние.

Для этого при запуске я отправляю запрос на повторную отправку всех сообщений на сервер. Они возвращают мне все соответствующие сообщения, и они помечены possdupflag = Y и possresend = Y. Перед каждым сообщением они отправляют сброс последовательности для повторяющегося сообщения, которое они собираются отправить.

Проблема в том, что эти сообщения, похоже, не обрабатываются моим взломщиком сообщений. И fromAdmin, и fromApp не получают эти сообщения. Я предполагаю, что они игнорируются из-за флага dup и / или повторной отправки. Так есть ли способ сообщить мне QuickFIX, что я хочу видеть эти сообщения?

На этой заметке - если у кого-нибудь есть какие-либо рекомендации по улучшению процессов восстановления, я буду открыт для них.

Спасибо.

Answer 1

Существует как минимум пара потенциальных проблем с этой стратегией восстановления. Во-первых, он не очень дружелюбен к вашему торговому контрагенту. Если во время сеанса вы получаете только небольшое количество сообщений, это может не вызывать проблем, но если вы получаете сотни тысяч сообщений, ваш контрагент может жаловаться на массовые повторные отправки.

Другая проблема заключается в том, что повторная отправка сообщений предназначена для восстановления после ошибок и управляется уровнем протокола сеанса. В QuickFIX / J (и других механизмах FIX) сеанс поддерживает состояние восстановления в дополнение к автоматической отправке ResendRequest при обнаружении пропуска порядкового номера. Ваш подход может сработать, если вы сбросите следующий ожидаемый входящий порядковый номер на 1. Когда сеанс получит следующее сообщение с большим порядковым номером, он обнаружит пробел и запросит пропущенные сообщения. Если сообщения проверены, они будут перенаправлены на прикладной уровень с установленным флагом PossDup. Если вы отправите сообщение ResendRequest самостоятельно, поведение будет неопределенным, поскольку состояние сеанса не будет настроено должным образом.

Я рекомендую использовать реализацию MessageLog для хранения входящих сообщений в форме, которую вы можете использовать для восстановления при запуске приложения. Вы можете посмотреть на реализацию существующих журналов сообщений (FileLog, JdbcLog), чтобы получить некоторые идеи.

Answer 2

У меня тоже такая же проблема, и что Фрэнк говорит абсолютно правильно, просто используйте метод ниже, чтобы установить целевой порядковый номер в начало последовательного номера требуемого запроса повторной отправки.

 getSession()->setNextTargetMsgSeqNum(atoi(seq.c_str()));

Двигательвнутренне определяет, что целевой номер слишком велик и автоматически отправляет запрос на повторную отправку, и все сообщения будут перехвачены в самом обратном вызове onMessage как обычно

Answer 3

Поведение происходит потому, что система персистентности движка сообщает ему, что полученные сообщения являются повторно отправленными сообщениями и поэтому (согласно спецификации протокола FIX) отбрасываются.Здесь мы сохраняем строки FIXml в нашей базе данных, чтобы обеспечить возможность восстановления, аналогичную той, которую вы описываете (они также записываются в файлы XML на диске по другим причинам).Я не верю, что есть какой-либо способ сообщить quickfix, что вы хотите видеть дублирующиеся сообщения, но, вероятно, лучше использовать другую форму или постоянство, чтобы сэкономить на издержках соединения.Quickfix предоставляет способ вывода сообщений в файл по мере их поступления, если это помогает.