Чудеса с тиковым потоком на ФОРТС - страница 3

Новый комментарий
 
Vasiliy Sokolov:
Теперь интересно узнать, реагирует ли OnBookEvent на событие Last?
Стакан - это котировочный поток. Конечно, реагирует. Но может быть маленькое отставание, которое на практике заметить - нужно постараться.
 
fxsaber:
Стакан - это котировочный поток. Конечно, реагирует. Но может быть маленькое отставание, которое на практике заметить - нужно постараться.
Сравнивал последний тик с ask/bid стакана цен, полученным через MarketBookGet. Результат такой же: last часто за диапазонами его лучших бандов, что печально.
 
Vasiliy Sokolov:

Выходит что last - это execution поток. А Ask/Bid - котировочные потоки. Т.е. сначала выжирается ликвидность ластом, а затем нам приходит рапорт: "ликвидность выжрана, текущие Ask/Bid такие-то".

Следовательно, высказанное мной предположение верно: текущий тик однозначно описывает уровень last, а вот уровни Ask и Bid в нем могут соответствовать еще предыдущим значениям.

В общем, как мне кажется, вы здесь пытаетесь нащупать то, что написано в справке https://www.mql5.com/ru/docs/series/copyticks

Примечание

Функция CopyTicks() позволяет запрашивать и анализировать все пришедшие тики. Первый вызов CopyTicks() инициирует синхронизацию базы тиков, хранящихся на жёстком диске по данному символу. Если тиков в локальной базе не хватает, то недостающие тики автоматически будут загружены с торгового сервера. При этом будут синхронизированы тики с даты from, указанной в  CopyTicks(), по текущий момент. После этого все приходящие по данному символу тики будут поступать в тиковую базу и поддерживать её в актуальном синхронизированном состоянии.

Если параметры from и count не указаны, то в массив ticks_array[] будут записаны все доступные тики, но не более 2000. Параметр flags позволяет задать тип требуемых тиков.

COPY_TICKS_INFO – отдаются тики, в которых есть изменения цены Bid и/или Ask. Но при этом будут также заполнены данные остальных полей, например, если изменилась только цена Bid, то в поля ask и volume будут записаны  последние известные значения. Чтобы узнать точно, что именно изменилось, необходимо анализировать поле flags, которое будет иметь значение  TICK_FLAG_BID и/или TICK_FLAG_ASK.  Если тик имеет нулевые значения цен Bid и Ask, и при этом флаги показывают, что эти данные цены изменились (flags=TICK_FLAG_BID|TICK_FLAG_ASK), то это говорит об опустошении стакана заявок. Другими словами,  в этот момент отсутствуют заявки на покупку и  продажи.

COPY_TICKS_TRADE – отдаются тики, в которых есть изменения последней цены сделки и объема. Но при этом будут также заполнены данные остальных полей, то есть в поля Bid и Ask будут записаны  последние известные значения. Чтобы узнать точно, что именно изменилось, необходимо анализировать поле flags, которое будет иметь значение TICK_FLAG_LAST и TICK_FLAG_VOLUME.

COPY_TICKS_ALL – отдаются все тики, в которых есть хоть какое-то изменение. При этом неизмененные поля также заполняются последними известными значениями.

Вызов CopyTicks() с флагом  COPY_TICKS_ALL выдает сразу все тики из запрашиваемого диапазона, в то время как вызов в других режимах требует некоторого времени на предобработку и выборку тиков, и поэтому не даёт существенного выигрыша по скорости выполнения.

При запросе тиков (неважно, COPY_TICKS_INFO или COPY_TICKS_TRADE), в каждом тике содержится полная ценовая информация на момент тика (bid, ask, last и volume). Это сделано для удобства анализа торговой обстановки на момент каждого тика, чтобы не приходилось каждый раз запрашивать глубокую тиковую историю и искать в ней значения по другим полям.

Документация по MQL5: Доступ к таймсериям и индикаторам / CopyTicks
Документация по MQL5: Доступ к таймсериям и индикаторам / CopyTicks
  • www.mql5.com
Доступ к таймсериям и индикаторам / CopyTicks - справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
 
fxsaber:

А по другому никак не организовать на самом деле, если делать биржу без тормозов.

Почему?
 
Andrey Khatimlianskii:
Почему?

Для лучшего понимания такой пример. Пусть мы шлем не маркет-запрос, а BuyLimit по цене >= Ask. Это вынудит котировочную часть биржи транслировать тик с неположительным спредом. Чтобы такого не было, происходит ожидание Execution-отработки до состояния, пока спред не станет положительным (или неопределенным, если вся сторона стакана выжрана).

Каждый шаг выжирания сопровождается трансляцияей этого события во вне. В какой последовательности клиент примет пакеты - уже никого не волнует.

 

Разобрался. Если контролировать флаг полученного тика, тогда действительно все встает на свои места. Вот написал новую версию стакана цен (скоро опишу его работу в статье):


Это пока черновик. Зеленым подсвечен банд, по которому прошла последняя сделка. Видно, что зеленым всегда подсвечиваются только лучшие уровни Ask Bid и зеленый цвет не зализает вглубь стакана. 

Делается следующая проверка:

   MqlBookInfo info=m_book.MarketBook[m_index];
   bool is_buy = (m_book.LastTick.flags & TICK_FLAG_BUY) == TICK_FLAG_BUY;
   bool is_sell = (m_book.LastTick.flags & TICK_FLAG_SELL) == TICK_FLAG_SELL;
   if((is_buy || is_sell) && m_book.MarketBook[m_index].price == m_book.LastTick.last)
   {
      BackgroundColor(clrLawnGreen);
   }
   else if(type==BOOK_TYPE_BUY || type==BOOK_TYPE_BUY_MARKET)
      BackgroundColor(clrCornflowerBlue);
   else if(type==BOOK_TYPE_SELL || type==BOOK_TYPE_SELL_MARKET)
      BackgroundColor(clrPink);
   else
      BackgroundColor(clrWhite);

Т.е. стакан цен действительно синхронизирован с потоком тиков.

 
fxsaber:

Для лучшего понимания такой пример. Пусть мы шлем не маркет-запрос, а BuyLimit по цене >= Ask. Это вынудит котировочную часть биржи транслировать тик с неположительным спредом. Чтобы такого не было, происходит ожидание Execution-отработки до состояния, пока спред не станет положительным (или неопределенным, если вся сторона стакана выжрана).

Каждый шаг выжирания сопровождается трансляцияей этого события во вне. В какой последовательности клиент примет пакеты - уже никого не волнует.


Вы хоть думаете над тем, что пишите?

"Это вынудит котировочную часть биржи транслировать тик с неположительным спредом"

Биржу нелься "ВЫНУДИТЬ"!

Для лучшего понимания как отдаёт инфориацию биржа,прочтите вложенный файл

Файлы:
p2gate_ru.zip  733 kb
 
prostotrader:

Вы хоть думаете над тем, что пишите?

Риторический вопрос.
 
fxsaber:

Для лучшего понимания такой пример. Пусть мы шлем не маркет-запрос, а BuyLimit по цене >= Ask. Это вынудит котировочную часть биржи транслировать тик с неположительным спредом. Чтобы такого не было, происходит ожидание Execution-отработки до состояния, пока спред не станет положительным (или неопределенным, если вся сторона стакана выжрана).

Каждый шаг выжирания сопровождается трансляцияей этого события во вне. В какой последовательности клиент примет пакеты - уже никого не волнует.

Почему нельзя слать каждый шаг со скорректированными бид/аск, если очевидно, что предыдущий уровень исчерпан?
 
Andrey Khatimlianskii:
Почему нельзя слать каждый шаг со скорректированными бид/аск, если очевидно, что предыдущий уровень исчерпан?
Для того, чтобы не плодить лишние сущности.
12345
Новый комментарий