[Quickfix-developers] RE: Infinite loop when receiving bad message in threaded acceptor

[Yihu F. <Yih...@re...>]

This works.

=20

In case you get a message with negative body length like 9=3D-10, it
should have if (length > 0) instead.

=20

Thanks,

=20

-Yihu

=20

  _____ =20

From: Oren Miller [mailto:or...@qu...]=20
Sent: Thursday, February 24, 2005 2:18 PM
To: Yihu Fang; qui...@li...
Subject: Re: Infinite loop when receiving bad message in threaded
acceptor

=20

I ended up writing the catch block as follows:

=20

if( length )

    m_buffer.erase( 0, pos + length )

else

  m_buffer.erase();

=20

I added a unit test to verify that passing the example string you
supplied throws an exception the first time, then returns false on the
second pass.  The reason I do the check for length is that it could save
some resend requests in case there are other messages in the buffer that
might be cleared.  Could be a significant factor in a high frequency
system if the buffer builds up. Please let me know if your tests
indicate that this code satisfies the error case you reported.

=20

--oren

	----- Original Message -----=20

	From: Yihu Fang <mailto:Yih...@re...> =20

	To: Oren Miller <mailto:or...@qu...>  ;
qui...@li...=20

	Sent: Tuesday, February 22, 2005 7:01 PM

	Subject: RE: Infinite loop when receiving bad message in
threaded acceptor

	=20

	Oren,

	=20

	Yes, after the fix to empty m_buffer correctly, QF can continue
to read the next message without disconnect the session.

	=20

	The only annoying thing is that
ThreadedSocketConnection::readMessage() gets an empty string so the log
could not record the garbled incoming message. It would record an event
error "BodyLength or CheckSum missing" because of the empty string. This
could be misleading.

	=20

	Thanks,

	=20

	-Yihu

	=20

=09
  _____ =20


	From: Oren Miller [mailto:or...@qu...]=20
	Sent: Tuesday, February 22, 2005 5:54 PM
	To: Yihu Fang; qui...@li...
	Subject: Re: Infinite loop when receiving bad message in
threaded acceptor

	=20

	Garbled messages should be ignored, so it shouldn't cause a
termination of the session. If it goes on to continue reading the
buffer, then that is the correct behavior according to the FPL test
cases.

	=20

	--oren

		----- Original Message -----=20

		From: Yihu Fang <mailto:Yih...@re...> =20

		To: Yihu Fang <mailto:Yih...@re...>  ; Oren
Miller <mailto:or...@qu...>  ;
qui...@li...=20

		Sent: Tuesday, February 22, 2005 2:45 PM

		Subject: RE: Infinite loop when receiving bad message in
threaded acceptor

		=20

		Hi,

		=20

		To stop the infinite loop, in catch(MessageParseError
&e) of Parser::readFixMessage(), the m_buffer should be emptied. Because
pos and length are zero, the bad message in m_buffer is reused which
causes the infinite loop.

		=20

		QuickFIX 1.9.4

		117,118c117

		<     // m_buffer.erase( 0, pos + length );

		<         m_buffer.erase();

		---

		>     m_buffer.erase( 0, pos + length );

		=20

		Whether QF is going to decide to terminate the session
or not should be done in the ThreadedSocketConnection.

		=20

		Thanks,

		=20

		-Yihu

		=20

	=09
  _____ =20


		From: Yihu Fang=20
		Sent: Tuesday, February 22, 2005 2:09 PM
		To: 'Oren Miller';
qui...@li...
		Subject: Infinite loop when receiving bad message in
threaded acceptor

		=20

		Oren,

		=20

		When a threaded acceptor receives a garbled message,
e.g. invalid length field, during an established FIX session, the
QuickFIX engine runs into an infinite loop.

		=20

		An example garbles message is like this,
8=3DTEST9=3DTEST35=3DTEST49=3DSS156=3DRORE34=3D352=3D20050222-16:45:5310=3D=
TEST

		=20

		Parser::extractLength() throws a MessageParserError
exception because of field 9=3DTEST.

		=20

		ThreadSocketConnection::readMessage() catches the
exception but it does nothing and returns true.

		=20

		This causes an infinite loop in the
ThreadedSocketConnection::readQueue(). An empty string is passed to
Session::next(), an InvalidMessage exception is thrown. However, because
the session is in a logon on state, the session is not disconnected, but
keeps going.

		=20

		The session should be disconnected in the exception
catch of either MessageParserError or InvalidMessage.

		=20

		Thank you,

		=20

		-Yihu

	=09
	=09
=09
-----------------------------------------------------------------
		Visit our Internet site at http://www.reuters.com
	=09
		Get closer to the financial markets with Reuters
Messaging - for more
		information and to register, visit
http://www.reuters.com/messaging
	=09
		Any views expressed in this message are those of the
individual
		sender, except where the sender specifically states them
to be
		the views of Reuters Ltd.

=09
=09
=09
-----------------------------------------------------------------
	Visit our Internet site at http://www.reuters.com
=09
	Get closer to the financial markets with Reuters Messaging - for
more
	information and to register, visit
http://www.reuters.com/messaging
=09
	Any views expressed in this message are those of the individual
	sender, except where the sender specifically states them to be
	the views of Reuters Ltd.



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.