Imported from previous forum
[ original email was from Peter Lada - lada@twinsun.com ]
During the development of our FIX engine we came across the following dilemma, I am seeking your thoughts on this issue.
If let’s say a transmission line is garbled at the same time for both ways, messages are lost traveling back and forth. If the transmission clears up later, bith sides will notice missing MsgSeqNum’s. Both sides issue ResendRequest messages, but since these messages are in the future (meaning MsgSeqNum’s are too high), no processing is done. This seems to be an infinite loop.
Our solution was to always respond to a ResendRequest, as soon as we receive it. This exception will break the infinite loop, even if it is only applied on one side.
I would be interested in the behavior of other FIX engines. How did other developers solve this problem?
Peter Lada
The scenario George describes is more clearly documented in "FIX Session-level Test Cases and Expected Behaviors" (either under "Organization", "Tech Committee" archive or FIX 4.3 Volume 2). Specifically reference the "FIX Logon Process State Transition Diagram" section.
>> This problem is raised all the time but you can find in the FIX specs (hidden somewhere) :
>> "Response to ResendRequest : Perform the Resend processing first, followed by a ResendRequest of your own in order to fill the incoming message gap."
>> So, you must deduct that a ResendRequest as to be processed as a Logon message : receiv Logon -> reply Logon -> resend request if needed.
>> I think this point is not enough highlighted in the FIX Specification. Plus it is a dramatic problem if not taken in account.
>> Regards,
>> Georges Gomes
>> gg@ullink.com
> During the development of our FIX engine we came across the following dilemma, I am seeking your thoughts on this issue.
>
> If let’s say a transmission line is garbled at the same time for both ways, messages are lost traveling back and forth. If the transmission clears up later, bith sides will notice missing MsgSeqNum’s. Both sides issue ResendRequest messages, but since these messages are in the future (meaning MsgSeqNum’s are too high), no processing is done. This seems to be an infinite loop.
>
> Our solution was to always respond to a ResendRequest, as soon as we receive it. This exception will break the infinite loop, even if it is only applied on one side.
>
> I would be interested in the behavior of other FIX engines. How did other developers solve this problem?
>
> Peter Lada
>