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

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

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

  _____ =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.



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