Model komunikacji¶

Wprowadzenie ¶

FIX API wykorzystuje komunikację opartą na sesjach. Sesja jest definiowana jako komunikacja między dwiema stronami: inicjatorem (klientem), stroną inicjującą komunikację, oraz akceptorem (serwerem), stroną odbierającą żądanie połączenia od inicjatora.

Serwer weryfikuje żądania klienta za pomocą komunikatu Logon.

Protokół sesji FIX ¶

Każda sesja utrzymuje dwukierunkową wymianę komunikatów między klientem a serwerem cTrader. Sesja może obejmować wiele połączeń fizycznych i jest utrzymywana przy użyciu numerów sekwencyjnych.

Każdy nowy komunikat w ramach pojedynczej sesji otrzymuje unikalny numer sekwencyjny, zaczynając od 1 (jeden). Obie strony polegają na numerach sekwencyjnych w celu utrzymania uporządkowanej komunikacji. Brakujące komunikaty są ponownie przesyłane na podstawie dwustronnego porozumienia między obiema stronami.

Typowy przebieg sesji:

1. Klient rozpoczyna sesję komunikatem Logon.
2. Klient wymienia komunikaty aplikacyjne z serwerem.
3. Sesja kończy się komunikatem Logout.

Kategorie komunikatów protokołu cTrader FIX ¶

Zgodnie z definicją w protokole FIX, serwer cTrader FIX wykorzystuje 2 różne poziomy danych: systemowy i aplikacyjny.

Należy pamiętać, że jest to minimalny zestaw komunikatów wymaganych do obsługi niezbędnych przepływów pracy i może ulec zmianie w miarę upływu czasu, w miarę jak zmieniają się potrzeby biznesowe i standard FIX.

Komunikaty systemowe (administracyjne) ¶

• Heartbeat (klient ↔ cTrader) – używany do sprawdzania łącza komunikacyjnego między dwiema stronami.
• Test request (klient ↔ cTrader) – używany do testowania sprawności łącza komunikacyjnego.
• Logon (klient → cTrader) – komunikat uwierzytelniania klienta.
• Logon (klient → cTrader) – normalne zakończenie sesji.
• Resend request (klient ↔ cTrader) – żądanie ponownego przesłania określonych komunikatów aplikacyjnych.
• Reject (klient ↔ cTrader) – niepowodzenie walidacji na poziomie sesji.
• Sequence reset (klient ↔ cTrader) – w przypadku problemów z komunikacją odzyskiwane są brakujące komunikaty lub sekwencja jest resetowana w celu zignorowania brakujących komunikatów.

Komunikaty aplikacyjne ¶

• Market data request (klient → cTrader) – ogólne żądanie danych rynkowych.
• Market data incremental refresh (klient ← cTrader) – odpowiedzi na komunikat żądania danych rynkowych.
• New order single (klient → cTrader) – używany do elektronicznego składania zleceń do brokera w celu realizacji.
• Execution report (klient ← cTrader) – używany do wysyłania informacji o statusie zlecenia do klienta FIX, takich jak potwierdzenia, realizacje i niezamówione zmiany.
• Business message reject (klient ← cTrader) – używany do odrzucania żądania klienta FIX z powodów niezwiązanych z sesją.

Struktura komunikatu FIX ¶

Ta sekcja wyjaśnia, jak zbudowany jest komunikat FIX API, opisuje format komunikatu FIX i pomaga użytkownikom zrozumieć koncepcję pary tag-wartość.

Każdy komunikat musi zawierać 3 części:

• Nagłówek – każdy komunikat administracyjny lub aplikacyjny jest poprzedzony standardowym nagłówkiem. Nagłówek identyfikuje typ komunikatu, wersję FIX, długość komunikatu, miejsce docelowe, numer sekwencyjny, pochodzenie i czas.
• Treść – zawartość treści komunikatu jest określona przez typ komunikatu zdefiniowany w nagłówku.
• Stopka – każdy komunikat, administracyjny lub aplikacyjny, jest zakończony standardową stopką. Stopka służy do oddzielania komunikatów i zawiera trzycyfrową reprezentację znakową wartości CheckSum <10>.

Format komunikatu FIX ¶

Komunikat FIX to zbiór pól. Każde pole to para tag-wartość sformatowana jako {tag}={wartość}. Na przykład, 54=2, co oznacza, że typ zlecenia to sprzedaż.

Tag ¶

• FIX używa predefiniowanych tagów.
• Każdy tag reprezentuje określone pole.
• Każdemu tagowi przypisany jest predefiniowany numer.
• Specyfikacja FIX cTrader zawiera listę pól i odpowiadających im numerów tagów.

Wartość ¶

• Wartości reprezentują wartość przypisaną do tagu.
• Wartości mogą być tylko jednym z następujących typów danych: liczba całkowita, liczba zmiennoprzecinkowa, znak, czas, data, dane lub ciąg znaków.

Wszystkie wiadomości w API FIX cTrader zaczynają się od 8=FIX.x.y, gdzie x.y to wersja protokołu FIX. Na końcu każdej wiadomości powinno znajdować się pole 10=xyz, gdzie xyz reprezentuje sumę wszystkich wartości binarnych w wiadomości, zwaną sumą kontrolną.

Suma kontrolna pomaga zidentyfikować wszelkie problemy z transmisją, w szczególności utratę pakietów, pozwalając odbiorcy wiedzieć, czy brakuje jakiejkolwiek części wiadomości.

Jeśli tag Symbol(55) jest używany w wiadomości FIX do cTrader/cServer, musisz określić identyfikator symbolu FIX. Ta wartość może być różna u różnych brokerów. Pole identyfikatora symbolu FIX można znaleźć w aplikacji cTrader danego brokera w oknie informacji o symbolu.

Przykład wiadomości ¶

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|