Hi. Im trying to track down the cause of a heap corruption break while running IB's TWS API. I was wondering if anyone had any experience with this type of problem or if anyone knows whether or not the C++ API creates new threads on the arrival of data. I am currently not using any type of mutexs.
IB C++ API Heap Corruption Issue.
- Thread starter walterjennings
- Start date
IB C++ API is total crap, way unreliable with almost 0% build-in recovery. When you lose connection to TWS the whole process is dead because you cannot re-connect.
I ended up wrapping up the whole IB thing into a separate sub-process, and just kill/restart it from my main TS process when things go out of control. FIX is only way to go...
I use the VB6 API...
And my ATS recovers from TWS disconnections very reliably...
With no special recovery code.
Most days my ATS via the API has 100% uptime.
This issue must be specific to C++ or the C++ API.
You're right about FIX...
But a well-designed API app can be quite robust...
Not fail-safe...
But fine if latency is not a big issue...
And your doing, say, < 5,000 orders/executions per day.
I'm pretty sure it's just C++ implementation. I've looked at their C++ source code (the library that connects to TWS and dispatches incoming messages), and it appears the code was written by some just-out-of-school guy.
My goal was to have TS up 100% during RTH, that's why I had to move all unreliable code to a separate process so I could bounce it with no impact on TS.
I'd like to have FIX connectivity regardless of the number of orders - it's robust, easy to troubleshoot, and uniform when it comes to switching brokers. Pretty close to certify my FIX gateway with IB, but I don't really want to pay $500 one-time setup fee though
Quote from speculatus:
I'm pretty sure it's just C++ implementation. I've looked at their C++ source code (the library that connects to TWS and dispatches incoming messages), and it appears the code was written by some just-out-of-school guy.
My goal was to have TS up 100% during RTH, that's why I had to move all unreliable code to a separate process so I could bounce it with no impact on TS.
I'd like to have FIX connectivity regardless of the number of orders - it's robust, easy to troubleshoot, and uniform when it comes to switching brokers. Pretty close to certify my FIX gateway with IB, but I don't really want to pay $500 one-time setup fee though
I started out developing an ATS adjunct to TWS via API using VB6/Excel...
But it has evolved into a ** complete replacement clone ** for TWS.
Once it's finished perhaps in 6 months...
After 2 years at 10-15 hours/week because I trade full-time...
I'll probably hire someone to do FIX front-end.
Think of the set-up fee as $2.00/day for one year.
If you have a full-blown ATS, its imperative to abstract it from any particular broker. That includes various data feed handlers, position manager, risk manager, various order gateways.
I started my TS in Python just to prove the concept, and then, when all logic has been debugged and tested, rewrote the whole thing into C++. Python is nice to build a pilot system because the development cycle is very short. But when it comes to execution speed in production, C++ is the only way to go given the current market conditions and participants.
Agree with first point...
My ATS is now about 15,000 lines of VB6 code...
Plus an Excel front-end which is a 10 MB workbook...
Tightly integrated...
And does all display plus significant calculation.
Maybe < 500 lines of code is IB specific.
My data feed handler is about 9,000 lines of VB6 code...
And together with an Excel front-end...
Takes Thomson real-time quote data...
And displays it PRECISELY the way I need to see it (no charts).
There is probably another 50,000 lines of various code going back to the 90s...
That does overnight number crunching or back office tasks.
As for speed and choosing C++...
I do not need millisecond latency to trade my stocks...
Mostly low volume NYSE issues.
Trust me on this...
If a stock trades a few 100 or a few 1000 times/day...
Total volume < 100,000 shares/day...
** Latency is a non-issue **.
If I had zero latency systems today...
My profits might go up by 10-20%.
Here is the fundamental problem with low latency approaches:
When you CHOSE to trade very liquid instruments...
And enter the low latency playing field....
You are CHOSING to compete with:
- the best trading operations in the world
- people with multi-million dollar tech budgets
It's like CHOSING to walk into the Bellagio...
And playing at the high stakes poker table...
Instead of systematically skinning fish at medium Party Poker limits.
My approach works very well on a medium scale...
I make a profit 90% of trading days...
And I got a good chance at $1 million net profit in fiscal 2008.