Server to Client Communication Architecture

Question

We have a "trade copying" software, which, as the name suggests is used to mirror trades from one trader(sender) to multiple other traders (receivers). It has three main components:

1. Sender client.

2. Server.

3. Receiver client.

Sender -> Server -> Receiver

The sender is built using MQL script. MQL is a programming language for traders built using C++. Since there is one sender the sender code pushes the trade information (or signal) to the server. The server is PHP based with a simple MySQL database where the admin can maintain the users to whom this signal is forwarded. The receiver is also built using MQL. But currently it is built using a unique technique , to make it clear we are not sure about it because we are getting our hands on the code for the first time and the original programmer is no where to be seen (as expected). So back to the issue, the receiver client has a piece of code that seems to "poll" the server for any updates. The MQL used a C++ lib to call InternetReadFile function which uses InternetOpenUrlA. Now the MQL sends a request to server every X millisecond to see if there is a new signal and pulls it if it is found. If providing the MQL code helps I can do that.

Now to my questions.

1. Is this is a good approach? What happens if receiving users grow hundreds and each one "polls" the server (or whatever it is doing using InternetReadFile) every X milliseconds. Depending on X, won't it just kill the server CPU at one point? I see this implemented as a pull service, whereas I believe server should be pushing out this information rather than all receiver clients constantly requesting.

2. If the answer to above question is "it is a bad approach", what is the best approach? Is pushing signals through socket communication from the server to each of the receivers a good idea? Are there issues expected like "port forwarding" and "changing IPs" at receiver client ends? Or can they be programmatically overcome?

Happy to provide code, further clarifications.

Answer 1

Anything that polls is going to introduce delays and generate extra traffic, that you can not escape. Ideally you would want to go for ether direct solution: "socket to socket" or async push with something like zeromq(also over socket btw, just abstracted).

The question is: is it worth the effort when your running inside the trader terminal. Since you're going from terminal to server to terminal, delay is already inherent. Plus, you will be delayed by the execution on the receiver side as well as the execution speed of the broker. So in the end, when the market is moving you will see a huge difference between the original and the copy which defeats the purpose of the solution. This functionality is really something that should be provided by the broker and implemented in server api plugins or manager api(at least). Short of that most brokers setups: delay + spread + markup will eat up whatever advantage your client if hoping to gain by copying "good" trades.

To address networking concerns, since you know your clients are running mt4 you also know that 443 outbound should be opened on client machine since that's what mt4 uses. You can also be fairly confident that http(80) is open as well, especially since the current solution uses http to communicate. So if you make you server host on 443 or 80 and both your sender and receiver connect as clients to your server, client ip and firewall setups should not matter. Short of that you can always implement some kind of file based config so you can tweak the port on the client side during install/troubleshooting. In the end, whether your polling or async your network problems will be the same, it all boils down to tcp over a socket.