[This message was posted by Mahesh Kumaraguru of <kay_mah...@yahoo.com> to the "4.0 Session" discussion forum at http://fixprotocol.org/discuss/12. You can reply to it on-line at http://fixprotocol.org/discuss/read/a022ccc4 - PLEASE DO NOT REPLY BY MAIL.]
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 [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org]
-- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
