Es gibt erhebliche Unterschiede zwischen dem CTP für Rohstoff-Futures und der API für digitale Währungen. Wer mit dem programmatischen Handel digitaler Währungen vertraut ist, aber nicht mit dem programmatischen Handel von Rohstoff-Futures, kann deren Erfahrung nicht einfach kopieren. Dieser Beitrag fasst die Ähnlichkeiten und Unterschiede zwischen ihnen zusammen.

Historische Daten

Die CTP-Schnittstelle stellt keine historischen Marktinformationen bereit. Diese müssen über Marktinformationsanbieter bezogen werden. Wenn die Marktdaten aufgrund eines Anmeldefehlers oder einer Verbindungsunterbrechung verloren gehen, stellt CTP keinen Mechanismus zur Wiederherstellung der Marktdaten bereit. Historische Marktbedingungen können nur über Daten von Drittanbietern abgerufen werden. Digitale Währungen bieten normalerweise Schnittstellen zum Abrufen der K-Linie und des Transaktionsverlaufs.

Verschiedene Protokolle

Kryptowährungs-APIs sind im Allgemeinen REST- und WebSocket-Protokolle. CTP kapselt netzwerkbezogene Logik intern und verwendet das auf dem TCP-Protokoll basierende FTD-Protokoll, um mit dem CTP-Hintergrund zu kommunizieren. Es gibt drei Modi:

• Anforderungs-Antwort-Modus: Der Client initiiert aktiv eine Anforderung, und das CTP-Backend empfängt und antwortet auf die Anforderung.
• Broadcast-Kommunikationsmodus: Nachdem der Client den Vertragsmarkt abonniert hat, überträgt CTP die Marktinformationen per Broadcast nach außen.
• Privater Kommunikationsmodus: Nachdem der Kunde einen Vertrag unterzeichnet hat, werden die Bestellinformationen, Transaktionsrückmeldungen usw. von CTP direkt an andere übermittelt.

Über sämtliche Marktzustände und Ordertransaktionen des CTP-Protokolls wird nur bei Änderungen informiert, während Anfragen zu Orders, Konten und Positionen aktive Anfragen sind. Die oben genannten drei Modi sind in ähnlicher Form in APIs für digitale Währungen zu finden.

Verschiedene Ebenen der Datenkomplexität

Die Tiefe des CTP-Protokolls beträgt nur einen Kauf und einen Verkauf, und die Marktgebühren auf fünf Ebenen sind teuer. Digitale Währungen können im Allgemeinen die volle Tiefe oder 200 Ebenen erreichen. CTP leitet keine realen Transaktionen weiter und kann nur durch Positionsänderungen abgeleitet werden, während die API für den digitalen Währungsaustausch reale Einzeltransaktionen abrufen kann. Das Tick-Level der Marktdaten auf der inländischen CTP-Plattform beträgt 2 Ticks pro Sekunde. Die meisten WebSockets für den digitalen Währungsumtausch schaffen 10 Umsätze pro Sekunde.

Unterschiedliche Zugriffsbeschränkungen

Digitale Währungsbörsen begrenzen Transaktionen im Allgemeinen auf 10 Mal pro Sekunde. Für die Stornierung einer Bestellung sind in der Regel keine besonderen Voraussetzungen erforderlich. CTP hat strenge Beschränkungen für Anfragen, die aktiv gestellt werden müssen. Im Allgemeinen ist es sicherer, dies alle 2 Sekunden zu tun. Es gibt auch Anforderungen für die Anzahl der Auftragsstornierungen.

Stabilität

Das CTP-Protokoll ist sehr stabil und nahezu frei von Fehlern und Netzwerkproblemen. Digitale Währungen sollten weniger Einschränkungen und längere Transaktionszeiten haben, und Wartungsarbeiten, Datenverzögerungen, Netzwerkfehler usw. kommen sehr häufig vor.

Best Practices des CTP-Protokolls auf der FMZ Quantitative Platform

Im Standardmodus von CTP können Schnittstellen zum Abrufen von Marktinformationen wie GetTicker, GetDepth und GetRecords die neuesten Daten nur abrufen, wenn zwischengespeicherte Daten vorhanden sind. Wenn keine Daten vorhanden sind, wird gewartet, bis Daten vorhanden sind. Strategie muss nicht schlafen. Bei einer Marktänderung werden Ticker, Tiefe und Datensätze aktualisiert. Zu diesem Zeitpunkt wird der Aufruf einer dieser Schnittstellen sofort zurückgegeben und der Status der aufgerufenen Schnittstelle wird auf „Warten auf Aktualisierungsmodus“ gesetzt. Der nächste Aufruf von Die gleiche Schnittstelle wartet, bis neue Daten verfügbar sind. Zurück. Einige unpopuläre Verträge oder Preislimits werden lange Zeit nicht gehandelt. Es ist normal, dass die Strategie lange Zeit feststeckt.

Wenn Sie bei jedem Marktabruf Daten abrufen möchten, auch alte Daten, können Sie in den Marktaktualisierungsmodus exchange.IO(“mode”, 0) wechseln. Derzeit kann die Strategie nicht ereignisgesteuert geschrieben werden. Um eine schnelle Endlosschleife zu vermeiden, muss ein Sleep-Ereignis hinzugefügt werden. Einige Strategien mit niedriger Frequenz können diesen Modus verwenden und das Strategiedesign ist einfach. Verwenden Sie exchange.IO(“mode”, 1), um zum Standard-Cache-Modus zurückzukehren.

Verwenden Sie beim Betrieb eines einzelnen Vertrags den Standardmodus. Wenn jedoch mehrere Verträge vorhanden sind, ist es möglich, dass bei einem Vertrag die Marktinformationen nicht aktualisiert wurden, was zu einer Blockierung der Schnittstelle zum Abrufen von Marktinformationen führt und die Marktinformationsaktualisierungen anderer Verträge nicht abgerufen werden können. Um dieses Problem zu lösen, können Sie den sofortigen Aktualisierungsmodus verwenden, aber das Schreiben von Hochfrequenzstrategien ist unpraktisch. Derzeit können Sie den Event-Push-Modus nutzen, um Push-Aufträge und Marktinformationen abzurufen. Die Einstellungsmethode ist exchange.IO(“wait”). Wenn mehrere Austauschobjekte hinzugefügt werden, was bei Rohstoff-Futures selten vorkommt, können Sie exchange.IO(“wait_any”) verwenden. Der zurückgegebene Index gibt den zurückgegebenen Austauschindex an.

Market Tick Change Push: {Ereignis:“Tick”, Index:Börsenindex (in der Reihenfolge, in der die Roboterbörse hinzugefügt wird), Nano:Nanosekundenzeit des Ereignisses, Symbol:Vertragsname} Order Push: {Event:“order”, Index:Börsenindex, Nano:Ereignis-Nanosekundenzeit, Order:Bestellinformationen (dasselbe wie GetOrder)}

An diesem Punkt kann die Strategiestruktur wie folgt geschrieben werden:

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