Menu
▾
▴
Re: [Quickfixj-users] Support for UI64 data type
|
From: Kodippili A. A. <as...@ls...> - 2019-08-08 10:10:10
|
The reason we want to exceed I32 max limit is to support continuous trading. e.g. a FIX user session might continue for more than 6 months, during that time I32 limit can be exceeded (this might take more time for Trading users, but for DropCopy users with All Firm permissions limit will reach earlier) For resend, we are not going to send billions of messages, only the most recent N (1000 to 10,000) number The C++ side will be using unsigned integer 64 bit ( 8 bytes) . I am adding capability to a java based test tool which acts as a client to test the C++ server. I was hoping to submit a pull request for changing the data type of sequence number related fields to long. Before starting to work on this I wanted to make sure that this change is acceptable. Thanks, AsankaK From: Christoph John [mailto:chr...@ma...] Sent: Thursday, August 08, 2019 2:13 PM To: Kodippili Arachchige, Asanka <as...@ls...>; qui...@li...; Philip Whitehouse <ph...@wh...> Subject: Re: [Quickfixj-users] Support for UI64 data type Wow, OK. Not indicating a limit in the FIX spec does not mean that one should use sequence numbers as large as 18446744073709551615. ;) I just realised that you are from LSE and so are on the server side of things and should be able to influence the implementation: please think about what you are trying to achieve and whether you are using the right protocol for it. Do you really want to do resends for possibly billions of messages? Why are there so many messages anyway? As stated earlier, maybe FIX is not the right fit for your purpose?! I can only recommend that you consult someone with FIX knowledge before building your system. Apart from that: my C++ skills are a little rusty but isn't an integer limited to 4bytes in C++ also? The implementations for C++ and .NET are also using an int for sequence numbers. Probably it wouldn't be such a big effort to change the sequence number to long datatype. But still I think it is not really necessary due to my points stated above. Of course I am ready to discuss. Maybe you can outline the system that you want to build. I am sure people on this mailing list can give some advice. Cheers, Chris. On 08.08.19 09:02, Kodippili Arachchige, Asanka wrote: Hi, The developer who is implementing the C++ server side ( FIX GW) of this change had posted a question about the maximum value allowed for the field according to FIX spec, and the reply he got was that there is no limit. https://forum.fixtrading.org/t/what-is-the-largest-allowed-value-for-seqnumber-34-unlimited-32-bit-int-64-bit-int/14507<https://forum.fixtrading.org/t/what-is-the-largest-allowed-value-for-seqnumber-34-unlimited-32-bit-int-64-bit-int/14507> Sending the value as a string throws a NumberFormatException 201908220122431.952|ERROR|QFJ Timer|quickfix.SocketInitiator:| |Error during timer processing quickfix.FieldException: invalid integral value: 18446744073709551615: java.lang.NumberFormatException: For input string: "18446744073709551615" at quickfix.FieldMap.newIncorrectDataException(FieldMap.java:401) at quickfix.FieldMap.getInt(FieldMap.java:255) at quickfix.Session.sendRaw(Session.java:2500) at quickfix.Session.generateLogon(Session.java:1926) at quickfix.Session.next(Session.java:1826) at quickfix.mina.SessionConnector$SessionTimerTask.run(SessionConnector.java:309) Thanks, AsankaK -----Original Message----- From: Philip Whitehouse [mailto:ph...@wh...] Sent: Wednesday, August 07, 2019 2:07 PM To: qui...@li...<mailto:qui...@li...> Subject: Re: [Quickfixj-users] Support for UI64 data type *** THIS EMAIL ORIGINATED FROM OUTSIDE OF THE ORGANISATION *** QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<http://www.quickfixj.org/documentation/> QuickFIX/J Support: http://www.quickfixj.org/support/<http://www.quickfixj.org/support/> ------------------------------------------------------------------------------------------------------------ Please read these warnings and restrictions: This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence. If you have received this e-mail in error or are not an intended recipient please inform the London Stock Exchange immediately by return e-mail or telephone 020 7797 1000. LSEG may collect, process and retain your personal information for its business purposes. For more information please see our Privacy Policy. We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. Calls to the London Stock Exchange may be recorded to enable the Exchange to carry out its regulatory responsibilities. London Stock Exchange plc 10 Paternoster Square London EC4M 7LS Registered in England and Wales No 2075721 ------------------------------------------------------------------------------------------------------------ -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma...<mailto:chr...@ma...> MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
