quickfix-developers Mailing List for QuickFIX (Page 252)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Vamsi K. <Vam...@ib...> - 2004-02-26 22:15:16
|
Oren Is there an effort to bring out pure java version of fixengine? Thanks Vamsi |
|
From: James C. D. <jc...@co...> - 2004-02-26 20:20:01
|
PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRy YW5zaXRpb25hbC8vRU4iPgo8SFRNTD48SEVBRD4KCjxUSVRMRT5bUXVpY2tmaXgtZGV2ZWxvcGVy c10gUXVpY2tmaXggYWNjZXB0YW5jZSB0ZXN0cy48L1RJVExFPgoKPE1FVEEgY29udGVudD0iTVNI VE1MIDYuMDAuMjgwMC4xMjY0IiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+CjxCT0RZIGRpcj1sdHI+ CjxESVY+VGltLDwvRElWPgo8RElWPlRoZSBvdGhlciAobW9yZSBsYWJvcmlvdXMpIGlkZWEmbmJz cDtpcyB0byBleGFtaW5lIHRoZSBleGlzdGluZyB0ZXN0cyBhbmQgCnNlZSBpZiB3aGVyZSB3ZSBz aG91ZGwgYmUgc2VuZGluZyBhIGxvZ291dCBtZXNzc2FnZSBpbnN0ZWQgb2YganVzdCAKZGlzY29u bmVjdGluZyw8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5KaW08L0RJVj4KPEJMT0NLUVVP VEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPgogIDxESVY+PEZPTlQgc2l6ZT0y Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxCUj48Qj5Gcm9tOjwvQj4gVGltb3RoeSBZYXRl cyAKICBbbWFpbHRvOnR5YXRlc0BwYXRzeXN0ZW1zLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiBUaHUg Mi8yNi8yMDA0IDE6NTYgUE0gCiAgPEJSPjxCPlRvOjwvQj4gSmFtZXMgQy4gRG93bnM7IFRpbW90 aHkgWWF0ZXM7IAogIHF1aWNrZml4LWRldmVsb3BlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0IDxC Uj48Qj5DYzo8L0I+IExlbm55IFNobGV5bW92aWNoIAogIDxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6 IFtRdWlja2ZpeC1kZXZlbG9wZXJzXSBRdWlja2ZpeCBhY2NlcHRhbmNlIAogIHRlc3RzLjxCUj48 QlI+PC9GT05UPjwvRElWPgogIDxESVY+PFNQQU4gY2xhc3M9NDY4NTc1NDE5LTI2MDIyMDA0PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+WWVzLCAKICB0aGlzIHdvcmtzLiZu YnNwOyBJIGhhZCBkb25lIHRoaXMgYWxyZWFkeS48L0ZPTlQ+PC9TUEFOPjwvRElWPgogIDxESVY+ PFNQQU4gY2xhc3M9NDY4NTc1NDE5LTI2MDIyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiAKICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4KICA8RElWPjxTUEFOIGNs YXNzPTQ2ODU3NTQxOS0yNjAyMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPkkgCiAgbW9kaWZpZWQgc2V0dXAuYmF0IHRvIGNyZWF0ZSB0d28gLmNmZyBmaWxlcywgb25l IG9mIHdoaWNoIGRvZXMgbm90IHJlc2V0IAogIHNlcXVlbmNlIG51bWJlcnMgb24gZGlzY29ubmVj dC48L0ZPTlQ+PC9TUEFOPjwvRElWPgogIDxESVY+PFNQQU4gY2xhc3M9NDY4NTc1NDE5LTI2MDIy MDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiAKICBzaXplPTI+PC9GT05UPjwvU1BB Tj4mbmJzcDs8L0RJVj4KICA8RElWPjxTUEFOIGNsYXNzPTQ2ODU3NTQxOS0yNjAyMjAwND48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgCiAgc2l6ZT0yPk9idmlvdXNseSwgeW91IGNhbiB0 aGVuIG9ubHkgcnVuIG9uZSB0ZXN0IGF0IGEgdGltZSB3aXRoIHRoZSBuZXcgLmNmZyAKICBmaWxl IGlmIHlvdSB3YW50IHlvdXIgdGVzdHMgdG8gYmUgaW5kZXBlbmRlbnQuPC9GT05UPjwvU1BBTj48 L0RJVj4KICA8RElWPjxTUEFOIGNsYXNzPTQ2ODU3NTQxOS0yNjAyMjAwND48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSMwMDAwZmYgCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+CiAg PERJVj48U1BBTiBjbGFzcz00Njg1NzU0MTktMjYwMjIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIAogIHNpemU9Mj5UaW0uPC9GT05UPjwvU1BBTj48L0RJVj4KICA8QkxPQ0tRVU9U RSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CiAgICA8RElWIGNsYXNzPU91dGxv b2tNZXNzYWdlSGVhZGVyIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPVRhaG9tYSAKICAg IHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gSmFtZXMg Qy4gRG93bnMgCiAgICBbbWFpbHRvOmpjZG93bnNAY29ubmFtYXJhLmNvbV08QlI+PEI+U2VudDo8 L0I+IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAwNCAKICAgIDEyOjUzIFBNPEJSPjxCPlRvOjwv Qj4gVGltb3RoeSBZYXRlczsgCiAgICBxdWlja2ZpeC1kZXZlbG9wZXJzQGxpc3RzLnNvdXJjZWZv cmdlLm5ldDxCUj48Qj5DYzo8L0I+IExlbm55IAogICAgU2hsZXltb3ZpY2g8QlI+PEI+U3ViamVj dDo8L0I+IFJFOiBbUXVpY2tmaXgtZGV2ZWxvcGVyc10gUXVpY2tmaXggYWNjZXB0YW5jZSAKICAg IHRlc3RzLjxCUj48QlI+PC9GT05UPjwvRElWPgogICAgPERJVj5vb3BzISBUaGUgYXQuY2ZnIGZp bGUgaXMgYWN0dWFsbHkgcmVjcmVhdGVkIHdpdGggZWFjaCBydW5uaW5nIG9mIAogICAgcnVuYXQu YmF0IHRocm91Z2ggYW5vdGhlciBiYXRjaCBmaWxlIGNhbGxlZCBzZXR1cC5iYXQuIENoYW5naW5n IHNldHVwLmJhdCwgCiAgICB3aGljaCByZXN1bHRzIGluIGFjdHVhbGx5IGNoYW5naW5nIGF0LmNm ZywgY2F1c2VzIG51bWVyb3VzIHRlc3RzIHRvIGZhaWwuIFNvIAogICAgaXQgbG9va3MgbGlrZSB0 aGlzIGlzIG5vdCBhcyBzaW1wbGUgYSBjaGFuZ2UgYXMgSSBmaXJzdCB0aG91Z2h0LiBJIHdvdWxk IAogICAgdGhpbmsgdGhhdCBhIHNvbHV0aW9uIGluIHRoaXMgY2FzZSBpcyB0byByZW1vdmUgdGhl IHNldHVwLmJhdCBjYWxsIGluIAogICAgcnVuYXQuYmF0IGFuZCBydW5hdC5leGUgdHdpY2UsIHNw ZWNpZml5aW5nIGEgZGlmZmVyZW50IHNldCBvZiB0ZXN0cyBhbmQgYSAKICAgIGRpZmZlcmVudCBR RiBjZmcgZmlsZS48L0RJVj4KICAgIDxESVY+Jm5ic3A7PC9ESVY+CiAgICA8RElWPkppbSBEb3du czwvRElWPgogICAgPERJVj5Db25uYW1hcmEgU3lzdGVtczwvRElWPgogICAgPEJMT0NLUVVPVEUg ZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPgogICAgICA8RElWPjxGT05UIHNpemU9 Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8QlI+PEI+RnJvbTo8L0I+IAogICAgICBxdWlj a2ZpeC1kZXZlbG9wZXJzLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCZuYnNwO29uIGJlaGFs ZiAKICAgICAgb2YmbmJzcDtUaW1vdGh5IFlhdGVzIDxCUj48Qj5TZW50OjwvQj4gVGh1IDIvMjYv MjAwNCAxMToyMyBBTSAKICAgICAgPEJSPjxCPlRvOjwvQj4gJ3F1aWNrZml4LWRldmVsb3BlcnNA bGlzdHMuc291cmNlZm9yZ2UubmV0JyA8QlI+PEI+Q2M6PC9CPiAKICAgICAgTGVubnkgU2hsZXlt b3ZpY2ggPEJSPjxCPlN1YmplY3Q6PC9CPiBbUXVpY2tmaXgtZGV2ZWxvcGVyc10gUXVpY2tmaXgg CiAgICAgIGFjY2VwdGFuY2UgdGVzdHMuPEJSPjxCUj48L0ZPTlQ+PC9ESVY+CiAgICAgIDxQPjxG T05UIHNpemU9Mj5UaGUgYXV0b21hdGVkIGFjY2VwdGFuY2UgdGVzdHMgZm9yIHF1aWNrZml4IGFy ZSBpbXByZXNzaXZlIAogICAgICBidXQgaGF2ZSBzb21lPEJSPnZlcnkgc2lnbmlmaWNhbnQgaG9s ZXMuPEJSPjxCUj5Gb3IgZXhhbXBsZSwgdGhlIHRlc3RzIAogICAgICBzdXJyb3VuZGluZyBwcm9j ZXNzaW5nIG9mIHJlc2VuZCByZXF1ZXN0cyBkbyBub3Q8QlI+Y292ZXIgdGhlIG1vc3QgY29tbW9u IAogICAgICByZXNlbmQgc2NlbmFyaW8sIG5hbWVseSBsb3NzIG9mIHN5bmNocm9uaXphdGlvbiBh ZnRlcjxCUj5hbiB1bmV4cGVjdGVkIAogICAgICBsb3NzIG9mIHRoZSBUQ1AgY29ubmVjdGlvbi4m bmJzcDsmbmJzcDsgQWxsIHRoZSBhY2NlcHRhbmNlIHRlc3RzIAogICAgICBhc3N1bWU8QlI+dGhh dCBzZXF1ZW5jZSBudW1iZXJzIGFyZSBzZXQgdG8gMSBhdCBldmVyeSBsb2dvbi4mbmJzcDsgCiAg ICAgIEhvd2V2ZXIsIGl0IGlzIHVzdWFsbHk8QlI+YXQgbG9nb24gdGhhdCB0aGUgbWlzc2luZyBt ZXNzYWdlcyBhcmUgCiAgICAgIGRldGVjdGVkLjxCUj48QlI+T25lIHNob3VsZG4ndCwgdGhlcmVm b3JlLCBzaG91bGRuJ3QgZ2V0IHRvbyBjb21wbGFjZW50IAogICAgICBhYm91dCB0aGUgcm9idXN0 bmVzczxCUj5vZiB0aGUgcXVpY2tmaXggc2Vzc2lvbiBsZXZlbCBjb2RlLCBlc3BlY2lhbGx5IAog ICAgICB3aGVuIGl0IGlzIHRhbGtpbmcgdG8gYSBidWdneTxCUj5wZWVyIGZpeCBhcHAgKGUuZy4g b25lIHRoYXQgb2Z0ZW4gCiAgICAgIGNyYXNoZXMpLCBvciBvdmVyIGFuIHVucmVsaWFibGUgbmV0 d29yazxCUj5jb25uZWN0aW9uLjxCUj48QlI+VGltIAogICAgICBZYXRlczxCUj5MZWFkIERldmVs b3BlcjxCUj5QYXRzeXN0ZW1zIChVUykgTExDPEJSPjE0MSBXZXN0IEphY2tzb24gCiAgICAgIEJv dWxldmFyZDxCUj5DaGljYWdvIDYwNjA0LCBVU0E8QlI+VGVsICsxICgzMTIpIAogICAgICA1NDIt MTMzNjxCUj53d3cucGF0c3lzdGVtcy5jb208QlI+PEJSPjxCUj5ESVNDTEFJTUVSOiBUaGlzIGUt bWFpbCBpcyAKICAgICAgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBsZWdhbGx5IHByaXZp bGVnZWQuPEJSPklmIHlvdSBhcmUgbm90IHRoZSAKICAgICAgaW50ZW5kZWQgcmVjaXBpZW50LCB1 c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbjxCUj50aGlzIGUtbWFpbCAKICAgICAg KGluY2x1ZGluZyBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbikgaXMgcHJvaGli aXRlZDxCUj5hbmQgbWF5IAogICAgICBiZSB1bmxhd2Z1bC4mbmJzcDsgUGxlYXNlIGluZm9ybSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIAogICAgICBtZXNzYWdlPEJSPmltbWVkaWF0ZWx5IGZy b20geW91ciBzeXN0ZW0uJm5ic3A7IFRoaXMgZS1tYWlsIGlzIGF0dHJpYnV0ZWQgCiAgICAgIHRv IHRoZSBzZW5kZXIgYW5kPEJSPm1heSBub3QgbmVjZXNzYXJpbHkgcmVmbGVjdCB0aGUgdmlld3Mg b2YgdGhlIAogICAgICBQYXRzeXN0ZW1zIEdyb3VwIGFuZCBubyBtZW1iZXI8QlI+b2YgdGhlIFBh dHN5c3RlbXMgR3JvdXAgYWNjZXB0cyBhbnkgCiAgICAgIGxpYWJpbGl0eSBmb3IgYW55IGFjdGlv biB0YWtlbiBpbjxCUj5yZWxpYW5jZSBvbiB0aGUgY29udGVudHMgb2YgdGhpcyAKICAgICAgZS1t YWlsIChvdGhlciB0aGFuIHdoZXJlIGl0IGhhcyBhIGxlZ2FsIG9yPEJSPnJlZ3VsYXRvcnkgb2Js aWdhdGlvbiB0byBkbyAKICAgICAgc28pIG9yIGZvciB0aGUgY29uc2VxdWVuY2VzIG9mIGFueSBj b21wdXRlcjxCUj52aXJ1c2VzIHdoaWNoIG1heSBoYXZlIGJlZW4gCiAgICAgIHRyYW5zbWl0dGVk IGJ5IHRoaXMgZS1tYWlsLiBUaGUgUGF0c3lzdGVtcyBHcm91cDxCUj5jb21wcmlzZXMgUGF0c3lz dGVtcyAKICAgICAgcGxjIGFuZCBpdHMgc3Vic2lkaWFyeSBncm91cCBvZiAKICAgICAgY29tcGFu aWVzLjxCUj48QlI+PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08QlI+U0YuTmV0IAogICAgICBpcyBzcG9uc29yZWQgYnk6IFNwZWVkIFN0 YXJ0IFlvdXIgTGludXggQXBwcyBOb3cuPEJSPkJ1aWxkIGFuZCBkZXBsb3kgYXBwcyAKICAgICAg JmFtcDsgV2ViIHNlcnZpY2VzIGZvciBMaW51eCB3aXRoPEJSPmEgZnJlZSBEVkQgc29mdHdhcmUg a2l0IGZyb20gSUJNLiAKICAgICAgQ2xpY2sgTm93ITxCUj48QSAKICAgICAgaHJlZj0iaHR0cDov L2Fkcy5vc2RuLmNvbS8/YWRfaWQ9MTM1NiZhbXA7YWxsb2NfaWQ9MzQzOCZhbXA7b3A9Y2xpY2si Pmh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkPTEzNTYmYW1wO2FsbG9jX2lkPTM0MzgmYW1wO29w PWNsaWNrPC9BPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxCUj5RdWlja2ZpeC1kZXZlbG9wZXJzIAogICAgICBtYWlsaW5nIGxpc3Q8QlI+UXVpY2tm aXgtZGV2ZWxvcGVyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ8QlI+PEEgCiAgICAgIGhyZWY9Imh0 dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3F1aWNrZml4LWRldmVs b3BlcnMiPmh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3F1aWNr Zml4LWRldmVsb3BlcnM8L0E+PEJSPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9U RT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4KCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh bCI+RElTQ0xBSU1FUjogVGhpcyBlLW1haWwgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBsZWdhbGx5IHByaXZpbGVnZWQuICBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCAoaW5j bHVkaW5nIGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9uKSBpcyBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuICBQbGVhc2UgaW5mb3JtIHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBpbW1lZGlhdGVseSBmcm9tIHlvdXIgc3lzdGVtLiAgVGhpcyBlLW1haWwg aXMgYXR0cmlidXRlZCB0byB0aGUgc2VuZGVyIGFuZCBtYXkgbm90IG5lY2Vzc2FyaWx5IHJlZmxl Y3QgdGhlIHZpZXdzIG9mIHRoZSBQYXRzeXN0ZW1zIEdyb3VwIGFuZCBubyBtZW1iZXIgb2YgdGhl IFBhdHN5c3RlbXMgR3JvdXAgYWNjZXB0cyBhbnkgbGlhYmlsaXR5IGZvciBhbnkgYWN0aW9uIHRh a2VuIGluIHJlbGlhbmNlIG9uIHRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCAob3RoZXIgdGhh biB3aGVyZSBpdCBoYXMgYSBsZWdhbCBvciByZWd1bGF0b3J5IG9ibGlnYXRpb24gdG8gZG8gc28p IG9yIGZvciB0aGUgY29uc2VxdWVuY2VzIG9mIGFueSBjb21wdXRlciB2aXJ1c2VzIHdoaWNoIG1h eSBoYXZlIGJlZW4gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlLW1haWwuIFRoZSBQYXRzeXN0ZW1zIEdy b3VwIGNvbXByaXNlcyBQYXRzeXN0ZW1zIHBsYyBhbmQgaXRzIHN1YnNpZGlhcnkgZ3JvdXAgb2Yg Y29tcGFuaWVzLjwvRk9OVD48L1A+ |
|
From: Timothy Y. <ty...@pa...> - 2004-02-26 20:08:38
|
Yes, this works. I had done this already. I modified setup.bat to create two .cfg files, one of which does not reset sequence numbers on disconnect. Obviously, you can then only run one test at a time with the new .cfg file if you want your tests to be independent. Tim. -----Original Message----- From: James C. Downs [mailto:jc...@co...] Sent: Thursday, February 26, 2004 12:53 PM To: Timothy Yates; qui...@li... Cc: Lenny Shleymovich Subject: RE: [Quickfix-developers] Quickfix acceptance tests. oops! The at.cfg file is actually recreated with each running of runat.bat through another batch file called setup.bat. Changing setup.bat, which results in actually changing at.cfg, causes numerous tests to fail. So it looks like this is not as simple a change as I first thought. I would think that a solution in this case is to remove the setup.bat call in runat.bat and runat.exe twice, specifiying a different set of tests and a different QF cfg file. Jim Downs Connamara Systems -----Original Message----- From: qui...@li... on behalf of Timothy Yates Sent: Thu 2/26/2004 11:23 AM To: 'qui...@li...' Cc: Lenny Shleymovich Subject: [Quickfix-developers] Quickfix acceptance tests. The automated acceptance tests for quickfix are impressive but have some very significant holes. For example, the tests surrounding processing of resend requests do not cover the most common resend scenario, namely loss of synchronization after an unexpected loss of the TCP connection. All the acceptance tests assume that sequence numbers are set to 1 at every logon. However, it is usually at logon that the missing messages are detected. One shouldn't, therefore, shouldn't get too complacent about the robustness of the quickfix session level code, especially when it is talking to a buggy peer fix app (e.g. one that often crashes), or over an unreliable network connection. Tim Yates Lead Developer Patsystems (US) LLC 141 West Jackson Boulevard Chicago 60604, USA Tel +1 (312) 542-1336 www.patsystems.com DISCLAIMER: This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, use of the information contained in this e-mail (including disclosure, copying or distribution) is prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender and may not necessarily reflect the views of the Patsystems Group and no member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems Group comprises Patsystems plc and its subsidiary group of companies. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356 <http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click> &alloc_id=3438&op=click _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers <https://lists.sourceforge.net/lists/listinfo/quickfix-developers> DISCLAIMER: This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, use of the information contained in this e-mail (including disclosure, copying or distribution) is prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender and may not necessarily reflect the views of the Patsystems Group and no member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems Group comprises Patsystems plc and its subsidiary group of companies. |
|
From: James C. D. <jc...@co...> - 2004-02-26 19:02:49
|
PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY0ODcuMSI+CjxUSVRMRT5bUXVpY2tmaXgtZGV2ZWxv cGVyc10gUXVpY2tmaXggYWNjZXB0YW5jZSB0ZXN0cy48L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRp cj1sdHI+CjxESVY+b29wcyEgVGhlIGF0LmNmZyBmaWxlIGlzIGFjdHVhbGx5IHJlY3JlYXRlZCB3 aXRoIGVhY2ggcnVubmluZyBvZiBydW5hdC5iYXQgCnRocm91Z2ggYW5vdGhlciBiYXRjaCBmaWxl IGNhbGxlZCBzZXR1cC5iYXQuIENoYW5naW5nIHNldHVwLmJhdCwgd2hpY2ggcmVzdWx0cyAKaW4g YWN0dWFsbHkgY2hhbmdpbmcgYXQuY2ZnLCBjYXVzZXMgbnVtZXJvdXMgdGVzdHMgdG8gZmFpbC4g U28gaXQgbG9va3MgbGlrZSAKdGhpcyBpcyBub3QgYXMgc2ltcGxlIGEgY2hhbmdlIGFzIEkgZmly c3QgdGhvdWdodC4gSSB3b3VsZCB0aGluayB0aGF0IGEgc29sdXRpb24gCmluIHRoaXMgY2FzZSBp cyB0byByZW1vdmUgdGhlIHNldHVwLmJhdCBjYWxsIGluIHJ1bmF0LmJhdCBhbmQgcnVuYXQuZXhl IHR3aWNlLCAKc3BlY2lmaXlpbmcgYSBkaWZmZXJlbnQgc2V0IG9mIHRlc3RzIGFuZCBhIGRpZmZl cmVudCBRRiBjZmcgZmlsZS48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5KaW0gRG93bnM8 L0RJVj4KPERJVj5Db25uYW1hcmEgU3lzdGVtczwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0 eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0gPEJSPjxCPkZyb206PC9CPiAKICBxdWlja2ZpeC1kZXZlbG9wZXJzLWFk bWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCZuYnNwO29uIGJlaGFsZiBvZiZuYnNwO1RpbW90aHkg CiAgWWF0ZXMgPEJSPjxCPlNlbnQ6PC9CPiBUaHUgMi8yNi8yMDA0IDExOjIzIEFNIDxCUj48Qj5U bzo8L0I+IAogICdxdWlja2ZpeC1kZXZlbG9wZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCcgPEJS PjxCPkNjOjwvQj4gTGVubnkgU2hsZXltb3ZpY2ggCiAgPEJSPjxCPlN1YmplY3Q6PC9CPiBbUXVp Y2tmaXgtZGV2ZWxvcGVyc10gUXVpY2tmaXggYWNjZXB0YW5jZSAKICB0ZXN0cy48QlI+PEJSPjwv Rk9OVD48L0RJVj4KICA8UD48Rk9OVCBzaXplPTI+VGhlIGF1dG9tYXRlZCBhY2NlcHRhbmNlIHRl c3RzIGZvciBxdWlja2ZpeCBhcmUgaW1wcmVzc2l2ZSBidXQgCiAgaGF2ZSBzb21lPEJSPnZlcnkg c2lnbmlmaWNhbnQgaG9sZXMuPEJSPjxCUj5Gb3IgZXhhbXBsZSwgdGhlIHRlc3RzIHN1cnJvdW5k aW5nIAogIHByb2Nlc3Npbmcgb2YgcmVzZW5kIHJlcXVlc3RzIGRvIG5vdDxCUj5jb3ZlciB0aGUg bW9zdCBjb21tb24gcmVzZW5kIHNjZW5hcmlvLCAKICBuYW1lbHkgbG9zcyBvZiBzeW5jaHJvbml6 YXRpb24gYWZ0ZXI8QlI+YW4gdW5leHBlY3RlZCBsb3NzIG9mIHRoZSBUQ1AgCiAgY29ubmVjdGlv bi4mbmJzcDsmbmJzcDsgQWxsIHRoZSBhY2NlcHRhbmNlIHRlc3RzIGFzc3VtZTxCUj50aGF0IHNl cXVlbmNlIAogIG51bWJlcnMgYXJlIHNldCB0byAxIGF0IGV2ZXJ5IGxvZ29uLiZuYnNwOyBIb3dl dmVyLCBpdCBpcyB1c3VhbGx5PEJSPmF0IGxvZ29uIAogIHRoYXQgdGhlIG1pc3NpbmcgbWVzc2Fn ZXMgYXJlIGRldGVjdGVkLjxCUj48QlI+T25lIHNob3VsZG4ndCwgdGhlcmVmb3JlLCAKICBzaG91 bGRuJ3QgZ2V0IHRvbyBjb21wbGFjZW50IGFib3V0IHRoZSByb2J1c3RuZXNzPEJSPm9mIHRoZSBx dWlja2ZpeCBzZXNzaW9uIAogIGxldmVsIGNvZGUsIGVzcGVjaWFsbHkgd2hlbiBpdCBpcyB0YWxr aW5nIHRvIGEgYnVnZ3k8QlI+cGVlciBmaXggYXBwIChlLmcuIG9uZSAKICB0aGF0IG9mdGVuIGNy YXNoZXMpLCBvciBvdmVyIGFuIHVucmVsaWFibGUgbmV0d29yazxCUj5jb25uZWN0aW9uLjxCUj48 QlI+VGltIAogIFlhdGVzPEJSPkxlYWQgRGV2ZWxvcGVyPEJSPlBhdHN5c3RlbXMgKFVTKSBMTEM8 QlI+MTQxIFdlc3QgSmFja3NvbiAKICBCb3VsZXZhcmQ8QlI+Q2hpY2FnbyA2MDYwNCwgVVNBPEJS PlRlbCArMSAoMzEyKSAKICA1NDItMTMzNjxCUj53d3cucGF0c3lzdGVtcy5jb208QlI+PEJSPjxC Uj5ESVNDTEFJTUVSOiBUaGlzIGUtbWFpbCBpcyAKICBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIGxlZ2FsbHkgcHJpdmlsZWdlZC48QlI+SWYgeW91IGFyZSBub3QgdGhlIAogIGludGVuZGVk IHJlY2lwaWVudCwgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW48QlI+dGhpcyBl LW1haWwgCiAgKGluY2x1ZGluZyBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbikg aXMgcHJvaGliaXRlZDxCUj5hbmQgbWF5IGJlIAogIHVubGF3ZnVsLiZuYnNwOyBQbGVhc2UgaW5m b3JtIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZTxCUj5pbW1lZGlhdGVseSAKICBm cm9tIHlvdXIgc3lzdGVtLiZuYnNwOyBUaGlzIGUtbWFpbCBpcyBhdHRyaWJ1dGVkIHRvIHRoZSBz ZW5kZXIgYW5kPEJSPm1heSBub3QgCiAgbmVjZXNzYXJpbHkgcmVmbGVjdCB0aGUgdmlld3Mgb2Yg dGhlIFBhdHN5c3RlbXMgR3JvdXAgYW5kIG5vIG1lbWJlcjxCUj5vZiB0aGUgCiAgUGF0c3lzdGVt cyBHcm91cCBhY2NlcHRzIGFueSBsaWFiaWxpdHkgZm9yIGFueSBhY3Rpb24gdGFrZW4gaW48QlI+ cmVsaWFuY2Ugb24gCiAgdGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIChvdGhlciB0aGFuIHdo ZXJlIGl0IGhhcyBhIGxlZ2FsIG9yPEJSPnJlZ3VsYXRvcnkgCiAgb2JsaWdhdGlvbiB0byBkbyBz bykgb3IgZm9yIHRoZSBjb25zZXF1ZW5jZXMgb2YgYW55IGNvbXB1dGVyPEJSPnZpcnVzZXMgd2hp Y2ggCiAgbWF5IGhhdmUgYmVlbiB0cmFuc21pdHRlZCBieSB0aGlzIGUtbWFpbC4gVGhlIFBhdHN5 c3RlbXMgR3JvdXA8QlI+Y29tcHJpc2VzIAogIFBhdHN5c3RlbXMgcGxjIGFuZCBpdHMgc3Vic2lk aWFyeSBncm91cCBvZiAKICBjb21wYW5pZXMuPEJSPjxCUj48QlI+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5TRi5OZXQgCiAgaXMgc3Bv bnNvcmVkIGJ5OiBTcGVlZCBTdGFydCBZb3VyIExpbnV4IEFwcHMgTm93LjxCUj5CdWlsZCBhbmQg ZGVwbG95IGFwcHMgCiAgJmFtcDsgV2ViIHNlcnZpY2VzIGZvciBMaW51eCB3aXRoPEJSPmEgZnJl ZSBEVkQgc29mdHdhcmUga2l0IGZyb20gSUJNLiBDbGljayAKICBOb3chPEJSPjxBIAogIGhyZWY9 Imh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkPTEzNTYmYW1wO2FsbG9jX2lkPTM0MzgmYW1wO29w PWNsaWNrIj5odHRwOi8vYWRzLm9zZG4uY29tLz9hZF9pZD0xMzU2JmFtcDthbGxvY19pZD0zNDM4 JmFtcDtvcD1jbGljazwvQT48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188QlI+UXVpY2tmaXgtZGV2ZWxvcGVycyAKICBtYWlsaW5nIGxpc3Q8QlI+UXVp Y2tmaXgtZGV2ZWxvcGVyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ8QlI+PEEgCiAgaHJlZj0iaHR0 cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVpY2tmaXgtZGV2ZWxv cGVycyI+aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVpY2tm aXgtZGV2ZWxvcGVyczwvQT48QlI+PC9GT05UPjwvUD48L0JMT0NLUVVPVEU+Cgo8L0JPRFk+Cjwv SFRNTD4= |
|
From: James C. D. <jc...@co...> - 2004-02-26 18:39:25
|
PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY0ODcuMSI+CjxUSVRMRT5bUXVpY2tmaXgtZGV2ZWxv cGVyc10gUXVpY2tmaXggYWNjZXB0YW5jZSB0ZXN0cy48L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRp cj1sdHI+CjxESVY+VGltLDwvRElWPgo8RElWPkkgYWdyZWUgdGhhdCB3ZSBuZWVkIGNvdmVyYWdl IG9mIHRoaXMgc2NlbmFyaW8uIEluIHRoZSBjdXJyZW50IHJlbGVhc2UsIHRoZSAKYXQuY2ZnIGZp bGUgaGFzIGEgc2V0dGluZyBvZiBSZXNldE9uRGlzY29ubmVjdD1ZLiBJIHRoaW5rIGlmIHdlIGNo YW5nZSB0aGF0IHRvIAo8RU0+UmVzZXRPbkxvZ291dD1ZPC9FTT4gd2Ugd291bGQgYmUgYWJsZSB0 byBjb25zdHJ1Y3QgdGhlIHR5cGUgb2YgdGVzdHMgeW91IApkaXNjcmliZS4gVGhpcyBjaGFuZ2Ug ZG9lcyBub3QgYWZmZWN0IGFueSBvZiB0aGUgZXhpc3RpbmcgYWNjZXB0YW5jZSAKdGVzdHMuPC9E SVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SmltIERvd25zPC9ESVY+CjxESVY+Q29ubmFtYXJh IFN5c3RlbXMsIExMQzwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklH SFQ6IDBweCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0g PEJSPjxCPkZyb206PC9CPiAKICBxdWlja2ZpeC1kZXZlbG9wZXJzLWFkbWluQGxpc3RzLnNvdXJj ZWZvcmdlLm5ldCZuYnNwO29uIGJlaGFsZiBvZiZuYnNwO1RpbW90aHkgCiAgWWF0ZXMgPEJSPjxC PlNlbnQ6PC9CPiBUaHUgMi8yNi8yMDA0IDExOjIzIEFNIDxCUj48Qj5Ubzo8L0I+IAogICdxdWlj a2ZpeC1kZXZlbG9wZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCcgPEJSPjxCPkNjOjwvQj4gTGVu bnkgU2hsZXltb3ZpY2ggCiAgPEJSPjxCPlN1YmplY3Q6PC9CPiBbUXVpY2tmaXgtZGV2ZWxvcGVy c10gUXVpY2tmaXggYWNjZXB0YW5jZSAKICB0ZXN0cy48QlI+PEJSPjwvRk9OVD48L0RJVj4KICA8 UD48Rk9OVCBzaXplPTI+VGhlIGF1dG9tYXRlZCBhY2NlcHRhbmNlIHRlc3RzIGZvciBxdWlja2Zp eCBhcmUgaW1wcmVzc2l2ZSBidXQgCiAgaGF2ZSBzb21lPEJSPnZlcnkgc2lnbmlmaWNhbnQgaG9s ZXMuPEJSPjxCUj5Gb3IgZXhhbXBsZSwgdGhlIHRlc3RzIHN1cnJvdW5kaW5nIAogIHByb2Nlc3Np bmcgb2YgcmVzZW5kIHJlcXVlc3RzIGRvIG5vdDxCUj5jb3ZlciB0aGUgbW9zdCBjb21tb24gcmVz ZW5kIHNjZW5hcmlvLCAKICBuYW1lbHkgbG9zcyBvZiBzeW5jaHJvbml6YXRpb24gYWZ0ZXI8QlI+ YW4gdW5leHBlY3RlZCBsb3NzIG9mIHRoZSBUQ1AgCiAgY29ubmVjdGlvbi4mbmJzcDsmbmJzcDsg QWxsIHRoZSBhY2NlcHRhbmNlIHRlc3RzIGFzc3VtZTxCUj50aGF0IHNlcXVlbmNlIAogIG51bWJl cnMgYXJlIHNldCB0byAxIGF0IGV2ZXJ5IGxvZ29uLiZuYnNwOyBIb3dldmVyLCBpdCBpcyB1c3Vh bGx5PEJSPmF0IGxvZ29uIAogIHRoYXQgdGhlIG1pc3NpbmcgbWVzc2FnZXMgYXJlIGRldGVjdGVk LjxCUj48QlI+T25lIHNob3VsZG4ndCwgdGhlcmVmb3JlLCAKICBzaG91bGRuJ3QgZ2V0IHRvbyBj b21wbGFjZW50IGFib3V0IHRoZSByb2J1c3RuZXNzPEJSPm9mIHRoZSBxdWlja2ZpeCBzZXNzaW9u IAogIGxldmVsIGNvZGUsIGVzcGVjaWFsbHkgd2hlbiBpdCBpcyB0YWxraW5nIHRvIGEgYnVnZ3k8 QlI+cGVlciBmaXggYXBwIChlLmcuIG9uZSAKICB0aGF0IG9mdGVuIGNyYXNoZXMpLCBvciBvdmVy IGFuIHVucmVsaWFibGUgbmV0d29yazxCUj5jb25uZWN0aW9uLjxCUj48QlI+VGltIAogIFlhdGVz PEJSPkxlYWQgRGV2ZWxvcGVyPEJSPlBhdHN5c3RlbXMgKFVTKSBMTEM8QlI+MTQxIFdlc3QgSmFj a3NvbiAKICBCb3VsZXZhcmQ8QlI+Q2hpY2FnbyA2MDYwNCwgVVNBPEJSPlRlbCArMSAoMzEyKSAK ICA1NDItMTMzNjxCUj53d3cucGF0c3lzdGVtcy5jb208QlI+PEJSPjxCUj5ESVNDTEFJTUVSOiBU aGlzIGUtbWFpbCBpcyAKICBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIGxlZ2FsbHkgcHJp dmlsZWdlZC48QlI+SWYgeW91IGFyZSBub3QgdGhlIAogIGludGVuZGVkIHJlY2lwaWVudCwgdXNl IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW48QlI+dGhpcyBlLW1haWwgCiAgKGluY2x1 ZGluZyBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbikgaXMgcHJvaGliaXRlZDxC Uj5hbmQgbWF5IGJlIAogIHVubGF3ZnVsLiZuYnNwOyBQbGVhc2UgaW5mb3JtIHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGUgbWVzc2FnZTxCUj5pbW1lZGlhdGVseSAKICBmcm9tIHlvdXIgc3lzdGVt LiZuYnNwOyBUaGlzIGUtbWFpbCBpcyBhdHRyaWJ1dGVkIHRvIHRoZSBzZW5kZXIgYW5kPEJSPm1h eSBub3QgCiAgbmVjZXNzYXJpbHkgcmVmbGVjdCB0aGUgdmlld3Mgb2YgdGhlIFBhdHN5c3RlbXMg R3JvdXAgYW5kIG5vIG1lbWJlcjxCUj5vZiB0aGUgCiAgUGF0c3lzdGVtcyBHcm91cCBhY2NlcHRz IGFueSBsaWFiaWxpdHkgZm9yIGFueSBhY3Rpb24gdGFrZW4gaW48QlI+cmVsaWFuY2Ugb24gCiAg dGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIChvdGhlciB0aGFuIHdoZXJlIGl0IGhhcyBhIGxl Z2FsIG9yPEJSPnJlZ3VsYXRvcnkgCiAgb2JsaWdhdGlvbiB0byBkbyBzbykgb3IgZm9yIHRoZSBj b25zZXF1ZW5jZXMgb2YgYW55IGNvbXB1dGVyPEJSPnZpcnVzZXMgd2hpY2ggCiAgbWF5IGhhdmUg YmVlbiB0cmFuc21pdHRlZCBieSB0aGlzIGUtbWFpbC4gVGhlIFBhdHN5c3RlbXMgR3JvdXA8QlI+ Y29tcHJpc2VzIAogIFBhdHN5c3RlbXMgcGxjIGFuZCBpdHMgc3Vic2lkaWFyeSBncm91cCBvZiAK ICBjb21wYW5pZXMuPEJSPjxCUj48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5TRi5OZXQgCiAgaXMgc3BvbnNvcmVkIGJ5OiBTcGVl ZCBTdGFydCBZb3VyIExpbnV4IEFwcHMgTm93LjxCUj5CdWlsZCBhbmQgZGVwbG95IGFwcHMgCiAg JmFtcDsgV2ViIHNlcnZpY2VzIGZvciBMaW51eCB3aXRoPEJSPmEgZnJlZSBEVkQgc29mdHdhcmUg a2l0IGZyb20gSUJNLiBDbGljayAKICBOb3chPEJSPjxBIAogIGhyZWY9Imh0dHA6Ly9hZHMub3Nk bi5jb20vP2FkX2lkPTEzNTYmYW1wO2FsbG9jX2lkPTM0MzgmYW1wO29wPWNsaWNrIj5odHRwOi8v YWRzLm9zZG4uY29tLz9hZF9pZD0xMzU2JmFtcDthbGxvY19pZD0zNDM4JmFtcDtvcD1jbGljazwv QT48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ UXVpY2tmaXgtZGV2ZWxvcGVycyAKICBtYWlsaW5nIGxpc3Q8QlI+UXVpY2tmaXgtZGV2ZWxvcGVy c0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ8QlI+PEEgCiAgaHJlZj0iaHR0cHM6Ly9saXN0cy5zb3Vy Y2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVpY2tmaXgtZGV2ZWxvcGVycyI+aHR0cHM6Ly9s aXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVpY2tmaXgtZGV2ZWxvcGVyczwv QT48QlI+PC9GT05UPjwvUD48L0JMT0NLUVVPVEU+Cgo8L0JPRFk+CjwvSFRNTD4= |
|
From: Miller, O. <OM...@ri...> - 2004-02-26 18:10:47
|
One more thing while were at it. I'm looking for some ideas on how the = scripting language for the test runner can be made smarter so we don't = have to essentially rewrite (and correct) the same tests for each = version of FIX. This is error prone and boring. --oren -----Original Message----- From: Timothy Yates [mailto:ty...@pa...] Sent: Thu 2/26/2004 11:23 AM To: 'qui...@li...' Cc: Lenny Shleymovich Subject: [Quickfix-developers] Quickfix acceptance tests. The automated acceptance tests for quickfix are impressive but have some very significant holes. For example, the tests surrounding processing of resend requests do not cover the most common resend scenario, namely loss of synchronization = after an unexpected loss of the TCP connection. All the acceptance tests = assume that sequence numbers are set to 1 at every logon. However, it is = usually at logon that the missing messages are detected. One shouldn't, therefore, shouldn't get too complacent about the = robustness of the quickfix session level code, especially when it is talking to a = buggy peer fix app (e.g. one that often crashes), or over an unreliable = network connection. Tim Yates Lead Developer=20 Patsystems (US) LLC=20 141 West Jackson Boulevard Chicago 60604, USA=20 Tel +1 (312) 542-1336=20 www.patsystems.com=20 DISCLAIMER: This e-mail is confidential and may also be legally = privileged. If you are not the intended recipient, use of the information contained = in this e-mail (including disclosure, copying or distribution) is = prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender = and may not necessarily reflect the views of the Patsystems Group and no = member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal = or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems = Group comprises Patsystems plc and its subsidiary group of companies. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Miller, O. <OM...@ri...> - 2004-02-26 18:03:25
|
Oh and the other hole you may have noticed is that we are currently only = acceptance testing the Acceptor logon sequence, which leaves the = Initiator logon sequence vulnerable. --oren -----Original Message----- From: Timothy Yates [mailto:ty...@pa...] Sent: Thu 2/26/2004 11:23 AM To: 'qui...@li...' Cc: Lenny Shleymovich Subject: [Quickfix-developers] Quickfix acceptance tests. The automated acceptance tests for quickfix are impressive but have some very significant holes. For example, the tests surrounding processing of resend requests do not cover the most common resend scenario, namely loss of synchronization = after an unexpected loss of the TCP connection. All the acceptance tests = assume that sequence numbers are set to 1 at every logon. However, it is = usually at logon that the missing messages are detected. One shouldn't, therefore, shouldn't get too complacent about the = robustness of the quickfix session level code, especially when it is talking to a = buggy peer fix app (e.g. one that often crashes), or over an unreliable = network connection. Tim Yates Lead Developer=20 Patsystems (US) LLC=20 141 West Jackson Boulevard Chicago 60604, USA=20 Tel +1 (312) 542-1336=20 www.patsystems.com=20 DISCLAIMER: This e-mail is confidential and may also be legally = privileged. If you are not the intended recipient, use of the information contained = in this e-mail (including disclosure, copying or distribution) is = prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender = and may not necessarily reflect the views of the Patsystems Group and no = member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal = or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems = Group comprises Patsystems plc and its subsidiary group of companies. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Miller, O. <OM...@ri...> - 2004-02-26 17:58:33
|
Tim, Yes, you are correct, these holes do exist in the current test = scenarios. The good news it that the test runner does have the = capability to test these scenarios. We have an iDISCONNECT call which = complements the iCONNECT call and will forcibly kill a tcp connection. = I think maybe the thing to do is to create additional versions of the = 8_*.def tests (the ones involving resend requests), and the 1_*.def = tests (the ones involving logons). These ones will test the same = functionality by disconnecting and restablishing a logon instead of = making the assumptions of the other tests. --oren -----Original Message----- From: Timothy Yates [mailto:ty...@pa...] Sent: Thu 2/26/2004 11:23 AM To: 'qui...@li...' Cc: Lenny Shleymovich Subject: [Quickfix-developers] Quickfix acceptance tests. The automated acceptance tests for quickfix are impressive but have some very significant holes. For example, the tests surrounding processing of resend requests do not cover the most common resend scenario, namely loss of synchronization = after an unexpected loss of the TCP connection. All the acceptance tests = assume that sequence numbers are set to 1 at every logon. However, it is = usually at logon that the missing messages are detected. One shouldn't, therefore, shouldn't get too complacent about the = robustness of the quickfix session level code, especially when it is talking to a = buggy peer fix app (e.g. one that often crashes), or over an unreliable = network connection. Tim Yates Lead Developer=20 Patsystems (US) LLC=20 141 West Jackson Boulevard Chicago 60604, USA=20 Tel +1 (312) 542-1336=20 www.patsystems.com=20 DISCLAIMER: This e-mail is confidential and may also be legally = privileged. If you are not the intended recipient, use of the information contained = in this e-mail (including disclosure, copying or distribution) is = prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender = and may not necessarily reflect the views of the Patsystems Group and no = member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal = or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems = Group comprises Patsystems plc and its subsidiary group of companies. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Joerg T. <Joe...@ma...> - 2004-02-26 17:55:19
|
Hi Tim,
thanks for the tests already provided. I did some initial reading
whether the message should be ignored or rejected, but did not come to
any conclusion yet.
> The automated acceptance tests for quickfix are impressive but have some
> very significant holes.
>
> For example, the tests surrounding processing of resend requests do not
> cover the most common resend scenario, namely loss of synchronization after
> an unexpected loss of the TCP connection. All the acceptance tests assume
> that sequence numbers are set to 1 at every logon. However, it is usually
> at logon that the missing messages are detected.
Agreed. Since we use QuickFIX in production, we see oft such kind of
re-syncs. Probably I could grab some tests from production issues. But
this kind of stuff is always difficult to analyse.
> One shouldn't, therefore, shouldn't get too complacent about the robustness
> of the quickfix session level code, especially when it is talking to a buggy
> peer fix app (e.g. one that often crashes), or over an unreliable network
> connection.
Actually, it is difficult to simulate an unreliable network connection.
There are TCP/IP level tools to simulate that (nistnet), but I did not
do any experiments so far. Perhaps it is possible to implement a "lossy"
low level socket read/write interface to be plugged in.
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Timothy Y. <ty...@pa...> - 2004-02-26 17:35:32
|
The automated acceptance tests for quickfix are impressive but have some very significant holes. For example, the tests surrounding processing of resend requests do not cover the most common resend scenario, namely loss of synchronization after an unexpected loss of the TCP connection. All the acceptance tests assume that sequence numbers are set to 1 at every logon. However, it is usually at logon that the missing messages are detected. One shouldn't, therefore, shouldn't get too complacent about the robustness of the quickfix session level code, especially when it is talking to a buggy peer fix app (e.g. one that often crashes), or over an unreliable network connection. Tim Yates Lead Developer Patsystems (US) LLC 141 West Jackson Boulevard Chicago 60604, USA Tel +1 (312) 542-1336 www.patsystems.com DISCLAIMER: This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, use of the information contained in this e-mail (including disclosure, copying or distribution) is prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender and may not necessarily reflect the views of the Patsystems Group and no member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems Group comprises Patsystems plc and its subsidiary group of companies. |
|
From: Timothy Y. <ty...@pa...> - 2004-02-26 17:05:42
|
There is an bug in Session::sendRaw, which may cause a sequence number to be consumed without any message actually being sent. For example, session-level reject messages are not sent if the session is not logged in. In such cases, an empty message (empty string) is committed to the message store and the outbound sequence number is incremented. This causes the session to be irretrievably broken. If the client asks for the missing message, an exception is thrown on attempting to parse the empty message from the message store. In the current quickfix release, this will cause the client's resend request to be ignored. The attached acceptance test definition illustrates this problem by sending a logon message with a bad sending time. This seems like a slightly artificial test case. However, we have seen a large number of instances of this problem which were caused by something other than bad sending time. We are still trying to ascertain exactly which outbound messages were being suppressed. I am not certain what the correct behaviour should be for this test case. Should the reject still be sent, or should it be suppressed? I think it should be suppressed because the normal way to reject a logon is either with a logout or a disconnect. Ideally, the logout text should include the reason for the problem (i.e. sending time inaccuracy), otherwise it could be very difficult for the client to ascertain. <<5000_STA.def>> Tim Yates Lead Developer Patsystems (US) LLC 141 West Jackson Boulevard Chicago 60604, USA Tel +1 (312) 542-1336 www.patsystems.com DISCLAIMER: This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, use of the information contained in this e-mail (including disclosure, copying or distribution) is prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender and may not necessarily reflect the views of the Patsystems Group and no member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems Group comprises Patsystems plc and its subsidiary group of companies. |
|
From: Howard E. <ho...@ex...> - 2004-02-25 21:44:32
|
Using qf 1.6.0.. I am trying to set up some scripts to archive + manage my fix session logs. I have noticed that if deleted the following files will be auto re-created by the qf library without requiring a re-start of my app: FIX.4.2-SBI0-SLGM0.body FIX.4.2-SBI0-SLGM0.header FIX.4.2-SBI0-SLGM0.seqnums FIX.4.2-SBI0-SLGM0.session However these files are not regenerated: FIX.4.2-SBI0-SLGM0.event FIX.4.2-SBI0-SLGM0.incoming FIX.4.2-SBI0-SLGM0.outgoing Is there a way that the .event, .incoming, .outgoing logs can be reset without having to restart my application? I am using the StartTime/EndTime settings in the config, does not seem to make much of a difference. Thanks, Howard |
|
From: Oren M. <ore...@ya...> - 2004-02-25 14:34:22
|
Thanks Heri, I'm very curious to take a look at this. I just finished a port to Mac OSX and would be interested to see if the same changes were required for both of these platforms. --oren --- "H. Steuer" <st...@st...> wrote: > hello, > > i've just did some small changes to the quickfix cvs > snapshot as of 24th feb.04 to get it to compile and > pass all unit and acceptance tests on freebsd. > > i also compiled stuff on solaris and linux to be > sure not to break anything, and it went fine. as we > are in a unix-only environment, i was not able to > compile stuff on windows. > > i first thought of including acx_pthread to safely > detect the threading environment, but was not sure > if thats okay for thoughtworks due to licensing > issues. but the way its done now should be okay for > all supported platforms. > > > it would be nice if that patch gets tested and goes > into the tree. im pretty sure that all BSD fans - > including me - are happy with it :) > > > kind regards, > heri > > ATTACHMENT part 2 application/octet-stream name=quickfix.diff __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
|
From: H. S. <st...@st...> - 2004-02-25 14:26:23
|
hello, i've just did some small changes to the quickfix cvs snapshot as of 24th feb.04 to get it to compile and pass all unit and acceptance tests on freebsd. i also compiled stuff on solaris and linux to be sure not to break anything, and it went fine. as we are in a unix-only environment, i was not able to compile stuff on windows. i first thought of including acx_pthread to safely detect the threading environment, but was not sure if thats okay for thoughtworks due to licensing issues. but the way its done now should be okay for all supported platforms. it would be nice if that patch gets tested and goes into the tree. im pretty sure that all BSD fans - including me - are happy with it :) kind regards, heri |
|
From: James C. D. <jc...@co...> - 2004-02-20 22:39:10
|
Tim, I am using Ruby 1.6.8 and just successfully ran the acceptance tests against QF 1.6 (Debug). I think there is an issue with later versions of Ruby with some methods being deprecated. Jim James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Timothy Yates Sent: Friday, February 20, 2004 11:57 AM To: 'qui...@li...' Subject: [Quickfix-developers] quickfix 1.6.0 acceptance tests. I am trying to run the QuickFIX 1.6.0 acceptance tests on Windows XP, without much success. I have downloaded ruby 1.8.0. When I invoke "runat debug 3000" I initially get a syntax error in runner.rb at line 151. (Should I be using an early version of ruby?) When I fix this, every test still fails with a message like this one: <test name='definitions/server/fix40/10_MsgSeqNumEqual.def' result='failure' > <message> Syntax error <line>3</line> </message> </test> What am I doing wrong? Any help much appreciated. Tim Yates Lead Developer Patsystems (US) LLC 141 West Jackson Boulevard Chicago 60604, USA Tel +1 (312) 542-1336 www.patsystems.com DISCLAIMER: This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, use of the information contained in this e-mail (including disclosure, copying or distribution) is prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender and may not necessarily reflect the views of the Patsystems Group and no member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems Group comprises Patsystems plc and its subsidiary group of companies. ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers DISCLAIMER: This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, use of the information contained in this e-mail (including disclosure, copying or distribution) is prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender and may not necessarily reflect the views of the Patsystems Group and no member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems Group comprises Patsystems plc and its subsidiary group of companies. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Timothy Y. <ty...@pa...> - 2004-02-20 20:57:34
|
I am trying to run the QuickFIX 1.6.0 acceptance tests on Windows XP,
without much success.
I have downloaded ruby 1.8.0.
When I invoke "runat debug 3000" I initially get a syntax error in runner.rb
at line 151. (Should I be using an early version of ruby?)
When I fix this, every test still fails with a message like this one:
<test name='definitions/server/fix40/10_MsgSeqNumEqual.def' result='failure'
>
<message>
Syntax error
<line>3</line>
</message>
</test>
What am I doing wrong? Any help much appreciated.
Tim Yates
Lead Developer
Patsystems (US) LLC
141 West Jackson Boulevard
Chicago 60604, USA
Tel +1 (312) 542-1336
www.patsystems.com
DISCLAIMER: This e-mail is confidential and may also be legally privileged.
If you are not the intended recipient, use of the information contained in
this e-mail (including disclosure, copying or distribution) is prohibited
and may be unlawful. Please inform the sender and delete the message
immediately from your system. This e-mail is attributed to the sender and
may not necessarily reflect the views of the Patsystems Group and no member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems Group
comprises Patsystems plc and its subsidiary group of companies.
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
DISCLAIMER: This e-mail is confidential and may also be legally privileged.
If you are not the intended recipient, use of the information contained in
this e-mail (including disclosure, copying or distribution) is prohibited
and may be unlawful. Please inform the sender and delete the message
immediately from your system. This e-mail is attributed to the sender and
may not necessarily reflect the views of the Patsystems Group and no member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems Group
comprises Patsystems plc and its subsidiary group of companies.
|
|
From: Joshua C. B. <jo...@xl...> - 2004-02-19 08:18:41
|
Oren, Thanks for the information. It was very helpful. I do have another quick (heh) question regarding QuickFIX. I noticed compile time options for linking to the MySQL library, and I was wondering what purpose that serves as far as QuickFIX goes; that is - what is MySQL used for within the QuickFIX engine? Additionally, I just want to thank everyone who has been working on this project. It's great to see something like this available in the open source community. Keep up the good work! Cheers, Joshua ----- Original Message ----- From: "Oren Miller" <ore...@ya...> To: "Joshua C. Bergeron" <jo...@xl...>; <qui...@li...> Sent: Wednesday, February 18, 2004 11:44 PM Subject: Re: [Quickfix-developers] FIXML > No, QuickFIX does not support FIXML and there arn't > any current plans to do so. FIXML is something > fixprotocol.org has been trying to push to several > years but really it's just not catching on. It was > proposed during the heady days when XML hype was at > it's peak and everybody was proposing using XML for > all purposes (those days are over... arn't they?) > > I really can't think of a major financial institution > that exposes a public FIXML interface. I know there > are some that use it for internal systems, but really > FIX not only eclipses it with its installed base, but > also eclipses it with its adoption. FIX proper is > growing faster than ever and I'm just not seeing the > same demand for FIXML. Now people are also starting > to use FIX for more high frequency things like market > data, where FIXML is just unworkable. > > QuickFIX can handle what you want it to do. As I tell > everyone, start using QuickFIX and get going on > producing some useful code. If it turns out all your > needs are met then you're golden. If not, you can > either shop around for a commercial engine, or do what > most people do and modify QF to fit you're needs and > contribute any generally usefull changes back to the > project. > > At this point I believe QF has more or less made a FIX > engine a commodity, at least that was the goal. > You'll have to see if any of the vendors can offer you > value above and beyond FIX compliance that you feel is > worth paying for. > > --oren > > --- "Joshua C. Bergeron" <jo...@xl...> wrote: > > Greetings, > > > > Does QuickFIX support FIXML? If not, is anyone > > working on currently implementing it, or are there > > any plans at all for this? I am curious, because > > FIXML seems to be the 'new standard'? But I'm not > > really sure. I'm rather new to the world of FIX. > > > > My organization would like to implement some kind of > > FIX based server that would allow us to tie the back > > end into our own market data, and be able to > > simulate orders over the FIX protocol to some > > extent. > > > > QuickFIX was my first thought regarding this, but > > maybe the developers here can give me some input? > > > > Thanks in advance. > > > > Cheers, > > Joshua C. Bergeron > > __________________________________ > Do you Yahoo!? > Yahoo! Mail SpamGuard - Read only the mail you want. > http://antispam.yahoo.com/tools > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Oren M. <ore...@ya...> - 2004-02-19 04:49:57
|
No, QuickFIX does not support FIXML and there arn't any current plans to do so. FIXML is something fixprotocol.org has been trying to push to several years but really it's just not catching on. It was proposed during the heady days when XML hype was at it's peak and everybody was proposing using XML for all purposes (those days are over... arn't they?) I really can't think of a major financial institution that exposes a public FIXML interface. I know there are some that use it for internal systems, but really FIX not only eclipses it with its installed base, but also eclipses it with its adoption. FIX proper is growing faster than ever and I'm just not seeing the same demand for FIXML. Now people are also starting to use FIX for more high frequency things like market data, where FIXML is just unworkable. QuickFIX can handle what you want it to do. As I tell everyone, start using QuickFIX and get going on producing some useful code. If it turns out all your needs are met then you're golden. If not, you can either shop around for a commercial engine, or do what most people do and modify QF to fit you're needs and contribute any generally usefull changes back to the project. At this point I believe QF has more or less made a FIX engine a commodity, at least that was the goal. You'll have to see if any of the vendors can offer you value above and beyond FIX compliance that you feel is worth paying for. --oren --- "Joshua C. Bergeron" <jo...@xl...> wrote: > Greetings, > > Does QuickFIX support FIXML? If not, is anyone > working on currently implementing it, or are there > any plans at all for this? I am curious, because > FIXML seems to be the 'new standard'? But I'm not > really sure. I'm rather new to the world of FIX. > > My organization would like to implement some kind of > FIX based server that would allow us to tie the back > end into our own market data, and be able to > simulate orders over the FIX protocol to some > extent. > > QuickFIX was my first thought regarding this, but > maybe the developers here can give me some input? > > Thanks in advance. > > Cheers, > Joshua C. Bergeron __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
|
From: Joshua C. B. <jo...@xl...> - 2004-02-18 19:48:40
|
Greetings, Does QuickFIX support FIXML? If not, is anyone working on currently = implementing it, or are there any plans at all for this? I am curious, = because FIXML seems to be the 'new standard'? But I'm not really sure. = I'm rather new to the world of FIX. My organization would like to implement some kind of FIX based server = that would allow us to tie the back end into our own market data, and be = able to simulate orders over the FIX protocol to some extent.=20 QuickFIX was my first thought regarding this, but maybe the developers = here can give me some input? Thanks in advance. Cheers, Joshua C. Bergeron |
|
From: James C. D. <jc...@co...> - 2004-02-18 14:12:35
|
I'll create it if some one describes it.=20 Jim =20 James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Miller, Oren Sent: Wednesday, February 18, 2004 5:48 AM To: st...@st...; qui...@li... Subject: Re: [Quickfix-developers] crashing on invalid messages (was: invalid message) That's why we have the automated tests. I could never validate code = with the same watchful eye that they do :) I also think a test for the new functionality would be warranted. -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: H. Steuer <st...@st...> To: qui...@li... <qui...@li...> Sent: Wed Feb 18 05:39:25 2004 Subject: [Quickfix-developers] crashing on invalid messages (was: = invalid message) hello, regarding my post to the list from 04/01/26 i've just added a catch = block which saves the application from crashing on invalid messages to SocketConnection::read( SocketConnector& s ).=20 using this patch, the application passed tests on invalid headers, = invalid checksums, missing checksums and invalid bodylength which all caused the application to crash before. hope oren will correct me, if that patch is not fine that way. regards, heri --- quickfix/src/C++/SocketConnection.cpp 2003-08-04 08:14:03.000000000 +0200 +++ SocketConnection.cpp 2004-02-18 11:46:38.000000000 +0100 @@ -97,7 +97,10 @@ std::string msg; if ( !readMessage( msg ) ) return false; =20 - m_pSession->next( msg ); + try { + m_pSession->next( msg ); + } + catch ( InvalidMessage& ) {} return true; =20 QF_STACK_POP ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software = kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software = kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Miller, O. <OM...@ri...> - 2004-02-18 11:52:29
|
That's why we have the automated tests. I could never validate code =
with the same watchful eye that they do :)
I also think a test for the new functionality would be warranted.
--------------------------
Sent from my BlackBerry Wireless Handheld
-----Original Message-----
From: H. Steuer <st...@st...>
To: qui...@li... =
<qui...@li...>
Sent: Wed Feb 18 05:39:25 2004
Subject: [Quickfix-developers] crashing on invalid messages (was: =
invalid message)
hello,
regarding my post to the list from 04/01/26 i've just added a catch =
block which saves the application from crashing on invalid messages to =
SocketConnection::read( SocketConnector& s ).=20
using this patch, the application passed tests on invalid headers, =
invalid checksums, missing checksums and invalid bodylength which all =
caused the application to crash before.
hope oren will correct me, if that patch is not fine that way.
regards,
heri
--- quickfix/src/C++/SocketConnection.cpp 2003-08-04 08:14:03.000000000 =
+0200
+++ SocketConnection.cpp 2004-02-18 11:46:38.000000000 +0100
@@ -97,7 +97,10 @@
std::string msg;
if ( !readMessage( msg ) ) return false;
=20
- m_pSession->next( msg );
+ try {
+ m_pSession->next( msg );
+ }
+ catch ( InvalidMessage& ) {}
return true;
=20
QF_STACK_POP
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Oren M. <ore...@ya...> - 2004-02-18 11:45:20
|
When you say defining in the XML, just make sure you add those to both the <fields> section and also add them to all the messages you would like them to be accepted in. Other then that you should be able to simply copy over the old file which will then load next time you bring the process up. (I'm thinking in the future this can be sent along with a custom FIX message so the DD can be updated realtime as well). --- "Dahl, Jon" <JD...@cm...> wrote: > Having followed the documentation, I have added some > custom fields by > using the Macros and also defining the fields in the > DataDictionary - > XML file. > > Is there anything else I need to make sure I do from > the client/server > side besides distributing the updated file? > > Thanks, > > JD > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps > Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id56&alloc_id438&op=click > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
|
From: H. S. <st...@st...> - 2004-02-18 11:44:12
|
hello,
regarding my post to the list from 04/01/26 i've just added a catch block which saves the application from crashing on invalid messages to SocketConnection::read( SocketConnector& s ).
using this patch, the application passed tests on invalid headers, invalid checksums, missing checksums and invalid bodylength which all caused the application to crash before.
hope oren will correct me, if that patch is not fine that way.
regards,
heri
--- quickfix/src/C++/SocketConnection.cpp 2003-08-04 08:14:03.000000000 +0200
+++ SocketConnection.cpp 2004-02-18 11:46:38.000000000 +0100
@@ -97,7 +97,10 @@
std::string msg;
if ( !readMessage( msg ) ) return false;
- m_pSession->next( msg );
+ try {
+ m_pSession->next( msg );
+ }
+ catch ( InvalidMessage& ) {}
return true;
QF_STACK_POP
|
|
From: Oren M. <ore...@ya...> - 2004-02-18 11:40:02
|
Sutee,
If you want a field to be optional, you should check
for its precense before pulling it out. By pulling
out the message without verifying whether or not if it
exists, forces QuickFIX to treat it as a required
field. You should try something like this:
SenderSubID senderSubID = new SenderSubID();
if( order.getHeader().isSet( senderSubID ) ) {
order.get( senderSubID );
}
--- Sutee Gettupan <su...@si...> wrote:
> Dear all,
> I develop my fix engine using C#, and I test it
> with Banzai. I setting
> my fix engine following below.
>
> [DEFAULT]
> ConnectionType=acceptor
> SocketAcceptPort=5001
> FileStorePath=store
> StartTime=00:00:00
> EndTime=23:00:00
>
> [SESSION]
> BeginString=FIX.4.0
> SenderCompID=XYZ
> TargetCompID=CLIENT1
> UseDataDictionary=Y
> DataDictionary=spec/FIX40.xml
> ValidateFieldsOutOfOrder=N
> ValidateFieldsHaveValues=N
>
> How can I manage Require tag missing, when I
> receive message from
> Banzai. In my idea, some tags that define in xml
> spec are not require. But
> when I receive message, it rejects message from
> banzai. For example code,
> that I use in my engine to get some field is
>
> string sSenderSubID =
> order.getHeader().getField(new
> SenderSubID()).getValue();
>
> Is this correct?, If It's wrong, please advise
> me to correct it.
>
> Best Regards,
> Sutee Gettupan
> Developer
>
>
>
-------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps
> Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
>
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
|
|
From: Oren M. <ore...@ya...> - 2004-02-18 11:31:53
|
Heri,
This looks about right to me. I have a couple of
suggestions to improve it. First I would like to see
the duplicated code rolled up into a method. This
could be done in Session, however I think a more
generally usefull place might be in the message class
itself. Imagine a usage something like this:
message.invert( reject );
or
message.reverse( reject );
or something to that affect. The nice thing about
this is that same method can be used in application
code as well.
The other thing is that I think that this would also
be useful for SenderSubID and TargetCompID. So this
inversion method could also check for the presence of
those and tag them into the new message in the same
manner. In fact, I think there are a few more field
pairs in the header this may qualify for. We can even
make it smarter and have it do the same with
SenderCompID and SenderSubID, and also tag it with the
same BeginString. That way we we can do things like:
fromApp( Message request, SessionID sessionID )
{
Message response;
response.invert( request );
...
// has everything it needs to route from invert call
Session::sendToTarget( response );
}
--- "H. Steuer" <st...@st...> wrote:
> Guys,
>
> as OnBehalfOfCompID and DeliverToCompID are widely
> used in large FIX networks to add kind of "routing
> informations" to FIX messages, we've added the
> fields to Session.cpp in Session::generateReject(),
> as these kind of messages do need to be addressed to
> the sell/buyside fix engine (which is not true e.g.
> for ResendRequest messages).
>
> In that scenario, you have a single FIX connection
> serving your trading counterparts which are all
> addressed by fields 115/128.
>
>
> We asked for a good place to add this in a earlier
> post, but maybe one of you guys is also in need for
> such a functionality. Therefore you can find the
> patch below, thats how far we've patched it for now.
> Maybe we've overseen some issues and Oren gives us a
> hint where these fields have to be added, too.
>
>
> Comments are welcome :)
>
> Regards,
> Heri
>
>
> --- Session.cpp.old 2003-08-11 00:41:20.000000000
> +0200
> +++ Session.cpp 2004-02-17 20:34:15.000000000 +0100
> @@ -642,17 +642,34 @@
>
> Message reject;
> reject.getHeader().setField( MsgType( "3" ) );
> + OnBehalfOfCompID onBehalfOfCompID;
> + DeliverToCompID deliverToCompID;
> fill( reject.getHeader() );
> +
> + if ( message.getHeader().isSetField(
> onBehalfOfCompID ) )
> + {
> + message.getHeader().getField( onBehalfOfCompID
> );
> + reject.getHeader().setField( DeliverToCompID(
> onBehalfOfCompID ) );
> + }
> + if ( message.getHeader().isSetField(
> deliverToCompID ) )
> + {
> + message.getHeader().getField( deliverToCompID);
> + reject.getHeader().setField( OnBehalfOfCompID(
> deliverToCompID ) );
> + }
>
> +
> +
> +
> MsgSeqNum msgSeqNum;
> MsgType msgType;
> PossDupFlag possDupFlag( false );
> -
> +
> message.getHeader().getField( msgType );
> message.getHeader().getField( msgSeqNum );
> +
> if ( message.getHeader().isSetField( possDupFlag
> ) )
> message.getHeader().getField( possDupFlag );
> -
> +
> reject.setField( RefSeqNum( msgSeqNum ) );
> if ( beginString >= FIX::BeginString_FIX42 )
> {
> @@ -667,7 +684,9 @@
> if ( msgType != MsgType_Logon && msgType !=
> MsgType_SequenceReset
> && !possDupFlag )
> { m_state.incrNextTargetMsgSeqNum(); }
> +
>
> +
>
> const std::string* reason = 0;
> switch ( err )
> @@ -741,12 +760,24 @@
> MsgType msgType;
> MsgSeqNum msgSeqNum;
> PossDupFlag possDupFlag( false );
> + OnBehalfOfCompID onBehalfOfCompID;
> + DeliverToCompID deliverToCompID;
>
> message.getHeader().getField( msgType );
> message.getHeader().getField( msgSeqNum );
> if ( beginString >= FIX::BeginString_FIX42 )
> reject.setField( RefMsgType( msgType ) );
> reject.setField( RefSeqNum( msgSeqNum ) );
> + if ( message.getHeader().isSetField(
> onBehalfOfCompID ) )
> + {
> + message.getHeader().getField( onBehalfOfCompID
> );
> + reject.getHeader().setField( DeliverToCompID(
> onBehalfOfCompID ) );
> + }
> + if ( message.getHeader().isSetField(
> deliverToCompID ) )
> + {
> + message.getHeader().getField( deliverToCompID);
> + reject.getHeader().setField( OnBehalfOfCompID(
> deliverToCompID ) );
> + }
>
> if ( msgType != MsgType_Logon && msgType !=
> MsgType_SequenceReset
> && !possDupFlag )
>
>
>
>
-------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps
> Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
>
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
|
98 messages has been excluded from this view by a project administrator.
