Высоконадежный копировщик сделок/сигналов (обсуждение идеологии и разработка) - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
простая схема обмена: генератор сигналов размещает на сервере файл, где все его открытые ордера и позиции, как в терминале. Если хотя бы один ордер или поза изменились, то размещает файл по новой. В этом случае сервер рассылает всем новую версию файла (ну или сообщение с полным содержимым этого файла), а клиент отвечает что получил (сервер дожен содержать список подключенных клиентов). Так же по запросу клиента в любой момент посылает этот файл.
Если клиент навернется или пропустит ордера, то легко может восстановиться прочитав терминальный файл сервера. Если будет покомандный обмен, то м.б. много аварийных и неоднозначных ситуаций. Клиент для диагностики может пересинхронизироваться например раз в Xмин. если не было изменений.
Трафик при такой схеме не д.б. большим. Поэтому можно использовать SSL или https даже.
Сообщения 3х видов: дай, получил, сам файл.
простая схема обмена: генератор сигналов размещает на сервере файл, где все его открытые ордера и позиции, как в терминале. Если хотя бы один ордер или поза изменились, то размещает файл по новой. В этом случае сервер рассылает всем новую версию файла (ну или сообщение с полным содержимым этого файла). Так же по запросу клиента в любой момент посылает этот файл.
Если клиент навернется или пропустит ордера, то легко может восстановиться прочитав терминальный файл сервера. Если будет покомандный обмен, то м.б. много аварийных и неоднозначных ситуаций. Клиент для диагностики может пересинхронизироваться например раз в Xмин. если не было изменений.
Трафик при такой схеме не д.б. большим. Поэтому можно использовать SSL или https даже.
Схема никуда не годная, т.к. файл с торговым сигналом быстро теряет свою актуальность, т.к. сделки нужно совершать вовремя. Самый оперативный вариант - это клиенту держать постоянное соединение с сокетом сервера и ждать появления торговых сигналов. Постоянное соединение не тратит трафик, в отличие от систематических запросов и надежность его достаточно высока.
Как уже я говорил, команд тоже никаких не нужно. Как торговый сигнал появился, сервер его отправляет клиентам в виде одной строки с символом завершения "\n" и ждет следующего. Клиент на сервер ничего не должен отправлять, а только принимать сигналы.
SSL и https - это вообще нахрен не нужно. Во первых владелец, сервера должен будет зарегистрировать домен и купить сертификат, а потом постоянно все это хозяйство продлять тоже не забесплатно, чтобы работать с такими протоколами. А во вторых, эти протоколы для шифрования данных, чтобы посторонние, перехватив информацию в TCP потоке не смогли ее дешифровать. Нагрузка на сервер будет колоссальная если на него законектятся много клиентов, потому что шифрование - это не халям балям, а операции возведения больших целых чисел в большие степени по модулю.
Схема никуда не годная, т.к. файл с торговым сигналом быстро теряет свою актуальность, т.к. сделки нужно совершать вовремя. Самый оперативный вариант - это клиенту держать постоянное соединение с сокетом сервера и ждать появления торговых сигналов. Постоянное соединение не тратит трафик, в отличие от систематических запросов и надежность его достаточно высока.
Как я говорил, команд тоже никаких не нужно. Как торговый сигнал появился, сервер его отправляет клиентам в виде одной строки и ждет следующего. Клиент на сервер ничего не должен отправлять, а только принимать сигналы.
да нет там никакой задержки т.к. рассылка идет сразу всем клиентам после появления сигнала.
Покомандно конечно экономит трафик, но надежность будет фиговая. Клиент должен иметь возможность получить все ордера (отложки к примеру, или модификации ордеров) даже которые пропустил по каким-то причинам.
да нет там никакой задержки т.к. рассылка идет сразу всем клиентам после появления сигнала.
Покомандно конечно экономит трафик, но надежность будет фиговая. Клиент должен иметь возможность получить все ордера (отложки к примеру, или модификации ордеров) даже которые пропустил по каким-то причинам.
Ладно, лепите горбатого. Только кто будет делать такую чушь - это уже не моя проблема.
Мое дело предложить самый оптимальный вариант с минимальной нагрузкой и трафиком, Ваше право - отказаться.
SSL и https - это вообще нахрен не нужно. Во первых владелец сервера должен зарегистрировать домен и купить сертификат, а потом постоянно его продлять тоже не забесплатно, чтобы работать с такими протоколами. А во вторых, эти протоколы для шифрования данных, чтобы посторонние, перехватив информацию в TCP потоке не смогли ее дешифровать. Нагрузка на сервер будет колоссальная если на него законектятся много клиентов, потому что шифрование - это не халям балям, а операции возведения больших целых чисел в большие степени по модулю.
зато все существующие сервер-сигналы без аутентификации вскрывают за пару часов. Хотя шифрование может и лишнее))
зато все существующие сервер-сигналы без аутентификации вскрывают за пару часов. Хотя шифрование может и лишнее))
1. Не часов, а миллисекунд
2. А кому нахрен нужны Ваши сигналы, чтобы их еще кто-то вкрывал? Анекдот про Неуловимого Джо.
Ладно, лепите горбатого. Только кто будет делать такую чушь - это уже не моя проблема.
Мое дело предложить самый оптимальный вариант с минимальной нагрузкой и трафиком, Ваше право - отказаться.
1. Не часов, а миллисекунд
2. А кому нахрен нужны Ваши сигналы, чтобы их еще кто-то вкрывал? Анекдот про Неуловимого Джо.
мне то пофиг, но люди которые продают сигналы за деньги растраиваются)) Но если это не важно в этом проекте - то нет проблем, защита не нужна
если у клиента пропал коннект, или перезагрузился, а в это время прошли какие-то отложки или модификации ордеров как это исправить с помощью покомандного обмена telnet? Я не знаю, может и можно - поэтому спрашиваю.
Я уже говорил, что нахрен никакого покомандного телнета не нужно, а Вы опять заладили чушь какую-то.
В файлы дублировать и выкладывать на какой нибудь дешевенький хостинг по SendFTP(). И пусть клиент считывает по FTP файлы с временем создания, за которое он был вне коннекта.
Я уже говорил, что нахрен никакого покомандного телнета не нужно, а Вы опять заладили чушь какую-то.
В файлы дублировать и выкладывать на какой нибудь дешевенький хостинг по SendFTP(). И пусть клиент считывает по FTP файлы с временем создания, за которое он был вне коннекта.
Т.е. это не твоё))
Reshetov:
Сокет по протоколу TCP/IP. Передавать сигналы можно в текстовом виде в одной строке на сигнал, типа "EURUSD Buy 1.0\n", как через Telnet, т.к. это самый примитивный вариант не требующий сложной процедуры обмена, как у протоколов http или ftp c минимальным парсингом.
Бред опять несешь - дублировать одно другим, когда можно обойтись одним)) Нахрена хранить файлы, когда достаточно один - последний с текущим состоянием всех ордеров и позиций? Объединить обмен по требованию сервера (когда на мастер-счете что-то изменилось) и по требованию клиента (когда у него проблемы были или несоответствия), а не придумывать дополнительные костыли. Передавать по требованию сервера можно и не весь файл с ордерами, а только то что изменилось и будет твой вариант "командного обмена".