Высоконадежный копировщик сделок/сигналов (обсуждение идеологии и разработка) - страница 8
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Зачем в такие дебри лезть? Есть стандартный контрол для работы с TCP/IP, написать отдельную программу для этого дела. В терминале советнк, связь советника с программой (в пределах одного компьютера, любым удобным вам способом)... и нет надобности изобретать велосипед - порты слушать, все уже давно за вас слушают.
в том и дело. что пытаюсь продумать всесторонне. Конечно, изначально требуется вкладывать большую масштабируемость. То есть цель - делать как для 1000-ч. И не важно, что это будут использовать потом единицы.
Поэтому и пытаюсь сейчас выбрать и определиться - или скорость и микротрафик с сокетами. Или http и немалый трафик на постоянной долбежке клиентов за новой порцией инфы.
Думаю второй вариант лучше. Для тех кому нужна масштабируемость, а таких единицы, в любом случае придется нести дополнительные затраты. Пусть платят и за соответствующий траффик.
Остальные же в 90% случаев будут использовать с малым числом клиентов, и надежность соединения, а значит и функциональность, в этом случае важнее чем трафик.
Да и в первом случае без надежного коннекта не получится хорошего решения.
в том и дело. что пытаюсь продумать всесторонне. Конечно, изначально требуется вкладывать большую масштабируемость. То есть цель - делать как для 1000-ч. И не важно, что это будут использовать потом единицы.
Поэтому и пытаюсь сейчас выбрать и определиться - или скорость и микротрафик с сокетами. Или http и немалый трафик на постоянной долбежке клиентов за новой порцией инфы.
А что если получившие инфу клиенты сами станут серваками и раздадут её некому набору клиентов. Как в скайпе.
ЗЫ тогда имеем масштабируемую сеть, пока она маленькая приказы проходят напрямую от сервака, как только сеть разростается появляются второй эшелон, третий. При этом нагрузка на сервак не увеличивается. Сеть конфигурировать по пингу между машинами.
А что если получившие инфу клиенты сами станут серваками и раздадут её некому набору клиентов. Как в скайпе.
Как раз только посмотрел новость) https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA
С peer-to-peer было бы "революционное" решение, не имеющее аналогов)
Только надо думать, реально ли, и вообще, есть ли целесообразность в этом.
Как раз только посмотрел новость) https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA
С peer-to-peer было бы "революционное" решение, не имеющее аналогов)
Только надо думать, реально ли, и вообще, есть ли целесообразность в этом.
А что если получившие инфу клиенты сами станут серваками и раздадут её некому набору клиентов. Как в скайпе.
вариант хороший, но масштабный :) думаю что для синхронизации клиентов с мастером делать дополнительный обмен между самими клиентами избыточно.
Хотя конечно каждый клиент будет ставать минисервером для рассылки принятой инфы, и это в принципе заслуживает обдумывания.
Зачем в такие дебри лезть? Есть стандартный контрол для работы с TCP/IP, написать отдельную программу для этого дела. В терминале советнк, связь советника с программой (в пределах одного компьютера, любым удобным вам способом)... и нет надобности изобретать велосипед - порты слушать, все уже давно за вас слушают.
Здесь хочу сделать общефорумное обсуждение между людьми, которые на этом съели собаку. И на основани выведенных плюсов и минусов технологий - сделать варианты надежных копировщиков, которые стабильны и устойчивы как к количеству клиентов так как качеству соединения и нагрузке на каналы.
..
И на основани выведенных плюсов и минусов технологий - сделать варианты надежных копировщиков, которые стабильны и устойчивы как к количеству клиентов так как качеству соединения и нагрузке на каналы.
Те на повестке два риска.
1 не получить сигнал из-за неполадок в связи
2 не получить правильное сообщение из-за потерь битов при передаче.
тогда без общения между соседними клиентами не обойтись, получив три сигнала от разных источников можно сделать побитовую сверку и вывести истинное сообщение по принципу "2 из 3 верно". Такая схема более защищена как от неполадок связи, так и от потерь при передаче. Тогда сообщения можно шифровать в битные маски и сжать до минимума (вместо передачи стринг предложений). Что уменьшит трафик сервера.
ЗЫ А чтоб небыло сбоя из-за отвалившегося соседа, формировать избыточную рассылку, например клиент получает сигнал от сервера и 4 соседей, но в работу берутся серверный сигнал и 2 сигнала от соседей пришедших первыми.
Те на повестке два риска.
1 не получить сигнал из-за неполадок в связи
отсутсвие связи на клиенте не решается никак. она или есть или её нет. подразумевается, что сервер имеет связь всегда.
2 не получить правильное сообщение из-за потерь битов при передаче.
неверное сообщение можно подписать например хешем. при его неверном значении происходит запрос сообщения с сервера повторно. но обычно наличие в конце и в середине файлов спец меток по типу @label@ уже делает однозначную трактову про полноту принятого сообщения.
...тогда без общения между соседними клиентами не обойтись, получив три сигнала от разных источников можно сделать побитовую сверку и вывести истинное сообщение по принципу "2 из 3 верно". Такая схема более защищена как от неполадок связи, так и от потерь при передаче. Тогда сообщения можно шифровать в битные маски и сжать до минимума (вместо передачи стринг предложений). Что уменьшит трафик сервера.