Отключение инициатора quickfixj из-за слишком низкого значения seqnum

Отключение инициатора quickfixj: обнаружен END_OF_STREAM при попытке входа в принимающую сторону. Мы используем механизм исправления поставщика в качестве акцептора. и обратная связь от акцептора заключается в том, что запрос на вход в систему для xxxx не был принят, входящий слишком мал, ожидается 305, получено 27.

Я прочитал документацию по быстрому исправлению, но не понял, что является правильным решением для несоответствия порядкового номера. Я понимаю, что если я отключусь, мой инициатор отправит 35 = 4 для повторной отправки с порядковым номером на стороне инициатора, попросив принимающую сторону повторно отправить сообщения и заполнить пробел. Но в каком случае, если инициатор отправляет более низкий seqnum, он будет отклонен акцептором и откажет в соединении? И какова правильная процедура обработки такого рода отклонения и повторного подключения? Чтобы не потерять какое-либо сообщение, как обе стороны должны выполнить сброс и заполнить пробел? В случае разрыва между инициатором и получателем, какое рекомендуемое решение для синхронизации сообщений и их потери?


quickfix quickfixj jinitiator
person baron    schedule 13.06.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Из-за первого предложения вашего вопроса я хотел бы показать вам ответьте на то же сообщение об ошибке Disconnecting: Encountered END_OF_STREAM. Существует сообщение в блоге цитирует bhageera.

В конце концов, причина была довольно глупой… контрагент, к которому я подключался, разрешает только одно подключение для каждого пользователя/пароля (т. е. сеанс с этими учетными данными) за раз. Как оказалось, было другое приложение, использующее те же учетные данные для того же TargetCompID. Как только это приложение было отключено, текущее входило в систему нормально.

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

person Yannick    schedule 10.10.2019

arrow_upward
0
arrow_downward

В соответствии с логикой по умолчанию в QuickfixJ: QuickfixJ управляет двумя порядковыми номерами: ожидаемым SeqNum для получения (targetSeqNum) и nextSeqNumber для отправки.

Сравните следующий ожидаемый целевой SeqNum с полученным SeqNum. Если обнаружено несоответствие, примените следующую логику:

  • если SeqNum ниже ожидаемого, выйти из системы
  • если выше, отправьте запрос на повторную отправку

В вашем случае получено меньше, чем ожидалось, поэтому он отключается.

Причина получения более высокого, чем ожидалось, SeqNum: получатель пропускает какое-то сообщение, поэтому это может быть нормальным сценарием.

Причина меньшего, чем ожидалось, SeqNum (ваш случай): один из контрагентов сбрасывает свой порядковый номер, что, как ожидается, не должно быть согласовано обеими контрагентами.

В обычном сценарии всякий раз, когда вы пропустите сообщение, вы получите более высокий номер, и им будет управлять QuickFixJ.

person Hemant Singh    schedule 13.06.2018
comment
Я думаю, что в моем случае (в качестве инициатора) я отправляю низкий seqnum, чтобы получатель немедленно отключился при моем сообщении о входе в систему. Когда вы говорите, что SeqNum ниже ожидаемого, выйдите из системы, что это значит? Я отключен, поэтому я не могу выйти из системы. Кроме того, когда вы говорите, если выше, отправьте запрос на повторную отправку. Вы имеете в виду, что я должен обработать сообщение об отключении и отправить 35 = 4 с меньшим seqNum? - person baron; 13.06.2018
comment
Извините за неясность. Существует 2 порядковых номера SenderSeqNum: порядковый номер, используемый для отправки сообщений. TargetSequenceNumber: ожидаемый порядковый номер в получаемых сообщениях. Проверка выполняется по порядковому номеру, полученному по TargetSequenceNumber. Порядковые номера между клиентом и сервером должны быть синхронизированы. В вашем случае, даже если другая сторона сбросит порядковый номер, вы получите сообщение об ошибке, потому что клиент отправит меньший порядковый номер, который вы ожидаете. - person Hemant Singh; 14.06.2018
comment
Этот случай является сценарием ошибки, и QuickFixJ (настраиваемая логика другой стороны) может автоматически отключить соединение, мне нужно подтвердить поведение QuickFixJ по умолчанию. Но это обычная практика, когда и клиент, и сервер сбрасывают порядковые номера по соглашению (при входе в систему, каждый день или при отправке 141 = Y и т. д.). Не могли бы вы вставить несколько журналов FIX для того же, чтобы я мог проанализировать их дальше? - person Hemant Singh; 14.06.2018