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

[Oren M. <or...@qu...>]

This is interesting.  I'll research this.  Do you know what version of=20=

the spec this first appeared in?

--oren

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

> 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=3D&) 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=3DY.
>
> According to this, a SessionReject should be generated in every=20
> possible case. IMHO, the description "any message that is garbled,=20
> cannot be parsed or fails a data integrity check" should should been=20=

> seen as narrow as possible. If cannot even identify the sequence=20
> number, you cannot do much about it, but if you have a complete=20
> message where only one field is badly formatted, a session-level=20
> reject is much more helpful.
>
> This is basically the same as for the Logout, which should be send if=20=

> 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.=20
> Currently some messages or connection attempts are silently ignored. A=20=

> message of the style "Disconnected since sequence number nnn too low"=20=

> is an example of that.
>
> Cheers, J=F6rg
>
> --=20
> 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
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>