Imported from previous forum
If you have just began to honor a resend request and your are issued another resend request should you completely fulfill the 1st request or abandon it to respond to the most recent?
If you have just began to honor a resend request and your are issued
another resend request should you completely fulfill the 1st request or
abandon it to respond to the most recent?
Hi Joshua,
The below is quoted from
fix-44_VOL-2_w_Errata_20030618.pdf ( page 23 of 58 )
“It is possible to have multiple Resend Requests issued in a row (i.e. 5 to 10 followed by 5 to 11). If sequence number 8, 10, and 11 represent application messages while the 5-7 and 9 represent administrative messages, the series of messages as result of the Resend Request may appear as Sequence Reset-GapFill mode with NewSeqNo of 8, message 8, Sequence Reset-GapFill with NewSeqNo of 10, and message 10. This could then followed by Sequence Reset-GapFill with NewSeqNo of 8, message 8, Sequence Reset-GapFill with NewSeqNo of 10, message 10, and message 11. One must be careful to ignore the duplicate Sequence Reset-GapFill mode which is attempting to lower the next expected sequence number. This can be detected by checking to see if its MsgSeqNum is less than expected. If so, the Sequence Reset-GapFill mode is a duplicate and should be discarded.”
Given this from the 4.4 specification, I understand that if more Resend Requests are received when one ResendRequest is being processed, the application should add the requirements to honor the new resend requests to the existing resend request being honoured, ie the response to multiple resend requests is the union of the responses to the individual Resend Requests.
Alternatively, the following also works ( though not efficient ) :-
If my application receives a second Resend request ( 5 - 11 ) when it is in the process of honouring the first Resend Request ( 5 - 10 ), it can complete honouring the first request ( 5 - 10 ) and then honour the second request completely ( 5 - 11 ). In this case application messages 8 & 10 get transmitted twice in response to two resend requests. Thus more messages are transmitted, but it works.
This approach is simpler to implement. Assume the following scenario -
First resend request is for messages 5 - 10. My application has already transmitted sequence reset gap fill for messages 5,6,7,8 when the second resend request for 4 - 11 is received. In this case, I found it easier to complete honouring the first resend request and then process the second request as a new Resend Request. It is responsibility of the receiving application ( which sent multiple Resend Requests ) to process the duplicate messages sent as result of Resend Requests properly.
I am presently developing Sell side FIX server using Java TCP / Sockets programming.
Regards,
Mahesh
kay_mahesh@yahoo.com
+1-203-890-7981
If you have just began to honor a resend request and your are issued
another resend request should you completely fulfill the 1st request or
abandon it to respond to the most recent?
FIX 4.0 recommends that the messages be processed in a sequential order meaning that it is not advisable to process message number 8 before you are actually through with 7. Introducing look aheads will only complicate your message processing scheme. There are other simpler ways to reduce overheads.
For example, resend requests usually occur during logon processing. If you want to do away with the extraneous message exchange (brought about by honoring 2 or more resend requests) then I suggest you should wait for the opposing parties resend request before generating your own. (If both the parties are missing messages, there will be 2 resend requests sent by each of the parties (4 in total), first because an out of sequence logon and the second because of the out of sequence resend request message). Therefore, wait till one end of the connection is synchronized and then initiate your own process. “NOTE” that the waiting time should not be infinity :).