Hi guys, I will try to make it brief this time. I have begun the integration of IB's API into my platform. And all went well until I had started working on the market data feed. The problem I have encountered is as follows: Since the tickprice/ticksize callbacks are called separately for each field, I need some sort of synchronization in place in order to make sure that the latest tick I store is valid. For instance, if we have a price update of MSFT from 72 to 72.1, I know for a fact that there should also be a ticksize update of the volume and so I must wait for it, otherwise I have a tick with latest price but out of date volume. So here are my questions: 1. Is it guaranteed that I will get the updates for a specific ticker in order? For Example: last price -> size -> bid -> bid size -> ask -> ask size -> volume. 2. Is it possible that two updates of the same ticker interleave with each other? For Example: last price 1 -> size 1 -> bid 1 -> bid size 1 -> ask 1 -> ask size 1 -> volume 1. _____last price 2 -> size 2 -> bid 2 -> bid size 2 -> ask 2 -> ask size 2 -> volume 2.
I trace all my IB Quotes, and from a quick look at today's trace, the only thing I can say for certain is that you always get bid -> bid size, and ask -> ask size. You can however, get a bid size or ask size without a preceding bid or ask. Sometimes you also get the Ask Exchange, and the Bid Exchange. Last Price is only sent when it changes, and is usually followed by Volume. If it help, here is a slice of today's trace for SPY around 16:01 PM. My codes: TS= Tick Size, TP= Tick Price, TR= Tick stRing, B= Bid, b= bid size, A= Ask, a= ask size, T= trade time, LS= Last Size, V= Volume, AE = Ask Exchange, BE= Bid Exchange 312507934 is my Request Id Timestamp is to the 10000th of a second. 16:01:01.0688,TR,312507934,T,1503604862,SPY:M,(16:01:02) 16:01:01.0688,TP,312507934,L,244.18,SPY:M 16:01:01.0688,TS,312507934,LS,3,SPY:M 16:01:01.0688,TS,312507934,V,444583,SPY:M 16:01:01.3185,TR,312507934,T,1503604863,SPY:M,(16:01:03) 16:01:01.3185,TS,312507934,LS,2,SPY:M 16:01:01.3185,TS,312507934,V,444585,SPY:M 16:01:01.5698,TP,312507934,B,244.17,SPY:M 16:01:01.5698,TS,312507934,b,94,SPY:M 16:01:01.5698,TP,312507934,A,244.18,SPY:M 16:01:01.5698,TS,312507934,a,8,SPY:M 16:01:01.5698,TS,312507934,b,94,SPY:M 16:01:01.5698,TS,312507934,a,8,SPY:M 16:01:01.5698,TR,312507934,BE,BQTM,SPY:M 16:01:01.5698,TR,312507934,AE,M,SPY:M 16:01:01.8192,TS,312507934,LS,11,SPY:M 16:01:01.8192,TS,312507934,V,444596,SPY:M 16:01:01.8212,TP,312507934,B,244.18,SPY:M 16:01:01.8212,TS,312507934,b,177,SPY:M 16:01:01.8212,TP,312507934,A,244.19,SPY:M 16:01:01.8212,TS,312507934,a,101,SPY:M 16:01:01.8212,TS,312507934,b,177,SPY:M 16:01:01.8212,TS,312507934,a,101,SPY:M 16:01:01.8212,TR,312507934,BE,T,SPY:M 16:01:01.8212,TR,312507934,AE,CQTM,SPY:M 16:01:02.0694,TS,312507934,LS,3,SPY:M 16:01:02.0694,TS,312507934,V,444599,SPY:M 16:01:02.0704,TS,312507934,b,202,SPY:M 16:01:02.0704,TS,312507934,a,89,SPY:M 16:01:02.0704,TR,312507934,BE,TM,SPY:M 16:01:02.3207,TS,312507934,b,9,SPY:M 16:01:02.3207,TS,312507934,a,107,SPY:M 16:01:02.3207,TR,312507934,BE,M,SPY:M 16:01:02.5709,TS,312507934,b,100,SPY:M 16:01:02.5709,TS,312507934,a,93,SPY:M 16:01:02.5709,TR,312507934,BE,BQTM,SPY:M 16:01:02.5709,TR,312507934,AE,CBQTM,SPY:M 16:01:03.3220,TS,312507934,b,327,SPY:M 16:01:03.3220,TS,312507934,a,1,SPY:M 16:01:03.3220,TR,312507934,BE,QTM,SPY:M 16:01:03.3220,TR,312507934,AE,M,SPY:M 16:01:04.0726,TS,312507934,b,999,SPY:M 16:01:04.0726,TR,312507934,BE,BQTM,SPY:M 16:01:04.3238,TR,312507934,T,1503604866,SPY:M,(16:01:06) 16:01:04.3238,TS,312507934,LS,1,SPY:M 16:01:04.3238,TS,312507934,V,444600,SPY:M
Thanks this is quite helpful. It seems I will have to create a small state machine to incorporate all of the rules you have mentioned: i.e. price -> size -> volume -> if followed by price or volume publish tick otherwise wait for x period of time for bid/bidsize/ask/asksize and then publish tick.
I think that this is one of those things that only IB can answer for sure as they know how their software operates.
@leonbrag215 : if it helps, you can take a look at my IB marketdata wrapper. It's Java and it's available on GitHub, private message me for the actual repository I had to decompile their JAR too in order to figure out how to write my wrapper. There were some examples on the net but didn't work.
Thanks for the offer. I am actually in the process of writing my own wrapper in C# and will probably solve the issue above with a state machine which will determine when I can publish a tick and know that it is valid. Did you address this problem in your wrapper as well?
Nope, I don't synchronize price and size. Since by the way, you also get price updates incrementally and not atomically. So it's possible you're in equilibrium, say bid/ask at 99/100, then you suddenly get a bid at 199 and after some undefined time you'll also get an ask at 200. So what do you do with your invalid 199/100 quote? Or 99/200.
I agree that bid/ask changes could be updated incrementally and it is not that significant whether this will be atomic or not, volume changes seem to me to be more important though. You can always design your system to react to changes incrementally which seems right to me. But at the same time, it seems like a waste of processing power to process an incomplete tick, especially if you relay on more fields then just the price in order to generate a signal. To answer your question though it seems I have no other choice but to wait a sufficient amount of time until I receive all updates, a penalty I prefer to publishing an incomplete or incorrect tick. Since they aggregate changes for 250ms (stocks, futures) I need to figure out what amount of time I can spare to wait until I publish a tick (even if it could be incorrect). This whole problem could of been solved easily by IB by sending all aggregated changes in one message instead of splitting to a message per field. But I will try to work around this I guess.
Actually I take it back bid/ask spread is very important, and I can think of a lot of implications for an incorrect bid/ask spread simply because of these sync issues.
>> This whole problem could of been solved easily by IB by sending all aggregated changes in one message instead of splitting to a message per field. I don't know if the exchange itself sends atomic updates or not.