Что произойдет, если ResendRequest потеряется или инициатор не сможет ответить на него?

Рассмотрим следующую диаграмму последовательности, которая изображает связь между инициатором FIX и получателем. Обратите внимание, что здесь я имею в виду FIX.4.4.

введите здесь описание изображения

Как видите, сообщение с порядковым номером 2 теряется при передаче. Инициатор отправляет другое сообщение (с номером последовательности 3), получатель обнаруживает этот пробел и выдает запрос на повторную отправку, снова запрашивая сообщение с номером последовательности. номер 2 и все, что могло за этим последовать (7=2|16=0).

Пара вопросов, на которые я не смог найти ответа, копаясь в спецификации:

  • Что произойдет, если запрос на повторную отправку будет потерян в пути?
  • Что произойдет, если инициатор не сможет повторно отправить запрошенные сообщения?

fix-protocol
person Matthias Güntert    schedule 12.08.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Что произойдет, если запрос на повторную отправку будет потерян в пути?

Пробел будет обнаружен в последующем сообщении так же, как вы указали.

Однако на самом деле сообщение ResendRequest не будет отправлено повторно, поскольку единственное сообщение уровня сеанса, которое должно быть отправлено повторно, — это сообщение Reject. Вместо этого либо SequenceReset с 123/GapFillFlag=Y (description) будет отправлено, или сообщение будет пропущено с сообщением SequenceReset с 36/NewSeqNo, установленным на более высокий порядковый номер, эффективно пропуская сообщение, которое не будет повторно отправлено.

Это указано в спецификации FIX в главе восстановления сообщений (ссылка)

Что произойдет, если инициатор не сможет повторно отправить запрошенные сообщения?

Как указано выше, вместо этого следует отправить GapFill или перейти к более высокому порядковому номеру.

person Christoph John    schedule 12.08.2020
comment
Спасибо за ответ. Это также справедливо для FIX.4.4? Кажется, это связано с FIXT 1.1. Извините, я упомянул об этом в своем первоначальном вопросе - исправлено. - person Matthias Güntert; 13.08.2020
comment
Это определенно применимо ко ВСЕМ версиям FIX. - person Christoph John; 13.08.2020
comment
Хорошо, отлично. Значит, только принимающая сторона (акцептор) может отправить SequenceReset сообщение? - person Matthias Güntert; 13.08.2020
comment
Вы ссылаетесь на свой пример? Потому что нет, каждая сторона может отправить SequenceReset сообщений. - person Christoph John; 13.08.2020
comment
Хорошо, но если обратиться к моему примеру, когда ResendRequest потерялся в пути: акцептор отправил бы SequenceReset (режим сброса) в ответ на следующее полученное сообщение о рассинхронизации. Правильный? - person Matthias Güntert; 13.08.2020
comment
Эм, нет. Когда какая-либо сторона обнаруживает разрыв (т. е. получает несинхронизированное сообщение), она отправляет ResendRequest для запроса отсутствующих сообщений. Когда какая-либо сторона хочет заполнить пробел в ответ на ResendRequest другой стороны, она либо повторно отправит отсутствующие сообщения, либо отправит SequenceReset в режиме Reset или GapFill. См. абзац, начинающийся с «При получении запроса на повторную отправку» ‹2› в ссылке, которую я разместил (глава восстановления сообщения). - person Christoph John; 13.08.2020