Протокол FIX: получение сообщения вне последовательности во время повторной передачи приводит к l oop при повторной передаче - PullRequest
2 голосов
/ 07 марта 2020

У меня есть клиент исправлений, использующий QuickFIX / n в качестве слоя FIX.

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

Когда мой клиент подключится снова, он заметит пробел в первом сообщении. Например, если последнее полученное от моего клиента сообщение имеет SeqNuM = 124 и после переподключения сервер отправляет SeqNum = 152, это означает, что сервер отправил сообщения с 125 до 151, прежде чем узнает об отключении.

Моя проблема возникает потом. Мой клиент отправляет запрос на повторную отправку 34 = 2 с BeginSeqNo 7 = 125 и EndSeqNo = 0 (дайте мне все). Во время этой повторной передачи и до ее завершения сервер FIX отправляет мне новое сообщение с SeqNo = 153

Так что мои клиенты получают:

- Disconnects with last message 124
- Reconnects 
- Receive 151
- Ask for Resend from 125 to 0 (everything after 125)
- Receive 125
- Receive 126
- Receive 127
- Receive 152 (35=8) <-- this makes the retransmission abort on my side
- Ask For resend from 128 to 0
---> if the number of message to resend is too high and new messages keep coming in
     my client never manages to get the full retransmission in one go.

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

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

Мой вопрос прост: что это за процедура кеширования и где я могу ее найти? найти спецификации об этом? И это обрабатывается библиотеками QuickFIX, или я должен реализовать что-то определенное c поверх него?

1 Ответ

1 голос
/ 15 марта 2020

Когда копали немного больше, мы наконец-то обнаружили, что реальная проблема заключалась в том, что мой клиент снова и снова запрашивал одну и ту же повторную передачу.

Например, если у меня 4000 порядковых номеров и я повторно отправляю повторную передачу сообщение каждый раз, когда есть последовательность непоследовательности (скажем, каждые 10 сообщений) Я могу в итоге попросить 500 раз в среднем более 1000+ сообщений.

Это создает высокую напряженность на стороне сервера и только ухудшает ситуацию .

В QuickFIX / J есть опция, которая также доступна в QuickFIX / N (но не упоминается об этом): SendRedundantResendRequests. Установив значение false, вы убедитесь, что ваш клиент не запрашивает дважды одну и ту же повторную передачу. Это значительно снижает нагрузку на сервер и облегчает переподключение.

...