A couple scenarios come to mind when you get no callback during a client connection to TWS/API. Please make sure you implement/override all three? methods so that you get all possible error messages.
The first scenario is triggered in case your client sends API requests too early after the call to connect. Take a look at the chapter in the where it says:
Important: The callback is commonly used to indicate that the connection is completed and other messages can be sent from the API client to TWS. There is the possibility that function calls made prior to this time could be dropped by TWS.
In our experience, TWS/IBGW will not just drop calls they receive before? but will actually give up and close/disconnect the network connection which your client entirely. The various TWS API implementations show slightly different behavior when that happens:
- From a quick glance at the C# implementation it looks like you would get an callback via the function with signature "void error(Exception e)"
- The Java implementation, for example, will send a (misleading) error 502 via the "void error(int id, int errorCode, ...)" callback
So make sure you wait (under no circumstance sleep !) until is called before you send any API requests.
There is a second scenario where TWS/IBGW generally would simply close the connection instead of sending an error code or . That is when your client attempts to connect with the same clientId another client already uses. You would get the same error callback as in the first scenario (different ones in C# and Java).
This scenario? can happen even if the client that originally used that clientId has disconnected or is terminated. Depending on your network setup, the first client's socket might be "stuck" or lingering and TWS/IBGW will refuse connection requests with that clientId until the operating system completely closes the first client's socket. In TWS, you can click the green DATA button in the upper right corner and it shows you a list of all currently used clientIds.
In both cases, TWS/IBG has given up on the connection, the socket is closed, and calling clientSocket.reqIds(-1) will have no effect (and should actually fail). You would have to reconnect at that point.
As a matter of practice, our framework blocks the client during connect until both and callback have arrived. The arrival order of these callbacks is random, so that often comes well after and, at least when talking to TWS, after a series of message code 21xx informational error messages about the connection status of the various data farms. This approach has led to rock stable connection logic forus for? years.
Hope this helps,
´³¨¹°ù²µ±ð²Ô
On Tue, Jun 6, 2023 at 03:57 PM, A.R.SYD wrote:
Thank you for your response. I have used the error() method, specifically the error codes, to monitor the connection status between my C# App and TWS. In the case where the connection is established between my App and TWS, but the NextValidID callback is not called, I am unsure whether I should proceed with calling clientSocket.reqIds(-1) or attempt to reconnect? Note that my App connects to IB without any issues most of the time, there are occasional problems with the connection, such as the NextValidID callback not being triggered.
Note: I am using a paper trading account, and I run My App and IB as Administrator
