Keyboard Shortcuts
Likes
Search
timeout when connecting to TWS Gateway, but existing connection still works
|
Hi, I found this interesting phenomenon today when trying to connect with a second client to a running TWS Gateway, that I'm getting a timeout error. At the same time, the gateway has an active connection running by a client, that still is operational and works. Of course the new connection is using a different client id than the existing one. In all cases the connection is made to 127.0.0.1, to the same port 4002. I can telnet to this port and it opens up, so the Gateway is listening on the port. But a new client can't connect and gets a timeout. What could cause this issue? ?kos |
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. ´³¨¹°ù²µ±ð²Ô ? On Tue, Nov 19, 2024 at 10:57 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:
|
|
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:
|