I wouldn't dismiss Gordon's comments outright, though. Granted, orderIds and requestIds serve very different purposes, and it is entirely legitimate if you have a market data subscription with requestId=10 as well as an order with orderId=10, but orderIds and requestIds are only independent until something goes wrong.

In that example, where would you route an ( id=10, .... ) callback? To the order manager that handles orderId=10 or the market data manager that handles requestId=10?

We follow the lead of the ApiController class that ships within the Java API and are very happy with this approach. We take the orderId value returned by

• and initialize a nextOrderId( orderId ) counter that monotonously increments for each call

• we also initialize a nextRequestId( orderId + 10_000_000 ) counter that also monotonously increments for each call

This approach assures that requestIds and orderIds are unique within each client session, that requestIds and orderIds never collide, and that all error callbacks can be associated with the request or order placement it relates to.

闯ü谤驳别苍

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.

• 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.

• 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 .

• 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 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,

闯ü谤驳别苍

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

@闯ü谤驳别苍
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.

开云体育

Not sure what needs to be tested here since the documentation at is crystal clear.? Also not clear why you are still trying to force the API into some kind of a "server increments orderIds"? mode. That is not how it works and you just need to accept that.

For your convenience, below and annotated copy of the first paragraph of

Perhaps the most important event received after successfully connecting to the TWS is the [...] As its name indicates, the nextValidId event provides the next valid identifier needed to place an order. This identifier is nothing more than the next number in the sequence. This means that if there is a single client application submitting orders to an account, it does not have to obtain a new valid identifier every time it needs to submit a new order. It is enough to increase the last value received from the nextValidId method by one. For example, if the valid identifier for your first API order is 1, the next valid identifier would be 2 and so on.

This is what you should do for now.

The situation may become a little more complicated as JG has suggested when orders can simultaneously be placed by multiple clients and TWS. Particularly if one of those clients is the "Master Client" (received order status for all orders placed by all clients) or "Client 0" (receives orders order status updates for all orders placed in TWS). The documentation is again crystal clear for that case:

However if there are multiple client applications connected to one account, it is necessary to use an order ID with new orders which is greater than all previous order IDs returned to the client application in openOrder or orderStatus callbacks.

1. The service keeps a private copy of the next valid orderId. Let's call that private variable nextOrderId
2. During connect(), initialize nextOrderId with the value you receive from
3. Whenever you receive an openOrder or orderStatus callback, extract orderId from the provided Order object and set nextOrderId = MAX( nextOrderId, orderId + 1 )
4. Whenever your business logic calls nextOrderId(), return nextOrderId++.

You obviously want to put some synchronization in place to make sure increment and set operations are atomic.

The final piece of documentation says:

You can always use the method in the event that your client application loses track of the sequence.

The documentation should really explain (at least briefly) why this kind of structured usage is necessary. Presumably it is for concurrency control and some reference, even to a general , might settle a skeptical and inquisitive developer's stomach a bit in my opinion.

Thanks for the very informative posts.I was looking into orderId recently and it solved my problem.One little comment about the following cited piece in the document.

However if there are multiple client applications connected to one account, it is necessary to use an order ID with new orders which is greater than all previous order IDs returned to the client application in openOrder or orderStatus callbacks.

I think it is inherently a race condition. Think about the situation that an orderStatus callback is en route from TWS to the master client while at the same time the master client is placing an order. In this event, there may be order id collision.

That is correct. There is a TWS API Global Setting that can eliminate the race condition for a large class of orders. It is called "Use negative numbers to bind automatic orders". When selected, automatic orders get bound to monotonously decreasing negative numbers and, therefore, will not interfere with the client's requirement of using monotonously increasing orderIds for new orders.

The remaining cases need to be eliminated by design. When several independent clients place orders in the same account, there is probably a need for coordination amongst them anyway (account margin management, avoiding opposing orders for the same instrument, ...)? so that one shared orderId assignment strategy could be used.

And the measure of last resort is monitoring the "Duplicate OrderID" error 103. The client could assign a new (higher) orderId and retry the placeOrder request.

闯ü谤驳别苍

That makes a lot of sense. Thank you.