Re: [Quickfix-developers] How to check for dropped socket

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Oren,

thanks for your explanations. That makes more sense. 

One more question that I just want your clarification. If I send a message 
when the session is down, does QF guarantee that it will automatically 
push the message out next time QF re-logons? 

Thanks again
Alvin

"Oren Miller" <or...@qu...>
06/23/2005 04:04 PM

        To:     "Alvin Wang" <AW...@FF...>
        cc:     "Francis Gingras" <fr...@at...>, 
<qui...@li...>, 
<qui...@li...>
        bcc: 
        Subject:        Re: [Quickfix-developers] How to check for dropped socket

Well, if you only want to attempt to send when logged on, then you will 
probably just want to verify that the session is logged on before sending. 
 Very often sending on a logged off session is standard operating 
procedure and not really an exceptional case.  For instance if I'm 
implementing a server that is intended to send drop copies of executions, 
I'm not going to care whether the counterparty is logged on or not.  I 
just need to get them a copy of this execution and just need to know that 
QF will get it out there whenever it can.  If QuickFIX would consider this 
an exceptional case it would seem pretty odd.

FIX isn't transactional so I can never really expect to know that my 
message has been delivered.  Sure, we can sometimes know the negative case 
and prove that a message has not been delivered, but I can never know the 
positive case.  If the socket call is succesful, can I assume that the 
message was sent succesfully?  Not really.  The socket call was 
succesfull, but I have no validation that the message actually made it 
into the opposing FIX engine and trading sub-systems.  (An ExecutionReport 
can sort of tell me this.  But that is an acknowledgement that isn't 
defined at the session level and specific to just one type of message).

So what option do you have instead?  Well, you basically have to decide 
what your tolerance for latency is.  This is where the toApp callback 
comes into play.  Everything that QF tries to send passes through this 
callback first.  One of the fields you can check is the value of the 
SendingTime.

When the message passes through the first time, your current system time 
and your SendingTime should be the same or really damn close.  Good 
enough, let it through.  Now let's say that 300 milliseconds later it 
turns out the message never made it and you get a resend request.  What do 
you do?  Do you let it through or do you throw a DoNotSend exception 
because it's too late?  "Ahhhh." you say.  "The market hasn't changed and 
not so much time has passed, let's let it through!".  Again.  2 seconds 
later, you get the request again.  At this point you figure the order is 
not worthwhile sending anymore, you throw a DoNotSend exception, and you 
let the application know that you are killing the order.

So since FIX isn't transactional, you really need to think more about what 
your tolerance is for latency/shifting markets.  Make sense?

--oren

----- Original Message ----- 
From: Alvin Wang 
To: Oren Miller 
Cc: Francis Gingras ; qui...@li... ; qui...@li... 
Sent: Friday, June 24, 2005 3:56 AM
Subject: Re: [Quickfix-developers] How to check for dropped socket

I mean not logged on, but enabled. 

"Oren Miller" <or...@qu...> 
06/23/2005 03:40 PM 

        To:        "Alvin Wang" <AW...@FF...> 
        cc:        "Francis Gingras" <fr...@at...>, <qui...@li...>, <qui...@li...> 
        bcc:         
        Subject:        Re: [Quickfix-developers] How to check for dropped 
socket

By "off" do you mean logged out or disabled? 

--oren 
----- Original Message ----- 
From: Alvin Wang 
To: Oren Miller 
Cc: Francis Gingras ; qui...@li... ; qui...@li... 
Sent: Friday, June 24, 2005 3:50 AM 
Subject: Re: [Quickfix-developers] How to check for dropped socket 

Oren, 

Do you mean that if the session is off, the message will only be stored 
locally and the seq number will be increased? Next time the session is 
created, the counterparty will figure out the seq # does not match and 
therefore will ask for resend. 

If that is the case, that  makes sense. However, I feel not comfortable 
assuming the message has been pushed out without any warning or exception. 
Should program be notified if it tries to send a message when the session 
is off? 

Thanks 
Alvin' 

"Oren Miller" <or...@qu...> 
06/23/2005 03:19 PM 

       To:        "Francis Gingras" <fr...@at...>, "Alvin Wang" <AW...@FF...> 
       cc:        <qui...@li...>, 
<qui...@li...> 
       bcc:         
       Subject:        Re: [Quickfix-developers] How to check for dropped 
socket

And you never will know.  FIX is an asynchronous protocol.  There is no 
way for it to indicate the succesful receipt of a message.  That is why 
the sequence numbers are necessary.  Your SendToTarget is returning true 
because QuickFIX was able to store your message and take responsibility 
for sending it.  It may not be able to send it right away, but it will do 
so when required by a ResendRequest. 

--oren 
----- Original Message ----- 
From: Alvin Wang 
To: Francis Gingras 
Cc: qui...@li... ; qui...@li... 
Sent: Friday, June 24, 2005 3:20 AM 
Subject: Re: [Quickfix-developers] How to check for dropped socket 

A related question: 

It seems that I can use the static method Session.sendToTarget(Message, SessionID) successfully even when the corresponding session is not logged on. (I am 
not sure if the counterparty really receives the message in this case) 

thanks 
Alvin 

Francis Gingras <fr...@at...> 
Sent by: qui...@li... 
06/23/2005 02:58 PM 

      To:        qui...@li... 
      cc:         
      bcc:         
      Subject:        [Quickfix-developers] How to check for dropped 
socket

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

I am using the initiator and I'd like to know how I can check if the 
socket
was dropped. (i.e. if the connection was shut down by the acceptor side)

I figure I can use these properties but I'm not 100% sure what they mean:

session.isEnabled()
If the session exists, how can it not be enabled?

session.isLoggedOn()
socket.isLoggedOn()
Are they always the same and do they mean the same thing?

Thanks,

Francis Gingras

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 