Imported from previous forum
[ original email was from George Jones - gjones@financialfusion.com ]
Hello,
I have been looking at the FIX 4.3 specification, and I have some questions about the list of test cases that appear at the end of section 2. I realize that the tests and their expected behaviors are, for the most part, derived from the various sections of the spec. However, in some cases the expected behavior for a test seems to appear only in the tests section, and is not documented elsewhere in the spec. In these cases, if a FIX engine does not adhere to the expected behavior, is it in violation of the spec, or is the behavior merely suggested?
Here are some specific cases where I have questions:
Test 2f: PossDupFlag set to Y; OrigSendingTime > SendingTime and MsgSeqNum as expected
The expected behavior in this case is to send a Reject message with "Inaccurate SendingTime" in the SessionRejectReason. However, I can find no requirement in the rest of the specification that says that requires OrigSendingTime <= SendingTime. Granted that this is implied by the definition of the OrigSendingTime field.
Test 2k: SenderCompID and TargetCompID values received did not match values expected and specified in testing profile.
The expected behavior here is to send a Reject message with "CompID problem" as the SessionRejectReason. Aside from the Logon message, I cannot find anything in the specification that indicates that the message should be rejected. Is it the case that for a connected session, all messages on that session are REQUIRED to have the same CompID fields? That is what this test seems to be implying.
Test 2o: SendingTime value received is either not specified in UTC or is not within a reasonable time (i.e. 2 minutes) of atomic clock-based time.
The test then lists the rational as being: Verify system clocks on both sides are in sync and that SendingTime must be current time.
The expected behavior says to send a Reject message with SessionRejectReason of "Sending Time accuracy problem". In this case the "2 minute" rule appears only in this test. Are all FIX engines REQUIRED to implement a "reasonable time" rule, and send Rejects if the "reasonable time" has passed? If so, is 2 minutes the only "reasonable time" allowed, or is the "reasonable time" implementation dependant?
Test 6: Send a TestRequest when no data is received during preset heartbeat interval (HeartBeatInt field) + "some reasonable period of time" (use 20% of HeartBeatInt field)
In the specification description of the HeartBeat message in the "Administrative Messages" section, the spec says to send a TestRequest message after (HeartBeatInt + x) seconds have passed, where x is "some reasonable transmission time". The test seems to define x as "some reasonable period of time", but then seems to require that x be "20% of HeartBeatInt". Is x REQUIRED to be 20% of HeartBeatInt, or is it "some reasonable period of time" that can be implementation defined?
In the case where the tests seem to be introducing new behaviors, should these be treated as applying to only FIX 4.3 and above, or should they apply to all of FIX 4.x? The tests explicitly state that the behavior is for all FIX 4.x, but they only first appear in FIX 4.3.
Any comments from the experts would be much appreciated.
Thanks,
George Jones
Financial Fusion, Inc.
gjones@financialfusion.com
George, you ask some good questions. I think the best way to respond is to provide some background on origin of the test cases. They were originally developed as the test cases or spec against which a FIX certification service would be implemented and would validate other FIX implementations. As a result some more arbitrary values such as “how long is a ‘reasonable time’ for system clock variance?” needed a specific rule.
The Global Technical Committee belived then (several years ago) and continues to believe that the test cases in that document (standalone within "FPL Organization", "Global Tech Committee" and now part of Volume 2 in the spec) represent a good minimum set of rules for the FIX session layer. You should expect them to be the basis for any FPL-sanctioned FIX Certification of the session layer. Thus, for example, if your FIX session transmitted SendingTime values which are more than 2 minutes off of the atomic clock it would not pass "Test 2o".
Users of the FIX Protocol can bilaterally agree to require and enforce more stringent rules. For example, timestamps can be no more than 5 seconds "off".
Specifics:
2f: The key to this test case is to make sure that a FIX implementation is providing a legitimate SendingTime in response to Resend Request as some implementations were found to populate SendingTime with "the original or old" time vs. current time.
2k: Yes, SenderCompID and TargetCompID (from the perspective of a single direction) should not change on each message.
2o: The key is to make sure that clocks are reasonably accurate and to ensure that the timestamps provided are in UTC vs. one’s local timezone. From practical experience, it’s a big problem if I process Exec Reports which are say an hour off. I would recommend that a FIX engine implements some sort of validation of time rule (could be customizable).
6: 20% was an arbitrary “stake in the ground”. The key to this test is to make sure that one doesn’t get into a “thrashing” situation in which every 30 seconds I send a heartbeat but the other side at exactly 30 second expiration sends me a Test Request. The other key is to make sure that the other side does in fact send a Test Request at some point in time after having not received any messages.
> Hello,
>
> I have been looking at the FIX 4.3 specification, and I have some questions about the list of test cases that appear at the end of section 2. I realize that the tests and their expected behaviors are, for the most part, derived from the various sections of the spec. However, in some cases the expected behavior for a test seems to appear only in the tests section, and is not documented elsewhere in the spec. In these cases, if a FIX engine does not adhere to the expected behavior, is it in violation of the spec, or is the behavior merely suggested?
>
> Here are some specific cases where I have questions:
>
> Test 2f: PossDupFlag set to Y; OrigSendingTime > SendingTime and MsgSeqNum as expected
> The expected behavior in this case is to send a Reject message with "Inaccurate SendingTime" in the SessionRejectReason. However, I can find no requirement in the rest of the specification that says that requires OrigSendingTime <= SendingTime. Granted that this is implied by the definition of the OrigSendingTime field.
>
> Test 2k: SenderCompID and TargetCompID values received did not match values expected and specified in testing profile.
> The expected behavior here is to send a Reject message with "CompID problem" as the SessionRejectReason. Aside from the Logon message, I cannot find anything in the specification that indicates that the message should be rejected. Is it the case that for a connected session, all messages on that session are REQUIRED to have the same CompID fields? That is what this test seems to be implying.
>
> Test 2o: SendingTime value received is either not specified in UTC or is not within a reasonable time (i.e. 2 minutes) of atomic clock-based time.
> The test then lists the rational as being: Verify system clocks on both sides are in sync and that SendingTime must be current time.
> The expected behavior says to send a Reject message with SessionRejectReason of "Sending Time accuracy problem". In this case the "2 minute" rule appears only in this test. Are all FIX engines REQUIRED to implement a "reasonable time" rule, and send Rejects if the "reasonable time" has passed? If so, is 2 minutes the only "reasonable time" allowed, or is the "reasonable time" implementation dependant?
>
> Test 6: Send a TestRequest when no data is received during preset heartbeat interval (HeartBeatInt field) + "some reasonable period of time" (use 20% of HeartBeatInt field)
> In the specification description of the HeartBeat message in the "Administrative Messages" section, the spec says to send a TestRequest message after (HeartBeatInt + x) seconds have passed, where x is "some reasonable transmission time". The test seems to define x as "some reasonable period of time", but then seems to require that x be "20% of HeartBeatInt". Is x REQUIRED to be 20% of HeartBeatInt, or is it "some reasonable period of time" that can be implementation defined?
>
> In the case where the tests seem to be introducing new behaviors, should these be treated as applying to only FIX 4.3 and above, or should they apply to all of FIX 4.x? The tests explicitly state that the behavior is for all FIX 4.x, but they only first appear in FIX 4.3.
>
> Any comments from the experts would be much appreciated.
>
> Thanks,
>
> George Jones
> Financial Fusion, Inc.
> gjones@financialfusion.com
>
>