Imported from previous forum
I would appreciate some feedback about the following scenario…
Note: our FIX engine always acts as a FIX session Acceptor; we never initiate a session.
We receive a Logon message during an active session that has a higher-than-expected MsgSeqNum (X+2 for example, where X is the MsgSeqNum we are expecting).
We respond with a Logon message immediately followed by a ResendRequest (as per the chart on page 9 of the Protocol). In the ResendRequest we ask for X to 999999.
The session Initiator detects a gap because our Logon authentification message has a higher-than-expected sequence MsgSeqNum. Upon receipt of our Logon message they immediately send a ResendRequest.
Both engines are now expecting the other side to honor the ResendRequest, so neither engine is transmitting messages. The connection has become stale.
When the connection is closed for lack of heartbeats and the Initiator tries again, the same scenario will happen.
Without manually resetting sequence numbers, how could this be avoided?
Thanks!
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Both engines are now expecting the other side to honor the ResendRequest, so neither engine is transmitting messages. The connection has become stale.
This should not be true if both engines are following the spec exactly.
Let’s say you are expecting 10 and receive a Logon of 15. You send a Logon of 55 (The other side was expecting 50) and a Resend Request (message 56) for 10-999999.
The other side sees your out of sequence Logon, sends a Resend Request (message 16) of 50-999999, and then receives your Resend Request, message 56. The crucial point here is that even though the sequence number is greater than expected, that FIX engine is REQUIRED to FIRST honor the Resend Request (i.e. send 10 PossDupe Gap Fill to 17), and THEN send another ResendRequest (msg 17) for 50-999999.
You see their first Resend Request which is out of sequence (msg 16) and FIRST honor it (50 PossDupe Gap Fill to 57), and THEN send 57 ResendRequest 10-999999. You next receive 10 PossDupe Gap Fill to 17, set your next expected number to 17, get 17 Resend Request 50-999999, you send 50 PossDupe Gap Fill to 58. Once they receive your 2nd Resend Request, you will receive again 10 PossDupe Gap Fill to 18, which you ignore because you are expecting 18, 10 < 18, and it is PossDupe.
The same things happens with the other side. The net reseult is that as long as no new messages are sent during this period, each side will have sent and received and honored exactly 2 Resend Requests, would have received the gap of messages twice (ignoring them the second time around) and will then be in sync. Yes, it’s a little inefficient, but it does work quite well.
Note that if instead of requesting X-999999 you request X-Y, it is possible that several more unneeded Resend Requests would be generated due to race conditions, possibly leading to a point where a timer expires or a counter of Resend Requests declares an infinite loop as been achieved.
In short, what happens is that one side sends two messages at once which are out of sequence (i.e. a responding Logon and Resend Request), you send Resend Request 10-15, then Resend Request 10-16, they honor them by sending 10 Poss Dupe Gap Fill to 16, 10 Poss Dupe Gap Fill to 17, then send 18. You are required to ignore the second gap fill, are expecting 17, and get 18, causing another resend request.
This is why I consider X-999999 to be significantly better than X-Y. It seems you are already doing that; it just seems from what you said that you believe the proper course of action is either to ignore the out of sequence Resend Requests, or to ignore all messages including Resend Requests while waiting for the other side to honor your request, neither of which are the action required by the spec.
I had a similar problem. I work in Thomson Financial Portfolio Solutions and we use Javelin’s Coppelia as our FIX Server. What I had to do was add a delay because this was immediately after we ran EOD for the connection. Since EOD hadn’t completed, the sequence number was out of psynch by 2-3.
I hope this helps.
> I would appreciate some feedback about the following scenario…
>
> Note: our FIX engine always acts as a FIX session Acceptor; we never initiate a session.
>
>
> We receive a Logon message during an active session that has a higher-than-expected MsgSeqNum (X+2 for example, where X is the MsgSeqNum we are expecting).
>
> We respond with a Logon message immediately followed by a ResendRequest (as per the chart on page 9 of the Protocol). In the ResendRequest we ask for X to 999999.
>
> The session Initiator detects a gap because our Logon authentification message has a higher-than-expected sequence MsgSeqNum. Upon receipt of our Logon message they immediately send a ResendRequest.
>
> Both engines are now expecting the other side to honor the ResendRequest, so neither engine is transmitting messages. The connection has become stale.
>
> When the connection is closed for lack of heartbeats and the Initiator tries again, the same scenario will happen.
>
> Without manually resetting sequence numbers, how could this be avoided?
>
> Thanks!
>