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

Question

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

[...] чтобы запросить текущее время у TWS, необходимо отправить код для "Текущего времени"(.twsOutgoingMSG$REQ CURRENT TIME): "49" и номер текущей версии конкретного запроса. В случае текущего времени версия - это просто символ "1".

Просматривая исходный код пакета IBrokers, я заметил, что автор использует разные номера VERSION для разных запросов (например, для reqMrktData, VERSION = 9). Кто бы ни посмотрел на API- документ Interactive Brokers для функции reqMktData(), я обнаружил, что для функции не требуется "номер версии" в качестве параметра.

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

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

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

Answer 1

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

Проблемы развития API.

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

В основном, по мере развития возможностей платформы IB / серверов, клиенты использовали как старые, так и новые версии клиентских API. Таким образом, сервер IB может обрабатывать запросы как от старых версий клиентов API API, так и от новых. VERSION помогает серверу определить, с какой версией вызова API он имеет дело.

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

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

(Обратите внимание, что существует ДВА других типа номеров версий: номер версии на стороне сервера (IB Server / Platform) и номер версии API клиента TWS IB! Они отличаются от ВЕРСИИ для каждого API, которая вас интересует. IB действительно нужна VERSION для вызова API, которая отделена от версии IB Client, для меня это не сразу очевидно, но вот как они работают сейчас).

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