{{Quickfixn}} Invalid body length

treffeisen ltd. director at treffeisen.net
Tue Jan 22 01:18:17 PST 2013 

Grant,
	Got it, field 9 needs to have the correct field length then it is successful.
So are you confident that this will work now?

Thanks,
	André

-----Original Message-----
From: Grant Birchmeier [mailto:gbirchmeier at connamara.com] 
Sent: 21 January 2013 22:37
To: director at treffeisen.net
Cc: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} Invalid body length

(Oops, resending to correct quickfixn list address.)

On Mon, Jan 21, 2013 at 4:35 PM, Grant Birchmeier
<gbirchmeier at connamara.com> wrote:
> I don't entirely understand your question; but I'll try my best.
>
> Your test is failing because it's wrong.  The test checks for length
> 1115, and it fails because it finds 1116.  (So I guess 7/8 is 2
> bytes.)  Basically, your test is failing because it trying to assert
> that 2+2=5.  If you fix your test, it will pass.
>
> Yes, UTF characters can be multibyte.  In the existing QF/n release,
> the engine is computing BodyLength and Checksum by counting characters
> (not bytes).  Basic letters and numbers are single-byte, so with those
> it's the same if you compute by byte or by char.  UTF can be
> multibyte, so that's when the errors occur.  (Our original tests only
> used ASCII, and that's why we missed it.)
>
> I'm not clear if my branch is failing for you in production.  Your
> earlier mails imply that you are focusing on the unit test.
>
> In my branch, please see unit test ReadFixMessageWithNonAscii, which
> demonstrates proper parsing of the two-byte UTF character "é" (e with
> an accent).
> https://github.com/gbirchmeier/quickfixn/blob/97/UnitTests/ParserTest.cs
>
> I also made an acceptance test that verifies that the AcceptanceTest
> app can receive and send the "é" character.
> You can also see an acceptance testuses that same character:
> https://github.com/gbirchmeier/quickfixn/blob/97/AcceptanceTest/definitions/server/fix44/InternationalCharacters.def
>
> -Grant
>
>
>
>
> On Mon, Jan 21, 2013 at 4:05 PM, treffeisen ltd.
> <director at treffeisen.net> wrote:
>> Grant,
>>         Hmm, got that mixed up - was late yesterday.
>> So it is about body length, which is not calculated correct. I still don't get the problem, anything I can do to fix? Could you explain why that goes wrong.
>> You mentioned in one post that the 7/8 is two bytes not one, that is normal in a UTF charset, right? So why is it first counted as one byte?
>>
>> Thanks,
>>         anmatr
>>
>> -----Original Message-----
>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>> Sent: 21 January 2013 00:52
>> To: director at treffeisen.net
>> Subject: Re: {{Quickfixn}} Invalid body length
>>
>> And I forgot to put it back on-list.  Nice.
>>
>> On Sun, Jan 20, 2013 at 6:17 PM, Grant Birchmeier <gbirchmeier at connamara.com> wrote:
>>> (Somehow we got off-list.  Hope you don't mind me putting this back on
>>> the list.)
>>>
>>> This is about BodyLength, not Checksum.  The Unit Test result you show
>>> is failing on the bodylength test, not checksum.
>>>
>>> BodyLength is easy to count: it's the byte count (*not* character
>>> count) starting at tag 35 (included) all the way to tag 10 (excluded).
>>> The SOH separators are included.
>>>
>>> CheckSum... I probably should write a small ruby script to calculate
>>> it, but I haven't.  The algorithm is to sum up the int value of all
>>> the bytes (except the checksum field, of course) and then modulo 256.
>>> (e.g. sum % 256).
>>>
>>> -Grant
>>>
>>>
>>> On Sun, Jan 20, 2013 at 4:40 PM, treffeisen ltd.
>>> <director at treffeisen.net> wrote:
>>>> Grant,
>>>>         Yes I am aware that the correct checksum has to be calculated first and given in field 10. I haven't done that and don't have an easy way of doing this. Did you manage to get a right test with a correct checksum given?
>>>>
>>>> (I first would need to dig out the old java framework where I have a
>>>> tool to calculate the checksum first. But lack of time today .... if
>>>> you could help out please?)
>>>>
>>>> Thanks,
>>>>         André
>>>>
>>>> -----Original Message-----
>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>> Sent: 20 January 2013 22:28
>>>> To: director at treffeisen.net
>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>
>>>> Er, in your recent test you changed 0x0100 to "7/8", but it's the
>>>> same problem.  (Actually, 7/8 might be 3 bytes.  Not sure.)
>>>>
>>>> -Grant
>>>>
>>>>
>>>> On Sun, Jan 20, 2013 at 4:19 PM, Grant Birchmeier <gbirchmeier at connamara.com> wrote:
>>>>> Did you see my Jan 4th email?  Your test is incorrect.  The \x0100
>>>>> character is two bytes long.  Therefore, the fixMsg2 is indeed one
>>>>> byte longer than fixMsg1, and the length field needs to be adjusted
>>>>> accordingly.  1116 is the correct length.
>>>>>
>>>>> -Grant
>>>>>
>>>>>
>>>>> On Sun, Jan 20, 2013 at 3:41 PM, treffeisen ltd.
>>>>> <director at treffeisen.net> wrote:
>>>>>> Grant,
>>>>>>
>>>>>>       Unfortunately I still get the same error - the checksum
>>>>>> calculation throws an error. I checked out branch 97 and compared
>>>>>> it to the earlier version I have and I saw you change to UTF8 encoding, right?
>>>>>>
>>>>>>
>>>>>>
>>>>>> What kind of logs would you like? I just get the usual error:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Errors and Failures:
>>>>>>
>>>>>> 1) Test Error : UnitTests.ParserTest.ReadFixMessageNEW
>>>>>>
>>>>>>    QuickFix.MessageParseError : Could not parse message: Invalid
>>>>>> body length. Calculated:1116 expected:1115
>>>>>>
>>>>>>    at QuickFix.Parser.ReadFixMessage(String& msg) in
>>>>>> D:\_Project_AMT\C#\quickfixn-97.1\QuickFIXn\Parser.cs:line 80
>>>>>>
>>>>>>    at UnitTests.ParserTest.ReadFixMessageNEW() in
>>>>>> D:\_Project_AMT\C#\quickfixn-97.1\UnitTests\ParserTest.cs:line 118
>>>>>>
>>>>>>
>>>>>>
>>>>>> This can also be seen by running the NUnit test (unit_test.bat)
>>>>>> with the test ReadFixMessageNEW which is provided already. It’s attached again.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I’ve never got the actual message sent in a proper format to use
>>>>>> and test it. Bloomberg support is not helpful on this issue. Here
>>>>>> is what I have got sent from them:
>>>>>>
>>>>>> 12:41:32.956 TX
>>>>>> 8=FIX.4.4|9=1164|35=AE|49=BLP|56=JCAMVCON|34=1878|57=5454321|115=i.
>>>>>> VC
>>>>>> ONSRV|43=Y|122=20121205-16:25:52|52=20121205-17:41:32|60=20121205-16:
>>>>>> 25:52|570=N|31=99.609375|571=00006499:0117:1a3a:50be9d1f|32=850000|
>>>>>> 42
>>>>>> 3=1|573=1|64=20121206|487=2|818=5818467426611495718|460=6|880=3739:
>>>>>> 20
>>>>>> 121205:50680:6|854=1|75=20121205|856=7|167=TBOND|48=US912810QX90|22
>>>>>> 8=
>>>>>> 1|231=1|22=4|55=[N/A]|235=WORST|236=2.769272|9610=3|9611=BOOK|9613=
>>>>>> 1|CS
>>>>>> 80/20|9611=STRATEGY|9613=CORP - US|9611=
>>>>>> |454=3|455=912810QX9|456=1|455=912810QX|456=A|455=US912810QX90|456=
>>>>>> |4| 552=1|54=1|37=MANUAL|453=3|448=OLIVER
>>>>>> RISSO-GILL @ RBS SECURITIES INC : 5784450 @
>>>>>> 1999|447=D|452=1|802=8|523=RBS|803=1|523=1999|803=4014|523=RBS
>>>>>> 1999|SECURITIES
>>>>>> INC|803=4015|523=30030569|803=4016|523=STAMFORD|803=34|523=US|803=3
>>>>>> INC|8| 523=RBSM|803=4010|523=RBS|803=4013|448=DREW
>>>>>> CHINTALA @ JAE CREDIT MANAGEMENT LP : 5454321 @
>>>>>> 755803|447=D|452=11|802=7|523=755803|803=4005|523=JAE CREDIT
>>>>>> MANAG|803=1|523=755803|803=4014|523=JAE CREDIT MANAGEMENT
>>>>>> LP|803=4015|523=30082871|803=4016|523=NEW
>>>>>> YORK|803=34|523=US|803=38|448=SXT|447=D|452=16|15=USD|381=846679.68
>>>>>> YORK|99
>>>>>> YORK|999999|159=7177.65|118=853857.34|58=RBS
>>>>>> SELLS TO JAE @ 99-19+ VS BUYING 1MM INTC 4¼'42 @ +143/CT30o
>>>>>> |9503=N|10=174|
>>>>>>
>>>>>>
>>>>>> 12:41:32.956 TX
>>>>>> 8=FIX.4.4|9=1183|35=AE|49=BLP|56=JCAMVCON|34=1879|57=5454321|115=i.
>>>>>> VC
>>>>>> ONSRV|43=Y|122=20121205-16:26:05|52=20121205-17:41:32|60=20121205-16:
>>>>>> 26:05|570=N|31=99.609375|571=000064a3:0117:1a3a:50be9d1f|32=850000|
>>>>>> 42 3=1|64=20121206|487=2|818=5818467426611495718|1328=No
>>>>>> reason
>>>>>> provided.|460=6|880=3739:20121205:50680:6|854=1|75=20121205|856=3|1
>>>>>> 67
>>>>>> =TBOND|48=US912810QX90|228=1|231=1|22=4|55=[N/A]|235=WORST|236=2.76
>>>>>> 92
>>>>>> 72|9610=3|9611=BOOK|9613=CS 80/20|9611=STRATEGY|9613=CORP -
>>>>>> 72|US|9611=
>>>>>> |454=3|455=912810QX9|456=1|455=912810QX|456=A|455=US912810QX90|456=
>>>>>> |4| 552=1|54=1|37=MANUAL|453=3|448=OLIVER
>>>>>> RISSO-GILL @ RBS SECURITIES INC : 5784450 @
>>>>>> 1999|447=D|452=1|802=8|523=RBS|803=1|523=1999|803=4014|523=RBS
>>>>>> 1999|SECURITIES
>>>>>> INC|803=4015|523=30030569|803=4016|523=STAMFORD|803=34|523=US|803=3
>>>>>> INC|8| 523=RBSM|803=4010|523=RBS|803=4013|448=DREW
>>>>>> CHINTALA @ JAE CREDIT MANAGEMENT LP : 5454321 @
>>>>>> 755803|447=D|452=11|802=7|523=755803|803=4005|523=JAE CREDIT
>>>>>> MANAG|803=1|523=755803|803=4014|523=JAE CREDIT MANAGEMENT
>>>>>> LP|803=4015|523=30082871|803=4016|523=NEW
>>>>>> YORK|803=34|523=US|803=38|448=SXT|447=D|452=16|15=USD|381=846679.68
>>>>>> YORK|99
>>>>>> YORK|999999|159=7177.65|118=853857.34|58=RBS
>>>>>> SELLS TO JAE @ 99-19+ VS BUYING 1MM INTC 4¼'42 @ +143/CT30o
>>>>>> |9503=N|10=218|
>>>>>>
>>>>>> It is in field 58 where most likely the character for a quarter ¼
>>>>>> causes the issue.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Attached is a message from the time when we had the old interface
>>>>>> running with the java quickfix framework. In that message in field
>>>>>> 58 you can find a character which I think would produce the same problem:
>>>>>>
>>>>>> 58=*****VS RABOBK 3⅞ '22 NEW ISSUE****
>>>>>>
>>>>>> It is the fraction 7 parts of 8. Maybe you can use this message
>>>>>> data somehow. I have done the test with this character and got the
>>>>>> same error with your latest changed branch using the UTF8 encoding.
>>>>>> So I guess it is the same problem still not fixed.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hope that helps. Thanks for your time.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kind Regards,
>>>>>>
>>>>>>                 André
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>>>> Sent: 04 January 2013 21:37
>>>>>> To: director at treffeisen.net
>>>>>>
>>>>>>
>>>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>>>
>>>>>>
>>>>>>
>>>>>> Anmater, your test fails because your fixMsg2 is invalid.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The \x0100 character is two bytes long.  Therefore, the fixMsg2 is
>>>>>> indeed one byte longer than fixMsg1, and the length field needs to
>>>>>> be adjusted accordingly.
>>>>>>
>>>>>>
>>>>>>
>>>>>> So, with my branch build on your actual connection, do you see the
>>>>>> same exact "invalid body length" error from your original email?
>>>>>>
>>>>>>
>>>>>>
>>>>>> If yes, could you send a message log that includes that message and
>>>>>> the reject and a bit of the surrounding context?  (I'm wondering if
>>>>>> your counterparty might be calculating the length wrong, using
>>>>>> character count rather than byte count.)
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Dec 23, 2012 at 10:54 AM, Grant Birchmeier
>>>>>> <gbirchmeier at connamara.com> wrote:
>>>>>>
>>>>>> Thanks, Anmatr.  I'm going to try to look further into this this
>>>>>> week (if I can make time around the various holiday stuff I have going on).
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 20, 2012 at 8:54 AM, treffeisen ltd.
>>>>>> <director at treffeisen.net>
>>>>>> wrote:
>>>>>>
>>>>>> Grant,
>>>>>>
>>>>>>                 Thanks, that sound promising.
>>>>>>
>>>>>> I have used the branch to do some testing on a message that caused
>>>>>> the issue. But unfortunately it still shows that error. Attached is
>>>>>> the ParserTest.cs class with the added test method ReadFixMessageNEW.
>>>>>> You will see the error as before:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Errors and Failures:
>>>>>>
>>>>>> 1) Test Error : UnitTests.ParserTest.ReadFixMessageNEW
>>>>>>
>>>>>>    QuickFix.MessageParseError : Could not parse message: Invalid
>>>>>> body length. Calculated:1116 expected:1115
>>>>>>
>>>>>>    at QuickFix.Parser.ReadFixMessage(String& msg) in
>>>>>> D:\_Project_AMT\C#\quickfixn-97\QuickFIXn\Parser.cs:line 80
>>>>>>
>>>>>>    at UnitTests.ParserTest.ReadFixMessageNEW() in
>>>>>> D:\_Project_AMT\C#\quickfixn-97\UnitTests\ParserTest.cs:line 118
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>                 Anmatr
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>>>> Sent: 20 December 2012 00:12
>>>>>> To: director at treffeisen.net
>>>>>> Cc: Mailing list for QuickFIX/n
>>>>>>
>>>>>>
>>>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>>>
>>>>>>
>>>>>>
>>>>>> I actually started integrating a submitted patch last week.  I
>>>>>> think it's nearly done, actually, but I need to extend our test
>>>>>> framework too in order to properly test it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If you'd like, though, you can build my branch and see if it is
>>>>>> working for
>>>>>> you:
>>>>>>
>>>>>> https://github.com/gbirchmeier/quickfixn/tree/97
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 19, 2012 at 5:43 PM, treffeisen ltd.
>>>>>> <director at treffeisen.net>
>>>>>> wrote:
>>>>>>
>>>>>> I’ve got to pick this up again as it turns out to be a real problem
>>>>>> on our client now. Is there any way I could do a hack just for my
>>>>>> version to get this message handled? It would be good to get the
>>>>>> noise out as we keep getting errors on our interface.
>>>>>>
>>>>>> I have already contacted the sender (Bloomberg) and I can only hope
>>>>>> that they pick this up on their side. But that will not be fixed soon, if at all.
>>>>>> We used the java quickfix/J before and that seemed more robust.
>>>>>>
>>>>>> Still there is no other option then quickfix/N now so we need to
>>>>>> continue on that.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If you could point me to the direction, I’d highly appreciate.
>>>>>> Maybe I find a solution which could be accepted in your next
>>>>>> release? Not a promise, just worth a try I guess.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Again, thanks for your time on this!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Anmatr.
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>>>> Sent: 07 December 2012 16:27
>>>>>>
>>>>>>
>>>>>> To: director at treffeisen.net; Mailing list for QuickFIX/n
>>>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>>>
>>>>>>
>>>>>>
>>>>>> I don't know an easy way around this at this time.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Don't overlook the fact that the message you're receiving is
>>>>>> technically illegal, and your counterparty should be notified about
>>>>>> it.  They are using non-ASCII in a field that should only be ASCII.
>>>>>>
>>>>>>
>>>>>>
>>>>>> That said, QF/n does have an associated bug.  If a message has
>>>>>> non-ASCII in fields where non-ASCII is allowed, then it's QF/n's
>>>>>> fault.  Fixing this bug will make QF/n tolerant of your
>>>>>> counterparty's bad message, but that doesn't make your counterparty ok.
>>>>>>
>>>>>>
>>>>>>
>>>>>> But I'm nitpicking, I guess.  Really, we need to just fix the bug.
>>>>>> I think we'll try to do that for the next release, which should be
>>>>>> within two months at most.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 6, 2012 at 1:41 AM, treffeisen ltd.
>>>>>> <director at treffeisen.net>
>>>>>> wrote:
>>>>>>
>>>>>> Grant,
>>>>>>
>>>>>>                 Thank you for the quick response on  this.
>>>>>>
>>>>>> Is there a way to catch the exception thrown so I can ignore or
>>>>>> skip the message?
>>>>>>
>>>>>> As this is happening in the SocketInitiatorThread I see that there
>>>>>> is an immediate disconnect when an exception is thrown.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>                 anmatr
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>>>> Sent: 05 December 2012 20:43
>>>>>> To: director at treffeisen.net; Mailing list for QuickFIX/n
>>>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, this is a known bug.  We're not computing the checksum
>>>>>> correctly for non ASCII characters.  An issue is open for it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Note, though, that the message you've presented is technically
>>>>>> invalid.  FIX messages are supposed to be all-ASCII, except for
>>>>>> fields named "Encoded<whatever>".  Field 58 ("Text") is not one of
>>>>>> those, and thus should not have non-ASCII in it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> In practice, counterparties can be stupid, though, and QF/n should
>>>>>> probably be tolerant of non-ASCII, at least as far as the checksum is concerned.
>>>>>>
>>>>>>
>>>>>>
>>>>>> You should let your sender know that this message is technically illegal.
>>>>>> Unfortunately I don't see a ready workaround at this time.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 5, 2012 at 2:20 PM, treffeisen ltd.
>>>>>> <director at treffeisen.net>
>>>>>> wrote:
>>>>>>
>>>>>> All,
>>>>>>
>>>>>>         I think this was it in the list as “Checksum problem”.
>>>>>>
>>>>>> 20121205-14:46:29.623 : Session FIX.4.4:SOURCE->TARGET disconnecting:
>>>>>> QuickFix.MessageParseError: Could not parse message: Invalid body
>>>>>> length
>>>>>>
>>>>>>    at QuickFix.Parser.ReadFixMessage(String& msg)
>>>>>>
>>>>>>    at QuickFix.SocketInitiatorThread.ProcessStream()
>>>>>>
>>>>>>    at QuickFix.SocketInitiatorThread.Read()
>>>>>>
>>>>>> There is an odd character in a comment field and it seems that the
>>>>>> checksum calculation does not handle that.
>>>>>>
>>>>>> 58=xyz SELLS TO JAE @ 99-19+ VS BUYING 1MM INTC 4¼'42 @ +143/CT30
>>>>>>
>>>>>> It is in this custom field 58 and might be the character after the
>>>>>> first sequence INTC 4 (not sure if that is displayed properly on the forum).
>>>>>>
>>>>>> We use quckfix/n version 1.3.0
>>>>>>
>>>>>> Is this a known problem?
>>>>>>
>>>>>> Any help is highly appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>         Anmatr.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Quickfixn mailing list
>>>>>> Quickfixn at lists.quickfixn.com
>>>>>> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Grant Birchmeier
>>>>>>
>>>>>> Connamara Systems, LLC
>>>>>>
>>>>>> Made-To-Measure Trading Solutions.
>>>>>>
>>>>>> Exactly what you need. No more. No less.
>>>>>>
>>>>>> http://connamara.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Quickfixn mailing list
>>>>>> Quickfixn at lists.quickfixn.com
>>>>>> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Grant Birchmeier
>>>>>>
>>>>>> Connamara Systems, LLC
>>>>>>
>>>>>> Made-To-Measure Trading Solutions.
>>>>>>
>>>>>> Exactly what you need. No more. No less.
>>>>>>
>>>>>> http://connamara.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Grant Birchmeier
>>>>>>
>>>>>> Connamara Systems, LLC
>>>>>>
>>>>>> Made-To-Measure Trading Solutions.
>>>>>>
>>>>>> Exactly what you need. No more. No less.
>>>>>>
>>>>>> http://connamara.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Grant Birchmeier
>>>>>>
>>>>>> Connamara Systems, LLC
>>>>>>
>>>>>> Made-To-Measure Trading Solutions.
>>>>>>
>>>>>> Exactly what you need. No more. No less.
>>>>>>
>>>>>> http://connamara.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Grant Birchmeier
>>>>>>
>>>>>> Connamara Systems, LLC
>>>>>>
>>>>>> Made-To-Measure Trading Solutions.
>>>>>>
>>>>>> Exactly what you need. No more. No less.
>>>>>>
>>>>>> http://connamara.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Grant Birchmeier
>>>>> Connamara Systems, LLC
>>>>> Made-To-Measure Trading Solutions.
>>>>> Exactly what you need. No more. No less.
>>>>> http://connamara.com
>>>>
>>>>
>>>>
>>>> --
>>>> Grant Birchmeier
>>>> Connamara Systems, LLC
>>>> Made-To-Measure Trading Solutions.
>>>> Exactly what you need. No more. No less.
>>>> http://connamara.com
>>>>
>>>
>>>
>>>
>>> --
>>> Grant Birchmeier
>>> Connamara Systems, LLC
>>> Made-To-Measure Trading Solutions.
>>> Exactly what you need. No more. No less.
>>> http://connamara.com
>>
>>
>>
>> --
>> Grant Birchmeier
>> Connamara Systems, LLC
>> Made-To-Measure Trading Solutions.
>> Exactly what you need. No more. No less.
>> http://connamara.com
>>
>
>
>
> --
> Grant Birchmeier
> Connamara Systems, LLC
> Made-To-Measure Trading Solutions.
> Exactly what you need. No more. No less.
> http://connamara.com



-- 
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.
http://connamara.com

More information about the Quickfixn mailing list