Interactive Brokers Integration

[Brandon Ogle]

I have heavily modified Zipline to support futures contracts (which I will happily share in the next couple weeks when it becomes a little more matured), so I want to replicate Quantopian's IB integration in my code. Namely sending off orders and reconciling values between IB and Zipline. So I am curious what is the best route for doing so;

1) Does anyone have a python wrapper to the IB API? IbPy seems out of date from what I can tell so I am fishing to see if there is anything else out there.

2) where are the best places to implement the communication between the two. I will need to send orders, reconcile filled orders, reconcile account values, etc.

[Jason Wirth]

+1 for this. 

--
You received this message because you are subscribed to the Google Groups "Zipline Python Opensource Backtester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zipline+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

--
Jason Wirth
    213.675.5294
    wirth...@gmail.com

[Jason Rennie]

Both of these are on my list of things to do.

I think the thing with IBpy is that it is an emulation of Java which means that the reference Java implementation has its implementation emulated. So even though its a bit old, it should still work.. I've found the Google+ and twitter of the guy who wrote it a few days ago. He also wrote a thing called profitpy - back in 2008

I did see another IB python wrapper but when I found IBpy, and realised how it worked, I figured it probably couldnt be beat.. 

I thought zeroMQ looked interesting for messaging. pyzmq package.

I was planning to tightly bind my application with IBpy to avoid having to implement a messaging layer.

An alternative is to use the FIX protocol and there's several interfaces to go that route. I think you run the IB gateway if you want to interface using FIX.

FIX doesnt allow us to read streaming prices AFAIK - its just for sending orders I think.

I thought this looked promising.. http://www.quickfixengine.org/

There are a bunch of paid FIX products out there as well - not sure what extra you get for the money though..

I'd be happy to collaborate if our plans coincide enough.

-Jason

--

[Brandon Ogle]

I think I am going to move forward with IbPy, while its implementation is fairly messy I don't think there is an advantage to FIX at this point. It seems to me that most brokers have proprietary extensions to the protocol for sending/receiving messages that I would have to reimplement the messaging anyways if I ever moved to a different broker. Over the next week or two I am going to work on wrapping all the socket calls in a more pythonic syntax, and hopefully return the callback messages (for reconciling zipline with IB).

For example, here is a more concise working prototype I have for generating an order in IB 

client = IBClient()

sleep(3)

ord_id = np.random.randint(200, 300)

client.order('GOOG', 100, ord_id)

I think in my final version I will just have blotter send the actual order object to my IB method so that it can access contract type (stock or future) and also determine the order type (MKT, LMT, STOP, STOPLIMIT, etc), and pass the id. Ultimately I think where I will need the most help, is in determining where, when and how to reconcile all of these values, and which ESocket methods ultimately request those values. Then I will create methods for all the requests, have my subclass of EWrapper catch that value and store it in a field that can be returned in the initial method call.

So conceptually, something like this:

class Wrapper(EWrapper):

    account_value = None

    finished_request = False

    def updateAccountValue(self, key, value, currency, accountName):

        self.account_value = (key, value, currency)

        self.finished_request = True

class Listener(object):

    def __init__(self,name=None):

        self.name = name

    def method(self,sender,event,msg=None):

        print "[{0}] got event {1} with message {2}".format(self.name,event,msg)

class IBClient(Listener):

    def __init__(self, name=None):

            self.host = 'localhost'

            self.port = 7496

            self.clientId = np.random.randint(0,1000)

            self.wrapper = Wrapper()

            self.connection = EClientSocket(self.wrapper)

            self.wrapper.register(self.method, events='execution')

            self.connect = self.connection.eConnect(self.host, self.port, self.clientId)

    def wait_for_request(self):

         while self.wrapper.finished_request is False:

               sleep(.5)

    def get_account(self, acct):

        self.connection.reqAccountUpdates(True, acct)

        wait_for_request()

        return self.wrapper.account_value

    

client = IBClient()

account = client.get_account(acct# here)

[Michael S]

Brandon,
 I was looking at IB recently.  I am not sure if I would wait for the requests.  I was thinking of setting the connection to something like this.

        self.data_handler = []

        self.connection = ib.opt.ibConnection('localhost', port, client_id)

        self.connection.registerAll(self.watcher)

    def watcher(self, msg):

        now = datetime.datetime.now()

        if self.debug:

            print(msg)

        self.data_handler.append((now, msg))

[Brandon Ogle]

I think the only con in waiting for the requests is latency, which I am not to concerned with. By synchronizing the API I like that I can catch errors and handle them in some way, if I were to go the asynchronous route I think I would want to rethink my handler functions to facilitate the reconcillation between IB & zipline, which would highly limit it to specific actions. I don’t have much experience with Asynchronous protocols, so perhaps I am overlooking some benefits.. What do you think?

Best, 

Brandon

[Fabian Braennstroem]

I saw some lines on quantstart
http://www.quantstart.com/articles/Using-Python-IBPy-and-the-Interactive-Brokers-API-to-Automate-Trades
Maybe this is of interest for you... though I think you are already a step ahead.

Best Regards
Fabian

--

[Michael S]

I guess my concern if you sleep here and don't get a response on one piece,  everything will break.

[Brandon Ogle]

Well my current design is 

def hold_for_request(self):

        self.timed_out = False

        start = dt.datetime.now()

        inc_secs = .2

        while not self.wrapper.isDone:

            end = dt.datetime.now()

            if (start - end) > dt.timedelta(seconds=5):

                self.timed_out = True

                return

            sleep(inc_secs)

        self.wrapper.isDone = False

def function()

    call ESocketMethod

    if self.sync is True:
        self.hold_for_request()

        if self.timed_out = True:

            return 'Request Failed'

        return self.wrapper.request

Therefore if you make a request and receive nothing after five seconds, it gives up on the response and simply outputs 'Request Failed'. This way in your code you can make the request and if it times out you can handle it how you deem fit. Also I should mention that I am designing this in such a way that waiting for the requests is completely optional, over in the callbacks side I currently just have them asynchronously emitting messages as they come, but I intend to extend this to stuff the messages into a dictionary that you can key against instead of waiting for the request.

[John Jay Buchtel]

Brandon,

I am trying to connect the Quantopian zipline to IB.

Do you by chance have the code  that will help me do this, or get me started on this properly? 

If so it would be greatly appreciated! Please let me know.

Thank you,

John Jay