Лучший онлайн-брокер для работы на бирже
214,84
рейтинг
19 ноября 2014 в 14:30

Разработка → Способы передачи финансовых данных #2: протокол FAST

image

В одном из прошлых топиков мы рассмотрели протокол FIX, который был создан для передачи финансовой информации и автоматизации коммуникаций на фондовом рынке. Однако этот протокол оказался не самым идеальным инструментом в условиях все увеличивающихся объёмов финансовых данных, поэтому в качестве его развития был создан новый стандарт — протокол FAST (FIX Adapted for STreaming). Сегодня мы поговорим об этой технологии.

История


В ноябре 2004 года тогдашний CEO финансового холдинга Acrhipelago Holding Майк Кормак на конференции сообщества FIX под названием FPL (FIX Protocol Limited) в Нью-Йорке заявил о том, что текущая версия протокола не справляется с возросшим объёмом финансовой информации, генерируемой на фондовом рынке. При передачи больших объёмов данных с помощью FIX возникали значительные задержки в их обработке, что приносило трейдерам убытки и лишало их возможности разработки действующих торговых стратегий.

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

При создании протокола FAST разработчики преследовали цель добиться возможности передачи больших объёмов данных, избегая появления задержек в получении информации. Разработкой протокола занималась рабочая группа сообщества FIX под названием «Группа оптимизации передачи рыночных данных» (Market Data optimization working group — mdowg), которая была сформирована в 2004 году.

В 2005 году эксперты группы представили пилотный проект (proof of concept) протокола, а уже через год был осуществлен релиз первой версии FAST 1.0. В дальнейшем было выпущено несколько обновлений, и в настоящий момент большинством игроков финансового рынка используется версия протокола 1.2. Также существует несколько открытых реализаций протокола (например, OpenFAST, OpenFAST.NET и QuickFAST).

Как это работает


Согласно стандарту FIX-протокола каждое сообщение имеет формат Tag = Value SOH, где Tag — это номер передаваемого поля, Value — его значение, а SOH — символ-разделитель (подробнее — в нашем прошлом материале). Пример записи сообщения в синтаксисе Tag = Value:

35=x|268=3 (message header) 279=0|269=2|270=9462.50|271=5|48=800123|22=8 (trade) 279=0|269=0|270=9462.00|27

Протокол FAST позволяет избавиться от избыточности с помощью шаблона, который описывает структуру сообщения целиком. Этот метод называется «неявным тегированием» (implicit tagging), поскольку теги FIX в передаваемых данных только «подразумеваются». Итого, синтаксис Tag = Value меняется следующим образом:

  • Шаблон описывает структурированный набор полей с их операторами;
  • Последовательность полей в сообщении соответствует последовательности тегов в шаблоне;
  • В сообщении передаются только изменения данных.

Протокол FAST используется для получения рыночных данных.

На каких биржевых площадках есть FAST


Протокол FAST поддерживается целым рядом крупнейших мировых фондовых площадок, среди которых:


Рассмотрим подробнее реализацию FIX на «Московской Бирже».

Реализация «Московской Биржи»


«Московская Биржа» реализовала возможность предоставления доступа к финансовой информации по протоколу FAST. Трейдеры могут получать по FAST таблицы финансовых инструментов (цены, объёмы торгов и т.п.), котировки, все сделки, индексы, а также информацию обо всех активных обезличенных заявках. Согласно информации на сайте Биржи, средняя задержка публикации обновлений составляет менее 300 микросекунд (для фондового и валютного рынков).

Для передачи финансовых данных используются UDP-каналы, а по TCP передаются наборы недоставленных данных. Данные структурированы на группу потоков (каналов или «фидов»), которые содержат в себе информацию о группе финансовых инструментов. Эти инструменты автоматически группируются торговой системой Биржи в соответствии с определенным параметрами.

image

UDP позволяет сократить задержки при передаче информации, а их дублирование снижает потери сообщений. Если описывать схему более подробно, то сервис FAST состоит из следующих каналов:

  • Market Data Incremental — система UDP-каналов для получения изменений данных по текущим торгам;
  • Incremental Refresh — данный канал позволяет получать информацию о текущих торгах на рынке;
  • Instruments Replay — поток используется для получения сообщений о финансовых инструментах, допущенных к торгам;
  • Market snapshot — поток используется для восстановления актуальной информации по всем инструментам;
  • Instruments Incremental — канал для получения изменений параметров инструментов (изменение гарантийного обеспечения и лимитов цен);
  • Message Replay — позволяет запрашивать сообщения, которые были пропущены в потоке Incremental Refresh.

image

Изображение / moex.com (по клику откроется в полном размере)

Все сообщения, отправляемые с торговой системой «Московской биржи» кодируются в формате FAST. Особенностью формата «Московской Биржи» заключается в добавлении к сообщению преамбулы из 4 байт. Эта преамбула содержит тег под номером 34 (SeqNum), который позволяет получать номер последовательности сообщений без необходимости декодирования всего сообщения — это выливается в дополнительную экономию времени на обработку потоков данных.

image

Как правило, передача шаблона FAST осуществляется с помощью XML. Типичный сценарий использования протокола (подключение до начала торгового дня) можно описать следующей последовательностью действий:

  1. Загрузка конфигурационного XML-файла со списком multicast IP-адресов и другими параметрами соединения (потоки, порты и т.п.).
  2. Загрузка шаблона FAST с FTP-ресурса.
  3. Начало «прослушивания» потока Snapshot, а затем Incremental Refresh для получения данных.

Пример шаблона на XML:

<!--  Market Data - Incremental Refresh Generic -->
<template xmlns="http://www.fixprotocol.org/ns/fast/td/1.1" name="X-Generic" id="2104">
<string name="MessageType" id="35">
<constant value="X"/>
</string>
<string name="ApplVerID" id="1128">
<constant value="9"/>
</string>
<string name="BeginString" id="8">
<constant value="FIXT.1.1"/>
</string>
<string name="SenderCompID" id="49">
<constant value="MOEX"/>
</string>
<uInt32 name="MsgSeqNum" id="34"/>
<uInt64 name="SendingTime" id="52"/>
<sequence name="GroupMDEntries">
<length name="NoMDEntries" id="268"/>
<uInt32 name="MDUpdateAction" id="279" presence="optional"/>
<string name="MDEntryType" id="269" presence="optional"/>
<string name="MDEntryID" id="278" presence="optional"/>
<int32 name="RptSeq" id="83" presence="optional"/>
<uInt32 name="MDEntryDate" id="272" presence="optional"/>
<uInt32 name="OrigTime" id="9412" presence="optional"/>
<uInt32 name="SettlDate" id="64" presence="optional"/>
<string name="SettleType" id="5459" presence="optional"/>
<uInt32 name="MDEntryTime" id="273" presence="optional"/>
<uInt32 name="EffectiveTime" id="5902" presence="optional"/>
<uInt32 name="StartTime" id="9820" presence="optional"/>
<string name="Symbol" id="55" presence="optional"/>
<decimal name="MDEntryPx" id="270" presence="optional"/>
<decimal name="MDEntrySize" id="271" presence="optional"/>
<string name="QuoteCondition" id="276" presence="optional"/>
<string name="TradeCondition" id="277" presence="optional"/>
<string name="OpenCloseSettlFlag" id="286" presence="optional"/>
<string name="OrdType" id="40" presence="optional"/>
<decimal name="NetChgPrevDay" id="451" presence="optional"/>
<decimal name="AccruedInterestAmt" id="5384" presence="optional"/>
<decimal name="ChgFromWAPrice" id="5510" presence="optional"/>
<decimal name="ChgOpenInterest" id="5511" presence="optional"/>
<decimal name="BidMarketSize" id="5292" presence="optional"/>
<decimal name="AskMarketSize" id="5293" presence="optional"/>
<int32 name="TotalNumOfTrades" id="6139" presence="optional"/>
<decimal name="TradeValue" id="6143" presence="optional"/>
<decimal name="Yield" id="236" presence="optional"/>
<decimal name="TotalVolume" id="5791" presence="optional"/>
<int32 name="OfferNbOr" id="9168" presence="optional"/>
<int32 name="BidNbOr" id="9169" presence="optional"/>
<decimal name="ChgFromSettlmnt" id="9750" presence="optional"/>
<int32 name="SumQtyOfBest" id="10503" presence="optional"/>
<string name="OrderSide" id="10504" presence="optional"/>
<string name="OrderStatus" id="10505" presence="optional"/>
<decimal name="MinCurrPx" id="10509" presence="optional"/>
<uInt32 name="MinCurrPxChgTime" id="10510" presence="optional"/>
<uInt32 name="VolumeIndicator" id="7017" presence="optional"/>
<decimal name="Price" id="44" presence="optional"/>
<int32 name="PriceType" id="423" presence="optional"/>
<decimal name="NominalValue" id="9280" presence="optional"/>
<decimal name="RepoToPx" id="5677" presence="optional"/>
<decimal name="BuyBackPx" id="5558" presence="optional"/>
<uInt32 name="BuyBackDate" id="5559" presence="optional"/>
<string name="TradingSessionID" id="336" presence="optional"/>
<string name="TradingSessionSubID" id="625" presence="optional"/>
</sequence>
</template>

Как подключиться по FAST


ITinvest предоставляет своим клиентам доступ к рынкам «Московской биржи» с помощью прямого подключения по протоколуам FIX и FAST Кроме того, для высокочастотных торговцев и алготрейдеров созданы специальные ИТ-услуги от колокации серверов в дата-центре M1 до предоставления доступа к виртуальным машинам для размещения торгового робота (тарифы указаны на сайте).

Для тех, кто не читал наш предыдущий материал о протоколе FIX снова прикрепляем видео с рассказом о решениях по получению прямого доступа на фондовый рынок.



Другие протоколы


Помимо протоколов FIX и FAST, поддерживаемых международным сообществом, для прямого подключения к отечественным рынкам используются и так называемые нативные протоколы, которые возникли еще до объединения бирж ММВБ и РТС в «Московскую биржу».

На рынках, относившихся к бирже РТС (FORTS – фьючерсы и опционы, Standard), для прямого совершения операций и получения данных в режиме подключения используется протокол Plaza II. Для выполнения торговых операций и получения биржевых данных на площадках, ранее относившихся к бирже ММВБ (валютный и фондовый рынки) используется двунаправленный шлюз MICEXBridge (TEAP).

Об этих протоколах пойдет речь в наших следующих статьях. Кроме того, мы расскажем о протоколе Simple Binary Encoding, который, в определенной степени, является продолжателем дела FIX.

На сегодня все, спасибо за внимание, будем рады ответить на вопросы в комментариях.

P. S. Если вы заметили опечатку или ошибку — напишите личным сообщением, и мы оперативно все исправим.
Автор: @IT_invest
ITinvest
рейтинг 214,84
Лучший онлайн-брокер для работы на бирже

Комментарии (14)

  • 0
    Как для протокола который призван передавать данные как можно быстрее использовать FIX и FAST мне кажется не самым наилучшим вариантом.
    Использование XML в качестве хранения данных для передачи занимает слишком много трафика.
    Представим механизм работы протокола:

    Новые данные => парсинг XML = > вещание multicast => прием данных => парсинг XML данных => обработка
    

    Тут парсинг XML и количество передаваемых данных слабые места.
    Помимо того что CPU парсит текст тегов, он еще преобразует число в текст и обратно.
    По мне так это лишние затраты мощностей, и в протоколе никому не нужна читабельность текста, а скорость критически важна, даже если сэкономить микросекунды.
    Почему не используют бинарные протоколы?
    Если записывать числа побитово без конвертаций в текст то это сэкономит время CPU.
    А если в протоколе не использовать текстовых меток вовсе то сэкономит трафик.
    В итоге можно получить протокол в котором будет сохранена контрольная сумма, метки данных, тот же функционал но будет использовано меньше трафика и больше экономии CPU.
    • +1
      FAST как раз и хранит в XML только описание полей, сами данные передаются в «сжатом» бинарном виде. XML карта пред загружается в память заранее, и процесс отображения бинарных данных в текстовые (или любые другие виды внутреннего протокола компании) можно свести в идеале до O(N) (обращение по индексу в массиве).
      Спасибо itinvest за статью, но хотелось бы увидеть больше подробностей сборки-разборки пакета FAST, так как документация по этой части не очень распространена в интернете, особенно в русскоязычном сегменте. Мне приходилось с ним заниматься, и без четкого описания кодирования, потребовалось длительное время для понимания протокола.
      • +1
        Пока мы хотели в целом рассказать о существующих протоколах, в дальнейшем уже будем в них углубляться, конечно. Спасибо, что читаете)
  • 0
    Единственный вопрос. Зачем нужно это сжатие при ныншней толщине каналов?
    CME в свое время внушили себе, что это гениально и всех заставили эту гадость слушать. Бинарные структуры фиксированного формата (типа ITCH, используемый многими рынками) куда как эффективнее.
    • 0
      UDP пакеты (а это основной вид транспорта для FAST) ограничены в пределах MTU, обычно в районе 1500 байт, что довольно не много. Есть способы фрагментации пакетов на уровне сетевого оборудования, но надежность от этого сильно может пострадать. Таким образом, различного вида популярные протоколы (JSON, XML, FIX plain text) могут оказаться не применимы.
      Также, у биржи существуют собственные бинарные протоколы: Plaza II (FORTS), MTE Srl (MICEX). Однако, они не являются универсальным мировым решением, что обеспечивает дополнительные затраты на разработку программ. Тогда как FIX и FIX/FAST являются общемировым стандартом обмена финансовой информации с биржей с огромным количеством готовых библиотек и приложений.
      • 0
        Что то, например, NASDAQ не торопится придерживаться данного «общемирового стандарта» и упорно рассылает ITCH сообщения, упакованные в мультикаст пакеты. Каждое сообщение длиной несколько десятков байт.
        FAST/FIX испольует CME и его производные.
        Московская же биржа как обычно идет своим путем.
        • 0
          • +1
            То что FIX это стандартный протокол для отправки заявок, с этим никто не спорит. Мы же говорим о фидах и где по вашей ссылке вы видите FastFIx?
            Там либо ITCH либо еще какой то их собственный.
            • 0
              Согласно Wiki/Exchanges that have adopted FAST. Есть еще статья.

              Тем не менее, вы скорее всего правы, так как отсутствие каких-либо упоминаний в официальной документации, позволяет предположить, что их проект по реализации FAST не завершился (или был отменен).
              Спасибо за уточнение.
              Однако в ММВБ идет масштабная реструктуризация торговых решений. Возможно, взамен собственных нативных протоколов будет использоваться тот-же ITCH (исключительно предположение)
  • 0
    Каково время хранениня данных для Message Replay на MICEX? Другими словами, через какое максимальное время я могу запросить сообщения пропушенные в Incremental Refresh?
    • 0
      В течении торгового дня при условии, что счетчик сообщений не был сброшен.
  • 0
    >> Для передачи финансовых данных используются UDP-каналы, а по TCP передаются наборы недоставленных данных.
    А как определяется что данные не были доставлены? Ведь если мы говорим о высокочастотной торговле, то там нет времени что-то кодировать, сличать контрольные суммы и перепосылать.
    • 0
      При высокочастотной торговли, операции кодирования и вычисления контрольной суммы тоже выполняются. Не только на клиентской части, но и в бирже.
      Тем не менее, UDP канал обычно используют для получения данных о «стаканах» и прочей биржевой информации, так как эта информация обычно устаревает раньше, чем будет отправлен запрос на восстановление пропущенных сообщений.
      Если отправляется заявка в биржу, то ее подтверждение (или отклонение) присылается обратно клиенту.
      Если заявка была отправлена, а ответ потерялся, счетчик сообщений с биржи разойдется с клиентским (у биржи будет больше клиента).
      Если заявка не была получена, счетчик сообщений так же разойдется (у клиента будет больше биржи).
    • +1
      У каждого сообщения порядковый номер есть. Если пришел больший чем ождается — значит потерялся.

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

Самое читаемое Разработка