@Slava просим ответить. Управлять размерами пакетов нет возможности, поэтому возможности практически нулевые даже здесь.
Интересно, что агенты не хранят глобальные переменные. И это в каком-то смыле логично (ниже приведу пример), но тогда удаленные агенты не должны хранить и файлы.
Пример
Два пользователя купили один и тот же советник в Маркете и решили его оптимизировать в Облаке.
Советник устроен так, что при достижении какого-то условия он записывает на агенте файл, как флаг того, что следующие прогоны надо делать ExpertRemove в OnInit.
Первый пользователь запускает такой советник на оптимизацию. И радуется, что условие "остановки" оптимизации сработало и не нужно платить лишних денег за Облако.
При этом второй раз запустить оптимизацию он не сможет на тех же агентах - файл там хранится.
Но прикольнее даже другое, после первого пользователя второй окажется совсем в обломе - он не сможет даже первую оптимизацию провести этого же советника.
Поэтому хранение глобальных переменных и файлов на удаленных агентах логично держать под запретом. Но на файлы, вроде, такой заперт не распространяется.
И все же, как во время оптимизации на удаленные агенты что-либо отправить? Ну или хотя бы, как через MQL прервать оптимизацию? Сейчас возможности руками это сделать есть, а программно - нет.
Какой-то перекос сейчас в возможностях, даже некоторые конфиденциальные данные владельцев агентов Облака доступны, а логичная возможность передать на них хоть что-то - нет.
ЗЫ Пример советника для Маркета, который не будет оптимизироваться из-за названных выше причин
С облачной оптимизацией дело обстоит несколько по-другому, чем с локальной оптимизацией.
Облаку дают пачку заданий. Большую пачку. И эта пачка сразу же расходится по агентам. Практика показывает, что на облачных серверах очереди заданий не образуется, так как свободных агентов гораздо больше.
Поэтому запись какого-либо признака в файл бессмысленна.
Другое дело, что эксперт мог бы завершать оптимизацию по получению этого признака из фрейма в OnTesterPass. Что-то типа функции OptimizationStop. Тогда все задания будут застоплены сервером. Всех денег не сэкономите, но если расчёты серьёзные, то экономия может оказаться серьёзной.
Все зависит от количества прогонов для оптимизации. Чем больше - тем выше вероятность нарваться повторно на одного и того же Облачного агента. Ну а там с примером выше выйдет нехорошесть (особенно, если писать в Common-папку). По-моему, такие выкрутасы с файлами нужно запрещать.
Но это все частности большого вопроса о передаче данных на агентов. Если правильно понял, то почти бессмысленно что-то передавать из-за озвученных практических особенностей Облака.
Хорошо бы еще иметь OptimizationRestart() с возможностью поменять диапазон входных.
Из самого клаудного агента ничего важного про материнский терминал(если он есть) узнать нельзя, так как агент самодостаточен(все данные получает исключительно в присылаемой задаче, терминал не нужен) и вообще работает в ограниченном клаудном режиме.
Еще один вариант топорной фантазии передачи данных
Маркет-советник собирает все данные своего пользователя в файл.
При оптимизации отправляет его на клауд в качестве tester_file. Не в курсе, tester_file вшивается ли на этапе компиляции в EX5 или нет. Но даже если вшивается, то есть возможность передачи любой инфы по 8 байт в каждой (s)input переменной через ParameterSetRange.
Прилетая на облачный агент пакет заданий с нужной инфой проверяет агент на свой/чужой. Если свой - пишем в песочницу агента, считывая сторонней программой все ее изменения. А даже если не пишем, то можно посмотреть в логи Облачного агента, увидев значения входных параметров, содержащих охраняемую инфу.
Еще один вариант топорной фантазии передачи данных
Маркет-советник собирает все данные своего пользователя в файл.
При оптимизации отправляет его на клауд в качестве tester_file. Не в курсе, tester_file вшивается ли на этапе компиляции в EX5 или нет. Но даже если вшивается, то есть возможность передачи любой инфы по 8 байт в каждой (s)input переменной через ParameterSetRange.
Прилетая на облачный агент пакет заданий с нужной инфой проверяет агент на свой/чужой. Если свой - пишем в песочницу агента, считывая сторонней программой все ее изменения. А даже если не пишем, то можно посмотреть в логи Облачного агента, увидев значения входных параметров, содержащих охраняемую инфу.
Годный способ?
Нет конечно.
Еще раз повторю - агент в клауде полностью самостоятелен и отделен от терминала. Ему вообще не нужен терминал. Все данные для расчета он получает исключительно из потока данных конкретной задачи и ничего не знает о локальном окружении.
Все данные клаудного агента постоянно зачищаются сразу после отработки задания. И даже логи старее трех суток зачищаются автоматически.
Запросы TERMINAL_xxx параметров в тестере всегда фейковые/предопределенные, так что даже в локальном исполнении нельзя получить ни имени терминала, ни имени пользователя.
Запросы TERMINAL_xxx параметров в тестере всегда фейковые/предопределенные, так что даже в локальном исполнении нельзя получить ни имени терминала, ни имени пользователя.
Ну как это нельзя получить, если я получаю через код по ссылке выше?!
А описанный в пред. посте способ передачи рабочий же. Могу пояснить, если какой-то пункт не выглядит убедительным.
предопределенные значения в полях, забитые жестко в агентах тестирования (никаких данных аккаунтов и тд)
технические характеристики (билд, доступная память, процессор и тд), не являющиеся конфиденциальными
защищенные фейковыми данными TERMINAL_COMPANY и TERMINAL_NAME
локальный запуск агента, а не клаудный, где данные путей TERMINAL_DATA_PATH и TERMINAL_COMMONDATA_PATH одинаковы и указывают в локальную постоянно очищаемую папку агента
Из всех данных единственное чуть минимально указывающее на привязку, от какого брокера поставлен терминал, является путь. Но это никак не конфиденциальные данные.\
Тем более, что у подавляющего большинства клаудных агентов путь будет C:\Program Files\MetaTrader 5 Strategy Tester, так как агентов обычно ставят с помощью независимого инсталлера.
То есть, клаудный агент вообще никак не имеет никаких конфиденциальных данных. Так что сравнивать и передавать нечего.
предопределенные значения в полях, забитые жестко в агентах тестирования (никаких данных аккаунтов и тд)
технические характеристики (билд, доступная память, процессор и тд), не являющиеся конфиденциальными
защищенные фейковыми данными TERMINAL_COMPANY и TERMINAL_NAME
локальный запуск агента, а не клаудный, где данные путей TERMINAL_DATA_PATH и TERMINAL_COMMONDATA_PATH одинаковы и указывают в локальную постоянно очищаемую папку агента
Из всех данных единственное чуть минимально указывающее на привязку, от какого брокера поставлен терминал, является путь. Но это никак не конфиденциальные данные.\
Тем более, что у подавляющего большинства клаудных агентов путь будет C:\Program Files\MetaTrader 5 Strategy Tester, так как агентов обычно ставят с помощью независимого инсталлера.
То есть, клаудный агент вообще никак не имеет никаких конфиденциальных данных. Так что сравнивать и передавать нечего.
Еще раз. Демонстрировал только локальные агенты, а не облачные. И со всеми доводами согласен. Этот же способ совсем о другом
Еще один вариант топорной фантазии передачи данных
Маркет-советник собирает все данные своего пользователя в файл.
При оптимизации отправляет его на клауд в качестве tester_file. Не в курсе, tester_file вшивается ли на этапе компиляции в EX5 или нет. Но даже если вшивается, то есть возможность передачи любой инфы по 8 байт в каждой (s)input переменной через ParameterSetRange.
Прилетая на облачный агент пакет заданий с нужной инфой проверяет агент на свой/чужой. Если свой - пишем в песочницу агента, считывая сторонней программой все ее изменения. А даже если не пишем, то можно посмотреть в логи Облачного агента, увидев значения входных параметров, содержащих охраняемую инфу.
Годный способ?
И он передает данные в Облако в значениях input-переменных во время оптимизации юзером Маркет-советника. И эти данные можно увидеть злоумышленнику, если заглянуть в лог подключенного в Облако им агента, если на него придет соответствующий пакет заданий.
Еще раз. Демонстрировал только локальные агенты, а не облачные. И со всеми доводами согласен. Этот же способ совсем о другом
А речь идет об облачных агентах, где исходно объем публикуемой информации меньше, чем в локальных.
И он передает данные в Облако в значениях input-переменных во время оптимизации юзером Маркет-советника. И эти данные можно увидеть злоумышленнику, если заглянуть в лог подключенного в Облако им агента, если на него придет соответствующий пакет заданий.
Даже если что-то закодировать в input переменные, то эти значения никогда не попадут не только в логи клаудных агентов, но и локальных.
Во первых, объем вывода в логи клаудных агентов урезан донельзя, чтобы не раскрывать данных. Во вторых, режим оптимизации(а в клауде запускается только оптимизация) полностью отключает логгирование даже в локальных агентах.
В общем, вы делаете умозрительные заключения, не имея в руках фактических данных по работе клаудных агентов и их логов.
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
В облаке /common папка равна локальной папке /files конкретного тестерного агента(даже не терминала!), которая к тому же обязательно вычищается.
Да, с локальными 100% все вытягивается, с Облаком - смело обобщил. Вариант такой нарисовал
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Глобальные переменные терминала в тестере работают?
fxsaber, 2017.06.13 11:13
@Slava просим ответить. Управлять размерами пакетов нет возможности, поэтому возможности практически нулевые даже здесь.
Интересно, что агенты не хранят глобальные переменные. И это в каком-то смыле логично (ниже приведу пример), но тогда удаленные агенты не должны хранить и файлы.
Пример
Поэтому хранение глобальных переменных и файлов на удаленных агентах логично держать под запретом. Но на файлы, вроде, такой заперт не распространяется.
И все же, как во время оптимизации на удаленные агенты что-либо отправить? Ну или хотя бы, как через MQL прервать оптимизацию? Сейчас возможности руками это сделать есть, а программно - нет.
Какой-то перекос сейчас в возможностях, даже некоторые конфиденциальные данные владельцев агентов Облака доступны, а логичная возможность передать на них хоть что-то - нет.
ЗЫ Пример советника для Маркета, который не будет оптимизироваться из-за названных выше причин
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Глобальные переменные терминала в тестере работают?
Slava, 2017.06.14 08:07
С облачной оптимизацией дело обстоит несколько по-другому, чем с локальной оптимизацией.
Облаку дают пачку заданий. Большую пачку. И эта пачка сразу же расходится по агентам. Практика показывает, что на облачных серверах очереди заданий не образуется, так как свободных агентов гораздо больше.
Поэтому запись какого-либо признака в файл бессмысленна.
Другое дело, что эксперт мог бы завершать оптимизацию по получению этого признака из фрейма в OnTesterPass. Что-то типа функции OptimizationStop. Тогда все задания будут застоплены сервером. Всех денег не сэкономите, но если расчёты серьёзные, то экономия может оказаться серьёзной.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Глобальные переменные терминала в тестере работают?
fxsaber, 2017.06.14 08:16
Все зависит от количества прогонов для оптимизации. Чем больше - тем выше вероятность нарваться повторно на одного и того же Облачного агента. Ну а там с примером выше выйдет нехорошесть (особенно, если писать в Common-папку). По-моему, такие выкрутасы с файлами нужно запрещать.
Но это все частности большого вопроса о передаче данных на агентов. Если правильно понял, то почти бессмысленно что-то передавать из-за озвученных практических особенностей Облака.
Хорошо бы еще иметь OptimizationRestart() с возможностью поменять диапазон входных.Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Глобальные переменные терминала в тестере работают?
fxsaber, 2017.06.14 10:37
Какой-то механизм чистки присутствует и сейчас, но не понял его логики.
Помимо песочницы есть еще COMMON-папка. Как с Облачными - не знаю, но с локальных точно вытягиваются все файлы через фреймы.
Я же указал:
В облаке /common папка равна локальной папке /files конкретного тестерного агента(даже не терминала!), которая к тому же обязательно вычищается
Ничего вы там не найдете.
Из самого клаудного агента ничего важного про материнский терминал(если он есть) узнать нельзя, так как агент самодостаточен(все данные получает исключительно в присылаемой задаче, терминал не нужен) и вообще работает в ограниченном клаудном режиме.
Еще один вариант топорной фантазии передачи данных
Еще один вариант топорной фантазии передачи данных
Нет конечно.
Еще раз повторю - агент в клауде полностью самостоятелен и отделен от терминала. Ему вообще не нужен терминал. Все данные для расчета он получает исключительно из потока данных конкретной задачи и ничего не знает о локальном окружении.
Все данные клаудного агента постоянно зачищаются сразу после отработки задания. И даже логи старее трех суток зачищаются автоматически.
Запросы TERMINAL_xxx параметров в тестере всегда фейковые/предопределенные, так что даже в локальном исполнении нельзя получить ни имени терминала, ни имени пользователя.
Запросы TERMINAL_xxx параметров в тестере всегда фейковые/предопределенные, так что даже в локальном исполнении нельзя получить ни имени терминала, ни имени пользователя.
Ну как это нельзя получить, если я получаю через код по ссылке выше?!
А описанный в пред. посте способ передачи рабочий же. Могу пояснить, если какой-то пункт не выглядит убедительным.
Ну как это нельзя получить, если я получаю через код по ссылке выше?!
А описанный в пред. посте способ передачи рабочий же. Могу пояснить, если какой-то пункт не выглядит убедительным.
Продемонстрируйте, что именно вы получаете в виде вывода в лог.
И как оно согласуется с указанием на предопределенность/фейковость результатов.
Продемонстрируйте, что именно вы получаете в виде вывода в лог.
И как оно согласуется с указанием на предопределенность/фейковость результатов.
Код по ссылке выше удален явно не мной...
Вот результат его работы
Выделил содержимое Common-папки локального агента и имя юзера в винде. Ну и понятно, какого брокера использовал.
Правда, это к способу передачи, что описал ранее, реально конфиденциальных данных почти не имеет отношения.
Вы продемонстрировали:
Из всех данных единственное чуть минимально указывающее на привязку, от какого брокера поставлен терминал, является путь. Но это никак не конфиденциальные данные.\
Тем более, что у подавляющего большинства клаудных агентов путь будет C:\Program Files\MetaTrader 5 Strategy Tester, так как агентов обычно ставят с помощью независимого инсталлера.
То есть, клаудный агент вообще никак не имеет никаких конфиденциальных данных. Так что сравнивать и передавать нечего.
Вы продемонстрировали:
Из всех данных единственное чуть минимально указывающее на привязку, от какого брокера поставлен терминал, является путь. Но это никак не конфиденциальные данные.\
Тем более, что у подавляющего большинства клаудных агентов путь будет C:\Program Files\MetaTrader 5 Strategy Tester, так как агентов обычно ставят с помощью независимого инсталлера.
То есть, клаудный агент вообще никак не имеет никаких конфиденциальных данных. Так что сравнивать и передавать нечего.
Еще раз. Демонстрировал только локальные агенты, а не облачные. И со всеми доводами согласен. Этот же способ совсем о другом
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Может ли советник без DLL функций отправить куда-нибудь данные?
fxsaber, 2017.06.19 14:11
Еще один вариант топорной фантазии передачи данных
И он передает данные в Облако в значениях input-переменных во время оптимизации юзером Маркет-советника. И эти данные можно увидеть злоумышленнику, если заглянуть в лог подключенного в Облако им агента, если на него придет соответствующий пакет заданий.
Еще раз. Демонстрировал только локальные агенты, а не облачные. И со всеми доводами согласен. Этот же способ совсем о другом
А речь идет об облачных агентах, где исходно объем публикуемой информации меньше, чем в локальных.
И он передает данные в Облако в значениях input-переменных во время оптимизации юзером Маркет-советника. И эти данные можно увидеть злоумышленнику, если заглянуть в лог подключенного в Облако им агента, если на него придет соответствующий пакет заданий.
Даже если что-то закодировать в input переменные, то эти значения никогда не попадут не только в логи клаудных агентов, но и локальных.
Во первых, объем вывода в логи клаудных агентов урезан донельзя, чтобы не раскрывать данных. Во вторых, режим оптимизации(а в клауде запускается только оптимизация) полностью отключает логгирование даже в локальных агентах.
В общем, вы делаете умозрительные заключения, не имея в руках фактических данных по работе клаудных агентов и их логов.