Support Board
Date/Time: Mon, 20 Jan 2025 11:24:18 +0000
Rithmic Data Connection Failure
View Count: 1975
| [2018-06-06 17:58:11] |
| |
|
Provide a copy of the Message Log by following these instructions: Support Board Posting Information: How to Post Your Message Log (Required In Some Cases) 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 |
| [2018-06-06 17:59:14] |
| |
|
This is what Rithmic has said: Rithmic is investigating degraded connectivity into the Rithmic infrastructure due to an ISP failure. The Rithmic system is functioning at this time.
There is no need to send the Message Log. We cannot help with this. 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 |
| [2018-06-06 18:18:38] |
| |
|
Refer to the response above at post #3. We will not be looking at the Message Log.
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 |
| [2018-06-06 18:25:14] |
| User374751 - Posts: 37 |
|
I emailed Rithmic. They request a R|API log file to be forwarded to their support team. Their emailed response follows: We are aware of an ISP outage, however R|Trader and other third party applications have failed over. Please ask Sierra Charts to send an R|API log file so we can determine why Sierra Chart has not failed over. Date Time Of Last Edit: 2018-06-06 23:59:41
|
| [2018-06-06 18:28:27] |
| User374751 - Posts: 37 |
|
Please confirm that your support team will forward the requested Rithmic R|API log file to the Rithmic support team.
|
| [2018-06-06 18:36:47] |
| |
|
Rithmic is requesting their own Rithmic log file. It is in the Rim subfolder in the Sierra Chart installation folder and has the name Rithmic.log.000. We do not have this. Only you do. Also any suggestion that this is some kind of Sierra Chart issue and we have not programmed a backup, is ridiculous. We are using the connection information that has been provided by Rithmic. 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: 2018-06-06 18:37:11
|
| [2018-06-06 18:52:46] |
| User548845 - Posts: 8 |
|
I got the same response from Rithmic that it has to do with how Sierra is connecting. Every other application that connects to Rithmic is working fine, except Sierra.
|
| [2018-06-06 19:10:40] |
| |
|
Rithmic has to accept full 100% responsibility for this. Not us whatsoever. If Rithmic is making changes to their complicated connection parameters, and cannot keep this simple so that a user application does not need to be kept up-to-date with these complex parameters, especially when they are not telling us when there any changes, that is fully their issue. It is not right that they cannot have a single address, or two addresses, and continuously keep those stable for years. Any way they did provide us new connection information we are updating them but allow about 30 minutes to an hour. 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: 2018-06-06 20:03:43
|
| [2018-06-06 19:47:12] |
| |
|
To understand what we mean by complicated connection information, these are the connection details specified by Rithmic: REngineParams : REngineParams.sAdmCnnctPt : dd_admin_sslc REngineParams.envp : The following variables need to be present : * MML_DMN_SRVR_ADDR=ritpz01001.01.rithmic.com:65000~ritpz01000.01.rithmic.com:65000~ritpz01001.01.rithmic.net:65000~ritpz01000.01.rithmic.net:65000~ritpz01001.01.theomne.net:65000~ritpz01000.01.theomne.net:65000~ritpz01001.01.theomne.com:65000~ritpz01000.01.theomne.com:65000 * MML_DOMAIN_NAME=rithmic_prod_01_dmz_domain * MML_LIC_SRVR_ADDR=ritpz01000.01.rithmic.com:56000~ritpz01001.01.rithmic.com:56000~ritpz01000.01.rithmic.net:56000~ritpz01001.01.rithmic.net:56000~ritpz01000.01.theomne.net:56000~ritpz01001.01.theomne.net:56000~ritpz01000.01.theomne.com:56000~ritpz01001.01.theomne.com:56000 * MML_LOC_BROK_ADDR=ritpz01000.01.rithmic.com:64100 * MML_LOGGER_ADDR=ritpz01000.01.rithmic.com:45454~ritpz01000.01.rithmic.net:45454~ritpz01000.01.theomne.net:45454~ritpz01000.01.theomne.com:45454 * MML_LOG_TYPE=log_net * MML_SSL_CLNT_AUTH_FILE=rithmic_ssl_cert_auth_params (full path to file) * MML_SSL_CLNT_CERT_FILE=rithmic_ssl_client_params (full path to file) * MML_SSL_CLNT_KEY_FILE=rithmic_ssl_client_private_key (full path to file) * USER=my_user_name (put your user name) Login Params: * LoginParams.sMdCnnctPt : login_agent_tp_r01c * LoginParams.sIhCnnctPt : login_agent_historyc * LoginParams.sTsCnnctPt : login_agent_prodc * LoginParams.sPnLCnnctPt : login_agent_pnl_sslc And what has happened, is there are small changes with characters here and there among all of these details. They do not have one or two simple domain names like everyone else would have. Like where they would be responsible for setting the actual IP addresses. And multiply those above details by 15 and we mean by 15 because there are 15 sets of those! So they occasionally make changes across this immense set of information here and there with little character changes. And they expect us to keep those up-to-date without notice. So who's to blame? None of this makes any sense. And something inadvertent as actually having an extra space character at the beginning or possibly the end of one of these text strings will cause a connection problem. Whereas that would never cause a connection problem when a simple domain name is used and we are responsible for the network connection using our own software rather than the Rithmic software. 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: 2018-06-06 19:53:57
|
| [2018-06-06 19:59:50] |
| |
|
We did a comparison, and basically the change involves a few characters at the end of this string: * LoginParams.sMdCnnctPt : login_agent_tp_r01c 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 |
| [2018-06-06 20:07:23] |
| User374751 - Posts: 37 |
|
Has the issue been resolved?
|
| [2018-06-06 20:27:27] |
| |
|
We are running into a complication. We need more time.
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 |
| [2018-06-06 20:46:11] |
| |
|
Message sent to Rithmic just now: We are running into a complication on our side, and we cannot do a new release today with the new connection details. You will have to solve this on your side and it is not right for the responsibility to be on us for the solution.
There is no reason why you cannot resolve this on your side. The connection details we are using our not that old. They are within the last year sometime. The change we have seen is only very minor. The complication relates to the fact that Rithmic uses an API component and not a direct connection. This is explained in detail here: Sierra Chart Does not Support External Service API Components We have to set this aside for now. Rithmic must resolve the problem on their side and they certainly have the ability to do that. We cannot commit further time to this today. 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: 2018-06-06 20:46:58
|
| [2018-06-06 20:48:36] |
| |
|
Rithmic has said this: Rithmic is aware of some Third Party Front Ends which were unable to failover to the alternate Internet Services due to the use of deprecated configurations.
The basic fact is, is they have a terribly poor design. This concept of deprecation is a completely ludicrous and absurd statement on their part. It does not tell the truth whatsoever. They are simply hiding behind a bunch of nonsense. In other words Rithmic, why are you making this so complicated, and changing things on the client side. None of this makes any sense. There is no one we work with who has any type of design like this. The only time problems arises when IP addresses are used rather than domain names. We are not going to put up with this crap from them or anyone. 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: 2018-06-06 20:51:22
|
| [2018-06-06 20:55:12] |
| User296719 - Posts: 21 |
|
It's working for me now, not sure if they rolled back or if you all were able to make the change? I do agree with you all, Rithmic looks like they make it a pain in the arse for you guys. This in turn hurts those of us that use the Rithmic feed to power our charts. Perhaps you all can convince them to make it easier? One would hope they would help out. Date Time Of Last Edit: 2018-06-06 20:56:08
|
| [2018-06-06 23:16:21] |
| User529356 - Posts: 40 |
|
ditto :) I trust that some form of resolution is in order shortly. It is beyond my understanding why Rithmic makes things more complex than necessary. Any thoughts as to why for a complete novice?
|
| [2018-06-06 23:52:04] |
| |
|
Message sent to Rithmic now: Does the issue relate to the environment variables and not to the login parameters when it came to using your backup network?
When I look at what changed in June 2016, among these lines of code: "MML_DMN_SRVR_ADDR=ritpz01001.01.rithmic.com:65000~ritpz01000.01.rithmic.com:65000~ritpz01001.01.rithmic.net:65000~ritpz01000.01.rithmic.net:65000~ritpz01001.01.theomne.net:65000~ritpz01000.01.theomne.net:65000~ritpz01001.01.theomne.com:65000~ritpz01000.01.theomne.com:65000" , "MML_DOMAIN_NAME=rithmic_prod_01_dmz_domain" , "MML_LIC_SRVR_ADDR=ritpz01000.01.rithmic.com:56000~ritpz01001.01.rithmic.com:56000~ritpz01000.01.rithmic.net:56000~ritpz01001.01.rithmic.net:56000~ritpz01000.01.theomne.net:56000~ritpz01001.01.theomne.net:56000~ritpz01000.01.theomne.com:56000~ritpz01001.01.theomne.com:56000" , "MML_LOC_BROK_ADDR=ritpz01000.01.rithmic.com:64100" , "MML_LOGGER_ADDR=ritpz01000.01.rithmic.com:45454~ritpz01000.01.rithmic.net:45454~ritpz01000.01.theomne.com:45454~ritpz01000.01.theomne.net:45454" , "MML_LOG_TYPE=log_net" The only thing that changed, was the LOGGER line. The other lines remained the same and then with the change that we made today, this is the only line that changed but it effectively really did not because the domain names are the same: "MML_LOGGER_ADDR=ritpz01000.01.rithmic.com:45454~ritpz01000.01.rithmic.net:45454~ritpz01000.01.theomne.net:45454~ritpz01000.01.theomne.com:45454" 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 |
| [2018-06-07 18:14:51] |
| |
|
No response from Rithmic, and we really do not believe we have ever been using old connection details or the three different times they have been updated in the last two years, what Rithmic was providing us were always old. So it is clear where the problem has always been. On the Rithmic side. Not ours. That is quite clear. 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: 2018-06-07 18:15:25
|
| [2018-06-07 18:37:39] |
| User529356 - Posts: 40 |
|
This lack of response is quite sincerely good hear about, at least in that it seems to confirm a general Rithmic theme. Surely it is possible they (the Rithmic crew) are working hard to compile a comprehensive and blatantly clear response to your message from yesterday and this reality explains their slow response time. I am hesitant to say such is likely, though surely time will tell. I look forward to any updates. Much gratitude.
|
| [2018-06-09 04:06:26] |
| User529356 - Posts: 40 |
|
Just for the sake of keeping this stream of communication open, I am compelled to add another message here. Lets not allow this to pass by again without some form of resolution. It is surely relatively minor in the larger scheme of things, but whatever the root of this problem it affects me and many like me quite directly. The fact that it only comes up every once in a while is irrelevant in my opinion. Quite honestly I don't know what your or their resolution process in general might look like or if a process of the sort would even apply here, though I do feel strongly that something needs to happen beyond what has. I am sure many customers feel the same or would feel the same if they understood that something is out of order beyond random ISP failure here.
|
| [2018-06-09 10:59:20] |
| |
|
Rithmic told us this after the outage: Well, our service is now restored. Please be aware that users with up to date config were not affected by our outage.
We strongly recommend that you release the correct configuration as soon as possible. The current configs were released in June of 2016. By my reckoning your config dates back to 2012. Let me know if I can provide any assistance. Attached is the folder that Rithmic has set up for us, to access their API software and the connection parameters. Notice the enormous amount of connection parameters. Also understand that Sierra Chart does not directly connect to Rithmic. It is Rithmic's own software that does the connection. So if there is a connection problem, only Rithmic can have an explanation as to what the issue is. We simply cannot. The Rithmic software that you are all running, contains the connection parameters in the red highlighted file in the attachment. Notice the date is 21-Jun-2016 . So we are not using old parameters and the claim that the parameters we are using are from 2012 is incorrect and we do not know how they are making a mistake with this. Now we also see two other Chicago area sets of parameters just above in the list. We do not recall seeing those before. So that looks as though they were recently added. We have accessed this folder about three times in the last couple of years and we do periodically update the connection parameters. And as we said, the parameters match the red highlighted file exactly. Therefore, what can we determine from all of this? The connectivity problem is with Rithmic and they have to explain what has happened. We have no idea. Perhaps the API software itself has to be updated. The reason we do not do that is there always complications when updating API components in general. It is something to be avoided. And as a matter of policy we no longer support those: Sierra Chart Does not Support External Service API Components But we do continue to maintain the existing support. At this point, we see that no action needs to be taken on our part because we have no idea what to do. Rithmic needs to explain the problem. Their current explanation does not fit. ---- 2018-10-12 update: We have tried to update the Rithmic API to the latest version but there is a binary incompatibility resulting in unstable execution of the bridge program and this is the whole problem with these client-side API components which Rithmic is using. This is not something we can solve. It is for this reason, why it is that we cannot use the connection parameters that Rithmic is saying we should be using. In order for us to use those new connection parameters requires that we build the bridge program using those new parameters. However we cannot because there is this binary incompatibility between the current Visual C++ we use and libraries like open SSL and the Rithmic libraries resulting in unstable execution. We even tried to use the very latest Rithmic libraries. It does not help. However, there are very tiny differences between what they say we should be using and what we are using which matches the highlighted file in the attachment. We will be highlighting the differences later today. So why it is Rithmic cannot solve this issue from their side makes no technical sense to us. And we will be pointing that out to them soon as we go over the differences. ---- Our message to Rithmic today (2018-10-12): Hello Rithmic, As you may be aware users are having problem connecting to Rithmic from Sierra Chart today and we have been previously told the connection parameters we are using are out of date but we are using them from a file dated in June 2016. See the attachment: https://www.sierrachart.com/Download.php?Folder=SupportBoard&download=19796 We are using what is highlighted in red. We have tried using your very latest API files and the updated connection parameters, but we still have the problem with unstable execution when running the bridge program that we build with your libraries. The issue might have to do with Open SSL or some incompatibility that you are not aware of between the Visual C++ we are using which is 2017 and your version. We have to use our version of Open SSL because we rely Open SSL ourselves. When we say unstable execution what we actually notice is very early on in the execution of the bridge after Sierra Chart connects, there is a jump to a function that is not even getting called. The difference between the connection details we are using and what you are saying we should use, as you can see are very tiny. Can you please look at the differences. It does not make any sense you cannot resolve the issue from your side. There are no hardcoded IP addresses. Just domain names and other text names. 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: 2018-10-12 17:18:45
|
 Rithmic connection parameters folder.png / V - Attached On 2018-06-09 10:52:37 UTC - Size: 684.32 KB - 881 views |
| [2018-06-09 11:00:41] |
| |
|
And also, we are working on our own full server-side trade simulation environment that Top Step Trader and MES Capital can use. We actually have finished it, and we are doing testing and improvements. This is a high quality full-featured simulation environment with complete risk management and reporting. It is very impressive. It is a fully integrated solution. 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: 2018-06-09 11:04:46
|
To post a message in this thread, you need to log in with your Sierra Chart account: