
商品先物 CTP とデジタル通貨 API には大きな違いがあります。デジタル通貨のプログラム取引には精通しているが、商品先物プログラム取引には精通していない人は、その経験をそのままコピーすることはできません。この投稿では、それらの類似点と相違点をまとめます。
履歴データ
CTP インターフェイスでは過去の市場情報は提供されないため、市場情報プロバイダーを通じて取得する必要があります。ログインの失敗や切断により市場データが失われた場合、CTP は市場回復メカニズムを提供しません。過去の市場状況は、サードパーティのデータを通じてのみ取得できます。デジタル通貨は通常、K ラインと取引履歴を取得するためのインターフェースを提供します。
異なるプロトコル
暗号通貨 API は、一般的に REST および Websocket プロトコルです。CTP はネットワーク関連のロジックを内部的にカプセル化し、TCP プロトコルに基づく FTD プロトコルを使用して CTP バックグラウンドと通信します。モードは3つあります:
CTP プロトコルのすべての市場状況と注文取引は変更後にのみ通知されますが、注文、アカウント、ポジションに関する問い合わせはアクティブな問い合わせです。上記の 3 つのモードは、デジタル通貨 API でも同様の形式で見つかります。
データの高度化のレベルの違い
CTP プロトコルの深さは、買いと売りがそれぞれ 1 つだけであり、5 レベルの市場料金は高額です。デジタル通貨は通常、完全な深さまたは 200 レベルを取得できます。 CTP は実際のトランザクションをプッシュせず、ポジションの変化を通じてのみ推測できますが、デジタル通貨交換 API は実際の個々のトランザクションを取得できます。国内CTPプラットフォーム上のマーケットデータのティックレベルは1秒あたり2ティックです。ほとんどのデジタル通貨交換 Web ソケットは 1 秒あたり 10 回実行できます。
異なるアクセス制限
デジタル通貨取引所では通常、取引回数を 1 秒あたり 10 回に制限しています。通常、注文のキャンセルには特別な要件はありません。 CTP では、能動的に発行する必要のあるリクエストに厳しい制限があります。一般的には、2 秒に 1 回行う方が安全です。また、注文キャンセルの回数にも要件があります。
安定性
CTP プロトコルは非常に安定しており、エラーやネットワークの問題はほとんどありません。デジタル通貨には制限が少なく、取引時間が長く、メンテナンス、データの遅延、ネットワーク エラーなどが非常によく発生します。
FMZ 定量プラットフォームにおける CTP プロトコルのベスト プラクティス
CTPのデフォルトモードでは、GetTicker、GetDepth、GetRecordsなどのマーケット情報を取得するためのインターフェースは、キャッシュされたデータがある場合のみ最新のデータを取得できます。データがない場合、データがあるまで待機するため、戦略は眠る必要はありません。市場の変化があると、ティッカー、深度、レコードが更新されます。このとき、これらのインターフェースのいずれかを呼び出すとすぐに戻り、呼び出されたインターフェースのステータスは更新モード待ちに設定されます。次の呼び出しは同じインターフェースは、新しいデータが利用可能になるまで待機します。戻ります。人気のない契約や価格制限は、長期間取引されません。戦略が長期間にわたって行き詰まるのは普通のことです。
マーケットを取得するたびに、古いデータであってもデータを取得したい場合は、マーケット更新モード exchange.IO(“mode”, 0) に切り替えることができます。現時点では、この戦略をイベント駆動型として記述することはできません。高速な無限ループを回避するには、Sleep イベントを追加する必要があります。頻度の低い一部の戦略ではこのモードを使用でき、戦略設計はシンプルです。デフォルトのキャッシュ モードに戻すには、exchange.IO(“mode”, 1) を使用します。
単一の契約を操作する場合は、デフォルト モードを使用します。ただし、複数の契約がある場合、1 つの契約が相場情報を更新していないために相場情報取得インターフェースがブロックされ、他の契約の相場情報の更新を取得できない可能性があります。この問題を解決するには、即時更新モードを使用できますが、高頻度の戦略を記述するのは不便です。このとき、イベント プッシュ モードを使用して、注文と市場情報のプッシュを取得できます。設定方法はexchange.IO(“wait”)です。複数の取引所オブジェクトが追加される場合は、商品先物ではまれですが、exchange.IO(“wait_any”) を使用でき、返される Index は返された取引所インデックスを示します。
マーケットティック変更プッシュ: {イベント:「ティック」、インデックス:取引所インデックス (ロボット取引所が追加された順序)、Nano:イベントのナノ秒時間、シンボル:契約名} 注文プッシュ: {Event:“order”、Index:Exchange インデックス、Nano:イベントのナノ秒時間、Order:注文情報 (GetOrder と同じ)}
この時点で、戦略構造は次のように記述できます。
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)
}
}
}