Re: [Quickfix-developers] [Quickfix-developers]

[Joerg T. <Joe...@ma...>]

Oren Miller wrote:
> This is interesting.  I'll research this.  Do you know what version of 
> the spec this first appeared in?

Actually, this is from the FIX 4.2 spec, Administrative Messages, Reject 
(description of Reject message). This section has not been changed in 
FIX 4.3 or FIX 4.4.

The most noteworthy sentences here are:

 > 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 .

and

 > Logic should be included in
 > the FIX engine to recognize the possible infinite resend loop, which
 > may be encountered in this situation.

Cheers, Jörg


> On Apr 19, 2004, at 9:13 AM, Joerg Thoennes wrote:
> 
>> 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.
>>  [...]

-- 
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