Чтение инормации с удаленного сервера. - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Покажет хорошие результаты (хотя не вериться) - сделаю твой DLL за даром. Мыло - itso @ dir . bg
Тест на D1 ничего не значить. Много раз говорилось на этом же форуме, что нужно моделировать по всем тикам, да и это еще не критерий. Пусть поработает на демо 1 месяц - тогда и поговорим.
Покажет хорошие результаты (хотя не вериться) - сделаю твой DLL за даром. Мыло - itso @ dir . bg
Тест на D1 ничего не значить. Много раз говорилось на этом же форуме, что нужно моделировать по всем тикам, да и это еще не критерий. Пусть поработает на демо 1 месяц - тогда и поговорим.
Покажет хорошие результаты (хотя не вериться) - сделаю твой DLL за даром. Мыло - itso @ dir . bg
Так я по всем тикам и моделировал! Иначе кол-во сделок значительно падает. А на D1 тестировал, т.к. в советнике период прописан D1
По моему для раздачи команд по сети, протокол ftp либо http не совсем подходят.
Из общепринятых сетевых протоколов самый подходящий - это протокол IRC. На сервере ставится сетвер, работающий по протоколу IRC, а к нему поключаются клиенты.
Плюсы такие:
1) Минимальные задержки
2) Постоянный коннект от клиентов к серверу
3) Протокол IRC является общепринятым в интернете
4) Приличная экономия на трафике (разы)
5) Требуется меньше ресурсов, т.к. при ftp и http клиенты будут постоянно подключаться чтобы запросить последнюю информацию
Минусы:
1) Через прокси не может работать (вроде-как). Но сейчас мало кто сидит в инете только через прокси.
А вообще, для большей безопасности можно реализовать свой протокол. Это совершенно несложно (при определенных знаниях и навыках :)
Готов реализовать и сервера и клиента, если аффтар системы поделится стратегией :)
2.) В том то и дело - постоянный коннект и не нужен. Он как раз и генерит трафик.
3.) Вышеуказанные протоколы тоже являются общепринятыми в интернете
4.) Вы АБСОЛЮТНО неправы! Наверно сравниваете IRC и IRC через http - только это - другая сказка...
5.) Ресурсы ОЧЕНЬ невеликие.
А к минусов:
2.) Очень плохой секьюрити - а сделать из http - https - проще простого!
Конечно, можно присобачить какого-то бота. НО! Только если было API! А такого нет и не будет! Так что нужно начать с нуля.
А вот за год
Период День (D1) 2005.05.02 00:00 - 2006.05.01 00:00 (2005.05.01 - 2006.05.01)
Начальный депозит 1000.00
Чистая прибыль 80889592.14
А вот за год
Период День (D1) 2005.05.02 00:00 - 2006.05.01 00:00 (2005.05.01 - 2006.05.01)
Начальный депозит 1000.00
Чистая прибыль 80889592.14
И обсудим.
Нужен именно протокол с постоянным соединением!
Ну давай прикинем, что будет происходить если сделать непостоянное соединение по протоколу http:
Стоит сервер, и у себя выкладывает ОПЕРАТИВНУЮ информацию. А как клиенту узнать, поступила ли новая информация? Нужно обратиться к серверу.
Получается, чтобы получать оперативную информацию, клиенты должны обращаться к серверу каждые N секунд. Что такое "обращение к серверу по протоколу http"?
Во первых, это открытие TCP соединения (минимум 3 IP пакета). Затем пошла аутентификация (минимум 2 пакета). Затем запрос информации: "Типа, ну чо там, торговать иль нет?", ответ, и закрытие соединения (еще 3-4 пакета).
И теперь давайте представим что 1000 клиентов начинают натурально ДОЛБИТЬ этот сервак. Почему ДОЛБИТЬ? Да потому что им надо как можно раньше получить информацию. Думаю что задержка в 1 минуту их не устроит. Будут делать это каждые 10 секунд. И даже при таком интервале не все получат информацию сразу, а некоторые только через 10 секунд.
Мало того, что будет расти потребление трафика. Но еще и сервак будет хорошо нагружен бесполезными обращениями.
Ужос!
А теперь представим, как будет работать по протоколу IRC:
Клиент один раз подключился, один раз прошла аутентификация.
А затем, каждую минуту сервер посылает клиентам информацию, что им надо делать/не делать.
Причем, сервер-то знает, когда ему надо посылать. И будет посылать пакеты только тогда, когда поступила новая информация.
Ему нужно будет только посылать пакеты раз в минуту, чтобы TCP сессия не отвалилась.
Вывод такой:
Надо использовать протокол, в котором сервер может инициировать передачу пакетов клиенту. Это не обязательно IRC. Можно любой другой. IRC - просто первый попавшийся стандартный протокол интернета, где сервер может сам передавать пакеты клиентам (без запроса).
Мало того, аффтару системы даже не обязательно иметь свой сервак в интернете!!! Можно использовать существующий для передачи сообщений всем клиентам!!! Все подключаются к одному IRC каналу, и сервер рассылает сообщения :)
Это конечно не совсем надежно, но на первых порах не требует особых вложений. + на трафике сэкономить можно ;)
Аффтар! Реально, если интересует, могу написать тебе такую систему ;)
Пиши: publicmail$mail.ru
Договоримся!