Изучаю FIX протокол с нуля. Подводим итоги первой части. Первая борьба за миллисекунды.

Начало положено тут
Продолжение тут

Вступление

     Разработка обертки протокола, только на первый взгляд, кажется простым. Нахрапом такую задачу не взять. Тут, как я уже говорил, важно посидеть с кружкой чая, полистать документацию, построить различные схемы, структуры. На основе этого, разработать логику обертки, иерархию классов и тд. Разберем иерархию команд протокола. Для анализа была взята документация самой биржи.

Теоретически аспекты. Разложим немного по полочкам.

     Все сообщения протокола можно разложить на несколько тем. Я начну с первой группы:

1. Сообщения для поддержания связи.

• Logon; Тип=A; Сообщение для инициализации сессии. Грубо говоря для подключения к серверу
• Logout; Тип=5; Сообщение для завершения сессии. Сообщаем серверу о прекращении связи
• Hearbeat; Тип=0; Сообщение для поддержания связи. 
• Request; Тип=1; Сообщение для поддержания связи. Запрос второй стороны, жива ли первая
• Reject; Тип=3; Сообщение об ошибке. Получаем его, если мы не правильно оформили свое сообщение
• Resend Request; Тип=2; Повторный запрос сообщений, в случае утери. Задается интервал номеров сообщений.
• Sequence Reset; Тип=4; Используется для сброса номеров сообщений. 

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

• метод шифрования (0 по умолчанию)
• интервал в секундах. Этот параметр указывает с каким интервалом мы будем обмениваться сообщениями поддержания связи (Hearbeat и Request)
• флаг сброса счетчика сообщений. (Y — сбросит на ноль).

При успешной операции, сервер нам отвечает тем же.

     Далее, сервер с указанной периодичностью, начнет слать в наш адрес сообщения запросы подтверждения связи. Я написал быстренько небольшое приложение, которое поможет показать на практике этот процесс. Я сделал таймер, который каждую секунду проверяет, не пришло ли нам что нибудь на сокет. 
Тут я моделирую, что мы глухи

А тут, я ему отвечаю на его запросы
  В принципе, вот и все общение. Далее, с опытом, придется еще отработать механизмы обрыва связи и механизм потери сообщений. 

Боевой кодинг. Начало борьбы за миллисекунды

     С получением опыта пришлось существенно доработать классы. Где то появилась избыточность кода. Все идет на минимизацию расчетов.
К примеру. Приведу старые скрины кода из первой части. В каждом классе у меня были 2 метода:

• ToString() — создавал на основе класса строку соответствующего сообщения в формате FIX для передачи на сервер
• GetMessageSize() — подсчет длины строки для формирования заголовка сообщения

     И при построении какого либо сообщения для отправки, у меня один и тот же метод использовался минимум 3 раза. То есть, я воспроизводил один и тот же расчет минимум 3 раза. Не проще ли произвести 1 раз и потом использовать его результат?


     Для этого я пошел на избыточность. Я создал в каждом классе еще по два поля, которые заполнялись при первом расчете.

И уже стал использовать их при построении сообщения.


Вроде как мелочь, да и переписывать классы пришлось часа 4. Но такой ход позволил скосить в среднем до 10 миллисекунд на операцию и теперь на отправку и получения ответа уходит стабильно менее 90мл сек (раньше было около 100 постоянно и выше). Мелочь, а приятно.
На этом пока все. Теперь предстоит долгий путь создания кода под торговые операции.