How do you handle asynchronous nature of IB API?

Quote from dloyer:


The user interface is a simple web server built into the ATS to provide status information. I use a web browser to ask it what the current positions are, over all profit, profit per trade, active orders and state of each system for each symbol.
More...
Very cool. How did you do this ? Open source web server API ?
 
Quote from syswizard:

Very cool. How did you do this ? Open source web server API ?
More...

That would be the way do to it for a more complex web ui. Apache would be a good way to go.

For this, I just used something quick and dirty.

Just have a thread wait for connections to a socket. On each connection, spit out the html for a page, with the status info.

Point your browser to "localhost" and hit refresh for a update.

Provides visibility into what is going on without getting complicated.
 
Quote from Chronos.Phenomena:

especially in the higher than traditional frequency...

do you handle all the asynchronous logic in your application, or do you handle that in a API layer... i.e. for your application Interactive Brokers provides synchronous service?

[]..
More...

Trading is asynchronous in nature. I would most definitely never try to layer a synchronous layer on top, as you essentially lose all the benefits of being async in the first place.

Whether you call it business logic, trading engine or something else, the best answer is to decouple the components and deal with events as they actually happen.
 
Quote from Chronos.Phenomena:

So the common opinion is that syncing the IB API is not right way to go?
More...

Ya. Vikana's comment above is very much on the money.

You can almost think of an ATS as a finite state machine that processes events coming from the broker/exchange on one side and events coming from trading logic on the other side plus possibly timer events.

Synchronous doesn't make any sense. You need to learn to think asynchronously - it's not all that hard to do.
 
I kept reading this thread and thinking "synchronous?" but I'm not a programmer and wasn't sure what the question really was....

Event driven is one way to design the code so it can keep up with the market, there are other ways as well... Openquant has a programming environment that is all event driven, it's a great way to design the code since[afaik] all the possible events are known at the outset...
 
Quote from Eight:

I kept reading this thread and thinking "synchronous?" but I'm not a programmer and wasn't sure what the question really was....

Event driven is one way to design the code so it can keep up with the market, there are other ways as well... Openquant has a programming environment that is all event driven, it's a great way to design the code since[afaik] all the possible events are known at the outset...
More...

My ATS uses Java and the IB API.

I would suggest using a simple synchronous method if possible otherwise it can get complicated and harder to debug.

I broke the system down into a bunch of components that are event driven. All components and events are registered with the component manager, so that the component manager can orchestrate which components need to be executed in a synchronized / serialized way and which one can be run in parallel and in separate threads.

Simple example, if component A recieves events from B and C. B and C need to be run before A. B and C do not receive events from any other components so they can be run in parallel at the same time. B and C are executed in seperate threads, when they are done, events are sent to A and A is executed.

I also used an embedded Web server (Jetti) to run my UI. Highly recommended as you can access the ATS from anywhere.
 
I decided I'll try quickFix (Java implementation)... and try to change my existing code to use fix engine...

anyone knows of good java examples... ideally open source software with both IB and FIX interfaces?
 
Quote from Chronos.Phenomena:

I decided I'll try quickFix (Java implementation)... and try to change my existing code to use fix engine...

anyone knows of good java examples... ideally open source software with both IB and FIX interfaces?
More...

To use both IB and QuickFix in the same platform you need an abstraction layer/interface e.g. IBroker and an adapter - one for IB and one for QuickFix. This is what OpenQuant does but it's not open source and it's not Java. Also, RightEdge implements a similar architecture but again it's not open source and it's not Java. Furthermore, I don't know if RightEdge supports FIX. Ditto NinjaTrader.

There's example java code with the QuickFix/J distribution that is more than enough to get you started.

Also, have a look at Marketcetera which uses (at least last time I checked) QuickFix/J and is both open source and Java. However, I'm not sure if they also have an IB connection....i vaguely recall it was being worked on last time I checked.

Note, even if you implement FIX, every broker seems to implement it a little bit differently even if they are using the same FIX version number.

You'll also have to implement a separate mechanism for subscribing to market data. You don't want to be using FIX for that unless it is FIX/FAST. That's where IB is convenient - market data and order execution with the same API. If you're going to develop with FIX you'll also need a test server to test against.

FIX was a nice idea but it's not nearly the best solution. Sorry, I haven't read the whole thread so I don't know what your motivation for looking at FIX in the first place was. Going by the thread title though, the asynchronous situation doesn't go away by using FIX and to be honest it's a non-issue when using IB.

There's so much open source example Java code for IB I don't see what the problem is. In fact, there are so many ready-made platforms to choose from, unless you have a highly specialized need in your platform you might be better off using one of those.
 
You must log in or register to reply here.
Back
Top