Diferencias entre las API de los futuros de productos y las de los intercambios de divisas digitales

Los CTP de futuros de mercancías y las API de monedas digitales tienen diferencias significativas, y la experiencia de copiar no es sencilla para aquellos que están familiarizados con la transacción programada de monedas digitales y no para aquellos que están familiarizados con la transacción programada de futuros de mercancías.

Datos históricos

Las interfaces de CTP no ofrecen mercados históricos, los cuales deben resolverse a través de los operadores. Si no se accede o la interrupción de la llegada causa la pérdida de datos de mercado, CTP no ofrece un mecanismo de recuperación de mercados. Los mercados históricos solo se pueden obtener a través de datos de terceros.

Los acuerdos son diferentes

Las APIs de las monedas digitales son generalmente REST y protocolo websocket, el CTP envuelve dentro de sí la lógica relacionada con la red, y utiliza el protocolo FTD basado en el protocolo TCP para comunicarse con el fondo del CTP.

• Modo de respuesta a la solicitud: el cliente inicia la solicitud, el fondo CTP recibe y responde a la solicitud
• Modelo de comunicación por radio: después de que el cliente suscribe el contrato, el CTP emite información por radio.
• Modelo de comunicación privada: después de que el cliente realiza operaciones como el encargo de un contrato, la información de facturación, la devolución de transacciones, etc. se impulsan de punto en punto por el CTP.

Todos los mercados y transacciones de pedidos del protocolo CTP se notifican solo después de un cambio, mientras que las consultas de pedidos, cuentas y tenencias son consultas activas. Los tres modelos anteriores se encuentran en una forma similar en la API de moneda digital.

La precisión de los datos varía.

La profundidad del protocolo de CTP es de una compra y una venta, las tarifas de cinco fichas son caras, y las monedas digitales generalmente pueden obtener una profundidad completa o 200 fichas. El CTP no impulsa transacciones reales, solo puede retrocedérse mediante el cambio de tenencia, mientras que las API de los intercambios de monedas digitales pueden obtener transacciones reales.

Las restricciones de acceso son diferentes

Los intercambios de divisas digitales generalmente limitan 1 a 10 veces por segundo. No hay requisitos especiales para la mayoría de los retiros de pedidos. El CTP tiene un límite estricto para las solicitudes que requieren una petición hecha de forma proactiva, generalmente 2 s es más seguro, también hay requisitos para el número de retiros.

Estabilidad

El protocolo CTP es muy estable y casi no presenta errores y problemas de red. Las monedas digitales deben tener menos restricciones, tener un tiempo de transacción largo, y son comunes en situaciones de mantenimiento, retraso de datos, errores de red, etc.

Las mejores prácticas del protocolo CTP

Las interfaces de acceso a transacciones de modo predeterminado de CTP, como GetTicker, GetDepth y GetRecords, tienen datos almacenados en caché para obtener los datos más recientes, por lo que la política puede no utilizar Sleep. Cuando hay cambios en el sector, los tickers, profundidades y registros se actualizan, y cuando se llama a cualquier interfaz, se devuelve inmediatamente, el estado de la interfaz que se ha llamado se pone en modo de espera de actualización, y la próxima llamada a la misma interfaz, se espera hasta que se devuelvan nuevos datos.

Si quieres acceder a los datos de cada transacción, incluso los datos antiguos, puedes cambiar a un modo de actualización instantánea de mercados.exchange.IO("mode", 0) ; en este momento, la política no puede escribirse como un evento impulsado, se requiere agregar un evento Sleep, para evitar un ciclo muerto rápido. Algunas políticas de baja frecuencia pueden usar este modelo, y la política es sencilla de diseño.使用exchange.IO("mode", 1) puede cambiar el modo de caché por defecto.

Cuando se opera un solo contrato, se puede usar el modo predeterminado; pero si son varios contratos, es posible que un contrato no tenga una actualización de mercado, lo que causa un bloqueo en la interfaz de mercado y no se puede obtener la actualización de mercado de otros contratos. Para resolver este problema, se puede usar el modo de actualización inmediata, pero no es conveniente escribir una política de alta frecuencia.设置方式为exchange.IO("wait") ─ Si se añaden varios objetos de intercambio, lo cual es raro en futuros de productos, puede ser necesario esperar hasta que se haya completado la transacción.可以使用exchange.IO("wait_any"), el índice devuelto indica el índice de intercambio devuelto.

El cambio de tick de transacción se empuja: {Event: tick tick, Index: index de la bolsa (se agrega en orden por el robot de la bolsa), Nano: tiempo en nanosegundos del evento, Symbol: nombre del contrato} Pulsado de órdenes: {Event:order, Index: índice de la bolsa, Nano: tiempo en nanosegundos del evento, Order: información de la orden ((coincide con GetOrder) }

La estructura de la estrategia en este momento 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)
        }
    }
}