?

Just because you don't like a design detail does not make it a design flaw, Arthur. Many of our group members are running rock stable automated trading systems based upon TWS API, some of them do that for more than 20 years, and Richard King created this mail group in 2002. There are aspects of TWS API that I personally would have designed differently, but it appears to me that TWS API is not fundamentally flawed.

You still have to get a much better understanding of TWS API, use it in a real (paper) account, and spend more time studying and understanding the . You clearly don’t have a grasp of TWS API yet if you seriously believe you “will avoid using the request() functions that need an ID …”.

TWS API is a low level, simple, and very fast asynchronous real-time protocol that is only concerned with the exchange of messages between your client app and TWS/IBGW within the current session (the time between connect() and disconnect() or when TWS/IBGW closes the connection). It connects your client with a complex trading world (any imaginable combination of accounts at IBKR, hundreds of exchanges, virtually unlimited number of tradable instruments) and relays to your client app(s) in real-time all events that trading world generates.

The API uses ephemeral IDs to relate one or more responses with a specific request and the actual ID values have no relevance once the session ends. IDs that fall into this class are orderIds, reqIds, and tickerIds.

Due to the real-time, asynchronous, and event-driven nature of the protocol, the design encourages maximum autonomy for clients and TWS/IBGW each. Therefore, your client application is in charge of and free to select the actual ID values with very few limiting requirements:

• At any point in time during a session, IDs have to be unique in the sense that no two outstanding requests shall use the same ID.
• orderIds shall be monotonously increasing by a value of at least 1
• the first orderId in a session shall have a value of no less than the nextValidId() value announced by TWS/IBGW during the connect() phase of the protocol.
• reqId and tickerId need to be unique but are not required to increase monotonously
• Other than that, your client may divide the available range of integer numbers anyway it likes (32bit signed int not 64bit signed long). There is no hard requirement that reqIds/tickerIds shall be different from orderIds, but since all requests share the same error() callback, practically it makes sense that you assure orderIds, reqIds, and tickerIds are all unique within the same session.

In a regime where TWS/IBGW restart daily, a client session cannot be longer than approx. 24 hours. At a rate limit of 50 requests per second, no client can generate more than 4,320,000 valid requests or orders during each session (practically only a tiny fraction thereof, though):

• The 32bit integer type has a value range of -2^31 to 2^31-1 which is a MAX_VALUE of 2,147,483,647. In other words, the integer data type can hold sufficient unique ID values for at least 500 sessions.
• No client can place more than 4,320,000 orders per session. Dividing the number space such that reqIds start at nextValidId() + 10,000,000 is therefore appropriate and there will never be an overlap in that session. And the initial values are recalculated right after connect() in the next session.
• realistic clients create only tens or hundreds of orders per session so there is really no risk of “overlap”. But if you are concerned, divide the number space such that orderIds increase starting at nextValidId() and reqIds/tickerIds decrease starting at 2,147,483,647 (MAX_VALUE ) each session.

As I said before, the scope of orderIds, reqIds, and tickerIds is one session for one client. In other words, identical numeric IDs can (and probably will) be used when a client reconnects for a new session or when several parallel clients have their own sessions. Objects with life spans of more than one session, therefore, have permanent identifiers that are different from ephemeral session IDs:

• Once your client has placed an order using the next valid orderId and in if that order is not rejected by IBKR, TWS API will send you a new Order object that contains the order’s permId. permId is assigned by IBKR, has a scope of “Account”, and is also an “int” value. This way, each order in each account can be identified uniquely in perpetuity, unless you plan on placing? 2,147,483,647 orders any time soon.
• In case an order fills (entirely or partially), one or more "trades" are recorded in and objects. These objects are identified by very long string based .

My suggestion is you forget about the IDs since there will be many and more important challenges ahead of you. Apply the “set and forget” and “keep it simple” principals, add a few lines of code to the interface between your clients and TWS API, and manage IDs just like we and many others do successfully for years:

• maintain a local nextOrderId() service that is initialized with nextValidId() when the client starts and monotonously increases each time it is called. It would be a waste of time to determine orderId by calling reqIds(-1) and waiting for the asynchronous answer for each individual order.
• maintain a local nextRequestId() service you use for all reqIds and tickerIds. It provides a unique number that is different from any previous nextRequestId() and all possible nextOrderId() values for the current session. It is robust, prudent and safe to simply initialize nextRequestId() with nextValidId() + someLargeOffset where someLargeOffset > 4,320,000.

The short answer to your "will then all results be gone ?" question is “no”.

All ephemeral data (such as orderIds, reqIds, tickerIds) will be gone once your client disconnects or TWS/IBGW restart (since they are obsolete), but any account level information is retained within the IBKR infrastructure and can be retrieved by your client app as needed. Please refer to the TWS API guide, but among others, you can request:

• all orders that are open when your client connects
• the entire trade history for the account for a period of up to seven days (length of history selectable within TWS)
• all current positions in the account
• a long list of account related monetary details including cash positions, net liquidation values, and currently committed levels of margin

Hope this helps,

闯ü谤驳别苍

On Sat, Aug 5, 2023 at 03:32 AM, Arthur wrote:

I consider the theoretical limit of orders (used long type) as a design flaw from IB, because this is a point where something can break (here its highly unlikely i only agree on that). If you have dozens of line like that the software is crap. As i experienced developer i like to avoid such pitfalls, if possible. In this particular case i can't avoid it but have to keep it in mind.

By "will then all results be gone ?" i meant that the trading history of already executed orders will be gone or not. As a matter of fact currently i only have demo access to tws and my trading results always will be cleared if i start the application

On Sat, Aug 5, 2023 at 03:47 AM, Arthur wrote:

@闯ü谤驳别苍
If you start counting the RequestId as "orderId + 10_000_000" you will get the problem when the overlap occurs (if the session is not "that long" this problem doesnt occur, so i have to calculate what "that long" exactly means). So the safest approach would be to get the m_orderId incremented by tws server when calling "m_pClient->reqIds(-1);" and using the callback nextValidId(). Further i will avoid using the request() functions that need an ID to be properly executed as much as possible if there exists an alternative to it.