[Quickfix-developers] Resend request range for >= FIX 4.2 always specify zero EndSeqNo
Brought to you by:
orenmnero
From: Igor S. <se...@tb...> - 2009-06-15 16:09:20
|
Hi, I am curious if there is a valid reason in EndSeqNo being always set as zero in resend requests for version FIX 4.2 or above. The exact implementation of Session::generateResendRequest() looks like: ... EndSeqNo endSeqNo( msgSeqNum - 1 ); if ( beginString >= FIX::BeginString_FIX42 ) endSeqNo = 0; else if( beginString <= FIX::BeginString_FIX41 ) endSeqNo = 999999; ... So, the resolved value (msgSeqNum-1) is always ignored, and in the resulting resend request there will be either 0 or 999999 for EndSeqNo, depending on FIX version. FIX server having this behavior causes confusion to FIX clients since they are asked for messages _already_ delivered within existing and live FIX session. Scenario: - client sends logon 34=N - server sends logon, OK - client sends many requests, obtaining numbers from N+1...N+k - server puts incoming requests into queue since in fact it is out of sync... and issue resend request for range [N-m..0] - client is confused, because besides the range [N-m..N-1] it is also asked for just sent messages with numbers [N+1...N+k] The confusion mainly comes due to specific client needs, where some message types are not allowed for resending.. and by omitting some messages during this resend client assumes that these messages were not delivered to FIX server. There seems no good suggestion for FIX client -- on some message resend it doesn't know if it was ever delivered to the other side, or? The valid solution would be to change QF behavior for Session::generateResendRequest(), so that in the scenario above the range [N-m..N-1] is requested by FIX server. Is there something _for_ the existing behavior, with 0 being always set in the range? Any suggestions, comments? Thanks, Igor |