[This message was posted by Pritam Kamat of PapaKilo <[email protected]> to the "5.0 SP2 Feedback" discussion forum at http://fixprotocol.org/discuss/121. You can reply to it on-line at http://fixprotocol.org/discuss/read/7f46fd8f - PLEASE DO NOT REPLY BY MAIL.]
Hi Hanno thanks for that - it doesn't quite fit my scenario but I didn't describe it very well. Let me try again without reference to a specific message type. Lets say you have a client FIX Engine which acts, for want of a better term, as a multiplexer of messages to end users. So each end user can connect to the client FIX Engine, which connects to a sellside FIX engine. The sellside FIX engine knows about all the messages it has issued but the client FIX engine does not have any persistence at its end. Now a specific end user of the client FIX Engine wants to know about his messages and only his mesages. What I was thinking was that each end user would have an ApplID which he could effectively 'register' with the sellside and thus issue a request for just the messages he was interested in. What I didn't see was a way to 'register' this ApplID - from what I understand this needs to be assigned and known by the sellside. cheers pritam > Pritam, > > the ApplID is not issued by the client (order submitter) but by the > central marketplace that wishes to split bulk information into logical > streams by means of multiple ApplID values. > > Application Sequencing thus needs to be supported by the entity > receiving the orders. You could support it towards your clients for drop > copies of Execution Reports. You could assign ApplID values such as "O" > for orders and "T" for trades (fills) and sequence them accordingly. > Your clients can then request message sequences from "T" to get drop > copies of trades. > > It should not replace the FIX session level recovery as this is standard > FIX engine behaviour. However, you can send gap fill messages on the > session layer to keep MsgSeqNum values intact and use application > sequencing to make some of the messages available for recovery on an > application level, e.g. only "T" and not "O". > > Regards, Hanno. > > > Hi > > > > I have a question about application sequencing and whether it would be > > applicable for a scenario I have. > > > > I have a FIX Engine through which a number of clients can connect and > > trade. If a particular client gets disconnected it may want to re- > > request certain messages. I thought rather than a resendRequest the > > application sequencing would be useful here (having seen the > > presentation at EMEA). > > > > So the disconnected application needs to request messages using its > > ApplID however I have not seen where it can set it. > > > > To use messages and fields for a bit more clarity: application A sends > > an order and received an execution with application sequence number 5. > > In order to use application sequencing I would have thought that the > > ApplID 'A' would need to be sent in the order to be returned in the > > execution. The later if application A got disconnected and > > reconnected, it could query for the last execution sent for > > application A. > > > > I am aware that OrderStatusRequest could possibly applied in the above > > example but lets assume it isn't just orders/executions that I am > > interested in, and also I would like to be able to query on the last > > message intended for application A without any presumption about what > > application A thinks it should have received (if you see what I mean). > > > > cheers pritam [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
