Re: [Quickfix-users] Possible bug in the Parser when receiving huge amounts through th e socket

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

I think I do need some more information about the version you are using.  I 
wrote a test and ran it against 1.9.4 and was not able to duplicate the 
behavior described.  The parser has changed over time so it may have been 
resolved somewhere along the way.  What version are you using?

--oren

----- Original Message ----- 
From: <em...@co...>
To: <qui...@li...>
Sent: Thursday, December 09, 2004 10:14 AM
Subject: [Quickfix-users] Possible bug in the Parser when receiving huge 
amounts through th e socket


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Here is the scenario.
>
> At the moment the socket buffer in the parser is 4096. So, I have recently
> generated a lot of traffic so I constantly receive of 4096 bytes on the
> socket and have encountered the following problem.
>
> The end of the incoming buffer (m_buffer) of 4096 is as follows (some of 
> the
> values have been substituted to hide trading details):
>
> 8=FIX.4.2
9=291
35=8
34=156110
369=31450
52=20041209-15:35:32.687
49=BLA
50=
> G
56=D33030N
60=20041209-15:35:32
59=0
55=GE
54=1
48=BLA000060467
107=BLF5
1
> 67=FUT
44=9740.00
41=0
40=2
39=0
38=10
37=20041209004077
151=10
150=0
20=0
9
> 717=67960
17=00687120041209093532
14=0
11=00067960
6=0
432=20041209
1=123456
> 78
10=097
8=F
>
> As we can see, when the parser gets to parsing this part of the buffer, it
> will extract the length of the valid message which is 294 (9=291) and in
> turn send of the message for processing into the application code, etc.
> After, it has processed the message the buffer then looks like:
>
> 8=F
>
> This is because the rest of the message is resting on the socket to be 
> read
> so a valid FIX message can be composed.
>
> As you can see there is a 8=F at the end which was received into the 
> buffer,
> and more data is left over on the socket to be read into the buffer. But, 
> at
> the moment what the parser will do is make 8=F into a fix message as this 
> is
> where the buffer is ending, and will try and extract length from it, and
> this generates a series of exceptions (FieldConvertError, 
> MessageParseError,
> FieldNotFound and InvalidMessage).
>
>
> Once the parser tries to parse this message, and throws its exceptions, it
> will get around to reading the socket again and receiving the following 
> into
> buffer:
>
> IX.4.2
9=349
35=8
34=156111
369=31450
52=20041209-15:35:32.692
49=BLA
50=G
5
> 6=D33030N
60=20041209-15:35:32
59=0
55=GE
54=1
48=CME000060467
107=BLF5
167=
> FUT
44=9740.00
41=0
40=2
39=2
38=10
37=20041209004077
337=0C0
32=10
31=9740.
> 00
151=0
150=2
20=0
9717=67960
17=00687220041209093532TN0002843
75=20041209

> 14=0
11=00067960
375=BLA030A1
6=0
432=20041209
1=12345678
10=178

>
> Once this is received the m_buffer is "8=F" and m_readBuffer is as above.
> When the parser appends m_readBuffer to m_buffer the message looks like:
>
> 8=FIX.4.2
9=349
35=8
34=156111
369=31450
52=20041209-15:35:32.692
49=BLA
50=
> G
56=D33030N
60=20041209-15:35:32
59=0
55=GE
54=1
48=CME000060467
107=BLF5
1
> 67=FUT
44=9740.00
41=0
40=2
39=2
38=10
37=20041209004077
337=0C0
32=10
31=97
> 40.00
151=0
150=2
20=0
9717=67960
17=00687220041209093532TN0002843
75=200412
> 09
14=0
11=00067960
375=BLA030A1
6=0
432=20041209
1=12345678
10=178

>
> a COMPLETE message as it should be.
>
> Now surely, if this kind of scenario is encountered the parser should not
> even attempt to parse the message, as it is incomplete. I think that there
> needs to be an extra safeguard in the parser that needs to check presence 
> of
> field 10 (Standard Trailer) in order to verify that it is a complete
> message.
>
> If anyone has any ideas how to solve this, please be my guess as it has
> taken my over 2 days just to track this problem down.
>
> Thanks a lot
>
> Emir
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/2004
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>