I am curious if anybody has come up with ways of doing real time
validation of the connection between TWS and IB. When using the
demo, our experience in this area was 'not good'. If I pull the plug
on the TWS connection at the firewall, it goes into a cycle of trying
to log back in, but never gives any kind of error indication to the
client application. I've kludged together a bit of an indication by
monitoring the bid/ask on the nq contract, basically we work on the
assumption that if there have been no updates for 30 seconds on the
nq, then it's likely the connection to IB is dead. The other option
we looked at, was a pinger thread, but that only verifies the network
connection, doesn't verify that TWS is indeed connected and live.
I am developing a socket API to TWS in C as I don't like C++ or MFC. I'm using the source they provide to the C++ lib as a "reference". Despite Richard Foulk's urging to "make the world a better place" the raw socket protocol as it stands is not well thought out and probably needs to be completely re-done. The C++ lib they provide is a thin wrapper over the socket i/o. Providing feedback on a beta product is one thing. Providing free consulting to do a proper design is another.
As for your specific situation of monitoring the connection to TWS, there is no heartbeat as far as I can tell. I know if I don't send anything to TWS the connection will be idle for over a minute. In essence TWS only talks the client in response to client requests. If you don't ask for anything you won't receive anything from the server (TWS). For now you would have to do your own fake heartbeat by making a request for something harmless and looking for a reply.
I is also don't think it's possible to recover from any communication problems on the socket due to the way data is sent from the server. They send a bunch of null-terminated strings for each logical record. If there are10 fields in a record then you read 10 "lines" from the socket. There is no header info with the number of lines or total length of the packet. All you can do is time out if you don't get all 10 lines, but then if any more data does arrive you don't know if it's the remaining part of the previous packet or a new packet altogether. At this point a timeout is fatal and you would have to close the connection and try to re-connect.
I'm just starting my investigation and this is what I have found out so far. If you are interested I can keep you posted on what I find as I go along. I'm not sure I will stay subscribed to this group as the dominance of messages appear to be VB programming questions.
Anyway, I hope this little bit of info is helpful.
- Nick
