Re: [Quickfix-developers] Socket Monitoring/Verification

[Jim W. <wi...@wi...>]

   First, many thanks for the reply.


Dave Linaker 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.
>   
   Unless you throw DoNotSend in toApp, correct?
>>    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 );
>   } 
> }
>
>   
   I managed to work out something similar, by checking the
SocketInitiator isLoggedOn() method before attempting to send.
Still, your technique seems a little more elegant -- but it begs the
question of how exactly I get the sessionID.  The function where
I'm generating the messages to be sent is not a method that gets
the sessionID passed in automatically.  It gets called in the main
loop of the run() method, where the sessionID does not appear to
be immediately available.  I have to admit I'm primarily a C
programmer, not C++, and there is a definite learning curve
trying to figure out QuickFIX internals by inspecting the source.
I have global variables storing the Sender and Target CompID
values as strings, as well as the FIX4.X string -- can I just *build*
a FIX::SessionID on the fly in the routine and use it?  Or possibly
build it in the run application and pass it in every time to my
outgoing message routine?

> 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
>
>
>