Hi syswizard, I didnât look at the history of the protocol, but it is really very general. If you look at its functionality you can use it for everything you want since the interpretation if only a matter of âtagâ-definition. Other parts of the definition are the âheartbeatâ to make sure that the connection is OK in the case that there is no other traffic/communication for a certain period and the follow-up (resend) function to make sure that there is a way to get information about executed orders during the time you lost the connection. There is also a âversionâ tag in each message, so you know which version of the protocol the other side uses. Most of the versions are âtextâ oriented so that it is easy to read (by humans). There are a lot of drawbacks since this type of protocol is not very efficient. In a new approach the fix-committee tries to make it ready for todayâs trading demands. This is called the FAST (FIX Adapted for Streaming) Protocol (http://www.fixprotocol.org/fast) but until now it is not used that much, other than version 4.2 â 4.4.
Exactly. The IB API is NOT an enterprise grade Automation Solution... IB has always clearly stated that it is not... Rather it's designed for small firms that: (1) Are on a limited budget. (2) Don't care much about latency. (3) Are not doing > 5,000 orders/day I've got about 20,000 lines of code that use the API... And you have to design everything asynchronolously... Because that's the nature of the API... And you can NEVER rely on any event firing reliably... So much of your code must "polling code"... Like every 30 seconds you syncronize all orders/executions/quotes/etc.. The OBVIOUS solution to these issue... Is to simply replace TWS with your Custom Platform via FIX... Assuming you have the *** resources to do this ***... Because experienced elite engineers that can actually work at this level... Are making $100,000 to $200,000/year.
As you probably already know, the asynchronous nature is unavoidable in the architecture. Your application utilizes the TWS API, which then makes TCP network connection to TWS, which is connected to IB servers over the internet. Whatever calls/requests your application makes, there would inevitably be some delay until you get the response. That asynchronous nature must be taken into account when developing applications, and in most cases you want to have some logic to make the whole thing synchronized. Whether to place that synch logic in the core "application" layer or some sort of wrapper API layer is an architecture choice, although the latter usually ends up being more elegant and robust solution.
I would really disagree since FIX is primarily used for trading, and it allows you to be as specific as you want regarding transactions. The advantages of using IB's FIX gateway over TWS API is that you don't have TWS between your trading system and IB's servers. An analogy could be, instead of using web browsers, you build your own program to communicate with web servers over HTTP. This way, you are not bounded by any limitations or bugs of TWS, you can use whatever programming language/OS/hardware you want, you can probably reduce some dozens to hundreds of milliseconds of latency (depending heavily on the network connection you use, because you can have direct connection to IB with FIX), etc. But as you can imagine, it can be far more difficult to develop, since you have to essentially write all the calls TWS API provides yourself.
Just throwing it out.... Trading is inherently asynchronous. Orders are issued and events are received from the market. If you have a lot of code that tries to make it look synchronous, then you are making it more complex than it needs to be. Just make everything state driven and be done with it. Very simple, fast, and not much code. Less code means less that can go wrong. My ATS only has a few thousand lines of code and trades 3 systems against > 500 markets. I wrote it over Christmas vacation.
Dloyer, How fast do you trade? My idea was to get rid of padre handling and focus on position handling... Once and forever!
The IB's implementation of FIX can be synchronous because it could ensure no possibility of receiving a message back that is not in the order with the event (request). The asynchronous nature of their API stems from the messages timing (as in any duplex asynchronous system) that is influenced by their serves availability and does not guarantee the proper timing. FIX connector can be written as a simplex system with the messages cue controlled by your app. One, of course, can make the API synchronous as well, however, in that case the system might run into a halt where with FIX it can be done seamlessly. P.S. We run FIX connectors for over 5 years now
It trades five systems. each with different time frames and symbol sets. None of these are what I would consider HFT. Java is fast enough and so is the IB API. Might have a dozen or so positions on at once when the market gets moving. The user interface is a simple web server built into the ATS to provide status information. I use a web browser to ask it what the current positions are, over all profit, profit per trade, active orders and state of each system for each symbol.