quickfixj-users

[Quickfixj-users] Handling of checksum errors

[Brad H. <Bra...@gb...>]

Hi All,

I recently encountered a problem where the checksum validation of a
particular incoming message always failed.  This has the side effect of
stopping fromApp being called for any future message because the engine
waits forever for the message to be resent. =20

Ignoring the problem of why the checksum is failing for the moment (non
printable/possibly embedded null characters in a string field - possibly
the subject of a future mail), what would be a better way to handle
this? =20

As a short term workaround I may disable checksum validation - we're
connecting to counterparty over a LAN and the risk of checksum being
incorrect on a message is higher than the risk of the message being
received incorrectly.

Longer term I was thinking of doing something to make the engine go to
the next target sequence number if there are 2 checksums failures for
the same MsgSeqNum.

Following is a log from Banzai showing the problem.  It was connecting
to Executor which I modified to always make the checksum of execution
reports for security "CHK" incorrect.  This test was done with quickfixj
trunk but problem was initially noticed with 1.0.2.

Any suggestions are appreciated.
Thanks,
Brad.

The test was:
* submitted two orders that received execution reports ok.
* submitted order for CHK.
* executor mangled checksum on execution report for CHK, banzai detected
checksum failure (fromApp not called)
* submit another order
* banzai detects out of sequence message, sends resend request
* executor resent execution report with managed checksum again.
* banzai detects checksum failure
* For any further incoming messages, banzai detects sequence too high
and does nothing because of pending resend request.

<20060921-12:25:25, FIX.4.2:BANZAI->EXEC, outgoing>
(8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D2=0149=3DBANZAI=0152=3D20060921-12=
:25:25.937=0156=3DEXEC=0111
=3D1158841525860=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DABC=
=0159=3D0=0160=3D20060921-12:25:2
5=0110=3D250=01)
<20060921-12:25:26, FIX.4.2:BANZAI->EXEC, incoming>
(8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D2=0149=3DEXEC=0152=3D20060921-12:2=
5:26.062=0156=3DBANZAI=016=3D
10=0111=3D1158841525860=0114=3D5=0117=3D1=0120=3D0=0131=3D10=0132=3D5=013=
7=3D1=0138=3D5=0139=3D2=0154=3D1=0155=3DABC
=01150=3D2=01151=3D0=0110=3D057=01)
<20060921-12:25:46, FIX.4.2:BANZAI->EXEC, outgoing>
(8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D3=0149=3DBANZAI=0152=3D20060921-12=
:25:46.546=0156=3DEXEC=0111
=3D1158841546548=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCBA=
=0159=3D0=0160=3D20060921-12:25:4
6=0110=3D003=01)
<20060921-12:25:46, FIX.4.2:BANZAI->EXEC, incoming>
(8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D3=0149=3DEXEC=0152=3D20060921-12:2=
5:46.546=0156=3DBANZAI=016=3D
10=0111=3D1158841546548=0114=3D5=0117=3D2=0120=3D0=0131=3D10=0132=3D5=013=
7=3D2=0138=3D5=0139=3D2=0154=3D1=0155=3DCBA
=01150=3D2=01151=3D0=0110=3D075=01)
<20060921-12:25:56, FIX.4.2:BANZAI->EXEC, outgoing>
(8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D4=0149=3DBANZAI=0152=3D20060921-12=
:25:56.312=0156=3DEXEC=0111
=3D1158841556315=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCHK=
=0159=3D0=0160=3D20060921-12:25:5
6=0110=3D006=01)
<20060921-12:25:56, FIX.4.2:BANZAI->EXEC, incoming>
(8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D4=0149=3DEXEC=0152=3D20060921-12:2=
5:56.312=0156=3DBANZAI=016=3D
10=0111=3D1158841556315=0114=3D5=0117=3D3=0120=3D0=0131=3D10=0132=3D5=013=
7=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK
=01150=3D2=01151=3D0=0110=3D179=01)
21/09/2006 22:25:56 quickfix.mina.AbstractIoHandler messageReceived
SEVERE: Invalid message: Expected CheckSum=3D79, Received CheckSum=3D179
<20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing>
(8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D5=0149=3DBANZAI=0152=3D20060921-12=
:26:26.468=0156=3DEXEC=0111
=3D1158841586472=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DAAA=
=0159=3D0=0160=3D20060921-12:26:2
6=0110=3D003=01)
<20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming>
(8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D5=0149=3DEXEC=0152=3D20060921-12:2=
6:26.468=0156=3DBANZAI=016=3D
10=0111=3D1158841586472=0114=3D5=0117=3D4=0120=3D0=0131=3D10=0132=3D5=013=
7=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA
=01150=3D2=01151=3D0=0110=3D080=01)
<20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
expecting 4 but received 5)
<20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing>
(8=3DFIX.4.2=019=3D62=0135=3D2=0134=3D6=0149=3DBANZAI=0152=3D20060921-12:=
26:26.468=0156=3DEXEC=017=3D4
=0116=3D0=0110=3D058=01)
<20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Sent ResendRequest
FROM: 4 TO: 0)
<20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming>
(8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D4=0143=3DY=0149=3DEXEC=0152=3D2006=
0921-12:26:26.484=0156=3DBANZ
AI=01122=3D20060921-12:25:56=016=3D10=0111=3D1158841556315=0114=3D5=0117=3D=
3=0120=3D0=0131=3D10=0132=3D5
=0137=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK=01150=3D2=01151=3D0=0110=3D=
255=01)
<20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming>
(8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D5=0143=3DY=0149=3DEXEC=0152=3D2006=
0921-12:26:26.500=0156=3DBANZ
AI=01122=3D20060921-12:26:26=016=3D10=0111=3D1158841586472=0114=3D5=0117=3D=
4=0120=3D0=0131=3D10=0132=3D5
=0137=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA=01150=3D2=01151=3D0=0110=3D=
133=01)
<20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
expecting 4 but received 5)
<20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Already sent
ResendRequest FROM: 4 TO: 4.  Not sending another.)
21/09/2006 22:26:26 quickfix.mina.AbstractIoHandler messageReceived
SEVERE: Invalid message: Expected CheckSum=3D155, Received =
CheckSum=3D255
<20060921-12:26:34, FIX.4.2:BANZAI->EXEC, outgoing>
(8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D7=0149=3DBANZAI=0152=3D20060921-12=
:26:34.421=0156=3DEXEC=0111
=3D1158841594426=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DBBB=
=0159=3D0=0160=3D20060921-12:26:3
4=0110=3D249=01)
<20060921-12:26:34, FIX.4.2:BANZAI->EXEC, incoming>
(8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D6=0149=3DEXEC=0152=3D20060921-12:2=
6:34.437=0156=3DBANZAI=016=3D
10=0111=3D1158841594426=0114=3D5=0117=3D5=0120=3D0=0131=3D10=0132=3D5=013=
7=3D5=0138=3D5=0139=3D2=0154=3D1=0155=3DBBB
=01150=3D2=01151=3D0=0110=3D079=01)
<20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
expecting 4 but received 6)
<20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (Already sent
ResendRequest FROM: 4 TO: 4.  Not sending another.)
<20060921-12:26:43, FIX.4.2:BANZAI->EXEC, outgoing>
(8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D8=0149=3DBANZAI=0152=3D20060921-12=
:26:43.609=0156=3DEXEC=0111
=3D1158841603615=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCCC=
=0159=3D0=0160=3D20060921-12:26:4
3=0110=3D252=01)
<20060921-12:26:43, FIX.4.2:BANZAI->EXEC, incoming>
(8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D7=0149=3DEXEC=0152=3D20060921-12:2=
6:43.625=0156=3DBANZAI=016=3D
10=0111=3D1158841603615=0114=3D5=0117=3D6=0120=3D0=0131=3D10=0132=3D5=013=
7=3D6=0138=3D5=0139=3D2=0154=3D1=0155=3DCCC
=01150=3D2=01151=3D0=0110=3D075=01)
<20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
expecting 4 but received 7)
<20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (Already sent
ResendRequest FROM: 4 TO: 4.  Not sending another.)
<20060921-12:26:54, FIX.4.2:BANZAI->EXEC, outgoing>
(8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D9=0149=3DBANZAI=0152=3D20060921-12=
:26:54.390=0156=3DEXEC=0111
=3D1158841614397=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DDDD=
=0159=3D0=0160=3D20060921-12:26:5
4=0110=3D010=01)
<20060921-12:26:54, FIX.4.2:BANZAI->EXEC, incoming>
(8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D8=0149=3DEXEC=0152=3D20060921-12:2=
6:54.406=0156=3DBANZAI=016=3D
10=0111=3D1158841614397=0114=3D5=0117=3D7=0120=3D0=0131=3D10=0132=3D5=013=
7=3D7=0138=3D5=0139=3D2=0154=3D1=0155=3DDDD
=01150=3D2=01151=3D0=0110=3D089=01)
<20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
expecting 4 but received 8)
<20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (Already sent
ResendRequest FROM: 4 TO: 4.  Not sending another.)

=20

Re: [Quickfixj-users] Handling of checksum errors

[Toli K. <to...@ma...>]

Brad,

Not sure if this helps - but i came across checksum problems when my
exchange simulator (modified exchange code) was inserting fields
unknown to quickfixj when these vars were set:
DataDictionary=3DFIX42.xml
UseDataDictionary=3DY

Are you sure you are not inserting "unknown" fields?

hope this helps. If i remember the exact sequence of what caused
checksum failures for me i'll post that

On 9/21/06, Brad Harvey <Bra...@gb...> wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Hi All,
>
> I recently encountered a problem where the checksum validation of a
> particular incoming message always failed.  This has the side effect of
> stopping fromApp being called for any future message because the engine
> waits forever for the message to be resent.
>
> Ignoring the problem of why the checksum is failing for the moment (non
> printable/possibly embedded null characters in a string field - possibly
> the subject of a future mail), what would be a better way to handle
> this?
>
> As a short term workaround I may disable checksum validation - we're
> connecting to counterparty over a LAN and the risk of checksum being
> incorrect on a message is higher than the risk of the message being
> received incorrectly.
>
> Longer term I was thinking of doing something to make the engine go to
> the next target sequence number if there are 2 checksums failures for
> the same MsgSeqNum.
>
> Following is a log from Banzai showing the problem.  It was connecting
> to Executor which I modified to always make the checksum of execution
> reports for security "CHK" incorrect.  This test was done with quickfixj
> trunk but problem was initially noticed with 1.0.2.
>
> Any suggestions are appreciated.
> Thanks,
> Brad.
>
> The test was:
> * submitted two orders that received execution reports ok.
> * submitted order for CHK.
> * executor mangled checksum on execution report for CHK, banzai detected
> checksum failure (fromApp not called)
> * submit another order
> * banzai detects out of sequence message, sends resend request
> * executor resent execution report with managed checksum again.
> * banzai detects checksum failure
> * For any further incoming messages, banzai detects sequence too high
> and does nothing because of pending resend request.
>
> <20060921-12:25:25, FIX.4.2:BANZAI->EXEC, outgoing>
> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D2=0149=3DBANZAI=0152=3D20060921-12=
:25:25.937=0156=3DEXEC=0111
> =3D1158841525860=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DABC=
=0159=3D0=0160=3D20060921-12:25:2
> 5=0110=3D250=01)
> <20060921-12:25:26, FIX.4.2:BANZAI->EXEC, incoming>
> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D2=0149=3DEXEC=0152=3D20060921-12:2=
5:26.062=0156=3DBANZAI=016=3D
> 10=0111=3D1158841525860=0114=3D5=0117=3D1=0120=3D0=0131=3D10=0132=3D5=013=
7=3D1=0138=3D5=0139=3D2=0154=3D1=0155=3DABC
> =01150=3D2=01151=3D0=0110=3D057=01)
> <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, outgoing>
> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D3=0149=3DBANZAI=0152=3D20060921-12=
:25:46.546=0156=3DEXEC=0111
> =3D1158841546548=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCBA=
=0159=3D0=0160=3D20060921-12:25:4
> 6=0110=3D003=01)
> <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, incoming>
> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D3=0149=3DEXEC=0152=3D20060921-12:2=
5:46.546=0156=3DBANZAI=016=3D
> 10=0111=3D1158841546548=0114=3D5=0117=3D2=0120=3D0=0131=3D10=0132=3D5=013=
7=3D2=0138=3D5=0139=3D2=0154=3D1=0155=3DCBA
> =01150=3D2=01151=3D0=0110=3D075=01)
> <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, outgoing>
> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D4=0149=3DBANZAI=0152=3D20060921-12=
:25:56.312=0156=3DEXEC=0111
> =3D1158841556315=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCHK=
=0159=3D0=0160=3D20060921-12:25:5
> 6=0110=3D006=01)
> <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, incoming>
> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D4=0149=3DEXEC=0152=3D20060921-12:2=
5:56.312=0156=3DBANZAI=016=3D
> 10=0111=3D1158841556315=0114=3D5=0117=3D3=0120=3D0=0131=3D10=0132=3D5=013=
7=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK
> =01150=3D2=01151=3D0=0110=3D179=01)
> 21/09/2006 22:25:56 quickfix.mina.AbstractIoHandler messageReceived
> SEVERE: Invalid message: Expected CheckSum=3D79, Received CheckSum=3D179
> <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing>
> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D5=0149=3DBANZAI=0152=3D20060921-12=
:26:26.468=0156=3DEXEC=0111
> =3D1158841586472=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DAAA=
=0159=3D0=0160=3D20060921-12:26:2
> 6=0110=3D003=01)
> <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming>
> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D5=0149=3DEXEC=0152=3D20060921-12:2=
6:26.468=0156=3DBANZAI=016=3D
> 10=0111=3D1158841586472=0114=3D5=0117=3D4=0120=3D0=0131=3D10=0132=3D5=013=
7=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA
> =01150=3D2=01151=3D0=0110=3D080=01)
> <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
> expecting 4 but received 5)
> <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing>
> (8=3DFIX.4.2=019=3D62=0135=3D2=0134=3D6=0149=3DBANZAI=0152=3D20060921-12:=
26:26.468=0156=3DEXEC=017=3D4
> =0116=3D0=0110=3D058=01)
> <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Sent ResendRequest
> FROM: 4 TO: 0)
> <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming>
> (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D4=0143=3DY=0149=3DEXEC=0152=3D2006=
0921-12:26:26.484=0156=3DBANZ
> AI=01122=3D20060921-12:25:56=016=3D10=0111=3D1158841556315=0114=3D5=0117=
=3D3=0120=3D0=0131=3D10=0132=3D5
> =0137=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK=01150=3D2=01151=3D0=0110=
=3D255=01)
> <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming>
> (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D5=0143=3DY=0149=3DEXEC=0152=3D2006=
0921-12:26:26.500=0156=3DBANZ
> AI=01122=3D20060921-12:26:26=016=3D10=0111=3D1158841586472=0114=3D5=0117=
=3D4=0120=3D0=0131=3D10=0132=3D5
> =0137=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA=01150=3D2=01151=3D0=0110=
=3D133=01)
> <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
> expecting 4 but received 5)
> <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Already sent
> ResendRequest FROM: 4 TO: 4.  Not sending another.)
> 21/09/2006 22:26:26 quickfix.mina.AbstractIoHandler messageReceived
> SEVERE: Invalid message: Expected CheckSum=3D155, Received CheckSum=3D255
> <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, outgoing>
> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D7=0149=3DBANZAI=0152=3D20060921-12=
:26:34.421=0156=3DEXEC=0111
> =3D1158841594426=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DBBB=
=0159=3D0=0160=3D20060921-12:26:3
> 4=0110=3D249=01)
> <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, incoming>
> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D6=0149=3DEXEC=0152=3D20060921-12:2=
6:34.437=0156=3DBANZAI=016=3D
> 10=0111=3D1158841594426=0114=3D5=0117=3D5=0120=3D0=0131=3D10=0132=3D5=013=
7=3D5=0138=3D5=0139=3D2=0154=3D1=0155=3DBBB
> =01150=3D2=01151=3D0=0110=3D079=01)
> <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
> expecting 4 but received 6)
> <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (Already sent
> ResendRequest FROM: 4 TO: 4.  Not sending another.)
> <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, outgoing>
> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D8=0149=3DBANZAI=0152=3D20060921-12=
:26:43.609=0156=3DEXEC=0111
> =3D1158841603615=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCCC=
=0159=3D0=0160=3D20060921-12:26:4
> 3=0110=3D252=01)
> <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, incoming>
> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D7=0149=3DEXEC=0152=3D20060921-12:2=
6:43.625=0156=3DBANZAI=016=3D
> 10=0111=3D1158841603615=0114=3D5=0117=3D6=0120=3D0=0131=3D10=0132=3D5=013=
7=3D6=0138=3D5=0139=3D2=0154=3D1=0155=3DCCC
> =01150=3D2=01151=3D0=0110=3D075=01)
> <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
> expecting 4 but received 7)
> <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (Already sent
> ResendRequest FROM: 4 TO: 4.  Not sending another.)
> <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, outgoing>
> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D9=0149=3DBANZAI=0152=3D20060921-12=
:26:54.390=0156=3DEXEC=0111
> =3D1158841614397=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DDDD=
=0159=3D0=0160=3D20060921-12:26:5
> 4=0110=3D010=01)
> <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, incoming>
> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D8=0149=3DEXEC=0152=3D20060921-12:2=
6:54.406=0156=3DBANZAI=016=3D
> 10=0111=3D1158841614397=0114=3D5=0117=3D7=0120=3D0=0131=3D10=0132=3D5=013=
7=3D7=0138=3D5=0139=3D2=0154=3D1=0155=3DDDD
> =01150=3D2=01151=3D0=0110=3D089=01)
> <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high,
> expecting 4 but received 8)
> <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (Already sent
> ResendRequest FROM: 4 TO: 4.  Not sending another.)
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>


--=20
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

Re: [Quickfixj-users] Handling of checksum errors

[Steve B. <st...@te...>]

> Ignoring the problem of why the checksum is failing for the 
> moment (non printable/possibly embedded null characters in a 
> string field - possibly the subject of a future mail), what 
> would be a better way to handle this?  

Hi Brad,

I don't think the checksum calculation would have a problem 
with null characters. I'm still investigating whether nonprintable
characters might be interpreted as Unicode and cause problems
with the checksum calculation.

In your Banzai example, you simply placed the wrong checksum
in the message, right?

Steve