No, there is no way for either of these things.

?

The TCP protocol suite contains a variety of mechanisms to automatically detect and recover from such incidents. But what it doesn’t have is a mechanism whereby an unexpected incident (eg spade through a cable, plug pulled from patch panel) results in some kind of notification being sent to the entities at both ends of the connection. It’s easy to imagine such a thing, but the practicality of doing it is close to zero, especially if you take into account all the timeouts, retries, resend requests etc involved in the automatic error detection and recovery machinery (not to mention the considerable range of different technologies that may be ?involved in what appears to be a simple internet connection). Also it would not be very helpful. Do you really want your application to be notified of every event that causes data to find a different route through the internet? All such mechanisms take time, not least because it takes time for them to even suspect that something might be wrong somewhere.

?

Although the TCP/IP stack makes great efforts to ensure that what goes in one end comes out at the other end in the same order, it inevitably incurs delays when something nasty happens somewhere in the middle. And if the recovery efforts are successful, you really don’t want the application entities to be told about this at all.

?

It’s worth noting that the API connection to TWS uses TCP Keepalives to ensure that failures are notified to the application fairly quickly. Presumably they are also used for the TWS to IBKR server connection. Without this optional TCP extension, an application only knows an error has occurred next time it tries to write to the connection (reads don’t generate an error if there is nothing to read). But the TCP Keepalives helps this by sending small packets periodically and checking for receipt of acknowledgment packets: if these acknowledgements are not received (after a suitable number of retries etc) then a fault is notified on the read.

?

As an example, a TWS API client application connection might not send anything for hours: for example, if the application is just receiving market data there is no reason to send anything. Without the TCP Keepalives, it would never know if there were a network fault, or if TWS froze and stopped sending data.

?

The parameters used for Keepalives for the TWS API connection (see the SetKeepAlive method in EClientSocket.cs) use an initial inactivity period of 20 seconds, followed by up to 10 repeats of the Keepalive packet at 100ms intervals after which an error occurs, so you can see that an error on this connection can result in a wait of up to 21 seconds before ?it is notified to the application.

?

Presumably the connection from TWS to the IBKR server uses Keepalives with longer parameters to give the 45 seconds you’ve observed.

?

But for neither connection can you specify the Keepalive parameters.

?

Thus there’s no way to get an instant error callback. What would you even do differently if there were such a thing? You just need to know when it’s possible for you to start sending and receiving data again, and 1102 gives you this.

?

As for as the second part of your question is concerned, I’m not even sure what you have in mind. When you get an error 1100, you must not send any further API requests until you’ve had the 1102. There could be one or more requests that you sent before the 1100 which you don’t know whether they have been processed. When you get the 1102, you can determine the state of PlaceOrder requests by use of ReqOpenOrders and ReqExecutions. But for things like market data or historical data requests you’re pretty much on your own. Personally I maintain a ‘ticker table’ where I record that data has been received, and after an 1102 I cancel and then reissue the market data request for any entry that is not marked as having received data.

?

I hope at least some of this makes sense!...

?

Richard