Oren Miller wrote:
> Yeah, if a message fails basic validation, you will get infinite
> resend requests. There isn't much that you can do about this. If a
> message fails validation, the protocol says that the message must be
> ignored. Meaning to treat it like it never happened. So of course
> sequence numbers do not get incremented. FIX is designed to process
> all messages in the correct order. Passing over a message and going
> to the next one would violate this. Rejects really should only occur
> during testing. If you ever see a session level reject during
> production, you should re-certify with your counter-party. It
> basically means your connection is broken and needs to be addressed.
Hi Oren,
we had several issues with such Resend-loops due to invalid message. Our
customer quoted the following lines from the FIX spec:
> Reject (session-level) -The reject message should be issued when a
> message is received but cannot be properly processed due to a
> session-level rule violation. An example of when a reject may be
> appropriate would be the receipt of a message with invalid basic data
> (e.g. MsgType=&) which successfully passes de-encryption, CheckSum
> and BodyLength checks . As a rule, messages should be forwarded to
> the trading application for business level rejections whenever
> possible.
>
> Rejected messages should be logged and the incoming sequence number
> incremented.
>
> Note: The receiving application should disregard any message that is
> garbled, cannot be parsed or fails a data integrity check. 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 .
>
> Generation and receipt of a Reject message indicates a serious error
> that may be the result of faulty logic in either the sending or
> receiving application.
>
> If the sending application chooses to retransmit the rejected
> message, it should be assigned a new sequence number and sent with
> PossResend=Y.
According to this, a SessionReject should be generated in every possible
case. IMHO, the description "any message that is garbled, cannot be
parsed or fails a data integrity check" should should been seen as
narrow as possible. If cannot even identify the sequence number, you
cannot do much about it, but if you have a complete message where only
one field is badly formatted, a session-level reject is much more helpful.
This is basically the same as for the Logout, which should be send if
every possible case. The QF 1.4.1 will do that, and that is very good.
In addition, a more detailed event log would be very helpful. Currently
some messages or connection attempts are silently ignored. A message of
the style "Disconnected since sequence number nnn too low" is an example
of that.
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
