服务器到客户端通信架构

Question

我们有一个“交易复制”软件，顾名思义，该软件用于反映从一个交易者（发件人）到多个其他交易者（接收者）的交易。它有三个主要组件：

1.发件人客户端。

2.服务器。

3.接收方客户端。

发件人 - >服务器 - >接收机

发件人使用MQL脚本构建。 MQL是使用C++构建的交易者的编程语言。由于有一个发件人，发件人代码会将交易信息（或信号）推送到服务器。 服务器是基于PHP的简单MySQL数据库，管理员可以维护此信号转发的用户。 接收器也使用MQL构建。但是目前它是使用独特的技术构建的，为了清楚表明我们不确定，因为我们第一次接触到代码，原来的程序员没有看到（如预期的那样）。所以回到这个问题，接收方客户端有一段代码似乎“轮询”服务器的任何更新。 MQL使用C++ lib调用InternetReadFile函数，它使用InternetOpenUrlA。现在，MQL每X毫秒发送一个请求到服务器，以查看是否有新信号并在找到它时进行提取。如果提供MQL代码可以帮助我做到这一点。

现在我的问题。

1. 这是一个好方法吗？如果接收用户增长数百人，并且每隔X毫秒“轮询”服务器（或使用InternetReadFile进行的任何操作），会发生什么情况。根据X，它不会在一个点上杀死服务器CPU吗？我认为这是一个拉服务，但我相信服务器应该推出这些信息，而不是所有的接收方客户端不断请求。

2. 如果上述问题的答案是“这是一个坏方法”，那么最好的方法是什么？通过从服务器到每个接收器的套接字通信推动信号是一个好主意吗？在接收方客户端有没有像“端口转发”和“改变IP”那样的问题？或者他们可以通过编程方式克服？

乐意提供代码，进一步说明。

Answer 1

任何民意调查都会引入延误并产生额外的流量，你无法逃脱。理想情况下，你会想要寻求ether直接解决方案：“套接字到套接字”或异步推动像zeromq（也通过套接字btw，只是抽象）。

问题是：当您在交易员终端内部运行时，是否值得付出努力？由于你正在从终端到服务器到终端，延迟已经是固有的。另外，接收方的执行以及代理的执行速度会延迟。所以最后，当市场在移动时，您会看到原始和副本之间巨大的差异，这会破坏解决方案的目的。这个功能实际上应该由代理提供，并在服务器API插件或管理API（至少）中实现。除了大多数经纪商的设置之外，延迟+点差+加价将会消耗客户希望通过复制“良好”交易而获得的优势。

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