Imported from previous forum
As per specs,
“When either end of the connection has not received any data for (HeartBtInt + “some reasonable transmission time”) seconds, it will transmit a Test Request message”.
Does “data” here would refer to a valid FIX message or any data (even junk data means link is alive!)?
As per specs, “When either end of the connection has not received any
data for (HeartBtInt + “some reasonable transmission time”) seconds, it
will transmit a Test Request message”.Does “data” here would refer to a valid FIX message or any data (even
junk data means link is alive!)?
Hi Nick,
I would say you should always play it safe and assume that the receipt of anything other than a well-formed FIX message indicates a fatal error for the session. Consider the challenge of parsing a new message from the stream after you have received garbage over it - FIX supports encoded length fields and other types of content that cannot be parsed correctly without knowing their length before you start the parsing operation. Once you receive “junk” over the wire, you can’t really be sure of anything else you parse from that point forward…
Cheers,
Russ
Nick,
[Start Quote from FIX.4.0 spec page 14]
When a message is received which is garbled, cannot be parsed or fails a data integrity check, the receiving application should disregard the message. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop which may be encountered in this situation.
[End Quote from FIX.4.0 spec]
This can be restated as “When a sequence of bytes are received which does not constitute a valid FIX message discard the bytes”
FIXT.1.1 spec elaborates this with more detail.
[Start Quote from FIXT.1.1 spec page 37 and 38]
The FIX Protocol takes the optimistic view; it presumes that a garbled message is received due to a transmission error rather than a FIX system problem. Therefore, if a Resend Request is sent the garbled message will be retransmitted correctly. If a message is not considered garbled then it is recommended that a session level Reject message be sent.
What constitutes a garbled message
-
BeginString (tag #8) is not the first tag in a message or is not of the format 8=FIXT.n.m.
-
BodyLength (tag #9) is not the second tag in a message or does not contain the correct byte count.
-
MsgType (tag #35) is not the third tag in a message.
-
Checksum (tag #10) is not the last tag or contains an incorrect value.
If the MsgSeqNum(tag #34) is missing a logout message should be sent terminating the FIX Connection, as this indicates a serious application error that is likely only circumvented by software modification.
[End Quote from FIXT.1.1 spec]
So if your FIX Engine does not receive a valid FIX message from your counterparty for HeartBeat interval + some reasonable transmission time, send a TestRequest. Your counterparty should reply with a HeartBeat, check the sequence number of the Heartbeat message to see if you have missed any messages, if yes, then send a Resend Request.
“Junk data” cannot be used as an indication the FIX session is alive, during periods of Business message inactivity Heartbeat messages are used to indicate the Session is alive.
As per specs, “When either end of the connection has not received any
data for (HeartBtInt + “some reasonable transmission time”) seconds,
it will transmit a Test Request message”.Does “data” here would refer to a valid FIX message or any data (even
junk data means link is alive!)?Hi Nick,
I would say you should always play it safe and assume that the receipt
of anything other than a well-formed FIX message indicates a fatal error
for the session. Consider the challenge of parsing a new message from
the stream after you have received garbage over it - FIX supports
encoded length fields and other types of content that cannot be parsed
correctly without knowing their length before you start the parsing
operation. Once you receive “junk” over the wire, you can’t really be
sure of anything else you parse from that point forward…Cheers,
Russ