Высоконадежный копировщик сделок/сигналов (обсуждение идеологии и разработка)
Ок. Для начала нужно разделить задачи (тип эксперта) на коммерческую (через сеть), и условно некоммерческий вариант (внутри одной ОП системы).
Сетевой вариант - однозначно через доп сервер, ибо безопасность и клиент менеджмент.
Внутрисистемный - связь: маппинг, ибо скорость и надежность.
Так как терминал будет удерживать либку до своего падения, или закрытия - это будет показателем состояния самого МТ (слейва)
И протокол будет выглядеть примерно так :
Мастер создает именованную мапу (имя которой известно всем слейвам), и ждет от них сигнала о запуске путь это будет хендл окна советника (слейва).
Поле того как они обменяются привестствиями, создается еще одна мапа куда сваливаются торговые сигналы и паралельно дается команда обновления окна для каждого из слейвов.
После исполнения сигнала слейв должен доложить об исполнении, или он считается зависшим, и принимаются меры к его поднятию .
При выгрузке (правильной) слейв должен ообщить об этом.
В свою очередь любой из слейвов может контролировать состояние мастера и принимать необходимые меры для его поднятия или подачи аварийного сигнала.
В общем около того.
Относительно связи через сеть - позже.
Делай коммерческую версию и толкай.
Это вы мне ?
Это вы мне ?
После исполнения сигнала слейв должен доложить об исполнении, или он считается зависшим, и принимаются меры к его поднятию .
При выгрузке (правильной) слейв должен ообщить об этом.
эти строки мне напомнили про необходимость обсуждение двух режимов работы
ордерной синхронизации на уровне ордер мастера->ордер клиента. И сигнальной синхронизации на уровне сигнал мастера->сигнал клиенту (нужна ли БД сигналов, подтверждление приема от клиента и т.д)
думаю надо тоже определиться что будет более надежно и менее гиморно в плане синхронизации и потери сигналов. или же вести оба проекта сразу.
Делай коммерческую версию и толкай.
толкать ничего не хочу и не буду. Делаю средство, а не цель. Делаю для всех.
эти строки мне напомнили про необходимость обсуждение двух режимов работы
ордерной синхронизации на уровне ордер мастера->ордер клиента. И сигнальной синхронизации на уровне сигнал мастера->сигнал клиенту (нужна ли БД сигналов, подтверждление приема от клиента и т.д)
думаю надо тоже определиться что будет более надежно и менее гиморно в плане синхронизации и потери сигналов. или же вести оба проекта сразу.
Не надо усложнять, достаточно в определенный промежуток (скажем раз в секунду) посылать контрольный сигнал клиенту, и если он не ответил, уж тогда и действовать.
толкать ничего не хочу и не буду. Делаю средство, а не цель. Делаю для всех.
уважаю таких людей, так держать!!!
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
- локально
- удаленно
планирование делаем сразу в режиме один сервер - много клиентов.
при этом необходимо уделить внимание таким аспектам как
- вариант канала связи (файлы, память для локального; сокеты, http, промежуточный сервер и т.д для удаленного)
- отсутствие нагрузки на канал связи (особенно актуально для удаленной синхронизации)
- отказоустойчивость (восстановление канала в случае его потери)
- переинициализация самого эксперта в случае сбоя терминала/ОС
- недублирование/неудаление сделок при потере/восстановлении связи
и т.д.
также необходимо продумать две идеологии
- синхронизация на уровне наличия ордеров
- синхронизация на уровне отправки сигналов открытия/закрытия ордеров
по каждому предложению желательно расписать плюсы и минусы этого варианта
Хотелось бы с помощью обсуждения прийти к оптимальному решению надежности/простоте системы.
Кодинг и тестирование беру на себя.
Результаты по согласию можно выложить в кодебазу.