Re: [Quickfix-developers] How to check for dropped socket
Brought to you by:
orenmnero
|
From: Alvin W. <AW...@FF...> - 2005-06-23 20:57:48
|
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.
**********************************************************************
|