That's a question for IBKR and it has been like this forever. There is a post in our group archive every few months such as this one from August: TWS not connecting throwing a timeout error as port is stuck in (CLOSE_WAIT) state .
The workaround is to avoid TCP/IP connections that get closed without sending the "API\0" message and firestorms of several connection requests simultaneously.
If you want to learn more about what happens (though you won't be able the change anything), enable verbose/debug logging in TWS, look at the logs, and follow how the port listener thread pool starts dedicated API threads for each connection. For some reason (race condition, missed socket-closed exception, singleton, ...) one of those threads can get locked up if it does not see the "API\0" message, or if the TCP/IP connection gets closed immediately after it has been established. Once that happens, TWS/IBGW can accept more (physical) TCP/IP connections, but it cannot start client conversations any longer until it restarts.
´³¨¹°ù²µ±ð²Ô
?
On Tue, Nov 19, 2024 at 11:29 AM, ?kos Mar¨®y wrote:
´³¨¹°ù²µ±ð²Ô,
?
What would be the reason for no new TWS API client connections, assuming the client is valid and follows the protocol? What is the limitation here?
?
?
?kos
On Tue 19 Nov 2024, 18:26 ´³¨¹°ù²µ±ð²Ô Reinold via , <TwsApiOnGroupsIo=
[email protected]> wrote:
I can telnet to this port and it opens up, so the Gateway is listening on the port.
This is likely your problem. TCP/IP socket connections that do not start the TWS API session conversation with a properly formatted "API\0" message or that send some other data. As you describe, TWS/IBGW will still accept additional TCP/IP connections, but an API session cannot start any longer until restart. Not sure whether that is by design or a side effect of the implementation.
Avoid any such TCP/IP connection requests from port scanners or port monitoring tools, or at least send a proper "API\0" message.
´³¨¹°ù²µ±ð²Ô
?
