Библиотеки: Event_Message

[Automated-Trading]

Event_Message:

Отправка/получение информации через ChartEvent-события

Автор: fxsaber

[fxsaber]

В боевом советнике задержки нежелательны. Например, использование WebRequest, чтобы отправить алерт себе на сайт, может быть  болезненным, если в этот момент нужно совершать торговые операции.

Поэтому желательно использовать асинхронный WebRequest.

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

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

[Alexandr Gavrilin]

Ознакомился с идеей, может она и имеет смысл, но для передачи таких объемов лучше комбинировать механизм с использованием сообщений и файлов для передачи данных.

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

[fxsaber]

Alexandr Gavrilin:

Ознакомился с идеей, может она и имеет смысл, но для передачи таких объемов лучше комбинировать механизм с использованием сообщений и файлов для передачи данных.

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

Сейчас реализация - одна/две строки.

[Igor Makanu]

есть ли ограничения применения этого кода:

1. по скорости обмена

2. по размеру данных

?

ЗЫ: чисто теоретический вопрос:

насколько реально сохранить небольшой массив структур используя сервер, размер одной структуры около 30 байт (записать данные в магик / комментарий ордера или в магик+комментарий) - путем открытия отложенных ордеров далеко от цены. Цель - миграция между ПК.... давно не было проблем с эл.питанием, а в последнюю неделю несколько раз.

[fxsaber]

Igor Makanu:

есть ли ограничения применения этого кода:

1. по скорости обмена

2. по размеру данных

?

Не исследовал. В примерах поставьте распринтовку.

ЗЫ: чисто теоретический вопрос:

насколько реально сохранить небольшой массив структур используя сервер, размер одной структуры около 30 байт (записать данные в магик / комментарий ордера или в магик+комментарий) - путем открытия отложенных ордеров далеко от цены. Цель - миграция между ПК.... давно не было проблем с эл.питанием, а в последнюю неделю несколько раз.

Никаких проблем записать такие данные на сервер нет. Вот модифицировать их - да.

[Igor Makanu]

fxsaber:

Не исследовал. В примерах поставьте распринтовку.

пока нет необходимости у меня

Спросил, т.к. думал, что Вам известны особенности работы с сообщениями в MQL, в доках нет инфы о размере буфера сообщений, есть ли переполнение и очередь

По моему не надежно будет работать, выполнение MQL в одном потоке, и если еще в OnTick() и в OnTimer() можно предугадать поведение MQL , но если добавить к ним и ChartEvent() в качестве источника данных для принятия решения ЕА, то по моему, сложная конструкция и скорее всего плохо синхронизированный и не управляемый код будет - могу ошибаться, просто не понимаю этот подход как использовать в одном потоке MQL  гарантированно без потери данных

Ну и сам подход к передаче данных отличается от принятых: мьютекс/семафор выставили - записали данные в канал передачи данных, а в предложенном решении получается что в то, что ранее считали каналом данных - глобальные переменные , теперь будем использовать как семафор, а то что использовали как семафор - сообщения чарта, теперь будем использовать как канал данных. Т.е. с ног на голову все перевернули. Целесообразность не понятна, про гарантированную передачу-получение данных, вообще не понятно, да и какую эффективность получили в этом решении тож под вопросом

За реализацию спасибо! самому было интересно что то такое сделать-посмотреть

[fxsaber]

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

Четкий анализ реджектов не допускает каких-либо пауз. Особенно, если идет контроль правильности работы того же Терминала. Там пропуски миллисекунд совсем не в тему. Поэтому быстро отправил инфу на сторону. А дальше пусть другая MQL-программа занимается обработкой этой инфы.

Например, другая прога получила алерт, сделала несколько скринов, собрала их в архив и отправила на сайт. Боевой советник никак в этом не участвует.

ЗЫ Несколько боевых советников отправляют одинаково все на один приемник. Ну и для расширения функционала Маркет-продуктов - самое то.

[Igor Makanu]

fxsaber:

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

наверно для этих целей будет работать, обмен же информацией до сотни байт, и в стороннем ЕА будет организована отправка информации в сеть

но проблема то та же осталась, новый канал данных Вы получили, а сам протокол обмена нет, даже не протокол то нужен, а нужно знать характеристик канала связи  ChartEvent() - где их посмотреть?

и речь тут не об экстремальных нагрузках, а просто об отсутствии информации как реализованы сообщения чарту в MQL: это очередь ? или это буфер для одного сообщения? - что будет с остальными сообщениями если буфер не обработали?

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

Проблема обмена данными между ЕА - это извечная проблема в MQL, разработчики другого видения чем должны заниматься эксперты у пользователя MQL и готовых решений никогда не предлагали, каждый организовывает обмен исходя из своих задач и мощностей ПК

[fxsaber]

Igor Makanu:

как реализованы сообщения чарту в MQL: это очередь ?

Очередь. Мышкой пользуетесь - тот же событийный механизм.

[Igor Makanu]

fxsaber:

Очередь. Мышкой пользуетесь - тот же событийный механизм.

первоисточник нужен, если я заложусь в winforms на такую модель, то могу найти инфу, что думает об этом Майкрософт https://docs.microsoft.com/ru-ru/dotnet/api/system.windows.forms.application.doevents?view=netframework-4.8

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

а в MQL что по докам?

вот:

Все MQL5-программы работают в потоках, отличных от главного потока приложения. Главный поток терминала отвечает за обработку всех системных сообщений Windows, и в результате  этой обработки в свою очередь порождает сообщения Windows для своего же приложения. Например, перемещение мышки на графике (событие WM_MOUSE_MOVE) порождает несколько системных сообщений для последующей отрисовки окна приложения, а также посылает внутренние сообщения экспертам и индикаторам, запущенным на этом графике. При этом может возникнуть ситуация, что главный поток приложения ещё не успел обработать системное сообщение WM_PAINT (и поэтому ещё не отрисовал изменённый график), а эксперт или индикатор уже получили событие о перемещении курсора мышки. Тогда в этом случае свойство графика CHART_FIRST_VISIBLE_BAR будет изменено только после отрисовки графика.

описана некая ситуация, но нет описания самого механизма

поэтому я и спросил в своем первом сообщении - были ли проверки на ограничение такого метода обмена данными, имхо, глобальные переменные терминала - единственный штатный механизм обмена данными между ЕА, тем более Вы уже провели большую работу по сериализации/десериализации данных через гл.переменные терминала используя Ваш TypeToBytes - это точно работает и работает правильно и надежно