RE: [Quickfix-developers] empty sequence number on sequence reset message

[Michael R. <mr...@li...>]

Generally speaking, to avoid exceptions like these "crashing" my app, where
these should be caught?

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Wednesday, December 15, 2004 11:41 AM
To: Michael Raykh
Cc: qui...@li...
Subject: Re: [Quickfix-developers] empty sequence number on sequence reset
message


Serves me right for not writing a proper functional test for this.  I'll
reopen this issue and do it right this time :(
 
--oren

----- Original Message ----- 
From: Michael  <mailto:mr...@li...> Raykh 
To: 'Oren Miller' <mailto:or...@qu...>  ; Michael
<mailto:mr...@li...> Raykh 
Cc: 'qui...@li...'
<mailto:'qui...@li...'>  
Sent: Wednesday, December 15, 2004 10:34 AM
Subject: RE: [Quickfix-developers] empty sequence number on sequence reset
message


Reported this issue a while back, there was a fix (Session.cpp - version
1.54-->1.55), 
but issue is still there: 

  message.getHeader().getField( msgType ); 
  if( message.getHeader().isSetField( msgSeqNum ) ) 
    message.getHeader().getField( msgSeqNum ); 
  if ( message.getHeader().isSetField( possDupFlag ) ) 
    message.getHeader().getField( possDupFlag ); 

  reject.setField( RefSeqNum( msgSeqNum ) ); 

Instead of line message.getHeader().getField( msgSeqNum ) as originally, 
now exception is thrown in reject.setField( RefSeqNum( msgSeqNum ) ); 

-----Original Message----- 
From: Oren Miller [ mailto:or...@qu...
<mailto:or...@qu...> ] 
Sent: Thursday, November 04, 2004 10:54 AM 
To: Michael Raykh 
Cc: 'qui...@li...' 
Subject: Re: [Quickfix-developers] empty sequence number on sequence 
reset message 


Well, when a sequence reset is sent in reset mode (123=N) the spec says 
that you should ignore the MsgSeqNum.  I guess Appia took this to mean 
that they can choose to just not send it, even though it is listed as a 
required field (not conditionally required) in the standard header. 

First thing that we should do is have QF gracefully handle rejecting a 
message without a sequence number.  This should be accomplished easily 
enough by replacing that line with this: 

   if( message.getHeader().isSetField( msgSeqNum ) ) 
     message.getHeader().getField( msgSeqNum ); 

This will essentially cause the reject message to say it is rejecting 
the message with sequence number 0, which I think is a reasonable thing 
to say if there is no sequence number. 

Now the question is do we want to make an exception for this message 
type and process the message that doesn't contain this required field.  
I would say since it is our job to "ignore" it, than yes, we should 
probably allow it.  To accomplish this we will need to allow the 
nextSequenceReset method to specify that the validate method should 
ignore sequence numbers.  We can probably do this by rewriting the 
method like so: 

bool Session::verify( const Message& msg, bool checkTooHigh, 
                       bool checkTooLow, bool checkSequenceNumber ) 
{ QF_STACK_PUSH(Session::verify) 

   SenderCompID senderCompID; 
   TargetCompID targetCompID; 
   SendingTime sendingTime; 
   MsgType msgType; 
   MsgSeqNum msgSeqNum; 

   try 
   { 
     const Header& header = msg.getHeader(); 
     header.getField( senderCompID ); 
     header.getField( targetCompID ); 
     header.getField( sendingTime ); 
     header.getField( msgType ); 
     if( checkSequenceNumber ) 
       header.getField( msgSeqNum ); 

     if ( !validLogonState( msgType ) ) 
       throw std::logic_error( "Logon state is not valid for message" ); 

     if ( !isGoodTime( sendingTime ) ) 
     { 
       doBadTime( msg ); 
       return false; 
     } 
     if ( !isCorrectCompID( senderCompID, targetCompID ) ) 
     { 
       doBadCompID( msg ); 
       return false; 
     } 
     if ( checkSequenceNumber && checkTooHigh && isTargetTooHigh( 
msgSeqNum ) ) 
     { 
       doTargetTooHigh( msg ); 
       return false; 
     } 
     else if ( checkSequenceNumber && checkTooLow && isTargetTooLow( 
msgSeqNum ) ) 
     { 
       doTargetTooLow( msg ); 
       return false; 
     } 

     UtcTimeStamp now; 
     m_state.lastReceivedTime( now ); 
     m_state.testRequest( 0 ); 
   } 
   catch ( std::exception& e ) 
   { 
     m_state.onEvent( e.what() ); 
     disconnect(); 
     return false; 
   } 

   fromCallback( msgType, msg, m_sessionID ); 
   return true; 

   QF_STACK_POP 
} 

On Nov 4, 2004, at 8:33 AM, Michael Raykh wrote: 

> In our test of quickFix against Appia fix engine the following happens: 
> 
> - Appia sends sequence reset request msg 
> - for some reason sequence number field is not populated on this reset 
> request 
> - quickFix decides to reject this 
> - crashes in generateReject in 
>           message.getHeader().getField( msgSeqNum ); 
>    'cause message seq number is not set... 
> 
> 
> 
> Is this proper behaviour? Any suggestions how to handle this? 
>  This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they 
> are addressed. If you have received this email in error please notify 
> the system manager. This message contains confidential information and 
> is intended only for the individual named. If you are not the named 
> addressee you should not disseminate, distribute or copy this e-mail. 

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. 

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.