As I know LastRptRequested is used for “The last Execution Report in a partition sent in response to the request will include a LastRptRequested (912) of Last Message (Y).”
But how about norml drop session?
If we want to notify the last message of Drop Copy, but not for request, could we also use the tag(912)?
When client connect to our drop copy session, we want to make sure they got last message we send. They can disconnect the session then. Otherwise they need to wait a certain time.
Hi. Not sure if there is a recommended practice here; but for this use case, one approach I’ve seen is to define a News message indicating that no more execution reports should be expected. eg; MsgType=News,…,Headline=EOD. I’d be interested to learn of other approaches as well.
@shenghsiunghu LastRptRequested(912) is intended for a request/response workflow and does not apply for drop copies which is a broadcast. You can use the FIX concept of Application Sequencing (see https://www.fixtrading.org/online-specification/business-area-infrastructure/). The ApplicationMessageReport(35=BY) message with ApplReportType(1426)=1 indicates that the last message of a logical stream has been sent. You need to add the ApplicationSequenceControl component to your ExecutionReport(35=8) messages and assign application level sequence numbers to make this work.
Your recipients can also use Application Sequencing to re-request drop copies they may have missed in between or at the end of the day. That is the original intention of this concept.
Thanks for your reply.
I also search some FIX protocol specs of stock exhcnages, like LSE, ASX, SGX.
It seems it still not a common practice.
I wonder why they don’t have problem when something wrong internally.
How could they make sure their recipients got every message from their engine.
Maybe those exchanges still use only the session layer recovery. During the exchange of Logout messages, the client or sever can detect a sequence gap and would send a ResendRequest(35=2) message to obtain missing messages.