Imported from previous forum
[ original email was from John Prewett - jprewett@lavatrading.com ]
I have noticed a similar mistake made by several FIX engines concerning handling receipt of a batch of out-of-sequence messages.
The mistake these FIX engines make is to issue one ResendRequest for each message received. Each of these ResendRequests asks for a similar range of messages to be received. This is very bandwidth unfriendly as the side processing the ResendRequest is virtually obligated to process each one in its entirety as it is received, resulting in way too much unnecessary message retransmission.
Example of poor behavior (taken from yesterday):
‘A’ receives MsgSeqNums 17153 thru 17172 while expecting MsgSeqNum 15895.
- ‘A’ sends ResendRequest for 15895 thru 17153 upon receipt of MsgSeqNum 17153.
- ‘A’ sends ResendRequest for 15895 thru 17154 upon receipt of MsgSeqNum 17154.
- ‘A’ sends ResendRequest for 15895 thru 17155 upon receipt of MsgSeqNum 17155.
- And so on.
Clearly ‘A’ isn’t being smart enough. Message sequence numbers 15895 thru 17153 were requested to be retransmitted 19 times and these 19 ResendRequests were actually received in the same millisecond!
Speaking on behalf of the recipient of these ResendRequests (I guess I’m ‘B’), I was wondering if I could attempt to circumvent this poor behavior of ‘A’.
Here is my proposal.
When receiving a ResendRequest, the FIX engine looks to see if it recently has received and processed a ResendRequest to retransmit a similar range of messages. If so, it only retransmits any delta in the range of messages to be retransmitted (if any).
Given the example above, this would mean that ‘B’ would behave as follows:
- Upon receipt of first ResendRequest for 15895 thru 17153, ‘B’ retransmits the requested messages and reemebers it has done so along with the timestamp of the request.
- Upon receipt of the second ResendRequest for 15895 thru 17154, ‘B’ notices that it has recently retransmitted 15895 thru 17153 and only retransmits the delta which would result in only retransmitting message 17154.
- Upon receipt of the third ResendRequest for 15895 thru 17155, ‘B’ notices that it has recently retransmitted 15895 thru 17154 and only retransmits the delta which would result in only retransmitting message 17155.
- And so on.
While clearly it would be better if ‘A’ behaved sensibly, ‘B’ is under my control and I am proposing to add more intelligence to manage what appears to be a common implementation mistake amongst not-too-smart FIX engines.
Now this extra intelligence must have some cutoff to determine when a message has been ‘recently’ been retransmitted and when that retransmission can no longer be considered ‘recent’. Certainly, this knowledge of what is ‘recent’ shouldn’t survive a logoff/disconnect/logon sequence. I imagine it could take the form of a brief (configurable) time interval in milliseconds. For example, only remembering ResendRequests you have honored within the last 20mSec would appear to resolve issues arising from almost all the poor implementations I have had to endure.
Comments?