Что такое контракт на обмен сообщениями QuickFIX / J? Получу ли я гарантию доставки заказа?
Я только начинаю работать с QuickFIX / J. Одна вещь, которую я смущаю, читая их документы, заключается в том, что именно контракт обмена сообщениями обеспечивается реализацией QuickFIX протокола FIX?
В частности, я знаю, что FIX имеет встроенный механизм на основе порядковых номеров, который реализации могут использовать для обработки неупорядоченных, отсутствующих или дублированных сообщений. Но есть ли в QuickFIX / J уже встроенная возможность? Могу ли я предположить, что приложение, использующее QuickFIX / J для связи с механизмом исправлений:
Сообщения, доставляемые в мое приложение из QuickFIX / J, всегда в порядке.
Нет пропущенных сообщений (QuickFIX / J автоматически обработает повторный запрос)
Нет дублирующихся сообщений (QuickFIX / J может посмотреть полученный порядковый номер и отфильтровать возможное дублирование)
Если двигатель удаленного исправления выйдет из строя, я автоматически подключусь с последним известным порядковым номером, когда двигатель вернется
Если мое приложение выйдет из строя, сможет ли оно при перезапуске автоматически возобновить сеанс с предыдущего известного порядкового номера? (например, будет ли какой-либо нестандартный механизм сохранения порядковых номеров?)
Ответы
QuickFIX / J реализует протокол сеанса FIX, поэтому он обрабатывает все вещи на уровне сеанса (соединения, порядковые номера, ...) за вас.
- Да, но могут быть дубликаты, см. 3.
- Да.
- Нет, на самом деле QFJ по-прежнему будет пересылать возможные дубликаты в ваше приложение, потому что вы все равно можете их обрабатывать. Вам нужно отфильтровать их самостоятельно, если хотите, на основе
43/PossDupFlag
. - Да.
- Да. QFJ имеет некоторые из коробки инерционности механизмов , как
FileStore
,JdbcStore
,MemoryStore
. Вы также можете реализовать свои собственные,Store
если вам нужно.
Вот ссылка на то, как создать приложение QFJ, если вы еще не нашли его: https://github.com/quickfix-j/quickfixj#creating-a-quickfixj-application