Скачать Data Fix

Does your phone have a problem with the mobile data connection? it's showing the 3g / egde / hsdpa icon but doesn't work? Android data fix jesse mclean Five star private safety app huawei ascend y330 only. Safe Download Ltd. 1. Free.

Download valiant Word file recovery tool developed by Recover Data Recover Data for MS Word is one of the outstanding and secure solution to fix the errors in unusable Word documents. The self-automated tool absolutely retrieved the data from corrupt or unapproachable Word files and restores them into a healthy file. This software is capable of repairing the files that becomes inaccessible or gets deleted due to virus infection, header or footer corruption, abrupt system failure, etc.

CorelDraw Fix Toolbox 2.0.0, RU. CorelDraw Fix Toolbox provides premium data recovery services supporting the analysis of *.cdr files on any.

Download valiant Word file recovery tool developed by Recover Data Recover Data for MS Word is one of the outstanding and secure solution.

Скачать бесплатно ZIP Archive Repair Tool 11.10.01 Like Office documents, Spreadsheets and other data files, Zip archives also face.

Работа с платформой MOEX Market Data FIX /FAST Multicast. Скачать файл конфигурации Каналов и Потоков с ftp-сервера.

Moscow Exchange Market Data Multicast FIX/FAST Platform

Moscow Exchange Market Data Multicast FIX/FAST Platform Руководство пользователя Московская биржа Version 3.3. September 29, 2014 Содержание 1. 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. 2. 2.1. 2.2. 2.3. 3. 3.1. 3.2. О платформе MOEX Market Data Multicast FIX/FAST ............................................................................................................................... 5 История изменений .................................................................................................................................................................................... 5 Потоковая передача данных ...................................................................................................................................................................... 6 Инкрементальные сообщения ................................................................................................................................................................... 6 FIX формат .................................................................................................................................................................................................. 6 Кодирование в FAST формат .................................................................................................................................................................... 6 Получение данных с помощью Multicast ................................................................................................................................................. 7 Восстановление данных............................................................................................................................................................................. 7 Работа с платформой MOEX Market Data FIX/FAST Multicast ................................................................................................................. 8 Подключение до старта Торговой системы ............................................................................................................................................. 8 Подключение после старта Торговой системы ....................................................................................................................................... 8 Обработка дублирующихся данных в потоках A и B ............................................................................................................................. 9 Функциональность системы ....................................................................................................................................................................... 11 Архитектура системы............................................................................................................................................................................... 11 FAST формат............................................................................................................................................................................................ 14 3.2.1 Общее описание .................................................................................................................................................................................. 14 3.2.2 Кодирование стоп-бита....................................................................................................................................................................... 14 3.2.3 Неявное тэгирование........................................................................................................................................................................... 14 3.2.4 Возможности кодирования полей...................................................................................................................................................... 15 3.2.5 FAST-шаблон ....................................................................................................................................................................................... 15 3.2.6 Процесс декодирования ...................................................................................................................................................................... 17 3.2.7 Пример FAST-шаблона....................................................................................................................................................................... 18 3.3. Основные потоки UDP ............................................................................................................................................................................. 20 3.3.1 Потоки Instrument Definitions ............................................................................................................................................................. 21 3.3.2 Потоки OrderBook, Market Statistics, Orders, и Trades ..................................................................................................................... 21 3.3.3 Потоки Recovery .................................................................................................................................................................................. 23 3.3.4 Сессии для запроса пропущенных сообщений по TCP ................................................................................................................... 23 3.4. Восстановление пропущенных данных ................................................................................................................................................. 23 3.4.1 Восстановление пропущенных данных из потоков Recovery (UDP) ............................................................................................. 24 3.4.2 Процесс восстановления данных ....................................................................................................................................................... 25 3.4.3 Восстановление пропущенных данных по TCP-соединению......................................................................................................... 26 4. 4.1. Публичный FIX интерфейс ......................................................................................................................................................................... 27 Группы полей ............................................................................................................................................................................................ 27 4.1.1 Заголовок.............................................................................................................................................................................................. 27 4.1.2 Группа Instrument ................................................................................................................................................................................ 28 4.1.3 Группа Instrument Extension ............................................................................................................................................................... 30 4.1.4 Группа Market Segment ....................................................................................................................................................................... 30 4.2. Сообщения сессионного уровня ............................................................................................................................................................. 32 4.2.1 Logon (A) .............................................................................................................................................................................................. 32 4.2.2 Logout (5).............................................................................................................................................................................................. 32 4.2.3 Heartbeat (0) .......................................................................................................................................................................................... 33 4.3. Сообщения бизнес уровня .......................................................................................................................................................................... 33 4.3.1 Security Definition (d) ............................................................................................................................................................................. 33 4.3.2 Security Status (f) .................................................................................................................................................................................... 34 4.3.3 Trading Session Status (h) ....................................................................................................................................................................... 36 4.3.4 Market Data Request (V) ........................................................................................................................................................................ 37 4.3.5 Market Data - Snapshot/Full Refresh (W) ............................................................................................................................................... 37 4.3.6 Market Data - Incremental Refresh (X) ................................................................................................................................................ 44 5. 5.1. 5.2. 5.3. 5.4. 6. 6.1. Настройка сетевого соединения ................................................................................................................................................................. 51 Настройка VPN соединения с MOEX на базе Windows XP ................................................................................................................. 51 Настройка VPN соединения с MOEX на базе Windows 7 .................................................................................................................... 64 Настройка VPN соединения с MOEX на базе OpenSUSE .................................................................................................................... 74 Часто возникающие вопросы и методы их решения ............................................................................................................................ 78 Сертифицированные средства работы ....................................................................................................................................................... 83 Библиотека FIX Antenna TM от EPAM – B2BitsÛ .................................................................................................................................. 83 6.1.1 Quick Start – примеры кода ................................................................................................................................................................ 84 6.1.2 Обзор API ............................................................................................................................................................................................. 88 1. О платформе MOEX Market Data Multicast FIX/FAST Система MOEX Market Data Multicast FIX/FAST Platform представляет собой новый, высокоэффективный механизм для передачи рыночных данных о торгах на Московской Бирже (далее используется сокращение MOEX). Данный механизм сочетает в себе структуру и синтаксис сообщений FIX протокола, хорошие возможности для оптимизации потоков данных FAST протокола, и возможности быстрой и эффективной передачи данных большому количеству пользователей UDP протокола. Система MOEX Market Data Multicast FIX/FAST Platform включает следующие аспекты: потоковые данные, инкрементальные сообщения, FIX формат сообщений, кодирование сообщений в формат FAST, получение данных большим количеством пользователей, возможность восстановления пропущенных данных. 1.1. История изменений Issue 1.0 2.0 3.3 Date 25 мая 2011 12 декабря 2012 08 апреля 2013 Description Исходная версия документа Добавления для улучшения понимания спецификаций и устранения ошибок в документе Добавлены поля, специфичные для сделок переговорных режимов и РЕПО Изменение форматов сообщений для разделения полей Режима, торгового статуса инструмента и периода торгов по разным полям в FIX сообщениях. Дополнительные поля для полной поддержки публикации данных режиомов РЕПО с ЦК, аукциона закрытия, дискретных аукционов, аукционов крупных пакетов, и данных рынка Т+2. Новый шаблон компресии FAST Редакторские правки документации и устранение неточностей Устранение ошибок и добавление пояснений по результатам обратной связи с клиентами. Удаление неиспользуемых полей из документа. Исправлен шаблон компрессии В документе сохранены правки в режиме рецензирования для выделения измененных частей . Уточнены единицы (лоты или количества ценных бумаг), используемые при публикации объемов аукционов в полях 271. В блок Market Segment добавлено поле OrderNote (9680), указывающее уровень 3.3.1 24 мая 2013 3.3.2 3.3.3 04 сентября 2013 26 марта 2014 листинга финансового инструмента на фондовом рынке. Изменен шаблон FAST компрессии Исправлены неточности в документации. 1.2.Потоковая передача данных Использование потоковой передачи данных позволяет передавать информацию от источника к получателю, не разбивая ее на отдельные сообщения для каждого события. Несколько таких событий могут быть включены в одно сообщение. Это позволяет существенно снизить задержки и увеличить скорость передачи данных. 1.3. Инкрементальные сообщения Использование инкрементальных сообщений позволяет значительно снизить объемы отправляемых данных. Используются только данные, изменившиеся под воздействием рыночных событий. Минимальное количество команд используется для их обновления: добавление новой записи, изменение записи, удаление записи. 1.4. FIX формат Система MOEX Market Data Multicast FIX/FAST Platform использует формат и синтаксис FIX сообщений. Сообщение состоит из заголовка, тела сообщения и трейлера. Поля в сообщении разделены между собой с помощью ASCII символа - <SOH>. Для более подробного ознакомления с составом сообщений см. 4. Публичный FIX . 1.5. Кодирование в FAST формат FAST (FIX Adapted for Streaming) представляет собой алгоритм сжатия, который позволяет в значительной степени оптимизировать FIX сообщения. FAST уменьшает размер данных без внесения задержек, что позволяет увеличить количество отправляемых данных и уменьшить время их передачи. FAST Protocol для сжатия сообщений использует следующее: - Неявное тэгирование; - Возможности кодирования полей; - Использование Pmap; - Кодирование стоп-бита; - Использование бинарного кодирования. В большинстве случаев правила кодирования в FAST формат согласовываются между контрагентами путем предоставления XML шаблонов. Для более подробного ознакомления с использованием FAST кодирования см. 3.2. FAST . 1.6. Получение данных с помощью Multicast Для распространения сообщений используется UDP протокол, который позволяет передавать пакеты сразу нескольким получателям. В один UDP пакет могут быть включены сразу несколько FIX сообщений, закодированных в FAST. Но в настоящее время система MOEX Market Data Multicast FIX/FAST Platform обеспечивает отправление только одного закодированного в FAST сообщения. FAST сообщение специально формируется таким образом, чтобы размер UDP пакета не превышал типичного для сети Ethernet значения парамерта MTU в 1500 байт. . Во избежание путаницы MOEX Market Data Multicast FIX/FAST Platform посылает данные из разных таблиц на бирже разным multicast группам. 1.7. Восстановление данных Для клиентов очень важно постоянное ¨присутствие£ на рынке. Если случиться так, что какие-то данных будут потеряны в процессе работы, то просто необходимо их быстрое восстановление. MOEX Market Data Multicast FIX/FAST Platform обеспечивает восстановление данных 2 способами: ñ Восстановление большого объема данных с помощью отправки клиенту снэпшотов (к примеру, для клиентов присоединившихся после начала торгов); ñ Восстановление небольшого объема данных по TCP – соединению (к примеру, когда отдельные сообщения были утеряны при трансфере). 2. Работа с платформой MOEX Market Data FIX/FAST Multicast 2.1. Подключение до старта Торговой системы Клиентам рекомендуется подключиться к системе MOEX Market Data Multicast FIX/FAST Platform еще до открытия торгов. Это гарантирует, что клиент начнет получать актуальные данные без необходимости обращения к каким -либо способам восстановления пропущенных данных. Данный сценарий является основным. Клиенту следует выполнить следующую последовательность действий: 1. Скачать файл конфигурации Каналов и Потоков с ftp-сервера. Конфигурационный файл в формате .xml описывает параметры подключения (IP адреса multicast, номера портов и т.д.). Скачать файл FAST-шаблона с ftp-сервера. Для получения дополнительной информации см. пункт 3.2.5 с описание шаблона. 2. Начать слушать Потоки Instruments Definitions, OrderBook и/или Orders, Statistics, Trades (клиент может слушать только интересующие его потоки) и применять получаемые данные в обычном порядке. 2.2.Подключение после старта Торговой системы При подключении к Системе позже начала Торгов для получения полной рыночной информации следует придерживаться следующей процедуры: 1. Скачать файл конфигурации Каналов и Потоков с ftp-сервера. Конфигурационный файл в формате .xml описывает параметры подключения (IP адреса multicast, номера портов и т.д.). Скачать файл FAST-шаблона с ftp-сервера. Для получения дополнительной информации см. пункт 3.2.5 с описанием шаблона. 2. Начать слушать Поток Instruments Definitions. 3. Начать слушать Потоки OrderBook и/или Orders, Statistics, Trades (клиент может слушать только интересующие его потоки) и накапливать получаемые сообщения. 4. Начать слушать Потоки OrderBook Recovery и/или Orders Recovery, Statistics Recovery, Trades Recovery. Получить по этим Потокам актуальный снэпшот, применить полученный снэпшот. Процесс можно проводить как последовательно (сначала получить снэпшоты по всем инструментам, а потом обрабатывать накопленные обновления), так и параллельно (по мере получения снэпшотов по инструментам обрабатывать накопленные обновления по полученному инструменту). 5. Перестать слушать Потоки Recovery. 6. Продолжить обычную обработку потоков инкрементальных обновлений. 2.3. Обработка дублирующихся данных в потоках A и B Данные во всех UDP-потоках распространяются в двух экземплярах (A и B) на двух разных multicast-адресах. Клиенту рекомендуется обрабатывать оба потока в виду негарантированности доставки UDP-пакетов. Обработка двух идентичных потоков позволяет снизить вероятность потерь по меньшей мере в 2 раза. В каком именно из потоков (A или B) сообщение появится первым, не оговаривается. Для обработки потоков следует использовать порядковый номер сообщения из преамбулы или тэга 34-MsgSeqNum. Использование преамбулы позволяет определить порядковый номер не прибегая к декодированию FAST-сообщения. Обработку потоков A и B следует производить по следующему алгоритму: 1. Слушать потоки A и B. 2. Обрабатывать сообщения по порядковому номеру. 3. Отбрасывать полученное сообщение, если сообщение с таким порядковым номером уже получалось ранее. 4. Если обнаруживается пропуск в порядковых номерах в обоих каналах, то это, скорее всего, свидетельствует о потере пакетов как в потоке A, так и в потоке B. Клиенту следует инициировать одну из процедур восстановления пропущенных данных. Впрочем, клиент может подождать некоторое (разумное) время, возможно пропущенный пакет придёт несколько позже, так как протокол UDP не гарантирует последовательность доставки пакетов. Пример: Поток A 34-MsgSeqNum = 59 34-MsgSeqNum = 60 34-MsgSeqNum = 62 34-MsgSeqNum = 63 34-MsgSeqNum = 65 Поток B 34-MsgSeqNum = 59 34-MsgSeqNum = 60 34-MsgSeqNum = 61 34-MsgSeqNum = 62 34-MsgSeqNum = 65 1. 2. 3. 4. 5. 6. Сообщения получаются из потоков A и B. Получили 59-е сообщение из A, обработали его. Получили 59-е сообщение из B, отбросили его, так как обработали его ранее. Получили 60-е сообщение из A, обработали его. Получили 60-е сообщение из B, отбросили его, так как обработали его ранее. Получили 62-е сообщение из A, отбросили его, так как ожидается 61-е. Получили 61-е сообщение из B, обработали его. 7. Получили 62-е сообщение из B, обработали его. 8. Получили 62-е сообщение из A, отбросили его, так как обработали его ранее. 9. Получили 63-е сообщение из A, обработали его. 10. Получили 65-е сообщение из A, отбросили его, так как ожидается 64-е. 11. Получили 65-е сообщение из B, отбросили его, так как ожидается 64-е. 12. Перешли к процедуре восстановления пропущенных данных, так как обнаружен пропуск сообщения. 3. Функциональность системы 3.1. Архитектура системы Для распространения рыночных данных используется транспортный протокол UDP, а для запроса пропущенных данных реализуются механизмы восстановления по протоколу UDP и повторного получения данных по протоколу TCP. В системе используются следующие виды информационных потоков: 1. Основные потоки. 1.1. Потоки распространения инкрементальных обновлений рыночных данных. 1.2. Потоки распространения описаний финансовых инструментов. 2. Потоки восстановления 2.1. Потоки распространения снэпшотов рыночных данных. 2.2. Сессии для запроса пропущенных данных. MOEX Market Data Multicast FIX/FAST Platform обеспечивает вещание по следующим Потокам: ñ Основные потоки: o Aggregated OrderBook Feeds(OBR), 20 лучших цен на покупку и продажу: Ï OrderBook Feed A; Ï OrderBook Feed B. o Market Statistics Feeds(MSR): Ï Statistics Feed A; Ï Statistics Feed B. o Active Orders List Feeds(OLR): Ï Orders Feed A; Ï Orders Feed B. o Trades List Feeds(TLR): Ï Trades Feed A; Ï Trades Feed B. Потоки Recovery: o Aggregated OrderBook Recovery Snapshot Feeds(OBS): Ï OrderBook Recovery Feed A; Ï OrderBook Recovery Feed B. o Market Statistics Recovery Snapshots Feeds(MSS): Ï Statistics Recovery Feed A; Ï Statistics Recovery Feed B. o Active Orders List Recovery Snapshots Feeds(OLS): Ï Orders Recovery Feed A; Ï Orders Recovery Feed B. o Trades List Recovery Snapshot Feeds(TLS): Ï Trades Recovery Feed A; Ï Trades Recovery Feed B. ñ Instruments Definitions Feeds(IDF): o Instruments Definitions Feed A; o Instruments Definitions Feed B. Помимо трансляции данных в UDP-потоках, MOEX Market Data Multicast FIX/FAST Platform может принимать входящие TCPсоединения, по которым клиенты могут запросить пропущенные данные. По TCP-соединению могут быть запрошены пропущенные сообщения в одном из следующих UDP-потоков: o OrderBook Feed (OBR) o Statistics Feed (MSR) o Orders Feed (OLR) o Trades Feed (TLR) ñ Существуют некоторые ограничения при запросе данных по TCP-соединению: 1. данные доступны за ограниченный период времени (не более чем с начала дня); 2. количество отсылаемых за один раз сообщений ограничено (около 500 сообщений в запросе); 3. общее количество запрашиваемых в день сообщений ограничено. 3.2. FAST формат 3.2.1 Общее описание Все сообщения, отправляемые MOEX Market Data Multicast, представляют собой сообщения в FIX-формате, закодированные по протоколу FAST (FIX Adapted for Streaming). Протокол FAST был разработан FIX Market Data Optimization Working Group для оптимизации электронного обмена финансовой информации, в частности, для распространения большого объёма данных с минимальной задержкой. Особенностью распространения данных в информационных потоках от MOEX Market Data Multicast является то, что перед каждым FAST-сообщением добавляется 4-байтовая преамбула, в которой содержится значение 34-го тэга (SeqNum) следующего за преамбулой FAST-сообщения (рис. 1). Это позволяет получить порядковый номер сообщения (как при обработке сообщений из потоков A и B, так и при обнаружении пропусков), не прибегая к декодированию самого FAST-сообщения – это значительно экономит время при обработке потока. Figure 1 3.2.2 Кодирование стоп-бита Кодирование стоп-бита является одним из составляющих процессов FAST, который позволяет исключить избыточность на уровне передачи полей с данными используя стоп-бит вместо привычного байтового разделителя. В FAST стоп-бит используется вместо стандартного FIX разделителя – байта <SOH>; таким образом 7 битов каждого байта используются для передачи данных, а 8й бит служит обозначением окончания поля. 3.2.3 Неявное тэгирование По стандарту FIX протокола каждое сообщение имеет вид ¨Тег = Значение <SOH>£, где: Тег – номер поля, которое в данный момент передается; Значение – фактическое содержание данных этого поля; <SOH> – ASCII символ, который используется в качестве байтового разделителя поля. Например: 35=x|268=3 (заголовок сообщения) 279=0|269=2|270=9462.50|271=5|48=800123|22=8 (сделка) 279=0|269=0|270=9462.00|271=175|1023=1|48=800123|22=8|346=15 (новое предложение 1) 279=0|269=0|270=9461.50|271=133|1023=2|48=800123|22=8|346=12 (новое предложение 2) FAST устраняет избыточность используя шаблон, который описывает структуру всего сообщения. Такой механизм называется ¨неявным тегированием£, т.к. FIX теги становятся неявной частью передаваемых данных. FAST-шаблон заменяет синтаксис ¨Тег = Значение£ на ¨неявное тегирование£ по таким правилам: • номера тэгов не передаются в сообщении, но заданы в шаблоне; • последовательность полей в сообщении такая же, как и тегов в шаблоне; • шаблон определяет упорядоченный набор полей с операторами. 3.2.4 Возможности кодирования полей FAST действует как машина состояний, которая в каждый момент должна знать, какие значения необходимо содержать в памяти. FAST сравнивает текущее значение поля с его предыдущим значением, и определяет, какое действие требуется предпринять: - использовать в качестве нового значения константу (заданную в шаблоне), - значение по умолчанию (применять, если новое значение поля отсутствует), - сделать копию (продублировать предыдущее значение этого тэга), - вычислить дельту (для целочисленных – арифметическая разность между текущим и предыдущим значением, также используется со строковыми значениями), - проинкрементировать предыдущее значение (только для целочисленных). Словарем называется кэш, в котором хранятся предыдущие значения полученные системой. Содержимое словаря сбрасывается в начале каждого UDP пакета. Так как в одном UDP-пакете отправляется только одно FAST-сообщение, то дельта в такой реализации использоваться не будет. 3.2.5 FAST-шаблон FAST-шаблон соответствует типу FIX сообщения, и однозначно определяет порядок полей в нем. Шаблон также содержит синтаксис, указывающий тип поля, и какой метод декодирования применять при передаче. Шаблон задается в XML виде. Каждое FAST сообщение в свою очередь содержит идентификатор шаблона, по которому будет происходить декодирование. Пример шаблона сообщения Market Data – Incremental Refresh (MsgType=X): Figure 2 3.2.6 Процесс декодирования Процесс декодирования происходит в следующей последовательности: Шаг 1. Транспорт: Клиент системы получает закодированное FAST сообщение. Шаг 2. Декодирование пакета: - Определение шаблона; - Извлечение бинарных закодированных бит; - Построение соответствия между полученными битами и полями в шаблоне. Шаг 3. Декодирование полей: применение операторов для определения значения на основании шаблона. Шаг 4. Построение FIX сообщения Шаг 5. Обработка FIX сообщения. Figure 3 3.2.7 Пример FAST-шаблона Table 1 Lli ne # 1 <template name=”X” id=”6” Template Syntax Use and Description Идентификатор и название шаблона. 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 xmlns=”http://www.fixprotocol.org/ns/fast/td/1.1”> <string name=”MessageType” id=”35”> <constant value=”X” /> </string> <string name=”ApplVerID” id=”1128”><copy/></string> <string name=”SenderCompID” id=”49”><copy/></string> <uInt32 name=”MsgSeqNum” id=”34”><increment/></uInt32> <uInt64 name=”SendingTime” id=”52”><copy/></uInt64> <byteVector name=”MessageEncoding” id=”347”presence=”optional”><default/></byteVector> <sequence name=”GroupMDEntries”> <length name=”NoMDEntries” id=”268”/> <uInt32 name=”MDUpdateAction” id=”279” presence=”optional”><copy/></uInt32> <string name=”MDEntryType” id=”269” presence=”optional”><copy/></string> <byteVector name=”MDEntryID” id=”278” presence=”optional”><copy/></byteVector> <byteVector name=”Symbol” id=”55” presence=”optional”><copy/></byteVector> <int32 name=”RptSeq” id=”83” presence=”optional”><copy/></int32> <decimal name=”MDEntryPx” id=”270” presence=”optional”><copy/></decimal> <decimal name=”MDEntrySize” id=”271” presence=”optional”><copy/></decimal> <uInt32 name=”MDEntryDate” id=”272” presence=”optional”><copy/></uInt32> <uInt32 name=”MDEntryTime” id=”273” presence=”optional”><copy/></uInt32> <byteVector name=”TradingSessionID” id=”336”presence=”optional”><copy/></byteVector> <byteVector name=”QuoteCondition” id=”276” presence=”optional”><copy/></byteVector> <byteVector name=”TradeCondition” id=”277” presence=”optional”><copy/></byteVector> <byteVector name=”OpenCloseSettlFlag” id=”286”presence=”optional”><copy/></byteVector> decimal name=”NetChgPrevDay” id=”451” presence=”optional”><copy/></decimal> MessageType определен как тип данных string, идентификатор = 35. ApplVerID определен как тип данных string, идентификатор = 1128 SenderCompID определен как тип данных string, идентификатор = 49 MsgSeqNum определен как тип данных unsigned integer, идентификатор = 34 SendingTime определен как тип данных unsigned integer, идентификатор = 52 MessageEncoding определен как тип данных byte vector, идентификатор = 347 Определение репитинг группы MDEntries. ‘NoMDEntries’ показывает количество повторяющихся элементов. MDUpdateAction определен как тип данных unsigned integer, идентификатор = 279 MDEntryType определен как тип данных string, идентификатор = 269 MDEntryID определен как тип данных byte vector, идентификатор = 278 Symbol определен как тип данных byte vector, идентификатор = 55. RptSeq определен как тип данных signed integer, идентификатор = 83 MDEntryPx определен как тип данных decimal, идентификатор = 270 MDEntrySize определен как тип данных decimal, идентификатор = 271 MDEntryDate определен как тип данных unsigned integer, идентификатор = 272. MDEntryTime определен как тип данных unsigned integer, идентификатор = 273 TradingSessionID определен как тип данных byte vector, идентификатор = 336 QuoteCondition определен как тип данных byte vector, идентификатор = 276 TradeCondition определен как тип данных byte vector, идентификатор = 277 OpenCloseSettlFlag определен как тип данных byte vector, идентификатор = 286 NetChgPrevDay определен как тип данных decimal, идентификатор = 451. 23 24 <decimal name=”AccruedInterestAmt” id=”5384”presence=”optional”><copy/></decimal> <decimal name=”ChgFromWAPrice” id=”5510” presence=”optional”><copy/></decimal> <int32 name=”TotalNumOfTrades” id=”6139” presence=”optional”><copy/></int32> <decimal name=”TradeValue” id=”6143” presence=”optional”><copy/></decimal> <decimal name=”Yield” id=”236” presence=”optional”><copy/></decimal> <int32 name=”OfferNbOr” id=”9168” presence=”optional”><copy/></int32> <int32 name=”BidNbOr” id=”9169” presence=”optional”><copy/></int32> <string name=”OrderSide” id=”10504” presence=”optional”><copy/></string> <string name=”OrderStatus” id=”10505” presence=”optional”><copy/></string> <decimal name=”MinCurrPx” id=”10509” presence=”optional”><copy/></decimal> <uInt32 name=”MinCurrPxChgTime” id=”10510”presence=”optional”><copy/></uInt32> AccruedInterestAmt определен как тип данных decimal, идентификатор = 5384 ChgFromWAPrice определен как тип данных decimal, идентификатор = 5510 TotalNumOfTrades определен как тип данных signed integer, идентификатор = 6139 TradeValue определен как тип данных decimal, идентификатор = 6143 Yield определен как тип данных decimal, идентификатор = 236 OfferNbOr определен как тип данных signed integer, идентификатор = 9168 BidNbOr определен как тип данных signed integer with identifier = 9169 OrderSide определен как тип данных string, идентификатор = 10504. OrderStatus определен как тип данных string, идентификатор = 10505 MinCurrPx определен как тип данных decimal, идентификатор = 10509. MinCurrPxChgTime определен как тип данных unsigned integer, идентификатор = 10510. 25 26 27 28 29 30 31 32 33 3.3. Основные потоки UDP В основных потоках (OrderBook, Statistics, Orders, Trades – Feed A и Feed B) в режиме multicast по протоколу UDP распространяются следующие рыночные данные: ñ В потоке OrderBook – обновления таблицы котировок. ñ В потоке Statistics – статистика рынка. ñ В потоке Orders – обновления таблицы заявок. ñ В потоке Trades – обновления таблицы сделок. Все перечисленные Потоки транслируются по протоколу UDP multicast. Каждый Поток транслируется на отдельном multicast-адресе. В соответствующих потоках A и B транслируются идентичные сообщения. Дублирование обеспечивает статистическое снижение вероятности потерь UDP-пакетов. 3.3.1 Потоки Instrument Definitions В потоках Instrument Definitions (Feed A и Feed B) с фиксированной периодичностью рассылаются описания финансовых инструментов в виде FIX-сообщений Security Definition (d), закодированных в формат FAST. Одно сообщение содержит описание одного финансового инструмента. Пример сообщения: 8=FIXT.1.1|9=400|35=d|1128=9|34=1551|460=5|423=2|911=1572|49=MOEX|55=VRSBP|48=RU000A0DPG75|22=4|461=EPXXXX|167=PS| 107=Voronezh EnergoSbyt.Comp(pref)|15=RUB|120=RUB|5217=2-01-55029Е|5385=FOND|969=0.001|5508=0.4|7595=18716678|350=54|351=£Воронеж.энергосб.комп£ ОАО ап|5382=20|5383=ВоронЭнСбп|52=2011050308:29:32.968|870=2|871=27|872=3|871=8|872=0|1310=1|561=1|1309=1|336=SMAL|10=000| Примечание: каждая ценная бумага (тег 55 ‘Symbol’) может торговаться в различных режимах, отличающихся правилами. Тег 336 содержит код режима торгов. Для каждой ценной бумаги могут быть доступны несколько режимов < Board> . Каждую комбинацию тегов 55 и 336 в Security Definition следует рассматривать как отдельный объект с отдельным потоком обновлений рыночных данных. 3.3.2 Потоки OrderBook, Market Statistics, Orders, и Trades Следующие рыночные данные распространяются в отдельных потоках : ñ Потоки OrderBook (A и B) – передают обновления из таблицы ORDERBOOK. Виды обновлений: 1. Add – создает/добавляет новую запись, записи отсортированы по цене ( MDUpdateAction(279) =0 ); 2. Change – изменяет параметры записи (MDUpdateAction (279) = 1 ); 3. Delete – удаляет запись (MDUpdateAction (279) = 2). Обновления применимы к элементам рыночных данных – MDEntryType (269) = '0' (Котировки на покупку), '1' (Котировки на продажу), ‘J’ – нет данных. ñ Потоки Statistics (A и B) – передают рыночную статистику, обновления из таблицы SECURITIES. Виды обновлений: Add, Change, и Delete. Элементы рыночных данных: '0' (Котировки на покупку); '1' (Котировки на продажу); '2' (Информация по последней сделке); '3' (Список индексов); '4' (Цена открытия/цена первой сделки); '5' (Цена закрытия/цена последней сделки предыдущего дня); '7' (Максимальная цена сделки); '8' (Минимальная цена сделки); '9' (Средневзвешенные цены); ‘A’ (Дисбаланс); 'B' (Объемы сделок); 'J' (Пустой снэпшот) 'N' (Максимальная цена спроса в течение сессии); 'O' (Минимальная цена предложения в течение сессии); 'Q' (Расчетная цена аукциона) ‘W’ (Цена аукциона закрытия); ’c’ (Объём аукциона закрытия); ‘f’ (Объём спроса рыночной заявки в аукцион закрытия); ‘g’(Объём преложения рыночной заявки в аукцион закрытия) 'i' (Спрос сессии); 'j' (Предложение сессии); 'h' (Цена предторгового периода); 'k' (Цена послеторгового периода); 'l' (Рыночная цена 2); Для валютного рынка –цена валютногофиксинга, рассчитанная за период 11:29 -12:00 московского времени 'm' (Рыночная цена); Для валютного рынка – цена валютного фиксинга 'o' (Официальная цена открытия); 'p' (Официальная текущая цена); 'q' (Признаваемая котировка); Для валютного рынка – междунароная цена валютного фиксинга 'r' (Официальная цена закрытия); 'v' (Совокупный спрос); 'w' (Совокупное предложение); 's' (Цена аукциона крупными пакетами); 'x' (Объем аукциона крупными пакетами); ‘y’ (Накопленный купонный доход на дату расчетов, в рублях, в пересчете на единицу финансового инструмента) 'u' (Дюрация); ñ Потоки Orders (A и B) – передают обновления из таблицы ORDERS. Виды обновлений: Add, Change, и Delete. Элементы рыночных данных: '0' (заявка на покупку), '1' (заявка на продажу) , ‘J’ – нет данных. Потоки Trades (A и B) – передают обновления из таблицы TRADES. Виды обновлений: только Add (MDUpdateAction(279) =0). Элементы рыночных данных: сделки/список обезличенных сделок) , ‘J’ – нет данных.. MDEntryType (269) = 'z' (Все ñ Данные распространяются в виде FIX-сообщений Market Data – Incremental Refresh (X), закодированных в формат FAST. Каждое сообщение может содержать обновления по нескольким финансовым инструментам. При изменении состояния соединения с Торговой системой в соответствующие UDP-потоки инкрементальных обновлений отправляется сообщение Trading Session Status (h). При изменении торгового статуса инструмента во все UDP-потоки инкрементальных обновлений отправляется сообщение Security Status (f). 3.3.3 Потоки Recovery В потоках Recovery (OrderBook, Statistics, Orders, Trades) в режиме multicast по протоколу UDP с фиксированной перидичностью распространяются текущие снэпшоты соответствующих данных в виде FIX-сообщений Market Data – Snapshot/Full Refresh (W), закодированных в формат FAST. Каждое сообщение содержит информацию по одному инструменту. Информация включает текущий торговый статус инструмента и текущее состояние соединения с Торговой системой. Клиенты не должны слушать эти потоки постоянно. К ним необходимо подключаться только в случае необходимости восстановить пропущенную в основных потоках информацию. После восстановления клиенту рекомендуется прекратить слушать данные потоки. 3.3.4 Сессии для запроса пропущенных сообщений по TCP Данный сервис позволяет клиенту запросить пересылку набора сообщений в заданном диапазоне номеров, уже опубликованных в одном из UDP-потоков. В запросе клиент указывает диапазон порядковых номеров для пересылки, а так же идентификатор UDP-потока, из которого запрашивается информация. Максимальное количество сообщений, которое может запросить клиент, ограничено (около 500 сообщений в запросе). Запрос отправляется в виде FIX-сообщения Market Data Request (V). Запрос отправляется по TCP-соединению, инициируемому клиентом. Ответные сообщения отправляются клиенту по этому же TCP-соединению в виде FIX-сообщений. По завершению отправки ответных сообщений MOEX Market Data Multicast закрывает это TCP-соединение. Все ответные сообщения закодированы в FAST-формат. Данный сервис клиент должен использовать лишь в крайнем случае, если другие методы восстановления невозможныСервис не обеспечивает высокую производительность 3.4.Восстановление пропущенных данных Данные во всех UDP-потоках распространяются в двух экземплярах (A и B) на двух разных multicast-адресах. Клиенту рекомендуется обрабатывать оба потока в виду негарантированности доставки UDP-пакетов. Может случиться так, что будут утеряны пакеты из обоих потоков, в этом случае нужно воспользоваться процедурой восстановления данных. Понять, что сообщение утеряно можно по пропускам в порядковых номерах сообщений 34-MsgSeqNum или по пропускам в номерах инкрементальных обновлений 83-RptSeq. Это означает, что рыночные данные больше не достоверны и клиент получает их не в полном объеме. Необходимо воспользоваться процедурой восстановления. MOEX Market Data Multicast предоставляет несколько механизмов для восстановления данных. Рекомендуется в первую очередь использовать потоки Recovery. Восстановления при помощи TCP-соединения более медленный процесс, при котором разрешено запрашивать ограниченное количество сообщений, им рекомендуется пользоваться в исключительных случаях, когда другие средства по каким-либо причинам недоступны. 3.4.1 Восстановление пропущенных данных из потоков Recovery (UDP) Восстановление пропущенных данных из Потоков Recovery может быть использовано для получения большого объёма потерянных данных и для подключения после старта Торгов. В потоках Recovery через фиксированный интервал времени распространяются снэпшоты рыночных данных. В каждом сообщении Market Data – Snapshot/Full Refresh (W) тэг 369-LastMsgSeqNumProcessed соответствует тэгу 34MsgSeqNum последнего сообщения Market Data – Incremental Refresh (X) в соответствующем потоке, включенного в данный снэпшот, а номер обновления каждого инструмента, содержащийся в тэге 83-RptSeq сообщения Market Data – Snapshot/Full Refresh (W), соответствует номеру инкрементального обновления, содержащегося в тэге 83-RptSeq соответствующего MDEntry последнего сообщения Market Data – Incremental Refresh (X), включенного в данный снэпшот. Таким образом, по пропуску в последовательности 34 -MsgSeqNum можно определить произошедшую потерю данных, а по пропуску в последовательностях 83 -RptSeq определить, по каким именно инструментам данные пропущены. Данные по инструменту в канале инкрементальных обновлений следует считать актуальными с того момента, как номер обновления этого инструмента в тэге 83-RptSeq сообщения Market Data – Incremental Refresh (X) станет больше этого номера в аналогичном тэге сообщения Market Data – Snapshot/Full Refresh (W) для этого инструмента. Также данные по инструменту в канале инкрементальных обновлений можно считать актуальными с того момента, как порядковый номер сообщения Market Data – Incremental Refresh (X) станет больше значения тэга 369-LastMsgSeqNumProcessed сообщения Market Data – Snapshot/Full Refresh (W) по этому инструменту. Нумерация сообщений в каждом цикле отправки снэпшотов начинается с 1. Поэтому все снэпшоты следует считать полученными, когда приходит сообщение с порядковым номером 1, которое относится к следующему циклу. Тэг 893-LastFragment значением ‘Y’ отмечает последнее сообщение в снэпшоте по данному инструменту. Поэтому снэпшот по инструменту следует считать полученным, когда получено сообщение с 893-LastFragment = ‘Y’. Пока идёт получение снэпшота, клиент должен накапливать сообщения из канала инкрементальных обновлений, чтобы применить их после получения снэпшота. Последовательность шагов при восстановлении соответствует шагам 3–6, приведенным в разделе 2.2. После восстановления пропущенных сообщений клиенту следует прекратить слушать поток Recovery, чтобы не перегружать свою сетевую инфраструктуру. 3.4.2 Процесс восстановления данных Процесс восстановления затрагивает только потоки с пропущенными сообщениями. Остальные потоки могут быть обработаны двумя способами: они могут быть перемещены в очередь, до тех пор, пока не будут получены все пакеты из потока Recovery, либо они могут быть обработаны параллельно с потоками Recovery. 3.4.2.1.1. Перемещение пакетов в очередь Данный процесс применяется к сообщениям из потоков обновлений во время обработки пакетов из потока Recovery. Во избежание накопления слишком большого количества пакетов в очереди рекомендуется обрабатывать обновления сразу же, как только будет получен соответствующий им снэпшот. 1. Определить поток, в котором пропущено сообщение. 2. Получить и положить в очередь сообщения из потоков обновлений. 3. Получить снэпшоты из потока Recovery, который соответствует потоку обновлений с пропущенным сообщением. 4. Проверить что все нужные снэпшоты были получены: a. Порядковый номер сообщений в цикле снэпшотов начинается с 1. Чтобы определить конец цикла, нужно дождаться следующего сообщения с 34-MsgSeqNum = 1. b. Снэпшоты в потоках Recovery отправляются в таком же порядке, как и описания инструментов в потоках Instrument Definitions. По значению 893-LastFragment в снэпшоте можно понять, что это последнее сообщение для данного инструмента. Получение снэршота с 893-LastFragment для последнего инструмента означает получение последнего сообщения в цикле. 5. Забрать из очереди все сообщения, в которых: a. Значение 34-MsgSeqNum больше самого минимального значения 369-LastMsgSeqNumProcessed сообщения Market Data – Snapshot/Full Refresh (W). Или b. Значение 83-RptSeq из сообщения Market Data Incremental – Refresh (Х) больше, чем самое минимальное значение 83RptSeq из снэпшота. 6. Продолжить получение обновлений. 3.4.2.1.2. Параллельная обработка Данный процесс позволяет осуществлять получение обновлений по инструментам и одновременно восстановление пропущенных данных. 1. Определить поток, в котором пропущено сообщение. 2. Получать обновления, и возможно пропущенные данные обновятся и потеряют уже актуальность. 3. Получить снэпшоты из потока Recovery, который соответствует потоку обновлений с пропущенным сообщением. 4. Для каждого инструмента: a. Сравнить значение 369-LastMsgSeqNumProcessed из снэпшота со значением 34-MsgSeqNum из обновления, и убедиться, что 34-MsgSeqNum не меньше. Или b. Сравнить значение 83-RptSeq из снэпшота со значением 83-RptSeq из обновления, и убедиться что значение 83-RptSeq из обновления не меньше. 5. Продолжить получение обновлений. 3.4.2.1.3. Инкрементальные обновления инструмента Сообщения из потоков с обновлениями содержат номера обновлений для каждого инструмента (tag 83-RptSeq). В каждой репитинг группе элемента рыночных данных содержится номер инкрементального обновления инструмента (tag 83-RptSeq). Клиенты могут отслеживать порядок номеров инкрементальных обновлений для быстрого обнаружения пропуска сообщений. • Если порядок номеров 83-RptSeq нарушен, это говорит о том, что часть рыночных дынных по инструменту была пропущена. • Если порядок номеров 83-RptSeq не нарушен, это говорит о том, что данные по инструменту верны и актуальны. 3.4.2.1.4. Восстановление по инкрементальным обновлениям Как правило, клиенты должны отслеживать состояние данных по котировкам. Но возможно при потерях данных инкрементальные обновления лучше позволят отобразить актуальное состояние котировок, даже без необходимости обращаться к процедурам восстановления. Этот процесс называется восстановлением по инкрементальным обновлениям. Для ликвидных инструментов большая вероятность быстрого обновления данных и как следствие быстрая потеря актуальности пропущенных данных. 3.4.3 Восстановление пропущенных данных по TCP-соединению Восстановление данных, пропущенных в потоках OrderBook, Statistics, Orders, Trades, можно выполнить, запросив их по TCPсоединению. Данный способ восстановления не является высокопроизводительным, и его следует использовать только в крайнем случае и только для запроса небольшого количества пропущенных сообщений. Количество сообщений, которое может быть запрошено клиентом за одно подключение, задаётся в конфигурационном файле сервера MOEX Market Data Multicast. Для запроса пропущенных данных клиент должен выполнить следующие действия: 1. Установить TCP-соединение с сервером MOEX Market Data Multicast. 2. Отправить серверу FIX-сообщение Logon(A). В случае успешной авторизации, сервер ответит FAST-сообщением Logon(A). 3. Отправить серверу FIX-сообщение Market Data Request (V), в котором необходимо указать: a. Идентификатор UDP-потока, из которого запрашиваются сообщения – в тэге 1180-ApplFeedID. b. Диапазон порядковых номеров запрашиваемых сообщений – в тэгах 1182-ApplBeginSeqNo и 1183-ApplEndSeqNo. Если запрос может быть обработан, сервер отправляет клиенту запрошенные FAST сообщения с порядковыми номерами, под которыми эти сообщения изначально были опубликованы в соответствующем Потоке. Если запрос не может быть обработан, клиенту отправляется FAST-сообщение Logout (5) с описанием причины отказа. После отправки ответа сервер закрывает соединение. Сервер обрабатывает только первый запрос от клиента. Если клиент посылает более одного запроса, второй и последующие игнорируются. Если сервер не получит Market Data Request (V) в течение определённого интервала времени после аутентификации, подключение закрывается. 4. Публичный FIX интерфейс Описание интерфейса базируется на спецификации протокола FIX (Financial Information Exchange, http://fixprotocol.org/) версии 5.0 SP2; предполагается, что читатель уже знаком с основами этого протокола. Системой используются только те сообщения (группы) и их поля, которые описаны в данном публичном интерфейсе. Следует обратить внимание, что поля, присутствующие в стандарте 5.0 SP2 (обязательные и не обязательные), но не перечислены в данном публичном интерфейсе, считаются необязательными и игнорируются биржей. Значения полей, присутствующие в списке допустимых значений в стандарте 5.0 SP2, но не описанные в этом документе, считаются некорректными – и поступающие сообщения с такими данными будут отклонены. 4.1. Группы полей 4.1.1 Заголовок Table 2 Поле О О О Наличие Tag Тип Допустимые значения ‘9’ (FIX50SP2) Примечание Определяет версию протокола для application messages. Всегда содержит незашифрованные данные, должно быть первым полем в сообщении. Определяет тип сообщения. Всегда содержит незашифрованные данные, должно быть третьим полем в сообщении. Идентификатор компьютера – отправителя сообщения. Всегда содержит незашифрованные данные. Если сообщение отправляется на сервер TCP Replay биржи, то это поле может содержать произвольное значение. Порядковый номер сообщения. Время передачи сообщения (выражено в формате UTC). 1128 AppVerID String (1) 35 49 MsgType SenderCompID String (10) String (12) 34 52 MsgSeqNum SendingTime О О SeqNum UTCTimestamp 347 MessageEncodin g Н String(11) ‘UTF-8’ (Unicode) Тип кодирования (не ASCII символы). Обязательное, если хотя бы одно из полей в сообщении имеет кодировку, отличающуюся от ASCII. 4.1.2 Группа Instrument Table 3 Поле О Наличие Tag Тип Допустимые значения Примечание Код/аббревиатура ценной бумаги. В его качестве используется внутренний идентификатор финансового инструмента на MOEX (SECCODE). Примечание: финансовый инструмент с кодом SecCode может быть доступен для торгов в разных режимах. Вы должны рассматривать комбинацию Symbol (55) + TradingsessionId (336) как отдельный инструмент с отдельными котировками и таблицами сделок и заявок. Идентификатор финансового инструмента (например, CUSIP, SEDOL, ISIN, и т.п.). Тип идентификатора финансового инструмента. Поле обязательное, если определено значение поля SecurityID (48). Тип продукта, с которым связана ценная бумага. 55 Symbol String(12) 48 22 SecurityID SecurityIDSou rce Product Н Н Н String String ‘4’ (ISIN) ‘3’ (CORPORATE); ‘4’ (CURRENCY); ‘5’ (EQUITY); ‘6’ (GOVERNMENT); ‘7’ (INDEX); ‘10’ (MORTGAGE) ‘11’ (MUNICIPAL); ‘12’ (OTHER);‘13’ (FINANCING). 460 int 461 167 CFICode SecurityType Н Н String String 'CORP' (Корпоративные облигации) 'FOR' (Валютный контракт) 'CS' (Акции обыкновенные) Тип ценной бумаги по стандарту ISO 10962. CFI код (Classification of Financial Instruments). Тип ценной бумаги. 'PS' (Акции привилегированные) 'EUSOV' (Еврооблигация) BN' (Ценные бумаги, выпущены банком) 'MF' (Паи инвестиционных фондов) 'MLEG' (Multi-leg инструмент) 'MUNI' (Муниципальные облигации) RDR – Российские депозитарные расписки ETF – Бумаги иностранных инвестиционных фондов (ETF) ‘COFP’(Ипотечные сертификаты участия) 'XCN' (Корзина бумаг) 'STRUCT' (Дополнительный идентификатор списка) 'WAR' (Инструмент ¨заявки-списки£) 224 223 107 350 351 CouponPayme ntDate CouponRate SecurityDesc EncodedSecuri tyDescLen EncodedSecuri tyDesc StateSecurityI D EncodedShortS ecurityDescLe n EncodedShortS ecurityDesc BaseSwapPx BuyBackPx Н Н Н Н Н Н Н Н Н H LocalMktDate Percentage String Length data Дата выплаты накопленного купонного дохода. Процентная ставка, по которой рассчитывается размер купонной выплаты по облигации (купонная ставка). Описание ценной бумаги. На MOEX это поле содержит наименование финансового инструмента на английском языке. Длина поля EncodedSecurityDesc (351) в байтах. Название ценной бумаги на русском языке (не ASCII символы). Тип кодироваки указан в поле MessageEncoding (347) в заголовке сообщения. Номер государственной регистрации. Длина поля EncodedShortSecurityDesc (5383)в байтах. Краткое (не ASCIIсимволы) наименование ценной бумаги на русском языке. Тип кодировки указан в поле MessageEncoding (347) в заголовке сообщения. Базовый курс при торговле СВОП инструментам. Цена досрочного выкупа облигации, заполняется если бумага предусматривает досрочный выкуп (до погашения). Если 5217 5382 String Length 5383 data 5556 5558 Price Price 5559 BuyBackDate H LocalMktDate указана, то расчет доходности производится по этой цене (в качестве цены погашения). При заполнении BUYBACKPRICE обязательно заполняется поле BUYBACKDATE Дата досрочного выкупа облигации, заполняется если бумага предусматривает досрочный выкуп (до погашения). Если указана, то расчет доходности производится с успользованием этой даты, в качестве даты погашения. 4.1.3 Группа Instrument Extension Table 4 Поле Н Н Наличие Tag Тип Допустимые значения Примечание Количество элементов в группе InstrAttribs. Тип атрибута ценной бумаги. Поле обязательное, если NoInstrAttrib (870) > 0. Значение атрибута ценной бумаги (если применимо). 870 => 871 NoInstrAttrib InstrAttribType NumInGroup int '8' (Купонный период) '27' (Кол-во десятичных знаков (DECIMALS) в ценах финансового инструмента) => 872 InstrAttribValue Н String 4.1.4 Группа Market Segment Table 5 Поле Н Н Н Н Наличие Tag Тип Допустимые значения Примечание Количество элементов в группе MarketSegmentGrp. Количество ценных бумаг в одном стандартном лоте. Количество элементов в группе TradingSessionRulesGrp. Идентификатор торговой сессии, на котором торгуется финансовый инструмент. Используется для указания режима торгов SECBOARD. Примечание: финансовый инструмент может быть доступен для торгов в разных режимах. Вы должны 1310 => 561 => 1309 => => 336 NoMarketSegments RoundLot NoTradingSessionR ules TradingSessionID NumInGroup Qty NumInGroup String рассматривать комбинацию Symbol (55) + TradingsessionId (336) как отдельный инструмент с отдельными котировками и таблицами сделок и заявок. Н NA – нет торгов O – период открытия C – период закрытия F – финальный период закрытия N – нормальный период торгов L – аукцион закрытия I – дискретный аукцион D – аукцион крупных пакетов E – период торгов по цене аукциона закрытия Указывает период торгов Примечания: ñ Код периода не определен перед началом торгов и после их окончания ñ Переключение между периодами обычно происходит с кратковременным переключением торгового статуса в состояние Нет Торгов, в котором код периода не определен (625=NA) ñ Порядок смены периодов торгов и расписание определяется Правилами торгов и рыночными условиями ñ Код периода в этой группе полей указывает на период, который продолжался в момент начала цикла вещания Security Definitions. Обновления статуса инструмента, которые могут приходить во время вещания цикла должны заменять статус на статус из сообщений 35=f. Указывает торговый статус инструмента Примечание: перерыв в торгах обозначается как 326=2 и идентификатор периода в поле 625. ñ Статусы Нет Торгов и Торги Закрыты означают разные технологические состояния торгов по инструменту. Однако, оба эти статуса означают запрет торговых операций, поэтому им присваиваются одинаковые значения поля 326. ñ Код статуса в этой группе полей указывает на статус, который существовал в момент начала цикла вещания Security Definitions. Обновления статуса инструмента, которые могут приходить во время вещания цикла должны заменять статус на =>=>625 TradingSessionSubI D String =>=>326 SecurityTradingStat us Н int 18 – нет торгов 118 – период открытия 18 – торги закрыты 103 – период закрытия 2 – перерыв в торгах 17 – нормальный период торгов 102 – аукцион закрытия 106 – аукцион крупных пакетов 107 – дискретный аукцион 120 – период торгов по цене аукциона закрытия статус из сообщений 35=f. =>=>9680 OrderNote Н Char Уровень листинга. 4.2. Сообщения сессионного уровня 4.2.1 Logon (A) Logon сообщение от пользователя к MOEX: Table 6 Поле О У У О Наличие Tag Тип Допустимые значения Примечание Тип сообщения = ‘A’ Имя пользователя (логин). Пароль пользователя. Определяет версию протокола на сессионном уровне. <Standard Message Header> 553 Username 554 Password 1137 DefaultAppl VerID String String String ‘9’ (FIX50SP2) Logon сообщение от MOEX к пользователю: Table 7 Поле О О О Наличие Tag Тип Допустимые значения Примечание MsgType = ‘A’ Интервал ожидания торговых сообщений или сообщений HeartBeat. Определяет версию протокола на сессионном уровне. <Standard Message Header> 108 HeartBtInt 1137 DefaultApplVer ID int String ‘9’ (FIX50SP2) 4.2.2 Logout (5) Table 8 Поле О Н Наличие Tag Тип Допустимые значения Примечание Тип сообщения = ‘5’ Причина завершения сессии. <Standard Message Header> 58 Text String 4.2.3 Heartbeat (0) Table 9 Поле О Наличие Tag Тип Допустимые значения Тип сообщения = ‘0’ Примечание <Standard Message Header> 4.3. Сообщения бизнес уровня 4.3.1 Security Definition (d) Table 10 Поле О О О Н Н Н Наличие Tag Тип Допустимые значения Тип сообщения = ‘d’ Примечание <Standard Message Header> 911 TotNumReports Component block <Instrument> Component block <Instrument Extension> 15 Currency Component block <Market Segment> int Количество сообщений по всем инструментам. Данные по финансовому инструменту. Дополнительная информация по финансовому инструменту. Код валюты, в которой выражен номинал ценной бумаги. Дополнительная информация по финансовому инструменту, его листингу, включая торговый статус и период на момент начала цикла вещания. Эти данные позволяют определить статус инструмента и период торгов Currency 120 423 SettlCurrenc y PriceType Н Н Н Currency int '1' (В процентах от номинала) '2' (За единицу (например, за акцию или за контракт) 5385 MarketCode String 64 SettlDate Н LocalMktDate 969 5508 5850 7595 MinPriceIncr ement FaceValue OrigIssuueA mt NoSharesIssu ed Н Н H Н float Amt Int Qty для поздних подключений, когда сообщения типа 35=f были пропущены. Код валюты, в которой производятся расчеты по данному финансовому инструменту. Тип цены. Для РЕПО с ЦК принимает значение ‘1’ , с указанием ставки РЕПО, а не номинала акции или облигации Код рынка, на котором торгуется финансовый инструмент. Примечание: MarketCode указывает на группу режимов торгов с похожими правилами торгов. Значение MarketCode может совпадать со значением <Market> 336 тэга, но иметь иное назначение. Дата расчетов, выраженная в ГГГГММДД формате. Для системных режимов фондового и валютного рынка – указывает дату расчетов Для переговорных режимов – указывает дату расчтетов для используемого по умолчанию кода расчетов. Фактическая дата расчетов по сделке может отличаться от этой даты и публикуется в поле SettlDate Потока обезличенных сделок. Для валютных своп- инструментов: дата расчетов для обратной сделки. Минимальный шаг изменения цены. Номинальная стоимость одной ценной бумаги, в валюте инструмента. Объем в обращении Объем выпуска. 4.3.2 Security Status (f) Сообщения Security status уведомляют об изменениях торгового статуса и периода торгов по инструменту. Пожалуйста, имейте в виду, что публикация большого числа сообщений в ограниченных по трафику каналах вещания занимает некоторое время, и происходит параллельно с публикацией обновлений торговых данных. Параллельная публикация может приводить к получению торговых обновлений из последующего периода торгов немного раньше получения изменения периода торгов, или к получению торговых обновлений из предыдущего периода торгов после получения сообщения о смене статуса. Table 11 Поле Наличие Tag Тип Допустимые значения Примечание Тип сообщения = 'f' Порядковый номер обновления информации по инструменту. Код/аббревиатура ценной бумаги. В его качестве используется внутренний идентификатор финансового инструмента на Московской бирже (SECCODE). Примечание: финансовый инструмент с кодом SecCode может быть доступен для торгов в разных режимах. Вы должны рассматривать комбинацию Symbol (55) + TradingsessionId (336) как отдельный инструмент с отдельными котировками и таблицами сделок и заявок. Идентификатор торговой сессии, на котором торгуется финансовый инструмент. Используется для указания режима торгов SECBOARD. Примечание: финансовый инструмент с кодом SecCode может быть доступен для торгов в разных режимах. Вы должны рассматривать комбинацию Symbol (55) + TradingsessionId (336) как отдельный инструмент с отдельными котировками и таблицами сделок и заявок. <Standard Message Header> 83 RptSeq 55 Symbol О O О int String 336 TradingSessionID Н String 625 TradingSessionSubID Н String NA – нет торгов O – период открытия C – период закрытия F – финальный период закрытия N – нормальный период торгов L – аукцион закрытия I – дискретный аукцион D – аукцион крупных пакетов E – период торгов по цене аукциона закрытия Указывает период торгов ñ Код периода не определен перед началом торгов и после их окончания ñ Переключение между периодами обычно происходит с кратковременным переключением торгового статуса в состояние Нет Торгов, в котором код периода не определен (625=NA) ñ Порядок смены периодов торгов и расписание определяется Правилами торгов и рыночными условиями Н 18 – нет торгов 118 – период открытия 18 – торги закрыты 103 – период закрытия 2 – перерыв в торгах 17 – нормальный период торгов 102 – аукцион закрытия 106 – аукцион крупных пакетов 107 – дискретный аукцион 120 – период торгов по цене аукциона закрытия 'Y' (Да); 'N' (Нет). Указывает торговый статус инструмента Примечания: ñ перерыв в торгах обозначается как 326=2 и идентификатор периода в поле 625 ñ Статусы Нет Торгов и Торги Закрыты означают разные технологические состояния торгов по инструменту. Однако, оба эти статуса означают запрет торговых операций, поэтому им присваиваются одинаковые значения поля 326. 326 SecurityTradingStatus int 5509 AuctionIndicator Н Boolean Индикатор информирующий, что по данному инструменту проводится аукцион первичного размещения. В настоящее время данные аукционов первичного размещения не публикуются в потоках. Примечания: ñ 5509=N для всех типов аукционов, кроме аукциона первичного размещения ñ Boolean значения передаются в FAST сообщениях как двоичные целые: 0 для N и 1 для Y 4.3.3 Trading Session Status (h) Table 12 Поле О О О Наличие Tag Тип Допустимые значения Примечание Тип сообщения = 'h' Идентификатор торговой сессии. Поле содержит идентификатор рынка. Статус торговой сессии. Информирует о состоянии подключения сервера MOEX Market Data Multicast FIX/FAST Platform к торговой системе биржи. Примечание: получение весьма маловероятного <Standard Message Header> 336 TradingSessionID 340 TradSesStatus String int ‘100’ (Соединение с MOEX установлено); ‘101’ (Соединение с MOEX потеряно); ‘102’ (Соединение восстановлено, торговая система не перезапускалась); ‘103’ (Соединение восстановлено, торговая система перезапускалась) сообщения 340=103 означает, что торговая система была перезапущена с полной потерей предыдущего состояния. Вы должны удалить все полученные данные и начать процедуру их получения с самого начала. Текстовая строка в свободном формате. Может использоваться для комментариев, дополнительной информации касающейся подключения к конкретному рынку MOEX. 58 Text Н String 4.3.4 Market Data Request (V) Table 13 Поле Наличие Tag Тип Допустимые значения Примечание Тип сообщения = 'V' Идентификатор UDP-потока. Порядковый номер первого запрашиваемого сообщения. Порядковый номер последнего запрашиваемого сообщения. Если запрос на одно сообщение, то ApplBegSeqNum(1182) = ApplEndSeqNum(1183). Если запрос на все сообщения (но не более максимального числа пересылаемых сообщений) после определенного сообщения, то ApplEndSeqNum(1183) = ‘0’(бесконечность). <Standard Message Header> 1180 ApplID 1182 ApplBegSeqNum 1183 ApplEndSeqNum О Н Н Н String SeqNum SeqNum OLR, OBR, TLR, MSR 4.3.5 Market Data - Snapshot/Full Refresh (W) Table 14 Поле Наличие Tag Тип Допустимые значения Примечание Тип сообщения = 'W' Номер обновления инструмента. Соответствует RptSeq(83) в сообщении Market Data - Incremental Refresh (X). Значение, соответствующее MsgSeqNum(34) из последнего сообщения Market Data - Incremental Refresh (X), которое было получено и обработано. <Standard Message Header> 83 RptSeq 369 LastMsgSeqNumPro cessed О О Н int SeqNum 340 TradSesStatus Н int ‘100’ (Соединение с MOEX установлено); ‘101’ (Соединение с MOEX потеряно); ‘102’ (Соединение восстановлено, торговая система не перезапускалась); ‘103’ (Соединение восстановлено, торговая система перезапускалась). Статус соединения с Торговой системой. Информирует о состоянии подключения сервера MOEX Market Data Multicast FIX/FAST Platform к торговой системе биржи. Примечание: получение весьма маловероятного сообщения 340=103 означает, что торговая система была перезапущена с полной потерей предыдущего состояния. Вы должны удалить все полученные данные и начать процедуру их получения с самого начала. Код/аббревиатура ценной бумаги. В его качестве используется внутренний идентификатор финансового инструмента на MOEX (SECCODE). Примечание: финансовый инструмент с кодом SecCode может быть доступен для торгов в разных режимах. Вы должны рассматривать комбинацию Symbol (55) + TradingsessionId (336) как отдельный инструмент с отдельными котировками и таблицами сделок и заявок. 55 Symbol О String 893 LastFragment Н Boolean 'N' (Сообщение не последнее, снэпшот еще не сформирован); 'Y' (Последнее сообщение, снэпшот сформирован). 18 – нет торгов 118 – период открытия 18 – торги закрыты 103 – период закрытия 2 – перерыв в торгах 17 – нормальный период торгов 102 – аукцион закрытия 106 – аукцион крупных пакетов 107 – дискретный аукцион 120 – период торгов по цене аукциона закрытия 1682 MDSecurityTrading Status Н int Индикатор, показывающий, является ли сообщение последним в серии, которая формирует снэпшот по данному инструменту. Boolean значения передаются в FAST сообщениях как двоичные целые: 0 для N и 1 для Y Состояние торгов по инструменту. Примечания: ñ перерыв в торгах обозначается как 1682=2 и идентификатор периода в поле 625. ñ Переключение между периодами обычно происходит с кратковременным переключением торгового статуса в состояние Нет Торгов, в котором код периода не определен (625=NA) ñ Порядок смены периодов торгов и расписание определяется Правилами торгов и рыночными условиями ñ Статусы Нет Торгов и Торги Закрыты означают разные технологические состояния торгов по инструменту. Однако, оба эти статуса означают запрет торговых операций, поэтому им присваиваются одинаковые значения поля 326. 5509 AuctionIndicator Н Boolean 'Y' (Да) 'N' (Нет) 451 268 => 269 NetChgPrevDay NoMDEntries MDEntryType Н О О PriceOffset NumInGroup char '0' (Котировки на покупку); '1' (Котировки на продажу); '2' (Информация по последней сделке); '3' (Список индексов); '4' (Цена открытия/цена первой сделки); '5' (Цена закрытия/цена последней сделки предыдущего дня); '7' (Максимальная цена сделки); '8' (Минимальная цена сделки); '9' (Средневзвешенные цены); ‘A’ (Дисбаланс); 'B' (Объемы сделок); 'J' (Пустой снэпшот) 'N' (Максимальная цена спроса в течение сессии); 'O' (Минимальная цена предложения в течение сессии); 'Q' (Расчетная цена аукциона) ‘W’ (Цена аукциона закрытия); ’c’ (Объём аукциона закрытия); ‘‘f’ (Для потоков MSR/MSS - объём рыночных заявокна покупку в аукцион закрытия, в единицах ценных бумаг; для потоков OLR/OLS – рыночная заявка в Индикатор информирующий, что по данному инструменту проводится аукцион первичного размещения. В настоящее время данные аукционов первичного размещения не публикуются в потоках. Примечания: ñ 5509=N для всех типов аукционов, кроме аукциона первичного размещения ñ Boolean значения передаются в FAST сообщениях как двоичные целые: 0 для N и 1 для Y Изменение цены последней сделки по отношению к цене последней сделки предыдущего торгового дня. Количество элементов в группе MDEntryTypes. Тип рыночных данных. Примечания: ñ Наличие различных типов данных определяется Правилами торгов и зависит от режима торгов и рынка. ñ Различные каналы вещания имеют подмножества значений типа данных из этого списка ñ Empty Book (269=J) означает, что по инструменту отсутствуют какие-либо данные. Это сообщение может быть получено без указания кода инструмента и режима (по всему рынку). В этом случае вы должны удалить все накопленные данные и начать процедуру первичного подключения. ñ Смысл некоторых типов данных зависит от типа рынка (фондовый или валютный) ñ Переговорные режимы торгов не содержат данных о котировках и активных заявках ñ Набор значений этого поля может расширяться при обновлениях торговой системы. Рекомендуется разрабатывать код так, чтобы неизвестные значения этого поля и привязанные к ним другие поля игнормировались в коде до тех пор, пока он не будет адаптирован к новым типам данных аукцион закрытия, на покупку ); ‘g’(Для потоков MSR/MSS - объём рыночных заявок на продажу в аукцион закрытия, в единицах ценных бумаг; для потоков OLR/OLS – рыночная заявка в аукцион закрытия, на продажу ); 'i' (Спрос сессии); 'j' (Предложение сессии); 'h' (Цена предторгового периода); 'k' (Цена послеторгового периода); 'l' (Рыночная цена 2); Для валютного рынка –цена валютного фиксинга, рассчитанная за период 11:29-12:00 московского времени 'm' (Рыночная цена); Для валютного рынка – цена валютного фиксинга) 'o' (Официальная цена открытия); 'p' (Официальная текущая цена); 'q' (Признаваемая котировка); Для валютного рынка – междунароная цена валютного фиксинга 'r' (Официальная цена закрытия); 'v' (Совокупный спрос); 'w' (Совокупное предложение); 's' (Цена аукциона крупными пакетами) 'x' (Объем аукциона крупными пакетами); ‘y’(Накопленный купонный доход на дату расчетов, в рублях, в пересчете на единицу финансового инструмента) 'u' (Дюрация); 'z' (Все сделки/список обезличенных сделок) => 278 MDEntryID Н String ñ ñ Индексы публикуются в канале MSS/MSR Данные предыдущего дня обозначаются наличием поля 286 Идентификатор элемента MDEntry. Примечания: ñ Для канала сделок (269=z) это поле содержит строку с биржевым номером сделки ñ Для канала котрировок, это поле содержит строку идентификатора уровня цены ñ Для канала заявок, это поле содержит строку идентификатора сообщения о добавлении новой заявки, который НЕ связан с биржевым номером заявки в таблице заявок биржи. => 270 MDEntryPx У Price Цена элемента рыночных данных (соответствует заданному типу рыночных данных и относится к текущему элементу MDEntry). Поле условно обязательное, если MDEntryType (269) не является одним из ( 'A', 'B', 'C', 'J'). Условно обязательно когда MDEntryType (269) = ‘Расчетная цена аукциона’ Количество или объем элемента рыночных данных (соответствует заданному типу рыночных данных и относится к текущему элементу MDEntry). Поле условно обязательное, если MDEntryType (269) является одним из ('0', '1', '2', ‘A’, 'B', 'C', ‘Q’, ‘g’). Примечание: для 269=B это поле выражено в количестве единиц финансового инструмента. Для других типов данных это поле выражено в количестве лотов. Дата, которая относится к данному элементу рыночных данных. Время, которое относится к данному элементу рыночных данных. Идентификатор режима торгов SECBOARD Примечание: финансовый инструмент может быть доступен для торгов в разных режимах. Вы должны рассматривать комбинацию Symbol (55) + TradingsessionId (336) как отдельный инструмент с отдельными котировками и таблицами сделок и заявок. Указывает период торгов Для инкрементальных обновлений и снэпшотов период торгов указывает на период, в который произошло событие для данного элемента, а не на текущий торговый период. => 271 MDEntrySize У Qty => 272 => 273 => 336 MDEntryDate MDEntryTime TradingSessionID Н Н Н UTCDateOnly UTCTimeOnly String => 625 TradingSessionSubI D Н String NA – нет торгов O – период открытия C – период закрытия F – финальный период закрытия N – нормальный период торгов L – аукцион закрытия I – дискретный аукцион D – аукцион крупных пакетов E – период торгов по цене аукциона закрытия 'C' (Наилучшая цена) => 276 QuoteCondition Н MultipleValueStrin Список условий, которые характеризуют котировку, => 277 TradeCondition Н g MultipleValueStrin g => 286 => 40 OpenCloseSettlFlag OrdType Н H MultipleValueStrin g Char 'C' (Расчеты по сделке осуществляются в день заключения сделки) 'J' (Расчеты по сделке осуществляются на следующий день после заключения сделки) 'R' (Цена открытия) 'AJ' (Официальная цена закрытия); ‘98’ (Минимальное значение); ‘99’ (Максимальное значение) '4' (Данные предыдущего торгового дня) ‘1’(Рыночная) условия между собой разделены пробелами. Условия, которые характеризируют сделку или рыночные данные, которые рассчитываются на базе сделки, условия между собой разделены пробелами. => 236 => 64 Yield SettlDate Н Н Percentage LocalMktDate => 44 => 423 => 5292 Price PriceType BidMarketSize Н Н H Price int Int ‘1’ проценты ставки РЕПО => 5293 => 5384 => 5459 => 5510 AskMarketSize AccruedInterestAmt SettlType ChgFromWAPrice H Н Н Н Int Amt Char PriceOffset Флаг, который идентифицирует тип элемента рыночных данных. Тип заявки. Используется если MDEntryType (269) =’g’,’f ‘ Примечание: рыночные в аукцион заявки активируются и публикуются после начала аукциона закрытия. Сделки аукциона заключаются по его окончании. Доходность, рассчитанная по цене MDEntryPx (270). Дата расчетов по сделке (SettlementDate) в YYYYMMDD формате Примечания: Для обычных сделок – дата расчетов Для сделок РЕПО – дата расчетов первой части сделки РЕПО Ставка REPO для сделок REPO Указывает на тип цены (ставка REPO в процентах) для сделок REPO. Суммарный объем рыночных заявок в аукционе закрытия на покупку по ожидаемой цене аукциона, выраженный в единицах инструмента. Суммарный объем рыночных заявок в аукционе закрытия на продажу, выраженный в единицах инструмента. Объем накопленного купонного дохода. Код расчетов по сделкам (269=z) Изменение цены сделки по сравнению со средневзвешенной ценой предыдущего торгового дня. Для сделок РЕПО – сумма сделки РЕПО (269=z). Для сделок РЕПО – дата второй части сделки РЕПО => 5558 => 5559 BuyBackPx BuyBackDate H H Price LocalMktDate (269=z) . => 5677 Repo2Px H Price Для сделок РЕПО – сумма второй части сделки РЕПО (269=z). Объём денежных средств. Используется если MDEntryType (269)=’f’ Рыночные в аукцион закрытия заявки на покупку в качесте объема указывают сумму денежных средств. Заявки другого типа содержат количество лотов торгуемого инструмента. Время активации заявки. Заявки и уровни цены в котировках, для которых не наступила активация, не участвуют в торгах. Время старта аукциона. Используется для аукционов крупных пакетов и дискретных аукционов. Общее количество сделок, заключенных на протяжении торгового дня. Объем совершенных сделок. Индикатор объема заявок крупными пакетами. Используется когда MDEntryType(269)=’v’ or ‘w’. N(переменное)*- величина индикатора определяется биржей. Количество заявок на продажу в очереди. Количество заявок на покупку в очереди. Объем котировки РЕПО, выраженный в рублях. В режиме торгов РЕПО с Центральным Контрагентом торги проводятся по ставкам РЕПО в качестве цены денежных средств. Для этого режима, цены финансовых инструментов, участвующих сделках как обеспечение, уменьшаются по правилам управления рисками ЦК на величину, зависящую от типа инструмента и объема заявки в лотах. Объемы денежных средств в заявках на каждом уровне ставки РЕПО суммируются и публикуются в этом поле. Для других режимов торгов это поле не публикуется. => 5791 TotalVolume H Amt => 5902 EffectiveTime Н Н Н Н Н UTSTimestamp => 9820 => 6139 => 6143 => 7017 StartTime TotalNumOfTrades TradeValue VolumeIndicator UTSTimestamp int Amt int '0'(Нет заявок) '1' (Объем заявок не превышает порговой величины N*) '2' (Объем заявок превышает порговую величинуN*) => 9168 => 9169 => 9280 OfferNbOr BidNbOr NominalValue Н Н Н int int float => 9412 OrigTime Н int Время транзакции в микросекундах как указано в торговой системе. Данное значение следует прибавить к значению 273 тэга для получения времени транзакции с микросекундной точностью. Поле доступно в каналах сделок и заявок. => 10504 => 10505 OrderSide OrderStatus Н Н char char 'O' (Активная); 'T' (Время активации не наступило). Направленность заявки. Текущий статус заявки. Заявки со статусом T неактивны и не участвуют в торгах. => 10509 MinCurrPx Н Price => 10510 MinCurrPxChgTime Н UTCTimeOnly Минимальная из двух цен: Официальной текущей цены и цены последней сделки, вошедшей в расчёт официальной текущей цены. Используется для определения условий запрета коротких продаж. Время изменения минимальной текущей цены. 4.3.6 Market Data - Incremental Refresh (X) Примечания об обработке обновлений: ñ Публикация большого объема обновлений в ограниченном по трафику потоке вещания может занять некоторое время. При старте или окончании торговых периодов публикация обновлений происходит параллельно с публикацией сообщений о смене статуса большого числа инструментов. Параллельная публикация может приводить к получению торговых обновлений из последующего периода торгов немного раньше получения изменения периода торгов, или к получению торговых обновлений из предыдущего периода торгов после получения сообщения о смене статуса. ñ Для каналов вещания, допускающих добавления, изменения и удаления данных (заявки, котировки) корректное состояние набора данных достигается после окончания обработки всех элементов повторяющихся групп в сообщении. ñ Размер FAST сообщения ограничен величиной MTU size, текущее ограничение составляет 1300 байт. Для массовых обновлений, это ограничение может приводить к публикации изменений в нескольких сообщениях подряд. Корректное состояние набора данных может быть достигнуто только после обработки сообщения заведомо меньшего по размеру, чем предельный размер. Промежуточные результаты обработки нескольких сообщений предельного размера могут приводить к перекрещенным котировкам. Table 15 Поле Наличие Tag Тип Допустимые значения Примечание Тип сообщения = 'X' Количество элементов в группе MDEntryTypes. Действие, которое нужно выполнить при обновлении элемента рыночных данных. Тип рыночных данных. Примечания: ñ Наличие различных типов данных определяется Правилами торгов и зависит от режима торгов и рынка. ñ Различные каналы вещания имеют подмножества значений типа данных из этого списка ñ Empty Book (269=J) означает, что по инструменту отсутствуют какие-либо данные. Это сообщение может быть получено без указания кода инструмента и режима (по всему рынку). В этом случае вы должны удалить все накопленные данные и начать процедуру первичного подключения. ñ Смысл некоторых типов данных зависит от типа рынка (фондовый или валютный) ñ Переговорные режимы торгов не содержат данных о котировках и активных заявках ñ Набор значений этого поля может расширяться при обновлениях торговой системы. Рекомендуется разрабатывать код так, чтобы неизвестные значения этого поля и привязанные к ним другие поля игнормировались в коде до тех пор, пока он не будет адаптирован к новым типам данных ñ Индексы публикуются в канале MSS/MSR ñ Данные предыдущего дня обозначаются наличием поля 286 <Standard Message Header> 268 NoMDEntries => 279 MDUpdateAction О О О У NumInGroup char => 269 MDEntryType char '0' (Добавить) '1' (Изменить) '2' (Удалить) '0' (Котировки на покупку); '1' (Котировки на продажу); '2' (Информация по последней сделке); '3' (Список индексов); '4' (Цена открытия/цена первой сделки); '5' (Цена закрытия/цена последней сделки предыдущего дня); '7' (Максимальная цена сделки); '8' (Минимальная цена сделки); '9' (Средневзвешенные цены); ‘A’ (Дисбаланс); 'B' (Объемы сделок); 'J' (Пустой снэпшот) 'N' (Максимальная цена спроса в течение сессии); 'O' (Минимальная цена предложения в течение сессии); 'Q' (Расчетная цена аукциона) ‘W’ (Цена аукциона закрытия); ’c’ (Объём аукциона закрытия); ‘f’ (Для потоков MSR/MSS – объём рыночных заявокна покупку в аукцион закрытия, в единицах ценных бумаг; для потоков OLR/OLS – рыночная заявка в аукцион закрытия, на покупку ); ‘g’(Для потоков MSR/MSS – объём рыночных заявок на продажу в аукцион закрытия, в единицах ценных бумаг; для потоков OLR/OLS – рыночная заявка в аукцион закрытия, на продажу ); 'i' (Спрос сессии); 'j' (Предложение сессии); 'h' (Цена предторгового периода); 'k' (Цена послеторгового периода); 'l' (Рыночная цена 2); Для валютного рынка – цена валютного фиксинга, рассчитанная за период 11:29-12:00 московского времени 'm' (Рыночная цена); Для валютного рынка – цена валютного фиксинга 'o' (Официальная цена открытия); 'p' (Официальная текущая цена); 'q' (Признаваемая котировка); Для валютного рынка – междунароная цена валютного фиксинга 'r' (Официальная цена закрытия); 'v' (Совокупный спрос); 'w' (Совокупное предложение); 's' (Цена аукциона крупными пакетами) 'x' (Объем аукциона крупными пакетами); ‘y’ (Накопленный купонный доход на дату расчетов, в рублях, в пересчете на единицу финансового инструмента); 'u' (Дюрация); 'z' (Все сделки/список обезличенных сделок) => 278 MDEntryID Н String Идентификатор элемента MDEntry. Примечания: ñ Для канала сделок (269=z) это поле содержит строку с биржевым номером сделки ñ Для канала котрировок, это поле содержит строку идентификатора уровня цены ñ Для канала заявок, это поле содержит строку идентификатора сообщения о добавлении новой заявки, который НЕ связан с биржевым номером заявки в таблице заявок биржи. => 55 Symbol О String Код/аббревиатура ценной бумаги. В его качестве используется внутренний идентификатор финансового инструмента на MOEX (SECCODE). Примечание: финансовый инструмент с кодом SecCode может быть доступен для торгов в разных режимах. Вы должны рассматривать комбинацию Symbol (55) + TradingsessionId (336) как отдельный инструмент с отдельными котировками и таблицами сделок и заявок. Порядковый номер обновления по инструменту. Увеличивается на единицу для каждого обновления торговой информации или статуса инструмента. Цена элемента рыночных данных (цена соответствует заданному типу рыночных данных, и относиться к текущему элементу MDEntry). Поле условно обязательное, когда (279) = New(0) и MDEntryType (269) не является одним из ( 'A', 'B', 'C', 'J'). Условно обязательно, когда MDEntryType (269) = ‘Расчетная цена аукциона’ Количество или объем элемента рыночных данных (соответствует заданному типу рыночных данных и относиться к текущему элементу MDEntry). Поле условно обязательное, когда MDUpdateAction (279) = New(0) и MDEntryType (269) является одним из ('0', '1', '2', ‘A’,'B', 'C', ‘Q’,’g’ ). Дата, которая относится к данному элементу рыночных данных. Время, которое относится к данному элементу рыночных данных. Идентификатор режима торгов SECBOARD. Примечание: финансовый инструмент с кодом SecCode может быть доступен для торгов в разных режимах. Вы должны рассматривать комбинацию Symbol (55) + TradingsessionId (336) как отдельный инструмент с отдельными котировками и таблицами сделок и заявок. Указывает период торгов Примечание: Значение периода торгов является пустым => 83 RptSeq О У int => 270 MDEntryPx Price => 271 MDEntrySize У Qty => 272 => 273 => 336 MDEntryDate MDEntryTime TradingSessionI D Н Н Н UTCDateOnly UTCTimeOnly String => 625 TradingSessionS ubID Н String NA – нет торгов O – период открытия C – период закрытия F – финальный период закрытия N – нормальный период торгов L – аукцион закрытия I – дискретный аукцион D – аукцион крупных пакетов E – период торгов по цене аукциона закрытия => 276 => 277 QuoteCondition TradeCondition Н Н MultipleValueStri ng MultipleValueStri ng 'C' (Наилучшая цена) 'C' (Расчеты по сделке осуществляются в день заключения сделки) 'J' (Расчеты по сделке осуществляются на следующий день после заключения сделки) 'R' (Цена открытия) 'AJ' (Официальная цена закрытия); ‘98’ (Минимальное значение); ‘99’ (Максимальное значение) '4' (Данные предыдущего торгового дня) ‘1’(Рыночная) до начала торгов и после закрытия торгов. Для инкрементальных обновлений и снэпшотов период торгов указывает на период, в который произошло событие для данного элемента, а не на текущий торговый период. Список условий, которые характеризуют котировку, условия между собой разделены пробелами. Условия, которые характеризируют сделку или рыночные данные, которые рассчитываются на базе сделки, условия между собой разделены пробелами. => 286 => 40 OpenCloseSettlFl ag OrdType Н H MultipleValueStri ng Char => 451 => 236 => 64 NetChgPrevDay Yield SettlDate Н Н Н PriceOffset Percentage LocalMktDate => 44 => 423 => 5292 Price PriceType BidMarketSize Н Н H Price int Int ‘1’ проценты ставки РЕПО => 5293 AskMarketSize H Int Флаг, который идентифицирует тип элемента рыночных данных. Тип заявки. Используется если MDEntryType (269) =’g’,’f ‘ Примечание: рыночные в аукцион заявки активируются и публикуются после начала аукциона закрытия. Сделки аукциона заключаются по его окончании. Изменение цены последней сделки по отношению к цене последней сделки предыдущего торгового дня. Доходность, рассчитанная по цене MDEntryPx (270). Дата расчетов по сделке (SettlementDate) в YYYYMMDD формате Примечания: Для обычных сделок – дата расчетов Для сделок РЕПО – дата расчетов первой части сделки РЕПО Ставка REPO для сделок REPO Указывает на тип цены (ставка REPO в процентах) для сделок REPO. Суммарный объем рыночных заявок в аукционе закрытия на покупку по ожидаемой цене аукциона, выраженный в единицах инструмента. Суммарный объем рыночных заявок в аукционе закрытия => 5384 => 5459 => 5510 AccruedInterestA mt SettlType ChgFromWAPric e BuyBackPx BuyBackDate Н Н Н Amt Char PriceOffset на продажу, выраженный в единицах инструмента. Объем накопленного купонного дохода. Код расчетов по сделкам (269=z) Изменение цены сделки по сравнению со средневзвешенной ценой предыдущего торгового дня. Для сделок РЕПО – сумма сделки РЕПО (269=z). Для сделок РЕПО – дата второй части сделки РЕПО (269=z) . Для сделок РЕПО – сумма второй части сделки РЕПО (269=z). Объём денежных средств. Используется если MDEntryType (269)=’f’ Рыночные в аукцион закрытия заявки на покупку в качесте объема указывают сумму денежных средств. Заявки другого типа содержат количество лотов торгуемого инструмента. Время активации заявки. Заявки и уровни цены в котировках, для которых не наступила активация, не участвуют в торгах. Общее количество сделок, заключенных на протяжении торгового дня. Объем совершенных сделок. Индикатор объема заявок крупными пакетами. Используется когда MDEntryType(269)=’v’ or ‘w’. N(переменное)*- величина индикатора определяется биржей. Количество заявок на продажу в очереди. Количество заявок на покупку в очереди. Объем котировки РЕПО, выраженный в рублях. В режиме торгов РЕПО с Центральным Контрагентом торги проводятся по ставкам РЕПО в качестве цены => 5558 => 5559 N H Price LocalMktDate => 5677 Repo2Px H Price => 5791 TotalVolume H Int => 5902 EffectiveTime Н Н Н H UTSTimestamp => 6139 => 6143 => 7017 TotalNumOfTrad es TradeValue VolumeIndicator int Amt int '0'(Нет заявок) '1' (Объем заявок не превышает порговой величины N*) '2' (Объем заявок превышает порговую величинуN*) => 9168 => 9169 => 9280 OfferNbOr BidNbOr NominalValue Н Н Н int int float денежных средств. Для этого режима, цены финансовых инструментов, участвующих сделках как обеспечение, уменьшаются по правилам управления рисками ЦК на величину, зависящую от типа инструмента и объема заявки в лотах. Объемы денежных средств в заявках на каждом уровне ставки РЕПО суммируются и публикуются в этом поле. Для других режимов торгов это поле не публикуется. => 9412 OrigTime N int Время транзакции в микросекундах как указано в торговой системе Данное значение следует прибавить к значению 273 тэга для получения времени транзакции с микросекундной точностью. Поле доступно в каналах сделок и заявок. => 10504 => 10505 =>10509 OrderSide OrderStatus MinCurrPx Н Н Н char char Price 'O' (Активная); 'T' (Время активации не наступило). =>10510 MinCurrPxChgTi me Н UTCTimeOnly Направленность заявки. Текущий статус заявки. Заявки со статусом T неактивны и не участвуют в торгах. Минимальная из двух цен: Официальной текущей цены и цены последней сделки, вошедшей в расчёт официальной текущей цены. Используется для определения условий запрета коротких продаж. Время изменения минимальной текущей цены. 5. Настройка сетевого соединения 5.1. Настройка VPN соединения с MOEX на базе Windows XP Для настройки VPN соединения необходимо выполнить следующее: 1. Убедитесь, что Internet подключен; 2. Нажмите Start, перейдите в Control Panel; 3. В Control Panel, двойной щелчок на Network Connections: 4. Выберите Create a new connection в Network Tasks: 5. В открывшемся помощнике Network Connection Wizard, нажмите Next: 6. Выберите Connect to the network at my workplace и нажмите Next: 7. Выберите Virtual Private Network connection и нажмите Next: 8. Введите название в поле Company Name (e.g. MOEX VPN Connection), и нажмите Next: 9. Выберите Do not dial the initial connection, и нажмите Next: 10. Введите IP адрес <адрес VPN сервера>, и нажмите Next: 11. Выберите My use only и нажмите Next: 12. Нажмите Finish, создание нового соединения завершено: 13. Не заполняете поля User name и Passwod, нажмите Properties 14. Перейдите на закладку Security, выберите Advanced (custom settings) и нажмите Settings…: 15. В выпадающем списке Data encryption выберите Optional encryption (connect even if no encryption) и нажмите OK: 16. На закладке Networking в выпадающем списке Type of VPN выберите PPTP VPN и нажмите OK: 5.2. Настройка VPN соединения с MOEX на базе Windows 7 1. Убедитесь, что Internet подключен. 2. Откройте Control Panel→Network and Internet→Network and Share Center и выберите Set up a new connection or network: 3. Выберите Connect to a workplace и нажмите OK: 4. Выберите No, create a new connection и нажмите Next 5. Нажмите Use my Internet Connection (VPN): 6. Введите <адрес VPN сервера> в поле Internet address, введите MOEX VPN Connection в поле Destination name, выберите Don’t connect now; just set it up so I can connect later и нажмите Next: 7. Оставьте следующее окно без изменений и нажмите Next: 8. Нажмите Close: 9. Откройте Control Panel→Network and Internet→Network and Share Center и нажмите Change adapter setting: 10. Откройте Properties для только что созданного соединения: 11. На закладке Security выберите в выпадающем списке Type of VPN - Point to Point Tunneling Protocol (PPTP), выберите в выпадающем списке Data encryption - Optional encryption (connect even if no encryption) и нажмите OK: 5.3. Настройка VPN соединения с MOEX на базе OpenSUSE 1. Убедитесь, что Internet подключен; 2. Установите pptp клиент, используя следующие команды: sudo zypper install pptp 3. Выполните следующую команду: sudo /usr/sbin/pptp-command setup 4. Введите ‘4’ и нажмите enter: 1.) Manage CHAP secrets 2.) Manage PAP secrets 3.) List PPTP Tunnels 4.) Add a NEW PPTP Tunnel 5.) Delete a PPTP Tunnel 6.) Configure resolv.conf 7.) Select a default tunnel 8.) Quit ?: 4 + <enter> 5. Введите ‘1’ и нажмите enter: Add a NEW PPTP Tunnel. 1.) Other Which configuration would you like to use?: 1 + <enter> 6. Введите ‘MOEX_vpn_connection’ и нажмите enter: Tunnel Name: MOEX_vpn_connection + <enter> 7. Введите <адрес VPN сервера> и нажмите enter: Server IP: <адрес VPN сервера> + <enter> 8. Введите ‘del default’ и нажмите enter: route: del default + <enter> 9. Введите ‘add default gw 1.1.1.1 TUNNEL_DEV’ и нажмите enter: route: add default gw 1.1.1.1 TUNNEL_DEV 10. Просто нажмите enter: route: <enter> 11. Введите ‘test’ и нажмите enter: Local Name: test 12. Оставьте значения по умолчанию и нажмите enter: Remote Name [PPTP]: <enter> 13. Если все было сделано правильно, вы должно увидеть: Adding MOEX_vpn_connection - <адрес VPN сервера> - test - PPTP Added tunnel MOEX_vpn_connection 14. Введите ‘8’ и нажмите enter чтобы выйти из помощника по установке. 15. Теперь необходимо сделать несколько изменений в только что созданном файле конфигурации. Для начала необходимо открыть его, выполнив команду: sudo vim /etc/ppp/peers/MOEX_vpn_connection 16. Необходимые изменения отмечены красным: # # PPTP Tunnel configuration for tunnel MOEX_vpn_connection # Server IP: <адрес VPN сервера> # Route: route del default # Route: route add default gw 1.1.1.1 TUNNEL_DEV # noauth # # Tags for CHAP secret selection # name test remotename PPTP # # Include the main PPTP configuration file # # file /etc/ppp/options.pptp 17. Пожалуйста, не забудьте сохранить файл перед закрытием. На этом все. Теперь необходимо установить VPN соединение, выполнив команду: sudo /usr/sbin/pptp-command start MOEX_vpn_connection На экране должно появиться примерно следующее: Using interface ppp0 Connect: ppp0 <--> /dev/pts/1 local IP address 1.1.1.19 remote IP address 1.1.1.1 Script ?? finished (pid 30023), status = 0x0 Script /etc/ppp/ip-up finished (pid 30032), status = 0x0 Route: add -net 0.0.0.0 gw 1.1.1.1 added Route: add -net 1.1.1.0 netmask 255.255.255.0 gw 1.1.1.1 added All routes added. Tunnel MOEX_vpn_connection is active on ppp0. IP Address: 1.1.1.19 18. Чтобы остановить соединение, нужно выполнить следующую команду: sudo /usr/sbin/pptp-command stop 19. Важно: После того, как VPN соединение будет закрыто необходимо восстановить правила маршрутизации. Иначе следующие попытки установить VPN соединение будут безуспешными. 5.4.Часто возникающие вопросы и методы их решения 1. VPN соединение установлено, но приложение не получает UDP пакеты (Windows 7) 1.1 Посмотрите на состояние вашего VPN соединения, и проверьте, что количество ¨Полученных£ байт возрастает. Если это не так, обратитесь в службу поддержки MOEX. 1.2 Проверьте настойки firewall. Временно отключите firewall. Если после этого все ¨заработает£, включите firewall и добавьте следующие настройки: ■ Откройте Windows Firewall→Advanced настройки; ■ Выберите Inbound Rules и в меню справа выберите New Rule: ■ Оставьте окно без изменений и нажмите Next: ■ В следующем окне необходимо указать путь к программе: ■ Оставьте следующие окна без изменений: ■ Укажите имя создаваемого правила. E.g. MyApplicationRule. Нажмите Finish. 6. Сертифицированные средства работы 6.1.Библиотека FIX Antenna TM от EPAM – B2BitsÛ EPAM Systems — крупнейший разработчик проектного (заказного) программного обеспечения и один из ведущих игроков в сфере ИТ-консалтинга в Центральной и Восточной Европе, и Центр компетенций по финансовым рынкам B2BITSÛ, входящий в состав компании EPAM Systems, сертифицировали свою высокопроизводительную библиотеку FIX Antenna TM для работы с платформой MOEX Market Data Multicast. FIX Antenna TM (C++ and .NET) позволяет осуществлять подписку на рыночные данные от MOEX Market Data Multicast прозрачно для программиста, скрывая всю работу по работе с потоками, восстановлению потерянных сообщений, предоставляя программисту объектноориентированный API. Пакет включает полную документацию и примеры кода, иллюстрирующие использование FIX Antenna TM с платформой MOEX Market Data Multicast. 6.1.1 Quick Start – примеры кода Ниже представлен код простейшего клиента. Этот код может служить скелетом реального приложения и демонстрирует возможные способы использования FIX Antenna TM для получения данных от MOEX Market Data Multicast. instrument_listener_impl.h: #pragma once #include <B2BITS_MOEX_mfix_listeners.h> namespace mfix_MOEX_client { class instrument_listener_impl : public MOEX_mfix::instrument_listener { public: virtual bool on_security_definition(const MOEX_mfix::security_description &sec_desc, const MOEX_mfix::security_id &sec_id, const MOEX_mfix::symbol &symb, const std::string &board, const Engine::FIXMessage &d_msg, const std::string &channel_id) { //add your processing code here, return your result true or false return false; } virtual void on_subscribed(const MOEX_mfix::symbol &symb, const std::string &board, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here } virtual void on_unsubscribed(const MOEX_mfix::symbol &symb, const std::string &board, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here } virtual void on_increment(const MOEX_mfix::symbol &symb, const std::string &board, const Engine::TagValue &entry, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here } virtual void on_security_status(const MOEX_mfix::symbol &symb, const std::string &board, const Engine::FIXMessage &msg, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here } virtual bool on_natural_refresh(const MOEX_mfix::symbol &symb, const std::string &board, const MOEX_mfix::increments &nr_msgs, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here, return your result true or false return true; } virtual void on_snapshot(const MOEX_mfix::symbol &symb, const std::string &board, const MOEX_mfix::snapshots &msgs, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here } virtual void on_recovery_started(const MOEX_mfix::symbol &symb, const std::string &board, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here, return your result true or false return false; } virtual void on_recovery_stopped(const MOEX_mfix::symbol &symb, const std::string &board, MOEX_mfix::mfix_recovery_reason reason, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here } virtual void on_error(const MOEX_mfix::symbol &symb, const std::string &board, const std::string &error, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here } }; } application_listener_impl.h: #pragma once #include <B2BITS_MOEX_mfix_listeners.h> namespace mfix_MOEX_client { class application_listener_impl : public MOEX_mfix::MOEX_mfix_application_listener { public: virtual void on_error(const std::string &error) { //add your processing code here } virtual void on_process(const Engine::FIXMessage &msg, const std::string &channel_id) { //add your processing code here } virtual void on_feed_reset(const std::string &channel_id, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here } virtual void on_heartbeat(const std::string &channel_id, MOEX_mfix::mfix_feed_type feed_type) { //add your processing code here } }; } main.cpp: #include <iostream> #include <B2BITS_FixEngine.h> #include <B2BITS_MOEX_mfix_application.h> #include "application_listener_impl.h" #include "instrument_listener_impl.h" using namespace mfix_MOEX_client; void subscribe_and_wait(MOEX_mfix::MOEX_mfix_application *app, instrument_listener_impl *&ins_listener); int main(int argc, char *agrv[]) { MOEX_mfix::MOEX_mfix_application *app = nullptr; application_listener_impl *app_listener = nullptr; instrument_listener_impl *ins_listener = nullptr; try { Engine::FixEngine::init("./engine.properties"); //configure parameters MOEX_mfix::MOEX_mfix_application_params app_params; app_params.templates_fn_ = "./FIX50SP2.xml"; app_params.config_xml_ = "./config.xml"; app_listener = new application_listener_impl(); app = Engine::FixEngine::singleton()->createMOEXApplication(app_params, app_listener); subscribe_and_wait(app, ins_listener); } catch (const Utils::Exception &ex) { std::cerr<<"Exception: "<<ex.what()<<"\ "; if (nullptr != app_listener) { app_listener->release(); } if (nullptr != ins_listener) { ins_listener->release(); } return 100; } app_listener->release(); ins_listener->release(); app->release(); return 0; } void subscribe_and_wait(MOEX_mfix::MOEX_mfix_application *app, instrument_listener_impl *&ins_listener) { //get channels id MOEX_mfix::channel_ids channels(app->get_channel_ids()); //get orderbook feed MOEX_mfix::MOEX_feed &order_book_feed = app->get_orderbook_feed(); ins_listener = new instrument_listener_impl(); //subscribe to known instrument in channel[1], with market recovery as recovery type order_book_feed.subscribe_by_symbol("AFLT", "EQBR", *ins_listener, channels[1],MOEX_mfix::RM_USE_MARKET_RECOVERY); while (true) { std::cout<<"Type 'q' for exit\ \ "; char c; std::cin>>c; if ('q' == c || 'Q' == c) { break; } } order_book_feed.unsubscribe_by_symbol("AFLT", "EQBR", channels[1]); } 6.1.2 Обзор API Для использования библиотеки необходимо подключить следующие заголовки : /include/B2BITS_MOEX_mfix_application.h /include/B2BITS_MOEX_mfix_listeners. /include/B2BITS_MOEX_mfix_types.h Список классов, структур, объединений и интерфейсов с кратким описанием: MOEX_mfix::instrument_listener MOEX_mfix::MOEX_feed MOEX_mfix::MOEX_mfix_application Слушатель инструментов ( паттерн observer) Представляет MOEX feed (поток stream) Представляет MOEX mfix application – класс с основными коллбэками MOEX_mfix::MOEX_mfix_application_listener MOEX_mfix::MOEX_mfix_application_params MOEX_mfix::security_definition_listener Представляет MOEX mfix application listener Параметры библиотеки Получает описания финансовых инструментов, вещаемых в потоке рыночных данных 6.1.2.1.1.