开云体育

Don't do that. There is no need for you to cancel subscriptions or to disconnect/reconnect your clients during the nightly reset window and what your client does may be more harmful than helpful. Especially if you have hard-coded wait/sleep/timeout times of 50 seconds.

TWS/IBGW are remarkably reliable through the nightly reset process and all real-time subscriptions survive the reset (and in fact provide data throughout the entire reset process). That includes subscriptions for five second real-time bars but not subscriptions the historical data with keepUpToDate = true.

First, each data farm gets disconnected/reconnected individually and you get a series of "connection broken" and "connection OK" indications. In my case, each of these resets takes only a fraction of a second and all real-time data keeps arriving (MktData, Level 2, TickBytick, Realtime Bars)

Eventually, TWS/IBGW reset their main connection with IBKR and re-authenticate. That is when you may see a series of error code 1100 messages "Connectivity between IB and Trader Workstation has been lost.", count-down pop-up windows, and eventually the indication 1102 "Connectivity between IB and Trader Workstation has been restored - data maintained.". But these have nothing to do with real-time data feeds for existing subscriptions. It is just that you can't make new subscriptions, place orders, or make any API request between 1100 and 1102 that require communication between TWS/IBGW and the IBKR servers.

I often get many 1100 over a period of several minutes before the final 1102, but real-time data continues since the market data farm connections are and all stay OK (where the real-time data comes from).

And the fact that you sometimes get "The following farms are not connected: ushmds" is probably normal and not an error. Since you use IGBW, the HMDS server may simply not be needed at that time. HMD traditionally stood for Historical Market Data but those servers now seem to provide a more general purpose query infrastructure but may not be needed until you request historical data or ContractDetails, establish new real-time subscriptions, or place orders. They would automatically be connected at that point.

And coming back to the 5 second real-time bars for a moment. You did not tell us what kind of instruments and exchanges you are subscribing to but it could very well be, that there are no trades to be reported for 10 or more periods of 5 seconds in the middle of the night. Very active instruments and CME/CBOT traded instruments do get updates even for periods with no activity (volume and count is 0), but I have seen some instruments that only get bars for periods with trades or bid/ask changes.

Just remove the cancel/disconnect/connect logic and your client should get through the reset windows without any problems and with real-time data arriving. It has done so for me for years.

闯ü谤驳别苍

?

No worries about the open orders. The reset only relates to the connections with IBKR, TWS maintains state, remembers open orders that were placed before connection is lost, and order callbacks continue when the connection is restored.

• Maintain and resubmit orders when connection is restored.
• The tool-tip says: When this setting is checked, all orders received while connectivity is lost will be saved in memory and automatically resubmitted when connectivity is restored. You may use this option to prevent order data loss.

I must have read your initial post to quickly and had not realized the fact that you have a docker containerized setup. While I understand how both work, I use neither Docker nor IBC so that I cannot give you any advice based on practical experience. But between IBC and Docker, I'd first look into the Docker network setup.

Docker containers materially change the data flow between applications inside the container, the host, and the external world with many possible configuration options and scenarios. And, depending on your docker network configuration, container isolation may interfere with data routing from IBKR to IBGW inside the container after the nightly reset when the port numbers used by IBGW have changed, but the ports number used by IBKR have not. The IBGW restart would clear that up.

If you can, make a test where IBGW runs without the docker container directly in the host. That works just fineand rock solid for me.

Extensive discussions about docker and IBC are out of scope for our group, though. For IBC you can start a discussion over at the /g/ibcalpha group.

闯ü谤驳别苍

?

Sorry to hear it still does not work for you, Farhan. But unless everyone is still on vacation, it looks like this issue may be unique to your setup.

Just to make sure. When you say that real time subscriptions do not send data after the maintenance window reconnects, that relates to callbacks from one or more of these: reqMktData, reqRealTimeBards, ?reqTickByTickData,, reqMarketDepth. Right? We are not talking about reqHistoricalData with keepUpToDate = true. I have seen those stop after the maintenance window reconnects.

And your code does not (inadvertently) call the corresponding cancel requests upon the various errors/warning/infos the client receives during the reset period?

How about other TWS API callbacks? Do you receive account value updates, position updates, openOrder, execDetails, ... or any of the non-data related calls?

I guess my next step would be to determine whether this is related to the client or to IBGW. Try to get a "second opinion" from one of the clients that ship with the API or All of those allow you to quickly subscribe to a market data feed. If they receive market data after the maintenance window, it's the client you;d have to look at. If not, it is something with IBGW that probably IBKR needs to look at.

闯ü谤驳别苍

?

Nothing jumps at me, except that ushmds disconnected at 12:17:38 and did not reconnect by the time TWS/IBGW had reestablished full connectivity with IBKR at 12:18:08. But that may be fine in case it was not needed any longer.

What kind of symbols were your reqRealTimeBars for? STK, FUT, OPT, ..., US, HK, Asia, ...?

What time zone are these timestamps in?

Have you taken a look at the TWS/IBKR logs? Just to see whether there are some errors related to market data.

闯ü谤驳别苍

?

From the logs is sounds like the intention was to "disconnectAndReconnect due to routing change for ushmds" but the reconnect part never materialized. You'd probably have to reach out to IBKR to understand why the reconnect never happened and what can be done about it.

Before disconnect, your TWS/IBGW was connected to the US Central/Chicago HMDS located at cdc1.ibllc.com. Do you have a decent network connection between your system and cdc1? As in decent packet loss?

闯ü谤驳别苍

?

?