Imported from previous forum
[ original email was from Erik Duus - eric_duus@deanwitter.com ]
My FIX engine has trouble reestablishing a conversation after a network event. The problem basically boils down to the fact that while our engine is trying to perform gap-fill processing, the counter-party is sending new messages. For example:
- Expect 100, receive 105
- Resend request 100-105
- Receive 106
- Receive 100-105
My FIX vendor claims the counter-party has violated the protocol by sending 106 while we are trying to gap-fill. I think the vendor is wrong. Who’s right?
[ original email was from Shay Gordon - gordon@instinet.com ]
Your counterparty should really stop everything to comply with your request. Instinet’s (proprietary) FIX engine allows for this situation, though, by putting out-of-sequence messages on an internal queue which is processed after the gap is filled. This does of course assume that the counterparty will eventually fill the gap.
Be warned about this approach though. A worse predicament can occur if both parties have to issue resend requests after exchanging logon messages (FIX 4.0 and up). This can result in both parties waiting to have their gap filled, having put the received out-of-sequence resend request on the “process later” queue. We get around this by always processing resend request messages when they arrive, even if they’re out-of-sequence. Complicated, but it works.
> My FIX engine has trouble reestablishing a conversation after a network event. The problem basically boils down to the fact that while our engine is trying to perform gap-fill processing, the counter-party is sending new messages. For example:
> - Expect 100, receive 105
> - Resend request 100-105
> - Receive 106
> - Receive 100-105
>
> My FIX vendor claims the counter-party has violated the protocol by sending 106 while we are trying to gap-fill. I think the vendor is wrong. Who’s right?
>
>
[ original email was from Ed Colletta - ecollett@lehman.com ]
The other side could have sent two messages in
a row. The msg number 106 might have been sent
before your resend request.
> Your counterparty should really stop everything to comply with your request. Instinet’s (proprietary) FIX engine allows for this situation, though, by putting out-of-sequence messages on an internal queue which is processed after the gap is filled. This does of course assume that the counterparty will eventually fill the gap.
>
Check out the chart on page 90 of the fix 4.0 spec. YOu should always process the resend
request right away unless the sequence number
is less than expected and not poss dupe.
> Be warned about this approach though. A worse predicament can occur if both parties have to issue resend requests after exchanging logon messages (FIX 4.0 and up). This can result in both parties waiting to have their gap filled, having put the received out-of-sequence resend request on the “process later” queue. We get around this by always processing resend request messages when they arrive, even if they’re out-of-sequence. Complicated, but it works.
>
>
> > My FIX engine has trouble reestablishing a conversation after a network event. The problem basically boils down to the fact that while our engine is trying to perform gap-fill processing, the counter-party is sending new messages. For example:
> > - Expect 100, receive 105
> > - Resend request 100-105
> > - Receive 106
> > - Receive 100-105
> >
> > My FIX vendor claims the counter-party has violated the protocol by sending 106 while we are trying to gap-fill. I think the vendor is wrong. Who’s right?
> >
> >
>
[ original email was from Ed Colletta - ecollett@lehman.com ]
Sorry, that should have been page 9.
> Check out the chart on page 90 of the fix 4.0 spec. YOu should always process the resend
> request right away unless the sequence number
> is less than expected and not poss dupe.
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> My FIX engine has trouble reestablishing a conversation after a network event. The problem basically boils down to the fact that while our engine is trying to perform gap-fill processing, the counter-party is sending new messages. For example:
> - Expect 100, receive 105
> - Resend request 100-105
> - Receive 106
> - Receive 100-105
>
> My FIX vendor claims the counter-party has violated the protocol by sending 106 while we are trying to gap-fill. I think the vendor is wrong. Who’s right?
From what you have stated, and an assumption that I am making which is that 105 and 106 were sent with little time between, I think your vendor might be wrong.
What you are seing seems to be a common race condition. FIX connections are full-duplex queues; while you are sending a message, the other firm may be sending messages back to you.
For instance, I’m guessing what happened was that the other firm had two messages to send, 105 and 106, and sent them both. Both arrived at your machine. Your engine processed 105, saw it was out of sequence, sent the Resend Request, and received 106. The other party’s chronology probably looks like they sent 105 and 106 and then received your Resend Request.
The proper way to handle the situation on your side would be for you to send another Resend Request. (And if 106 happened to be a Resend Request, you are required to honor it first even it if is out of sequence.)
The other party will have sent 105 and 106, then get a Resend Request, send 100-105, get the second, and send 100-106. Since these are PossDupe, you will process 100-105, then ignore the next 100-105, and process 106.
Of course if the other side really did send 106 after receiving your Resend Request but before sending 100-105, then they really should be queueing the message, which they should send after replaying 100-105.