Re: [Quickfix-developers] Socket Monitoring/Verification

[Djalma R. d. S. F. <drs...@gm...>]

Hi guys,

Thank you Dave for the answers. I have to agree with you that FIX is an
optimistic model.
But, it would be clearer and easier for me if SendToTarget could return one
of the following 3 values:

0 - message successfully sent
1 - message not sent, but seqnum incremented and message stored to be resent
after reconnection
2 - message won't be sent for some reason (because toApp threw DoNotSend or
an IOException was raised e.g.), which means no possiblity of resending
after reconnection

This way, I would have information to know what really happened with the
message and I would be more confortable to decide what to do.

@Jim, if you have SenderCompID, TargetCompID and BeginString then you
already have the SessionID, see the available FIX::SessionID constructors.

Another solution is getting the SessionID from the mounted message:

FIX::Session* pSession = FIX::Session::lookupSession( message.getSessionID()
);
if( pSession )
{
    if( pSession->isLoggedOn() )
    {
        if (!FIX::Session::sendToTarget( message ))
        {
            // error handling here (optional?)
        }
    }
}

Regards,
Djalma

On 3/25/07, Dave Linaker <dav...@ma...> wrote:
>
> Hi Djalma,
>
> > Yes, these are exactly the same techniques I use in my application to
> > detect the availability of connections.
> >
> > In the past, before sending, I used to check if session was logged on,
> as
> > Dave showed in his example. But, later I verified that SendToTarget
> > already does it internally and then I decided to stop doing it, so I
> could
> > avoid the performance penalty of a double-checking.
>
> True, but this only prevents it from actually being sent while the
> connection is down, it would still be stored and consume a sequence
> number,
> and later on be sent when the inevitable ResendRequest arrives.  You could
> of course prevent the stored message from being resent by throwing a
> DoNotSend when the connection is reestablished. So I guess it depends on
> what you want to achieve:
>
> - if you always want the message to be sent then I think there is little
> to
> be gained by checking the logon state before sending.
> - if you only want the message to sent if there is an active connection
> then you could either:
>
>     - check the logon state before sending, or
>     - send it anyway, and prevent the resend in toApp() with DoNotSend
>
> > If a connection problem occurs after the message is written to the
> store,
> > the function will return true, although the message was not sent. In
> this
> > case, Dave is right, the message won't be lost, but only if the app is
> > lucky enough to get a soon reconnection and if the counterparty sends a
> > ResendRequest, after detecting the message sequence number gap.
> >
> > I think that for mission-critical systems this is dangerous to rely on
> the
>
> > desire of the counterparty to resend messages, there should be an
> > alternative in QF, like a function/queue from where to get the messages
> > that were not sent due to unavailability of a socket connections. With
> > this function, the application could force the "resending" of these
> > messages even if a SequenceReset is received.
>
> I think the ResendRequest is inevitable provided that the subsequent
> reconnection takes place during the same session. Each message that is
> stored consumes a sequence number regardless of whether it is actually
> sent.
> So, if you have sent some messages while the connection was down, when you
> logon, your Logon message will have a later sequence number and the other
> side will see a gap and must perform a gap fill operation to fill that
> gap.
> The counterparty is required to process messages in sequence so they must
> fill any gaps. I think there should always be a ResendRequest to recover
> the
> messages sent while the connection was down (i.e. it is not optional on
> the
> part of the counterparty).  FIX is an optimistic model, which means you
> are
> always reliant on the counterparty to identify any missed messages.
>
> Cheers,
> Dave
>
>