Как сделать удаленный доступ к индюку? - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
и не должно наблюдаться.
дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.
Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.
Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!
И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.
Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
в принципе как вариант... это как раз нечто среднее между приемом всех данных за один раз или по немногу но часто.
Главное - чем точнее поставленная задача, тем больше шансов оптимизировать её по скорости.
например для одной линии индикатора 250000 баров*8 байт(время бара) + 8 байт (значение линии) ~ 4 мб инфы.
1. Время нужно не для всех индикаторов.
2. Котировки можно сжимать. Время тоже можно сжимать)))
3. Не обязательно каждый раз передавать все котировки. Есть более экономичный вариант. При инициализации индикатор логинится на сервер и передает большой кусок данных. Сервер возвращает некоторый хэндл, ассоциированный с полученным набором данных и клиентом, который эти данные прислал. Во время работы индикатор периодически отправляет информацию о показателях нулевого бара, чтобы скорректировать текущие показания на нём. Во время закрытия бара индикатор должен послать окончательную информацию о баре на сервер, который вернет значение для закрывшегося бара. При деинициализации/разрыве соединения сервер освобождает выделенный хэндл и уничтожает набор данных (или не освобождает, кому как нравится).
4. Кроме того, индикатор может кешировать на стороне клиента полученные значения индикатора (их можно хранить вместе с блоком сжатых данных, по которым они расчитаны).
UPD: Пересчитывать индикатор вообще можно не на всех тиках, т.к. очень часто тики идут потоком вида +1 -1 +1 -1 +1 -1 - реально нужно вычислить индикатор лишь 2 раза.
1. Время нужно не для всех индикаторов.
Да. но сейчас говорим про общий случай.
2. Котировки можно сжимать. Время тоже можно сжимать)))
Подкиньте идейку
3. Не обязательно каждый раз передавать все котировки. Есть более экономичный вариант. При инициализации индикатор логинится на сервер и передает большой кусок данных. Сервер возвращает некоторый хэндл, ассоциированный с полученным набором данных и клиентом, который эти данные прислал. Во время работы индикатор периодически отправляет информацию о показателях нулевого бара, чтобы скорректировать текущие показания на нём. Во время закрытия бара индикатор должен послать окончательную информацию о баре на сервер, который вернет значение для закрывшегося бара. При деинициализации/разрыве соединения сервер освобождает выделенный хэндл и уничтожает набор данных (или не освобождает, кому как нравится).
вот это немного непонятно как может ускорить передачу данных про линию индюка.
4. Кроме того, индикатор может кешировать на стороне клиента полученные значения индикатора (их можно хранить вместе с блоком сжатых данных, по которым они расчитаны).
по аналогии как это уже и так реализовано в МТ - IndicatorCounted(). Я бы прописал свою аналогичную функцию для таких целей.
UPD: Пересчитывать индикатор вообще можно не на всех тиках, т.к. очень часто тики идут потоком вида +1 -1 +1 -1 +1 -1 - реально нужно вычислить индикатор лишь 2 раза.
Другими словами - для индюков мы сейчас начали решать задачу. какую и так давно решили метаквоты. Синхронизирование и передача баров истории :)
Может надо высказать предложение, чтоб они сделали у себя такой сервис!
а что, интересная мысль. пусть на серваке хранится такой себе инструмент, у которого цена открытия/закрытия/хай/ло равны. И объемы тоже. Он будет загружатся и синхронизироватся по всем общим правилам как и все валюты. И его потом можно будет использовать в качестве линии индюкаторов.
Вот наверно стоит покопать именно в этом направлении в техдокументации синхронизации баров.
1) делаем скриншот графика с индикатором
2) закачиваем файл скриншота на свой HTTP сервер
3) юзера заходят под своими логинами\паролями и смотрят картинку
годится правда только для случая когда на индюк нужно просто смотреть. если там еще самому что достраивать - то... :(
3. Не обязательно каждый раз передавать все котировки. Есть более экономичный вариант. При инициализации индикатор логинится на сервер и передает большой кусок данных. Сервер возвращает некоторый хэндл, ассоциированный с полученным набором данных и клиентом, который эти данные прислал. Во время работы индикатор периодически отправляет информацию о показателях нулевого бара, чтобы скорректировать текущие показания на нём. Во время закрытия бара индикатор должен послать окончательную информацию о баре на сервер, который вернет значение для закрывшегося бара. При деинициализации/разрыве соединения сервер освобождает выделенный хэндл и уничтожает набор данных (или не освобождает, кому как нравится).
Отвратительный вариант - при старте вся система тормозиться вместе с терминалом, или приходиться очень долго ждать загрузки ( некоторые до сих пор на медленных каналах сидят - например мофильные сети ) . Гораздо целесообразнее подкачивать информацию небольшими кусками сохраняя историю на машине пользователя, таким образом в трафик идет только свежая информация как решено в последних версиях этого : http://xrust.land.ru/download/
Подкиньте идейку
Первый элемент ряда храним в явном виде. Далее дифференцируем ряд и используем энтропийное кодирование.
Отвратительный вариант
даже в случае с ДЛЛ желательно подавать инфу кусками и потребитель не томиться в ожидании ( не задает глупых вопросов " ПОЧЕМУ?"), и красиво в конце концов :)
даже в случае с ДЛЛ желательно подавать инфу кусками и потребитель не томиться в ожидании ( не задает глупых вопросов " ПОЧЕМУ?"), и красиво в конце концов :)
Фоновая/асинхронная загрузка в моем понимании это подразумевает.Вот и я о том же...