Diferenças entre as APIs de commodity futures e de exchanges de moeda digital

O CTP de futuros de commodities e a API de moeda digital têm diferenças significativas, que não podem ser simplesmente copiadas por quem está familiarizado com transações programadas de moeda digital e não com a experiência programada de futuros de commodities.

Dados históricos

A interface do CTP não fornece mercados históricos, os quais precisam ser resolvidos através de negociantes. CTP não oferece um mecanismo de recuperação de mercados se o desembarque ou a interrupção do desembarque causar a perda de dados de mercado. Os mercados históricos só podem ser obtidos através de dados de terceiros.

O acordo é diferente.

A API da moeda digital é geralmente REST e protocolo websocket, o CTP envolve a lógica da rede e usa o protocolo FTD baseado no protocolo TCP para se comunicar com o CTP em segundo plano.

• Modo de resposta de solicitação: o cliente inicia a solicitação, o CTP em segundo plano recebe e responde à solicitação
• Modelo de comunicação de rádio: Após o cliente assinar um contrato de mercado, o CTP envia informações de mercado via rádio.
• Modelo de comunicação privada: Após o cliente encomendar um contrato, as informações sobre o pedido, o retorno da transação, etc., são empurradas de ponto em ponto pelo CTP.

Todos os mercados e transações de pedidos do protocolo CTP são notificados somente após a mudança, enquanto pedidos de consulta, contas e detenções são consultas ativas. Os três modelos acima podem ser encontrados em uma forma semelhante na API de moeda digital.

A precisão dos dados varia.

A profundidade do protocolo CTP é de apenas um compra-venda, e as taxas de transação são caras. A moeda digital geralmente é acessível em toda a profundidade ou em 200 arquivos. O CTP não impulsiona transações reais e só pode ser retroalimentado por mudanças de estoque, enquanto a API do exchange de moeda digital obtém transações reais.

Restrições de acesso diferentes

As trocas de moeda digital geralmente limitam 1 segundo a 10 vezes. Não há requisitos especiais para a maioria dos pedidos de cancelamento. O CTP limita severamente os pedidos que precisam ser feitos de forma proativa, geralmente 2s uma vez é mais seguro, também há requisitos para o número de cancelamentos.

Estabilidade

O protocolo CTP é muito estável e quase não apresenta erros e problemas de rede. A moeda digital deve ser menos restrita, o tempo de transação é longo, a manutenção, o atraso de dados, os erros de rede são comuns.

Melhores práticas do protocolo CTP

O modo padrão do CTP é obter transações através de interfaces como GetTicker, GetDepth e GetRecords, que possuem dados em cache para obter os dados mais recentes. A estratégia pode ser desativada se não houver dados. Quando as transações mudam, os tickers, profundidades e registros são atualizados.

Se você quiser ter acesso a cada transação, mesmo os dados antigos, você pode mudar para o modo de atualização instantânea do mercado.exchange.IO("mode", 0) ; a política não pode ser escrita como um evento-driven, e é necessário adicionar um evento Sleep, evitando um ciclo morto rápido. Algumas políticas de baixa frequência podem usar esse modo, sendo o design da política simples.使用exchange.IO("mode", 1) pode mudar para o modo de cache padrão.

Quando se opera um único contrato, o modo padrão pode ser usado; mas se for um conjunto de contratos, é possível que um contrato não tenha uma atualização de mercado, o que pode causar bloqueio na interface de mercado e outras atualizações de mercado não podem ser obtidas. Para resolver este problema, pode-se usar o modo de atualização imediata, mas não é conveniente escrever uma estratégia de alta frequência.设置方式为exchange.IO("wait") ─ Se forem adicionados vários objetos de bolsa, o que é raro em futuros de commodities, você pode esperar até que o objeto seja adicionado.可以使用exchange.IO("wait_any"), o índice retornado indica o índice da bolsa retornado.

Mudanças de transações em tick push: {Event: tick tick, Index: index de bolsa de valores (apresentado em ordem por bolsa robótica), Nano: tempo de eventos em nanossegundos, Symbol: nome do contrato} Pushes de ordens: {Event: order, Index: índice de bolsa, Nano: tempo em nanossegundos do evento, Order: informação de ordem ((coincide com GetOrder) }

A estrutura estratégica pode ser escrita 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)
        }
    }
}