开云体育

Not sure that there is anything wrong with the connect/disconnect API design. Works well for many of us (and for some of us for decades).

Also, not sure what objects of the previous reader thread need to be transported. The reader thread (I guess that is the one you are taking about) has only one purpose and contains no long-term state:

• It reads a stream of bytes from the network socket that connects the client with TWS/IBGW, assembles complete API messages, deserializes the messages into objects, and calls the corresponding EWrapper callback with those objects

• It maintains no state and becomes obsolete as soon as the network socket connection is closed

When your client is not connected yet (504) or an existing connection with TWS/IBGW is lost (502), no network socket exists and there is no need for a reader thread. When a new network connection exists upon a successful connect() , a new reader thread is created to process the messages as long as that socket exists.

At any point in time, your client may voluntarily call disconnect()/connect() or, upon receiving an error 502, call connect() to reestablish the connection.

In the architecture of your application stack, TWS API is way at the bottom as an "Adapter" with a very simple interface contract:

• It can create a connection with TWS/IBGW
• While connected, it forwards requests your client makes via the EClient interface to TWS/IBGW
• While connected it forwards responses from TWS/IBGW to your client via the EWrapper interface
• It informs your client when the network connection with TWS/IBGW is lost (when TWS/IBGW voluntarily closes the connection or when it is closed by your network)

• It allows your client to disconnect voluntarily from TWS/IBGW

As an "Adapter" TWS API's life-cycle starts with connect() and ends with disconnect() or error 502. The API plays no role and is not involved in maintaining or restoring application state between connections. Higher layers in your application stack architecture or framework need to provide any "high availability" functions so that disconnect/connect cycles are hidden from the business logic in your client application

• Upon (re-)connect(), your framework will generally request all positions and open orders on behalf of your business logic.
• Upon (re-)connect(), your framework will generally subscribe to all data feeds the business logic needs

• Your framework completely hides API internal concepts (such as requestIds) from the business logic layer. That is often done with software patterns such as "model-view-controller" where the "model" buffers and separates the world of your business logic from the world of TWS API connections

闯ü谤驳别苍