A group of orders for the same instrument with parent/child relationship is ... a bracket order.

You probably could build an order construct without parent/child relationships for your scenario (using groups, and other features) but it will be challenging (or impossible) to protect your orders from the many things that can go really wrong (such over fills or order failures).

We can't design the exact solution for you, but here a couple paths you could explore. Both start with a traditional bracket order for entry, profit taking, stop loss, and other conditions. IBKR synchronizes order quantities based upon actual parent order fill or the entire set of orders gets cancelled. Nothing bad happens even if your client or TWS/IBGW crash or your network connection with IBKR gets disrupted for an extended period of time. The worst case is that the stop-loss order closes the position instead of reversing the position.

The first path to implementing position side reversal requires your client to be around and observe all order status callbacks. Once the parent order is filled

• The actual entry order fill quantity is known
• Quantities for all child orders are updated automatically
• The child orders are now unrelated other than that they share the same group. IBKR automatically wraps the child orders of the bracket into an OCA so that only one child order executes and the others get cancelled.
• Your client can now change the order quantity for the stop loss order without impacting the other orders in the group. In case the entry order filled completely, you'd simply double the stop loss order quantity. Upon partial fills you'd adjust based on the target reverse position.

The second path you could explore is a tree of bracket orders. You can have up to 20 open orders for the same instrument at any point in time. For this approach:

• You place the same bracket order the first path uses
• You attach a position reversal order to the stop loss order. It has the same same quantity and action (Buy or Sell) as the stop loss order.
• Should the stop loss order trigger, it closes the position but also activates the attached reversal order.

I have not tried this, so there may be caveats but I'd expect that the position reversal order quantity is updated automatically to the actual stop loss order quantity. This would effectively reverse the position to the actual fill quantity of the entry order (which may be less than the originally requested quantity).

You could extend this approach such that the reversal order has siblings in the second level bracket (profit taker, close position at end of day, others) or you could attach profit and loss orders to the reversal order for a third level.

Attached an example of a two-level bracket that IBKR accepted (though it has not executed since markers are closed):

• The main bracket has an entry parent order, a profit taker, a stop loss, and a close position at end of day order.
• The stop loss order is the parent for a position reversal market order. Other order types would work, too.

Hope this helps,

闯ü谤驳别苍

开云体育

Starting with v100, each message exchanged between client and server is prefixed with a 4-byte header containing the big-endian (network order) binary representation of the length of the message string.

Refer to the official IB API implementations for the exact steps to encode and decode the messages.

开云体育

I had to switch to 10.24 and have problems setting up a connection (didn't before).
Using V100Plus (I have to, I believe) I want to pass the client version.
I construct a UTF_8 string as indicated "API\0v100..177" and get the following response:

2023-09-09 19:48:31.634 [OI] ERROR [JTS-SocketListener-53] - Error parsing integer value from header. Reason: For input string: "API\0v100..177"
2023-09-09 19:48:31.634 [OI]WARN? [JTS-SocketListener-53] - API client version is missing.

What am I doing wrong?

David is correct. You should hide all low-level TWS API details in a Controller class.

The Java TWS API implementation ships with a sample ApiController class that could be a starting point for your own design. For each API request, it groups all corresponding callbacks into a small handler interface and transparently manages requestIds and most orderIds. Requests are called with handler objects instead of requestIds and the controller routes all corresponding callbacks to that handler.

Our implementation has a few improvements over that controller class. The most important ones are:

• A handler super-interface that all handler interfaces extend. The super interface provides an error callback method.
• An error router that routes any request related error callbacks to the handler for that request
• More comprehensive transparent orderID management. The sample Java ApiController already has basic transparent orderId management for single orders (your client/framework does not assign orderIds) but it lacks support for attached orders and orderId management when multiple API clients are connected to the same account.

Based upon such an ApiController you can then implement domain or task specific higher level controllers such as OrderController,PositionController, DataStreamController, ... that hide TWS API entirely from your trading and business logic or enable safe multi-threaded operation.

闯ü谤驳别苍

The reason I am asking, is because I want to modularize this Client Class to use for other strategies.

Hi,

In the sample application of TestCppClient the visibility for EWrapper's hooks is being stored as private.? EReaderOSSignal m_osSignal, EClientSocket * const m_pClient, etc. are all private and initialized in the initializer list of the TestCppClient. As we all know.

Now, I already have a strategy adhering to this visibility, but I find my classes to be not so cohesive. I have a class where I am doing a lot of the heavy lifting around preprocessing the data I need to make predictions, and then subsequently deciding how to trade signals from the model I have. My main loop is in my Client Class so I am constantly going back and forth b/w the Client Class and the Model's Class, which is eh, but I have functions in the Client Class specific to the Model's class and they should just be in the model's class, but when I put them in there I do not have the hook into m_pClient which is obviously crucial for order placing etc.

So, I am thinking, if I alter the visibility, I can create another derived class, i.e. MyModel() -> does heavy lifting for preprocessing and decision modeling, instead that inherits Client Class, make the visibility of EReaderOSSignal, EClientSocket objects, etc. protected in said Client Class and run my main loop from the derived MyModel() Class. I would put functions that were previously MyModelStrategyGetLong(), MyModelStrategyGetShort() in the Client Class, which were only in the Client Class b/c of visibility problems, into the appropriate, cohesive, MyModel() class. I would have to change the visibility for all the abstract virtual functions too that the TestCppClient has as private to protected or public as well.

1. Is this even allowed w/ the API's design?
2. If so, does anyone think this would be a good idea?

I am spit balling here... It just seems my program would be so much cleaner and cohesive, because really the Client Class is only used for getting things from IB. My strategy is really the focal point of making things happen. I really only need data, order submissions/fills, and account details from IB. The extensive preprocessing and analysis that comes after getting the data is not really cohesive to this Client Class and is really the main class IMO. It just seems silly to be doing all my analysis from this Client Class. We all want High Cohesion & Less Coupling no? I just don't seem to be getting that with this current design.

Thanks

Hi,

I am thinking of having 2 separate threads to handle order book and historical data monitoring. Main reason, I want to send aggressive orders when stops are hit rather than have passive orders on the book as soon as I enter a trade. Is this worth adding another thread over? Anyone else try this?

Thanks

Thanks I can try it out, yes I might be using same ticker for both - I presumed that both triggers separate callbacks so that could be ok...
Thanks again for taking time for this question...

On a separate note, can you please answer my question here if possible? I am waiting on that as well.
[email protected] | How do I know from the data coming to tickByTickAllLast whether its Buy (green) or Sell (red) indicated in the Time And Sale window of TWS

Yes , i read it.
I understood that I cannot use bracket - so I'm looking for a solution of what i CAN use.
what is the best approach to go from position 1 to -1 and vice-versa , with different quantities between parent and childs?

Then you can't use bracket orders. You read my reply, right?

what if i want to go from position 1 , to position -1 of the equity?
lets say im in position 0 , I put an order with quantity 1,tp 1, sl 1, and filled it, now im in position 1.
what if i want to go to position -1? i should put quantity -2, tp and sl still 1.
but as soon as i transmit - the tp and sl are going 2 also.
why is that ? (:

开云体育

Hello,

If you think about it, it's not that weird. From your example, you plan to take profit and also immediately go short at the same level (sell 3 on position of 1, ends up -2). Also, that short order would not have a protected stop. It's probably better to enter a separate order (with bracket) that opens a short postition.

The use of brackets is great though, or make it an oca order, even better with trail and what more. ;-)

Take care,
Raoul

That is how bracket orders are supposed to work. You can search our archive since we had lots of discussions about this before. One that comes to mind from a couple weeks ago can be found here.

When a bracket order is transmitted to IBKR, IBKR adjusts the requested quantities for all attached orders (profit, loss, others) to the quantity of the parent. And once the parent order starts actually filing, IBKR again adjusts all attached orders to the actual fill quantity of the parent order.

If you want a different behavior, you need to model your strategy with other order types or combinations of? hedge orders, pairs orders, OCA groups, order conditioning or other constructs.

闯ü谤驳别苍

So what error message do you get?

I assume your variable "ticker" has the same value for both calls, but the requestId for each TWS API request must be unique in the sense that no two outstanding requests or subscriptions shall have the same requestId.

A good practice is that you create a function "nextRequestId()" that provides a unique ID for each TWS API request you make.

闯ü谤驳别苍

How do i subscribe to?TickByTickLast and?TickByTickBidAsk both for the same Contract/Instrument?

If I do

reqTickByTickData(ticker, contract, "Last", 0, true);
reqTickByTickData(ticker, contract, "BidAsk", 0, true);

for 2 contracts, meaning 4 requests

only one of the 2 for each contract get subscribed...

I have started with TWS Apis few days back. Thanks to this group gave me answers to many initial question.

Still one thing is so unclear to me is that how do I know?from the data coming to tickByTickAllLast whether its Buy (green) or Sell (red) indicated in the Time And Sale window of TWS.

Do I have to consider/include/sync data from other events or there is something I can utilize from the tickAttribLast or?specialConditions from the?tickByTickAllLast callback?