should Test Request Initiator disconnect the connection if the remote party does NOT send a response BUT still sending msgs for a resend request ?

1

Please assume below scenario,

  • Party-A sends a FIX Resend request (assume the gap is large).
  • Party-A sends a Test Request. Assume the Response expected timeout is 3 times the HB interval.
  • Other party keeps sending msgs for above Resend Request (with PossDup=Y)
  • Now even after the timeout (3 times the HB interval) other party does NOT send the response to the Test Request because it is still sending the responses to the Resend Request.

NOW, should the Test Request Initiator break the connection because of the timeout OR should he wait until the resend request is completed before starting the count down timer ? logically it seems the second one should be the correct option. But if one is to do that next comes the question for how long should he wait for the resend request to complete ? because the other party could delay the completion of the resend request.

Is this explicitly mentioned anywhere in the FIX standard documents ?

2

Is Party A sending a Test Request right after a ResendRequest and not waiting for Party B to respond? If that’s what Party A is doing, my question is why?

This shows that responding to the resend has a higher precedence than a TestRequest
https://www.fixtrading.org/standards/fix-session-layer-online/#fix-session-state-matrix

TestRequest is meant to be send when you are not receiving heartbeats, it is not advise to send TestRequest unnecessarily.

If there is a concern with resends taking too long because the session being used for high frequency trading, you might want to consider not doing resend requests at all and resolve those “missing” messages offline or use the ApplicationMessageRequest(35=BW) to do requests to recover msgs on a different session. This is not a common technique between buy-side and sell-side setups, but used by exchanges. However, my question to you here is by “completion” are you saying the resend has not started or did it start already but may take 2 mins to complete because it is a big gap? If Party B is already sending the requested messages, as I said above, this session is “live” and no reason for the TestRequest nor to terminate the session. If the start of the resending the messages is delayed, my question is what is Party B sending in the mean time? I would suspect that whatever B sends is likely still going to cause a sequence gap issue.

1 Like
3

Test Request is sent(upon login) as part of Sequence number synchronization strategy before sending queued messages (to avoid flushing msgs from (finite sized) FIX resend cache before other party recovers them). This is done despite a resend request is sent or not (by us).
When the remote side responds to the Test request, we can assume that he has sent any resend requests from his side(and they are served by us) and after that we can start sending queued msgs.

What I meant by “resends taking too long” is, say we change our FIX engine rule to “Do NOT disconnect the connection even if the remote party does NOT send the response within the timeout IF remote party is still sending responses to a Resend Request”.
Now, How can we decide “remote party is still sending responses to a Resend Request” ? e.g. one strategy might be “has the remote party sent a PossDup=Y msg within last N seconds”.

What I wanted to know is what does the FIX standrds say about this scenario.

4

I’d encourage you to look through the standard via the link I mentioned for session level scenarios. It seems to me you’re imposing an additional step on Login by sending a TestRequest regardless. I wouldn’t have configured it this way. If the other side responds with a Login in a timely fashion there is no reason for a TestRequest. If upon Login and you have a session that is out of sequence, then one side should be requesting resend, again I don’t see a TestRequest being necessary.

I’d do what you stated and see if the sequencing stabilizes, it can be determined based on whether one side is still attempting to do ResendRequest or not. My concern with sending TestRequest in the midst of all this is it can make troubleshooting difficult because you end up having at least 2 things happening at the same time.

I’d advocate for keeping it simple.

5

as I mentioned earlier, Test Request is sent to ensure whether Resend Request could be expected or NOT from the other side.
This is one method of sequence number synchronization suggested by FIX protocol documents.