quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Possible Rounding Errors

[Jody H. <jod...@at...>]

On Tue, 27 Apr 2004 15:08:22 -0500
Oren Miller <or...@qu...> wrote:

> Here is what the FIX spec says:
> 
> float:  Sequence of digits with optional decimal point and sign 
> character (ASCII characters "", "0" - "9" and ".");  the absence of
> the decimal point within the string will be interpreted as  the float 
> representation of an integer value.  All float fields must accommodate
> 
> up to fifteen  significant digits. The number of decimal places used 
> should be a factor of business/market  needs and mutual agreement 
> between counterparties. Note that float values may contain  leading 
> zeros (e.g. _00023.23_ = _23.23_) and may contain or omit trailing 
> zeros after the  decimal point (e.g. _23.0_ = _23.0000_ = _23_ = 
> "23.").


Thanks, Oren.  Does "fifteen significant digits" mean 15 digits in
total, or after the decimal point?  If the latter, then the example
submitted should be parsed correctly since it has exactly 15 digits
after the decimal (I'd even wager that the example comes from someone
reading the spec and specifically using 15 digits).  Unless exactly
specified, there is always confusion over the scientific meaning of
"significant digits" and the practical interpretation...

Re: [Quickfix-developers] Possible Rounding Errors

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

They may be using long doubles then.  They can contain 19 significant=20
digits.  But yeah, it looks like it violates the spec.  The question is=20=

what to do when this happens.  Should we reject or allow it, or set it=20=

in the configuration file.

On Apr 27, 2004, at 3:09 PM, James C. Downs wrote:

> The FIX spec states that the float data type should have 15=20
> significant digits
>  250.300000000000010 has 18
> =A0
> I just did a quick test using this price and QF will reject it.
> =A0
> Jim
> =A0
> James C. Downs
> Connamara Systems, LLC
> 53 W. Jackson Blvd
> Suite 1627
> Chicago, IL 60604
> 312 - 282 - 7746
> www.connamara.com
> =A0
>
>
> From: qui...@li...=20
> [mailto:qui...@li...] On Behalf Of=20=

> Oren Miller
> Sent: Tuesday, April 27, 2004 2:29 PM
> To: Patrick Flannery
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] Possible Rounding Errors
>
> Looking at this more closely, we have several tests that have trailing=20=

> zeros, and this works fine. It looks like there are just too many=20
> significant digits. Are they running on a 64 bit architecture? I think=20=

> the only thing you can do right now is to change the type to a STRING=20=

> in the data dictionary. The alternative is to comment out the=20
> validation code for doubles.
>
> --oren
>
> On Apr 26, 2004, at 8:23 AM, Patrick Flannery wrote:
>
>
> Oren,
>
> I am using quick Fix 4.2 version 1.7.=A0 We are receiving execution=20
> reports with AvgPrice and Last Price values to the effect of
>
> 250.300000000000010.=A0 QucikFix generates a reject message referring =
to=20
> the AvgPrice field of the execution report.=A0 Would quick fix =
generate=20
> a reject for the aforementioned value?=A0 What can be done about it?=A0=20=

> Thank you in advance for your time.=A0 Patrick
>
> =A0
>
> This email message is intended only for the addressee(s) and contains=20=

> information that may be confidential and/or
>  copyright.=A0 If you are not the intended recipient please notify the=20=

> sender by reply email and immediately delete
>  this email. Use, disclosure or reproduction of this email by anyone=20=

> other than the intended recipient(s) is strictly
>  prohibited. No representation is made that this email or any=20
> attachments are free of viruses. Virus scanning is
>  recommended and is the responsibility of the recipient.
>
> Thank you.
>
> For more information on CTC, LLC please visit our website at=20
> http://www.chicagotrading.com.
>
>
> =A0

RE: [Quickfix-developers] Possible Rounding Errors

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

The FIX spec states that the float data type should have 15 significant
digits 
250.300000000000010 has 18
 
I just did a quick test using this price and QF will reject it.
 
Jim
 
James C. Downs
Connamara Systems, LLC
53 W. Jackson Blvd
Suite 1627
Chicago, IL 60604
312 - 282 - 7746
www.connamara.com
 

  _____  

From: qui...@li...
[mailto:qui...@li...] On Behalf Of Oren
Miller
Sent: Tuesday, April 27, 2004 2:29 PM
To: Patrick Flannery
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Possible Rounding Errors


Looking at this more closely, we have several tests that have trailing
zeros, and this works fine. It looks like there are just too many
significant digits. Are they running on a 64 bit architecture? I think the
only thing you can do right now is to change the type to a STRING in the
data dictionary. The alternative is to comment out the validation code for
doubles.

--oren

On Apr 26, 2004, at 8:23 AM, Patrick Flannery wrote:



Oren,

I am using quick Fix 4.2 version 1.7.  We are receiving execution reports
with AvgPrice and Last Price values to the effect of

250.300000000000010.  QucikFix generates a reject message referring to the
AvgPrice field of the execution report.  Would quick fix generate a reject
for the aforementioned value?  What can be done about it?  Thank you in
advance for your time.  Patrick

 

This email message is intended only for the addressee(s) and contains
information that may be confidential and/or 
copyright.  If you are not the intended recipient please notify the sender
by reply email and immediately delete 
this email. Use, disclosure or reproduction of this email by anyone other
than the intended recipient(s) is strictly 
prohibited. No representation is made that this email or any attachments are
free of viruses. Virus scanning is 
recommended and is the responsibility of the recipient.

Thank you.

For more information on CTC, LLC please visit our website at
http://www.chicagotrading.com.


 

Re: [Quickfix-developers] Possible Rounding Errors

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

Here is what the FIX spec says:

float:  Sequence of digits with optional decimal point and sign=20
character (ASCII characters "", "0" - "9" and ".");  the absence of the=20=

decimal point within the string will be interpreted as  the float=20
representation of an integer value.  All float fields must accommodate=20=

up to fifteen  significant digits. The number of decimal places used=20
should be a factor of business/market  needs and mutual agreement=20
between counterparties. Note that float values may contain  leading=20
zeros (e.g. =9300023.23=94 =3D =9323.23=94) and may contain or omit =
trailing=20
zeros after the  decimal point (e.g. =9323.0=94 =3D =9323.0000=94 =3D =
=9323=94 =3D=20
"23.").

On Apr 27, 2004, at 2:57 PM, Jody Hagins wrote:

> On Tue, 27 Apr 2004 14:28:40 -0500
> Oren Miller <or...@qu...> wrote:
>
>> Looking at this more closely, we have several tests that have =
trailing
>>
>> zeros, and this works fine.  It looks like there are just too many
>> significant digits.  Are they running on a 64 bit architecture?  I
>> think the only thing you can do right now is to change the type to a
>> STRING in the data dictionary.  The alternative is to comment out the
>> validation code for doubles.
>
> I doubt a 64 bit architecture is to blame.  More than likely, a
> printf("%.15f"), or setting a large precision in an ostream, or
> something similar.  The code to process doubles could be a *little*=20
> more
> understanding, by using the standard limits to truncate the value to=20=

> the
> number of digits that can be represented on that hardware.  In the =
case
> of a double, I'd think that would be better than rejecting the value.
> By definition, you can not throw around floating point values and=20
> expect
> to get the exact same value on different machines.
>
> That said, is there anything in the FIX spec that dictates precision =
of
> price values to something like 6 or 8 decimal places?
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=3D12297
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Possible Rounding Errors

[Jody H. <jod...@at...>]

On Tue, 27 Apr 2004 14:28:40 -0500
Oren Miller <or...@qu...> wrote:

> Looking at this more closely, we have several tests that have trailing
> 
> zeros, and this works fine.  It looks like there are just too many 
> significant digits.  Are they running on a 64 bit architecture?  I 
> think the only thing you can do right now is to change the type to a 
> STRING in the data dictionary.  The alternative is to comment out the 
> validation code for doubles.

I doubt a 64 bit architecture is to blame.  More than likely, a
printf("%.15f"), or setting a large precision in an ostream, or
something similar.  The code to process doubles could be a *little* more
understanding, by using the standard limits to truncate the value to the
number of digits that can be represented on that hardware.  In the case
of a double, I'd think that would be better than rejecting the value. 
By definition, you can not throw around floating point values and expect
to get the exact same value on different machines.

That said, is there anything in the FIX spec that dictates precision of
price values to something like 6 or 8 decimal places?

RE: [Quickfix-developers] Resend Request not sent

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

I think this existing test covers it.

1a_ValidLogonMsgSeqNumTooHigh.def

# if the message sequence number is too high, respond with logon and =
send
# resend request

iCONNECT
I8=3DFIX.4.0=0135=3DA=0134=3D5=0149=3DTW=0152=3D<TIME>=0156=3DISLD=0198=3D=
0=01108=3D30=01
E8=3DFIX.4.0=019=3D57=0135=3DA=0134=3D1=0149=3DISLD=0152=3D00000000-00:00=
:00=0156=3DTW=0198=3D0=01108=3D30=0110=3D
0=01
E8=3DFIX.4.0=019=3D59=0135=3D2=0134=3D2=0149=3DISLD=0152=3D00000000-00:00=
:00=0156=3DTW=017=3D1=0116=3D999999=011
0=3D0=01

# logout message and response
I8=3DFIX.4.0=0135=3D5=0134=3D6=0149=3DTW=0152=3D<TIME>=0156=3DISLD=01
E8=3DFIX.4.0=019=3D45=0135=3D5=0134=3D3=0149=3DISLD=0152=3D00000000-00:00=
:00=0156=3DTW=0110=3D0=01
eDISCONNECT=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: Oren Miller [mailto:or...@qu...]=20
Sent: Tuesday, April 27, 2004 2:34 PM
To: Howard S. Engelhart
Cc: QuickFIX Questions ((E-mail)); James C. Downs
Subject: Re: [Quickfix-developers] Resend Request not sent

Doesn't sound like the correct behavior.  Jim, I believe we have a test =
case
for this scenario.  Can you take a look at it?

--oren

On Apr 27, 2004, at 7:18 AM, Howard S. Engelhart wrote:

> Using QuickFIX 1.7 with a 4.0 Session..
>
> When my engine, acting as an acceptor receives a Logon Request with a=20
> higher than expected sequence number (got 5 expected 1), rather than=20
> accepting the logon and sending a Resend Request to fill the gap,=20
> quickfix appears to simply disconnect the socket.
>
> Is this correct behavior?  From perusing the FIX 4.0 spec it seems=20
> like accepting the logon and sending the Resend Request would be the=20
> correct thing to do?
>
> Thanks,
>
> Howard
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek=20
> For a limited time only, get FREE Ground shipping on all orders of $35 =

> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Possible Rounding Errors

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

Looking at this more closely, we have several tests that have trailing=20=

zeros, and this works fine.  It looks like there are just too many=20
significant digits.  Are they running on a 64 bit architecture?  I=20
think the only thing you can do right now is to change the type to a=20
STRING in the data dictionary.  The alternative is to comment out the=20
validation code for doubles.

--oren

On Apr 26, 2004, at 8:23 AM, Patrick Flannery wrote:

> Oren,
>
> I am using quick Fix 4.2 version 1.7.=A0 We are receiving execution=20
> reports with AvgPrice and Last Price values to the effect of
>
>  250.300000000000010.=A0 QucikFix generates a reject message referring=20=

> to the AvgPrice field of the execution report.=A0 Would quick fix=20
> generate a reject for the aforementioned value?=A0 What can be done=20
> about it?=A0 Thank you in advance for your time.=A0 Patrick
>
>  =A0
>
> This email message is intended only for the addressee(s) and contains=20=

> information that may be confidential and/or
> copyright.=A0 If you are not the intended recipient please notify the=20=

> sender by reply email and immediately delete
> this email. Use, disclosure or reproduction of this email by anyone=20
> other than the intended recipient(s) is strictly
> prohibited. No representation is made that this email or any=20
> attachments are free of viruses. Virus scanning is
> recommended and is the responsibility of the recipient.
>
> Thank you.
>
> For more information on CTC, LLC please visit our website at=20
> http://www.chicagotrading.com.
>
>
> =A0

RE: [Quickfix-developers] Resync problems ... Infinite Resend

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

Angela,
Thanks. We will take a look at this and create a test.
I'll let you know the results. 


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

-----Original Message-----
From: Angela Metallo [mailto:A.M...@it...] 
Sent: Tuesday, April 27, 2004 10:55 AM
To: James C. Downs; Oren Miller
Cc: qui...@li...
Subject: RE: [Quickfix-developers] Resync problems ... Infinite Resend

Jim I send you the three files generated by QuickFix, I used the 1.6.0
version for both FixEngine (Initiator and Acceptor).
You can find the infinite resed request starting by this time:
20040414-08:09:07.087.

For the second case I had the infinite resend I'll check for the log, but
I'm not sure to have them, anyway the reason is the store of the logon
message in the QuickFix queue that generate the infinite resend. About that
I sent the patch I used to resolve the problem.

Thank you

Angela



-----Original Message-----
From: James C. Downs [mailto:jc...@co...]
Sent: Tuesday, April 27, 2004 15:53
To: Angela Metallo; 'Oren Miller'
Cc: qui...@li...
Subject: RE: [Quickfix-developers] Resync problems ... Infinite Resend


Angela,
Could you repost the a sample from a log file that shows the Infinite Resend
issue caused by a session reject. I have tried to create a test but the test
did not fail! I would like to create a test that exactly models your inputs
and expected results.

Thanks,


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

RE: [Quickfix-developers] Resync problems ... Infinite Resend

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

Angela,
Could you repost the a sample from a log file that shows the Infinite Resend
issue caused by a session reject. I have tried to create a test but the test
did not fail! I would like to create a test that exactly models your inputs
and expected results.

Thanks,


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

RE: [Quickfix-developers] development time and cost

[Brian E. <Br...@ma...>]

It took me one month to develop a C++ OMS and a VB6 GUI.  I also =
created a venue simulator for testing.  Both the OMS & venue simulator =
incorporate the QuickFIX engine.  By first getting everything working =
with an internal simulator, it made it easier to connect to our 'real' =
FIX venues.

All my business logic was included in the OMS at the source code level. =
 I already had an in-memory database which I incorporated into the OMS, =
so very little had to be done on the DB side.

I'm still using QF 1.6.  Everything is working and stable so I'm =
hesitant to upgrade to QF 1.7.

Brian

-----Original Message-----
From: Won Lee [mailto:sci...@ya...]
Sent: Monday, April 26, 2004 5:26 PM
To: qui...@li...
Subject: [Quickfix-developers] development time and cost


Hello,

For those of you that have incorporated QuickFIX into
your firm's program trading activities, how long did
it take you to roll out a complete trading platform?

I'm assuming that a) the FIX engine was QuickFIX, b)
custom middle layer to handle all business logic, c)
custom developed GUI for traders to interact with, d)
written all in JAVA, and e) any and all DB work that
needed to be done.=20

What is a realistic time frame?=20




=09
	=09
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25=A2
http://photos.yahoo.com/ph/print_splash


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=3D12297
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] RE: Resend Request not sent

[Howard S. E. <ho...@ex...>]

Correction:  QuickFIX version =3D 1.6

-----Original Message-----
From: Howard S. Engelhart=20
Sent: Tuesday, April 27, 2004 8:19 AM
To: QuickFIX Questions (E-mail)
Subject: Resend Request not sent=20


Using QuickFIX 1.7 with a 4.0 Session..

When my engine, acting as an acceptor receives a Logon Request with a =
higher than expected sequence number (got 5 expected 1), rather than =
accepting the logon and sending a Resend Request to fill the gap, =
quickfix appears to simply disconnect the socket. =20

Is this correct behavior?  From perusing the FIX 4.0 spec it seems like =
accepting the logon and sending the Resend Request would be the correct =
thing to do?

Thanks,

Howard

[Quickfix-developers] Resend Request not sent

[Howard S. E. <ho...@ex...>]

Using QuickFIX 1.7 with a 4.0 Session..

When my engine, acting as an acceptor receives a Logon Request with a =
higher than expected sequence number (got 5 expected 1), rather than =
accepting the logon and sending a Resend Request to fill the gap, =
quickfix appears to simply disconnect the socket. =20

Is this correct behavior?  From perusing the FIX 4.0 spec it seems like =
accepting the logon and sending the Resend Request would be the correct =
thing to do?

Thanks,

Howard

[Quickfix-developers] development time and cost

[Won L. <sci...@ya...>]

Hello,

For those of you that have incorporated QuickFIX into
your firm's program trading activities, how long did
it take you to roll out a complete trading platform?

I'm assuming that a) the FIX engine was QuickFIX, b)
custom middle layer to handle all business logic, c)
custom developed GUI for traders to interact with, d)
written all in JAVA, and e) any and all DB work that
needed to be done. 

What is a realistic time frame? 




	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

Re: [Quickfix-developers] Incoming bad price fields

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

John and Patrick,

You can have the field treated like a string by opening up your data=20
dictionary file and changing the type of those fields to STRING.  This=20=

will circumvent any validation but you will then need to do the=20
conversion from a string to a double yourself.

Really, though, QuickFIX should be able to handle this value.  The fact=20=

that it cannot is actually a bug.  I wrote a unit test and verified=20
that QuickFIX will not correctly validate a double if it has extra=20
trailing zeros.  A weird thing to do, but doesn't break the definition=20=

of a valid floating point in FIX.  I'll work on a fix for this and post=20=

it to the mailing list.  In the meantime the STRING trick should work=20
for you.

--oren

On Apr 26, 2004, at 8:31 AM, John Debay wrote:

> Hi,
>
> I am receiving a double as a string value from a server application=20
> over
> which I have no control. They are not handling floating point numbers
> correctly (they are using native doubles), so I am getting values with
> rounding errors in them within the message. When this value is then=20
> received
> by QuickFix, it rejects the message because it can't parse the field
> correctly (the message is an execution report). I am still wading=20
> through
> the QuickFix code to find out where the rejection takes place, but in=20=

> the
> interim I was wondering if there is a way to get around this problem=20=

> without
> changing the code. Is there something I can set in my message=20
> definition
> file or something like that to get it to either accept a funky double=20=

> value,
> or to treat the double as a string and let me parse it? Is there a =
hook
> somewhere (like fromApp with a non-const Message) where I can fix the=20=

> value
> on the way in before QuickFix tries to build a typed message for it?
>
> For example, I am receiving a message of type 8, and am receiving a=20
> LastPx
> and AvgPx value of 250.300000000000010, which QuickFix is rejecting.
>
> I'm using QuickFix 4.2.
>
> Thanks,
> John
>
> -----------------------------------------------------------
> This email message is intended only for the addressee(s)
> and contains information that may be confidential and/or
> copyright.  If you are not the intended recipient please
> notify the sender by reply email and immediately delete
> this email. Use, disclosure or reproduction of this email
> by anyone other than the intended recipient(s) is strictly
> prohibited. No representation is made that this email or
> any attachments are free of viruses. Virus scanning is
> recommended and is the responsibility of the recipient.
>
> Thank you.
> -----------------------------------------------------------
>
> For more information on CTC, LLC please visit
> our website at:
>
>            http://www.chicagotrading.com.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Incoming bad price fields

[John D. <joh...@ch...>]

Hi,

I am receiving a double as a string value from a server application over
which I have no control. They are not handling floating point numbers
correctly (they are using native doubles), so I am getting values with
rounding errors in them within the message. When this value is then =
received
by QuickFix, it rejects the message because it can't parse the field
correctly (the message is an execution report). I am still wading =
through
the QuickFix code to find out where the rejection takes place, but in =
the
interim I was wondering if there is a way to get around this problem =
without
changing the code. Is there something I can set in my message definition
file or something like that to get it to either accept a funky double =
value,
or to treat the double as a string and let me parse it? Is there a hook
somewhere (like fromApp with a non-const Message) where I can fix the =
value
on the way in before QuickFix tries to build a typed message for it?

For example, I am receiving a message of type 8, and am receiving a =
LastPx
and AvgPx value of 250.300000000000010, which QuickFix is rejecting.

I'm using QuickFix 4.2.

Thanks,
John

-----------------------------------------------------------=20
This email message is intended only for the addressee(s)=20
and contains information that may be confidential and/or=20
copyright.  If you are not the intended recipient please=20
notify the sender by reply email and immediately delete=20
this email. Use, disclosure or reproduction of this email=20
by anyone other than the intended recipient(s) is strictly=20
prohibited. No representation is made that this email or=20
any attachments are free of viruses. Virus scanning is=20
recommended and is the responsibility of the recipient.

Thank you.
-----------------------------------------------------------=20

For more information on CTC, LLC please visit
our website at:=20

           http://www.chicagotrading.com.

[Quickfix-developers] Possible Rounding Errors

[Patrick F. <pat...@ch...>]

Oren,
I am using quick Fix 4.2 version 1.7.  We are receiving execution =
reports
with AvgPrice and Last Price values to the effect of=20
250.300000000000010.  QucikFix generates a reject message referring to =
the
AvgPrice field of the execution report.  Would quick fix generate a =
reject
for the aforementioned value?  What can be done about it?  Thank you in
advance for your time.  Patrick=20
=20

-----------------------------------------------------------=20
This email message is intended only for the addressee(s)=20
and contains information that may be confidential and/or=20
copyright.  If you are not the intended recipient please=20
notify the sender by reply email and immediately delete=20
this email. Use, disclosure or reproduction of this email=20
by anyone other than the intended recipient(s) is strictly=20
prohibited. No representation is made that this email or=20
any attachments are free of viruses. Virus scanning is=20
recommended and is the responsibility of the recipient.

Thank you.
-----------------------------------------------------------=20

For more information on CTC, LLC please visit
our website at:=20

           http://www.chicagotrading.com.

RE: [SPAM] [Quickfix-developers] Infinite resend loop

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

I thought the attached (Shown below also) test would fail. Am I missing
something?=20

# 22 Session Reject increments incoming sequence number

iCONNECT
#Logon
I8=3DFIX.4.0=0135=3DA=0134=3D1=0149=3DTW=0152=3D<TIME>=0156=3DISLD=0198=3D=
0=01108=3D30=01
E8=3DFIX.4.0=019=3D57=0135=3DA=0134=3D1=0149=3DISLD=0152=3D00000000-00:00=
:00=0156=3DTW=0198=3D0=01108=3D30=0110=3D
0=01

# Send a good messages
I8=3DFIX.4.0=0135=3DD=0134=3D2=0149=3DTW=0152=3D<TIME>=0156=3DISLD=0111=3D=
ID=0121=3D3=0138=3D100=0140=3D1=0154=3D1=0155=3D
INTC=01
E8=3DFIX.4.0=019=3D81=0135=3DD=0134=3D2=0149=3DISLD=0152=3D00000000-00:00=
:00=0156=3DTW=0111=3DID=0121=3D3=0138=3D1
00=0140=3D1=0154=3D1=0155=3DINTC=0110=3D0=01

#Send a message with good length, MsgSeqNum,and Check sum but bad enum =
value
54=3DX
I8=3DFIX.4.0=0135=3DD=0134=3D3=0149=3DTW=0152=3D<TIME>=0156=3DISLD=0111=3D=
ID=0121=3D3=0138=3D100=0140=3D1=0154=3DX=0155=3D
IVP=01
#Expect a reject
E8=3DFIX.4.0=019=3D105=0135=3D3=0134=3D3=0149=3DISLD=0152=3D00000000-00:0=
0:00=0156=3DTW=0145=3D3=0158=3DValue
is incorrect (out of range) for this tag (54)=0110=3D0

#Send a good message again with the MsgSeqNum incremented
I8=3DFIX.4.0=0135=3DD=0134=3D4=0149=3DTW=0152=3D<TIME>=0156=3DISLD=0111=3D=
ID=0121=3D3=0138=3D100=0140=3D1=0154=3D1=0155=3D
IVP=01
E8=3DFIX.4.0=019=3D80=0135=3DD=0134=3D4=0149=3DISLD=0152=3D00000000-00:00=
:00=0156=3DTW=0111=3DID=0121=3D3=0138=3D1
00=0140=3D1=0154=3D1=0155=3DIVP=0110=3D0=01

# logout message and response
I8=3DFIX.4.0=0135=3D5=0134=3D5=0149=3DTW=0152=3D<TIME>=0156=3DISLD=01
E8=3DFIX.4.0=019=3D45=0135=3D5=0134=3D5=0149=3DISLD=0152=3D00000000-00:00=
:00=0156=3DTW=0110=3D0=01
eDISCONNECT

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: James C. Downs [mailto:jc...@co...]=20
Sent: Wednesday, April 21, 2004 6:31 AM
To: 'Joerg Thoennes'; 'Oren Miller'
Cc: 'Kovalenko, Michael'; 'qui...@li...'
Subject: RE: [SPAM] [Quickfix-developers] Infinite resend loop

Joerg,
I think the test case we need to create is as follows:

Message has CORRECT body length, check sum, and sequence number; but =
FAILS
message validation, e.g. MSgType=3D&.

Quick fix should send session level reject with clear reason, and =
increment
the incoming sequence number to expect on the next message.

Does this look correct? If so we should create a test for this test =
case. We
should also review the existing test cases to ensure that we have proper
coverage for message rejection.

Also are we considering all FIX versions or just 4.2 forward?


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: Wednesday, April 21, 2004 4:52 AM
To: Oren Miller
Cc: Kovalenko, Michael; 'qui...@li...'
Subject: Re: [SPAM] [Quickfix-developers] Infinite resend loop

Oren Miller wrote:
> Ok.  This answers my question.  Looks like it's pretty clear what has=20
> to be done.  Thanks.

Oren,

does this mean your are planning to add session level rejects for all =
case
except body length or checksum errors? That would resolve some of our
customers complaints.

Thanks, J=F6rg

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

[Quickfix-developers] Resync problems ... Infinite Resend

[Angela M. <A.M...@it...>]

Hi Oren,
there is another problem during the resync phase that generate the =
infinite resend request and it appens because of the Logon message is =
put in the queue this means when I receive a sequence reset with the =
same sequence number of logon message QuickFix can't process this =
message because it processes the Logon message that increment the seqnum =
and doesn't process the sequencereset because of seqnum < than seqnum =
expexted after the reprocessed Logon message.

This is an example to clarify my explanation:

Last message received 34 =3D 24

send 35=3DA 34=3D ...
receive 35=3DA;34=3D26
send 35=3D2;34=3D...;7=3D25
receive 35=3D8;34=3D25
receive 35=3D4;34=3D26

from here every message I receive QuickFix generate a resendRequest from =
27

receive 35=3D8;34=3D30
receive 35=3D8;34=3D31
receive 35=3D8;34=3D32

and so on ....

I made this change to the session.cpp file:

void Session::doTargetTooHigh( const Message& msg )
{ QF_STACK_PUSH(Session::doTargetTooHigh)

  const Header & header =3D msg.getHeader();
  BeginString beginString;
  MsgSeqNum msgSeqNum;
  MsgType	msgType;	/* AMetallo 23/01/2004 */
  header.getField( beginString );
  header.getField( msgSeqNum );
  header.getField( msgType );	/* AMetallo 23/01/2004 */
 =20
  m_state.onEvent( "MsgSeqNum too high RECEIVED: "
                   + IntConvertor::convert( msgSeqNum )
                   + " EXPECTED: "
                   + IntConvertor::convert( getExpectedTargetNum() ) );
	/* =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
	* AMetallo 23/01/2004 BF -=20
	* =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
	if ( msgType !=3D MsgType_Logon)
	{
	  m_state.onEvent( "<doTargetTooHigh> Inserisco nella coda xche' seqnum =
>. MsgType " + msgType.getString());
	  m_state.queue( msgSeqNum, msg );
	}
	/* =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
	* AMetallo 23/01/2004 BF -=20
	* =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
	generateResendRequest( beginString, msgSeqNum );

  QF_STACK_POP
}

Oren I tested this change and it works, do you think it is possible to =
insert this modification in QuickFix?

Just another little problem in the session.cpp when I receive an empty =
message the application crash so I did another little change to prevent =
this in the Session::next( const std::string& msg ) method as follow:

void Session::next( const std::string& msg )
{ QF_STACK_PUSH(Session::next)

  try
  {
    m_state.onIncoming( msg );
	/* =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
	* AMetallo 04/02/2004 BF START
	* =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
	if (msg.length() <=3D 1 || msg.empty())	{
		m_state.onEvent("<Session::next> Ricevuto messaggio vuoto per cui lo =
scarto!" );
		return;
	}
	/* =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
	* AMetallo 04/02/2004 BF END
	* =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
	next( Message( msg, m_dataDictionary ) );
  }=20
  catch( InvalidMessage& e )
  {
    m_state.onEvent( e.what() );

    try
    {
      if( identifyType(msg) =3D=3D MsgType_Logon )
        disconnect();
    } catch( MessageParseError& ) {}
    throw e;	/* This exception isn't catched why ? It cause the cras of =
my application*/
  }

  QF_STACK_POP
}

Thank you

Angela

__________________________________
Angela Metallo
IT SOFTWARE S.p.A.
Via Santa Sofia 27 - 20122 Milano
Phone	+39 02.58343.339
Fax	+39 02.58315.195
mailto:a.m...@it...
www.itsoftware.it


This message is for the named person's use only. It may contain =
confidential, proprietary or legally privileged information. No =
confidentiality or privilege is waived or lost by any mistransmission. =
You may not, directly or indirectly, use, disclose, distribute, print, =
or copy any part of this message if you are not the intended recipient. =
You are therefore equested to cancel this e-mail and the relating =
attachments if you are not the intended recipient. IT SOFTWARE S.p.A. =
does not warrant, whether to the intended recipient or to anybody else, =
that any attachments are free from viruses or other defects and accept =
no liability for any losses resulting from infected email transmissions. =
Please note, that any views expressed in this message are those of the =
individual sender, except where the sender specifically states them to =
be the views of IT SOFTWARE S.p.A.

Re: [SPAM] [Quickfix-developers] Infinite resend loop

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

Hi James,

> Message has CORRECT body length, check sum, and sequence number; but FAILS
> message validation, e.g. MSgType=&.

Yes. We should add test cases for different variants, too. E.g. 
duplicate message tags, etc. There are some tests in the "future" 
sections which probably could used.

> Quick fix should send session level reject with clear reason, and increment
> the incoming sequence number to expect on the next message.

And log to the event log. This is important, too.

> Does this look correct? If so we should create a test for this test case. We
> should also review the existing test cases to ensure that we have proper
> coverage for message rejection.

Yes.

> Also are we considering all FIX versions or just 4.2 forward?

If the spec not explicitely prohibits this, we should add it. It 
improves useability in error situations dramatically (avoiding loops).

James, you are the guy which always says "I am adding an acceptance test 
for it..." :-) This is a Good Thing - thank you very much! Do you add 
these cases directly to the CVS repository? I haven't checked it lately, 
though.

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

RE: [SPAM] [Quickfix-developers] Infinite resend loop

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

Joerg,
I think the test case we need to create is as follows:

Message has CORRECT body length, check sum, and sequence number; but =
FAILS
message validation, e.g. MSgType=3D&.

Quick fix should send session level reject with clear reason, and =
increment
the incoming sequence number to expect on the next message.

Does this look correct? If so we should create a test for this test =
case. We
should also review the existing test cases to ensure that we have proper
coverage for message rejection.

Also are we considering all FIX versions or just 4.2 forward?


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: Wednesday, April 21, 2004 4:52 AM
To: Oren Miller
Cc: Kovalenko, Michael; 'qui...@li...'
Subject: Re: [SPAM] [Quickfix-developers] Infinite resend loop

Oren Miller wrote:
> Ok.  This answers my question.  Looks like it's pretty clear what has=20
> to be done.  Thanks.

Oren,

does this mean your are planning to add session level rejects for all =
case
except body length or checksum errors? That would resolve some of our
customers complaints.

Thanks, J=F6rg

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

Re: [SPAM] [Quickfix-developers] Infinite resend loop

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

Oren Miller wrote:
> Ok.  This answers my question.  Looks like it's pretty clear what has  
> to be done.  Thanks.

Oren,

does this mean your are planning to add session level rejects for all 
case except body length or checksum errors? That would resolve some of 
our customers complaints.

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

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

Re: [Quickfix-developers] ExecutionReport

[Caleb E. <ca...@bk...>]

On Tue, Apr 20, 2004 at 07:12:29PM +0200, Bjo...@ub... wrote:

> Hello, according to the fix documentation one should get a compiler
> warning when accessing a tag, which is not defined for a message.
> 
> Here an extract from the documentation:
> void onMessage( const FIX41::NewOrderSingle& message, const FIX::SessionID&
> )
> {
>    FIX::ClOrdID clOrdID;
>    message.get(clOrdID);
> 
>    // compile time error!! field not defined in FIX41
>    FIX::ClearingAccount clearingAccount;
>    message.get(clearingAccount);
> }
> 
> When using something like this:
> void FixApplication::onMessage( const FIX43::ExecutionReport& message,
> const FIX::SessionID& sessionID)
> {
> 
>    FIX::TradeRequestID toto;
>    message.getField( toto );
> 
> }
> 
> I don't get any warnings.

	If you used "get" and not "getField" you would get a warning
	(perhaps an error?).

	The generic "getField" method will work with any class derived
	from FieldBase (though it will throw an exception if the field
	is not in the messsage).  The type-safe, message-specific
	"get" methods are only provided for fields which are specified
	as being part of the message.


-- 
Caleb Epstein |  bklyn . org  |            BOFH excuse #64:
    cae at    | Brooklyn Dust |
bklyn dot org |   Bunny Mfg.  |            CPU needs recalibration

[Quickfix-developers] ExecutionReport

[<Bjo...@ub...>]

Hello,

according to the fix documentation one should get a compiler warning when
accessing a tag,
which is not defined for a message.

Here an extract from the documentation:
void onMessage( const FIX41::NewOrderSingle& message, const FIX::SessionID&
)
{
   FIX::ClOrdID clOrdID;
   message.get(clOrdID);

   // compile time error!! field not defined in FIX41
   FIX::ClearingAccount clearingAccount;
   message.get(clearingAccount);
}

When using something like this:
void FixApplication::onMessage( const FIX43::ExecutionReport& message,
const FIX::SessionID& sessionID)
{

   FIX::TradeRequestID toto;
   message.getField( toto );

}

I don't get any warnings.
I've checked the fix43 header file ExecutionReport.h and the field
TradeRequestID is is not defined.
Writing:
FIX43::ExecutionReport::TradeRequestID toto;

gives a compilor error:
fixapplication.cpp(287) : error C2039: 'TradeRequestID' : is not a member
of 'ExecutionReport'
../src/fix/inc/fix43/ExecutionReport.h(9) : see declaration of
'ExecutionReport'

Does anyone have an idea why the compiler does not give any errors in the
first case?

Thanks
Bjoern
PS.: I'm using C++ under Windows.

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