Il existe des différences significatives entre le CTP des contrats à terme sur matières premières et l’API des devises numériques. Ceux qui sont familiers avec le trading programmatique de devises numériques, mais pas avec le trading programmatique des contrats à terme sur matières premières, ne peuvent pas simplement copier leur expérience. Cet article résumera les similitudes et les différences entre eux.

Données historiques

L’interface CTP ne fournit pas d’informations historiques sur le marché, qui doivent être obtenues auprès de fournisseurs d’informations sur le marché. Si les données de marché sont perdues en raison d’un échec de connexion ou d’une déconnexion, CTP ne fournit pas de mécanisme de récupération des données de marché. Les conditions historiques du marché ne peuvent être obtenues qu’à partir de données provenant de tiers. Les monnaies numériques fournissent généralement des interfaces permettant d’obtenir l’historique des K-lines et des transactions.

Différents protocoles

Les API de crypto-monnaie sont généralement des protocoles REST et WebSocket. CTP encapsule la logique liée au réseau en interne et utilise le protocole FTD basé sur le protocole TCP pour communiquer avec l’arrière-plan CTP. Il existe trois modes :

• Mode requête-réponse : le client lance activement une requête, et le backend CTP reçoit et répond à la requête
• Mode de communication par diffusion : après que le client a souscrit au marché contractuel, le CTP transmet les informations du marché à l’extérieur par diffusion.
• Mode de communication privé : Après que le client a confié un contrat, les informations de commande, le retour de transaction, etc. sont transmises de point à point par CTP.

Toutes les conditions du marché et les transactions d’ordre du protocole CTP ne seront notifiées qu’après les changements, tandis que les demandes de renseignements sur les ordres, les comptes et les positions sont des demandes actives. Les trois modes ci-dessus peuvent être trouvés sous des formes similaires dans les API de monnaie numérique.

Différents niveaux de sophistication des données

La profondeur du protocole CTP n’est que d’un achat et d’une vente, et les frais de marché à cinq niveaux sont élevés. Les monnaies numériques peuvent généralement atteindre une profondeur totale ou 200 niveaux. Le CTP ne génère pas de transactions réelles et ne peut être déduit que par des changements de positions, tandis que l’API d’échange de devises numériques peut obtenir des transactions individuelles réelles. Le niveau de tick des données de marché sur la plateforme CTP nationale est de 2 ticks par seconde. La plupart des Websockets d’échange de devises numériques peuvent le faire 10 fois par seconde.

Différentes restrictions d’accès

Les échanges de devises numériques limitent généralement les transactions à 10 fois par seconde. Il n’y a généralement pas d’exigences particulières pour l’annulation d’une commande. Le CTP impose des restrictions strictes sur les demandes qui doivent être émises activement. En général, il est plus sûr de le faire une fois toutes les 2 secondes. Il existe également des exigences concernant le nombre d’annulations de commandes.

Stabilité

Le protocole CTP est très stable et presque exempt d’erreurs et de problèmes de réseau. Les monnaies numériques devraient avoir moins de restrictions et des délais de transaction plus longs, et la maintenance, les retards de données, les erreurs de réseau, etc. sont très courants.

Bonnes pratiques du protocole CTP sur la plateforme quantitative FMZ

Dans le mode par défaut de CTP, les interfaces permettant d’obtenir des informations sur le marché, telles que GetTicker, GetDepth et GetRecords, ne peuvent obtenir les données les plus récentes que s’il existe des données en cache. S’il n’y a pas de données, elles attendent qu’il y en ait. la stratégie n’a pas besoin de dormir. En cas de changement de marché, le ticker, la profondeur et les enregistrements seront mis à jour. À ce moment, l’appel de l’une de ces interfaces sera immédiatement renvoyé et le statut de l’interface appelée sera défini sur le mode d’attente de mise à jour. Le prochain appel à la même interface attendra que de nouvelles données soient disponibles. Certains contrats ou limites de prix impopulaires ne seront pas négociés pendant une longue période. Il est normal que la stratégie soit bloquée pendant une longue période.

Si vous souhaitez obtenir des données à chaque fois que vous accédez au marché, même des données anciennes, vous pouvez passer au mode de mise à jour du marché exchange.IO(“mode”, 0). À l’heure actuelle, la stratégie ne peut pas être écrite comme pilotée par les événements. Un événement Sleep doit être ajouté pour éviter une boucle infinie rapide. Certaines stratégies à faible fréquence peuvent utiliser ce mode, et la conception de la stratégie est simple. Utilisez exchange.IO(“mode”, 1) pour revenir au mode de cache par défaut.

Lorsque vous utilisez un contrat unique, utilisez le mode par défaut. Cependant, s’il existe plusieurs contrats, il est possible qu’un contrat n’ait pas mis à jour les informations de marché, ce qui entraîne un blocage de l’interface d’acquisition des informations de marché, et les mises à jour des informations de marché des autres contrats ne peuvent pas être obtenues. Pour résoudre ce problème, vous pouvez utiliser le mode de mise à jour immédiate, mais il n’est pas pratique d’écrire des stratégies à haute fréquence. À ce stade, vous pouvez utiliser le mode push d’événement pour obtenir des informations sur les commandes et le marché. La méthode de configuration est exchange.IO(“wait”). Si plusieurs objets d’échange sont ajoutés, ce qui est rare dans les contrats à terme sur matières premières, vous pouvez utiliser exchange.IO(“wait_any”), et l’index renvoyé indiquera l’indice d’échange renvoyé.

Changement de tick du marché : {Événement : « tick », Index : Indice d’échange (dans l’ordre dans lequel l’échange du robot est ajouté), Nano : Heure de l’événement en nanosecondes, Symbole : Nom du contrat} Commande push : {Événement : « commande », Index : Index d’échange, Nano : Durée de l’événement en nanosecondes, Commande : Informations sur la commande (identiques à GetOrder)}

À ce stade, la structure de la stratégie peut être écrite comme suit :

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