|
4.0 Session
< Previous Next >
re: Gap fill processing and new messages
Ed Colletta / Lehman Bros.
11 Feb 1999 3:47PM ETThe 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?
> >
> >
>
re: Gap fill processing and new messages
Ed Colletta / Lehman Bros. 11 Feb 1999 3:47PM ET
|
