FIX API для МТ5 - страница 2

 
Mesaoria:

Он мало чем отличается от того, что можно найти в примерах к QuickFIX  ( http://www.quickfixengine.org/quickfix/doc/html/sending_messages.html ):

Не стоит забывать, что бизнес-логика всегда заведомо важнее (и сложнее) транспорта, а FIX - это транспорт.

Кроме того, я использую версию QuickFIX с собственными оптимизациями, в частности, полностью переписанным парсером MarketDataSnapshotFullRefresh / MarketDataIncrementalRefresh .

Слова - ничто, дайте код.

 
prostotrader:

МТ5, раньше точно, работал через Плаза 2,

Никогда разработчики не пойдут на то, чтобы дать инструмент, который будет работать

в обход терминала. (Почему? Подумайте сами...) 

Был анонс? Был. Хочется подробностей. Как можно о чем-то рассуждать на данном этапе - не понятно. Т.к. не понятно, о чем рассуждать:)

 
prostotrader:

Слова - ничто, дайте код.

Для чего Вам код упаковки команд "послать новый ордер" в FIX, или распаковки события "новый стакан" в собственную структуру?

ну вот сниппет. Подписывается на полный стакан по символу. В ответ полетят события MarketDataSnapshotFullRefresh, или MarketDataRequestReject. Все это описано в стандарте и в документации конкретного провайдера.

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

FIX44::MarketDataRequest Request;

Request.set(FIX::MDReqID(
        "MSA" + SymbolName + std::to_string(::time(nullptr))
));

Request.set(FIX::SubscriptionRequestType(FIX::SubscriptionRequestType_SNAPSHOT_PLUS_UPDATES));
Request.set(FIX::MarketDepth(0));
Request.set(FIX::MDUpdateType(FIX::MDUpdateType_FULL_REFRESH));

FIX44::MarketDataRequest::NoRelatedSym SymbolsGroup;
SymbolsGroup.set(FIX::Symbol(SymbolName));
Request.addGroup(SymbolsGroup);

FIX44::MarketDataRequest::NoMDEntryTypes EntriesGroup;
EntriesGroup.set(FIX::MDEntryType_BID);
Request.addGroup(EntriesGroup);
EntriesGroup.set(FIX::MDEntryType_OFFER);
Request.addGroup(EntriesGroup);

FIX::Session::sendToTarget(Request, m_SessionID);
 
Alexey Kozitsyn:

Был анонс? Был. Хочется подробностей. Как можно о чем-то рассуждать на данном этапе - не понятно. Т.к. не понятно, о чем рассуждать:)

Вам виднее, но для меня всё прозрачно и очевидно.

 
Mesaoria:

Для чего Вам код упаковки команд "послать новый ордер" в FIX, или распаковки события "новый стакан" в собственную структуру?

ну вот сниппет. Подписывается на полный стакан по символу. В ответ полетят события MarketDataSnapshotFullRefresh, или MarketDataRequestReject. Все это описано в стандарте и в документации конкретного провайдера.

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

Даже НЕ смешно

Даваёте на этом и закончим.

 
prostotrader:

Даже НЕ смешно

Даваёте на этом и закончим.

Давайте, просто непонятно, откуда про "2 года" взяли. За 2 года можно новый язык программирования выучить, а не простой текстовый протокол из 10 (нужных) команд.

 
Mesaoria:

Раз заговорили про стакан. Скажите пожалуйста, можно ли с помощью FIX API получить время прихода снапшота стакана? И если да, то какова его точность (милли-, микро-,нано)?

 
Alexey Kozitsyn:

Раз заговорили про стакан. Скажите пожалуйста, можно ли с помощью FIX API получить время прихода снапшота стакана? И если да, то какова его точность (милли-, микро-,нано)?

По стандарту есть 52 тэг - время генерации события у отправляющей стороны. Обычно точностью до миллисекунд (но "стандарт" допускает и микро и нано,).

Сопоставляя его с текущим временем (в динамике) можно примерно оценить сетевую задержку и ее временные всплески.

Конечно, это всё не очень точно.

 
Mesaoria:

По стандарту есть 52 тэг - время генерации события у отправляющей стороны. Обычно точностью до миллисекунд (но "стандарт" допускает и микро и нано,).

Сопоставляя его с текущим временем (в динамике) можно примерно оценить сетевую задержку и ее временные всплески.

Конечно, это всё не очень точно.

Это и нужно, знать время генерации события (снятия слепка), чтобы потом его можно было сопоставить со временем открытия сделок. Миллисекундной точности будет вполне достаточно. 

Вот даже если разработчики дадут возможность получить это время - это уже хорошо.

Если через фикс можно будет получить еще и время обновления данных типа открытого интереса - вообще замечательно.

 
Alexey Kozitsyn:

Это и нужно, знать время генерации события (снятия слепка), чтобы потом его можно было сопоставить со временем открытия сделок. Миллисекундной точности будет вполне достаточно. 

Вот даже если разработчики дадут возможность получить это время - это уже хорошо.

Если через фикс можно будет получить еще и время обновления данных типа открытого интереса - вообще замечательно.

Пардон, я немного некорректно выразился.

Под "генерацией события" имел в виду время отправки сообщения клиенту. Само событие могло произойти и раньше.

В FIX это поле так и называется - SendingTime. 

Брокер/дилер может по своему усмотрению вставлять дополнительные поля со временем, в частности, так делал Dukas (у них было время уже именно генерации каждого ценового банда, если правильно помню)

Причина обращения: