
Existen diferencias significativas entre el CTP de futuros de materias primas y la API de moneda digital. Quienes están familiarizados con el comercio programático de moneda digital pero no con el comercio programático de futuros de materias primas no pueden simplemente copiar su experiencia. En este post resumiremos las similitudes y diferencias entre ellos.
Datos históricos
La interfaz CTP no proporciona información histórica del mercado, que debe obtenerse a través de proveedores de información del mercado. Si los datos del mercado se pierden debido a una falla al iniciar sesión o una desconexión, CTP no proporciona un mecanismo de recuperación de datos del mercado. Las condiciones históricas del mercado solo se pueden obtener a través de datos de terceros. Las monedas digitales suelen proporcionar interfaces para obtener la línea K y el historial de transacciones.
Diferentes protocolos
Las API de criptomonedas son generalmente protocolos REST y websocket. CTP encapsula internamente la lógica relacionada con la red y utiliza el protocolo FTD basado en el protocolo TCP para comunicarse con el entorno CTP. Hay tres modos:
Todas las condiciones del mercado y las transacciones de órdenes del protocolo CTP se notificarán solo después de los cambios, mientras que las consultas sobre órdenes, cuentas y posiciones son consultas activas. Los tres modos anteriores se pueden encontrar en formas similares en las API de moneda digital.
Diferentes niveles de sofisticación de datos
La profundidad del protocolo CTP es de solo una compra y una venta, y los cargos por mercado de cinco niveles son costosos. Las monedas digitales generalmente pueden alcanzar una profundidad total o 200 niveles. CTP no impulsa transacciones reales y solo se puede inferir a través de cambios en posiciones, mientras que la API de intercambio de moneda digital puede obtener transacciones individuales reales. El nivel de ticks de los datos del mercado en la plataforma CTP nacional es de 2 ticks por segundo. La mayoría de los websockets de intercambio de moneda digital pueden hacerlo 10 veces por segundo.
Diferentes restricciones de acceso
Los intercambios de monedas digitales generalmente limitan las transacciones a 10 veces por segundo. Por lo general no existen requisitos especiales para la cancelación de pedidos. El CTP tiene restricciones estrictas sobre las solicitudes que deben emitirse de forma activa. Por lo general, es más seguro hacerlo una vez cada dos segundos. También existen requisitos para la cantidad de cancelaciones de pedidos.
Estabilidad
El protocolo CTP es muy estable y casi libre de errores y problemas de red. Las monedas digitales deberían tener menos restricciones y tiempos de transacción más largos, y el mantenimiento, los retrasos en los datos, los errores de red, etc. son muy comunes.
Mejores prácticas del protocolo CTP en la plataforma cuantitativa FMZ
En el modo predeterminado de CTP, las interfaces para obtener información de mercado, como GetTicker, GetDepth y GetRecords, solo pueden obtener los datos más recientes si hay datos almacenados en caché. Si no hay datos, esperará hasta que los haya, por lo que el La estrategia no necesita dormir. Cuando se produce un cambio en el mercado, se actualizarán el ticker, la profundidad y los registros. En este momento, al llamar a cualquiera de estas interfaces, se retornará de inmediato y el estado de la interfaz llamada se establecerá en modo de espera de actualización. La siguiente llamada a La misma interfaz esperará hasta que haya nuevos datos disponibles. Algunos contratos impopulares o límites de precio no se negociarán durante mucho tiempo. Es normal que la estrategia se quede estancada durante mucho tiempo.
Si desea obtener datos cada vez que ingresa al mercado, incluso datos antiguos, puede cambiar al modo de actualización del mercado exchange.IO(“mode”, 0). En este momento, la estrategia no se puede escribir como impulsada por eventos. Se debe agregar un evento de suspensión para evitar un bucle infinito rápido. Algunas estrategias con baja frecuencia pueden utilizar este modo y el diseño de la estrategia es simple. Utilice exchange.IO(“mode”, 1) para volver al modo de caché predeterminado.
Al operar un solo contrato, utilice el modo predeterminado. Sin embargo, si hay varios contratos, es posible que un contrato no haya actualizado la información del mercado, lo que genera un bloqueo en la interfaz de adquisición de información del mercado y no se pueden obtener las actualizaciones de información del mercado de otros contratos. Para resolver este problema, puede utilizar el modo de actualización inmediata, pero resulta inconveniente escribir estrategias de alta frecuencia. En este momento, puede utilizar el modo push de eventos para recibir información de pedidos y del mercado. El método de configuración es exchange.IO(“wait”). Si se agregan varios objetos de intercambio, lo cual es poco común en futuros de materias primas, puede usar exchange.IO(“wait_any”) y el índice devuelto indicará el índice de intercambio devuelto.
Cambio de tick del mercado: {Evento: “tick”, Índice: Índice de intercambio (en el orden en el que se agrega el intercambio del robot), Nano: Tiempo en nanosegundos del evento, Símbolo: Nombre del contrato} Orden push: {Evento:“order”, Índice:Índice de intercambio, Nano:Tiempo de nanosegundo del evento, Orden:Información de la orden (igual que GetOrder)}
En este punto la estructura de la estrategia se puede escribir como:
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)
}
}
}