CCXT Pro est une partie gratuite de CCXT qui ajoute la prise en charge du streaming WebSocket : https://github.com/ccxt/ccxt/issues/15171

Manuel

CCXT Pro est une partie gratuite de CCXT qui ajoute la prise en charge du streaming WebSocket : https://github.com/ccxt/ccxt/issues/15171

La pile CCXT Pro est construite sur CCXT et étend les classes principales de CCXT, en utilisant :

Les mixins au niveau du prototype JavaScript
L'héritage multiple Python
Les Traits PHP
L'héritage de classes Java (les classes d'exchange pro étendent les classes d'exchange de base)

CCXT Pro s'appuie fortement sur le transpileur de CCXT pour la prise en charge multilingue.

                                 User

    +-------------------------------------------------------------+
    |                          CCXT Pro                           |
    +------------------------------+------------------------------+
    |            Public            .           Private            |
    +=============================================================+
    │                              .                              |
    │                  The Unified CCXT Pro API                   |
    |                              .                              |
    |     loadMarkets              .         watchBalance         |
    |     watchTicker              .         watchOrders          |
    |     watchTickers             .         watchMyTrades        |
    |     watchOrderBook           .         watchPositions       |
    |     watchOHLCV               .         createOrderWs        |
    |     watchStatus              .         editOrderWs          |
    |     watchTrades              .         cancelOrderWs        |
    │     watchOHLCVForSymbols     .         cancelOrdersWs       |
    │     watchTradesForSymbols    .         cancelAllOrdersWs    |
    │     watchOrderBookForSymbols .                              |
    │                              .                              |
    +=============================================================+
    │                          unWatch                            |
    │                   (to stop **watch** method)                |
    +=============================================================+
    │                              .                              |
    |            The Underlying Exchange-Specific APIs            |
    |         (Derived Classes And Their Implementations)         |
    │                              .                              |
    +=============================================================+
    │                              .                              |
    |                 CCXT Pro Base Exchange Class                |
    │                              .                              |
    +=============================================================+

    +-------------------------------------------------------------+
    |                                                             |
    |                            CCXT                             |
    |                                                             |
    +=============================================================+

Exchanges

La bibliothèque CCXT Pro prend actuellement en charge les 74 marchés d'échange de cryptomonnaies et API de trading WebSocket suivants :

logo	id	name	ver	type	certified	pro
	aftermath	AftermathFinance
	alpaca	Alpaca
	apex	Apex
	arkham	ARKHAM
	ascendex	AscendEX
	aster	Aster
	backpack	Backpack
	bequant	Bequant
	binance	Binance
	binancecoinm	Binance COIN-M
	binanceus	Binance US
	binanceusdm	Binance USDⓈ-M
	bingx	BingX
	bitfinex	Bitfinex
	bitget	Bitget
	bithumb	Bithumb
	bitmart	BitMart
	bitmex	BitMEX
	bitopro	BitoPro
	bitrue	Bitrue
	bitstamp	Bitstamp
	bittrade	BitTrade
	bitvavo	Bitvavo
	blockchaincom	Blockchain.com
	blofin	BloFin
	bullish	Bullish
	bybit	Bybit
	bybiteu	Bybit EU
	bydfi	BYDFi
	cex	CEX.IO
	coinbase	Coinbase Advanced
	coinbaseexchange	Coinbase Exchange
	coinbaseinternational	Coinbase International
	coinex	CoinEx
	cryptocom	Crypto.com
	deepcoin	DeepCoin
	deribit	Deribit
	derive	derive
	dydx	dYdX
	gate	Gate
	gemini	Gemini
	grvt	GRVT
	hashkey	HashKey Global
	hollaex	HollaEx
	htx	HTX
	hyperliquid	Hyperliquid
	independentreserve	Independent Reserve
	kraken	Kraken
	krakenfutures	Kraken Futures
	kucoin	KuCoin
	kucoinfutures	KuCoin Futures
	lbank	LBank
	lighter	Lighter
	luno	luno
	mexc	MEXC Global
	modetrade	Mode Trade
	myokx	MyOKX (EEA)
	ndax	NDAX
	okx	OKX
	okxus	OKX (US)
	onetrading	One Trading
	oxfun	OXFUN
	p2b	p2b
	pacifica	Pacifica
	paradex	Paradex
	phemex	Phemex
	poloniex	Poloniex
	toobit	Toobit
	upbit	Upbit
	weex	Weex
	whitebit	WhiteBit
	woo	WOO X
	woofipro	WOOFI PRO
	xt	XT

Il s'agit de la liste des exchanges dans CCXT Pro avec prise en charge des API WebSockets. Cette liste sera mise à jour régulièrement avec de nouveaux exchanges.

Liste complète des exchanges disponibles dans CCXT via REST : Marchés d'échange de cryptomonnaies pris en charge.

Utilisation

- this part of the doc is under heavy development right now
- there may be some typos, mistakes and missing info here and there
- contributions, pull requests and feedback appreciated

La meilleure façon de comprendre CCXT Pro est de s'assurer que vous maîtrisez l'intégralité du Manuel CCXT et de pratiquer d'abord le CCXT standard. CCXT Pro s'appuie sur CCXT. Les deux bibliothèques partagent de nombreux points communs, notamment :

les concepts d'API publique et d'API privée authentifiée
les marchés, symboles, codes de devises et identifiants
les structures et formats de données unifiés, carnets d'ordres, transactions, ordres, bougies, intervalles de temps, ...
les exceptions et les correspondances d'erreurs
l'authentification et les clés API (pour les flux et appels privés)
les options de configuration

Le public de CCXT Pro est composé principalement de traders algorithmiques professionnels et de développeurs. Pour travailler efficacement avec cette bibliothèque, l'utilisateur doit bien maîtriser les concepts du streaming. Il faut comprendre les différences fondamentales entre les API de streaming basées sur des connexions (WebSocket, CCXT Pro) et les API basées sur des requêtes-réponses (REST, CCXT).

Le flux général de style asynchrone pour une application CCXT est le suivant :


// a RESTful orderbook polling request-response loop

while (condition) {

    try {

        // fetch some of the public data
        orderbook = await exchange.fetchOrderBook (symbol, limit)

        // do something or react somehow based on that data
        // ...

    } catch (e) {

        // handle errors
    }
}

Dans CCXT Pro, chaque méthode RESTful unifiée publique et privée ayant un préfixe fetch* possède également une méthode homologue basée sur les flux, préfixée par watch*, comme suit :

API publique
- fetchStatus → watchStatus
- fetchOrderBook → watchOrderBook
- fetchOrderBookForSymbols → watchOrderBookForSymbols
- fetchTicker → watchTicker
- fetchTickers → watchTickers
- fetchOHLCV → watchOHLCV
- fetchOHLCVForSymbols → watchOHLCVForSymbols
- fetchTrades → watchTrades
- fetchTradesForSymbols → watchTradesForSymbols
- fetchBidsAsks → watchBidsAsks
- fetchLiquidations → watchLiquidations
- fetchLiquidationsForSymbols → watchLiquidationsForSymbols
API privée
- fetchBalance → watchBalance
- fetchOrders → watchOrders
- fetchOrdersForSymbols → watchOrdersForSymbols
- fetchMyTrades → watchMyTrades
- fetchPosition → watchPosition
- fetchPositions → watchPositions
- fetchLiquidations → watchLiquidations
- fetchMyLiquidations → watchMyLiquidations
- fetchMyLiquidationsForSymbols → watchMyLiquidationsForSymbols
- fetchFundingRates → watchFundingRates
Alternatives REST
- fetchTrades → fetchTradesWs
- createOrder → createOrderWs
- editOrder → editOrderWs
- cancelOrder → cancelOrderWs
- cancelOrders → cancelOrdersWs
- cancelAllOrders → cancelAllOrdersWs
- etc ...
unWatch (arrête l'abonnement en arrière-plan pour les méthodes watch-ées)
- unWatchOrderBook
- unWatchOrderBooksForSymbols
- unWatchTrades
- unWatchTradesForSymbols
- unWatchOHLCVForSymbols
- unWatchOrderBookForSymbols
- unWatchPositions
- unWatchTickers
- unWatchMyTrades
- unWatchTicker
- unWatchOHLCV
- unWatchOrders

L'API de streaming unifiée CCXT Pro hérite des schémas d'utilisation de CCXT pour faciliter la migration.

Le flux général de style asynchrone pour une application CCXT Pro (par opposition à une application CCXT ci-dessus) est présenté ci-dessous :


// a stream-based (WebSocket) orderbook feed loop

while (condition) {

    try {

        // watch some of the public data
        orderbook = await exchange.watchOrderBook (symbol, limit)

        // do something or react somehow based on that data
        // ...

    } catch (e) {

        // handle errors
    }
}

Ce schéma d'utilisation est généralement encapsulé dans une méthode de logique métier centrale appelée "une fonction tick()", car elle réitère une réaction aux événements entrants (aussi appelés ticks). D'après les deux exemples ci-dessus, il est évident que le schéma d'utilisation générique dans CCXT Pro et CCXT est identique.

Bon nombre des règles et concepts de CCXT s'appliquent également à CCXT Pro :

CCXT Pro chargera les marchés et les mettra en cache lors du premier appel à une méthode d'API unifiée
CCXT Pro appellera les méthodes RESTful de CCXT en coulisse si nécessaire
CCXT Pro lèvera des exceptions CCXT standard le cas échéant
...

Spécificités du Streaming

Malgré les nombreux points communs, les API basées sur le streaming ont leurs propres spécificités, en raison de leur nature orientée connexion.

Disposer d'une interface basée sur les connexions implique des mécanismes de gestion des connexions. Les connexions sont gérées par CCXT Pro de manière transparente pour l'utilisateur. Chaque instance d'exchange gère son propre ensemble de connexions.

Lors de votre premier appel à toute méthode watch*(), la bibliothèque établira une connexion à un flux/ressource spécifique de l'exchange et la maintiendra. Si la connexion existe déjà, elle est réutilisée. La bibliothèque gérera les séquences de messages de demande/réponse d'abonnement ainsi que l'authentification/signature si le flux demandé est privé.

La bibliothèque surveillera également l'état de la liaison montante et maintiendra la connexion active. En cas d'exception critique, de déconnexion ou d'expiration/d'échec de connexion, la prochaine itération de la fonction tick appellera la méthode watch qui déclenchera une reconnexion. De cette façon, la bibliothèque gère les déconnexions et reconnexions pour l'utilisateur de manière transparente. CCXT Pro applique la limitation de débit nécessaire et des délais de reconnexion à recul exponentiel. Toutes ces fonctionnalités sont activées par défaut et peuvent être configurées via les propriétés de l'exchange, comme d'habitude.

La plupart des exchanges ne disposent que d'une seule URL de base pour les API de streaming (généralement WebSocket, commençant par ws:// ou wss://). Certains peuvent avoir plusieurs URL pour chaque flux, selon le flux en question.

Les API de streaming des exchanges peuvent être classées en deux catégories distinctes :

sub ou subscribe permet la réception uniquement
pub ou publish permet l'envoi et la réception

Sub

Une interface sub permet généralement de s'abonner à un flux de données et de l'écouter. La plupart des exchanges qui prennent en charge les WebSockets n'offriront qu'un type d'API sub. Le type sub inclut le streaming de données de marché publiques. Parfois, les exchanges permettent également de s'abonner aux données privées des utilisateurs. Une fois que l'utilisateur s'est abonné à un flux de données, le canal commence effectivement à fonctionner de manière unidirectionnelle, envoyant des mises à jour de l'exchange vers l'utilisateur en continu.

Types courants de flux de données publiques :

carnet d'ordres (le plus courant) - mises à jour sur les ordres ajoutés, modifiés et supprimés (aussi appelés deltas de changement)
mises à jour du ticker lors de la modification des statistiques sur 24 heures
flux d'exécutions (aussi courant) - un flux en direct de transactions publiques
flux de bougies ohlcv
heartbeat
chat/trollbox de l'exchange

Types moins courants de flux de données privées des utilisateurs :

le flux des transactions privées de l'utilisateur
mises à jour d'ordres en direct
mises à jour du solde
flux personnalisés
flux spécifiques à l'exchange et autres flux

Pub

Une interface pub permet généralement aux utilisateurs d'envoyer des demandes de données vers le serveur. Cela inclut généralement les actions courantes des utilisateurs, telles que :

passer des ordres
annuler des ordres
soumettre des demandes de retrait
publier des messages dans le chat/trollbox
etc

Certains exchanges ne proposent pas d'API WS pub, ils n'offriront qu'une API WS sub. Cependant, il existe des exchanges disposant d'une API de streaming complète. Dans la plupart des cas, un utilisateur ne peut pas opérer efficacement avec uniquement l'API de streaming. Les exchanges diffuseront les données de marché publiques en sub, et l'API REST reste nécessaire pour la partie pub là où elle est absente.

unWatch

Chaque méthode watchX établit un abonnement à un flux et recevra continuellement des mises à jour de l'exchange. Même si vous arrêtez de récupérer la valeur de retour de la méthode watchX, le flux continuera à envoyer des données, qui sont traitées et stockées en arrière-plan. Pour arrêter ces abonnements en arrière-plan, vous devez utiliser la méthode unWatch (par ex. watchTrades -> unWatchTrades).

Structures de Données Incrémentales

Dans de nombreux cas, en raison de la nature unidirectionnelle des flux de données sous-jacents, l'application à l'écoute côté client doit conserver un instantané local des données en mémoire et fusionner les mises à jour reçues du serveur de l'exchange dans l'instantané local. Les mises à jour provenant de l'exchange sont aussi souvent appelées deltas, car dans la plupart des cas ces mises à jour ne contiendront que les changements entre deux états des données et n'incluront pas les données qui n'ont pas changé, rendant nécessaire le stockage de l'état courant S mis en cache localement de tous les objets de données pertinents.

Toutes ces fonctionnalités sont gérées par CCXT Pro pour l'utilisateur. Pour travailler avec CCXT Pro, l'utilisateur n'a pas à suivre ou gérer les abonnements et les données associées. CCXT Pro maintiendra un cache de structures en mémoire pour gérer la complexité sous-jacente.

Chaque mise à jour entrante indique quelles parties des données ont changé et le côté récepteur « incrémente » l'état local S en fusionnant la mise à jour par-dessus l'état courant S et passe au prochain état local S'. En termes de CCXT Pro, cela s'appelle "état incrémental" et les structures impliquées dans le processus de stockage et de mise à jour de l'état mis en cache sont appelées "structures incrémentales". CCXT Pro introduit plusieurs nouvelles classes de base pour gérer l'état incrémental là où cela est nécessaire.

Les structures incrémentales retournées par les méthodes unifiées de CCXT Pro sont souvent de l'un des deux types suivants :

Objet décodé en JSON (object en JavaScript, dict en Python, array() en PHP). Ce type peut être retourné par des méthodes publiques et privées telles que watchOrderBook, watchTicker, watchBalance, watchOrder, etc.
Un tableau/liste d'objets (généralement triés dans l'ordre chronologique). Ce type peut être retourné par des méthodes telles que watchOHLCV, watchTrades, watchMyTrades, watchOrders, etc.

Les méthodes unifiées retournant des tableaux comme watchOHLCV, watchTrades, watchMyTrades, watchOrders, sont basées sur la couche de cache. L'utilisateur doit comprendre le fonctionnement interne de la couche de cache pour l'utiliser efficacement.

Le cache est une deque de taille fixe, aussi appelée tableau/liste avec deux extrémités. La bibliothèque CCXT Pro impose une limite raisonnable sur le nombre d'objets stockés en mémoire. Par défaut, les structures de tableau en cache stockeront jusqu'à 1000 entrées de chaque type (1000 transactions les plus récentes, 1000 bougies les plus récentes, 1000 ordres les plus récents). Le nombre maximum autorisé peut être configuré par l'utilisateur lors de l'instanciation ou ultérieurement :

ccxtpro.binance({
    'options': {
        'tradesLimit': 1000,
        'OHLCVLimit': 1000,
        'ordersLimit': 1000,
    },
})

# or

exchange.options['tradesLimit'] = 1000
exchange.options['OHLCVLimit'] = 1000
exchange.options['ordersLimit'] = 1000

Les limites du cache doivent être définies avant d'appeler toute méthode watch et ne peuvent pas être modifiées pendant l'exécution d'un programme.

Lorsqu'il reste de l'espace dans le cache, les nouveaux éléments sont simplement ajoutés à la fin. S'il n'y a pas assez de place pour un nouvel élément, l'élément le plus ancien est supprimé du début du cache pour libérer de l'espace. Ainsi, par exemple, le cache passe de 0 à 1000 transactions les plus récentes puis reste à un maximum de 1000 transactions les plus récentes, renouvelant constamment les données stockées à chaque nouvelle mise à jour provenant de l'exchange. Cela rappelle une fenêtre à cadre glissant ou une porte coulissante, qui ressemble à ce qui est illustré ci-dessous :

      past > ------------------ > time > - - - - - - - - > future


                           sliding frame
                           of 1000 most
                           recent trades
                        +-----------------+
                        |                 |
                        |===========+=====|
+----------------+------|           |     | - - - - - + - - - - - - - - + - - -
|                |      |           |     |           |                 |
0              1000     |         2000    |         3000              4000  ...
|                |      |           |     |           |                 |
+----------------+------|           |     | - - - - - + - - - - - - - - + - - -
                        |===========+=====|
                        |                 |
                        +---+---------+---+
                            |         |
                      since ^         ^ limit

                   date-based pagination arguments
                         are always applied
                       within the cached frame

L'utilisateur peut configurer les limites du cache en utilisant exchange.options comme indiqué ci-dessus. Ne pas confondre les limites du cache avec la limite de pagination.

Notez que les paramètres since et limit de pagination basée sur les dates ont une signification différente et sont toujours appliqués dans la fenêtre mise en cache ! Si l'utilisateur spécifie un argument since lors de l'appel à watchTrades(), CCXT Pro retournera toutes les transactions mises en cache ayant timestamp >= since. Si l'utilisateur ne spécifie pas d'argument since, CCXT Pro retournera les transactions mises en cache depuis le début de la fenêtre glissante. Si l'utilisateur spécifie un argument limit, la bibliothèque retournera jusqu'à limit bougies à partir de since ou depuis le début du cache. Pour cette raison, l'utilisateur ne peut pas paginer au-delà du cadre mis en cache en raison des spécificités temps réel de WebSocket.

exchange.options['tradesLimit'] = 5  # set the size of the cache to 5

# this call will return up to 5 cached trades
await exchange.watchTrades (symbol)

# the following call will return the first 2 of up to 5 cached trades
await exchange.watchTrades (symbol, since=None, limit=2)

# this call will first filter cached trades by trade['timestamp'] >= since
# and will return the first 2 of up to 5 cached trades that pass the filter
since = exchange.iso8601('2020-01-01T00:00:00Z')
limit = 2
await exchange.watchTrades (symbol, since, limit)

Mode newUpdates

Si vous souhaitez toujours obtenir uniquement le trade le plus récent, vous devez instancier l'exchange avec le drapeau newUpdates défini à true.

exchange = ccxtpro.binance({'newUpdates': True})
while True:
    trades = await exchange.watchTrades (symbol)
    print(trades)

Le mode newUpdates continue d'utiliser le cache glissant en arrière-plan, mais l'utilisateur ne recevra que les nouvelles mises à jour. Cela est dû au fait que certains exchanges utilisent des structures incrémentielles, nous devons donc conserver un cache d'objets car l'exchange peut ne fournir que des informations partielles telles que des mises à jour d'état.

Le résultat du mode newUpdates sera une ou plusieurs mises à jour survenues depuis la dernière résolution de exchange.watchMethod. CCXT Pro peut retourner un ou plusieurs ordres mis à jour depuis l'appel précédent. Le résultat de l'appel à exchange.watchOrders ressemblera à ce qui est indiqué ci-dessous :

[
    order, // see /docs/manual#order-structure
    order,
    order,
    ...
]

Avertissement de dépréciation : à l'avenir, newUpdates: true sera le mode par défaut et vous devrez définir newUpdates à false pour obtenir le cache glissant.

const ccxtpro = require ('ccxt').pro
console.log ('CCXT version', ccxtpro.version)
console.log ('Supported exchanges:', ccxtpro.exchanges)

Le module CCXT Pro importé encapsule CCXT en son sein — chaque exchange instancié via CCXT Pro dispose de toutes les méthodes CCXT ainsi que des fonctionnalités supplémentaires.

Instanciation

CCXT Pro est conçu pour la syntaxe async/await et repose largement sur des primitives asynchrones telles que les promises et les futures.

La création d'une instance d'exchange CCXT Pro est quasiment identique à la création d'une instance d'exchange CCXT.

const ccxt = require ('ccxt').pro
const exchange = new ccxtpro.binance ({ newUpdates: false })

Python

L'implémentation Python de CCXT Pro repose sur le module intégré asyncio et en particulier sur Event Loop. En Python, il est possible de fournir une instance de boucle d'événements asyncio dans les arguments du constructeur comme indiqué ci-dessous (identique à ccxt.async support) :

import ccxt.pro as ccxtpro
from asyncio import run

async def main():
    exchange = ccxtpro.kraken({'newUpdates': False})
    while True:
        orderbook = await exchange.watch_order_book('BTC/USD')
        print(orderbook['asks'][0], orderbook['bids'][0])
    await exchange.close()


run(main())

PHP

En PHP, les primitives asynchrones sont empruntées à ReactPHP. L'implémentation PHP de CCXT Pro repose sur Promise et EventLoop en particulier. En PHP, l'utilisateur doit fournir une instance de boucle d'événements ReactPHP dans les arguments du constructeur comme indiqué ci-dessous :

error_reporting(E_ALL);
date_default_timezone_set('UTC');
require_once 'vendor/autoload.php';

$exchange = new \ccxt\pro\kucoin(array( 'newUpdates' => false ));

using ccxt.pro;

    public async static Task Watch()
    {
        var exchange = new binance();
        while (true)
        {
            var trades = await exchange.WatchTrades("BTC/USDT");
            Console.WriteLine("Trades: " + JsonConvert.SerializeObject(trades, Formatting.Indented));
        }
    }

Propriétés de l'exchange

Chaque instance CCXT Pro contient toutes les propriétés de l'instance CCXT sous-jacente. En plus des propriétés CCXT standard, l'instance CCXT Pro inclut les éléments suivants :

{
    'has': { // an associative array of extended exchange capabilities
        'ws': true, // only available in CCXT Pro
        'watchOrderBook': true,
        'watchTicker': true,
        'watchTickers': true,
        'watchTrades': true,
        'watchMyTrades': true,
        'watchOHLCV': true,
        'watchBalance': true,
        'watchPositions': true,
        'createOrderWs': true,
        'editOrderWs': true,
        'cancelOrderWs': true,
        'cancelOrdersWs': false,
        'cancelAllOrdersWs': true,
        'fetchOrderWs': true,
        'fetchOrdersWs': true,
        'fetchBalanceWs': true,
        'fetchMyTradesWs': true,
        ...
    },
    'urls': {
        'api': { // will contain a streaming API base URL, depending on the underlying protocol
            'ws': 'wss://ws.exchange.com',            // https://en.wikipedia.org/wiki/WebSocket
            'signalr': 'https://signalr.exchange.com' // https://en.wikipedia.org/wiki/SignalR
            'socketio': 'wss://socket.exchange.io'    // https://socket.io
        },
    },
    'version': '1.21',
    'streaming': {
        'keepAlive': 30000, // integer keep-alive rate in milliseconds
        'maxPingPongMisses': 2.0, // how many ping pong misses to drop and reconnect
        ... // other streaming options
    },
    // incremental data structures
    'orderbooks':   {}, // incremental order books indexed by symbol
    'ohlcvs':       {}, // standard CCXT OHLCVs indexed by symbol by timeframe
    'balance':      {}, // a standard CCXT balance structure, accounts indexed by currency code
    'orders':       {}, // standard CCXT order structures indexed by order id
    'trades':       {}, // arrays of CCXT trades indexed by symbol
    'tickers':      {}, // standard CCXT tickers indexed by symbol
    'transactions': {}, // standard CCXT deposits and withdrawals indexed by id or txid
    ...
}

API unifiée

L'API CCXT Pro unifiée encourage un flux de contrôle direct pour un meilleur style de code, un code plus lisible et architecturalement supérieur par rapport à l'utilisation d'EventEmitters et de callbacks. Cette dernière approche est considérée comme obsolète de nos jours car elle nécessite une inversion de contrôle (les gens ne sont pas habitués à la pensée inversée).

CCXT Pro adopte l'approche moderne et est conçu pour la syntaxe async. Sous le capot, CCXT Pro devra parfois utiliser un flux de contrôle inversé en raison des dépendances et des bibliothèques WebSocket qui ne peuvent pas faire autrement.

Il en va de même non seulement pour JS/ES6 mais aussi pour le code async Python 3. En PHP, les primitives asynchrones sont empruntées à ReactPHP.

La syntaxe async moderne vous permet de combiner et de diviser l'exécution en chemins parallèles, puis de les fusionner, de les regrouper, de les prioriser, et bien plus encore. Avec les promises, il est facile de convertir d'un flux de contrôle async direct à un flux de contrôle inversé par callbacks, et vice versa.

Temps réel vs Limitation

CCXT Pro prend en charge deux modes de boucles de fonctions tick — le mode temps réel et le mode de limitation. Les deux sont présentés ci-dessous en pseudocode :

// real-time mode
const limit = 5 // optional
while (true) {
    try {
        const orderbook = await exchange.watchOrderBook (symbol, limit)
        // your reaction to the update takes place here
        // you arrive here after receiving the update from the exchange in real time
        console.log (orderbook) // every update
    } catch (e) {
        console.log (e)
        // throw e // uncomment to stop the loop on exceptions
    }
}

// throttling mode
const limit = 5 // optional
// await is optional, alternatively you can launch it in bg without await
await exchange.watchOrderBook (symbol, limit)
while (true) {
    // your reaction takes place here
    // you arrive here every 100 ms regardless of whether there was an update or not
    // in throttling mode offloading the orderbook with .limit () is required
    console.log (exchange.orderbooks[symbol].limit (limit))
    await exchange.sleep (100) // every 100 ms
}

En mode temps réel, CCXT Pro retournera le résultat dès que chaque nouveau delta arrive de l'exchange. La logique générale d'un appel unifié dans une boucle temps réel consiste à attendre le prochain delta et à retourner immédiatement la structure de résultat unifiée à l'utilisateur, encore et encore. Ceci est utile lorsque le temps de réaction est critique ou doit être le plus rapide possible.

Cependant, le mode temps réel nécessite une expérience en programmation avec les flux asynchrones lorsqu'il s'agit de synchroniser plusieurs boucles tick parallèles. En dehors de cela, les exchanges peuvent diffuser un très grand nombre de mises à jour pendant les périodes de forte activité ou de forte volatilité. Par conséquent, l'utilisateur développant un algorithme en temps réel doit s'assurer que le code en espace utilisateur est capable de consommer des données aussi rapidement. Travailler en mode temps réel peut parfois être plus exigeant en ressources.

En mode de limitation, CCXT Pro recevra et gérera les données en arrière-plan. L'utilisateur est responsable d'appeler les résultats de temps en temps lorsque nécessaire. La logique générale de la boucle de limitation consiste à dormir la plupart du temps et à se réveiller pour vérifier les résultats occasionnellement. Cela se fait généralement à une fréquence fixe, ou "cadence d'images". Le code à l'intérieur d'une boucle de limitation est souvent plus facile à synchroniser entre plusieurs exchanges. Le rationnement du temps passé dans une boucle limitée contribue également à réduire l'utilisation des ressources au minimum. C'est pratique lorsque votre algorithme est lourd et que vous souhaitez contrôler précisément l'exécution pour éviter de l'exécuter trop souvent.

L'inconvénient évident du mode de limitation est d'être moins réactif aux mises à jour. Lorsqu'un algorithme de trading doit attendre quelques millisecondes avant d'être exécuté, une ou deux mises à jour peuvent arriver avant l'expiration de ce délai. En mode de limitation, l'utilisateur ne vérifiera ces mises à jour qu'au prochain réveil (itération de la boucle), de sorte que le délai de réaction peut varier dans un certain nombre de millisecondes au fil du temps.

Méthodes publiques

watchOrderBook

L'interface de watchOrderBook est identique à fetchOrderBook. Elle accepte trois arguments :

symbol – chaîne, un symbole CCXT unifié, obligatoire
limit – entier, le nombre maximum d'offres/demandes retournées, optionnel
params – dictionnaire associatif, surcharges optionnelles décrites dans Surcharger les paramètres de l'API unifiée

En général, les exchanges peuvent être divisés en deux catégories :

les exchanges qui prennent en charge les carnets d'ordres limités (diffusant uniquement la partie supérieure de la pile d'ordres)
les exchanges qui diffusent uniquement des carnets d'ordres complets

Si l'exchange accepte un argument de limitation, l'argument limit est envoyé vers l'exchange lors de l'abonnement au flux du carnet d'ordres via une connexion WebSocket. L'exchange n'enverra alors que le nombre d'ordres spécifié, ce qui contribue à réduire le trafic. Certains exchanges peuvent n'accepter que certaines valeurs de limit, comme 10, 25, 50, 100, etc.

Si l'exchange sous-jacent n'accepte pas d'argument de limitation, la limitation est effectuée côté client.

L'argument limit ne garantit pas que le nombre d'offres ou de demandes sera toujours égal à limit. Il désigne la limite supérieure ou le maximum, donc à un moment donné il peut y avoir moins de limit offres ou demandes, mais jamais plus de limit offres ou demandes. C'est le cas lorsque l'exchange ne dispose pas d'assez d'ordres dans le carnet d'ordres, ou lorsqu'un des ordres en tête du carnet d'ordres est exécuté et supprimé, laissant moins de limit entrées du côté des offres ou des demandes. L'espace libre dans le carnet d'ordres est généralement rapidement comblé par de nouvelles données.

if (exchange.has['watchOrderBook']) {
    while (true) {
        try {
            const orderbook = await exchange.watchOrderBook (symbol, limit, params)
            console.log (new Date (), symbol, orderbook['asks'][0], orderbook['bids'][0])
        } catch (e) {
            console.log (e)
            // stop the loop on exception or leave it commented to retry
            // throw e
        }
    }
}

watchOrderBookForSymbols

Similaire à watchOrderBook mais accepte un tableau de symboles afin que vous puissiez vous abonner à plusieurs carnets d'ordres en un seul message.

if (exchange.has['watchOrderBookForSymbols']) {
    while (true) {
        try {
            const orderbook = await exchange.watchOrderBookForSymbols (['BTC/USDT', 'LTC/USDT'], limit, params)
            console.log (new Date (), symbol, orderbook['asks'][0], orderbook['bids'][0])
        } catch (e) {
            console.log (e)
            // stop the loop on exception or leave it commented to retry
            // throw e
        }
    }
}

watchTicker

Certains exchanges permettent d'écouter différents sujets pour les tickers (par exemple : bookTicker). Vous pouvez le définir dans exchange.options['watchTicker']['name']

// JavaScript
if (exchange.has['watchTicker']) {
    while (true) {
        try {
            const ticker = await exchange.watchTicker (symbol, params)
            console.log (new Date (), ticker)
        } catch (e) {
            console.log (e)
            // stop the loop on exception or leave it commented to retry
            // throw e
        }
    }
}

# Python
if exchange.has['watchTicker']:
    while True:
        try:
            ticker = await exchange.watch_ticker(symbol, params)
            print(exchange.iso8601(exchange.milliseconds()), ticker)
        except Exception as e:
            print(e)
            # stop the loop on exception or leave it commented to retry
            # raise e

if ($exchange->has['watchTicker']) {
    $exchange::execute_and_run(function() use ($exchange, $symbol, $params) {
        while (true) {
            try {
                $ticker = yield $exchange->watch_ticker($symbol, $params);
                echo date('c'), ' ', json_encode($ticker), "\n";
            } catch (Exception $e) {
                echo get_class($e), ' ', $e->getMessage(), "\n";
            }
        }
    });
}

watchTickers

if (exchange.has['watchTickers']) {
    while (true) {
        try {
            const tickers = await exchange.watchTickers (symbols, params)
            console.log (new Date (), tickers)
        } catch (e) {
            console.log (e)
            // stop the loop on exception or leave it commented to retry
            // throw e
        }
    }
}

watchOHLCV

Une idée reçue très courante sur les WebSockets est que les flux OHLCV WS peuvent d'une manière ou d'une autre accélérer une stratégie de trading. Si le but de votre application est d'implémenter un trading OHLCV ou une stratégie algorithmique spéculative, réfléchissez attentivement à ce qui suit.

En général, il existe deux types de données de trading utilisées dans les algorithmes :

les données temps réel de premier ordre comme les carnets d'ordres et les trades
les données non temps réel de second ordre comme les tickers, les ohlcvs, etc.

Lorsque les développeurs disent "temps réel", cela signifie généralement pseudo temps réel, ou plus simplement, "aussi vite et aussi proche du temps réel que possible".

Les données de second ordre sont toujours calculées à partir des données de premier ordre. Les OHLCVs sont calculés à partir des trades agrégés. Les tickers sont calculés à partir des trades et des carnets d'ordres.

Certains exchanges effectuent le calcul des OHLCVs (données de second ordre) pour vous côté exchange et vous envoient des mises à jour via WS (Binance). D'autres exchanges n'estiment pas vraiment que cela soit nécessaire, pour une raison.

Évidemment, il faut du temps pour calculer les bougies OHLCV de second ordre à partir des trades. En plus de cela, l'envoi de la bougie calculée à tous les utilisateurs connectés prend également du temps. Des délais supplémentaires peuvent survenir pendant les périodes de forte volatilité si un exchange est très actif sous une charge élevée.

Il n'y a aucune garantie stricte sur le temps que mettra l'exchange pour calculer les données de second ordre et vous les diffuser via WS. Les délais et décalages sur les bougies OHLCV peuvent varier considérablement d'un exchange à l'autre. Par exemple, un exchange peut envoyer une mise à jour OHLCV environ 30 secondes après la clôture effective de la période correspondante. D'autres exchanges peuvent envoyer les mises à jour OHLCV actuelles à intervalles réguliers (par exemple, une fois toutes les 100 ms), alors qu'en réalité les trades peuvent se produire beaucoup plus fréquemment.

La plupart des gens utilisent WS pour éviter tout type de délais et disposer de données en temps réel. Ainsi, dans la plupart des cas, il est bien préférable de ne pas attendre l'exchange. Recalculer les données de second ordre à partir des données de premier ordre par vous-même peut être beaucoup plus rapide et cela peut réduire les délais inutiles. Par conséquent, il n'est pas très utile d'utiliser WS uniquement pour surveiller les bougies OHLCV de l'exchange. Les développeurs préfèrent utiliser watch_trades() et recalculer les bougies OHLCV en utilisant les méthodes intégrées de CCXT comme build_ohlcvc().

# Python
exchange = ccxtpro.binance()
if not exchange.has['watchOHLCV']:
    while True:
        try:
            trades = await exchange.watch_trades(symbol)
            ohlcvc = exchange.build_ohlcvc(trades, '1m')
            print(ohlcvc)
        except Exception as e:
            print(e)
            # stop the loop on exception or leave it commented to retry
            # raise e

Cela explique pourquoi certains exchanges estiment raisonnablement que les OHLCVs ne sont pas nécessaires dans le contexte WS, car les utilisateurs peuvent calculer ces informations dans l'espace utilisateur beaucoup plus rapidement en ayant simplement un flux WS de trades de premier ordre en temps réel.

Si votre application n'est pas très critique en termes de temps, vous pouvez toujours vous abonner aux flux OHLCV, à des fins de graphiques. Si l'exchange sous-jacent dispose de exchange.has['watchOHLCV'], vous pouvez utiliser watchOHLCV()/watch_ohlcv() comme indiqué ci-dessous :

if (exchange.has['watchOHLCV']) {
    while (true) {
        try {
            const candles = await exchange.watchOHLCV (symbol, timeframe, since, limit, params)
            console.log (new Date (), candles)
        } catch (e) {
            console.log (e)
            // stop the loop on exception or leave it commented to retry
            // throw e
        }
    }
}

watchOHLCVForSymbols

Similaire à watchOHLCV mais permet plusieurs abonnements de symboles et de périodes de temps

if (exchange.has['watchOHLCVForSymbols']) {
    while (true) {
        try {
            const subscriptions = [[
                ['BTC/USDT', '1d'],
                ['LTC/USDT', '5m'],
                ['ETH/USDT', '1h']
            ]]
            const candles = await exchange.watchOHLCVForSymbols (subscriptions, since, limit, params)
            console.log (new Date (), candles)
        } catch (e) {
            console.log (e)
            // stop the loop on exception or leave it commented to retry
            // throw e
        }
    }
}

watchTrades

// JavaScript
if (exchange.has['watchTrades']) {
    while (true) {
        try {
            const trades = await exchange.watchTrades (symbol, since, limit, params)
            console.log (new Date (), trades)
        } catch (e) {
            console.log (e)
            // stop the loop on exception or leave it commented to retry
            // throw e
        }
    }
}

watchTradesForSymbols

Similaire à watchTrades mais permet de s'abonner à plusieurs symboles en un seul appel.

if (exchange.has['watchTradesForSymbols']) {
    while (true) {
        try {
            const trades = await exchange.watchTradesForSymbols (['LTC/USDT', 'BTC/USDT'], since, limit, params)
            console.log (new Date (), trades)
        } catch (e) {
            console.log (e)
            // stop the loop on exception or leave it commented to retry
            // throw e
        }
    }
}

Méthodes privées

Dans la plupart des cas, la logique d'authentification est empruntée à CCXT puisque les exchanges utilisent les mêmes paires de clés et algorithmes de signature pour les API REST et les API WebSocket. Consultez Configuration des clés API pour plus de détails.

watchBalance

if (exchange.has['watchBalance']) {
    while (true) {
        try {
            const balance = await exchange.watchBalance (params)
            console.log (new Date (), balance)
        } catch (e) {
            console.log (e)
            // stop the loop on exception or leave it commented to retry
            // throw e
        }
    }
}

watchOrders

watchOrders (symbol = undefined, since = undefined, limit = undefined, params = {})

watchMyTrades

watchMyTrades (symbol = undefined, since = undefined, limit = undefined, params = {})

watchPositions

surveiller toutes les positions ouvertes et retourne une liste d'objets de structure de position

watchPositions (symbols = undefined, since = undefined, limit = undefined, params = {})

createOrderWs

createOrderWs (symbol: string, type: OrderType, side: OrderSide, amount: number, price: number = undefined, params = {})

editOrderWs

// JavaScript
editOrderWs (id, symbol: string, type: OrderType, side: OrderSide, amount: number, price: number = undefined, params = {})

cancelOrderWs

cancelOrderWs(id: string, symbol: string = undefined, params = {})

cancelOrdersWs

cancelOrdersWs(ids: string[], symbol: string = undefined, params = {})

cancelAllOrdersWs

cancelAllOrdersWs(symbol: string = undefined, params = {})

watchTransactions

- this method is a work in progress now (may be unavailable)

Gestionnaire personnalisé

Si vous souhaitez accéder aux messages bruts entrants et utiliser vos propres gestionnaires, vous pouvez redéfinir la méthode handleMessage/handle_message de l'exchange, comme suit :

A) Par héritage :

class myExchange extends ccxt.pro.coinbase {
    handleMessage (wsClient, data) {
        console.log("Raw incoming message:", message) // this is the raw update
        super.handleMessage(wsClient, data);
        // your extra logic here
    }
}
const ex = new myExchange();
ex.watchTicker('BTC/USDT');

B) En surchargeant la méthode :

function myHandler(ws, data, orignal_handler){
    orignal_handler(ws, data); // trigger original `handleMessage`
    if (your_condition) {
        // execute your additional code
    }
}

const ex = new ccxt.pro.binance();
const original_handler = ex.handleMessage.bind(ex);
ex.handleMessage = (ws, data) => myHandler(ws, data, original_handler);
ex.watchTicker('BTC/USDT');

Gestion des erreurs

En cas d'erreur, CCXT Pro lèvera une exception CCXT standard, consultez Gestion des erreurs pour plus de détails.

Manuel CCXT Pro