Обсуждение статьи "Связь с MetaTrader 5 через именованные каналы без применения DLL"
А в тестере пайпы работают?
С какого это перепугу связь между разными терминалами должна работать в тестере?
делайте через события, они в тестере работают.
С какого это перепугу связь между разными терминалами должна работать в тестере?
делайте через события, они в тестере работают.
что через события? связь между терминалами?
;)
Именованные пайпы работают в локальных агентах, но в клаудах отключены.
То есть, как отдельные тесты, так и массовые локальные агенты могут коннектиться к стороннему (не только локальному) пайп серверу.
А почему не? Пробовать надо. Только непонятно зачем.. :)
что через события? связь между терминалами?
;)
Сутью вопроса проникнись, если человеку нужно общение программ в тестере, то просматривается задача передачи данных между программами в одном терминале, а это можно делать через события, опуская всю эту лабуду мой ответ вполне логичен.
Навскидку сразу есть два варианта использования:
- копирование сделок со счета на счет (а также с MetaTrader 5 на MetaTrader 4 или наоборот)
- получение результатов оптимизации на лету с динамической обработкой в другом приложении
И статьи на эту тему будут интересны.
Навскидку сразу есть два варианта использования:
- копирование сделок со счета на счет (а также с MetaTrader 5 на MetaTrader 4 или наоборот)
- получение результатов оптимизации на лету с динамической обработкой в другом приложении
И статьи на эту тему будут интересны.
К сожалению такое возможно только тем, кто умеет программировать на С для Windows, потому что:
Только учтите, что это клиентская поддержка, а серверные коннекты в терминале создавать нельзя.
Т.е. в технологиях клиент-сервер два клиента друг друга никак не увидят без посредства сервера.
Я посмотрел на предмет создания именованных каналов в других языках
программирования, но к сожалению, в большинстве из них, штатными средствами можно создать
клиента для Windows, хотя каналы под Unix почти везде создаются без
проблем.
Нужны шлюзы в виде EXE-шников, которые могли бы соединить полнодуплексно два именованных канала по алгоритму:
- Создаем два именованных канала А и B
- Создаем первый подпроцесс, который слушает канал А на предмет коннекта
- После того, как к каналу А законнектится клиент, который ждет сообщения, создаем второй подпроцесс, который слушает канал B на предмет коннекта.
- Первый подпроцесс включается на передачу байтового потока в цикле из канала А в канал B
- Как только на канал B законектится клиент, второй подпроцесс запускается на чтение байтового потока в цикле из канала B в канал А.
- Второй клиент начинает передачу первого сообщения из канала B в канал А.
- и т.д. и т.п., до тех пор, пока какой нибудь клиент не отвалится, после чего оба канала уничтожаются и переходим к п.п. 1
Конечно
же в однозадачных MQL скриптах полный дуплекс необязателен, т.к.
клиенты не могут принимать и передавать информацию асинхронно. Но
полудуплекс подходит лишь для тех случаев, когда сервер знает протокол
обмена и может запросто вычислить, где заканчивается прием-передача от
одного клиента к другому, чтобы переключиться в противоположный режим.
Если он не знает этого, т.к. не обладает телепатическими способностями, а
это известно только клиентам, обменивающимся между собой по только им
известному протоколу, то необходим полный дуплекс с двумя подпроцессами.
Такой шлюз удобен тем, что у каждого клиента для связи с другим
клиентом прописывается только один канал и последовательность
подключения со стороны клиента не играет никакой роли, если он конечно же будет проверять в начальном цикле возможность коннекта. Алгоритм шлюза исключает возможность подключение клиента, который первым по протоколу должен передать сообщение до того, как законнектится второй клиент и передачи в пустоту не произойдет.
Теоретически, поскольку количество именованных каналов неограниченно, то можно было бы создать однозадачный симплексный шлюз по алгоритму:
- Создается первый именованный канал на передачу от шлюза к клиенту
- После того, как первый клиент осуществил коннект, создаем второй канал на прием сообщений от клиента
- После того, как передающий клиент подсоединился к второму каналу, процесс в цикле передает поток байтов из приемного канала в передающий.
- Как только какой нибудь клиент отвалится, удаляем оба канала и переходим к п. 1
В этом случае понадобится два таких шлюза, чтобы связать двух клиентов по полудуплексу или один, если используется только симплекс. Недостаток по сравнению с полнодуплексным шлюзом в том, что в скриптах на MQL придется прописывать два канала (на прием и передачу) и в них же строго соблюдать последовательность подключения: сначала на прием, а потом на передачу (а иначе второй канал не будет создан никогда). Алгоритм этого шлюза также исключает возможность подключение клиента, который первым по протоколу должен передать сообщение до того, как законнектится второй клиент и передачи в пустоту не произойдет.
Естественно, что в шлюзах нужно предусмотреть возможность настроек имен каналов в зависимости от последовательности приема-передачи и подключения клиентов, например, через командную строку при запуске.
Если бы кто нибудь, программирующий на С, создал такие шлюзы и скомпилировав их в EXE-шники, выложил здесь, то создавать коннекты между скриптами, советниками и индикаторами штатными средствами МQL5, без танцев с бубном на других языках программирования, уже сейчас можно было бы запросто.
Теоретически
также можно написать статью, как правильно объединять клиентов такими
шлюзами, чтобы не создавать сервера на языках отличных от MQL (ведь наверняка не только я не умею программировать на С?) с
конкретными примерами в соавторстве с С-шным программистом. Т.е. с меня текст
статьи и примеры на MQL, а с С-шного программиста исходники шлюзов на С и EXE-шники. Гонорар пополам.
Сервер простой, весь в исходниках, включая скомпилированный exe файл в каталоге /release. Тесты повторить можно легко.
Кстати, в примерах показан полнодуплексный обмен, где никого ждать не надо.
Сервер простой, весь в исходниках, включая скомпилированный exe файл в каталоге /release. Тесты повторить можно легко.
Речь не о том. Пробовал я запустить Ваш пример. Он работает. Но толку от него ноль, т.е. попробовал и все, его уже можно удалить, т.к. он больше не нужен.
С одной стороны избавили от dll, а с другой опять же, для прикладного применения необходимы костыли на других языках программирования.
Недостаток предложенного метода заключается в том, что он подходит лишь для программистов, разрабатывающих приложения на языках отличных от MQL и поддерживающих Windows API. Т.е. предложенный пример не универсален и его нельзя без переделки приспособить под другие задачи. А задачи у всех разные. А это значит, что пользователям придется для создания даже элементарного обмена информацией между двумя скриптами изучать помимо MQL еще какой нибудь язык, дабы на нем, создать сервер, в котором нужно прописать часть логики относящейся к протоколу обмена.
Я же предлагаю, один раз создать шлюзы, скомпилировать и выложить для всех желающих, чтобы любой пользователь мог создавать коннекты, обходясь лишь штатными средствами MQL.
Например, для меня что открытые сырцы на С, что закрытые - без разницы. Потому что я на С ничего не пишу, а для разбора полетов понадобится время. Мне эти самые сырцы даже скомпилировать нечем. А в Pure Java, как и во многих других языках программирования, штатными средствами можно создать только клиентское соединение через файловые потоки. Был бы шлюз, который соединяет два именованных канала хотя бы по симплексу, то проблем бы не было. Прописал бы протокол обмена в клиентах, подключил через пару шлюзов, отладил и все работает. Т.е. не надо проектировать и создавать под каждую задачу отдельный сервер.
А в данный момент, т.е. без шлюзов, многим придется устанавливать среду разработки для С, изучать новый язык программирования и т.д. и т.п.
Шлюзу ведь до лампочки: что у одного клиента получил, то другому и отправил. Логика тупая, но зато позволяет объединить двух клиентов без всяких дополнительных костылей и танцев с бубном, т.е. она универсальна и независима от протокола обмена информацией и знаний языка С.
Тут как говориться, сытый голодного не разумеет. Тот кто на С что-то разрабатывает, проблемы вряд ли видит. А всем остальным, как хочешь, так и разбирайся с этим хозяйством.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Связь с MetaTrader 5 через именованные каналы без применения DLL:
Перед многими разработчиками встает одинаковая проблема - как пробиться в песочницу торгового терминала без применения небезопасных DLL. Одним из простых и безопасных методов является использование стандартных именованных каналов (Named Pipes), которые работают как обычные файловые операции. Они позволяют организовать межпроцессорное клиент-серверное взаимодействие между программами. Посмотрите практические примеры на C++ и MQL5 в виде сервера, клиента, обмен данными между ними и замер производительности.
Перед многими разработчиками встает одинаковая проблема - как пробиться в песочницу торгового терминала без применения небезопасных DLL.
Одним из простых и безопасных методов является использование стандартных именованных каналов (Named Pipes), которые работают как обычные файловые операции. Они позволяют организовать межпроцессорное клиент-серверное взаимодействие между программами. Хотя ранее уже публиковалась статья "Реализация взаимодействия между клиентскими терминалами MetaTrader 5 при помощи именованных каналов (Named Pipes)", которая показывала способ использования через включение доступа к DLL библиотекам, мы воспользуемся стандартными и безопасными возможностями терминала.
Более детально об именованных каналах можно прочесть в библиотеке MSDN, а мы сразу перейдем к практическим примерам на C++ и MQL5. Реализуем сервер, клиента, обмен данными между ними и замерим производительность.
Автор: MetaQuotes