How to reset the sequence number while ensuring the retransmission of lost messages

[lw6666666]

In our system, in order to prevent the sequence number from being too large and causing storage overflow and to control the size of the transmitted message, the client and server set ResetOnLogon=Y on the client and server respectively to configure the reset sequence number. The message storage method uses file storage, but it is found that after the client or server restarts the service, the other method does not send a resend request to the other party for the last lost message, but directly chooses to ignore it. As a result, our system loses a lot of messages. I hope to get a solution ，

The following is the main configuration of our system
[default]
FileStorePath=./fileStore
FileLogPath=./logs-client
ConnectionType=initiator
HeartBtInt=30
ContinueInitializationOnError=Y
StartTime=02:59:01
EndTime=02:59:00
MaxMessagesInResendRequest=10000
FileLogHeartbeats=Y
FileIncludeTimeStampForMessages=Y
RejectGarbledMessage=N
RejectInvalidMessage=N

[session]
UseDataDictionary=N
DataDictionary=fix/FIX44.xml
SenderCompID=xxxx
TargetCompID=xxxx
BeginString=FIX.4.4
SocketConnectHost=xxxxx
ResetOnLogon=Y
ResetOnLogout=Y
ResetOnDisconnect=Y

[chrjohn]

You cannot resend messages when you reset the sequence numbers on each Logon. The reset deletes the message store as well.

[lw6666666]

You mean the quickfix framework doesn't implement this feature, right?

[lw6666666]

Is it not possible to reset the sequence number and resend the failed or unsent messages?

[chrjohn]

The FIX protocol does not implement this feature. Imagine you reset the seqnums to 1 and get a resend request from seqnums from 1 to 10000. How should the engine know which messages to resend?

Maybe you can describe your use case more exactly. Under which circumstances are you losing messages? What are failed messages?

MaxMessagesInResendRequest is no supported option in QuickFIX/J, so maybe you are wrong in this forum. However, it is not a problem of the engine but more of the FIX protocol.

[lw6666666]

The fixes are based on the server and the client, but no matter which side will always restart the service, then the disconnection will occur when the service restarts. Assuming that the server is disconnected at this time, but the client is still sending messages, but the client does not report any errors at this time. After the server restarts, I found that the unsuccessful messages sent by the client during the server disconnection were not resent before the sequence number was reset.

[lw6666666]

However, I found that when neither the client nor the server configures sequence number reset, and the message storage method is configured as file storage, both parties will resend the lost messages.