开云体育

Well, your characterization is not correct. The id parameter for callbacks always identifies the message the error relates to:

• If the error relates to a request, id will have the numerical value of that requestId
• If the error relates to an order, id will have the numerical value of the orderId

• if the error is not directly related to a message your client sent (such as global errors), id will have a value of -1.

Between requestIds and orderIds, numeric values for orderIds have to follow strict requirements possibly for very long periods of time (as in forever or until you reset the sequence in TWS/IBGW) while requestIds are ephemeral and can be reused as soon as the last request they have been used for is complete.

Therefore, you simple design a numeric assignment strategy for your client that makes sure that, at any point in time, the id value of an error callback can be uniquely related to a recent request or an order. There are may ways you can do that, but a simple approach, that worked well for us for years is this:

• When your client connects, it receives the numeric value for the next valid orderId through the nextValidId() callback. For clientIds that have never been used before, nextValidId will return a value of 1
• Memorize that value as the nextOrderId and increment it every time you need to assign an orderId
• Similarly, create a nextRequestId that you use to assign unique ids for your requests from. Assign the initial value with a large offset from nextValidId(), such as, nextRequestId = nextOrderId + 10_000_000

Your error callback can uniquely be related to requests or order.

闯ü谤驳别苍