1
$\begingroup$

I am using FIX4.3 and QuickFIX/n v1.0.0 for its implementation.

I came across a situation where i had subscribed for Market Data and was successfully receiving Snapshot message then suddenly all communication with the Market Session stopped and i didn't receive any more snapshot from the server on the Market Data Session.

When i asked the support they said that they didn't receive any heartbeat from my end so they closed the connection.

When i look at my FIX log files i see that time between my last heartbeat and the last snapshot from the server is under 60 seconds. And i didn't receive any logout message from the server either.

Also during all this time my Order Session stayed connected with proper heartbeat message.

My Questions are:

  1. What might have caused the system to not send out a Heartbeat message?

  2. Is it normal for the server to close connection on missing 1 heartbeat message? My understanding was that in case there is no heartbeat from the client, server will send a test request.

  3. Using QuickFIX/n how can i ensure my periodic heartbeat message?

  4. Whats the best time interval for heartbeat? (Mine is currently set to 60 seconds)

$\endgroup$
5
  • $\begingroup$ Your FIX logs indicate that you sent a heartbeat? Ask your counter-party for what FIX messages they've actually received from you. Your questions about ensuring QuickFIX sends the heartbeat are moot until you establish whether the counter-party actually received the messages your log files indicate. $\endgroup$ Aug 16, 2012 at 13:40
  • $\begingroup$ Yes, my FIX logs indicate that i sent a heartbeat and the counter-party also confirms all the heartbeat messages that my FIX log file indicates. $\endgroup$ Aug 16, 2012 at 17:15
  • $\begingroup$ So the counter-party actually got the heartbeat and still disconnected you? That's a problem on their end. $\endgroup$ Aug 16, 2012 at 17:27
  • $\begingroup$ You must also check the sequence numbers. If the sequence number you send does not match with what your counter party expects, you will also get D/C'ed. $\endgroup$
    – czchlong
    Aug 17, 2012 at 13:33
  • $\begingroup$ i talked to the counter party again and they said that before they disconnected they sent a test request and got no response from my end so they disconnected. I talked with the QuickFIX/n development team and they suggested i should move onto the latest QuickFIX/n build v1.2.0 and said that this one might be issue #57, which is fixed in v1.2.0. $\endgroup$ Aug 17, 2012 at 18:26

1 Answer 1

1
$\begingroup$

Taking the information given in your question and subsequent follow up, I believe the following is the issue at hand:

The heart beats you send out are good practice but are irrelevant in regards to your specific problem. It looks like your brokers sends out periodic "heart beats" (= test requests) on its own and if your application does not respond then it disconnects. I would not entirely rely on the specific Fix version (build) but rather inquire with the broker what specific message is sent through FIX and what they expect back to keep you alive. You most likely need to reply with a message to acknowledge the "test request". That most likely will solve your problem.

Regarding your other questions:

1) You answered that yourself, you actually sent out the heartbeats and the broker received them, thus no problems here.

2) ...which the server did (sending out a test request). Make sure you understand there is a difference between you sending out heart beats and the broker sending out his own heartbeats.

3) See 1) no problem there, you sent them out, they were received

4) It entirely depends on your trading frequency. Obviously before sending out FIX messages you want to make sure the connection is alive, other than that if you trade high frequency 60 seconds is way too infrequent. If your trade frequency is a lot lower then 60 seconds may be sufficient.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.