상품 선물 CTP와 디지털 통화 API 사이에는 상당한 차이가 있습니다. 디지털 통화 프로그래밍 거래에는 익숙하지만 상품 선물 프로그래밍 거래에는 익숙하지 않은 사람들은 그들의 경험을 그냥 따라할 수 없습니다. 이 글에서는 이들 간의 유사점과 차이점을 요약해보겠습니다.

역사적 데이터

CTP 인터페이스는 시장 정보 제공자를 통해 얻어야 하는 과거 시장 정보를 제공하지 않습니다. 로그인 실패나 접속 끊김으로 인해 시장 데이터가 손실된 경우, CTP는 시장 데이터 복구 메커니즘을 제공하지 않습니다. 역사적 시장 상황은 제3자 데이터를 통해서만 얻을 수 있습니다. 디지털 통화는 일반적으로 K-라인과 거래 내역을 얻기 위한 인터페이스를 제공합니다.

다양한 프로토콜

암호화폐 API는 일반적으로 REST와 웹소켓 프로토콜입니다. CTP는 네트워크 관련 로직을 내부적으로 캡슐화하고 TCP 프로토콜을 기반으로 하는 FTD 프로토콜을 사용하여 CTP 백그라운드와 통신합니다. 세 가지 모드가 있습니다.

• 요청-응답 모드: 클라이언트가 적극적으로 요청을 시작하고 CTP 백엔드가 요청을 수신하고 응답합니다.
• 브로드캐스트 통신 모드: 클라이언트가 계약 시장에 가입한 후 CTP는 브로드캐스트를 통해 시장 정보를 외부로 푸시합니다.
• 비공개 통신 모드: 클라이언트가 계약을 위탁한 후 주문 정보, 거래 반환 등이 CTP를 통해 지점 간으로 푸시됩니다.

CTP 프로토콜의 모든 시장 상황 및 주문 거래는 변경 후에만 공지되며, 주문, 계좌, 포지션에 대한 문의는 활성 문의입니다. 위의 세 가지 모드는 디지털 통화 API에서 비슷한 형태로 발견될 수 있습니다.

다양한 수준의 데이터 정교화

CTP 프로토콜의 깊이는 매수 1회, 매도 1회에 불과하며, 5단계 시장 요금은 비쌉니다. 디지털 통화는 일반적으로 전체 깊이 또는 200단계를 얻을 수 있습니다. CTP는 실제 거래를 푸시하지 않고 포지션의 변화를 통해서만 추론할 수 있는 반면, 디지털 화폐 거래 API는 실제 개별 거래 정보를 얻을 수 있습니다. 국내 CTP플랫폼의 시장데이터 틱레벨은 초당 2틱입니다. 대부분의 디지털 화폐 교환 웹소켓은 초당 10회 처리할 수 있습니다.

다양한 접근 제한

디지털 화폐 거래소에서는 일반적으로 거래 횟수를 초당 10회로 제한합니다. 일반적으로 주문 취소에는 특별한 요구 사항이 없습니다. CTP는 적극적으로 발행해야 하는 요청에 대해 엄격한 제한을 두고 있습니다. 일반적으로 2초마다 한 번씩 하는 것이 더 안전합니다. 주문 취소 횟수에 대한 요구 사항도 있습니다.

안정

CTP 프로토콜은 매우 안정적이며 오류나 네트워크 문제가 거의 없습니다. 디지털 통화는 제한이 적고 거래 시간이 길어야 하며, 유지 관리, 데이터 지연, 네트워크 오류 등이 매우 흔합니다.

FMZ 양적 플랫폼의 CTP 프로토콜 모범 사례

CTP의 기본 모드에서 GetTicker, GetDepth, GetRecords와 같은 시장 정보를 얻기 위한 인터페이스는 캐시된 데이터가 있는 경우에만 최신 데이터를 얻을 수 있습니다. 데이터가 없으면 데이터가 있을 때까지 기다리므로 전략은 잠들 필요가 없습니다. 시장이 변경되면 티커, 깊이 및 레코드가 업데이트됩니다. 이때 이러한 인터페이스를 호출하면 즉시 반환되고 호출된 인터페이스의 상태는 업데이트 대기 모드로 설정됩니다. 다음 호출은 동일한 인터페이스는 새 데이터가 있을 때까지 기다립니다. 반환합니다. 일부 인기 없는 계약이나 가격 한도는 오랫동안 거래되지 않을 것입니다. 전략이 오랫동안 멈춰 있는 것은 정상입니다.

마켓을 가져올 때마다 오래된 데이터라도 데이터를 가져오려면 마켓 업데이트 모드 exchange.IO(“mode”, 0)으로 전환하면 됩니다. 현재 이 전략은 이벤트 구동으로 작성할 수 없습니다. 빠른 무한 루프를 피하기 위해 Sleep 이벤트를 추가해야 합니다. 일부 낮은 빈도의 전략에서 이 모드를 사용할 수 있으며, 전략 설계는 간단합니다. exchange.IO(“mode”, 1)을 사용하여 기본 캐시 모드로 돌아갑니다.

단일 계약을 운영하는 경우 기본 모드를 사용하세요. 하지만 여러 개의 계약이 있는 경우, 하나의 계약이 시장 정보를 업데이트하지 않아 시장 정보 수집 인터페이스가 막혀 다른 계약의 시장 정보 업데이트를 얻지 못하는 경우도 있습니다. 이 문제를 해결하려면 즉시 업데이트 모드를 사용할 수 있지만, 고빈도 전략을 작성하는 것은 불편합니다. 이때, 이벤트 푸시 모드를 사용하면 주문 및 시장 정보 푸시를 받을 수 있습니다. 설정 방법은 exchange.IO(“wait”)입니다. 상품 선물 거래에서는 흔치 않은 일이지만, 여러 개의 거래소 객체가 추가되면 exchange.IO(“wait_any”)를 사용할 수 있으며, 반환되는 Index는 반환된 거래소 인덱스를 나타냅니다.

시장 틱 변화 푸시: {이벤트:“틱”, 인덱스:거래소 인덱스(로봇 거래소가 추가된 순서대로), 나노:이벤트의 나노초 시간, 심볼:계약 이름} 주문 푸시: {이벤트:“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)
        }
    }
}