[This message was posted by Ryan Pierce (FPL Technical Director) of FIX Protocol Ltd. <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/7071d521 - PLEASE DO NOT REPLY BY MAIL.]
> What is the "official way" to do an initial logon after a disaster > either at the initiator or acceptor, that is, where either side has lost > its session (sequence number) state? It's hard for there to be an "official way" as this situation falls entirely outside the FIX spec. FIX assumes that each side of a session can keep state, and as such it can recover automatically from certain communications errors. But if a side loses its state, this is an all-hands-on-deck emergency. Attempting to recover automatically by using ResetSeqNumFlag=Y on Logon is often inappropriate. Only engines that support 24 hour FIX connections need to support it, and the majority of systems don't do this. So you have no guarantee that a party would honor the message and reset its sequence number. Also, even if the session recovers successfully, application data will likely be missing. An automatic recovery may hide this until someone discovers trade breaks. A disaster situation can happen if one party resets their sequence number and the other party does not do so. It often results in one party sensing a sequence number higher than expected and sending a Resend Request from 1 onward, resulting in the entire day's data being replayed. Depending on how much state is missing, this could have really bad consequences. A client replaying most of a day's orders to the exchange, and the exchange proceeding to execute them a second time. Or an exchange could reject the orders, which itself is serious; if ClOrdID=123 is alive at the exchange prior to the disconnection, and ClOrdID=123 is resent, and the exchange rejects it because of a duplicate ClOrdID, the client might infer that ClOrdID=123 is dead, causing much surprise when the same order fills an hour later. I think what to do in these situations is outside the scope of the spec. My own personal suggestions are: 1. Determine if recovery is appropriate. If multiple sessions between the parties exist, often the safest course of action may be to cancel all orders on the broken session and leave it down for the rest of the day, using the other session(s) for future traffic and reconciling any missed fills offline. 2. If recovery is to be done, both parties need to agree on whether one side or both should start with seq no 1, what sequence numbers should be expected, whether a replay of all or some of the day's traffic is possible, whether or not this is desired, and what actions should be taken. 3. Careful monitoring needs to happen as the session is brought up. 4. Recovery of missed data needs to happen. One needs to determine if duplicating data to a party will be a problem. (e.g. were only sequence numbers lost, or were state on whether business messages had been processed lost as well?) This could be done via a Resend Request, either manually initiated or with one party adjusting their expected sequence number prior to the connection. One party could, if their application supported it, manually initiate an application-level resend of data to the other party with the PossResend flag (although, again, extreme caution is needed to make sure that the other system supports this flag and can identify what has and has not been processed.) Or recovery could happen via an offline means, e.g. e-mailing an Excel spreadsheet of transactions. I hope this helps! [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 -~----------~----~----~----~------~----~------~--~---
