I thought the TCP socket will take care of the reliability part
between TWS and your client. Besides they are on the same local
host, so the only chance is buffer overflow, and that should be
taken care of by the TCP protocal.
Your are making the assumption here that they are on the same local
host. Our target end environment has analysis and trading on
separate computers, in separate locations.
Now regarding the internect connection with IB, do you actually
experienced such disconnection causing the client blocked in the
middle of a message? Would be very interested to learn the patterns
of "always where" it is blocked.
It's not so much as 'in the middle of a message', as 'is the
connection to IB still alive'. We currently process thru other
brokers, via different mechanisms, but, want IB in the loop. The
order volume generated by our setup can be significant, many
hundreds, and sometimes over a thousand, orders in a day. If the
system has 25 orders open in the market, and connectivity to the
broker dies, we need to know, so that manual procedures can be
initiated. Since the actual trading computer is sitting in a cubicle
on another site, where there is redundant net connection, redundant
power, etc, we need to do all of this programatically, there is no
human interaction at the computer actually executing trades in the
market.
Anyway, I am very interested in your investigations. And if enough
of us C++ users find this group too irrelevent to our project, then
we should form our own group.
I think i broke the ice, and the c/c++ folks are speaking up now :)
It looks to me like there's 2 main focus groups looking at the TWS
api. The first, is what i would term the 'hobby folks', toying with
automated trading for the first time, and learning VB in the
process. The second group, developers that have been doing trading
type stuff for a long time already, and the interface to IB is 'just
another tool to go in the toolbox'.
IB is an intriguing tool too. It will be interesting to see where it
all ends up.
