Thread: RE: [Quickfix-developers] Field with embedded null character
Brought to you by:
orenmnero
From: Yihu F. <Yih...@re...> - 2004-10-28 20:55:05
|
Hi, Actually I am thinking what if a FIX engine sends a FIX message which has embedded null character. After the message read off the socket (which is a character array), the rest of the code is using STL string to represent the message. A null character will basically truncate the string. For example, this message with an extra null in 55=3DIBM<null><soh> =20 8=3DFIX.4.0<soh>9=3D71<soh>35=3DD<soh>49=3DFIRM0<soh>56=3DFIRM1<soh>11=3D12= 3<soh>21=3D 1<soh>38=3D456<soh>40=3D2<soh>44=3D789<soh>54=3D1<soh>55=3DIBM<null><soh>59= =3D0<soh> 10=3D157<soh> In Parser::readFixMessage, extractLength will extract the length of the message which is larger than m_buffer.size() because m_buffer is a string and the null character terminate the string in the middle of the message. This will in turn drop the whole character buffer in ThreadedSocketConnection::readQueue() even if the buffer could have a multiple FIX message in it. There is no exception or error log in such a scenario. How should QF handle this case? Thanks. -Yihu -----Original Message----- From: Caleb Epstein [mailto:cal...@gm...]=20 Sent: Thursday, October 28, 2004 9:06 AM To: Yihu Fang Cc: qui...@li...; Oren Miller Subject: Re: [Quickfix-developers] Field with embedded null character On Wed, 27 Oct 2004 21:23:04 -0400, Yihu Fang <yih...@re...> wrote: > However, in QuickFIX message constructor, it takes string as the parameter. > It will throw an invalid message exception because it thinks the string is > truncated at the null character and cannot find the Tag 10.=20 Make sure you construct the string you pass to the Message constructor properly. The std::string constructor can take a const char* with or without a length. If you don't pass the length, it'll stop at the first embedded \0 and you'll end up with a truncated message. That said, it does seem that QuickFIX has a bug in the message serialization code when dealing with fields having embedded \0 bytes: #include <quickfix/Message.h> #include <iostream> using namespace FIX; using namespace std; int main () { Message m; m.setField (1000, string ("one\0", 4)); cout << m.toString () << endl; cout << m.getField (1000) << endl; } Gives the output (where ^A =3D ASCII SOH and \0 is an ASCII NULL) 9=3D10^A1000=3D one^A10=3D057^A one\0 Note extra space and lack of \0 for serialized message form. --=20 Caleb Epstein cal...@gm... ----------------------------------------------------------------- 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. |
From: Yihu F. <Yih...@re...> - 2004-10-29 20:46:30
|
Caleb, Thanks for the patch. Oren, when you have an extra null byte, the bodylength value increases by 1. So the checksum should increase by 1 too. -Yihu -----Original Message----- From: Oren Miller [mailto:or...@qu...]=20 Sent: Friday, October 29, 2004 3:59 PM To: Caleb Epstein Cc: Yihu Fang; qui...@li... Subject: Re: [Quickfix-developers] Field with embedded null character I added some unit tests and it seems to work except for one problem. I=20 have a message that I'm passing into the messages constructor, which is=20 just a normal message. The checksum of this message is 218. The test=20 is that I send the same message in except I added a null character at=20 the end of one of the fields. It is able to parse everything fine, but=20 it determines that the checksum of the message with the null should be=20 219 and throws an Invalid message. Now since null has a value of 0 I=20 would expect that the checksum of these two messages should be=20 identical. Anybody see any flaw in this reasoning? --oren On Oct 29, 2004, at 9:37 AM, Caleb Epstein wrote: > Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary > changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to > deal with NUL bytes in messages. > > Clearly this must be a pretty uncommon need, otherwise it would have > been raised on this list before, but if anyone plans on using > encrypted messages or moving around messages with binary Data fields, > this patch would be a big win. > > --=20 > Caleb Epstein > cal...@gm... > <quickfix-1.9.2-allow-nuls.diff> ----------------------------------------------------------------- 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. |
From: Oren M. <or...@qu...> - 2004-10-29 20:53:07
|
Right! On Oct 29, 2004, at 3:43 PM, Yihu Fang wrote: > Caleb, Thanks for the patch. > > Oren, when you have an extra null byte, the bodylength value increases > by 1. So the checksum should increase by 1 too. > > -Yihu > > -----Original Message----- > From: Oren Miller [mailto:or...@qu...] > Sent: Friday, October 29, 2004 3:59 PM > To: Caleb Epstein > Cc: Yihu Fang; qui...@li... > Subject: Re: [Quickfix-developers] Field with embedded null character > > I added some unit tests and it seems to work except for one problem. I > have a message that I'm passing into the messages constructor, which is > just a normal message. The checksum of this message is 218. The test > is that I send the same message in except I added a null character at > the end of one of the fields. It is able to parse everything fine, but > it determines that the checksum of the message with the null should be > 219 and throws an Invalid message. Now since null has a value of 0 I > would expect that the checksum of these two messages should be > identical. Anybody see any flaw in this reasoning? > > --oren > > On Oct 29, 2004, at 9:37 AM, Caleb Epstein wrote: > >> Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary >> changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to >> deal with NUL bytes in messages. >> >> Clearly this must be a pretty uncommon need, otherwise it would have >> been raised on this list before, but if anyone plans on using >> encrypted messages or moving around messages with binary Data fields, >> this patch would be a big win. >> >> -- >> Caleb Epstein >> cal...@gm... >> <quickfix-1.9.2-allow-nuls.diff> > > > > > ----------------------------------------------------------------- > 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. > > |
From: Oren M. <or...@qu...> - 2004-10-29 21:45:02
|
Ok, I checked in the changes along with new unit tests for the Message and Parser classes. --oren On Oct 29, 2004, at 3:43 PM, Yihu Fang wrote: > Caleb, Thanks for the patch. > > Oren, when you have an extra null byte, the bodylength value increases > by 1. So the checksum should increase by 1 too. > > -Yihu > > -----Original Message----- > From: Oren Miller [mailto:or...@qu...] > Sent: Friday, October 29, 2004 3:59 PM > To: Caleb Epstein > Cc: Yihu Fang; qui...@li... > Subject: Re: [Quickfix-developers] Field with embedded null character > > I added some unit tests and it seems to work except for one problem. I > have a message that I'm passing into the messages constructor, which is > just a normal message. The checksum of this message is 218. The test > is that I send the same message in except I added a null character at > the end of one of the fields. It is able to parse everything fine, but > it determines that the checksum of the message with the null should be > 219 and throws an Invalid message. Now since null has a value of 0 I > would expect that the checksum of these two messages should be > identical. Anybody see any flaw in this reasoning? > > --oren > > On Oct 29, 2004, at 9:37 AM, Caleb Epstein wrote: > >> Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary >> changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to >> deal with NUL bytes in messages. >> >> Clearly this must be a pretty uncommon need, otherwise it would have >> been raised on this list before, but if anyone plans on using >> encrypted messages or moving around messages with binary Data fields, >> this patch would be a big win. >> >> -- >> Caleb Epstein >> cal...@gm... >> <quickfix-1.9.2-allow-nuls.diff> > > > > > ----------------------------------------------------------------- > 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. > > |
From: Caleb E. <cal...@gm...> - 2004-10-29 14:08:08
|
On Thu, 28 Oct 2004 16:54:46 -0400, Yihu Fang <yih...@re...> wrote: > Actually I am thinking what if a FIX engine sends a FIX message which > has embedded null character. After the message read off the socket > (which is a character array), the rest of the code is using STL string > to represent the message. A null character will basically truncate the > string. No, thats not correct. STL strings can contain \0 bytes. There are a couple of other bugs that are due to using char* buffers. In Parser.cpp, line 152 reads: m_buffer += m_readBuffer; This should be changed to: m_buffer.append (m_readBuffer, size); This fixes the sending side of things, but on the receive side, the ThreadedSocketConnection needs an overhaul to deal with data that could contain NUL bytes. The simplest change would probably be to use a Queue<std::pair<size_t, char*> > and just include the length along with each buffer. -- Caleb Epstein cal...@gm... |
From: Caleb E. <cal...@gm...> - 2004-10-29 14:38:11
Attachments:
quickfix-1.9.2-allow-nuls.diff
|
Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to deal with NUL bytes in messages. Clearly this must be a pretty uncommon need, otherwise it would have been raised on this list before, but if anyone plans on using encrypted messages or moving around messages with binary Data fields, this patch would be a big win. -- Caleb Epstein cal...@gm... |
From: Oren M. <or...@qu...> - 2004-10-29 19:59:33
|
I added some unit tests and it seems to work except for one problem. I have a message that I'm passing into the messages constructor, which is just a normal message. The checksum of this message is 218. The test is that I send the same message in except I added a null character at the end of one of the fields. It is able to parse everything fine, but it determines that the checksum of the message with the null should be 219 and throws an Invalid message. Now since null has a value of 0 I would expect that the checksum of these two messages should be identical. Anybody see any flaw in this reasoning? --oren On Oct 29, 2004, at 9:37 AM, Caleb Epstein wrote: > Attached is a comprehensive patch to QuickFIX 1.9.2 with the necessary > changes to Field.h, Parser.cpp and ThreadedSocketConnector.{cpp,h} to > deal with NUL bytes in messages. > > Clearly this must be a pretty uncommon need, otherwise it would have > been raised on this list before, but if anyone plans on using > encrypted messages or moving around messages with binary Data fields, > this patch would be a big win. > > -- > Caleb Epstein > cal...@gm... > <quickfix-1.9.2-allow-nuls.diff> |