Что такое контракт обмена сообщениями QuickFIX/J? Получу ли я гарантию доставки заказа?

Я только начинаю работать с QuickFIX/J. Одна вещь, которую я смущаю, читая их документы, заключается в том, что именно контракт обмена сообщениями обеспечивается реализацией QuickFIX протокола FIX?

В частности, я знаю, что FIX имеет встроенный механизм на основе порядковых номеров, который реализации могут использовать для обработки неупорядоченных, отсутствующих или дублирующихся сообщений. Но есть ли в QuickFIX/J уже встроенная функция? Как приложение, использующее QuickFIX/J для связи с механизмом исправлений, могу ли я предположить:

  1. Сообщения, доставленные в мое приложение из QuickFIX/J, всегда в порядке.

  2. Нет пропущенных сообщений (QuickFIX/J автоматически обработает повторный запрос)

  3. Нет повторяющихся сообщений (QuickFIX/J может просмотреть полученный порядковый номер и отфильтровать возможное дублирование)

  4. Если модуль удаленного исправления выйдет из строя, я автоматически переподключусь с последним известным порядковым номером, когда модуль вернется

  5. Если мое приложение выйдет из строя, сможет ли оно автоматически возобновить сеанс с предыдущего известного порядкового номера при перезапуске? (например, будет ли какой-либо готовый механизм сохранения порядкового номера?)


fix-protocol quickfixj
person Xinchao    schedule 18.08.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

QuickFIX/J реализует протокол сеанса FIX, поэтому он обрабатывает все вещи на уровне сеанса (подключение, порядковые номера и т. д.) за вас.

  1. Да, но могут быть дубликаты, см. 3.
  2. да.
  3. Нет, на самом деле QFJ по-прежнему будет пересылать возможные дубликаты в ваше приложение, потому что вы все еще можете их обработать. Вам нужно отфильтровать их самостоятельно, если хотите, на основе 43/PossDupFlag.
  4. да.
  5. да. QFJ имеет некоторые готовые механизмы сохранения, такие как FileStore, JdbcStore, MemoryStore. Вы также можете реализовать свой собственный Store, если вам нужно.

Вот ссылка о том, как создать приложение QFJ, если вы еще не нашли его: https://github.com/quickfix-j/quickfixj#creating-a-quickfixj-application

person Christoph John    schedule 18.08.2020
comment
Хорошо, спасибо. Вы абсолютно правы в том, что QuickFIX/J имеет полностью встроенную обработку управления сеансом. Часто ли приложение перезаписывает номер последовательности при перезапуске? QuickFIX/J сохраняет полученный порядковый номер синхронно после отправки сообщения приложению. Но если я перемещаю сообщения в другую очередь, они не считаются обработанными, пока рабочий поток не прочитает из этой очереди. Я могу отслеживать номер последовательности на другом конце очереди вручную, но как я могу передать свой номер последовательности в QuickFIX/J, когда мое приложение восстанавливается после сбоя? - person Xinchao; 21.08.2020
comment
Вам нужно использовать хранилище сообщений, чтобы установить следующие ожидаемые порядковые номера. Позаботьтесь о том, чтобы изменить значение перед началом/принятием следующего входа в систему. Вы можете использовать Session.setNextTargetMsgSeqNum(int) или Session.setNextSenderMsgSeqNum(int) - person Christoph John; 21.08.2020
comment
После некоторого тестирования я понял, что не все сообщения администратора доставляются на прикладной уровень по порядку. Меня особенно смущает поведение при ответе на вход в систему, когда требуется повтор сообщения. Ответ на вход всегда доставляется (метод fromAdmin) в момент его получения, а затем следуют повторно отправленные сообщения. Это означает, что мое приложение сначала увидит ответ на вход в систему с номером последовательности (который выше, чем ожидалось), а затем повторно отправит номер последовательности. Что еще более удивительно, в конце повтора есть SeqReset с GapFill, чтобы пропустить ответ о входе в систему. вообще не доставляется приложению? - person Xinchao; 26.08.2020
comment
Мне нужно посмотреть в источнике, чтобы быть уверенным, но есть некоторые сообщения, которые пересылаются в любом случае, независимо от их порядкового номера. Вход и выход, например. Ответ на вход в систему пропускается, поскольку сообщения уровня сеанса не отправляются повторно (кроме сообщения об отклонении). Вам действительно нужно учитывать сообщения администратора? - person Christoph John; 26.08.2020
comment
Я понимаю, почему получатель отправляет SeqReset, чтобы пропустить ответ о входе в систему. Но я думал, что мой слой приложения должен видеть этот SeqReset. Случилось так, что ответ на вход (с seq=10) был получен и доставлен в приложение, а затем поставлен в очередь. После этого происходит повторная отправка сообщения для последовательностей 7, 8, 9, а затем это поставленное в очередь сообщение о входе в систему обрабатывается для продвижения targetSeqNum до 10 (следовательно, ожидается 11). Наконец приходит SeqReset (с seq=10, newSeqNo=11, PossDup=Y) и игнорируется, потому что его порядковый номер слишком мал: он равен 10, но QuickFIX/J ожидает 11. - person Xinchao; 26.08.2020
comment
изначально я думал, что просто посмотрю на все полученные сообщения и запишу их порядковый номер на своем прикладном уровне. Меня не волнует значение сообщений администратора на уровне приложения, но в случае, если соединение не используется в течение длительного времени (нет сообщений приложения, просто сердцебиение), я хочу время от времени продвигать свой отслеживаемый порядковый номер. чтобы не отставать слишком далеко. Но если сообщения администратора не всегда доставляются по порядку, отслеживание их последовательного номера будет более сложным, чем просто получение поля. И я бы предпочел полностью игнорировать сообщения администратора. - person Xinchao; 26.08.2020
comment
Хм, вы уверены, что SeqReset игнорируется, потому что его seqnum слишком низкий? Звучит странно для меня. Можете лог куда-нибудь загрузить? Какой движок использует контрагент? - person Christoph John; 26.08.2020
comment
да, это то, что я понимаю под трассировкой исходного кода. Сервер представляет собой очень простой эхо-сервер, который я также сделал с помощью QuickFIX/J. Да, я могу загрузить журнал куда-нибудь, если вы считаете, что это неожиданно - person Xinchao; 26.08.2020
comment
Я полагаю, вы используете последнюю версию? - person Christoph John; 26.08.2020
comment
ага, должна быть самая последняя версия релиза - person Xinchao; 26.08.2020
comment
Мое предложение: чтобы убедиться, что ваши порядковые номера синхронизированы, отправьте TestRequest с уникальным TestReqID (например, отметкой времени) сразу после входа в систему. Когда ответ Heartbeat с соответствующим TestReqID передается вашему коду, вы знаете, что вы синхронизированы. Таким образом, вы можете игнорировать сообщения администратора почти полностью, кроме Heartbeats с желаемым TestReqID. Или вы также можете позволить всем другим Heartbeats время от времени продвигать отслеживаемые последовательности. - person Christoph John; 27.08.2020