IMHO a lot posted above is over complicated & over engineered. The IB API is OK as a solution, and yes, of course is async. How can communicating with an exchange not be? - I send a new order -- and get an async ack. - I send an amend -- and get an async ack. - I get a *partial* fill. - I get a fill. - I send a cancel -- and get a cancel ack. ... How would you make fills synchronous !?! ... Also, having a static position structure can be useful. Update it on new / amend / fill / partial / cancal-ack. Note that it should assume exposure, as-in assume "new" exposes you before ack, and that cancel always still exposes you *until* ack. Also, the IB new-ack latency is pretty slow compared to "the competition" so I really would not bother with threading on the customer end. The slow part is from you to IB to Exch to IB to you .. and threading on your end does not help this much at all. Save 10ms then add their 300ms? Not worth the 10ms.
I use a controller that handles events from the TWS API. So I have my own interface that is implemented in a class that extends their Ewrapper. This class also implements a Messagehandler. So the controller issues a request to the Model that implements my interface and extends the Ewrapper. The controller then listens to the model for responses or errors and acts appropriately. This allows me to implement the Model with different versions so currently I have one for TWS and another Test one that implements the TWS functionality by replaying history (in my case price action via candles data on a 5min basis but this can be anything down to 5sec!! if you have the DB space) data that I had previously stored. For my strategies, I have them for entries and position management I use the Swingworker class. So for each position that I may trade there will be a thread that executes my strategy then when a position is entered the controller kicks of another worker that takes over the management of that position. I select 10-15 stocks a day that I would like to trade and store the chart for that day and the prev day. This data is then used to back test new strategies. So far so go
I have read the whole tread and many people speak about ATS as a state machine with async connection to IB. Actually seems there's a flaw in this approach: when order for 700 gets filled ATS will lose consistency between orders and positions. Initial state was 1000 needed, 300 had and 700 to buy. As soon as order filled, before both position update and order update came, the state will be undefined, e.g. 1000 need, 300 have but no active order so it will create order for 700 again and it might be executed (in this case I assume that original order status updated already so it is not active anymore but position update has not come yet). Any idea how deal with it?
To keep system stable use another variable as a switch/state to signify order in progress. This will prevent submitting another order until last order status is resolved (not easy considering partial fills, no shares to short, order routing issues, network issues - you get the picture). By doing this you can control "undefined" state before it does any damage.
The thing is that order itself is done and its state consistent - in my example we just received that order was filled and know it for sure, however position haven't reflected this yet. So if we make automatic decision on broken state: no active orders (as it was filled already) and position not updated yet, we can mistakenly create another order and it might even be fulfilled. It would be easier if we knew for sure that order status gets updated first and then position, so upon receiving 'order filled' status we could put position in pending state and delay decision making until 'position update' comes. But as far as I know no one can guarantee it
I just do not get how you would know position and the system does not? Maybe you are not utilizing all the features of API? Usually there are several simultaneous ways of dealing with orders and positions through various API; you get order status updates as the order progresses through the system, separately executions and then portfolio and positions updates. Some of them are immediate and some come with delay. In simple case if you rely on automation it is you who sets "undefined" state once you fire the order and until your program gets desired response the state remains unchanged. This way there is no chance of firing next order until previous one has been completed or cancelled. For example IB API order status would be first to respond, real time execution would fire immediately after order completion but portfolio updates are periodic.
In your ats you keep track of orders and positions. So if you send an order you keep the order on a map or similar. The order gets filled you remove the open order on the map and add a position to another map
I think what ruslan refers to is the potential discrepancy between internally managed position state and broker position state. Obviously the two must be synchronized on a continuous basis. Generally by properly handling fills/cancels properly such discrepancy can be avoided. Internal position state should be updated on each fill/partial fill, only, and not cancellations. Also submitted orders should be actively managed internally. Each time a fill/cancel comes in the internal order must be updated in order to know whether the submitted order has been completed, whether via fills or cancellations. This requires additional flags/counters. The easiest solution is to create internal order object types and update those upon incoming fills and cancellations. Then it does not make a difference anymore whether the incoming message that pertains to a particular order is a complete fill, partial fill, full cancellation/reject or partial cancellation.
I would ask instead the opposite question. How would you handle trading, if the API weren't asynchronous ?
very good point. Trading (and most tasks in life) are by nature async. Events and the handling of those...