|
|
vaskoСтаж: 12 лет 2 месяцаСообщений: 1272 | | | | westtrd писал(а):Но до приема всего снапшота 1..N о корректном парсинге говорить невозможно
корректно, ибо LastFragment: 1
| | |
|
Константин МымринСтаж: 9 лет 4 месяцаОткуда: Московская биржаСообщений: 22 | | | | vasko, приветствую,
Устранили проблему с некорректными данными в FUT-BOOK-5_F_Snapshot_A.
Благодарю за баг-репорт.
| | |
|
RobinСтаж: 5 лет 4 месяцаСообщений: 112 | | | | Держу пари, что проблема с проглатыванием пакетов у vasko осталась
| | |
|
westtrdСтаж: 9 лет 8 месяцевОткуда: BelarusСообщений: 1034 | | | | vasko писал(а):westtrd писал(а):Но до приема всего снапшота 1..N о корректном парсинге говорить невозможно
корректно, ибо LastFragment: 1
Как только у вас пропуск в sequence, фид переходит в failed state
| | |
|
vaskoСтаж: 12 лет 2 месяцаСообщений: 1272 | | | | Константин Мымрин писал(а):Устранили проблему с некорректными данными в FUT-BOOK-5_F_Snapshot_A.
спасибо, но если ваше утверждение было верным, как обьяснить такое снапшот сообщение полученное на следующий день с FUT-BOOK-5_F_Snapshot_A.log:
6027500000e-5 > 6006400000e-5
2017-02-10 21:40:54.511901: seq_id: 2, size: 304
2017-02-10 21:40:54.511902: id: 13
2017-02-10 21:40:54.511930: {MsgSeqNum: 2 SendingTime: 20170210184054507 LastFragment: 1 RptSeq: 94266 TotNumReports: 41 LastMsgSeqNumProcessed: 1538275 SecurityID: 419139}
{MDEntryType: 0 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6027500000e-5 MDEntryDate: 0 MDEntryTime: 145807388861400 MDEntrySize: 10 MDPriceLevel: 1 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
{MDEntryType: 0 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6019300000e-5 MDEntryDate: 0 MDEntryTime: 150330928686500 MDEntrySize: 3000 MDPriceLevel: 2 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
{MDEntryType: 0 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6016800000e-5 MDEntryDate: 0 MDEntryTime: 123102053656200 MDEntrySize: 500 MDPriceLevel: 3 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
{MDEntryType: 0 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6011100000e-5 MDEntryDate: 0 MDEntryTime: 161938605434200 MDEntrySize: 8 MDPriceLevel: 4 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
{MDEntryType: 0 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6008100000e-5 MDEntryDate: 0 MDEntryTime: 174457729643600 MDEntrySize: 4 MDPriceLevel: 5 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
{MDEntryType: 1 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6006400000e-5 MDEntryDate: 0 MDEntryTime: 184049692920100 MDEntrySize: 30 MDPriceLevel: 1 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
{MDEntryType: 1 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6006800000e-5 MDEntryDate: 0 MDEntryTime: 183838462797800 MDEntrySize: 150 MDPriceLevel: 2 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
{MDEntryType: 1 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6007400000e-5 MDEntryDate: 0 MDEntryTime: 184025931116300 MDEntrySize: 20 MDPriceLevel: 3 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
{MDEntryType: 1 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6007900000e-5 MDEntryDate: 0 MDEntryTime: 183410965314500 MDEntrySize: 150 MDPriceLevel: 4 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
{MDEntryType: 1 MDEntryID: 0 MarketDepth: 5 MDEntryPx: 6008000000e-5 MDEntryDate: 0 MDEntryTime: 184003012055600 MDEntrySize: 100 MDPriceLevel: 5 NumberOfOrders: 0 MDEntryTradeType: TrdType: 0}
| | |
|
Константин МымринСтаж: 9 лет 4 месяцаОткуда: Московская биржаСообщений: 22 | | | | vasko, приветствую,
Действительно, 10 февраля опять были некорректные данные в FUT-BOOK-5_F_Snapshot_A.
Начиная с 14 февраля исправлено.
| | |
|
| pavvvkin | | | | Apollo писал(а):... 5d ee 01 00 e0 1b b8 07 5c dd 23 68 04 53 47 2b
... Начинаем парсить... Первые 4 байта по спецификации MOEX (5d ee 01 00) - это порядковый номер 126557 (пока трудностей нет). ...
Пардон, но ведь 00 01 ee 5d - это 126557, т.е. чтобы получить 126557, нужно записать байты в порядке, обратном указанному
Apollo писал(а):... Template ID (1b b  равен 3512 (Шаблон найден). ...
1b b8 - это 7096, и даже b8 1b - это 47131
0d b8 ведь будет 3512
| | |
|
oleg1101Стаж: 1 год 9 месяцевСообщений: 2 | | | | Столкнулся с проблемой разборки данных по FAST шаблону 3610
Сам шаблон выглядит следующим образом:
<!-- Market Data - Incremental Refresh OLR CURR-->
<template name="X-OLR-CURR" id="3610" xmlns="http://www.fixprotocol.org/ns/fast/td/1.1">
<string name="MessageType" id="35"><constant value="X" /></string>
<string name="ApplVerID" id="1128"><constant value="9"/></string>
<string name="BeginString" id="8"><constant value="FIXT.1.1"/></string>
<string name="SenderCompID" id="49"><constant value="MOEX"/></string>
<uInt32 name="MsgSeqNum" id="34"></uInt32>
<uInt64 name="SendingTime" id="52"></uInt64>
<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>
<string name="MDEntryID" id="278" presence="optional"></string>
<string name="Symbol" id="55" presence="optional"><copy/></string>
<int32 name="RptSeq" id="83" presence="optional"></int32>
<uInt32 name="MDEntryDate" id="272" presence="optional"><copy/></uInt32>
<uInt32 name="MDEntryTime" id="273" presence="optional"><copy/></uInt32>
<uInt32 name="OrigTime" id="9412" presence="optional"><copy/></uInt32>
<decimal name="MDEntryPx" id="270" presence="optional"><copy/></decimal>
<decimal name="MDEntrySize" id="271" presence="optional"><copy/></decimal>
<string name="OrderStatus" id="10505" presence="optional"><copy/></string>
<string name="TradingSessionID" id="336" presence="optional"><copy/></string>
<string name="TradingSessionSubID" id="625" presence="optional"><copy/></string>
</sequence>
</template>
10.05.2019 По каналу OLR-A получил следующий пакет:
C0|1C 9A|0C 11 85|02 52 34 7E 04 23 18 09 CE|81|77 F8|81|B0|31 38 37 35 36 B9|55 53 44 30 30 30 54 4F 44 54 4F CD|01 30 AC|35 7A 08 C9|21 21 91|FC|01 D1|81|9F|CF|43 45 54 D3|CE|
Разберем пакет по стоп-битам:
C0| - PMAP: 01000000
1C 9A| - Номер шаблона 3610
0C 11 85| - MsgSeqNum
02 52 34 7E 04 23 18 09 CE| - SendingTime
81| - NoMDEntries длина sequence (1 элемент)
77 F8| - MDUpdateAction
81| - MDEntryType
B0| - MDEntryID
31 38 37 35 36 B9| - Symbol
55 53 44 30 30 30 54 4F 44 54 4F CD| - RptSeq (Противоречие! по кол-ву байт это не может быть int32)
01 30 AC| - MDEntryDate
35 7A 08 C9| - MDEntryTime
21 21 91| - OrigTime
FC|01 D1| - MDEntryPx
81|9F| - MDEntrySize
CF| - OrderStatus
43 45 54 D3| - TradingSessionID
CE| - TradingSessionSubID
Противоречия:
1) Внутри sequence GroupMDEntries есть 10 операторов COPY, какждый из которых требует свой бит в PMAP. В то время как реально в PMAP всего 7 бит. Явно не хватает.
2) Из ручной разборки пакета видно, что все данные шаблона присутсвуют в пакете. Но PMAP имеет соответствующие им нулевые биты, как будто данных нет.
3) RptSeq типа int32 никак не может содержать 12 байт. Этb байты соответсвуют строке 'USD000TODTOM'. Это значит, что сопоставление данных с шаблоном сдвинуто на 1, но не понятно, где...
Прошу подкинуть идеи, как разрешить данные противоречия...
P.S.
Разобрался.
Байты 77 F8| в начале sequence - это не MDUpdateAction, а PMAP.
PMAP внутри sequence присутствует, если хотя-бы 1 поле его требует, а в шаблоне 11 операторов copy, и все эти поля требуют PMAP
| | | | | | | Последний раз редактировалось автором 12.05.2019 12:56, всего редактировалось 2 раза |
|
ShurikСтаж: 14 лет 4 месяцаОткуда: Санкт-ПетербургСообщений: 635 | | | | Коллеги, не подскажите, а что приходит в качестве экспоненты и мантиссы для опционального поля типа decimal в случае, если оно равно null? Дважды null, т.е. 2 раза 0x80? Разобрался, 1 раз 0x80.
| | | | | | | Последний раз редактировалось автором 10.07.2019 10:53, всего редактировалось 2 раза |
|
|
Поиск
Правила
Пользователи
Профиль
Регистрация
Вход
