Hi all,

I would like to request a feature and I don't know to whom to address this.
The feature is about requesting all option contracts for specific expiration dates, or all contracts up to some date in the future.
So, in pseudocode, I would like to have something like

contractsList = ib.reqOptionContractsUntil(symbolId, 60days from today)

The contractsList would then be filled with objects that hold all calls and puts contracts for a specific date(like the tabs in the options trader) up to 60days in the future.
The current solution with reqSecDefOptParams is really hard to work with to achieve the same result.
You first get the data and then you have to request if a specific combination of expiration/strike is even valid.
If you have many symbols, for which you want these contracts, you would have thousands of slow requests towards the server for all possible combinations.
This takes a very long time and is bad for the network.

It would be so much simpler, if the IB server would directly give us back all valid contracts.
What do you think?
Is there an email address where I can forward this proposal to the developers?

Thanks you very much for help,
Juergen

I run it fine on Ubuntu on AWS

Version 20 of Ubuntu.

Works fine.

My only nit is the need to restart it weekly.

That is truly sophomoric.

A daemon is supposed to run 7x24x365 and not require re-authentication or at most automatic re-authentication.

Very strange.

Plus having to run the GUI itself.

The IB Gateway also is sophomoric.

My two cents.

Level up Interactivebrokers.com!!!!

I'm no technology expert so would appreciate any help.
I've downloaded the latest version of TWS API and ticked the "Enable ActiveX and Sockets Clients" box under API Settings in TWS.

However, when attempting to run the sample Excel sheet TwsRtdServer sheet or building simple RTD functions to bring in stock prices I get #N/A error codes.

Any idea what might be the reason for error?

I've tried to repair Excel but the problem still remains.

After looking through Microsoft help pages I read: "RTD servers should be digitally signed. If an RTD server is not digitally signed, the server may not load, and a #N/A will be displayed in the cell(s) referencing the RTD server."

Does anyone know how to confirm that the RTD server is digitally signed?

Also, are there any specific excel COM Add-ins that have to be running for TWS RTD to work?

I’m running Excel on Microsoft 365.

I don't know how your overall design is structured, but indeed there are performance issues due to GIL of python. So you do need to use multiprocessing.? But I do believe you can get lot of performance just using python + multiprocessing. Lot of the core building blocks in numpy/pandas is highly optimized - so it is less likely your performance would be impacted due to these (unless ofcourse you are extremely latency sensitive). I use IB for orders, but use a different 3rd party data provider. What I have is?
#1) First I have a process that would start IB as a background thread. This process will create the IB thread with all the connections established. Then it enters a wait loop forever, waking up periodically.
#2) I have a separate process that handle data feeds, does model predictions etc and send messages to the waiting process. I use multiprocessing shared memory () to exchange signal output between data feed process and IB process. Waiting IB process picks up from queue periodically and post orders to IB. Just use locks as appropriate (If you need IB for feed, you can still do it by making the waiting process query data and receive data in an async fashion. Locks and shared memory are your best friend here).?

It take a bit to get this going, but I want to stick to python and this design so far works for me (I haven't tested it with lot of symbols, but at that point the bottleneck would be with data + model evaluation, I suspect)

What would be the best way to do on-the-fly computations using Numpy, Pandas for trading using IB TWS API, writing to/from mySQL, and in the meanwhile receive and send data and orders?

From (and ) I conclude that CPU-bound programs, those that spend most of the their time processing data (like on the-fly computations using Pandas which is synchronous single threaded), solutions like threading (pre-emptive multitasking) and asyncio are inferior (and may disrupt the sending/receipt of data or introduce some lag or data drops) since there is only one Python interpreter on a single core/processor (asyncio aligns I/O processes more efficiently) that takes care of both the CPU computations and checking for socket data.

I know there is? a ib_insync library that implements cooperative multitasking (asyncio) in Python, but will the overall program be fast enough if you do computations using large dataframes? I read that on a socket level there might not be any limitations (“socket itself is actually thread-safe”), as suggested by . I do not assume that Ptyhon has it implemented this way since the Global Interpreter Lock is in place (single thread, synchronous). From :

IB.sleep(0); may be an alternative, but I do not think a Pandas groupby() can be interrupted once called.

Should I use the Multiprocessing library and do every task on its own processor (thus dataframe calculations, mySQL connection read/write, sending and receiving orders and data)?
Or should I combine some things using (I think some next level threading which can be combined with the normal way of interpretation of code by Python) or the (has to do with built-in async for Scikit-Learn, Pandas, etc. functions, if I understand correctly) library? I think this is next level, and may be an overkill.

Or should stick to Java (I do not know if there is a Pandas like alternative which allows easy manipulation of data and performing machine learning for example, but threading may be organized better)?

Any suggestions or tutorials?

(I read something about was well, but that’s a whole different story since it is not directly applicable to IB TWS API, and may be prone to delays resulting from single core processing/interpreting by Python as well, if I understand correctly)

Thanks for your answers. That's what I thought at first, but when I ask for the underlying past quotes, I can see a discrepancy between historical data using reqhistoricaldata, and what is displayed on the graph. Using RTH or not, and setting RTH graph parameter, figures differ for all (open, high, low, close)

Hi, I try to get the expiration price of an option (let's say SPY) expired 2 months ago.
I tried to get the Close of the last trading day using reqHistoricalData:
IContract.exchange="SMART"
IContract.conId=458962807?????? //SPY 2021-01-22 Call 386
IContract.includeExpired=true
IBClient.ClientSocket.reqHistoricalData(1,IContract,"20210125 02:00:00 CET","1 W","1 day","TRADES",0,1,0,Null)

But I get an error 200 No security definition has been found for the request
Which sounds logical, according to the historical data limitations:
unavailable historical data: Expired options, FOPs, warrants and structured products

So, does anyone knows how to get the last price of an expired option (the expiration price kept for assignment calculations by OCC and IB) via API (and not FLEX queries)?

Hi Dan, did you get any solution to handle these Expired/Assigned option orders, initiated by IB?

Am I the only one here to try to automate ASSIGNED, or EXPIRED option prices retrieval?

Thanks Mark. That was a great suggestion that did give me insights into the real issue (that you alluded to subtly). There is strong correlation between IB prices and what I expect to so based on tape. So turns out my edge was small enough (close to spread value) that it was not real!? But still getting better fill is important. I don't know how well midprice or Adaptive orders could be simulated in paper trading for example. I'd greatly appreciate if you have any pointers to explore getting better fils.? (my system is momentum based, so will be taking liquidity away).

This is why orderRef (or a similar customer-supplied field) should be int64 instead of string, then no issues with storage.

True but OrderRef reset is an exception I wouldn't blame them for. Didn't test its limits but obviously clients can stuff A LOT of data into this field at zero cost to them so I imagine it could easily get out of hand for IB if they kept all of it on their servers forever.

开云体育

IB is all-in with daily resets. I don't know if they painted themselves into a corner long ago and would essentially have to start over, or if there is some kind of regulatory or legal explanation. It doesn't seem like technology itself requires a broker to go offline every day.