Болтовня о тестере стратегий МТ5 - страница 9
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Извините, что это? Оверпрайс?
Я работаю с специализированным хостингом, который может разместить VPS где удобно для клиента, NY4, LD4, поэтому дорого, но зато быстро (пинг 0-1мс).
Оверпрайс - излишне высокая цена.
Поиграйтесь с визуализатор нашего VPS: там вообще сеть по всему миру и точные тайминги с учетом топологии серверов всех MetaTrader брокеров
Стоит 10 долларов и доступны все физические ядра. Важное уточнение, что мы показываем чистое время в серверном протоколе, а не сетевой пинг, который практически всегда ниже фактического.
Вы говорите о чтении истории из одной зоны - из одной папки для группы терминалом , история она не меняется , это как раз решается без проблем. Про настраиваемый мапинг давно известно.
Это не то , вы одним терминалом прогрузили историю а потом к ней ссылаетесь из других - эка невидаль... это как раз не проблема
Вы зачем на попятную пошли? :)))
Или не внимательно читали? Лишь бы поспорить и при этом не ставить на спор деньги? Юрий, Вы как пацан малолетний, чеслово.
Вот видите, Юрий, решения есть! А ведь всё это можно было получить из "коробки" в МТ!
Просто идеология такая у МТ, он не подразумевает наличия нескольких копий запущенных терминалов, поэтому и не ставится задача доступа к единой базе данных.
Вы запишите 100 тиков от 100 терминалов в один файл... в один момент времени. и так что бы не нарушить ничего.
Делал как-то вот такую штуку: https://www.mql5.com/ru/articles/1316#c4_1
Понятно что без БД, единственный способ адекватного обмена между терминалами без dll, это блокировка одного файла и конкурирование за доступ к нему вроде вот такой жести:
Есть умельцы организовывающие синхронизацию торгового окружения через WebRequest и промежуточный сервер (смотрим копировщики сделок в Маркете).
Понятно, что все это медленно и протирает дырки на винтах пользователей, но что поделать если БД нам так и не дали (и не дадут).
Это все как раз понятно!
Мы о штатном терминале - который собирает тики в одну точку... и если 100 терминалов начнет писать в один файл один и тот же тик ! что получится ?
а читать общую историю уже не изменяемую из мапированного ресурса ( папки ) - это реально не проблема. ( причем эту историю формировать из одного терминала а не из 100 и сразу )
Андрей а может вы путаете чтение с общего HISTOR - и запись в файл ?
Оверпрайс - излишне высокая цена.
Поиграйтесь с визуализатор нашего VPS: там вообще сеть по всему миру и точные тайминги с учетом топологии серверов всех MetaTrader брокеров
Стоит 10 долларов и доступны все физические ядра. Важное уточнение, что мы показываем чистое время в серверном протоколе, а не сетевой пинг, который практически всегда ниже фактического.
Ваш хостинг - замечательное специфичное решение, когда нужно настроить советник, отправить его на хостинг и забыть. Лучшее решение для таких задач.
Но оно, к сожалению, не подходит, когда нужен доступ нескольких терминалов друг к другу. Отчасти это от того, что в терминале МТ нет возможности подключения к нескольким счетам одновременно. Есть и другие задачи, не совместимые с Вашим VPS.
Кстати, Вашим визуализатором VPS активно пользуюсь, классная штука.
Вы зачем на попятную пошли? :)))
Или не внимательно читали? Лишь бы поспорить и при этом не ставить на спор деньги? Юрий, Вы как пацан малолетний, чеслово.
вы давайте вменяемый ответ!
КАК ВЫ ЗАПИШИТЕ В БАЗУ ТИК от инструмента ! который должен хранится в базе ОДНОЙ записью с одним ID
при это у вас 100 терминалов делают INSERT ...
Вы запишите 100 тиков от 100 терминалов в один файл... в один момент времени. и так что бы не нарушить ничего.
Это все как раз понятно!
Мы о штатном терминале - который собирает тики в одну точку... и если 100 терминалов начнет писать в один файл один и тот же тик ! что получится ?
а читать общую историю уже не изменяемую из мапированного ресурса ( папки ) - это реально не проблема. ( причем эту историю формировать из одного терминала а не из 100 и сразу )
Андрей а может вы путаете чтение с общего HISTOR - и запись в файл ?
вы давайте вменяемый ответ!
КАК ВЫ ЗАПИШИТЕ В БАЗУ ТИК от инструмента ! который должен хранится в базе ОДНОЙ записью с одним ID
при это у вас 100 терминалов делают INSERT ...
Вы же не хотите спорить! Скакого перепугу я должен разжёвывать бесконечно одно и тоже и при том бесплатно?!
Напоминаю и предупреждаю - Вы занимаете неверную и вредную позицию для развития МТ.
Давайте не будем дурака включать, ладно? Это не к лицу бородатым но уже лысым дядькам. Я четко выразился - создается общая папка с историческими данными и терминалы отлично работают с ней по ссылке, никаких проблем с доступом нет. Это реально экономит дисковое пространство, которое очень ограничено.
у вас 100 терминалов одновременно пишут в историю ?
--
Вы пожалуйста сами дурака не включайте - просто ответ хочется
давайте вменяемый ответ! КАК ВЫ ЗАПИШИТЕ В БАЗУ ДАННЫХ ТИК от инструмента - который должен хранится в базе в виде ОДНОЙ записи и с одним ID
при это у вас 100 терминалов одновременно делают INSERT в одну и ту же таблицу по этому инструменту ...
p.s.
у меня решение есть - ваше интересует
у вас 100 терминалов одновременно пишут в историю ?
--
Вы пожалуйста сами дурака не включайте - просто ответ хочется
давайте вменяемый ответ! КАК ВЫ ЗАПИШИТЕ В БАЗУ ДАННЫХ ТИК от инструмента - который должен хранится в базе в виде ОДНОЙ записи и с одним ID
при это у вас 100 терминалов одновременно делают INSERT в одну и ту же таблицу ...
Отвечу за Андрея. Если мы работаем через файлы, то ни о каком одновременном INSERT речи не идет. INSERT сделает только тот поток, который получит доступ к файлу самым первым. Остальные получат INVALID_HANDLE и не смогут сделать запись. Поток получивший хендл сможет сделать проверку: существует ли уже его запись в файле или нет (предположим, что мы знаем как определяется уникальность каждой записи). Далее дело техники: если записи нет - записываем, если запись уже кем-то сделана, закрываем хендл.
Другой вопрос что делать сразу 100 писателей и 100 читателей как минимум не рационально и чревато потенциальными проблемами. Писатель если это возможно, должен быть один. Выяснить, кого назначить писателем из 100 потоков тоже вполне можно.
p.s. Насчет конкурентного доступа к СУБД ни один десяток страниц исписан, поэтому эту тему затрагивать не будем. Тем более раз в MQL нет БД то и предмета обсуждения тоже нет.
Отвечу за Андрея. Если мы работаем через файлы, то ни о каком одновременном INSERT речи не идет. INSERT сделает только тот поток, который получит доступ к файлу самым первым. Остальные получат INVALID_HANDLE и не смогут сделать запись. Поток получивший хендл сможет сделать проверку: существует ли уже его запись в файле или нет (предположим, что мы знаем как определяется уникальность каждой записи). Далее дело техники: если записи нет - записываем, если запись уже кем-то сделана, закрываем хендл.
Другой вопрос что делать сразу 100 писателей и 100 читателей как минимум не рационально и чревато потенциальными проблемами. Писатель если это возможно, должен быть один. Выяснить, кого назначить писателем из 100 потоков тоже вполне можно.
вот я об этом! и об этом
Василий, то что конкурировать за файл из 100 терминалов возможно , это понятно.
то что можно из одного терминала гонять сделки в другой копировальщиком - это иная фишка
Вопрос о том - что сам терминал ( если МТ4 ) то он пишет тики в файл ticks.raw ...
а если в файл {ТЕРМИНА}\history\{броке}\tiscks.raw будет пытаться писать сразу 100 терминалов - произойдет косяк
вот мне кажется - именно это Андрей и не понимает
Слышу снова , как натужно скрипит теоретический диван под Андреем.
p.s.
Андрей , Вы ушли за смазкой для дивана ?