
Между товарными фьючерсами CTP и API цифровой валюты существуют существенные различия. Те, кто знаком с программной торговлей цифровой валютой, но не с программной торговлей товарными фьючерсами, не могут просто скопировать их опыт. В этой статье будут обобщены сходства и различия между ними.
Исторические данные
Интерфейс CTP не предоставляет историческую рыночную информацию, которую необходимо получать через поставщиков рыночной информации. Если рыночные данные утеряны из-за невозможности входа в систему или отключения, CTP не предоставляет механизм восстановления рыночных данных. Исторические рыночные условия можно получить только с помощью сторонних данных. Цифровые валюты обычно предоставляют интерфейсы для получения K-line и истории транзакций.
Разные протоколы
Криптовалютные API обычно представляют собой протоколы REST и websocket. CTP инкапсулирует внутри себя сетевую логику и использует протокол FTD на основе протокола TCP для связи с фоном CTP. Существует три режима:
Все рыночные условия и транзакции ордеров протокола CTP будут уведомляться только после изменений, в то время как запросы по ордерам, счетам и позициям являются активными запросами. Вышеуказанные три режима можно найти в схожих формах в API цифровых валют.
Различные уровни сложности данных
Глубина протокола CTP составляет всего одну покупку и одну продажу, а пятиуровневые рыночные сборы дороги. Цифровые валюты обычно могут получить полную глубину или 200 уровней. CTP не продвигает реальные транзакции и может быть выведена только через изменения позиций, в то время как API обмена цифровой валютой может получать реальные отдельные транзакции. Уровень тиков рыночных данных на отечественной платформе CTP составляет 2 тика в секунду. Большинство веб-сокетов для обмена цифровой валютой могут делать это 10 раз в секунду.
Различные ограничения доступа
Биржи цифровых валют обычно ограничивают количество транзакций до 10 раз в секунду. Обычно никаких специальных требований для отмены заказа не существует. CTP имеет строгие ограничения на запросы, которые необходимо активно выдавать. Как правило, безопаснее делать это раз в 2 секунды. Также есть требования к количеству отмен заказов.
Стабильность
Протокол CTP очень стабилен и практически не имеет ошибок и сетевых проблем. Цифровые валюты должны иметь меньше ограничений и более длительное время транзакций, а техническое обслуживание, задержки данных, сетевые ошибки и т. д. являются весьма распространенными.
Лучшие практики протокола CTP на количественной платформе FMZ
В режиме по умолчанию CTP интерфейсы для получения рыночной информации, такие как GetTicker, GetDepth и GetRecords, могут получать последние данные только при наличии кэшированных данных. Если данных нет, он будет ждать, пока они появятся, поэтому Стратегии не нужен сон. При изменении рынка тикер, глубина и записи будут обновлены. В это время вызов любого из этих интерфейсов немедленно вернет, а статус вызываемого интерфейса будет установлен на режим ожидания обновления. Следующий вызов тот же интерфейс будет ждать, пока не появятся новые данные. return. Некоторые непопулярные контракты или ценовые лимиты не будут торговаться в течение длительного времени. Нормально, если стратегия застрянет на долгое время.
Если вы хотите получать данные каждый раз при получении рынка, даже старые данные, вы можете переключиться в режим обновления рынка exchange.IO(“mode”, 0). На данный момент стратегия не может быть написана как событийно-управляемая. Необходимо добавить событие Sleep, чтобы избежать быстрого бесконечного цикла. Некоторые стратегии с низкой частотой могут использовать этот режим, а конструкция стратегии проста. Используйте exchange.IO(“mode”, 1) для возврата к режиму кэширования по умолчанию.
При работе с одним контрактом используйте режим по умолчанию. Однако при наличии нескольких контрактов возможно, что один контракт не обновил рыночную информацию, что приведет к блокировке интерфейса получения рыночной информации, и обновления рыночной информации по другим контрактам не могут быть получены. Для решения этой проблемы можно использовать режим немедленного обновления, но писать высокочастотные стратегии неудобно. В настоящее время вы можете использовать режим push-уведомлений о событиях для получения push-уведомлений о заказах и рыночной информации. Метод настройки — exchange.IO(“wait”). Если добавлено несколько объектов биржи, что редко встречается в товарных фьючерсах, можно использовать exchange.IO(“wait_any”), и возвращаемый индекс будет указывать на возвращаемый индекс биржи.
Изменение тикового значения рынка push: {Событие:“тик”, Индекс:Индекс биржи (в порядке добавления биржи робота), Нано:Наносекундное время события, Символ:Название контракта} Отправка заказа: {Событие:“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)
}
}
}