Support Board
Date/Time: Sat, 23 Nov 2024 07:00:27 +0000
Announcement: Open Specification Protocol for Connectivity to Data and Trading Services
View Count: 7799
| [2013-06-15 08:08:52] |
| |
|
Sierra Chart has started an initiative to establish an open Protocol for the connectivity between Data and Trading services and the programs and applications that use those services. Complete details can be found here: http://www.sierrachart.com/index.php?l=doc/doc_GeneralDataTradeServiceProtocol.php We have made a lot of progress on documentation and it can be found here: http://www.sierrachart.com/index.php?l=doc/doc_GSPMessageDocumentation.php It is used Sierra Chart, and by TransAct. We have developed a bridge for Rithmic. And we are also looking to develop a bridge for IQ Feed. We are making the source code for the Rithmic Bridge available. 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: 2013-06-15 23:52:45
|
| [2013-06-15 23:30:39] |
| |
|
We recognize that this is a very bold initiative. However, it is something which is so very badly needed in this industry. What exists currently is very disorganized. Think if a web browser had to be using blackbox API components or some proprietary protocol to every website it had to connect to. The web would be completely dysfunctional and web browsers would become terribly unreliable. This is what currently exists in this industry. And this is what we are working to change. Anyone in this industry, who does not acknowledge this, and feels that the status quo is reasonable, is not facing up to the current realities and to the potential for a much better way which can exist. Everyone is going to benefit from this. The best connectivity model for Data and Trading services is for them to provide a GSP server on their servers. Or, provide a client-side server executable program which runs on the client's machine which handles the encryption and compression to the backend server. An application program on the client-side will then use a simple GSP connection to that server or use a simple open-source wrapper class that provides request and response functions using an asynchronous socket. We do recognize is going to take some time for this to gain a following but we are 100 percent confident this is going to succeed. Nothing is going to happen if no one does anything. We are going to be out in front to take all of the steps necessary to make this a reality. For the historical record, this is a public service initiative by Sierra Chart for the community, which was started in May 2013. If you are interested in being part of a working group on this project, then please do let us know. 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: 2013-06-15 23:36:03
|
| [2013-06-16 20:01:50] |
| AndyL - Posts: 119 |
|
Maybe it would be helpful to get this protocol more accepted faster if you would provide bindings for the most popular languages. I think part of the reason why projects like msgpack or protobuf have good quality bindings for a bazillion languages, and you can be productive with these in no time. P.S. did you have a look at Blink protocol? Its probably a little late to discuss this, but looks interesting. http://blinkprotocol.org/ |
| [2013-06-16 20:14:07] |
| |
|
Not sure what is meant by "bindings". The protocol is not specific to any language. It is merely a protocol which is language independent. It is not the intent of this protocol or initiative to be creating software which implements the protocol. That is for implementers to be doing. For example take the FIX protocol, it is language independent. From FIX website: The Financial Information eXchange ("FIX") Protocol is a series of messaging specifications for the electronic communication of trade-related messages. It has been developed through the collaboration of banks, broker-dealers, exchanges, industry utilities and associations, institutional investors, and information technology providers from around the world. These market participants share a vision of a common, global language for the automated trading of financial instruments.
FIX is the industry-driven messaging standard that is changing the face of the global financial services sector, as firms use the protocol to transact in an electronic, transparent, cost efficient and timely manner. FIX is open and free, but it is not software. Rather, FIX is a specification around which software developers can create commercial or open-source software, as they see fit. This project needs to be completely independent. It should not utilize or involve any other protocol or software other than the FIX protocol which it needs to be similar to and improve upon. With FIX, each message contains a version number, a sequence number, a checksum, the sender comp ID and the target comp ID. All of this is unnecessary over an authenticated TCP/IP connection. It is a text format which is not efficient which involves the conversion of binary data to text and text to a binary format. This is regarded as inefficient for market data and is definitely inefficient for historical data transmission. As a practical matter for real-time market data, with fast CPUs and efficient code, our impression is that FIX is not really that inefficient . But then again we do not have experience with it using it on a server serving hundreds of 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: 2013-06-16 21:40:06
|
| [2013-06-16 20:40:25] |
| |
|
Blink Looks like a very good specification. The data format used by GSP is very similar. In the case of text strings, we use fixed length strings. Possibly making them variable length by prefixing the string with its size can be a good idea, but it is more convenient to use a fixed size data structure being that strings are not sent in high-frequency messages.
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 |
| [2013-06-16 21:39:19] |
| |
|
There was a small mistake in post #5. We meant to say the FIX protocol is language independent.
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 |
| [2013-06-16 22:03:13] |
| AndyL - Posts: 119 |
|
Just saying, GSP might be accepted faster if there were libraries availaible like for fix.
|
| [2013-06-16 22:33:08] |
| |
|
We see this differently. The most important thing is that service Data and Trading service providers adopt this. That is going to be the biggest hurdle. They are not going to have any problem working at the protocol level and providing a library is not going to change things. If we were to provide a library, that only introduces a whole another aspect which would be outside the scope of this initiative which is only going to create undue interference with getting this protocol adopted. For example, do you think DTN would be more interested in adopting is protocol if there is a library for it? We would think that would not even be relevant at all, and if we were the ones creating a library, they would then have more of an incentive to stay away from this because they would probably disagree with how the library works. When it comes to actual implementation in a particular language, everyone has their own view on how that should be done. And that is the primary complaint about API components. They are too proprietary and specific to a particular implementers view of how to program. We can tell you, there is a lot of junk programming out there. If libraries are created, then that will be the responsibility of implementers of this protocol. That's not for us to be getting involved with. At some point, will be contributing a C++ wrapper class that supports the protocol to simplify the use of it. One popular library for fix is quick fix. The C++ version, is substandard. We did use it for a while and it was a waste of time and created problems. We implemented our own FIX processing class which is vastly superior. Quick fix is heavyweight, overly complex, hard to use, terribly inefficient, and has bugs. We have seen similar comments about it from other programmers as well. It drops messages and disconnects without giving any reason. It has everything that we simply do not like. Take for example Tele-trader. They had contacted us and were interested in us adding support for their data services. We did begin some work with the integration. For real-time data the only choices for integration are an API component, which we stay away from, and a web-based protocol which is more complicated than we are comfortable with and is an older protocol. So the fact that they actually have a library, is a disincentive for us to even work with them. Everyone has their own view. 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: 2013-06-16 23:08:27
|
| [2013-06-16 22:43:38] |
| |
|
We also recognize, that Data and Trading Service providers and the Client users of those services, will probably have some differences about some aspects of this protocol. For example, the use of fixed length strings. We recognize that this is where there needs to be some kind of collaboration to work out these differences and create a good general purpose protocol that will be plug-and-play. We definitely believe GSP is a very good starting point and overall the protocol as it exists now is good and is complete with the basics. 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 |
| [2013-06-17 00:52:06] |
| |
|
Had a look at this Blink again. What we have developed in GSP is quite similar to what they are doing with Blink. The Blink protocol is meant for financial market data and trading. The have a specification to encode FIX messages using that protocol. They also were involved with the development of FAST. We are going to contact them to see if we can develop a working relationship on this. This is exciting. Thank you for pointing out that project to us. It is exactly what we are looking for. If we can build cooperation with them, we are definitely going to have a lot more momentum and legitimacy with what we are doing. 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: 2013-06-17 05:44:23
|
| [2013-06-18 01:51:57] |
| |
|
We did contact the developers at Blink and they are going to contact FIX Protocol Limited about the idea. They are a member. After reviewing Blink, one thing has become apparent and we have added this to our GSP overview page: In this initial implementation of GSP, fixed size binary data structures with fixed length strings are used. This allows for very easy implementation in code, compactness of messages (where strings are not used) and very fast performance.
We recognize the importance though of following a format similar to FIX where each field in a message is prefixed with a code. In GSP this code will signify the size, data type, and meaning of the following element in the message. Therefore, we do intend to develop another version of GSP where messages contain prefixed data fields. In this way, fields can be easily added, and removed or not included in a particular message, in order for the protocol to be more adaptable and not require executables to use an updated header file with updated data structures if message fields/variables are added or removed. 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: 2013-06-18 01:54:49
|
To post a message in this thread, you need to log in with your Sierra Chart account: