Kommunikationsmodell¶

Einführung ¶

FIX API verwendet eine sitzungsbasierte Kommunikation. Eine Sitzung wird als Kommunikation zwischen zwei Parteien definiert: dem Initiator (Client), der Partei, die die Kommunikation initiiert, und dem Akzeptor (Server), der Partei, die die Verbindungsanfrage vom Initiator empfängt.

Der Server validiert Client-Anfragen mithilfe der Logon-Nachricht.

FIX-Sitzungsprotokoll ¶

Jede Sitzung unterhält bidirektionale Nachrichten zwischen dem Client und dem cTrader-Server. Eine Sitzung kann mehrere physische Verbindungen umfassen und wird mithilfe von Sequenznummern aufrechterhalten.

Jede neue Nachricht innerhalb einer einzelnen Sitzung erhält eine eindeutige Sequenznummer, beginnend bei 1 (eins). Beide Parteien verlassen sich auf Sequenznummern, um eine geordnete Kommunikation aufrechtzuerhalten. Fehlende Nachrichten werden mit einer bilateralen Vereinbarung zwischen beiden Parteien erneut übertragen.

Typischer Sitzungsablauf:

1. Der Client startet die Sitzung mit einer Logon-Nachricht.
2. Der Client tauscht Anwendungsnachrichten mit dem Server aus.
3. Die Sitzung endet mit einer Logout-Nachricht.

cTrader FIX-Protokoll Nachrichtenkategorien ¶

Wie im FIX-Protokoll definiert, verwendet der cTrader FIX-Server 2 verschiedene Datenebenen: System und Anwendung.

Bitte beachten Sie, dass dies der Mindestsatz an Nachrichten ist, der erforderlich ist, um die notwendigen Arbeitsabläufe zu unterstützen, und sich im Laufe der Zeit ändern kann, wenn sich sowohl die geschäftlichen Anforderungen als auch der FIX-Standard weiterentwickeln.

System- (Admin-) Nachrichten ¶

• Heartbeat (Client ↔ cTrader) – wird verwendet, um die Kommunikationsverbindung zwischen zwei Parteien zu überprüfen.
• Testanfrage (Client ↔ cTrader) – wird verwendet, um den Zustand der Kommunikationsverbindung zu testen.
• Logon (Client → cTrader) – Client-Authentifizierungsnachricht.
• Logon (Client → cTrader) – normale Beendigung der Sitzung.
• Resend-Anfrage (Client ↔ cTrader) – Anfrage zur erneuten Übertragung bestimmter Anwendungsnachrichten.
• Ablehnung (Client ↔ cTrader) – Validierungsfehler auf Sitzungsebene.
• Sequenz-Reset (Client ↔ cTrader) – bei Kommunikationsproblemen werden fehlende Nachrichten wiederhergestellt oder die Sequenz wird zurückgesetzt, um die fehlenden Nachrichten zu ignorieren.

Anwendungsnachrichten ¶

• Marktdatenanfrage (Client → cTrader) – allgemeine Anfrage für Marktdaten.
• Inkrementelle Marktdatenaktualisierung (Client ← cTrader) – Antworten auf eine Marktdatenanfragenachricht.
• Neue Einzelorder (Client → cTrader) – wird verwendet, um Orders elektronisch zur Ausführung an einen Broker zu übermitteln.
• Ausführungsbericht (Client ← cTrader) – wird verwendet, um Orderstatusinformationen an einen FIX-Client zu senden, wie Bestätigungen, Ausführungen und unaufgeforderte Änderungen.
• Geschäftsnachrichtenablehnung (Client ← cTrader) – wird verwendet, um eine FIX-Client-Anfrage aus nicht sitzungsbezogenen Gründen abzulehnen.

FIX-Nachrichtenstruktur ¶

Dieser Abschnitt erklärt, wie die FIX API-Nachricht aufgebaut ist, beschreibt das FIX-Nachrichtenformat und hilft Benutzern, das Konzept von Tag und Wertepaar zu verstehen.

Jede Nachricht muss 3 Teile enthalten:

• Header – jeder administrativen oder Anwendungsnachricht geht ein Standardheader voraus. Der Header identifiziert den Nachrichtentyp, die FIX-Version, die Nachrichtenlänge, das Ziel, die Sequenznummer, den Ursprung und die Zeit.
• Body – der Inhalt im Body der Nachricht wird durch den im Header definierten Nachrichtentyp spezifiziert.
• Footer – jede Nachricht, administrativ oder anwendungsbezogen, wird durch einen Standardfooter abgeschlossen. Der Footer wird verwendet, um Nachrichten zu trennen und enthält die dreistellige Zeichendarstellung des CheckSum <10>-Wertes.

FIX-Nachrichtenformat ¶

Eine FIX-Nachricht ist eine Sammlung von Feldern. Jedes Feld ist ein Tag-Wert-Paar, formatiert als {tag}={value}. Zum Beispiel 54=2, was bedeutet, dass der Ordertyp Verkauf ist.

Tag ¶

• FIX verwendet vordefinierte Tags.
• Jeder Tag repräsentiert ein spezifisches Feld.
• Jedem Tag wird eine vordefinierte Nummer zugewiesen.
• Die cTrader FIX-Spezifikation bietet eine Liste von Feldern und entsprechenden Tag-Nummern.

Wert ¶

• Werte repräsentieren den Wert des ihnen zugewiesenen Tags.
• Werte können nur einen der folgenden Datentypen haben: Ganzzahl, Gleitkommazahl, Zeichen, Zeit, Datum, Daten oder Zeichenkette.

Alle Nachrichten innerhalb der cTrader FIX API beginnen mit 8=FIX.x.y, wobei x.y die Version des FIX-Protokolls ist. Am Ende jeder Nachricht sollte ein Feld 10=xyz stehen, wobei xyz die Summe aller Binärwerte in der Nachricht darstellt, die als Prüfsumme bezeichnet wird.

Die Prüfsumme hilft dabei, Übertragungsprobleme zu identifizieren, insbesondere Paketverluste, indem sie dem Empfänger ermöglicht zu erkennen, ob ein Teil der Nachricht fehlt.

Wenn das Symbol(55)-Tag in einer FIX-Nachricht an cTrader/cServer verwendet wird, müssen Sie die FIX-Symbol-ID angeben. Dieser Wert kann bei verschiedenen Brokern unterschiedlich sein. Sie finden das Feld FIX-Symbol-ID in der cTrader-Anwendung des jeweiligen Brokers im Symbolfenster.

Nachrichtenbeispiel ¶

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|