Imported from previous forum
[ original email was from Lakshminarasimhan Rajabather - narasimhan@ssi-technologies.com ]
Some of the test cases (2t, 3b, 3c, 3e etc.) has the description of the Session acceptor state as follows:
‘Consider garbled and ignore message (do not increment the inbound MsgSeqNum and continue accepting messages’
Question: Shouldnt the session acceptor reject these messages at session level (with appropriate error) so that the session initiator gets to know that there is an error in the message he has sent? If the acceptor ignores the message and does not increment the inbound MsgSeqNum, the next incoming message will have a higher than expected MsgSeqNum, making the session acceptor to ask for a resend. The resent message will again be garbled. Will this not trigger an endless loop of resend requests from the session acceptor?
[ original email was from scott gietler - scott@transacttools.net ]
If the message appears to be garbled, the correct thing to do is NOT to increment the seq number… in case the messages got garbled while it was transmitted, you actually want to generate a resend request if the engine receives the next seq. #, because it means that you missed a message.
If the FIX engine itself has a bug in the code, and is generating a garbled message, that is a different problem, and that may throw some FIX engines into an infinite resend request loop. Engines should have code in them to limit the amount of resend requests they make for the same seq. # range…
The reason you don’t send a reject is because the assumption is that the message “got garbled” on the way, and that it will work itself out with the resend requests.
However, I do think the spec should be amended to limit the number of resend requests (maybe to 3 or 4), and then send a session-level reject and close the connection if the message keeps coming back garbled and the resend request limit is reached.
Scott Gietler
scott@transacttools.net
> Some of the test cases (2t, 3b, 3c, 3e etc.) has the description of the Session acceptor state as follows:
>
> ‘Consider garbled and ignore message (do not increment the inbound MsgSeqNum and continue accepting messages’
>
> Question: Shouldnt the session acceptor reject these messages at session level (with appropriate error) so that the session initiator gets to know that there is an error in the message he has sent? If the acceptor ignores the message and does not increment the inbound MsgSeqNum, the next incoming message will have a higher than expected MsgSeqNum, making the session acceptor to ask for a resend. The resent message will again be garbled. Will this not trigger an endless loop of resend requests from the session acceptor?
>