RE: [Quickfix-developers] [Quickfix-developers]

[James C. D. <jc...@co...>]

I am planning on creating an acceptance test to describe this. In this =
case
QF would issue a session level reject and increment the expected =
incoming
sequence number.

=20


Jim
=20
James C. Downs
Connamara Systems, LLC
53 W. Jackson Blvd
Suite 1627
Chicago, IL 60604
312 - 282 - 7746
www.connamara.com

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of =
Joerg
Thoennes
Sent: Tuesday, April 20, 2004 5:03 AM
To: Oren Miller
Cc: Angela Metallo; qui...@li...
Subject: Re: [Quickfix-developers] [Quickfix-developers]

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=3D&) 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=F6rg


> On Apr 19, 2004, at 9:13 AM, Joerg Thoennes wrote:
>=20
>> Oren Miller wrote:
>>
>>> Yeah, if a message fails basic validation, you will get infinite=20
>>> resend requests.  There isn't much that you can do about this. If a=20
>>> message fails validation, the protocol says that the message must be =

>>> ignored. Meaning to treat it like it never happened.  So of course=20
>>> 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=20
>>> production, you should re-certify with your counter-party.  It=20
>>> 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=20
>>> message is received but cannot be properly processed due to a=20
>>> session-level rule violation. An example of when a reject may be=20
>>> appropriate would be the receipt of a message with invalid basic=20
>>> data (e.g. MsgType=3D&) which successfully passes de-encryption,=20
>>> CheckSum and BodyLength checks . As a rule, messages should be=20
>>> forwarded to the trading application for business level rejections=20
>>> whenever possible.
>>> Rejected messages should be logged and the incoming sequence number=20
>>> incremented.
>>> Note: The receiving application should disregard any message that is =

>>> garbled, cannot be parsed or fails a data integrity check.=20
>>> Processing of the next valid FIX message will cause detection of a=20
>>> 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=20
>>> receiving application.
>>> If the sending application chooses to retransmit the rejected=20
>>> message, it should be assigned a new sequence number and sent with=20
>>> 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.
>>  [...]

--
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=3Dcli=
ck
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers