Stephen, In my experience, the main problem is to get at the 'state' of your TWS-IB operations inside your own computer. This is far from simple and documentation is very inadequate (restarts, dropouts, etc). It is obvious that all this was put together by people who never traded themselves over an API. In defense of IB however, they are still the most advanced. Over the years, many discussions were posted on this at IB's forum, mainly under API. I learned a lot from these. I worked a long time on my own solution, but once you have this licked it becomes relatively trivial. As to FIX, it seems that IB is kind of a slow starter on this. Maybe similar problems. A real McCoy would be to start getting rid of Java and forget about FIX.
I'm not hating on IB here, I'm just saying that the API in its current sate is inadequate for my purposes. It is obviously a fine solution for many people. The problems you mention (drop outs, etc) are very important issues that should easy to handle from the API. As far as being the most advanced, what criteria are you using to judge? TWS itself is definitely very advanced.. but from an API perspective it certainly isn't.. Lime's api is however handles dropouts beautifully and can tell you individually which streams are connected/disconnected, automatic reconnection, etc as well as giving raw data (milliseconds) and all that so you can estimate latencies yourself. There are better apis out there.. I meant co-located the server in your facilities.. as far as aggregate depth that is understandable because inidividual orders at every level is overkill most of the time, but it would be bery nice to have the number of orders and the total size so you could at least calculate the average order size at that level. ms timestamps are generated by the exchanges I care about.
You seem to have a hard time resisting raising your "get rid of Java" issue everywhere. Anyway, IB is not slow starting the FIX; we have had it for years and it is being utilized by all our institutional clients. We have also made it available to retail, partially on your request. I hope you are using it.
I don't know about FIX.. the only reason I can think of for using it are if you are getting a raw quote feed via a socket. If you are already using the API for quotes, why not use it for orders? Re: java. What do you suggest as a replacement? Java is absolutely beautiful compared to most of the other things out there. Dotnet would be nice if it wasn't tied to mickeysoft. (Yes i know about mono but it is terrible) The only way I would support some broker moving away from java is if they allowed clients to connect with raw sockets and published a thouroughly documented protocol reference.
We currently don't have clients co-locating. However, it seems that you also have a list of other issues that would need to be addressed in order for you to become a client. Perhaps some day in the future we can do business together. Thanks for the conversation.
Because of the focus on performance, I'm guessing, too, that Stephen wants to route his orders himself, and not via SMART. This doesn't work well with IB's fee structure.
Yes, I do route myself.. each exchange has different rules and fee structures so I optimize using that information as well.
I don't know anything about the Goldman algos. IB has VWAP guarantees, and the orders exist on their servers - not sure about TWAP. I don't see why non-NYSE stocks are an issue at the "close" - they continue to trade after the close on ECN's, althought admitedly the B/A spread widens somewhat. But in a pinch, that will do. In my experience, unless the stock has earnings, there is almost zero chance of a disaster of trading liquid NAZ stocks on ECNs in the after hours as an "emergency" exit. Howerver, I do appreciate your desire to wanting to cover as many contigencies as possible during RTHs. nitro