Архитектура связи сервера с клиентом
У нас есть программное обеспечение для копирования сделок, которое, как следует из названия, используется для зеркального отображения сделок от одного трейдера (отправителя) к множеству других трейдеров (получателей). Он состоит из трех основных компонентов:
1. Отправитель клиента.
2. Сервер.
3. Получатель клиента.
Отправитель -> Сервер -> Получатель
Отправитель построен с использованием MQL скрипт. MQL — это язык программирования для трейдеров, созданный с использованием C ++. Поскольку существует один отправитель, код отправителя отправляет информацию о торговле (или сигнал) на сервер.
Сервер на основе PHP с простой базой данных MySQL, где администратор может поддерживать пользователей, которым этот сигнал пересылается.
Приемник также построен с использованием MQL. Но в настоящее время он построен с использованием уникальной техники, чтобы прояснить, что мы не уверены в этом, потому что мы впервые попадаем в код, а оригинальный программист не видит, где его можно увидеть (как и ожидалось). Итак, вернемся к этой проблеме: у клиента-получателя есть фрагмент кода, который, кажется, «опрашивает» сервер на наличие обновлений. MQL использовал C ++ lib для вызова InternetReadFile функция, которая использует InternetOpenUrlA. Теперь MQL отправляет запрос на сервер каждую X миллисекунду, чтобы увидеть, есть ли новый сигнал, и извлекает его, если он найден. Если предоставление кода MQL помогает, я могу это сделать.
Теперь к моим вопросам.
-
Это хороший подход? Что происходит, если число принимающих пользователей увеличивается до сотни, и каждый «опрашивает» сервер (или все, что он делает с помощью InternetReadFile) каждые X миллисекунд. В зависимости от X, не будет ли он просто убить процессор сервера в один момент? Я вижу, что это реализовано как сервис извлечения, хотя я полагаю, что сервер должен распространять эту информацию, а не все клиенты-получатели, постоянно запрашивающие.
-
Если ответ на поставленный выше вопрос «это плохой подход», каков наилучший подход? Является ли передача сигналов через сокетную связь от сервера к каждому из приемников хорошей идеей? Ожидаются ли такие проблемы, как «переадресация портов» и «изменение IP-адресов» на приемных клиентских концах? Или они могут быть программно преодолены?
Рад предоставить код, дальнейшие разъяснения.
Решение
Все, что опросы будут вводить задержки и генерировать дополнительный трафик, что вы не можете избежать. В идеале вы хотели бы пойти на прямое решение эфира: «сокет в сокет» или асинхронный push с чем-то вроде zeromq (также поверх сокета btw, только что абстрагированный).
Вопрос: стоит ли усилий, когда вы бегаете внутри терминала трейдера. Так как вы переходите от терминала к серверу к терминалу, задержка уже присуща. Кроме того, вы будете задержаны исполнением на стороне получателя, а также скоростью исполнения брокера. Таким образом, в конце концов, когда рынок движется, вы увидите огромную разницу между оригиналом и копией, которая противоречит цели решения. Эта функциональность действительно должна быть предоставлена брокером и реализована в плагинах api сервера или менеджере api (по крайней мере). Кроме этого, большинство настроек брокеров: задержка + спред + разметка поглотят любое преимущество вашего клиента, если вы надеетесь получить прибыль, копируя «хорошие» сделки.
Чтобы решить проблемы с сетью, так как вы знаете, что ваши клиенты используют mt4, вы также знаете, что 443 исходящих должен быть открыт на клиентском компьютере, поскольку это то, что использует mt4. Вы также можете быть достаточно уверены, что http (80) также открыт, тем более что текущее решение использует http для связи. Таким образом, если вы устанавливаете хост сервера на 443 или 80, и отправитель и получатель подключаются как клиенты к вашему серверу, настройки ip клиента и брандмауэра не должны иметь значения. Если не считать этого, вы всегда можете реализовать какую-то конфигурацию на основе файлов, чтобы вы могли настроить порт на стороне клиента во время установки / устранения неполадок. В конце концов, будут ли ваши проблемы с опросом или асинхронными сетями одинаковыми, все сводится к tcp через сокет.
Другие решения
Других решений пока нет …