开云体育

Hi Francois,

Did you find a solution for your issue? I'm facing something similar but do not have a good idea so far.?

Actually, it's not a bad idea to have a separate thread for each of those 10 securities. This is how I do it. It really depends on how you want to structure your software. I have one "central" facility that communicates with the IB Gateway to submit orders or receive status updates in a threadsafe manner, and each of my 10 threads access data stored on this facility, as well as register condition variables that get triggered whenever an event it's waiting on occurs. You could obviously implement all this using one thread if you want, but I like being able to think of and implement strategy execution for each security this way. It just feels more natural and intuitive to me.

Well said, Nick.

Our approach is not so much driven by the size of the environment, though, and a lot of what we do is actually really small. It is rather the fact that my background is in system architecture. Just like everything looks like a nail to a hammer, system architects look for opportunities for "abstractions" and "the separation of concerns". That generally results in more modular, stable, and reusable designs by hiding unnecessary details and establishing well defined and long-living interfaces. It can be done in any programming language and is not limited to Java.

The layer of code we use between our applications and the TWS API has developed over time piece-by-piece as we learned more about how details can properly be abstracted and hidden. That usually happens when I find myself writing the same kind of code or boiler plate for the third time.

Interestingly, our Java interfaces are now structured very similar to those of the ib_insync Python framework. Ewald de Wit did an outstanding job "separating the API concerns" and has created nicely abstracted interfaces so that applications don't need to know "too much" about TWS API. The ib_insync interface definitions could very well be used to guide developments in other languages.

闯ü谤驳别苍

On Sun, May 1, 2022 at 07:23 PM, Nick wrote:

It is interesting to observe the difference in approach based on different environments.

I focus on small environments, these days just for myself, so having everything in a single exe works best for me. I can create everything needed for a strategy and put it in one self-contained program. Simple to deploy and has a minimum of moving parts.

Alternatively Jurgen is in a larger environment and has needs beyond just running a strategy, so his approach works for his situation.

There's no one size fits all. You have to understand what the api can provide, combine that with what you need and then create an approach that works for you.

We do focus on the detail aspects of the TWS API in this group and application level topics are generally out of scope. But I am sure there are current and future group members that need a little help along the lines of your question.

You should start with the if you have not done so yet. Work through it from to to bottom so that you get a feel for all aspects. It is fine to jump over sections that are not immediately relevant to you.

Since you are familiar with Java, take a look at the source of the ApiController class in the com.ib.controller package. It is a good example of how you can hide a lot of the necessary API details and idiosyncrasies (such as request IDs) from your application logic. It should help you create an interface to TWS API that works for your application architecture. And there is nothing wrong with a multi-threaded WebApp mindset consisting of services and controllers.

The TWS API is inherently asynchronous and as such a great fit for a micro-service/multi-threaded/reactive application stack (in any language, not just Java). We hide TWS API details behind Java CompletableFutures, Java Flows, and Java Streams, and all of our applications do use several to many threads for executing real time and order processing tasks.

闯ü谤驳别苍

No, that's not the way to go.

All data is coming from a single socket so no need for extra threads.

Each market data request has a unique id that you supply. When a quote arrives you look at the id so you know what symbol it is, then process that symbol.

Same idea for orders and pretty much everything else - they all have id's so you know what the arriving data is.

You make your requests and respond to replies as they come in. The general idea isn't too hard.

The api has gotcha's that everyone encounters. You develop your app one step at a time, verifying that each step is doing what you need.

Thanks everyone for putting this community together. It is really helpful and for the last hour and half searching I did find valuable information. I am however pretty new to exploring IKBR API. What I am trying to understand is where to start! there is so much information and my head is spinning, TBH. I have Java background and have been building Web applications for more than 10 years, so its natural for me to look at building my trading bot in Java. It has to be a threaded application but does not have to be an web app.?

Can some one please shed some light on where to start? If I am tracking 10 securities and looking for a breakout how would my bot look like? will I have a threaded application running that captures realtime bars determine price point movements and volume and enter trade with a bracket order if the condition is met. Very basic to start with. Is my assumption correct that I have to start with multithreaded application with 10 threads monitoring that tickers??
I am a little scatterbrained right now and would love for someone to please put me in the right direction to start building something I described above. Thanks in advance.?

I hope you are feeling better now, Rob.

Drew asked about REL types in Bracket Orders. Does anyone have an experience to share? I don't know about REL orders, but MKT orders are not accepted as parents for Bracket Orders.

Coming back to paper trading for a brief moment. One thing I always have to remind myself of is that "paper trading" is just a model of reality and that it can never behave exactly like reality. This old wisdom from my time in systems architecture applies to paper trading (generally and for IBKR): Models are always wrong but sometimes useful.

How wrong they are depends on the features used but also on the questions you ask of the model. We get great results with the IBKR paper trading account, but then we use straight forward order constructs against extremely liquid ES front month futures. Results are virtually identical when we run identical algorithms in paper and live accounts in parallel. But then our algorithms have been designed to tolerate uncertainty around entry and exit since even in live trading, order fill behavior can vary considerably depending on market conditions.

While not exactly within our focus on the TWS API, I can see value in a (separate) topic on experiences with the limits of the IBKR paper account.

闯ü谤驳别苍

In the Python ?placeOrder(self, orderId:OrderId , contract:Contract, order:Order), the "order" argument already contains an instance variable "". So you are in fact sending two orderIds to placeOrder(). Anybody knows why? Is the "orderId" member variable in "order" even used?

In IB's for bracket orders, the parent's order type is set to "LMT". I'm wondering if it would still work if I set it to "REL" (with still a set limit)?? I would try testing this in paper trading if I could, but REL orders are not supported in paper trading.

You are looking for a bracket order.? See https://www.interactivebrokers.com/en/index.php?f=583

Hi,

I am pretty new here so firstly hello to everyone!
Basically, I am trader used basic transaction before however now I want to try something more complicated.
I want, for example, BUY stock and set TRAIL if touched the price + to have stop loss (if the price don't hit first TRAIL) when touched changed into bracket order.
I tried with adjustable but not successfully. Is it possible to do it easily? Or I need to listen prices on side of my program and update just stop loss price?
Any ideas highly appreciate it.?
Regards,

For OPEN orders the TWS shows the order system submit time (and modify time).
Is there a way to retrieve the submit time of an open order through the API?

There is nothing wrong with using the the socket level, Marc. You can still use "+PACEAPI" since it is a connection message option.

Traditionally, client applications had to implement their own request pacing, but using "+PACEAPI" is the better approach for new developments since it was introduced in TWS 974.

One advantage of "+PACEAPI" is, that you may be able to achieve rates of more than 50 requests/second when you let TWS do the pacing for you (e.g. when you don't throttle your requests at 50 per second). Traditionally, IBKR has relaxed restrictions over time that TWS would let you take advantage of right away.

We have a little "request flood tester" that fires requests (with sequentially increasing conds) at the highest possible speed. Without "+PACEAPI", we obviously get error 100 "Max rate of messages per second has been exceeded:max=50 rec=912" immediately. But with "+PACEAPI" enabled:

• TWS allows us to fire 10,000 requests in 290ms. That's a rate of more than 34,000 requests per second.
• The 10,000 responses from TWS arrive within 100 seconds. A rate of 100 per second

We get practically the same results with stable TWS 981.3l and latest TWS 10.15.1e

闯ü谤驳别苍

According to the ContractDetaills object, VIX index "trading hours" on work days are (US/Central time):

• 02:15 to 08:15
• 08:30 to 16:00

We don't do options, but I just grabbed the ContractDetails for object for "VIX 220518C00025000". Trading hours are (US/Central time)

• 19:15 to 08:15 next day (Sun through Thu)
• 08:15 to 15:15 (Mon through Fri)

So there are three hours in the late afternoon where you'd get no market data.

Hope this helps,

闯ü谤驳别苍

Cool, thanks for the replies!

My real account seems unaffected so that works for now.

Best,
Dave

TWS says scheduled maintenance is still going on. You might want to try again tomorrow afternoon when things are back to normal.