Commodity futures and digital currency exchange API differences

Commodity futures CTP and digital currency APIs have significant differences, and it is not easy to copy the experience of those who are familiar with digital currency programmed transactions without being familiar with commodity futures programmed. This post will summarize the differences between them.

Historical data

The CTP interface does not provide historical markets, which must be resolved through the market maker. CTP does not provide a mechanism to recover the market data if the loss of market data is caused by a failure to land or a breakdown of the landing line.

The Agreement Differs

The APIs for digital currencies are generally REST and websocket protocols, and the CTP internally encapsulates network-related logic to communicate with the CTP in the background using the FTD protocol based on the TCP protocol.

• Request-response mode: client initiates the request, CTP background receives and responds to the request
• Broadcast communication mode: After the client subscribes to the contract transaction, the CTP pushes the transaction information through the broadcast.
• Private communication mode: after the client has commissioned an operation on a contract, the order information, transaction returns, etc. are pushed by the CTP point-to-point.

All markets and orders transacted in the CTP protocol are notified only after a change, whereas orders, accounts and holdings are actively queried. The above three modes can be found in a similar form in the digital currency API.

The precision of the data varies.

The depth of the CTP protocol is only one buy-sell-one, five-tier transaction fees are expensive, and digital currencies are generally available in full depth or 200-tier. CTP does not push real transactions, it can only be pushed back by holding stock changes, while the digital currency exchange API can get real payout transactions. The transaction data tick level of the domestic CTP platform is 1 second 2 ticks.

Access restrictions vary

Cryptocurrency exchanges generally limit the number of withdrawals to 10 times in 1 second. There are also no special requirements for most withdrawals. CTPs strictly limit the number of requests that need to be initiated, generally 2s is more secure, and there are also requirements for withdrawal times.

Stability

The CTP protocol is very stable, with almost no errors and network problems. Digital currencies are supposed to be less restrictive, have a longer transaction time, and are very common for maintenance, data delays, network errors, etc.

FMZ quantified platform CTP protocol best practices

CTP default mode interfaces such as GetTicker, GetDepth, GetRecords have cached data to get the latest, so the policy can be used without sleep when there is no data. When there is a change in the market, ticker, depth and records are updated, at which time any interface called will be returned immediately, the state of the interface called is set to wait for the update mode, the next time the same interface is called, it will wait for new data to return.

If you want to access data every time you access a market, even old data, you can switch to a market instant update mode.exchange.IO("mode", 0) ⇒ At this point the policy cannot be written as event driven, and a Sleep event needs to be added to avoid a quick dead loop. Some low-frequency policies can use this mode, and the policy design is simple.使用exchange.IO("mode", 1) can be switched back to the default cache mode.

When operating a single contract, the default mode can be used. However, if there are multiple contracts, it is possible that one contract does not update the market, resulting in blockage of access to the market interface, and other contracts do not receive market updates. To solve this problem, you can use the instantaneous update mode, but it is not convenient to write a high-frequency strategy.设置方式为exchange.IO("wait") ⇒ If multiple exchange objects are added, which is rare in commodity futures, then you can expect to see a decrease in the number of exchange objects.可以使用exchange.IO("wait_any"), the returned index will indicate the returned index of the exchange.

The event tick changes push: {Event: tick tick, Index: exchange index ((added in order by robot exchange), Nano: event nanosecond time, Symbol: contract name} Order push: {Event: order push, Index: exchange index, Nano: event nanosecond time, Order: order information ((consistent with GetOrder) }

At this point, the strategy structure can be written as:

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