c++ - 服务器到客户端通信架构

Question

我们有一个“交易复制”软件，顾名思义，该软件用于将一个交易者（发送者）的交易镜像到多个其他交易者（接收者）。它具有三个主要组成部分：

1. 发件人客户端。

2. 服务器。

3.接收客户端。

发送者 -> 服务器 -> 接收者

发送方是使用MQL脚本构建的。MQL 是一种使用 C++ 构建的交易者编程语言。由于有一个发送者，发送者代码将交易信息（或信号）推送到服务器。该服务器是基于 PHP 的，带有一个简单的 MySQL 数据库，管理员可以在其中维护向其转发此信号的用户。接收器也是使用 MQL 构建的。但是目前它是使用一种独特的技术构建的，为了清楚起见，我们不确定它，因为我们是第一次接触代码，而原始程序员却无处可寻（正如预期的那样）。回到这个问题，接收客户端有一段代码似乎在“轮询”服务器以获取任何更新。MQL 使用 C++ 库调用InternetReadFile函数，该函数使用InternetOpenUrlA. 现在，MQL 每 X 毫秒向服务器发送一个请求，以查看是否有新信号，如果找到则拉取它。如果提供 MQL 代码有帮助，我可以做到。

现在回答我的问题。

1. 这是一个好方法吗？如果接收用户增长数百并且每个用户每 X 毫秒“轮询”服务器（或使用 InternetReadFile 执行的任何操作）会发生什么情况。取决于X，它不会在某一时刻杀死服务器CPU吗？我认为这是作为拉取服务实现的，而我认为服务器应该推送此信息，而不是所有接收者客户端不断请求。

2. 如果上述问题的答案是“这是一种不好的方法”，那么最好的方法是什么？通过套接字通信将信号从服务器推送到每个接收器是一个好主意吗？接收器客户端是否会出现“端口转发”和“更改 IP”等问题？还是可以通过编程方式克服它们？

很高兴提供代码，进一步说明。

Answer 1

任何民意调查都会引入延迟并产生额外的流量，这是您无法逃脱的。理想情况下，您希望使用以太直接解决方案：“套接字到套接字”或使用 zeromq 之类的异步推送（也通过套接字 btw，只是抽象的）。

问题是：当您在交易终端内奔跑时，是否值得付出努力。由于您要从终端到服务器再到终端，延迟已经是固有的。此外，您将因接收方的执行以及经纪人的执行速度而延迟。因此，最终，当市场发生变化时，您会看到原始和副本之间存在巨大差异，这违背了解决方案的目的。这个功能确实应该由代理提供并在服务器 api 插件或管理器 api 中实现（至少）。除了大多数经纪商的设置之外：延迟 + 点差 + 加价将吞噬您的客户如果希望通过复制“好”交易而获得的任何优势。

为了解决网络问题，由于您知道您的客户端正在运行 mt4，因此您还知道应该在客户端计算机上打开 443 出站，因为这是 mt4 使用的。您也可以相当确信 http(80) 也是开放的，特别是因为当前的解决方案使用 http 进行通信。因此，如果您将服务器主机设置在 443 或 80 上，并且您的发送方和接收方都作为客户端连接到您的服务器，则客户端 IP 和防火墙设置应该无关紧要。除此之外，您始终可以实现某种基于文件的配置，以便您可以在安装/故障排除期间调整客户端的端口。最后，无论您的轮询或异步网络问题是否相同，都归结为通过套接字的 tcp。