상품 선물과 디지털 통화 거래소 API의 차이

상품 선물 CTP와 디지털 화폐 API는 상당한 차이를 가지고 있으며, 디지털 화폐의 프로그래밍 거래에 익숙하지 않은 상품 선물 프로그래밍에 익숙하지 않은 사람들은 간단한 복제 경험을 할 수 없습니다. 이 게시물은 두 가지 차이점을 요약합니다.

역사적 자료

CTP 인터페이스는 역사적 시장을 제공하지 않으며, 역사적 시장을 거래자가 해결해야 한다. 착륙하지 않거나 착륙 중단으로 인해 시장 데이터가 손실되는 경우 CTP는 거래 상환 메커니즘을 제공하지 않는다.

다른 계약

디지털 화폐 API는 일반적으로 REST 및 웹소켓 프로토콜이며, CTP는 네트워크 관련 논리를 내부로 포괄하여 TCP 프로토콜에 기반한 FTD 프로토콜을 사용하여 CTP 백그라운드와 통신합니다. 세 가지 모드로 나니다:

• 요청 응답 모드: 클라이언트가 요청을 주도적으로 시작하고 CTP 백그라운드가 요청을 수신하고 응답합니다.
• 라디오 통신 모드: 클라이언트가 계약에 가입 한 후 CTP는 라디오를 통해 시장 정보를 외부로 밀어냅니다.
• 개인 통신 모드: 클라이언트가 어떤 계약에 대한 임무를 수행 한 후, 청구서 정보, 거래 반환 등은 CTP에서 점 점으로 추진됩니다.

CTP 프로토콜의 모든 거래 및 주문 거래는 변경된 후에야 알립니다. 주문, 계정, 보유를 검색하는 것은 적극적인 검색입니다. 위의 세 가지 모형은 디지털 통화 API에서 유사한 형태를 찾을 수 있습니다.

데이터의 정밀도는 다릅니다.

CTP 프로토콜의 깊이는 한 번 구매 한 번 판매 한 번, 5 개의 거래소 수수료가 비싸다. 디지털 화폐는 일반적으로 전체 깊이 또는 200 파일에 액세스 할 수 있습니다. CTP는 실제 거래를 추진하지 않으며 보유 변경으로만 반사 할 수 있으며 디지털 화폐 거래소 API는 실제 분담 거래를 얻을 수 있습니다. 국내 CTP 플랫폼의 거래 데이터 틱 레벨은 1 초 2 틱입니다. 디지털 화폐 거래소 웹 소켓은 최대 1 초 10 번 할 수 있습니다.

다른 접근 제한

디지털 화폐 거래소는 일반적으로 1초 10회로 제한한다. 대부분의 주문 철회에는 특별한 요구 사항이 없습니다. CTP는 직접적으로 발송해야하는 요청에 엄격한 제한을하고, 일반적으로 2s 한 번은 비교적 안전하며, 철회 수에도 요구 사항이 있습니다.

안정성

CTP 프로토콜은 매우 안정적이며 오류와 네트워크 문제가 거의 없습니다. 디지털 화폐는 제한이 적고 거래 시간이 길고 유지 보수, 데이터 지연, 네트워크 오류가 일반적입니다.

FMZ 양자화 플랫폼 CTP 프로토콜 최선 사례

CTP 기본 모드 취득 시장을 위한 인터페이스들 (GetTicker, GetDepth, GetRecords) 은 모두 최신 데이터를 얻기 위해 캐시된 데이터를 가지고 있으며, 데이터가 없을 때 데이터가 있을 때까지 계속 기다립니다. 따라서 정책은 Sleep를 사용하지 않습니다. 시장을 변경할 때, ticker, depth, records 모두 업데이트됩니다. 이 때 호출된 임의의 인터페이스가 즉시 반환됩니다. 호출된 인터페이스 상태는 업데이트를 기다리는 모드로 설정되며, 다음 호출에서 동일한 인터페이스가 새로운 데이터가 돌아올 때까지 기다립니다. 또는 냉문 계약이 중단되는 경우 오랫동안 거래되지 않는 경우가 발생할 수 있습니다.

만약 여러분이 매번 시장에 대한 데이터를 얻고 싶다면, 심지어 오래된 데이터라도 시장의 즉각적인 업데이트 모드로 전환할 수 있습니다.exchange.IO("mode", 0) ᅳ 이 때 정책은 이벤트로 작성될 수 없으며, 빠른 사순환을 피하기 위해 SLEEP 이벤트를 추가해야 한다. 일부 낮은 빈도의 정책은 이 패턴을 사용할 수 있으며, 정책 설계는 간단하다.使用exchange.IO("mode", 1) 는 기본 캐시 모드로 되돌릴 수 있습니다.

단일 계약을 조작할 때 기본 모드를 사용할 수도 있다. 그러나 여러 계약이 있는 경우, 하나의 계약이 시장을 업데이트하지 않아 시장을 접근하는 인터페이스가 막히고 다른 계약의 시장을 업데이트할 수 없게 될 수도 있다. 이 문제를 해결하기 위해, 즉각적인 업데이트 모드를 사용할 수 있지만, 높은 주파수 전략을 작성하는 것이 쉽지 않다. 이 경우 이벤트 푸시 모드를 사용하여 주문과 시장을 접근할 수 있다.设置方式为exchange.IO("wait") ᅳ다양한 거래소 객체를 추가하면, 이것은 상품 선물에서 드문 일이지만,可以使用exchange.IO이 때 반환된 인덱스는 반환된 거래소 인덱스를 나타냅니다.

트랜잭션 틱 변경 푸싱: {Event: tick, Index: 거래소 인덱스 ((로봇 거래소에 의해 순서 추가), Nano: 이벤트 나노초 차원 시간, Symbol: 계약 이름} 주문 추진: {Event: order, Index: 거래소 인덱스, 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)
        }
    }
}