MQL: безопасность vs возможностей - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Глупости все это. Не гигабайты же круглосуточно гоняете.
Операционка с системными процессами на порядки больше с диском работают.
Был вопрос
komposter:
... или какая-то прога есть для проверки?
...и, насколтко мне известно, дело не в размере, а в расположении файла.
Если постоянно перезаписываемый файл находится всеггда в одном месте (там можно своп виндовский зафиксировать) - винт физически начнет сыпаться именно с этого места.
(Еженедельная дефрагментация по расписанию разруливает.).
В общем, это не совсем глупость.
Глупости все это. Не гигабайты же круглосуточно гоняете.
Операционка с системными процессами на порядки больше с диском работают.
Ренат приветствую. хотел бы уточнить вопрос про понятие файловой песочницы МТ и какую роль ей отвели.
Файловая песочница - это разрешение для эксперта что то записать или прочитать только в ограниченном месте.
Делается это однозначно с целью безопасности данных компьютера.
То есть мы ограничиваем возможности эксперта песочницей, чтоб трояны не могли сделать FileOpen каких то приватных данных клиента вне её.
Иначе, чтоб такое можно было бы им сделать - нужно явное разрешение DLL для эксперта.
ок.
А если дать возможность эксперту писать не на диск, а хотя бы в файлы в памяти?
Теряется ли при этом безопасность пользователя / МК?
А если дать возможность эксперту писать не на диск, а хотя бы в файлы в памяти?
Теряется ли при этом безопасность пользователя / МК?
А зачем это нужно?
Мы дали файлы, пайпы и глобальные переменные, все эксперты на одном терминале могут нормально и без проблем общаться друг с другом. А вот задача "общаться с кем-то наружу в свободном режиме" перед нами не стоит. Наоборот перед нами стоит задача - ни в коем случае не дать выйти информации наружу.
ps: искать обходные пути метода общения терминалов друг с другом не стоит - мы этого не сделаем.
ок. спасибо.
и еще вопросы:
1. можете ли поставить в планы разработки - передачу информации от эксперта в локальные агенты во время теста?
2. просертифицируется ли приложение для маркета, которое использует пайпы?
1. можете ли поставить в планы разработки - передачу информации от эксперта в локальные агенты во время теста?
Для начала обоснуйте, пожалуйста, необходимость такого рода вмешательства.
По нашим соображениям передача какой-то дополнительной информации тестируемому эксперту помимо той информации, которую обеспечивает тестер (набор параметров и файлы данных, да и пользовательские индикаторы мы теперь предоставляем по запросу) - это методологически неверно.
Кстати, локальные агенты имеют доступ к общей папке всех клиентских терминалов на данном компьютере.
Для начала обоснуйте, пожалуйста, необходимость такого рода вмешательства.
По нашим соображениям передача какой-то дополнительной информации тестируемому эксперту помимо той информации, которую обеспечивает тестер (набор параметров и файлы данных, да и пользовательские индикаторы мы теперь предоставляем по запросу) - это методологически неверно.
как пример - свои ГА
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
dll и маркет.
joo, 2013.04.18 21:51
Всё верно глаголите. <...> и про то что 100 раз обговаривалось - передача инфы на агенты и "узость на местах" в количестве оптимизируемых параметров.
<...>1. Ограничение на количество оптимизируемых параметров.
2. Монокритериальность оптимизации (пардон за новословообразование)
3. Невозможность управлять процессом песочной эвалюциии.
Это не укор разрабам, отнюдь. Наоборот - это поле для полёта мысли разработчиков программ на MQL5!
<...> если появятся возможности двусторонней передачи - проблемы решены. Не нужно будет тройку вышеназванных пунктов воплащать в жизнь - всё взрастёт само собой.
Кстати, локальные агенты имеют доступ к общей папке всех клиентских терминалов на данном компьютере.
Для информации - наши клауд серверы MQL5 Cloud Network в сутки штатно генерят около 5 террабайт трафика, иногда бывало и 10 Tb.
Если в эту сеть пустить неограниченный кастомный трафик с гарантией доставания каждого агента, то сеть себя будет чувствовать не очень хорошо.
1. Смею предположить, что трафик на 99.9% сейчас состоит из исторических данных.
2. Адресное обращение к каждому агенту вовсе не требуется. Ниже покажу как.
...
Мы дали файлы, пайпы и глобальные переменные, все эксперты на одном терминале могут нормально и без проблем общаться друг с другом. А вот задача "общаться с кем-то наружу в свободном режиме" перед нами не стоит. Наоборот перед нами стоит задача - ни в коем случае не дать выйти информации наружу.
ps: искать обходные пути метода общения терминалов друг с другом не стоит - мы этого не сделаем.
Не знаю кому как, а я предельно четко показал ранее, что необходим двусторонний обмен информацией между программами на чарте и агентах. Наружу не нужно. То есть в рамках только одного терминала (и управляемых им агентов). Никакие другие запущенные копии терминалов (с разными целями) не участвуют в обмене информацией.
stringo:
По нашим соображениям передача какой-то дополнительной информации тестируемому эксперту помимо той информации, которую обеспечивает тестер (набор параметров и файлы данных, да и пользовательские индикаторы мы теперь предоставляем по запросу) - это методологически неверно.
Кстати, локальные агенты имеют доступ к общей папке всех клиентских терминалов на данном компьютере.Именно по запросу. То есть не адресное обращение к агенту с передачей ему информации, а сам агент возьмет пакет адресованный только ему (и соответственно уже просто отправить данный пакет тестером в облако).
То есть нужно что то типа такого:
где expert_opt_param - стандартное свойство программ типа советник.
Если CustomData оказывается неинициализированным, то пас пропускается.
Соответственно что бы агент смог получить адресованный ему и только ему пакет данных, он должен быть предварительно создан экспертом на чарте, как то так:
где bool OptDataSend() - стандартная функция языка
double CustomData - пользовательские данные
int AgentId - ид агента, а попросту - порядковый номер прохода согласно режиму "полный перебор" в оптимизаторе.
И - как же нарушится пострадает в таком случае безопасность? Всё строго и сердито, в рамках песочницы одного терминала.
в рамках одного эксперта решается через CFastFile (в папке MQH\Ctrl погляди).
но как показал тест вывод битмапа на чарт по сравнению с объектами - пустая трата времени. CView рулит :)
Я так предполагаю что тест не очень корректен.
Во первых для создания битмапа не участвовал OpenCL (спорно конечно, для больших объёмов может и будет преимущество для маленьких врядли),
во вторых запись в файл и считывание из файла на порядок медленнее чем обращение к оперативе (а вот тут при частом пересчёте, например 24 раза в секунду самые большие потери, запиши и прочитай файл 24 раза в секунду и замерь время), вот тут как раз и весь проигрыш 1-го битмапа против 26 лабелей.
Поэтому то я и ратую за виртуальные файлы. Это многофункциональное решение. Применимое во многих алгоритмах.
Urain:
Я так предполагаю что тест не очень корректен.
запись в файл и считывание из файла на порядок медленнее
там не было записи в файл. там ResourceCreate.