Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix register-contract/lookup-contract #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cbilson
Copy link
Owner

@cbilson cbilson commented Jan 4, 2013

These functions won't consider {:symbol "AAPL" :exchange "ISLAND"} and {:symbol "AAPL" :exchange "ISLAND" :currency "USD"} as the same security. If I request ticks for both, ib-re-actor will have two entries in @id->contract and make two requests. I am not sure if Interactive Brokers will send the same ticks for both ticker ids (maybe it will ignore one of them?), but even if it did, this is kind of dumb.

Not sure if it would be better to go back to having the client track their own ticker-ids (that was how this used to work, and it was kind of a pain,) or forge onward and implement full-blown tracking of contract details.

The following is just kind of brain-stormy. If no one cares, I will probably try to do this sometime in the future.

I think "full-blown" tracking of contract details would involve:

  • When we see a contract, like inside of request-market-data, we already call register-contract to see if we already have a ticker-id to use for this. Inside of register-contract, I think it should look for a match with a comparison function instead of using the contract as a key to lookup the ticker id. I think the comparison function could be pretty simple: if both have some subset of symbol, local-symbol, currency, exchange, contract-id, ..., then use those to compare and it's the same security if you have a match.
  • When we see a new contract, kick off a request to get contract details for it. When we get a response, update our copy of the contract details.
  • Since contract details have some time-specific data in them (trading/liquid hours, margin reqs., etc,) we need to refresh them from time to time. Maybe we could use the trading hours as some kind of a signal to refresh?

Writing this out has made me realize it's probably too much stuff for a library that is supposed to be a wrapper. On the other hand I hate to have to implement this every time I build an application that uses ib-re-actor.

I have been considering starting a new project to build a host for trading algorithms. I have a couple of poorly designed applications I could replace if I did this, and it would be easier to maintain than several applications. The host could manage security reference data (as mentioned above) and keep that stuff out of the wrapper library. It would also include facilities to schedule things like activating trading programs at certain times and other market schedule driven processing.

Is anyone interested in pursuing a separate project (and revert to request-id based calls inside ib-re-actor) or should we fix the security reference data inside ib-re-actor?

@ghost ghost assigned cbilson Jan 4, 2013
@cbilson
Copy link
Owner Author

cbilson commented Jan 4, 2013

I've gone ahead and just removed the offending functionality. Instead of getting a contract back in the following message types, the message will contain a request-id:

  • :tick
  • :update-market-depth
  • :update-market-depth-level-2

In addition, when calling request-market-data, in addition to a contract, you will need to supply a ticker-id, which you can get from get-ticker-id, which just uses an atom to maintain an incrementing id.

I've also updated the one affected synchronous function, so you can see an example if you want.

Please give this a try if you are worried about this impacting your downstream applications and let me know if there are any problems. If there are no issues, I will probably merge this into master in a couple of days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant