TestRequest out of sequence

, ,
1

Imported from previous forum

2

Which is the appropriate action when receiving a TestRequest message with a sequence number larger than expected?

According to the 4.1 specification (IMHO), a normal gap-fill operation should be performed, which may include throwing the TestRequest away and request resends of all messages up to and including the TestRequest. Doing this could however trigger a timeout in the counterpart session causing it to terminate.

Should the TestRequest be handled out of sequence, despite the protocol specification ?

Thanks in advance,

Ulf Eriksson
Interbizz Financial Systems

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
>
> Which is the appropriate action when receiving a TestRequest message with a sequence number larger than expected?
>
> According to the 4.1 specification (IMHO), a normal gap-fill operation should be performed, which may include throwing the TestRequest away and request resends of all messages up to and including the TestRequest. Doing this could however trigger a timeout in the counterpart session causing it to terminate.
>
> Should the TestRequest be handled out of sequence, despite the protocol specification ?

I would think it best to stick to the letter of the spec and not respond to the Test Request, but instead send a Resend Request.

If one only responds to a Test Request if it is in sequence, it allows the other party to use a Test Request as a verification that all messages up to that point have been successfully received.

For instance, if I send a Test Request and receive a Heartbeat with that TestReqID, then I know the other party has received all of the messages I sent up to and including that Test Request; otherwise the other party would not have responded to the Test Request but instead would have sent a Resend Request.

I know that some engines, upon receiving any valid message after a Test Request, will consider the connection still active. If the other party does this, your response to their Test Request with a Resend Request will reset their timer and prevent them from considering you idle and logging you off. I’m not sure if this conforms to the letter of the spec, but it appears to work quite well, and it certainly seems better than killing a perfectly healthy session just because a gap managed to happen right before a Test Request.