开云体育

You might want to check this post and the topic for more information about the various market data connection messages. I don't want to repeat that post but here some thoughts:

• There is a difference between "connection inactive" (when the farm is no longer needed) and "connection lost" (when there is a network failure or IBKR resets the farm)
• If there is any active subscription to real-time data, market data farms never become "inactive". They may be "lost" but in our experience are re-established within milliseconds without any impact on your client (unless you have a serious and ongoing network issue between you and IBKR).
• HDMS farms provide more general information services and are not limited to just historical market data download. If you dig into the TWS/IBGW logs you will see that internally, HDMS queries are made even for TWS API calls such as and and many (if not all) calls that have a object parameter. Apparently, HDMS farms carry and provide certain instrument related meta information for the instruments they are responsible for.
• There is absolute no need to "heartbeat" any of these servers and it actually may backfire on you since you may eat into you "pacing" budget. As I said before, market farms become inactive when they are no longer needed and get connected instantaneously and transparently when any of your API requests require them. If a connection that is needed is lost, it is also reconnected automatically without service interruption.

You say you find over 300 error code 162 messages in your log. That suggests to me that your client is causing pacing violations and I suggest you revisit the section and other documentation on the limits IBKR places on the rate of historical market data requests. Error code 162 is often related to pacing violations and does not always use the words "pacing violation" in the error message. When you request historical data too quickly, IBKR sometimes:

• slows down the response time fore requests
• fails requests with error 162 and message "no such data" or other errors
• fails requests with error 162 and some pacing violation message
• disconnects your client all together when too many pacing violations occur

You can dig into the TWS/IBGW logs to learn more about what is going on but that may be cumbersome and time consuming. You can also enable additional (and very verbose) HDMS activity logging where you can see exactly which of your client API calls cause HDMS server XML data exchange. You can also see farm management in action (such as "inactive/active" and "lost/reconnect").

闯ü谤驳别苍