Re: [Quickfix-developers] Socket Monitoring/Verification

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

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.

As far as I know, the only Exception raised by SendToTarget is the
FIX::SessionNotFound, nothing related to sockets (this is good in my
opinion).

But, in order to avoid losing messages, I suggest the verification of its
return value. If SendToTarget returns false, it means that the message has
not been sent and that it won't be resent, since it was not written in the
session's Store.

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.

Regards,
Djalma

On 3/25/07, Dave Linaker < dav...@ma...> wrote:
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> >    I am working on a QuickFIX App that connects to a counterparty
> > where the connection is not very reliable.  Checking the logs, I see on
> > average half a dozen to ten re-logins each market day.  I want to be a
> > lot more proactive about tracking the status of the connection, and if
> > possible, when it is time to send out an application message, check to
> > see that the connection is good before even attempting to send it.  I've
>
> > put a try {} around my sendToTarget calls and attempted to catch
> > exceptions related to the socket, but none get thrown.  Even when I
> > am testing and deliberately break the network connection, I still get
> > no exception thrown.
> >
>
> No there won't be, the messages are persisted and will ultimately be
> resent
> when the connection is reestablished.
>
> >    Does anyone have a decent rundown on what facilities are there in
> > QuickFIX to monitor the status of the socket at a low level?  Are there
> > any flags or fields on the Session that I can check?  Should I force a
> > Test message before attempting to send Orders, etc.?  I don't want to
> > hack QuickFIX itself if I can avoid it.
> >
>
> The onLogout() in your interface will be called whenever there is a logout
> or disconnection, so you could also use this to handle unexpected
> disconnects.
>
> You could check the session to see if it is logged on before you send the
> message, perhaps something like:
>
> FIX::Session* pSession = FIX::Session::lookupSession( sessionID );
> if( pSession ) {
>   if( pSession->isLoggedOn() ) {
>       FIX::Session::sendToTarget( message, sessionID );
>   }
> }
>
> Cheers,
> Dave
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>