Okay, MktDataType 2 may be the answer. Parts of the documentation say it is the quotes recorded at the last closing, which is not what I want, but part of it says it is the last quotes seen by their system, which is what I want. Since the market is closed, I have to find out on Monday. Thank you for your help.

There are still some pending questions that I need to investigate:

1. Does MkDataType 2 provide the last quotes recorded at closing or just the last recorded quotes?
2. Do I need to call reqMktData twice for each contract, once with type 2 and a second time with type 1, to get both the last recorded quotes and the live updates?
3. If I do this, it may mask the problem that a bid is in fact "stuck" and is never updated, which means I have to write extra monitoring code to see if quotes do update.

开云体育

开云体育

Type 2 is the last data recorded at market close, which is not what I want.

Also, "live" does not usually just mean that I will only get the data when there are new updates. It also means that I will get the most recent quote when there are no new updates.

If it were to only get the data when there is an update, then all the snapshot functions wouldn't work. Also, it is not really consistent with my experience. I find that sometimes it is missing a bid and sometimes the close. Note that a market maker rarely only send the ask and not the bid when updating their quotes. Missing the close is even harder to explain. The fact that I never experienced this on the initial connection to a freshly started gateway also means that this is perhaps not the reason.

I am having an odd problem. Everything works as expected when my client makes an initial connection to the gateway. However, if I restart the client process, sometimes reqMktData()won't get all the fields. Specifically, if I do the below, I find everything in the ticker object are filled except for bid and bidSize, which are nan. Sometimes, it is the close price that is nan.

ticker  = ib.reqMktData(contract)
asyncio.sleep(0.5)
# ticker.bid, ticker.bidSize, ticker.close may be nan

I have logic to retry the subscription as follows, but it rarely does anything:

ib.cancelMktData(contract)
asyncio.sleep(0.1)
ib.reqMktData(contract)

When this happens, the same few contracts out of 30 have this problem no matter how many times I retry (like the above). The other contracts are completely fine.

This does not happen every time. Occasionally, restarting the client to make a new connection the second time is okay, and when the second time is okay, it tends to be okay for subsequent connections. Over 50% of the time, however, making the connection the second time will have the above-described problem. If the second time fails, all subsequent connections will also fail.

The problem is not limited to the gateway. Connecting with TWS has exactly the same problem.

Restarting the gateway fixes this problem. I have never seen this happening to the initial connection to the gateway instance. This seems to say that the gateway has to be restarted every time I restart my client, which is tedious.

Has anyone encountered similar issues?

开云体育

开云体育

开云体育

开云体育

ib.reqHistoricalDataAsync takes timeout parameter, set it to 0 and this method will not time out.

thank you for replying, I have identified the problem: the reqTickers was nested in the reqTickByTickData, so I changed the App structure. BTW do you know the function to use for nested call (even though I remember that nested asyncio and blocking was not recommended)? best

What seems to be happening is the instance of IB() is keeping data and not actually sending a request to TWS. The API logs only show one request being sent per connection, not the two I was expecting from the code above.

If I have two instances of IB(), and switch between those, I get correct data. Just disconnecting, changing port, and reconnecting within the same instance of IB() seems to be causing the confusion.

Any delay between disconnect and reconnect, makes no difference as long as it's still the same instance of IB(). Could someone who maintains the library investigate?

开云体育

I have a program that will place trades in either the paper or live account. I run both platforms simultaneously on the same machine. It crashes when I try get my account value after switching from one to the other because I get the first result over again. I have a support ticket in with IB, but they keep suggesting it's my code. Can anyone here create the problem to help me sort this out?

With two instances of TWS open, one paper and one live, here's the simplest code I've run to show the problem:

from ib_async import *

def ensure_connection(ib: IB, host: str, desired_port: int, client_id: int): """Ensure IB is connected to the desired port. Reconnect if necessary."""

# Check if IB is connected and if the port matches
if ib.isConnected() and ib.client.port == desired_port:
    print(f"Already connected on the desired port: {desired_port}")
    return

# If connected but on the wrong port, disconnect
if ib.isConnected():
    print(f"Connected on wrong port {ib.client.port}, disconnecting...")
    ib.disconnect()
    ib.sleep(1)

# Reconnect on the correct port
print(f"Connecting to port {desired_port}...")
ib.connect(host, desired_port, client_id)

print(f"Connected on port: {ib.client.port}")

ib = IB()

IBPort = 7496

ensure_connection(ib, "127.0.0.1", IBPort, 33) print(ib.isConnected()) print(ib.client.port)

SummaryAccountValue = ib.accountSummary() print(SummaryAccountValue)

IBPort = 7497

ensure_connection(ib, "127.0.0.1", IBPort, 33) print(ib.isConnected()) print(ib.client.port)

SummaryAccountValue = ib.accountSummary() print(SummaryAccountValue)

ib.disconnect()

print(ib.isConnected()) print(ib.client.port)

IBPort = 7497

ensure_connection(ib, "127.0.0.1", IBPort, 33) print(ib.isConnected()) print(ib.client.port)

SummaryAccountValue = ib.accountSummary() print(SummaryAccountValue)

IBPort = 7496

ensure_connection(ib, "127.0.0.1", IBPort, 33) print(ib.isConnected()) print(ib.client.port)

SummaryAccountValue = ib.accountSummary() print(SummaryAccountValue)

ib.disconnect() ''' ib.fills also seems to have problems. For the first connection, it will show correct information, but on the second connection, it will show the first plus the second.

Is there a problem somewhere in the ib_async library or is this an IB issue? Can anyone reproduce this or suggest how I can fix it?

Glenn