开云体育

Recently, this mailing list was already the venue for an investigation into this apparent breaking change. You can search for the respective tread. As far as I can rely on my memory, the second argument is inconsequential for retail investors and it's OK to use both null and a default new instance.

That's a question for IBKR and it has been like this forever. There is a post in our group archive every few months such as this one from August: TWS not connecting throwing a timeout error as port is stuck in (CLOSE_WAIT) state .

The workaround is to avoid TCP/IP connections that get closed without sending the "API\0" message and firestorms of several connection requests simultaneously.

If you want to learn more about what happens (though you won't be able the change anything), enable verbose/debug logging in TWS, look at the logs, and follow how the port listener thread pool starts dedicated API threads for each connection. For some reason (race condition, missed socket-closed exception, singleton, ...) one of those threads can get locked up if it does not see the "API\0" message, or if the TCP/IP connection gets closed immediately after it has been established. Once that happens, TWS/IBGW can accept more (physical) TCP/IP connections, but it cannot start client conversations any longer until it restarts.

闯ü谤驳别苍

?

I can telnet to this port and it opens up, so the Gateway is listening on the port.

This is likely your problem. TCP/IP socket connections that do not start the TWS API session conversation with a properly formatted "API\0" message or that send some other data. As you describe, TWS/IBGW will still accept additional TCP/IP connections, but an API session cannot start any longer until restart. Not sure whether that is by design or a side effect of the implementation.

Avoid any such TCP/IP connection requests from port scanners or port monitoring tools, or at least send a proper "API\0" message.

闯ü谤驳别苍

?

My apologies. I use a (pimped) version of the ApiController class that ships with the TWS API. It implements a "controller pattern" and hides a lot of unnecessary TWS API details from the client. But for some reason for the reqExecutions call, it renamed the execDetails() callback to tradeReport() and execDetailsEnd() to tradeReportEnd(). But their functions are identical.

You should reach out to IBKR if your execDetails callbacks indeed only arrive, when the Trade History window is open in TWS.

I still think that you need something more than Execution objects to properly implement your rules based trading. Keep in mind that a single order can be filled with multiple trades (causing multiple execDetails() callbacks and multiple Execution objects with different execIds) and that the total traded volume could be different from what your order asked for. Your rules logic needs to properly handle that. But you are correct that the position callbacks only provide you with aggregate quantities.

Maybe you need a thin layer that related the rule instructions to the various order and execution events and that avoids the erroneous rule execution tiggered by certain execDetails call backs. You could probably use the orderRef field to tag orders so that you know which rule event it belongs to. orderRef is a string in the Order class that you can define as you like when you place the order, it is returned with all order related callbacks as well as in Execution objects you receive from execDetails callbacks. If the rule, for example, says "sell 120" but that takes place in three trades of 100 + 10 + 10, your logic knows that those three execDetails() callbacks and Execution objects relate to that one rule event. And it also would know in case the actually traded volume is different from what the rule asked for.

闯ü谤驳别苍

?

The Trade to Execution (Trade Report) relationship is definitely a "one to many". From the documentation:

As far as I know, Trade to CommissionReport is a "1 to 1" relation. I don't think that there are corrections for those.

闯ü谤驳别苍

?

Just to confirm that you are talking about historical tradeReports right after the call to reqExecutions and before the tradeReportEnd clall back. You are not talking about real-time reports right after order fills, right?

I can confirm this behavior for when the markets were closed over the weekend, and today at 16:30 US/Central during the CME/CBOT daily trading pause hour (my trade reports were for various futures). But just before 17:00 US/Central on Sunday and today and during trading hours, historical trade reports were delivered right after reqExecutions calls regardless of whether the Trade History window was open or not. This is probably a question for IBKR, but there are other request types with a disclaimer in the documentation that they only work when exchanges are open.

But coming back to your other questions. If I understand you correctly, you are trying to create a reliable "position" monitor within your client application. Both getting the an initial correct state when the client starts as well timely updates in real time when your orders fill.

For my taste, historical trade reports are not well suited to do that, considering that they generally are only available for the time since midnight (IBGW and TWS default) and only manual configuration of the TWS Trade History windows give you a longer historical view. Also, when you look at the (simplified) data model below, trade reports are pretty far removed from the notion of "Position" and subscriptions that get you updatePortcolio, position, pnl, and order status callbacks give you better data for position monitoring.

I did not understand your comment about position updates when you say "By using the position(..) + positionEnd(...) ? In my case it sends the close again and basically opens the symbol in the other direction". You would:

• call to subscribe to position updates
• for each first call back for an instrument you'd create an internal "Position" object
• you can configure TWS/IBGW in the API configuration section whether they should send you "empty" positions (e.g. recent positions that now have a quantity of 0).
• you know that you have seen all currently open positions when you receive the callback
• and for each subsequent call back for that instrument, you'd update your internal "Position" object accordingly.

闯ü谤驳别苍

?

?

• Real time market data subscriptions include reqMktData, reqRealTimeBars, reqTickByTickData, and reqMktDepth
• It does not include reqHistoricalData with keepUpToDate set to true. In my experience, those do not survive all data farm reconnects.

When I checked up on "holes in the data" for an instrument in the past it was always caused by a quiet period for that instrument (unless my recorder client had failed).

As a matter of practice I now subscribe to "5 second real time bars" for all instruments as a "second opinion" and data feed quality metric. For many instruments, those bars get sent for every 5 second period, even if no trades or ask/bid changes took place (16,560 or 17,280 bars per day). A 0 volume 0 count bar confirms quiet periods for the other feeds of that instrument. They also serve as data feed heart beat detectors.

But then, data for instruments I subscribe come from big exchanges and are generally quite active. Feeds from smaller exchanges or infrequently traded instruments may behave differently.

闯ü谤驳别苍