Противоречия между API товарных фьючерсов и цифровых валютных бирж

Существуют существенные различия между CTP на товарные фьючерсы и API на цифровые валюты.

Исторические данные

Интерфейс CTP не предоставляет исторических рынков, которые должны быть решены через трейдеров. В случае, если отсутствие прибытия или разрыв прибытия приводит к потере данных о рынках, CTP не предоставляет механизм возврата данных. Исторические рынки доступны только с помощью данных третьих лиц.

Соглашение разное

API криптовалют, как правило, REST и websocket протоколы, внутри которых CTP вкладывает сетевую логику, используют протокол FTD, основанный на протоколе TCP, для общения с CTP в фоновом режиме.

• Режим ответа на запрос: клиент инициирует запрос, CTP в фоновом режиме принимает и отвечает на запрос
• Модель радиокоммуникаций: после подписания клиента на контрактный рынок, CTP продвигает информацию о рынке через радио.
• Модель частной связи: после того, как клиент поручает выполнение операции по контракту, информация о заявке, возврате сделки и т. д. перемещаются между точками CTP.

Все рынки и сделки с заказами в протоколе CTP уведомляются только после изменения, а запросы на заказы, счета и хранение являются активными запросами. Все эти три модели могут быть найдены в аналогичной форме в API цифровой валюты.

Различается точность данных.

CTP-протоколы имеют глубину покупки-продажи, платформы платят за пять типов, цифровые валюты обычно доступны в полной глубине или 200-ти. CTP не продвигает реальные транзакции, а может отталкивать их только с помощью изменений в состоянии, а API цифровых валютных бирж получает реальные транзакции. Внутренний CTP-платформа имеет уровень тика данных транзакций в 1 секунду.

Различные ограничения

Криптовалютные биржи обычно ограничивают 10 раз в секунду. Для снятия большинства заказов нет особых требований. CTP строго ограничивает запросы, которые требуют инициативной подачи, обычно один раз в 2 с более безопасным, также есть требования к количеству снятий.

Устойчивость

Протокол CTP очень стабилен и практически не имеет ошибок и проблем с сетью. Цифровые валюты должны быть менее ограничительными, длительными для транзакций, а также повсеместными для обслуживания, задержек данных, ошибок в сети.

FMZ - платформа для количественной оценки лучших практик протокола CTP

По умолчанию интерфейсы CTP для получения данных, такие как GetTicker, GetDepth и GetRecords, имеют кэшированные данные для получения последнего, поэтому политика может быть использована без использования Sleep. При изменении рынка все тикеры, глубины и записи обновляются, при этом любой интерфейс, на который был вызван, возвращается немедленно, состояние вызванного интерфейса устанавливается в ожидании обновления, следующий вызов того же интерфейса ждет, пока не вернется новая информация.

Если вы хотите получить доступ к данным каждый раз, когда вы получаете данные, даже старые данные, вы можете переключиться на режим мгновенного обновления рынка.exchange.IO("mode", 0) ; в этом случае политика не может быть написана как движущаяся событиями, необходимо добавить событие SLEEP, чтобы избежать быстрого мертвого цикла. Некоторые невысокочастотные стратегии могут использовать эту модель, а стратегия проста в разработке.使用exchange.IO("mode", 1) можно перейти в режим кэширования по умолчанию.

При работе с отдельными контрактами можно использовать режим по умолчанию; но если это несколько контрактов, возможно, что один контракт не обновляет рынок, что приводит к блокировке доступа к интерфейсу рынка, и другие контракты не могут получить обновления рынка. Чтобы решить эту проблему, можно использовать режим немедленного обновления, но не удобно писать высокочастотную стратегию.设置方式为exchange.IO("wait") ; если добавлено несколько обменных объектов, что редко бывает в товарных фьючерсах, то это может привести к увеличению цены.可以使用exchange.IO("wait_any"), при этом возвращенный индекс указывает на возвращенный индекс биржи.

Процесс тика изменения push: {Event: tick, Index: индекс биржи ((в порядке добавления роботом биржи), Nano: время наносекундного масштаба события, Symbol: название контракта} Публикация ордера: {Event: order, Index: индекс биржи, Nano: время наносекундного масштаба события, Order: информация о заказе ((совместимо с получением GetOrder) }

В этом случае стратегическая структура может быть написана так:

function on_tick(symbol){
    Log("symbol update")
    exchange.SetContractType(symbol)
    Log(exchange.GetTicker())
}

function on_order(order){
    Log("order update", order)
}

function main(){
    while(true){
        if(exchange.IO("status")){ //判断链接状态
            exchange.IO("mode", 0)
            _C(exchange.SetContractType, "MA888")//订阅MA，只有第一次是真正的发出订阅请求，接下来都是程序切换，不耗时间。
            _C(exchange.SetContractType, "rb888")//订阅rb
            while(True){
                var e = exchange.IO("wait")
                if(e){
                    if(e.event == "tick"){
                        on_tick(e.Symbol)
                    }else if(e.event == "order"){
                        on_order(e.Order)
                    }
                }
           }
        }else{
            Sleep(10*1000)
        }
    }
}