Re: [Quickfix-developers] SeqNum not incrementing

[Dave L. <dav...@ma...>]

> I don't think there is any problem sending this whenever you want.   
> If their acceptor is always sending a reset on a sequence number of
> 1, than the initiator probably should as well.  Otherwise If it  
> doesn't, I think the behavior would have to work as follows.
> 
> Initiator: Sends Logon Without ResetSeqNumFlag
> Acceptor: Respond With Logon With ResetSeqNumFlag
> Initiator: Respond With Logon With ResetSeqNumFlag
> 
> But, that doesn't seem like it would even work in this case, because
> after they send an unsolicited reset, they are still expecting  
> sequence number 2, when I would expect it would be 1 and the reject  
> would be due to receiving another message when a logon is expected.   
> It is possible they would respond entirely differently to a logon  
> message however, so who knows.
> 

It looks like quickfix only generates a ResetSeqNum ack in response to
the "initiator" (i.e. the initiator of the connection). If the
"acceptor" (i.e. the acceptor of the connection) initiates the
ResetSeqNum process then the quickfix "initiator" handles this as though
it were a ResetSeqNum ack (see attached examples, using version 1.11.0).

I found the code in the Session.cpp that seems to handle this decision:

  if ( !m_state.initiate() 
       || (m_state.sentReset() && !m_state.receivedReset()) )
  {
    if( logon.isSetField(m_state.heartBtInt()) )
      logon.getField( m_state.heartBtInt() );
    m_state.onEvent( "Received logon request" );
    generateLogon( logon );
    m_state.onEvent( "Responding to logon request" );
  }
  else
    m_state.onEvent( "Received logon response" );

I was wondering if the condition should be more like:

  if ( !m_state.sentReset() 
       && (!m_state.initiate() || m_state.receivedReset()) )

...i.e. the reciever of the logon has not already sent a reset and is
either the "acceptor" or the receiver of a reset. 

Cheers
Dave