Support Board
Date/Time: Sun, 24 Nov 2024 04:10:07 +0000
Post From: Now Released: Upcoming CME Direct Routing
| [2021-11-19 11:30:03] |
| |
|
The problems described in post #1 of this thread, involving the FIX protocol and the CME use of it, do not exist with FairX and their use of FIX. Sequence numbers can be reset on every connection, and there is a dedicated separate request, to request missed execution reports only. And the two available servers, use independent sequence numbers and whether they do or they do not, does not matter because the sequence numbers can be reset on each connection. The FairX implementation of FIX is a thoughtful and superior design, which solves all the problems with the CME FIX and other uses of FIX, which persist sequence numbers across sessions. The use of the same sequence numbers across sessions and across servers is monumentally absurdly stupid. It is the height of maximum stupidity. CME FIX is an accident waiting to happen. And it did happen, with the incident with TT back in February. This kind of problem simply does not occur with FairX. Now is this accident going to happen with Sierra Chart direct order routing to CME? There are numerous safeguards, in place to avoid this accident. So the answer is No. However, sequence number issues potentially can happen but when they do happen, there are safeguards in place to mitigate the detrimental effects of those. There was so much damn time spent dealing with sequence numbers issues, and the integration to CME FIX. Once again it is the height of absolute complete stupidity to the maximum the way that CME uses sequence numbers which is persisting sequence numbers across sessions which the FIX protocol supports. So it is not CME specific but it is still stupid. God damn stupidity. It is to the point of anger because of all the damn time we spent on this crap. And this problem does not exist with FairX! The CME is a dinosaur. They are going to get replaced. ---- Decades ago when the FIX protocol was developed for networks which did not have assured data delivery like a TCP/IP connection over an internal network, and with the needs of the communication needed by the users of FIX, there might have been some reasonable logic with the use of sequence numbers persisting across sessions in the way that FIX was originally used. However, over TCP/IP connections, and where the only need for recovery is the client asking the server for missed Execution reports and there is no need for the server to be asking the client for any missed messages, the use of persistent sequence numbers across sessions is totally illogical and leads to huge complications and accidents. And really the sequence numbers can completely be done away with over a TCP/IP connection. They are just not needed. Each message can have its own unique incrementing identifier. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2021-11-19 11:47:22
|