Блог

Главная - Вопросы по программированию - Что произойдет, если повторный запрос будет потерян или инициатор не сможет на него ответить?

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

#fix-protocol

#исправить-протокол

Вопрос:

Рассмотрим следующую диаграмму последовательности, которая изображает обмен данными между инициатором ИСПРАВЛЕНИЯ и принимающим. Пожалуйста, обратите внимание, что я ссылаюсь на ИСПРАВЛЕНИЕ.4.4 здесь.

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

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

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

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

Ответ №1:

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

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

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

Это указано в спецификации ИСПРАВЛЕНИЯ в главе «Восстановление сообщений» (ссылка)

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

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

Комментарии:

1. Спасибо за ответ. Это также справедливо для FIX.4.4? Похоже, это связано с FIXT 1.1. Извините, я упоминал это в моем первоначальном вопросе — теперь исправлено.

2. Это определенно применимо ко ВСЕМ версиям ИСПРАВЛЕНИЯ.

3. Хорошо, отлично. Таким образом, только принимающая сторона (акцептор) может отправить SequenceReset сообщение?

4. Вы ссылаетесь на свой пример? Потому что нет, каждая сторона может отправлять SequenceReset сообщения

5. Мм, нет. Когда какая-либо сторона обнаруживает разрыв (т. Е. получает несинхронизированное сообщение), она отправляет ResendRequest запрос на недостающие сообщения. Когда какая-либо сторона хочет заполнить пробел в ответ на a ResendRequest другой стороны, она либо повторно отправит недостающие сообщения, либо отправит a SequenceReset в режиме Reset или GapFill . Смотрите абзац, начинающийся с «При получении запроса на повторную отправку<2>» по ссылке, которую я разместил (глава «Восстановление сообщений»).