Specific request version number, IBrokers package for online brokers

I'm trying to understand the IBrokers package, and while reading its real-time widgets , at the end of section 2.4.1, the author of the package, Jeffrey A. Ryan, wrote:

[...] to request the current time from TWS, you must send the code for "Current time" (. twsOutgoingMSG $ REQ CURRENT TIME): "49" and the current version number of the specific request . In the case of the current time, the version is just a “1” symbol.

Scanning through the IBrokers package source code, I noticed that the author uses different VERSION numbers for different requests (for example, for reqMrktData, VERSION = 9). The one who, when I looked at the document interactive brokers API for the reqMktData () function, I see that the function does not require a "version number" as a parameter.

I also tried to find a general explanation of what version number of a particular request and when / where it might be needed, but I could not find.

I would be grateful if someone could provide me with an explanation of this "VERSION" variable, what he wanted to do / achieve, and how / where we can find a list of version numbers for various requests to the interactive brokers API.

Thank you in advance

+6
source share
1 answer

I would be grateful if someone could provide me with an explanation of this "VERSION" variable, what he wanted to do / achieve, and how / where we can find a list of version numbers for various requests to the interactive brokers API.

Problems with the evolution of the API.

Look at the class EClientSocket in the Java API (or C ++) client library code. Jeff Ryan probably picked up / should pick up VERSION numbers from here.

Basically, as the capabilities of the IB / server platform evolved, there were older as well as newer versions of the client APIs used by clients. Thus, the IB server is able to handle requests from older versions of the IB API Clients, as well as newer ones. VERSION helps the server distinguish which version of the API this calls.

For example, newer versions of the IB Client API can reqMktData() for whole combinations with several legs in one shot, which old clients could not do. Thus, as you noted, this is 1 for a simpler API that has not evolved, e.g. cancelHistoricalData() , cancelScannerSubscription() , etc., but there can be up to 7 or 9 for APIs that tend to evolve over time such as reqMktData ().

In lower-level terms, VERSION tells the server which parameters the Client will transmit to Socket immediately after send() -in << 25>. Below is a snippet of code from reqScannerSubscription() . Pay attention to send(VERSION); immediately after send(REQ_SCANNER_SUBSCRIPTION);

(Note that there are two more types of version numbers: the server version of the server on the server side (IB Server / Platform) and the version number of the TWS client API API! They are separated from each version of the API by API s. Regardless of whether you really need IB for each VERSION API request, which is separate from the version of the IB client, it does not seem immediately obvious to me, but now how they roll right now).

Apologies for an incoherent response; one look at EClientSocket.java will clear it! EClientSocket.java

 public synchronized void reqScannerSubscription( int tickerId, ScannerSubscription subscription) { // not connected? if (!m_connected) { error(EClientErrors.NO_VALID_ID, EClientErrors.NOT_CONNECTED, ""); return; } if (m_serverVersion < 24) { error(EClientErrors.NO_VALID_ID, EClientErrors.UPDATE_TWS, " It does not support API scanner subscription."); return; } final int VERSION = 3; try { send(REQ_SCANNER_SUBSCRIPTION); send(VERSION); send(tickerId); sendMax(subscription.numberOfRows()); send(subscription.instrument()); send(subscription.locationCode()); 

Client version history at the top of EClientSocket.

 public class EClientSocket { // Client version history // // 6 = Added parentId to orderStatus // 7 = The new execDetails event returned for an order filled status and reqExecDetails // Also market depth is available. // 8 = Added lastFillPrice to orderStatus() event and permId to execution details // 9 = Added 'averageCost', 'unrealizedPNL', and 'unrealizedPNL' to updatePortfolio event // 10 = Added 'serverId' to the 'open order' & 'order status' events. // We send back all the API open orders upon connection. // Added new methods reqAllOpenOrders, reqAutoOpenOrders() // Added FA support - reqExecution has filter. // - reqAccountUpdates takes acct code. // 11 = Added permId to openOrder event. // 12 = requsting open order attributes ignoreRth, hidden, and discretionary // 13 = added goodAfterTime // 14 = always send size on bid/ask/last tick // 15 = send allocation description string on openOrder // 16 = can receive account name in account and portfolio updates, and fa params in openOrder // 17 = can receive liquidation field in exec reports, and notAutoAvailable field in mkt data // 18 = can receive good till date field in open order messages, and request intraday backfill // 19 = can receive rthOnly flag in ORDER_STATUS // 20 = expects TWS time string on connection after server version >= 20. // 21 = can receive bond contract details. // 22 = can receive price magnifier in version 2 contract details message // 23 = support for scanner // 24 = can receive volatility order parameters in open order messages // 25 = can receive HMDS query start and end times // 26 = can receive option vols in option market data messages // 27 = can receive delta neutral order type and delta neutral aux price in place order version 20: API 8.85 // 28 = can receive option model computation ticks: API 8.9 // 29 = can receive trail stop limit price in open order and can place them: API 8.91 // 30 = can receive extended bond contract def, new ticks, and trade count in bars // 31 = can receive EFP extensions to scanner and market data, and combo legs on open orders // ; can receive RT bars // 32 = can receive TickType.LAST_TIMESTAMP // ; can receive "whyHeld" in order status messages // 33 = can receive ScaleNumComponents and ScaleComponentSize is open order messages // 34 = can receive whatIf orders / order state // 35 = can receive contId field for Contract objects // 36 = can receive outsideRth field for Order objects // 37 = can receive clearingAccount and clearingIntent for Order objects private static final int CLIENT_VERSION = 37; private static final int SERVER_VERSION = 38; private static final byte[] EOL = {0}; private static final String BAG_SEC_TYPE = "BAG"; 
+2
source

Source: https://habr.com/ru/post/951592/


All Articles