|
When calling reqSecDefOptParams() on ES futures, it's possible to see it inexplicably hang.
Given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
Where the conId is for ESU0, the call will hang, however given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 383974339})
Where the conId is for ESZ0, the call returns data as expected.
I'm using ib_insync, but this doesn't appear to be a bug with that library
Additionally when calling it for ESZ0, only some expiries are not being returned. I can see dates in the TWS option chain that do not show up in the API response.
Has anyone played with this before?
I know about the reqContractDetails() approach, but that is good for 1 option chain call seemingly per minute. For ES it returns 11000 rows
|
Forgot to mention the only other important variable that I can see: passing "localSymbol" (i.e. ESU0) rather "symbol" (ES) causes it to always return an empty response, so looks like .symbol is correct.
|
For both calls:
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339))
Seeing normal msg response in the sense of a series of 75 msg, followed by a 76.? The Sec Def Opt Param and Sec Def Opt Param End msgs.? No obvious difference in the data returned with regard to formatting.
Note I am not utilizing the Python lib, but invoking the API via a different library.? So from the API req/rsp msg layer seems ok on the surface as of time of writing.
When calling reqSecDefOptParams() on ES futures, it's possible to see it inexplicably hang.
Given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
Where the conId is for ESU0, the call will hang, however given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 383974339})
Where the conId is for ESZ0, the call returns data as expected.
I'm using ib_insync, but this doesn't appear to be a bug with that library
Additionally when calling it for ESZ0, only some expiries are not being returned. I can see dates in the TWS option chain that do not show up in the API response.
Has anyone played with this before?
I know about the reqContractDetails() approach, but that is good for 1 option chain call seemingly per minute. For ES it returns 11000 rows
|
Thanks for this. What version of TWS do you use? Also, is it possible for you to show the exact send/received text in your environment?
For example replicating your first call, I receive this:
DEBUG:__main__:get_option_params(): reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
DEBUG:ib_insync.client:>>> 78,510,ES,GLOBEX,FUT,371749798
DEBUG:ib_insync.client:chunk:[b'\x00\x00\x00>4\x002\x00510\x00322\x00Error processing request. no derivatives returned\x00']
DEBUG:ib_insync.client:<<< 4,2,510,322,Error processing request. no derivatives returned
Using localSymbol instead:
DEBUG:__main__:get_option_params(): reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ESU0', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
DEBUG:ib_insync.client:>>> 78,510,ESU0,GLOBEX,FUT,371749798
DEBUG:ib_insync.client:chunk:[b'\x00\x00\x00\x0776\x00510\x00']
DEBUG:ib_insync.client:<<< 76,510
DEBUG:__main__:get_option_params(): reSecDefOptParams() empty result
|
Trying to be careful to use specific sym and con-id combo that you are interested in.
Using ES - 371749798? I see responses.?
?- See
Using ESU0 - 371749798 | No returned data, but I do get an expected single SecDefOptEND msg. ?- See
From a pure messaging perspective all seems well.? No hangs or anything.
Thanks for this. What version of TWS do you use? Also, is it possible for you to show the exact send/received text in your environment?
For example replicating your first call, I receive this:
DEBUG:__main__:get_option_params(): reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
DEBUG:ib_insync.client:>>> 78,510,ES,GLOBEX,FUT,371749798
DEBUG:ib_insync.client:chunk:[b'\x00\x00\x00>4\x002\x00510\x00322\x00Error processing request. no derivatives returned\x00']
DEBUG:ib_insync.client:<<< 4,2,510,322,Error processing request. no derivatives returned
Using localSymbol instead:
DEBUG:__main__:get_option_params(): reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ESU0', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
DEBUG:ib_insync.client:>>> 78,510,ESU0,GLOBEX,FUT,371749798
DEBUG:ib_insync.client:chunk:[b'\x00\x00\x00\x0776\x00510\x00']
DEBUG:ib_insync.client:<<< 76,510
DEBUG:__main__:get_option_params(): reSecDefOptParams() empty result
|
ray what library is this?
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339)) does not?look like python is it lisp? and if so how do ?you access twsapi via lisp?
For both calls:
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339))
Seeing normal msg response in the sense of a series of 75 msg, followed by a 76.? The Sec Def Opt Param and Sec Def Opt Param End msgs.? No obvious difference in the data returned with regard to formatting.
Note I am not utilizing the Python lib, but invoking the API via a different library.? So from the API req/rsp msg layer seems ok on the surface as of time of writing.
When calling reqSecDefOptParams() on ES futures, it's possible to see it inexplicably hang.
Given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
Where the conId is for ESU0, the call will hang, however given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 383974339})
Where the conId is for ESZ0, the call returns data as expected.
I'm using ib_insync, but this doesn't appear to be a bug with that library
Additionally when calling it for ESZ0, only some expiries are not being returned. I can see dates in the TWS option chain that do not show up in the API response.
Has anyone played with this before?
I know about the reqContractDetails() approach, but that is good for 1 option chain call seemingly per minute. For ES it returns 11000 rows
|
I apologize ahead of time for the blurb.? One time happening out of respect for the list.? But since someone asked ...
This is the Interactive Brokers Reactive Engine, aka IBKRE.?
Found here:
It has a couple of examples here:
There is a brief, rough draft "tutorial" (with a bunch of typos), on how to use IBKRE.? Check it out!! : Scroll down and at least read the description of the first code example.
Here is another example for some code invoking market data, getting con ids, option chains via Sec Def Parameters, etc found here:
Given a list of stocks and exchanges, get the con-id for each stock, for each stock/exchange combo get the possible strikes (the option chains via the infamous Sec Def Params API), and finally to verify the option chains invokes contract details for filter the possible option chain from Sef Def Params to the actual valid available options. Oh and all while this is going on it is also getting market data for open, close, last, volume, implied volatilities or whatever.
This is A LOT of API calls.? The key point of this example is to show how IBKRE is performing all of this stuff concurrently, all at the same time.? It will run through 100s even 1000s of option chains in a reasonable period of time (constrained by IBK's API rate limits).? CAVEAT: This example has an "api rate limiter" in the code that has a bug as I was in the middle of changing to another approach.?
About Racket:
While it is Lisp, it is in Racket (a variant) and not Common Lisp or Scheme.? Frankly it is probably one of the best languages out there.? It has been around for a long time and has a very stable core of maintainers, many of them professors, grad students, academics, hardcore developers.? One of the core leaders won the Turing Award from CS (the Nobel Prize of CS) a few years back partly for Racket. It is very stable, maintained and active.? It is not a one man fly-by-night hobby language by any means.
You can read all about Racket here:
Racket Highlights:
- AMAZINGLY well documented. See - Native compilation like C or Java granting decent performance.
- High level like Python or Ruby. - Cross platform.? Runs on Mac, Linux, Windows, ARM (Raspberry Pi). - Pretty decent GUI set for graphical programs that runs cross platform as well.? i.e. Your graphics gui programs, plots etc will run on Mac, Linux and Windows. - Bug reports are addressed very quickly with pretty much immediate turn around. - Robust plotting library for graphs and charts. - Batteries included core of libraries found here:
About the IBKRE Library.
My first iteration took a standard approach to concurrency using async code, futures, thread queues, CML constructs, condition variables etc.? And while it worked OK I found I was spending too much time dealing with machinery and not enough time with my stock trading logic. The IBKRE is a Actor based approach that personally I think has been the perfect fit for working with the IBK API and is MUCH easier to use.
Library Caveats:
- Alpha / Early Beta code. - Some aspects of the library have not seen widespread code use so may have an issue here or there. - I have deliberately NOT added any of the code for order placement at this time.? (Soon)? I did not want someone placing orders and having it go wrong for them on my karma balance until things were shaken down.
I do use it all the time and someone can expect a quick fix for any bug etc.
ray what library is this?
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339)) does not?look like python is it lisp? and if so how do ?you access twsapi via lisp?
For both calls:
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339))
Seeing normal msg response in the sense of a series of 75 msg, followed by a 76.? The Sec Def Opt Param and Sec Def Opt Param End msgs.? No obvious difference in the data returned with regard to formatting.
Note I am not utilizing the Python lib, but invoking the API via a different library.? So from the API req/rsp msg layer seems ok on the surface as of time of writing.
When calling reqSecDefOptParams() on ES futures, it's possible to see it inexplicably hang.
Given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
Where the conId is for ESU0, the call will hang, however given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 383974339})
Where the conId is for ESZ0, the call returns data as expected.
I'm using ib_insync, but this doesn't appear to be a bug with that library
Additionally when calling it for ESZ0, only some expiries are not being returned. I can see dates in the TWS option chain that do not show up in the API response.
Has anyone played with this before?
I know about the reqContractDetails() approach, but that is good for 1 option chain call seemingly per minute. For ES it returns 11000 rows
|
thanks?ray will start using immediately? i was wondering if you have ibkr tws v 972 windows or mac available? for download?if so do you mind sharing it please
I apologize ahead of time for the blurb.? One time happening out of respect for the list.? But since someone asked ...
This is the Interactive Brokers Reactive Engine, aka IBKRE.?
Found here:
It has a couple of examples here:
There is a brief, rough draft "tutorial" (with a bunch of typos), on how to use IBKRE.? Check it out!! : Scroll down and at least read the description of the first code example.
Here is another example for some code invoking market data, getting con ids, option chains via Sec Def Parameters, etc found here:
Given a list of stocks and exchanges, get the con-id for each stock, for each stock/exchange combo get the possible strikes (the option chains via the infamous Sec Def Params API), and finally to verify the option chains invokes contract details for filter the possible option chain from Sef Def Params to the actual valid available options. Oh and all while this is going on it is also getting market data for open, close, last, volume, implied volatilities or whatever.
This is A LOT of API calls.? The key point of this example is to show how IBKRE is performing all of this stuff concurrently, all at the same time.? It will run through 100s even 1000s of option chains in a reasonable period of time (constrained by IBK's API rate limits).? CAVEAT: This example has an "api rate limiter" in the code that has a bug as I was in the middle of changing to another approach.?
About Racket:
While it is Lisp, it is in Racket (a variant) and not Common Lisp or Scheme.? Frankly it is probably one of the best languages out there.? It has been around for a long time and has a very stable core of maintainers, many of them professors, grad students, academics, hardcore developers.? One of the core leaders won the Turing Award from CS (the Nobel Prize of CS) a few years back partly for Racket. It is very stable, maintained and active.? It is not a one man fly-by-night hobby language by any means.
You can read all about Racket here:
Racket Highlights:
- AMAZINGLY well documented. See - Native compilation like C or Java granting decent performance.
- High level like Python or Ruby. - Cross platform.? Runs on Mac, Linux, Windows, ARM (Raspberry Pi). - Pretty decent GUI set for graphical programs that runs cross platform as well.? i.e. Your graphics gui programs, plots etc will run on Mac, Linux and Windows. - Bug reports are addressed very quickly with pretty much immediate turn around. - Robust plotting library for graphs and charts. - Batteries included core of libraries found here:
About the IBKRE Library.
My first iteration took a standard approach to concurrency using async code, futures, thread queues, CML constructs, condition variables etc.? And while it worked OK I found I was spending too much time dealing with machinery and not enough time with my stock trading logic. The IBKRE is a Actor based approach that personally I think has been the perfect fit for working with the IBK API and is MUCH easier to use.
Library Caveats:
- Alpha / Early Beta code. - Some aspects of the library have not seen widespread code use so may have an issue here or there. - I have deliberately NOT added any of the code for order placement at this time.? (Soon)? I did not want someone placing orders and having it go wrong for them on my karma balance until things were shaken down.
I do use it all the time and someone can expect a quick fix for any bug etc.
ray what library is this?
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339)) does not?look like python is it lisp? and if so how do ?you access twsapi via lisp?
For both calls:
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339))
Seeing normal msg response in the sense of a series of 75 msg, followed by a 76.? The Sec Def Opt Param and Sec Def Opt Param End msgs.? No obvious difference in the data returned with regard to formatting.
Note I am not utilizing the Python lib, but invoking the API via a different library.? So from the API req/rsp msg layer seems ok on the surface as of time of writing.
When calling reqSecDefOptParams() on ES futures, it's possible to see it inexplicably hang.
Given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
Where the conId is for ESU0, the call will hang, however given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 383974339})
Where the conId is for ESZ0, the call returns data as expected.
I'm using ib_insync, but this doesn't appear to be a bug with that library
Additionally when calling it for ESZ0, only some expiries are not being returned. I can see dates in the TWS option chain that do not show up in the API response.
Has anyone played with this before?
I know about the reqContractDetails() approach, but that is good for 1 option chain call seemingly per minute. For ES it returns 11000 rows
|
ray is a simple?racket getting started guide for python devs and no knowledge of ?lisp ?
I apologize ahead of time for the blurb.? One time happening out of respect for the list.? But since someone asked ...
This is the Interactive Brokers Reactive Engine, aka IBKRE.?
Found here:
It has a couple of examples here:
There is a brief, rough draft "tutorial" (with a bunch of typos), on how to use IBKRE.? Check it out!! : Scroll down and at least read the description of the first code example.
Here is another example for some code invoking market data, getting con ids, option chains via Sec Def Parameters, etc found here:
Given a list of stocks and exchanges, get the con-id for each stock, for each stock/exchange combo get the possible strikes (the option chains via the infamous Sec Def Params API), and finally to verify the option chains invokes contract details for filter the possible option chain from Sef Def Params to the actual valid available options. Oh and all while this is going on it is also getting market data for open, close, last, volume, implied volatilities or whatever.
This is A LOT of API calls.? The key point of this example is to show how IBKRE is performing all of this stuff concurrently, all at the same time.? It will run through 100s even 1000s of option chains in a reasonable period of time (constrained by IBK's API rate limits).? CAVEAT: This example has an "api rate limiter" in the code that has a bug as I was in the middle of changing to another approach.?
About Racket:
While it is Lisp, it is in Racket (a variant) and not Common Lisp or Scheme.? Frankly it is probably one of the best languages out there.? It has been around for a long time and has a very stable core of maintainers, many of them professors, grad students, academics, hardcore developers.? One of the core leaders won the Turing Award from CS (the Nobel Prize of CS) a few years back partly for Racket. It is very stable, maintained and active.? It is not a one man fly-by-night hobby language by any means.
You can read all about Racket here:
Racket Highlights:
- AMAZINGLY well documented. See - Native compilation like C or Java granting decent performance.
- High level like Python or Ruby. - Cross platform.? Runs on Mac, Linux, Windows, ARM (Raspberry Pi). - Pretty decent GUI set for graphical programs that runs cross platform as well.? i.e. Your graphics gui programs, plots etc will run on Mac, Linux and Windows. - Bug reports are addressed very quickly with pretty much immediate turn around. - Robust plotting library for graphs and charts. - Batteries included core of libraries found here:
About the IBKRE Library.
My first iteration took a standard approach to concurrency using async code, futures, thread queues, CML constructs, condition variables etc.? And while it worked OK I found I was spending too much time dealing with machinery and not enough time with my stock trading logic. The IBKRE is a Actor based approach that personally I think has been the perfect fit for working with the IBK API and is MUCH easier to use.
Library Caveats:
- Alpha / Early Beta code. - Some aspects of the library have not seen widespread code use so may have an issue here or there. - I have deliberately NOT added any of the code for order placement at this time.? (Soon)? I did not want someone placing orders and having it go wrong for them on my karma balance until things were shaken down.
I do use it all the time and someone can expect a quick fix for any bug etc.
ray what library is this?
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339)) does not?look like python is it lisp? and if so how do ?you access twsapi via lisp?
For both calls:
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339))
Seeing normal msg response in the sense of a series of 75 msg, followed by a 76.? The Sec Def Opt Param and Sec Def Opt Param End msgs.? No obvious difference in the data returned with regard to formatting.
Note I am not utilizing the Python lib, but invoking the API via a different library.? So from the API req/rsp msg layer seems ok on the surface as of time of writing.
When calling reqSecDefOptParams() on ES futures, it's possible to see it inexplicably hang.
Given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
Where the conId is for ESU0, the call will hang, however given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 383974339})
Where the conId is for ESZ0, the call returns data as expected.
I'm using ib_insync, but this doesn't appear to be a bug with that library
Additionally when calling it for ESZ0, only some expiries are not being returned. I can see dates in the TWS option chain that do not show up in the API response.
Has anyone played with this before?
I know about the reqContractDetails() approach, but that is good for 1 option chain call seemingly per minute. For ES it returns 11000 rows
|
So as to not abuse this list, for any interested in using Racket IBKRE please feel free to contact me off list.? My email is at the top of the mini-tutorial that starts with getting positions and account navs:
If there is enough demand I will create a Discord or IRC to be able to quickly answer any questions.
There is a TON of doc for the Racket Universe and please do not be scared of a Lisp.? If you can deal with Python, you can deal with Racket without issue.
The jumping off point is the language home page: In the upper right of the home page there is a link regarding some new Racket books.? Some are online and free .
The Racket language and library documentation is extensive: the two core docs are the Guide and the Reference along with tutorials, getting started guide etc. The home page for the documentation is:
The Getting Started: The Guide:
Depending on your programming experience scanning through the Getting Started and the Guide should be adequate.? For new programmers one of the books may be an easier on-ramp.? I can't really recommend one over the other.
Racket comes with its own built-in in IDE (or you can use your editor of choice).? But the Emacs racket-mode and the IDE itself are really nice. If you are a novice programmer the IDE is a godsend and will really help you out.
I'd say the signature capability of Racket is the ability to define your own languages and DSLs in Racket.? Like DotNet, DSLs, Languages and Racket can all interact and work together.? My IBKRE library is based on the outstanding Actor library called Syndicate by Tony G.??
Syndicate is far more than an Actor Library, but for doing basic IBK API stuff in the beginning you won't need much more.?? Defining and using Actors in Syndicate is the same basic pattern over and over.? Once you do a couple it is almost brainless.
Syndicate itself is a DSL in Racket.? I mention this because as you read the Racket doc you won't see much Syndicate stuff.? You need to go to the Syndicate doc.?? But you can say code up some Pivot Point logic in Racket and have an IBKRE Actor use the Pivot Point logic in a Marketdata fetching Actor without any problem.
To repeat, as to not abuse this list, please feel free to contact me off list.
ray is a simple?racket getting started guide for python devs and no knowledge of ?lisp ?
I apologize ahead of time for the blurb.? One time happening out of respect for the list.? But since someone asked ...
This is the Interactive Brokers Reactive Engine, aka IBKRE.?
Scroll down and at least read the description of the first code example.
Given a list of stocks and exchanges, get the con-id for each stock, for each stock/exchange combo get the possible strikes (the option chains via the infamous Sec Def Params API), and finally to verify the option chains invokes contract details for filter the possible option chain from Sef Def Params to the actual valid available options. Oh and all while this is going on it is also getting market data for open, close, last, volume, implied volatilities or whatever.
This is A LOT of API calls.? The key point of this example is to show how IBKRE is performing all of this stuff concurrently, all at the same time.? It will run through 100s even 1000s of option chains in a reasonable period of time (constrained by IBK's API rate limits).? CAVEAT: This example has an "api rate limiter" in the code that has a bug as I was in the middle of changing to another approach.?
About Racket:
While it is Lisp, it is in Racket (a variant) and not Common Lisp or Scheme.? Frankly it is probably one of the best languages out there.? It has been around for a long time and has a very stable core of maintainers, many of them professors, grad students, academics, hardcore developers.? One of the core leaders won the Turing Award from CS (the Nobel Prize of CS) a few years back partly for Racket. It is very stable, maintained and active.? It is not a one man fly-by-night hobby language by any means.
Racket Highlights:
- Native compilation like C or Java granting decent performance.
- High level like Python or Ruby. - Cross platform.? Runs on Mac, Linux, Windows, ARM (Raspberry Pi). - Pretty decent GUI set for graphical programs that runs cross platform as well.? i.e. Your graphics gui programs, plots etc will run on Mac, Linux and Windows. - Bug reports are addressed very quickly with pretty much immediate turn around. - Robust plotting library for graphs and charts.
About the IBKRE Library.
My first iteration took a standard approach to concurrency using async code, futures, thread queues, CML constructs, condition variables etc.? And while it worked OK I found I was spending too much time dealing with machinery and not enough time with my stock trading logic. The IBKRE is a Actor based approach that personally I think has been the perfect fit for working with the IBK API and is MUCH easier to use.
Library Caveats:
- Alpha / Early Beta code. - Some aspects of the library have not seen widespread code use so may have an issue here or there. - I have deliberately NOT added any of the code for order placement at this time.? (Soon)? I did not want someone placing orders and having it go wrong for them on my karma balance until things were shaken down.
I do use it all the time and someone can expect a quick fix for any bug etc.
ray what library is this?
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339)) does not?look like python is it lisp? and if so how do ?you access twsapi via lisp?
For both calls:
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 371749798))
?(sec-def-opt-params-req (gen-rid) 'ES "GLOBEX" 'FUT 383974339))
Seeing normal msg response in the sense of a series of 75 msg, followed by a 76.? The Sec Def Opt Param and Sec Def Opt Param End msgs.? No obvious difference in the data returned with regard to formatting.
Note I am not utilizing the Python lib, but invoking the API via a different library.? So from the API req/rsp msg layer seems ok on the surface as of time of writing.
When calling reqSecDefOptParams() on ES futures, it's possible to see it inexplicably hang.
Given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 371749798})
Where the conId is for ESU0, the call will hang, however given the call:
- reqSecDefOptParamsAsync(**{'underlyingSymbol': 'ES', 'futFopExchange': 'GLOBEX', 'underlyingSecType': 'FUT', 'underlyingConId': 383974339})
Where the conId is for ESZ0, the call returns data as expected.
I'm using ib_insync, but this doesn't appear to be a bug with that library
Additionally when calling it for ESZ0, only some expiries are not being returned. I can see dates in the TWS option chain that do not show up in the API response.
Has anyone played with this before?
I know about the reqContractDetails() approach, but that is good for 1 option chain call seemingly per minute. For ES it returns 11000 rows
|
