Support Board

but I am sure traders community would appreciate the full functionality as well.

lagging and disconnection

It is clear, we probably have to bring back the bridge program, but we want to see what the feedback is with version 1982.

This affects all chart types, from Number Bars and P&F to simple time interval.

The worst part of this situation is that Transact completely refusing responsibility for this issue and pointing to Sierra. This is a silent push by Transact to force people switching to their new platform.

Yes it will be. We expect it will be out this coming month in September.

You are not alone. Many Transact customers feel the same. The worst part of this situation is that Transact completely refusing responsibility for this issue and pointing to Sierra. This is a silent push by Transact to force people switching to their new platform. They going to start losing business and customers in droves pretty soon.

The other problem is various websocket framing related errors. In the more than seven years or so that we have worked with websocket connections we have never seen any problem like this from a server.

If you are having problems, with losing the connection Transact and sometimes the reconnection not succeeding and the reconnection keeps getting lost over and over again

It seems the sierra websocket is holding up. I think its good to release.

your timing of the message is interesting. I was just looking into see why it is we were having a problem previously.

I have confirmed, that when using the binary price packets, you are sending out corrupted websocket data at times which is causing the lost connection. I cannot see any other possibility. I have looked at this quite closely. Nothing changes on our side, at the websocket level when you are using the JSON format, the websocket processing remains identical. (Note: and as we said above, there could not possibly be an issue at the network I/O or encryption/decryption level/layer)

The only variance is that there is less data flowing but the only possible reason that could be an issue is that if there is a frame over 65K, there is a different block of code to determine the frame size, but it essentially works identically. But that is not what is happening. There are no frames ever coming in over that size, when we are getting corrupt data.

And with the subsequent processing of the binary price packet, that is a safe read-only processing . So it is not as though there is any potential for data corruption using the binary price packets causing this issue. If there is any potential for data corruption, it would be more likely with JSON but clearly that is not happening because now we are processing enormous amounts more of that using the compact JSON format. (Note: We already knew there is no corruption occurring with the JSON data processing either. This code is reliable and has never been a problem for years with various usage of JSON internally and also with external services)

We will force an update, over the weekend.

We will force an update, over the weekend.

so they can make a decision to either abandon SC altogether and move to TT, Lynnsoft Investore R/t, Bluewater or other platforms

The Transact websocket connection does not provide market depth data. Only the top of book. But you should still see bars based on the top of book. We are looking into this now.

Ok we looked into this, the problem is the new Transact websocket data feed does not even provide best bid and ask size data either.

FYI: Just got off phone with Transact. He had me revert back to version 1941 (last one to work before new socket) and Bid/Ask works fine. He said first time he's heard of it. He said stay on this version until further notice. So you guys can do your stuff wherever the problem may be.