Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Sat, 27 Apr 2024 18:46:02 +0000
Notice: Transact Websocket Connectivity Issue
View Count: 7692
| [2019-08-23 04:31:08] |
| |
|
What I can't understand is how is this possible for Sierra to release a MAJOR new functionality (Web Socket Interface) without adequately testing it with a counterparty (Transact) and have so many traders badly impacted, It was well tested. There are two basic issues. The two basic issues we have seen, is authorization problems on the Transact side. That is not something we have any control over or would have been aware of ahead of time and is easily resolved by Transact.And we also did not know the users were not able to use the Trading connection. It is certainly usable in the test environment, and we expected that Transact would make this available shortly. We did not realize it would be going on for weeks. And this most recent issue with the disconnection of the orders connection, is something that really we have just noticed in the last couple of days ourselves. We will have a solution implemented before morning. At best this is a minor non-impacting issue. And it is also something that that Transact could resolve on their side as well. They need to make the connection stable or just not allow the connection. 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: 2019-08-23 05:45:51
|
| [2019-08-23 05:21:40] |
| |
|
What I can't understand is how is this possible for Sierra to release a MAJOR new functionality (Web Socket Interface) without adequately testing it with a counterparty (Transact) Also in regards to this, there was extensive work done by us on the Transact trading websocket connection. This was done to a high standard and with high attention to detail. There were various issues/questions that were reported to Transact and they were resolved/answered, and this was extensively tested using our detailed test procedure and all tests passed. It was not until about more than two months later after the initial development was it then ready for release. It was not released, until such time that it was properly certified. 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 |
| [2019-08-23 11:48:13] |
| Meklon - Posts: 217 |
|
Support, I appreciate you answering this and explaining in such detail but the bottom line is - ALL of Transact users are not able to use Sierra platform to trade from the charts unless they roll back to V1941. It is certainly usable in the test environment, and we expected that Transact would make this available shortly.
That is NOT correct: Neither TEST (live Sym) nor Live (Trading) environment of Transact are working. Orders are being rejected outright and not displayed on Sierra if entered from Infinity DOM. Also, Transact provides NO time line for resolving this issue and claims major issues with Web Socket interface introduced by SC. Again, I don't think user (trader) community cares who's fault is this (Transact or Sierra) but it is clearly a concern that traders cannot use the platform and tools they have invested so much time and money into. Why not enable an original Transact Bridge connection in the current version of Sierra as an interim solution until Sierra and Transact figure out their connectivity issues? User support should be a priority for BOTH companies but it seems like none of the parties are making any effort to resolve this. Date Time Of Last Edit: 2019-08-23 12:56:27
|
| [2019-08-23 13:00:21] |
| User316362 - Posts: 210 |
|
Could you just keep this as a sticky post until Resolved by both sides?
|
| [2019-08-23 14:20:16] |
| Meklon - Posts: 217 |
|
Support, So is there any reliable solution for the constant disconnect problem to Transact server on V1978 besides downgrading to V1941? Not only that trading from the charts is disabled but now even the stable connectivity is not working! Please advise. |
| [2019-08-23 14:53:59] |
| Meklon - Posts: 217 |
|
It's not SC Support's fault.. All Transact's fault!!
They got SC to do the websocket connection, but hid behind SC when the websocket failed on their live servers. Shame on Transact's Engineers and support staff. 40winks, That is a quite assertive and adamant statement on your part. Do you have any proof to support this? There are many sources (including Transact) stating the opposite. I would like to underscore once again that traders DO NOT care which side has dropped the ball, they only concerned about their ability to facilitate the trading and have a reliable product. |
| [2019-08-23 16:01:25] |
| |
|
In regards to market data feed issues with Transact, we have discussed this now with Transact. They are setting up a test server to better analyze this, and we will use their JSON encoding method rather than binary. They say that would be more bandwidth efficient. But the binary method is what the old bridge program uses anyway. It certainly is faster on the decoding/client side. And also, we see no evidence this issue is on the Sierra Chart side. There is some framing problem which clearly looks like on their side. For example we see errors indicating extension bits set, and invalid opcodes. We never see these with any other service which uses a websocket connection. This would indicate a problem with the actual data coming from the remote side. And we have analyzed the Sierra Chart websocket functionality, and that is according to specifications. 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: 2019-08-23 21:54:49
|
| [2019-08-23 21:53:52] |
| |
|
We are looking at the possibility that the determination of the frame length is incorrect when there are larger frames.
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: 2019-08-23 21:54:11
|
| [2019-08-23 22:57:39] |
| |
|
We just sent this to Transact now: As I looked at how we determine the frame size, it is all technically correct and I went through actual step-by-step manual calculations to verify the code. It is according to specification and is logical.
So I don't see anything wrong with the decoding of the websocket frames on our side. Reference: https://tools.ietf.org/html/rfc6455#section-5 The purpose of this is not to place blame anywhere. We are just going through all possibilities to determine where the problem is. So far we are still not finding any issue on our side. But we are going to go through a test with them next week where they are going to look at the lower level packets. 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: 2019-08-23 23:28:42
|
| [2019-08-24 00:57:53] |
| Meklon - Posts: 217 |
|
Thank you Support, your dedication to resolve this problem is greatly appreciated. Please keep at this as we need a solution.
|
| [2019-08-24 06:00:04] |
| |
|
We also want to say that this is very easily resolved by Transact and we told them this as well. They just need to reduce the size of the websocket frames. Clearly there is some corruption occurring when they are too large. What the maximum size should be, we do not know but we suggested 4K. That will at least immediately mitigate the problem. At least we think so. This is just based on a reasonable assumption. We see no evidence at all that the frames are mishandled on the Sierra Chart side and our websocket processor has been in extensive use for years now with 0% problems like this with CQG and other services. If there is some problem on our side, it must have something to do with the large frame side but as we said, we went over this again today and saw no issue even when the frame size approaches 4 GB. All of the network I/O, and decryption, and websocket frame handling, is all common code which is extensively used every day by other services by thousands of users with no trouble. 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: 2019-08-25 05:41:37
|
| [2019-08-27 00:29:36] |
| |
|
We continue to not see any problem on the Sierra Chart side in regards to the framing errors with the websocket connection to Transact, which results in a lost connection. This is a 100% the same connection that is used with CQG, BitMex, our web-based trade simulator, Bitfinex, and there has been never any known instance of framing errors with thousands of connections every day for years now. And over the weekend we continue to look at this very closely and see no evidence of a problem at all on the Sierra Chart side. We gave Transact additional information over the weekend and we are waiting to work with them to analyze this problem further. We are not sure if they made any progress on it today or not. We are just waiting to go through a test procedure with them. They had us connect to a test server, and we have been using that connection Sunday evening but there is a problem with the packets on that server but nevertheless maybe they did gather some information from our connection to figure out the issue. 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: 2019-08-27 00:30:22
|
| [2019-08-27 01:54:48] |
| |
|
What we think we are going to do, is switch to their JSON encoding method. This is what they recommend to solve the lag problem and we have looked at the protocol and we understand that it does use a lot less bandwidth. The only thing is that it does not have any market depth data. This may also solve the websocket framing problem as well. We will try to get it out this week. 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 |
| [2019-08-27 02:04:45] |
| Meklon - Posts: 217 |
|
Will this be a temporary solution just to enable the trading from the chart and stability of the connection or a permanent fix for Transact issue? How will this affect Number Bars study and other functionality that required Market Depth data?
|
| [2019-08-27 02:40:26] |
| |
|
This has no effect on the trading support. Only market data. And ultimately we cannot say what the stability will be using their JSON market data encoding. But we can see it does use less bandwidth. This has no detrimental effect on the Numbers Bars study because that does not require market depth data. 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: 2019-08-27 08:08:04
|
| [2019-08-27 09:37:29] |
| Carl71 - Posts: 125 |
|
1)Their JSON market data encoding what kind of protocol uses? TCP or UDP? UDP is faster than TCP, and the simple reason is because its nonexistent acknowledge packet (ACK) that permits a continuous packet stream, instead of TCP that acknowledges a set of packets, calculated by using the TCP window size and round-trip time (RTT). 2)Are you saying that the only way to trade with their market depth is through their DOM? Sierra DOM will be unusable? |
| [2019-08-27 10:11:42] |
| |
|
1. The connection is always TCP. UDP is completely unacceptable for charting. No one would ever use that for charting purposes. 2. Yes at the present time they do not provide that with the JSON encoding. 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 |
| [2019-08-27 11:45:26] |
| Meklon - Posts: 217 |
|
If this implementation of JSON protocol will effectively render Sierra DOM unusable, then it will entirely negate the purpose of using Package 5 Sierra Chart we paying for. Orders from SC DOM will not be possible to place and there will be no information on executed volume, Bids / Asks and Pulling Stacking available which is a major component of traders decision making process.
Date Time Of Last Edit: 2019-08-28 03:44:22
|
| [2019-08-27 12:22:49] |
| User316362 - Posts: 210 |
|
Let's be clear. So chart trading will no longer be supported by TransAct?
|
| [2019-08-27 17:06:16] |
| |
|
So chart trading will no longer be supported by TransAct? Yes it will be. We expect it will be out this coming month in September.
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 |
| [2019-08-29 09:49:16] |
| |
|
We will be releasing in about an hour version 1982, which supports the new Transact compact JSON encoding for market data. The limitations are as follows: No market depth data No top of book bid or ask sizes. No daily high and low values (they will be present but not accurate) But we think this has a good chance of solving the lagging issues, and the disconnections. But we would need feedback to know that for sure. It is clear, we probably have to bring back the bridge program, but we want to see what the feedback is with version 1982. ---- On another subject: You can either pay for Sierra Chart through your brokerage account with Infinity/Transact. There should be no price change for the month of September. Or alternatively you can pay for Sierra Chart directly to Sierra Chart. If you run Sierra Chart using the shortcut on your desktop, you can then pay for usage time and take advantage of the 30% discount even if you pay month-to-month (we make no long-term guarantee as to how long this will be available). After logging into Sierra Chart, select Help >> Account Control Panel from the menu. And then follow the instructions here to pay for usage time: Sierra Chart Purchase and License Information: Renewing Access And once you are paying direct for Sierra Chart, you will just always launch Sierra Chart through the shortcut on your desktop. You would not launch it direct from the Transact software. You will continue to use the username that begins with Transact_user_. The above discount only applies to existing Transact users. 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: 2019-08-29 16:38:27
|
| [2019-08-29 19:45:43] |
| Meklon - Posts: 217 |
|
Support, we are happy to assist with testing and will give it a try by downloading version 1982, but it's clear that Market Depth and Order Book limitations are quite severe. Ultimate solution would be bringing back the Bridge connectivity at least for the time being until this issue is worked out. What you offering will address very important issue - lagging and disconnection but I am sure traders community would appreciate the full functionality as well.
|
| [2019-08-29 20:57:33] |
| |
|
but I am sure traders community would appreciate the full functionality as well. This is something that Transact will need to add to their compact JSON encoding. And also in regards to this, it is something also that Transact will need to resolve if this persists with the compact JSON encoding: lagging and disconnection
And also if the disconnect issue is resolved when using 1982 and the market is very active, then it quite likely indicates the problem was on the Transact side because the underlying handling of the websocket frames, which relates to the disconnect, is the same whether we are processing the binary price packet or the JSON messages. There is no difference. 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: 2019-08-29 23:05:49
|
To post a message in this thread, you need to log in with your Sierra Chart account: