ПоискПоиск  ПравилаПравила  ПользователиПользователи  ПрофильПрофиль  РегистрацияРегистрация  ВходВход
Форум «Техническая поддержка ПО ASTS»
Форум разработчиков и пользователей программного обеспечения, предназначенного для работы на рынках, обслуживаемых торгово-клиринговой системой ММВБ (ASTS).
определение своих заявок при работе через fast
Новая тема   Ответить на тему
На страницу 1, 2  След.
 Предыдущая тема :: Следующая тема 
 Автор  Сообщение 
Oleg Vazhnev
Стаж: 8 лет
Сообщений: 1381
Пн Окт 15, 2012 22:35 Ответить с цитатой Получить постоянный адрес сообщения
Хотелось бы получить апдейт по вопросу “показывать публичный ID в потоке FAST в ответе на регистрацию заявки”. Врод как запланировано? Есть ли сроки? Я правильно понимаю что сейчас при работе через фаст нормального способа получить стакан “очишенный” от своих заявок нет? 
 
Grigory Baytsur
Стаж: 5 лет 9 месяцев
Откуда: Москва
Сообщений: 46
Пт Окт 19, 2012 16:48 (спустя 3 дня 18 часов) Ответить с цитатой Получить постоянный адрес сообщения
Вопрос мне непонятен. По определению, в таблице агрегированных котировок (стаканах) невозможно увидеть всои заявки или как-то от них "очиститься".

Принцип работы udp multicast вещания состоит в том, что передается общаяя информация, одинаковая для всех. В ней по определению не может быть ничего индивидуального.  
 
Oleg Vazhnev
Стаж: 8 лет
Сообщений: 1381
Пт Окт 19, 2012 16:56 (спустя 3 дня 18 часов) Ответить с цитатой Получить постоянный адрес сообщения
Григорий, вот ваши слова из переписки на другом форуме полугодичной давности:

=============================
В отличие от более простого рынка FORTS, мы не можем публиковать в OrderList биржевой номер заявки – у нас активно используются айсберг-заявки, и нам надо их защищать. В текущей реализации каждое событие обновления видимого количества айсберг заявки публикуется как снятие этой заявки и постановка новой с новым ID и новым видимым количеством. При этом ID всех заявок в потоке – это порядковый номер события Add Order, а не биржевой номер заявки. Вы не можете понять, где находится ваша заявка.
В планах сделать этот публичный ID видимым вам в параметрах вашей заявки.
=============================

Меня в общем то интересует только последнее предложение "В планах сделать этот публичный ID видимым вам в параметрах вашей заявки.". Хотелось бы узнать каков сейчас статус (запланировано, отменено, сделано)?

Конечно же я смогу очиститься от своих заявок, если вы мне по защищённому каналу будете передавать публичные FAST идентификаторы моих заявок Smile За исключенем случаев когда в фаст заявка прилетит раньше, чем я получу публичный идентификатор. 
 
Последний раз редактировалось автором 19.10.2012 17:10, всего редактировалось 1 раз
Grigory Baytsur
Стаж: 5 лет 9 месяцев
Откуда: Москва
Сообщений: 46
Пт Дек 28, 2012 16:14 (спустя 2 месяца 12 дней 17 часов) Ответить с цитатой Получить постоянный адрес сообщения
В январе будет обновление, в котором:
- для FIX заявок будет в Execution Report / New и Pending Cancel возвращаться timestamp регистрации/снятия заявки. Он уникален для каждого события. Для сделок timestamps и так есть.
- в FAST будут присутствовать те же timestamps для добавления, изменения и удаления заявок. Сейчас для изменения или удаления заявки в результате сделки время события не публикуется.

По этим timestamps в потоке FAST можно будет найти свою заявку.

Обновление не меняет форматов сообщений - просто необязательные тэги с timestamp будут присутствовать всегда. В клиентском коде ничего менять не надо, если не добавлять в него поиска своей заявки.

FIX с timestamps уже доступен на тестовом контуре. FAST еще релизный.

Точная дата замены версий пока неизвестна. Скорее всего, 21 января. Специальных уведомлений не будет, потому что совместимость не нарушается.  
 
Oleg Vazhnev
Стаж: 8 лет
Сообщений: 1381
Пт Авг 23, 2013 19:04 (спустя 10 месяцев 8 дней 20 часов) Ответить с цитатой Получить постоянный адрес сообщения
Григорий, вы пишите что "timestamp уникален для каждого события", я хотел бы уточнить.

Правильно ли я понимаю что по проштампованному времени (с микросекундной точностью) я однозначно могу идентифицировать заявку? Т.е. в одну и ту же микросекунду на бирже не может произойти больше 1го события? Или может?

В фортсовом ордерлоге я ориентируюсь просто по биржевому order id, но тут ничего подобного не светит? Ничего лучше микросекунд предложить нельзя? Завязываться на то что "не больше одного события в микросекунду" боязно, ненадёжно. Ведь прогресс идёт и через годик будет уже "не больше 10 событий в микросекунду". А что будет делать биржа если одновременно поступит 1000 заявок на покупку чего-нибудь по рынку, заявки получается растянутся как минимум на 1 миллисекунду? Одновременно отправить 1000 заявок в целом возможно, не один участник конечно, а всем вместе. У кого-то round-trip получается возрастёт на целую миллисекунду?

В общем меня свойство "не больше одного события в микросекунду" очень интересует. Это специально сделано для удобства и насколько перспективно на такое закладываться? 
 
Последний раз редактировалось автором 23.08.2013 19:06, всего редактировалось 3 раза
Grigory Baytsur
Стаж: 5 лет 9 месяцев
Откуда: Москва
Сообщений: 46
Вт Авг 27, 2013 16:26 (спустя 10 месяцев 12 дней 17 часов) Ответить с цитатой Получить постоянный адрес сообщения
Короткий ответ - в одну микросекунду не может произойти более 0.02 события. Чтобы сделать эту цифру больше единицы, потребуется немало времени. Вот тогда и будем менять логику.  
 
Oleg Vazhnev
Стаж: 8 лет
Сообщений: 1381
Ср Авг 28, 2013 11:32 (спустя 10 месяцев 13 дней 12 часов) Ответить с цитатой Получить постоянный адрес сообщения
Спасибо 
 
Oleg Vazhnev
Стаж: 8 лет
Сообщений: 1381
Пн Мар 24, 2014 11:22 (спустя 1 год 5 месяцев 6 дней) Ответить с цитатой Получить постоянный адрес сообщения
Я вижу в новом релизе добавили такую фичу:

"Передача, в том числе в шлюзе, информации о публичном номере собственной заявки в FAST-потоке."

Хотел бы узнать с точки зрения биржи зачем это было сделано и как это предполагается использовать? 
 
Последний раз редактировалось автором 24.03.2014 11:22, всего редактировалось 1 раз
Grigory Baytsur
Стаж: 5 лет 9 месяцев
Откуда: Москва
Сообщений: 46
Пн Мар 24, 2014 11:33 (спустя 1 год 5 месяцев 6 дней) Ответить с цитатой Получить постоянный адрес сообщения
Для удобства нахождения своей заявки в потоке обезличенных активных заявок FAST.
Предполагается использование именно для этого.

Все вопросы про это уже были заданы полтора года назад в этой теме, и были даны ответы. Теперь сделали отдельное поле, без использования timestamps не по прямому назначению.  
 
Oleg Vazhnev
Стаж: 8 лет
Сообщений: 1381
Пн Мар 24, 2014 12:05 (спустя 1 год 5 месяцев 6 дней) Ответить с цитатой Получить постоянный адрес сообщения
Спасибо Григорий,

Решил перепроверится поскольку выдёргивание личной информации из фаста - фишка конечно интересная. Здорово что биржа такое сделала, я конечно попробую обязательно. Так просто интересно это инновация или более менее используется где-то ещё?

А в фиксе тоже будет трансляция?
Гарантируется ли что каждая своя заявка будет сопровождаться фаст номером который гарантированно появится в фаст потоке? Или всё же некоторые свои заявки могут не транслироваться в фасте? Например заявки по рынку ведь можно в фаст и не транслировать (достаточно просто изменить соответствующие "котировочные" заявки). 
 
Grigory Baytsur
Стаж: 5 лет 9 месяцев
Откуда: Москва
Сообщений: 46
Пн Мар 24, 2014 12:29 (спустя 1 год 5 месяцев 6 дней) Ответить с цитатой Получить постоянный адрес сообщения
В FIX Execution Report добавлен тэг 278, о чем написано в истории изменений в документации и в описании форматов сообщений.
FAST публикует только активные заявки, а не все. Рыночные, IOC, FOK, полностью исполненные, снятые по критериям предотвращения кросс-сделок, не публикуются. Такие заявки могут иметь значение в тэге 278 в FIX, в ответе ТС и в таблице ORDERS.
У айсбергов публичный номер изменяется при пополнении видимой части, о чем будет сообщаться в тэге 278 в Execution report и в таблице ORDERS.

Изменений на деле больше.

1. Обратите внимание, что все отказы от ядра ТС будут иметь timestamp, в том числе и в FIX Execution Report / Order Cancel Reject. Это полезно для понимания, какой именно был стакан, когда вашему приказу было отказано в исполнении.

2. Добавляются также две новые причины отказа - заявка исполнена и заявка уже снята, (915) и (916). Это помогает избавиться от миллионов попыток снять заявку в ответ на отказ "не найдено заявок для снятия".

3. В ответе функции ExecTransEx появится еще и биржевой номер заявки в отдельном поле. Это позволяет при обработке ответа ориентироваться именно на него, а не выискивать номер заявки в тексте ответа ТС на одном из двух языков, и держать в коде еще и список номеров ошибок, при которых заявка все же регистрируется.  
 
Grigory Baytsur
Стаж: 5 лет 9 месяцев
Откуда: Москва
Сообщений: 46
Пн Мар 24, 2014 12:41 (спустя 1 год 5 месяцев 6 дней) Ответить с цитатой Получить постоянный адрес сообщения
Добавление про инновацию.
Вообще-то, очень многие используют timestamps для нахождения своих заявок в потоке (и их приоритета в очереди, и оценок своей скорости реакции относительно конкурентов) from day one от добавления микросекунд к временам.
Введение отдельного публичного идентификатора активной заявки упрощает процесс и делает его приспособленным для того случая, когда времена регистрации заявок перестанут быть уникальными.

Еще одно преимущество - если FAST переключится на резерв, то эти идентификаторы ( 278 ) заявок не изменятся. В настоящее время это не так - при переключении на резерв он будет публиковать другие значения строки 278, не совпадающие с основным сервером.  
 
Последний раз редактировалось автором 24.03.2014 12:42, всего редактировалось 1 раз
Oleg Vazhnev
Стаж: 8 лет
Сообщений: 1381
Пн Мар 24, 2014 13:22 (спустя 1 год 5 месяцев 6 дней) Ответить с цитатой Получить постоянный адрес сообщения
Спасибо Григорий, отличные нововведения, буду использовать.

FAST шаблон ведь не меняется? Вообще нет каких-нибудь изменений которые влекут изменение клиентского кода? Обратная совместимость сохраняется? 
 
Grigory Baytsur
Стаж: 5 лет 9 месяцев
Откуда: Москва
Сообщений: 46
Пн Мар 24, 2014 13:36 (спустя 1 год 5 месяцев 6 дней) Ответить с цитатой Получить постоянный адрес сообщения
про FIX/FAST было так написано (см. ниже весь текст). Обратная совместимость в FIX сохраняется, если вы умеете игнорировать тэги, которых не ожидаете получить в FIX (278 в 35=8, 60 и 9412 в 35=9). Для FAST - если не предполагаете, что поле 278 - цифра, которая прирастает единицей. Шаблон не меняется.

Что касается шлюза, то надо либо оставаться на интерфейсе < 22, либо научиться использовать или игнорировать перечисленные нововведения.

===


MFIX transactional фондового рынка:
- в сообщения Execution report добавлено поле MDEntryID (278 ), указывающее на публичный номер заявки в потоке данных об обезличенных активных заявках рынка Order List Refresh / Snapshot (OLR/OLS) сервиса FAST UDP multicast marketdata. Это поле позволяет идентифицировать собственные заявки в книге заявок рынка для анализа торговых стратегий
- в сообщение Order Cancel Reject добавлено значение поля CxlRejReason (102) '0' : too late to cancel, указывающее на то, что заявка уже не активна. Добавлено поле Order Status (39), указывающее на статус заявки на момент получения отвергаемого запроса на ее снятие.

FAST udp multicast marketdata сервис фондового рынка:
Изменен алгоритм формирования публичного идентификатора заявки MDEntryID (278 ) в потоках Order List Refresh / Snapshot (OLR/OLS). Как и ранее, это поле типа String содержит возрастающее число, но его приращения при добавлении новой заявки могут отличаться от единицы. Значения поля MDEntryID (278 ) будут сохраняться в случае переключения на резервный сервер или при рестарте основного сервера в течение торгового дня. Данное изменение не предполагает каких-либо изменений в функциональности сервиса.

Предполагаемая дата внедрения указанных доработок на валютном рынке - первый релиз валютного рынка в втором квартале 2014 года.

Общее изменение MFIX transactional фондового и валютного рынков с 31 марта 2014 года:
- в сообщения Order Cancel Reject, Order Mass Cancel Report, Execution Report (rejected) добавлены поля TransactTime (60) и OrigTime (9412), указывающие время начала обработки ядром торговой системы запроса, который привел к отправке данных сообщений. Ранее данные timestamps были доступны только для успешных регистраций или снятий заявок.
Использование точных timestamps времен обработки запросов, независимо от их результатов, позволяет сопоставлять состояние книги заявок рынка с результатом обработки запроса и определить причины получения любых ответов от сервера к клиенту.

Обновленная документация размещена по адресу ftp://ftp.moex.com/pub/FIX/ASTS/docs/. Документация и функциональность FAST udp multicast marketdata сервиса не изменялись.

 
 
Последний раз редактировалось автором 24.03.2014 13:37, всего редактировалось 2 раза
Oleg Vazhnev
Стаж: 8 лет
Сообщений: 1381
Чт Мар 27, 2014 13:09 (спустя 1 год 5 месяцев 9 дней) Ответить с цитатой Получить постоянный адрес сообщения
Спасибо Григорий, продолжаю серию вопросов Smile

"идентификатора заявки MDEntryID (278 ) в потоках Order List Refresh / Snapshot (OLR/OLS). Как и ранее, это поле типа String содержит возрастающее число, но его приращения при добавлении новой заявки могут отличаться от единицы"

лично я на настоящий момент никак не закладываюсь, просто складываю в мэпу, но в будущем возможно стал бы использовать тот факт что MDEntryID плавно возрастает.

насколько сильно приращение может отличаться от единицы? может сразу скакнуть на 10 миллионов например? 
 
Последний раз редактировалось автором 27.03.2014 13:09, всего редактировалось 1 раз
Показать сообщения:   
Новая тема   Ответить на тему
Список разделов форума -> Техническая поддержка ПО ASTSНа страницу 1, 2  След.
Страница 1 из 2

Rambler's Top100 Rambler's Top100
Рейтинг@Mail.ru
Copyright © Московская биржа, 2006-2017.
Ваши предложения, замечания и вопросы
по работе форума направляйте на email: