You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
FIX Testing
- Thread starter Craig66
- Start date
Quote from Craig66:
So even QuickFix may be complete overkill for basic trading? It would seem that to develop something basic would not be too hard.
Someone mentioned that you have to generate $100 of commissions, what time frame is this over?
Unless you work for some hardcore operation managing millions, your broker APIs that are non-FIX are your best bet.
I don't see what load has to do with it, all the broker API's I have looked at (IB, MB, Genesis) all have gotchas or are just flat out awful (not to mention unstable).
The major benefit of FIX as I see it (apart from the somewhat enhanced broker transparency) is the well defined order model.
I place an order though the IB API, I get 3 identical filled messages, why? Nobody knows, which one do I take as being gospel? Nobody knows, is this always going to be the case? Nobody knows... this rubbish simply isn't good enough when my money is on the line.
The major benefit of FIX as I see it (apart from the somewhat enhanced broker transparency) is the well defined order model.
I place an order though the IB API, I get 3 identical filled messages, why? Nobody knows, which one do I take as being gospel? Nobody knows, is this always going to be the case? Nobody knows... this rubbish simply isn't good enough when my money is on the line.
FIX is really pretty easy to use.
The basic Fix42 messages are all you need for most trading.
Although it is meant to be a standard brokers vary significantly in how they implement it. The IB implementation is pretty non-standard and has a lot of custom tags. It's also even slower than the IB API so you might as well stick with the API unless you already have a FIX enabled app.
The basic Fix42 messages are all you need for most trading.
Although it is meant to be a standard brokers vary significantly in how they implement it. The IB implementation is pretty non-standard and has a lot of custom tags. It's also even slower than the IB API so you might as well stick with the API unless you already have a FIX enabled app.
Quote from Craig66:
I don't see what load has to do with it, all the broker API's I have looked at (IB, MB, Genesis) all have gotchas or are just flat out awful (not to mention unstable).
The major benefit of FIX as I see it (apart from the somewhat enhanced broker transparency) is the well defined order model.
I place an order though the IB API, I get 3 identical filled messages, why? Nobody knows, which one do I take as being gospel? Nobody knows, is this always going to be the case? Nobody knows... this rubbish simply isn't good enough when my money is on the line.
You get three filled messages, so you maintain a data structure that persists and then gets "matched".
I posted what I did because I've used both broker APIs and done certification testing for various ECNs. You don't gain that much of an edge because you've already "lost"[1] if you're using a retail broker.
[1] The FIX advantage gains you very little on top of most retail platforms with poor API performance.
Point taken, I'm aware it does not give me a trading edge. I'm just more concerned with not re-inventing the wheel if and when I have to shift.
As for the 3-filled messages, err...I'd worked that out, you can develop a finite state machine around the order id, the problem being that nobody seems to be able to define all possible transitions and the error handling is abysmal.
I write telecoms software for a living, so I maybe I'm a little over sensitive to these issues, anything that can go wrong, will.
As for the 3-filled messages, err...I'd worked that out, you can develop a finite state machine around the order id, the problem being that nobody seems to be able to define all possible transitions and the error handling is abysmal.
I write telecoms software for a living, so I maybe I'm a little over sensitive to these issues, anything that can go wrong, will.
Quote from Craig66:
As for the 3-filled messages, err...I'd worked that out, you can develop a finite state machine around the order id, the problem being that nobody seems to be able to define all possible transitions and the error handling is abysmal.
I have a map from order id into my own order info struct. It saves BUY/SELL flag along with number of executed lots in that order. Then when I receive execution signal from IB TWS I compare the incoming filled number (or remaining number) with my saved. If there is a change I call my function on the difference, else I simply ignore the execution signal.