Номер версии конкретного запроса, пакет IBrokers для интерактивных брокеров

Question

Я пытаюсь понять пакет IBrokers, а при чтении его Real Time vignettes в конце раздела 2.4.1 автор пакета Джеффри А. Райан, писал:

[...], чтобы запросить текущее время от СПЦ, нужно отправить код "Current Time" (twsOutgoingMSG $ REQ текущего времени.): "49" и текущей версии номер конкретного запроса. В случае текущего времени версия является просто символом «1».

Сканирование через исходный код пакета IBrokers, я заметил, что автор использует другой номер версии для различных запросов (например, для reqMrktData, Version = 9). Тот, кто, когда я, посмотрел API Interactive Brokers document, для функции reqMktData(), я вижу, что функция не требует «номера версии» в качестве параметра.

Я также попытался найти общее объяснение того, какой номер версии конкретного запроса и когда/где он может понадобиться, но я не мог найти его.

Я был бы признателен, если бы кто-нибудь мог предоставить мне объяснение этой переменной «VERSION», что она предназначена для достижения/достижения и как/где мы можем найти список номеров версий для различных запросов к API интерактивных брокеров ,

Спасибо заранее

Answer 1

Я был бы признателен, если кто-то может дать мне объяснения к этой «VERSION» переменной, то, что это означало, чтобы сделать/достичь, и как/где мы можем найти список номер версии для различных запросов к API интерактивных брокеров.

Проблемы с эволюцией API.

Посмотрите на class EClientSocket в коде клиентской библиотеки API Java (или C++). Джефф Райан, вероятно, взял/должен был забрать номера VERSION отсюда.

В основном, поскольку развивались возможности платформы IB/Сервера, были использованы более старые и новые версии клиентских API, используемых клиентами. Таким образом, сервер IB способен обрабатывать запросы от более старых версий IB API Clients, а также более новые. ВЕРСИЯ помогает серверу различать, какую версию API вызывает это.

Например, более новые версии API-клиентов IB могут reqMktData() для целых комбинаций с несколькими ногами одним выстрелом, которые старые клиенты не могли сделать. Таким образом, как вы отметили, это 1 для более простого API, который не эволюционировал, например, cancelHistoricalData(), cancelScannerSubscription() и т. Д., Но может быть до 7 или 9 для API, которые, как правило, эволюционируют со временем, например reqMktData() ,

В более низкоуровневых выражениях VERSION сообщает серверу, какие параметры Клиент собирается передать на Сокет сразу после send() -в VERSION. Ниже приведен фрагмент кода от reqScannerSubscription(). Обратите внимание на send(VERSION); сразу после send(REQ_SCANNER_SUBSCRIPTION);

(Обратите внимание, что существуют два других типа номера версии: серверная сторона (IB Server/Platform) номер версии, и IB TWS номер версии Client API Они отделены от per-API VERSION, о которой вы беспокоитесь.Независимо от того, нужен ли IB для каждого API-запроса VERSION, который отдельно от версии IB-клиента, мне сразу не кажется очевидным, но вот как они сейчас рулятся).

Извинения за бессвязный ответ; один взгляд на 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()); 

История версий клиента в верхней части 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";