我们有一个“交易复制”软件，顾名思义，该软件用于镜像从一个交易者（发送者）到多个其他交易者（接收者）的交易。它有三个主要组成部分：
1。发件人客户。
2。服务器。
第3。接收方客户端。
发件人 - ＆gt;服务器 - ＆gt;接收器
发件人使用MQL脚本构建。 MQL是使用C ++构建的交易者的编程语言。由于有一个发送者，发送者代码将交易信息（或信号）推送到服务器。 服务器是基于PHP的，具有简单的MySQL数据库，管理员可以维护转发此信号的用户。 接收器也是使用MQL构建的。但是目前它是使用一种独特的技术构建的，为了说清楚我们不确定它，因为我们第一次接触代码并且原始程序员无处可见（正如预期的那样）。回到这个问题，接收器客户端有一段代码似乎“轮询”服务器进行任何更新。 MQL使用C ++ lib来调用 InternetReadFile 函数，该函数使用 InternetOpenUrlA 。现在，MQL每隔X毫秒向服务器发送一个请求，以查看是否有新信号，如果找到则将其拉出。如果提供MQL代码有助于我做到这一点。
现在回答我的问题。
这是一个好方法吗？如果接收用户增长数百个，并且每个X毫秒，每个人“轮询”服务器（或使用InternetReadFile执行的任何操作），会发生什么。根据X，它不会只是在一点上杀死服务器CPU吗？我认为这是作为拉服务实现的，而我相信服务器应该推出这些信息而不是所有接收客户端不断请求。
如果上述问题的答案是“这是一个糟糕的方法”，那么最好的方法是什么？通过套接字通信从服务器向每个接收器推送信号是一个好主意吗？接收方客户端是否存在“端口转发”和“更改IP”等问题？或者可以通过编程方式克服它们？
很高兴提供代码，进一步澄清。
答案 0 :(得分：4)
任何民意调查都会引入延迟并产生额外的流量，这是你无法逃避的。理想情况下，您可能希望使用以太直接解决方案：“socket to socket”或使用zeromq之类的异步推送（也通过套接字btw，只是抽象）。
问题是：当你在交易者终端内跑步时，是否值得努力。由于您从终端到服务器到终端，延迟已经是固有的。另外，接收器端的执行以及代理的执行速度将延迟。因此，最终，当市场发展时，您将看到原始版本与副本之间存在巨大差异，从而破坏了解决方案的目的。这个功能实际上应该由代理提供，并在服务器api插件或经理api中实现（至少）。没有大多数经纪人设置：如果希望通过复制“好”交易获得收益，延迟+差价+加价会吞噬客户的任何优势。
要解决网络问题，因为您知道您的客户端正在运行mt4，您还知道应该在客户端计算机上打开443出站，因为这是mt4使用的。您也可以相当确信http（80）也是开放的，特别是因为当前的解决方案使用http进行通信。因此，如果您将服务器主机设置为443或80，并且发送方和接收方都作为客户端连接到服务器，则客户端IP和防火墙设置无关紧要。除此之外，您始终可以实现某种基于文件的配置，以便在安装/故障排除期间调整客户端端口。最后，无论您的轮询还是异步，您的网络问题都是一样的，这一切都归结为tcp over socket。