Re: [Quickfix-developers] Sequence numbers and session startup question
Brought to you by:
orenmnero
From: <OM...@th...> - 2002-03-04 18:06:58
|
Sean, FIX very specifically defines an automatic recovery process for when you send a message that is too high. There is no automated recovery process for sending a sequence number that is too low. The following is a quote, which is actually in bold in the specification document. If the incoming message has a sequence number less than expected and the PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session be terminated and manual intervention be initiated. Basically, there is no way to determine automatically how to recover. We can't simply reset everything to 1 because that could result in message loss. Likewise if we increased the sequence number. For this reason it is considered a fatal error where the user must determine the appropriate course of action. The fact that the sequence numbers catch up at all is a side effect of how sequence numbers are incremented in FIX. If FIX was redesigned today it would probably never catch up to the correct sequence number (i.e., Logons probably wouldn't increment the expected numbers). Does FIX support a way to reset sequence numbers? The newer versions do (the logon message supports a field to tell the opposite side to reset the sequence numbers). This was designed for 24 hour connectivity (reseting when the sequence number reaches 99999), however it could be used for this purpose assuming the other side supports this functionality (many do not). Currently however QuickFIX does not implement a way for you to manually indicate you want to send one. In any case such action would not be safe because it could result in message loss. Also it would not work with FIX 4.0 (reseting during logon only was introduced in 4.1). The easiest work around for this is to manually edit the sequence number file and set your next target sequence number to one that you know is higher than what the target is expecting. This is the only method I know of to ensure there is no message loss. If you are unsure of this number it may require a little trial and error, however incrementing the number by 1000 each trial should get you pretty fast results in any case. Generally when such a thing happens, it is prudent to call up your counter party to verify these numbers. Here is what the specification says about reseting the targets expected sequence number to a lower number: The sequence reset can only increase the sequence number. If a sequence reset is received attempting to decrease the next expected sequence number the message should be rejected and treated as a serious error. Despite these warnings, if you still want to automate this, let me know and we can probably figure out something. Keep in mind any solution will be inherently non-standard and potentially unsafe. I would certainly like to hear any suggestions you have about how we can simplify the process of manually recovering from this situation. --oren |---------+-----------------------------------------------> | | "Sean Castette" | | | <sca...@ge...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 03/04/02 08:56 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: <qui...@li...> | | cc: | | Subject: [Quickfix-developers] Sequence numbers and session startup question | >----------------------------------------------------------------------------------------------| I am working with the "ordermatch" and "tradeclient" sample applications. I have changed the samples to log the messages that are sent/received for each of the 4 events in both apps (from/to Admin/App). When I start both of them initially, they connect with each other and work correctly. However, if I disconnect the client and remove its sequence numbers and message files and then try to reconnect it takes a long time for the Logon to occur. The client starts sending logon requests (MsgType=A) to the server with a sequence number starting at 1 and incrementing with each attempt. The server keeps dropping the connection until a message with the expected sequence number has been received. The client will also drop the socket once the server drops it. This causes Logoff events in both the client and server to fire. Then, in the "block"/"onTimeout" loop of the initiator, the client will try to re-establish the connection after 30 events. Once the connection is re-established, the client will send a logon with the next sequence number. During this process, there are no Application level events that are fired (toAdmin, fromAdmin) on the server, except the Logout event. The events on the client are the "toAdmin" for the logon request (MsgType=A) and a "Logout" event. > Is there a way to have the client initiate the conversation with a logon that resets the sequence numbers? I believe that this would be the preferred course of action if the recovery files are not found. > Is there another way to speed up this logon or to have more control of the process from the application? Any help is much appreciated. Thanks, Sean Castette ---------------------------- GetCo (312) 242-4605 |