HeartBtInt negative values

, ,
1

Imported from previous forum

2

This may be a stupid question, but the HeartBtInt (108) is defined as an integer, and in my Fast template I define it as , what is to prevent a client from sending a negative heartbeat value? If he does what is the proper action to take?

Thanks,
C. Helck

3

If he does, then do a session level reject (35=3) and send a test request immediately

Regards
Sunil Singh

4

Sunil,

Ok I send a sessin level reject

35 = MsgType =3 with

373 = SessionRejectReason = 5 = Value is incorrect (out of range) for this tag

45 = RefSeqNum = MsgSeqNum of rejected message

371 = RefTagID = The tag number of the FIX field being referenced = 108

58 = Text = message to explain reason for rejection = “Tag needs postive value more than 30 seconds”

but as HeartBeat interval is part of Logon message, how is a Test Request immediately following the Rejected Logon going to work because the session itself is not existing in the counterparty system? If I were your counterparty, why would my FIX engine reply to your Test request? HeartBeat is always set by the Session initiator, which is the Buy side, so when Session initiator sends invalid value in the Session initiation / Logon message the Session Acceptor does not yet have a valid Session to talk to.

Am I correct in my reasoning?

Regards,
K. Mahesh

If he does, then do a session level reject (35=3) and send a test
request immediately

Regards Sunil Singh

5

Mahesh,

You are correct in your reasoning. I assumed the negative value for tag 108 coming with a heartbeat message (35=0) rather than with a logon message.

Cheers
Sunil

6

This may be a stupid question, but the HeartBtInt (108) is defined as an
integer, and in my Fast template I define it as , what is to
prevent a client from sending a negative heartbeat value? If he does
what is the proper action to take?

Thanks,
C. Helck

Helck,

[Quote from “FIX Session-level Test Cases and Expected Behaviors” of FIX_Transport_1.1.pdf Version 1.1 FIX Session Protocol Page 28 of 58]

When to send a Logout vs. when to just disconnect

In general a Logout message should always be sent prior to shutting down a connection. If the Logout is being sent due to an error condition, the Text field of the Logout should provide a descriptive reason, so that operational support of the remote FIX system can diagnosis the problem. There are exceptions, when it is recommended that a Logout message not be sent, these include:

• If during a logon either the SenderCompID, TargetCompID or IP address of the session initiator is invalid, it is recommended that the session be immediately terminated and no Logout message sent. This login attempt might be an unauthorized attempt to break into your system; hence one does not want to divulge any information about one’s FIX system, such as: which SenderCompID/TargetCompID values are valid or which version of FIX is supported.

• If during a Logon one receives a second connection attempt while a valid FIX session is already underway for that same SenderCompID, it is recommended that the session acceptor immediately terminate the second connection attempt and not send a Logout message. Sending a Logout message runs the risk of interfering with and possibly adversely affecting the current active FIX connection. For example, in some FIX system implementations, sending a Logout message might consume a sequence number that would cause an out of sequence condition for the established FIX session.

In all other cases, if sending a Logout does not create risk or violate security, a Logout message should be sent with a descriptive text message.

[End Quote]

You can download the FIXT.1.1 specs at

http://fixprotocol.org/fixt1.1spec