Коннекторы Fix/Fast, Plaza2, Twime C# часть 2. Технические нюансы FIX, написание коннектора на C#.

В прошлой статье я рассказывал кратко, что представляет каждый из коннекторов. В этой статье я расскажу глубже про сам FIX, их семейство и как собрать коннектор под FIX для MOEX  на C#, а также расскажу про нюансы протокола, скорость и т.д. Погнали

Что такое FIX? 

Fix — это текстовый протокол общения, который был описан и придуман Робертом Ламуро и Крисом Морсатттом. Они создали протокол FIX для внедрения электронной передачи данных об акциях между компаниями Fidelity Investments и Salomon Brothers аж в 1992 году! Первая публичная версия появилась в 1995 году и во многом была прорывной для тех лет. Задумка гениальная и простая создать некий унифицированный вариант API, если его можно так назвать, для общения между клиентом и биржей. 

На этом история заканчивается и мы переходим к версии FIX 4.4, которая дожила до наших лет. 
Fix общается посредством текстовых строк, которые собраны определенным образом со специальными полями. 

Вот пример строки, которая отвечает за отправку ордера. Также есть другие виды сообщений в виде строки (входящие, исходящие). Logon (подключение), отклик о выставленной заявки (Execution Report), отправка ордера (Single Order) и т.д.  Было разработано огромное количество полей, чтобы FIX был универсален для любой биржи.



35 = D означает, что мы отправляем сигнал FIX на выставление Single Order. 35 это поле, которое отвечает за тип — новый ордер, отмена, перестановка  и т.д. Также в сообщении передается основной логин в формате MD______, лицевой счет, направление, код заявки и т.д. Посмотреть все поля вы можете здесь MsgType <35> field – FIX 4.4 – FIX Dictionary – Onix Solutions

Как сформировать строку?

Для того чтобы сформировать строку надо определить какие поля обязательны, а какие нет, а где-то биржа и вовсе может добавить свои поля в протокол (такая возможность тоже есть, об этом ниже). В доке на FTP MOEX есть описание полей. Соответственно вам нужно создать некий движок или использовать готовый, который будет правильно формировать текстовые сообщения FIX.

Здесь я прикладываю пример из движка QuikFix (.net), где мы указываем какие поля использовать в запросе, а какие нет. 


В данном контексте y/n выглядит весьма просто, как YES/NO. Но эта аббревиатура не всегда используется так прямо лобно, то есть эти режимы Y/N могут означать более тонкие настройки. 

Отлично! теперь вы понимаете, как это примерно работает и мы можем продолжить!

Семейство FIX

Помимо отправки ордеров нужно также получать рыночные данные. И из FIX родился протокол FAST.  FAST — Fix Adapted for Streaming, который отвечает за передачу маркет данных. Fast по смыслу/архитектурно похож на FIX, но все равно требует написания другого коннектора. Поэтому термины Fix/Fast часто идут вместе. Вы конечно можете получать данные и из QUIK, но скорость получения маркет данных из квика полностью убьет всю вашу скорость на FIX :)

Минус протокола FIX заключается в том, что способ передачи данных кодируется текстом и конечно же уступает бинарным способам передачи данных. Поэтому текстовый FIX пошел дальше и появился новый FIXP и FIX (SBE) — бинарный вариант. 

Глубоко погружаться на этом этапе в новые технологии не буду, но лишь обозначу, что новый Twime — это тот же FIXP + FIX (SBE). А SIMBA, которая предназначена для ультра быстрой передачи маркет данных — это FIX (SBE). 

Так что фактически биржа напридумывала большое количество красивых наименований, хотя технологии очень близки друг к другу. С другой стороны никто и не запрещал придумывать. Это же маркетинг! Симбы, тваймы, пумбы… ну вы поняли. 

Особенности унификации FIX

Нет в мире двух бирж, которые использовали бы совместимые реализации FIX. Это просто некий способ кодирования полей и значений. Важный момент конечно заключается в том, что способ передачи данных кодируется текстом  и конечно же уступает бинарным способом отправки данных.

Получается, что формально это протокол, имеющий спецификации и версионность. Но протокол этот определяет не формат контента, а скорее транспортный уровень. Протокол сам по себе довольно широкий, потому многие биржи его заимствуют не полностью или берут только что-то прикладное. К тому же у каждой биржи своя специфика инструментов и торгов, поэтому вполне логично, что у каждой есть свои нюансы, несовместимые с другими.

Скорость работы FIX (плюсы и минусы)

Основные проблемы в скорости у FIX связаны с тем, что биржа как бы адаптировала свое ядро под FIX. ТО есть биржа на своей стороне должна точно также декодировать ваше сообщение, потом отправить его в свое ядро и обратно. И учитывая то, что это делается в текстовом формате, мы теряем здесь много времени. 


Как мы видим на картинке наш сигнал FIX улетает на промежуточный шлюз FIX, где мы и теряем время. В случае с той же Plaza2, которая является далеко не самой свежей, получается, что сам роутер CGATE отправляет запрос на прямую в общий шлюз биржи и он делает это не текстовым способом, а бинарным, что значительно ускоряет его скорость работы.

Не спешите думать, что с плазой все окей :) Иначе зачем нам вообще нужно было бы столько пумб, симб и прочих разработок?
С одной стороны все просто и прямолинейно, а с другой стороны многопланово!

Сам роутер, который стоит на компьютере работает с биржей быстро, но вот именно в вашего бота данные он передаст со значительной задержкой.
Искусственно это сделано или нет я точно не знаю. Об этом уже позже и в других статьях про плазу. 

Так или иначе FIX — это в первую очередь про универсальность и любительскую скорость для HFT. Хотя в принципе заморочиться можно и скорость будет близка к скорости той же plaza2 на срочном рынке. Но если вам нужна максимальная скорость, под каждый рынок, то придется использовать каждый коннектор заточенный под конкретный рынок. 

 Простейший коннектор на C#

У нас есть два варианта реализации коннектора по которым мы можем пойти.

— Мы можем сами написать движок, который будет собирать строки и отправлять их на сервер. Вот пример коллеги 
— Можем использовать готовый движок, которому зададим настройки для полей и он сам нам будет паковать сигналы FIX нужным образом. 

Я использовал проект QUIcK FIX Documentation – Quick Fix Engine (quickfixn.org)  — они предлагают универсальную архитектуру с помощью которой можно настроить любой FIX под ваш запрос. Кстати библиотека есть также под C++, Go, JAVA.

К моему великому сожалению просто так задать тип биржи MOEX и стартовать нельзя, никто не поддерживает такие кулуарные разработки. 
Придется реализовать интерфейс и отлаживать свой коннектор с помощью архитектуры QuikFix и «синхронизировать» настройки от MOEX с настройками, которые читает QuickFix формат xml.



Плюс такого метода заключается в том, что в каком-то плане QUIKFix берет на себя весь нудный процесс сборки таких сообщений, минусы заключаются в том, что как любой унифицированный проект он плохо подходит под HFT.


Это отличный вариант, чтобы стартануть, завести ваш движок, а дальше его дорабатывать и тюнинговать. 

Помимо простых запросов в духе — LogOn и прочее, есть также запросы, которые понадобятся для боевой версии FIX.
А именно — смена пароля при первом подключении к боевому аккаунту и т.д.

Все вот эти нудные моменты он берет на себя и является хорошей платформой для старта, чтобы потом написать что — то свое. 

Я пошел именно по такому пути, но в итоге все равно пришлось часть запросов переписать самостоятельно, потому что внутри проекта существует большое количество лишних звеньев, которые конечно же будут в любом безопасном и унифицированном проекте. После переписывания запросов вы можете приобрести от 3 до 5 мс в разных запросах :)

Спасибо за ваше внимание, увидимся в следующих постах.