Re: [Quickfix-developers] Sequence numbers and session startup question

[<OM...@th...>]

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...|
|         |           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