Архитектура связи между сервером и клиентом

У нас есть программное обеспечение для «копирования сделок», которое, как следует из названия, используется для отражения сделок от одного трейдера (отправителя) к нескольким другим трейдерам (получателям). Он состоит из трех основных компонентов:

<сильный>1. Клиент отправителя.

<сильный>2. Сервер.

<сильный>3. Клиент получателя.

Отправитель -> Сервер -> Получатель

Отправитель создается с помощью скрипта MQL. MQL — это язык программирования для трейдеров, созданный на C++. Поскольку есть один отправитель, код отправителя отправляет торговую информацию (или сигнал) на сервер. Сервер основан на PHP с простой базой данных MySQL, где администратор может поддерживать пользователей, которым перенаправляется этот сигнал. Приемник также построен с использованием MQL. Но в настоящее время он построен с использованием уникальной техники, чтобы было ясно, что мы не уверены в этом, потому что мы впервые получаем код, а оригинального программиста нигде не видно (как и ожидалось). Итак, вернемся к проблеме: у клиента-получателя есть фрагмент кода, который, кажется, «опрашивает» сервер на наличие обновлений. MQL использовал библиотеку C++ для вызова функции InternetReadFile, которая использует InternetOpenUrlA. Теперь MQL отправляет запрос на сервер каждые X миллисекунд, чтобы узнать, есть ли новый сигнал, и извлекает его, если он найден. Если предоставление кода MQL поможет, я могу это сделать.

Теперь к моим вопросам.

  1. Это хороший подход? Что произойдет, если количество принимающих пользователей увеличится на сотни, и каждый из них будет «опрашивать» сервер (или что-то еще, что он делает с помощью InternetReadFile) каждые X миллисекунд. В зависимости от X, не убьет ли он ЦП сервера в какой-то момент? Я вижу, что это реализовано как служба извлечения, тогда как я считаю, что сервер должен выталкивать эту информацию, а не постоянно запрашивать все клиенты-получатели.

  2. Если ответ на приведенный выше вопрос «это плохой подход», то какой подход лучше всего? Является ли хорошей идеей передача сигналов через сокеты от сервера к каждому из приемников? Ожидаются ли такие проблемы, как «переадресация портов» и «изменение IP-адресов» на стороне клиента-получателя? Или их можно программно побороть?

Рад предоставить код, дополнительные разъяснения.


c++ architecture client-server mql4 metatrader4
person Aziz    schedule 26.11.2012    source источник
comment
Для тех, кто сталкивается с подобными вопросами. Мы рассмотрели MQ, веб-сокеты и в итоге решили использовать WPF: msdn.microsoft. com/en-us/library/ms752254.aspx   -  person Aziz    schedule 31.12.2012

Ответы (1)


arrow_upward
4
arrow_downward

Все, что проводит опросы, будет вызывать задержки и генерировать дополнительный трафик, от которого вы не сможете избавиться. В идеале вы хотели бы использовать прямое эфирное решение: «сокет в сокет» или асинхронное нажатие с чем-то вроде zeromq (также через сокет, кстати, просто абстрагировано).

Вопрос в том, стоит ли это усилий, когда вы работаете внутри торгового терминала. Поскольку вы переходите от терминала к серверу и к терминалу, задержка уже присуща. Кроме того, вас задержит исполнение на стороне получателя, а также скорость исполнения брокера. Итак, в конце концов, когда рынок движется, вы увидите огромную разницу между оригиналом и копией, которая противоречит цели решения. Эта функциональность действительно должна быть предоставлена ​​брокером и реализована в плагинах API сервера или API менеджера (по крайней мере). Если не считать этого, настройки большинства брокеров: задержка + спред + наценка съедят любое преимущество вашего клиента, если он надеется получить путем копирования «хороших» сделок.

Чтобы решить проблемы с сетью, поскольку вы знаете, что ваши клиенты работают с mt4, вы также знаете, что исходящий трафик 443 должен быть открыт на клиентской машине, поскольку именно его использует mt4. Вы также можете быть уверены, что http(80) также открыт, тем более, что текущее решение использует http для связи. Поэтому, если вы сделаете свой сервер хостом на 443 или 80, и ваш отправитель и получатель подключатся к вашему серверу в качестве клиентов, настройки IP-адреса клиента и брандмауэра не должны иметь значения. Кроме того, вы всегда можете реализовать какую-либо конфигурацию на основе файлов, чтобы вы могли настроить порт на стороне клиента во время установки/устранения неполадок. В конце концов, будут ли ваши проблемы с опросом или асинхронной сетью одинаковыми, все сводится к tcp через сокет.

person Dmitry    schedule 27.11.2012
comment
Спасибо Дмитрий. Проблема присущей задержки хорошо известна нам, но величина проскальзывания цены, которую она вызывает на стороне получателя, — это то, что можно игнорировать, если ‹ 1 секунды для объема этого проекта. ZeroMQ выглядит как хорошее решение для абстрактных сокетов. Хотя не совсем понял последний абзац - person Aziz; 27.11.2012
comment
Вам очень повезет, если задержка выполнения приемника будет меньше секунды. Предполагая идеальные сетевые условия, клиент-сервер составляет ~ 150 мс, скажем, в США. Если ваш отправитель, сервер или получатель находится за океаном, вы, скорее всего, получите вдвое больше. 2 ноги дают вам более 1/2 секунды только для транспортировки. Фактор того, что mql мучительно медленный, а брокеру просто не терпится подсунуть вам любые изменения, которые они получают, вам очень повезет, если вы получите меньше секунды. - person Dmitry; 27.11.2012
comment
Во втором абзаце все, что я пытаюсь сказать, это то, что по крайней мере исходящие порты 443 и 80 должны быть открыты. В противном случае клиенты не смогут торговать или просматривать веб-страницы, если они заблокированы или переадресованы, у них будет гораздо больше различных проблем. - person Dmitry; 27.11.2012
comment
Понял. И да, я согласен с вашими замечаниями о задержке, но ожидается, что отправитель и получатель будут в одной стране. Однако основной причиной отсутствия проскальзывания будет использование при копировании лимитных и стоп-приказов. В любом случае это должен решить владелец продукта, и мы передали все такие опасения. Спасибо, что предложили свои советы по этому вопросу. Ваше здоровье. - person Aziz; 28.11.2012