weidong wrote:
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.
They don't have to be on the same machine although I agree they probably would be most of the time.
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.
I haven't seen this yet. In my approach I never block anyway - the request will simply time out.
In my app I modified IB's code a bit - still using MFC though - but
does it in the burst mode, so that it doesn't have to call those
readInt or ReadFloat all the time. I also recongnize the possibility
that the available data in the socket may not be null terminated. So
by pulling them to a much larger buffer locally and having a macro
parsing through the buffer for readInt and readFloat I greatly
reduce the chance of blocking in the middle of a message. But I
admit I don't have a mechanism in place to deal with when such an
event actually happens, which could be caused by the internet
problem for example.
I have a generic "sockGets()" that reads lines from a socket and uses a large buffer to collect replies from the server. If there is an incomplete message the sockGets() will just time out. At that point the app can decide what to do but as far as I know a timeout is fatal.
- Nick
