Re: [Quickfix-developers] Socket Monitoring/Verification

[Oren M. <or...@qu...>]

Unfortunately this just isn't possible.  The Socket implementations  
uses non-blocking sockets.  When the SendToTarget call returns,  
QuickFIX just doesn't know whether or not the message has been  
successfully sent or not.  Blocking sockets solve that problem (as we  
used to use), but causes much worse problems in the form of  
deadlocks.  So really we are conveying to you as much information as  
we have.  When true is returned, we have persisted the message  
(guaranteed) and sent it on the socket (perhaps successfully, perhaps  
not, we do not know at this point) .  This is all we know and all we  
can return to you.

On Mar 25, 2007, at 1:49 PM, Djalma Rosa dos Santos Filho wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> 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