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 obter dados de cada transação, mesmo os dados antigos, você pode mudar para o modo de atualização imediata do mercado exchange.IO (modo de download, 0). Nesta altura, a política não pode ser escrita como um evento, sendo necessário adicionar um evento SLeep, evitando um ciclo morto rápido. Algumas políticas de baixa frequência podem usar esse modo, uma estratégia projetada para ser simples de usar.Exchange.IO (modo de download, 1) pode ser cortada para o modo de cache padrão.

O modo padrão pode ser usado para operar um único contrato; mas se for um conjunto de contratos, é possível que um contrato não atualize o mercado, o que causa o bloqueio da interface de mercado e não é possível obter atualizações de outros contratos. Para resolver este problema, é possível usar o modo de atualização imediata, mas não é conveniente escrever uma estratégia de alta frequência. Neste caso, o modo de push de eventos pode ser usado para obter ordens e movimentos.

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)
        }
    }
}