Сведение заявок на Срочном рынке МОЕХ - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Во время матчинга не может прилететь (или быть снята) лимитная (или маркет) заявка в стакан. Абсолютно все операции последовательны.
Сейчас только ленивый не написал биржевое ядро (для крипты). Заметьте, что технический вопрос пропуска данных не рассматривается. Просто чьи-то представления о том, как должно работать, выдаются за истину.
Не может прилететь или не будет принята? Если кто-нибудь обнаружит, что за время исполнения его заявки (оно не может же быть нулевым?) поступали заявки с лучшей ценой чем он получил, то не возникнут ли у него претензии?
Вроде бы декларируется первичность принципа предложения лучшей цены по отношению к принципу очереди по времени:
Все заявки, поданные участниками торгов, удовлетворяются в следующем порядке:
- по цене заявки;
- по времени подачи заявки, в случае указания одинаковой цены в двух и более заявок
PS. На мой взгляд, технические вопросы имеет смысл рассматривать после понимания как оно должно быть и почему оно должно быть именно так.Не может прилететь или не будет принята?
Правило очереди. Если идет матчинг, то ценообразование откладывается до окончания матчинга.
Здесь пишут так, будто матчинг - это какое-то время. На самом деле тысячи маркетов могут обрабатываться суммарно меньше миллисекунды. Это элементарный алгоритм, который может написать почти каждый.
Просто задайтесь целью написать биржевой механизм. Это почти Тестер, но только не по BestPrices, а по стакану. Там все ну очень просто и логично. Однопоток по каждому символу. Абсолютно все действия последовательны и супер-быстрые. Тестеры на основе ордерлога быстрее реал-тайм биржи на многие порядки. Поэтому длина очереди превышает единицу только в случае, если в одном пришедшем на сервер биржи сетевом пакете содержится сразу несколько приказов.
Никогда одиночные приказы, отправленные с разных физических машин, не могут увеличить очередь биржевого ядра больше, чем на единицу. Как бы не старались.
Правило очереди. Если идет матчинг, то ценообразование откладывается до окончания матчинга.
Здесь пишут так, будто матчинг - это какое-то время. На самом деле тысячи маркетов могут обрабатываться суммарно меньше миллисекунды. Это элементарный алгоритм, который может написать почти каждый.
Просто задайтесь целью написать биржевой механизм. Это почти Тестер, но только не по BestPrices, а по стакану. Там все ну очень просто и логично. Однопоток по каждому символу. Абсолютно все действия последовательны и супер-быстрые. Тестеры на основе ордерлога быстрее реал-тайм биржи на многие порядки. Поэтому длина очереди превышает единицу только в случае, если в одном пришедшем на сервер биржи сетевом пакете содержится сразу несколько приказов.
Никогда одиночные приказы, отправленные с разных физических машин, не могут увеличить очередь биржевого ядра больше, чем на единицу. Как бы не старались.
С указанным в заголовке ветки срочным рынком МОЕКС, скорее всего, так и есть. В том смысле, что результат вряд ли поменяется если сделать по другому.
ASK или BID формируется каждый раз, если скушан весь объем лучшей цены.
Дело не в очереди заявок (наших), ведь есть еще заявки оппонентов.
Представьте, что когда сводится мой объем 14 (а в стакане 13) в стакан прилетела (туда откуда мы берем)
заявка объемом 1 и с ценой, которая находится между лучшей ценой и следующей, которая была в стакане!
Если не возникнет новый ASK/BID, то последняя сделка будет совершена ПО НЕ СУЩЕСТВУЮЩЕЙ цене,
а такого, на Бирже, быть не может!
Следовательно Лучшая цена формируется каждый раз, после сведения предыдущей Лучшей цены.
Так понятно?
нет, пока не понятно.
Как я понимаю (упрощенно):
1. На какой-то момент времени есть стакан с заявками.
2. С какого-то сервера брокера на сервер биржи прилетает лимитная заявка. Здесь скорее всего есть предварительная проверка биржей - корректно ли все, не вылезает ли цена за планки, разрешена ли торговля для счета/субсчета и тп.
Если проверка пройдена, заявка ставится в очередь заявок на постановку в стакан.
3. Предположим эта очередь пустая. Тогда заявка сразу начинает исполняться. Здесь проводится окончательная проверка и затем сведение. Если заявка на покупку с ценой ниже лучшего аска, то она просто ставится в стакан. Если не ниже, то сведение и сделки.
4. Пока эта заявка исполяется, прилетают новые заявки от всех брокеров и они ставятся в очередь на постановку в стакан. Но они пока НЕ в стакане и поэтому никак не учитываются в сведении исполняемой заявки. То, что процитировал Aleksey Nikolayev :
"Все заявки, поданные участниками торгов, удовлетворяются в следующем порядке:
п.2 касается только тех заявок, которые уже были в стакане на начало исполнения текущей заявки.
Пока тек. заявка полностью не исполнятся нет никакого смысла публиковать новый аск, и бид тоже.
В общем, как fxsaber описал, хотя технические реализации могут быть очень разными.
Стакан - индикатор, который обновляет данные с меньшей частотой, чем происходят торговые события.
С указанным в заголовке ветки срочным рынком МОЕКС, скорее всего, так и есть.
К примеру, в Чикаго всё устроено сложнее.
К примеру, в Чикаго всё устроено сложнее.
Как именно?
Досконально не изучал, но по ссылке можно увидеть восемь разных алгоритмов сведения заявок. Помимо фифо есть ещё про-рата, где учитывается ещё объём заявки.
По сути обсуждаемого нами здесь вопроса ничего там не увидел.
Досконально не изучал, но по ссылке можно увидеть восемь разных алгоритмов сведения заявок. Помимо фифо есть ещё про-рата, где учитывается ещё объём заявки.
По сути обсуждаемого нами здесь вопроса ничего там не увидел.
Будем ждать дополнительной информации.
Пока же, немного пробежавшись по документу, я извлек следующую информацию:
Торговая информация включает в себя:
Как я понимаю, MT5 в своём стакане миксует FORTS_AGGR20_REPL (стакан) и FORTS_TRADE_REPL (история тиков), а вот FORTS_COMMON_REPL не используется для сохранения истории.
При этом:
К сожалению, в этом документе, не совсем то, что в примере, но техподдержка, пока не отвечает