Конец пакета. - страница 2

Новый комментарий
 
pronych:
Это вы о чем?
Да, нифига непонятно в чем вопрос. Более конкретно. Идея как-то смутно улавливается, но конкретика не просматривается...
 
TheXpert:
Вот что бывает когда излишне самоуверенный товарищ не понимает чего же он таки хочет.

Если это в мою сторону, то могу вернуть тезис 

Если не удается понять каких-то вещей, не стоит самоуверенно обвинять других в недалёкости. Не надо считать себя умней других, это не красит.  От тебя Андрей, этого не ожидал, буду иметь ввиду.  

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

Как ни крути, за примерами постоянно приходится обращаться к стороннему апи. В  котором я использую такие прекрасные события (из справки):

evhEndFrame
public event TableDataEventHandler evhEndFrame;
Генерируется после приема пакета обновлений таблицы.
 
evhUpdateAllTableViews  
public event TableListEventHandler evhUpdateAllTableViews;
Генерируется при необходимости обновления отображения данных таблиц.

 Надеюсь никто спорить не будет, что для обмена данными используется не только низкоуровневый протокол TCP/IP, но и некий собственный протокол, специализированный для обмена конкретно MT5<=>ServerMT5

Как он работает, естественно я не знаю, но смею предположить что передача информации идет порциями. т.е. дискретно, с каким-то заданным интервалом времени отправляется пакет с новыми данными, стаканами, и другими  значениями  параметров, но только теми, которые изменились с прошлой отправки.  поток выглядит скажем так  -||-||||-|-|||-||||||-|||- в каждом пакете только обновленные данные, размер разный. Логично?  

В такой порции наверняка может содержаться не один стакан, а столько, сколько их изменилось(и так сделано в упомянутом апи).  

evhEndFrame генерится после размещения  каждой, вновь принятой таблицы  во внутренней структуре данных, практически это аналог OnBookEvent() и далее  действия похожи. в этом событии я считываю стакан в собственную структуру, более удобную для работы.

evhUpdateAllTableViews генерится уже по размещению всех таблиц, которые были переданы в последней порции. И пусть вас не путает присутствие Views в названии, использовать можно как надобно. Тут уже идет расчет необходимых кросс-значений со всех стаканов,  обновленных сейчас и  обновленных ранее. Именно этот момент я хочу отловить. Не обязательно событиями.

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

 -||-||||-|-|||-||||||-|||-

принято 19 стаканов и на каждый произойдет  BookEvent, а  полных пересчета сделать надо всего 6, в паузах! Сейчас приходится на каждом  BookEvent'е это делать 19 раз.

Нет, конечно я могу ошибаться, и протокол может работать по другому. Но хотелось бы об этом  знать. 

 
pronych:
Постучите в СД за уточнением. Я думал, что просто есть несколько потоков, в каждом очередь событий. Но в тему не углублялся.
 
Silent:
Постучите в СД за уточнением. Я думал, что просто есть несколько потоков, в каждом очередь событий. Но в тему не углублялся.

Да Ренат читает же форум. Надеюсь увидит, ответит.

Получается надо знать очередь событий для каждого советника/индикатора. При чем те, которые были получены с сервера. Лично меня интересуют только стаканы))

В лубом случае, интересно знать как в терминал поступает информация. 

 
pronych:

Если не удается понять каких-то вещей, не стоит самоуверенно обвинять других в недалёкости. Не надо считать себя умней других, это не красит.  От тебя Андрей, этого не ожидал, буду иметь ввиду. 

Та моя цитата это сарказм, еще и в контексте ) ну да ладно. Чуть позже отвечу.
 
TheXpert:
Та моя цитата это сарказм, еще и в контексте ) ну да ладно. Чуть позже отвечу.
Ок.
 
pronych:
Ок.
TheXpert - тоже Андрей? Да, то что в 1 и здесь это то понятно. Но в еще большей конкретике. когда на каждый стакан генерируется событие - мы имеем дело с 1 стаканом, а в твоем случае нужен доступ к истории стаканов. Т.е. одно событие и массив стаканов. Один хрен их всех обрабатывать по очереди, копируя в промежуточные стаканы. Не понятно, что это ускорит..
 
pronych:

 Например, необходимо рассчитать в индикаторе некую величину по пятнадцати стаканам.  

В последнем пакете, на текущем временном срезе  пришло 5 обновлений из 15 используемых стаканов. То есть  5 событий.

Как экономно и в то же время без задержек построить алгоритм, чтоб обработать эти пять событий, и только потом уже рассчитать ту самую величину по всем пятнадцати стаканам?


1. как вы отмечаете первый из 15 стаканов?

2. что для вас есть обновление стакана?

 

По поводу пакетов. Это такой низкий уровень, что выпрашивать его настройку на уровне пользователя нет вообще никакого смысла. А скорее всего и возможности.

Да и смысла нет, потому что кроме этого надо будет еще список инструментов в пакете или список событий. Это точно никто предоставлять не будет.

Остальное все решается асинхронной обработкой в едином модуле в отдельном потоке.

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

Исходя из опыта работы с сообщениями МТ, без длл нормально сделать не получится.

 
sergeev:

1. как вы отмечаете первый из 15 стаканов?

2. что для вас есть обновление стакана?

я не отмечаю, я по условию задачи использую 15 стаканов. скажем так, все их свожу в один, пусть это будет 'тяжелая' функция, и занимает 5ms.

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

один хрен их все копировать в свою собственную структуру (в промежуточные стаканы, для удобства) в событии BookEvent(),  но это занимает меньше 1ms на каждый. 

а "тяжелую" функцию сведения хотелось бы выполнить один раз на 100ms, уже после всех  BookEvent'ов. Этот момент нам не известен, так как мы не знаем какой именно   BookEvent из принятых в последнем пакете отрабатывает в данный момент. может первый, а их еще десяток впереди, тогда надо подождать последнего события.

Тут даже не во времени выполнения дело, а в том, что на первом событии мы можем одно решение принять(например отправить ордер), а на последнем стакане окажется, что не по той цене. И всё это за единицы миллисекунд.

TheXpert:

По поводу пакетов. Это такой низкий уровень, что выпрашивать его настройку на уровне пользователя нет вообще никакого смысла. А скорее всего и возможности.

MQL5 и так очень низкоуровневый. Достаточно было бы доступа к обратному счетчику событий последнего пакета, например. 

Скорость работы напрямую зависит от возможностей базового апи. Получается, что "там" я могу это сделать, а на мт5 - нет.

Некоторое время я зависал на 'том' форуме и там просил некоторые вещи, которые есть в MQL5. Например асинхронные ордера. Как думаете что мне сказали? Правильно - послали! ))

Теперь пришел сюда, и оказывается что там-то многие вещи реализованы, а тут их и просить особого смысла не имеет. Вот так-то...

 ВСЕ ЦИФРЫ УСЛОВНЫ.  

1234
Новый комментарий
Причина обращения: