Как запросить повторение уже полученного сообщения об ошибке

Question

У меня есть приложение, которое могло бы потенциально вызвать ошибку при получении сообщения ExecutionReport (35 = 8). Эта ошибка возникает на уровне приложения, а не на уровне уровня исправления. Механизм исправления записывает сообщение как видимое и поэтому не отправляет ResendRequest (35 = 2). Однако приложение не обработало его, и я хотел бы вручную запустить повторную обработку пропущенного ExecutionReport.

Задание ResendRequest (35 = 2) не работает, так как требует изменения ожидаемого следующего порядкового номера.

Было ли интересно, поддерживает ли FIX воспроизведение сообщений, но не требует сброса номера последовательности?

Answer 1

При обработке отчета о выполнении вы не должны исключать какие-либо исключения и ожидать, что библиотека FIX обработает его. Вы либо обрабатываете отчет, либо имеете системный сбой (т. Е. Вызываете abort()). Поэтому, если ваш код, обрабатывающий отчет о выполнении, генерирует исключение, и вы знаете, как его обрабатывать, затем поймайте его в той же самой функции, устраните причину проблемы и повторите попытку. Например (псевдо-код):

// This function is called by FIX library. No exceptions must be thrown because 
// FIX library has no idea what to do with them. 
void on_exec_report(const fix::msg &msg) 
{ 
    for (;;) { 
     try { 
      // Handle the execution report however you want. 
      handle_exec_report(msg); 
     } catch(const try_again_exception &) { 
      // Oh, some resource was temporarily unavailable? Try again! 
      continue; 
     } catch(const std::exception &) { 
      // This should never happen, but it did. Call 911. 
      abort(); 
     } 
    } 
} 

Конечно, это можно сделать библиотеку FIX сделать запрос на повторную передачу и передать вам это сообщение еще раз, если было сгенерировано исключение. Тем не менее, это не имеет никакого смысла, потому что, чтобы попросить отправителя (по сети, используя TCP/IP) повторно отправить сообщение, которое у вас уже есть (вверх по вашему стеку :)), и просто нужно обработать. Даже если бы это произошло, какова гарантия, что это не повторится? Повторная передача в этом случае не только не звучит правильно логически, другая сторона (т.е. обмен) может вызвать вас и попросить прекратить делать это дерьмо, потому что вы слишком много загружаете на свой сервер с ненужной повторной передачей (потому что IRL TCP/IP не теряет сообщений, и процесс синхронизации последовательности FIX происходит только при подключении, если, конечно, не используется некоторая ненадежная транспортировка, что теоретически возможно, но не происходит на практике).

При прерывании, тем не менее, библиотека библиотеки FIX не должна увеличивать последовательность RX, если она точно не знает, что пользователь обработал это сообщение. Так, что в следующий раз приложение запускается, оно фактически выполняет синхронизацию и получает отсутствующие сообщения. Если QuickFIX этого не делает, вам нужно либо исправить это, либо позаботиться об этом вручную (например, открыть винт с файлом, где хранятся порядковые номера RX/TX), либо использовать какую-либо другую библиотеку, которая правильно ее обрабатывает.

Answer 2

Это неправильная вещь.

ResendRequest сообщает другой стороне, что произошла ошибка передачи. В вашем случае этого не было, поэтому вы не должны этого делать. Вы злоупотребляете протоколом, чтобы покрыть ошибки вашего приложения. Это не верно. (Кроме того, как Влад Лазаренко указывает на his answer, если бы они сделали его повторную передачу, что сказать, что вы не будете иметь ошибку снова?)

Если ошибка происходит в обработчике сообщения, то это ваша проблема, и вам нужно найти его и исправить, или поочередно вам нужно поймать собственное исключение и обработать его соответствующим образом.

(Основываясь на прошлых вопросах, держу пари, что вы храните ExecutionReports в хранилище DB или что-то в этом роде, и вы хотите использовать Resends для компенсации исключений хранения БД. Плохая идея. Вам нужно придумать собственное решение для резервирования.)