开云体育

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

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.

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.

闯ü谤驳别苍

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.

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:

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.