Imported from previous forum
The FIX Specification (4.4) indicates for a garbled message, the initiator/acceptor should treat it like it was never actually received (disregard it).
This means the next receive, it is going to detect a gap in the sequence numbers and request a resend of the message.
This in turn means the initiator/acceptor could end up infinitely receiving a garbled message from an counter-party application that has a bug in it.
Now, the specification suggests you should deal with the infinite loop scenario, however, doesn’t indicate how you might do this.
Does anyone have a suggestion on what an initiator or acceptor should do in this situation. It seems more appropriate that a reject or logout might occur, but I’m looking for an answer within the protocol boundaries which will allow the initiator/acceptor to continue to process other messages.
Generally, you should build some kind of detection mechanism for fruitlessly repeated resends. There are various algorithms for doing this, such as keeping track of the seq nums of any garbled messages, along with a count of how many times it was received, etc. Or even just simply counting the number of garbled messages received without receiving a valid message, and resetting the count when a valid message arrives. If the garbled message count breaches a threshold that you pick, take action.
The action you take typically involves logging out with a suitable logout text message indicating the reason why you are logging out.
A logout is acceptable here, because in general, a repeated garbled message is an indication of a pretty serious problem in the FIX engine of your trading partner, and it needs to be dealt with.
> The FIX Specification (4.4) indicates for a garbled message, the initiator/acceptor should treat it like it was never actually received (disregard it).
>
> This means the next receive, it is going to detect a gap in the sequence numbers and request a resend of the message.
>
> This in turn means the initiator/acceptor could end up infinitely receiving a garbled message from an counter-party application that has a bug in it.
>
> Now, the specification suggests you should deal with the infinite loop scenario, however, doesn’t indicate how you might do this.
>
> Does anyone have a suggestion on what an initiator or acceptor should do in this situation. It seems more appropriate that a reject or logout might occur, but I’m looking for an answer within the protocol boundaries which will allow the initiator/acceptor to continue to process other messages.
>
Thanks.
Actually, I have a view that in a modern communications environment, a message should never be garbled for transmission reasons.
Therefore, I suspect it would be a fix engine bug or business application bug which would lead to this, and as a result wondered whether it would be better to send a reject message instead so that we don’t get into the constant retry loop.
[There is a possibility that an application may try to resend a messsage in response to a reject but this typically doesn’t seem to make sense.]
Fix 4.0 defined garbled messages as those messages that cannot either be parsed or fail one of the data integrity checks (such as the body length and the check sum verification). Note that messages containing unrecognized tags or message types do not come under garbled messages. According to this definition we may safely say that nothing can be done about it as it doesn’t fall under a valid message under any implementation (be it broker or exchange specific). And consequently we “have” to completely disregard the message without inferring anything about the constituent data.
But as the case may be, continually ignoring messages from an errant engine can lead to a never ending loop, thus causing wastage of precious resources on your end. This will only happen if a specific message is being malformed by the engine since. On the contrary, the connection will time out if “every” message is garbled. Generation of a resend request means that you are parsing at least one valid message of a higher sequence number than the garbled one. I think the best way to work around this problem is to keep a counter of the number of garbled messages generated against the expected sequence number. If your counter exceeds a specific amount then it is advisable to conclude that there is a major problem with the other side’s implementation.
> The FIX Specification (4.4) indicates for a garbled message, the initiator/acceptor should treat it like it was never actually received (disregard it).
>
> This means the next receive, it is going to detect a gap in the sequence numbers and request a resend of the message.
>
> This in turn means the initiator/acceptor could end up infinitely receiving a garbled message from an counter-party application that has a bug in it.
>
> Now, the specification suggests you should deal with the infinite loop scenario, however, doesn’t indicate how you might do this.
>
> Does anyone have a suggestion on what an initiator or acceptor should do in this situation. It seems more appropriate that a reject or logout might occur, but I’m looking for an answer within the protocol boundaries which will allow the initiator/acceptor to continue to process other messages.
>