Modèle de communication¶

Introduction ¶

L'API FIX utilise une communication basée sur des sessions. Une session est définie comme une communication entre deux parties : l'initiateur (client), la partie qui initie la communication, et l'accepteur (serveur), la partie qui reçoit la demande de connexion de l'initiateur.

Le serveur valide les demandes du client à l'aide du message Logon.

Protocole de session FIX ¶

Chaque session maintient des messages bidirectionnels entre le client et le serveur cTrader. Une session peut inclure plusieurs connexions physiques et est maintenue à l'aide de numéros de séquence.

Chaque nouveau message au sein d'une même session reçoit un numéro de séquence unique commençant par 1 (un). Les deux parties s'appuient sur les numéros de séquence pour maintenir une communication ordonnée. Les messages manquants sont retransmis avec un accord bilatéral entre les deux parties.

Flux de session typique :

1. Le client démarre la session avec un message Logon.
2. Le client échange des messages d'application avec le serveur.
3. La session se termine par un message Logout.

Catégories de messages du protocole FIX de cTrader ¶

Comme défini dans le protocole FIX, le serveur FIX de cTrader utilise 2 niveaux de données différents : système et application.

Veuillez noter qu'il s'agit de l'ensemble minimal de messages requis pour prendre en charge les flux de travail nécessaires et qu'il est susceptible d'évoluer au fil du temps en fonction des besoins commerciaux et de l'évolution de la norme FIX.

Messages système (admin) ¶

• Heartbeat (client ↔ cTrader) – utilisé pour vérifier le lien de communication entre les deux parties.
• Test request (client ↔ cTrader) – utilisé pour tester l'état du lien de communication.
• Logon (client → cTrader) – message d'authentification du client.
• Logon (client → cTrader) – terminaison normale de la session.
• Resend request (client ↔ cTrader) – demande de retransmission de certains messages d'application.
• Reject (client ↔ cTrader) – échec de validation au niveau de la session.
• Sequence reset (client ↔ cTrader) – en cas de problèmes de communication, les messages manquants sont récupérés ou la séquence est réinitialisée pour ignorer les messages manquants.

Messages d'application ¶

• Market data request (client → cTrader) – demande générale de données de marché.
• Market data incremental refresh (client ← cTrader) – réponses à un message de demande de données de marché.
• New order single (client → cTrader) – utilisé pour soumettre électroniquement les ordres à un courtier pour exécution.
• Execution report (client ← cTrader) – utilisé pour envoyer des informations sur l'état des ordres à un client FIX, telles que des confirmations, des exécutions et des changements non sollicités.
• Business message reject (client ← cTrader) – utilisé pour rejeter une demande d'un client FIX pour des raisons non liées à la session.

Structure des messages FIX ¶

Cette section explique comment le message de l'API FIX est composé, décrit le format du message FIX et aide les utilisateurs à comprendre le concept de paire tag-valeur.

Chaque message doit contenir 3 parties :

• En-tête – chaque message administratif ou d'application est précédé d'un en-tête standard. L'en-tête identifie le type de message, la version FIX, la longueur du message, la destination, le numéro de séquence, l'origine et l'heure.
• Corps – le contenu du corps du message est spécifié par le type de message défini dans l'en-tête.
• Pied de page – chaque message, administratif ou d'application, se termine par un pied de page standard. Le pied de page est utilisé pour séparer les messages et contient la représentation en trois caractères de la valeur CheckSum <10>.

Format du message FIX ¶

Un message FIX est une collection de champs. Chaque champ est une paire tag-valeur formatée comme {tag}={valeur}. Par exemple, 54=2, ce qui signifie que le type d'ordre est vente.

Tag ¶

• FIX utilise des tags prédéfinis.
• Chaque tag représente un champ spécifique.
• Chaque tag se voit attribuer un numéro prédéfini.
• La spécification FIX de cTrader fournit une liste des champs et des numéros de tag correspondants.

Valeur ¶

• Les valeurs représentent la valeur du tag qui leur est attribué.
• Les valeurs ne peuvent être que l'un des types de données suivants : entier, virgule flottante, caractère, heure, date, données ou chaîne de caractères.

Tous les messages dans l'API FIX de cTrader commencent par 8=FIX.x.y, où x.y est la version du protocole FIX. À la fin de chaque message, il doit y avoir un champ 10=xyz, où xyz représente la somme de toutes les valeurs binaires du message appelée somme de contrôle.

La somme de contrôle aide à identifier tout problème de transmission, en particulier la perte de paquets, en permettant au destinataire de savoir si une partie du message est manquante.

Si le tag Symbol(55) est utilisé dans un message FIX vers cTrader/cServer, vous devez spécifier l'ID du symbole FIX. Cette valeur peut être différente selon les courtiers. Vous pouvez trouver le champ ID du symbole FIX dans l'application cTrader de ce courtier dans la fenêtre d'information du symbole.

Exemple de message ¶

8=FIX.4.4|9=126|35=A|34=1|49=theBroker.12345|57=TRADE|50=any_string|52=20170117-08:03:04|56=CSERVER|98=0|108=30|553=12345|554=passw0rd!|10=131|