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

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

  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 -----=20
  From: Alvin Wang=20
  To: Oren Miller=20
  Cc: Francis Gingras ; qui...@li... ; =
qui...@li...=20
  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.=20

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

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

  By "off" do you mean logged out or disabled?=20
   =20
  --oren=20
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Oren Miller=20
  Cc: Francis Gingras ; qui...@li... ; =
qui...@li...=20
  Sent: Friday, June 24, 2005 3:50 AM=20
  Subject: Re: [Quickfix-developers] How to check for dropped socket=20

  Oren,=20

  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.=20

  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?=20

  Thanks=20
  Alvin'=20

       "Oren Miller" <or...@qu...>=20
        06/23/2005 03:19 PM=20
              =20
               To:        "Francis Gingras" <fr...@at...>, =
"Alvin Wang" <AW...@FF...>=20
               cc:        <qui...@li...>, =
<qui...@li...>=20
               bcc:        =20
               Subject:        Re: [Quickfix-developers] How to check =
for dropped socket=20

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

  A related question:=20

  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)=20

  thanks=20
  Alvin=20

       Francis Gingras <fr...@at...>=20
        Sent by: qui...@li...=20
        06/23/2005 02:58 PM=20
              =20
              To:        qui...@li...=20
              cc:        =20
              bcc:        =20
              Subject:        [Quickfix-developers] How to check for =
dropped socket=20

  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=3D7477&alloc_id=3D16492&op=3Dclick
  _______________________________________________
  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. =
**********************************************************************=20