Recovering from client side sequence number amnesia

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Recovering from client side sequence number amnesia

Dale Wilson
Due to some network problems, I may (or may not) have managed to send this message yesterday.   Please forgive it if it's a duplicate.

Dale

Hi QuickFIX developers,

I think I've run into a "you-can't-get-there-from-here" problem, but I'd like to be sure I'm not missing something.

The situation I'm trying to handle happens when the client (initiator) is recovering from a significant failure and has lost track of the sequence number expected by the server (acceptor).  The client sends logon message a sequence number that is less than the one expected by the server.  The server responds, correctly, with a logout message.  If the server is based on QuickFIX this logout message will contain a Text field giving the expected sequence number. 

   i.e.: 58=MsgSeqNum too low, expecting 7 but received 1

What I would like to do is detect this Logout message; inform the user of the situation; and allow them to verity that the sequence number should be reset.

Unfortunately as far as I have been able to determine, the Logout message containig the expected sequence number never reaches the application code.  QuickFIX determines that this is not a valid sequence of messages:

  [Session::verify calls Session::validLogonState and throws an exception when it returns false. ] 

and calls Application::onLogout()  (twice, actually, but who's counting.) The body of the message containing the expected sequence number isn't available vis the onLogout call -- so I can't find a way to determine what sequence number is expected.

My work around for this will be to read the log, identify the logout message, and parse it to find the expected sequence number -- unless, of course, someone tells me that there's a better way.

Any suggestions would be appreciated,

Dale

--
-----------------------------------------------------
Dale Wilson, Senior Software Engineer
Object Computing, Inc. (OCI)
http://www.ociweb.com/ http://www.theaceorb.com/
----------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Recovering from client side sequence number amnesia

Oren Miller
Dale,
 
You can ask the session object for the expected sequence numbers.
 
 
--oren
----- Original Message -----
Sent: Tuesday, May 24, 2005 12:53 PM
Subject: [Quickfix-developers] Recovering from client side sequence number amnesia

Due to some network problems, I may (or may not) have managed to send this message yesterday.   Please forgive it if it's a duplicate.

Dale

Hi QuickFIX developers,

I think I've run into a "you-can't-get-there-from-here" problem, but I'd like to be sure I'm not missing something.

The situation I'm trying to handle happens when the client (initiator) is recovering from a significant failure and has lost track of the sequence number expected by the server (acceptor).  The client sends logon message a sequence number that is less than the one expected by the server.  The server responds, correctly, with a logout message.  If the server is based on QuickFIX this logout message will contain a Text field giving the expected sequence number. 

   i.e.: 58=MsgSeqNum too low, expecting 7 but received 1

What I would like to do is detect this Logout message; inform the user of the situation; and allow them to verity that the sequence number should be reset.

Unfortunately as far as I have been able to determine, the Logout message containig the expected sequence number never reaches the application code.  QuickFIX determines that this is not a valid sequence of messages:

  [Session::verify calls Session::validLogonState and throws an exception when it returns false. ] 

and calls Application::onLogout()  (twice, actually, but who's counting.) The body of the message containing the expected sequence number isn't available vis the onLogout call -- so I can't find a way to determine what sequence number is expected.

My work around for this will be to read the log, identify the logout message, and parse it to find the expected sequence number -- unless, of course, someone tells me that there's a better way.

Any suggestions would be appreciated,

Dale

--
-----------------------------------------------------
Dale Wilson, Senior Software Engineer
Object Computing, Inc. (OCI)
http://www.ociweb.com/ http://www.theaceorb.com/
----------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Recovering from client side sequence number amnesia

Dale Wilson
Hi Oren,

Oren Miller wrote:
Dale,
 
You can ask the session object for the expected sequence numbers.
Unfortunately that tells me what my local copy of QuickFIX expects, but not what the FIX engine at the other end of the pipe is looking for.

This code:

  std::cerr << "Expected sender num before logon: " << session_->getExpectedSenderNum() << std::endl;
  std::cerr << "Expected target num before logon: " << session_->getExpectedTargetNum() << std::endl;
  session_->logon();

and:

void
QuickFIXECNAdapter::Exchange::onLogout( const FIX::SessionID& sessionID )
{
  std::cerr << "Expected sender num in onLogout: " << session_->getExpectedSenderNum() << std::endl;
  std::cerr << "Expected target num in onLogout: " << session_->getExpectedTargetNum() << std::endl;


Produces this output:

Expected sender num before logon: 1
Expected target num before logon: 1
Expected sender num in onLogout: 2
Expected target num in onLogout: 1
Expected sender num in onLogout: 3
Expected target num in onLogout: 1


And here's the interpreted input log message:

============================================================
 8=FIX.4.2 |          BeginString = FIX.4.2
     9=104 |           BodyLength = 104
      35=5 |              MsgType = Logout
     34=10 |            MsgSeqNum = 10
  49=EXSIM |         SenderCompID = EXSIM
52=20050524-19:00:51.000
           |          SendingTime = 20050524-19:00:51.000
 56=CLIENT |         TargetCompID = CLIENT
----------------------------------------
58=MsgSeqNum too low, expecting 7 but received 1
           |                 Text = MsgSeqNum too low, expecting 7 but received 1
----------------------------------------
    10=007 |             CheckSum = 007


Notice that the local copy of QuickFIX *still* doesn't know that the target is looking for sender sequence # 7.  ( I wouldn't really expect it to, that info is only available in the Text field which I'm planning to parse if I can get my hands on it.)

One theory I have is that the test in  Session::validLogonState is incorrect, because a Logout message is a legitimate response to a Logon.  If validLoginState allowed this message to pass then presumably both fromAdmin and onLogout would be called and I could capture the data I need to fix things in fromAdmin, and the session would end up correctly logged out.  There may be other implications of making this change that I'm missing, though so I haven't experimented yet.

Dale

 
 
--oren
----- Original Message -----
Sent: Tuesday, May 24, 2005 12:53 PM
Subject: [Quickfix-developers] Recovering from client side sequence number amnesia

Due to some network problems, I may (or may not) have managed to send this message yesterday.   Please forgive it if it's a duplicate.

Dale

Hi QuickFIX developers,

I think I've run into a "you-can't-get-there-from-here" problem, but I'd like to be sure I'm not missing something.

The situation I'm trying to handle happens when the client (initiator) is recovering from a significant failure and has lost track of the sequence number expected by the server (acceptor).  The client sends logon message a sequence number that is less than the one expected by the server.  The server responds, correctly, with a logout message.  If the server is based on QuickFIX this logout message will contain a Text field giving the expected sequence number. 

   i.e.: 58=MsgSeqNum too low, expecting 7 but received 1

What I would like to do is detect this Logout message; inform the user of the situation; and allow them to verity that the sequence number should be reset.

Unfortunately as far as I have been able to determine, the Logout message containig the expected sequence number never reaches the application code.  QuickFIX determines that this is not a valid sequence of messages:

  [Session::verify calls Session::validLogonState and throws an exception when it returns false. ] 

and calls Application::onLogout()  (twice, actually, but who's counting.) The body of the message containing the expected sequence number isn't available vis the onLogout call -- so I can't find a way to determine what sequence number is expected.

My work around for this will be to read the log, identify the logout message, and parse it to find the expected sequence number -- unless, of course, someone tells me that there's a better way.

Any suggestions would be appreciated,

Dale
    

--
-----------------------------------------------------
Dale Wilson, Senior Software Engineer
Object Computing, Inc. (OCI)
http://www.ociweb.com/ http://www.theaceorb.com/
----------------------------------------------------



-- 
-----------------------------------------------------
  Dale Wilson, Senior Software Engineer      
  Object Computing, Inc. (OCI)
  http://www.ociweb.com/  http://www.theaceorb.com/
----------------------------------------------------