开云体育

Looks like your triggers should work since, according to the IBKR documents, the order types you use are no native exchange order types. Maybe the next step would be to reach out to IBKR for clarification.

What kind of tick data did you use for your analysis? ? data is aggregated and can have a delay relative to your order executions. Or did you use that should be much closer to the order fill events.

And one last thought if you are up for another test. You should be able to force any order type to be simulated by IBKR when you place the order into a group. I am not sure whether a group with just one order would work, but you could add a dummy order (maybe with a time condition so that it can never execute) into a group with the order you are really interested in. Just for testing purpose to rule out that the order types are actually native (and that the documentation is incorrect).

闯ü谤驳别苍

Hello 闯ü谤驳别苍,

Thanks for the reply. What I mean by "they all default to what appears to be bid/ask for buy/sell", this is based off on logging the tick data of the price, and comparing when the order was executed. The Order object after I place the order confirms that the trigger method is the one I had selected, as well as the info displayed on the trader workstation terminal.

Based on the documentation for??it seems the trigger method should be working as I am dealing with Stop Limits?andTrailing stop limits,?which are both simulated on by IB.

Some more relevant info:

I have confirmed that the Order object reflects the trigger method I chose, as well as the information provided to me from the Trader Workstation Client.
I have tested this on both paper and real accounts.
I came to this conclusion based on logging tick data sent from the API and comparing it to when my order gets executed.

?

Appreciate your help on this.

Couple quick questions for clarification.

When you say "they all default to what appears to be bid/ask for buy/sell", does that mean the Order object you receive in the first callback after you place the order has a trigger method that is different from the one you had selected, or does that mean the actual triggers you experience look like they take place at ask/bid trigger points?

Also, have you verified that, for the instrument and exchange you are trading, the stop orders are indeed simulated by IBKR? The very last line in the documentation you point to says that trigger methods are ignored for stop-variant orders that execute natively at an exchange. You can determine whether your stop order is simulated through the "" documentation.

闯ü谤驳别苍

The short answer to the OP's question is, that the orderId field of the Order object is irrelevant for requests. The orderId is specified only by the "id" parameter of the? request. You can see this even in the code samples IBKR provides in the section of the API documentation, where the Order.orderId field is not explicitly set.

Once the order is accepted and placed, TWS/IBGW provides you with a fully initialized Order object through the callback. That object does not only have the orderId initialized (to the "id" value of ) but also fields such as permId and several others.

From an API design, this makes a lot of sense. The "id" parameter for each API request establishes a common identifier between your client and TWS/IBGW for all subsequent exchanges related to that request. TWSAPI cannot assume that the complex objects you provide have been initialized properly (they might just contain garbage) and TWS/IBGW needs to have a fail-safe way to inform your client in case the request needs to be rejected. Any error messages related to that request will be tagged with the "id" parameter your client specified in the request.

From an application design point of view, your client should never call TWS API requests directly. So you will find yourselves making a small layer between your client and TWSAPI that hides a lot of these details. For order placement, you might want to think about a few helper functions such as "placeMarketOrder", "placeLimitOrder", or "placeBracketOrder" that handle all Order object initialization details. These functions select orderIds and call accordingly. These calls could return the selected orderId (or orderIds) to the trading logic in your client.

闯ü谤驳别苍

I do not get a clear picture of what your client programs do exactly, Brendan, but I have the feeling that you need to go back to the drawing board. Gordon gave you some good pointers already, and there was a recent post titled "updateMktDepthL2 missing data points" you might want to take a look at (the second half that talks about L2 Market Book updates).

What concerns me is that, if I understand your comment correctly, your clients repeatedly call . They should not do that. Calling establishes a subscription that keeps sending you? callbacks until your client calls or disconnects from TWS/IBGW.

While the subscription is active, your client keeps two arrays (lists, maps, ...) of price-value pairs, one each for the buy side and sell side of the market book. Position (index) 0 of the buy side is the current "Bid" price/size while position 0 of the sell side is the "Ask". You would keep and update those two arrays as long as the client holds the subscription.

• Update( side, position, price, size)
• Delete( side, position )

• Insert( side, position, price, size)

Occasionally, IBKR decides that it makes more sense (for whatever reason) to just discard the entire market book and to start from scratch. That is when you receive the "RESET Market Book" instruction. And while [IMHO] that would have better been implemented as a fourth operation type for the updateMktDepth callback, designers opted for an . Upon receipt of that message, your client will simply discard the two arrays and rebuild the market book from the updateMktDepth callbacks that follow right away.

• Code 316 - Market depth data has been HALTED. Please re-subscribe.

• Code 2152 - List of exchanges for Level 2 subscription

updateMktDepth sends you streams of update instructions for individual positions, but it does not tell you when the "Update Market Book" transaction is complete and when your copy of the market book is consistent again ("transaction boundaries"). For instruments with very little activity or during the middle of the night, a market book update transaction might have needed only a single updateMktDepth callback. But for heavily traded instruments or when Bid/Ask change, the transaction may take 20 or so updateMktDepth callbacks. The second half of the "updateMktDepthL2 missing data points" post discusses approaches of how you can efficiently detect when your the market book copy is consistent again.

Hope this helps,
闯ü谤驳别苍

Yes I mean flushing local order book.

"Bank full":
By bank I mean same thing as you do I guess: the local map of entries indexed after the 'position' value.
The maximum number of entries ('position') in your local 'bank' of orders is defined in your request , can be far less on low activity instruments.
Otherwise said 'position' should not exceed your request "number of rows"-1 but also it may never reach it too.
Note:
In my implementation, if? 'position' >= nCountRowAsked, I process it as a relevant. This is limited in damages it can do in terms of memory alloc.? The complexity of what happens behind the scene make that I don't blame IB to overshoot 'position'.
Otherwise said don't do a hard memory alloc for your bank, C++ have plenty of very efficient map that are fast enough even if using dynamic alloc.

Case 317:
I no longer expect anything in-sync in term of 'position' with what will be sent trough IB call back. I expect IB to re-fill every entries ('position') without need to re-issue a request.
To exemplify in C++, in real life you may need a lock to handle sharing of resource: if (error==317) {deepthbank.erase (deepthbank.begin(),deepthbank.end());}?
This also can be diagnosed when call back run with 'operation' set as 'Insert' where position refer to an already existing one
(as in C++ the following condition should always be true on 'insert' (deepthbank.find(position) == deepthbank.end()) or equivalent using deepthbank.emplace(...).second==true),? otherwise it would means I hadn't received a 'removed' operation for it .

If you can experiment and report finding I would appreciate. Because a 317 is not something where I know a recipe to trigger it, and it should be a typical situation where this should happens if you don't .erase() your bank

Note:
I am not 100% sure that IB is fully compliant with it's own rules (like to always remove before insert)? so for cases like they forget to remove a position, (aside of 317) I default to overwrite the existing entry. Otherwise said I trust 'position'
and in case you wonder: I didn't even blip a warning as there is nothing I can do aside of de-subscribing and sending same request again, which doesn't seems a good idea in view of: delay to reprocess it, the expected high oddity of this case and the expected efficiency of this.

Not sure I catch what you seems to imply by differentiating Paper vs Real. I don't think that Paper is less well serving LII than Real.

Some thoughts:
What do you call platform ? TWS or Gateway ?
Are you looking at LII on TWS simultaneously ?
Aside of telco contention:If TWS consider increasing the amount of RAM allocated to TWS

Suggestion too look at the "halt" status, I never seen it moving fast in real time, but it may happens that the market itself is in a stall position.
I also would wonder what is the impact of using Smart mode versus specific venue like the primary exchange or a major one.
If one venue stall maybe it stall the IB deliver process. (unlikely in my deep perception as IB should deliver RT what they have available)

Otherwise said, what you call a halt for split second need to be considered against another reference, like a Bloomberg terminal or that class of platform
Because there are real reason why market may freeze waiting for something that trigger a big move (as in: cause or consequence ?)

Nothing easy popup to my mind.
50 is quit a number of users and you most probably will face a wall with the pacing violation and limitations if you use a single account
There is a concept of ClienId that allow to a certain extent to track what a proxy you have to design could do but you would have to de-consolidate a lot of trading information your self.
IB mind set is even exactly in the opposite direction, allowing a single trader to handle in single action a consolidation of accounts (customer).

So I would suggest you call IBKR direct, IBKR have cost of operation for their advanced service and here this is to deal with users that are not paying for the service in a foreseeable future.
So supporting many user for free is not really rational and they probably never considered this schooling usage in their API, hence reason to contact them and see what they can suggest.