Communication architecture between server and client

Question

We have “trading copy” software, which, as the name implies, is used to reflect transactions from one trader (sender) to several other traders (recipients). It has three main components:

1. Sender's customer.

2. The server.

3. Customer's recipient.

Sender → Server → Recipient

The sender is created using the MQL script. MQL is a programming language for traders built using C ++. Since there is one sender, the sender code pushes trade information (or signal) to the server. The server is based on PHP based on a simple MySQL database, where the administrator can support users who receive this signal. The receiver is also built using MQL. But now it is built using a unique technique, so that it is clear that we are not sure of this, because we get the code for the first time for the first time, and the original programmer has no where to see it (as expected). Therefore, returning to the problem, the receiving client has a piece of code that appears to be a “polling” of the server for any updates. MQL used C ++ lib to call the InternetReadFile function, which uses InternetOpenUrlA. Now MQL sends a request to the server every X milliseconds to see if there is a new signal and pulls it if it is found. If providing MQL code helps me do this.

Now to my questions.

• Is this a good approach? What happens if users get hundreds, and each of them "polls" the server (or whatever it does with the help of InternetReadFile) every X milliseconds. Depending on X, would it just kill the server processor at some point? I see that this is implemented as a pull service, while I believe that the server should push this information, and not all client clients that constantly request.

• If the answer to the previous question is “bad approach”, then what is the best approach? Is pushing signals through a socket connection from the server to each receiver a good idea? Are problems such as “port forwarding” and “changing IP addresses” expected on the client's client computer? Or can they be overcome programmatically?

We are pleased to provide a code, additional clarifications.

Answer 1

All that polls are going to introduce delays and generate additional traffic that you cannot avoid. Ideally, you would like to go on-air with a direct solution: "socket to socket" or asynchronous push with something like zeromq (also via btw socket, just abstracted).

The question is whether it is worth while working inside the trader's terminal. As you go from terminal to server to terminal, a delay is already inherent. In addition, you will be delayed by the execution on the recipient's side, as well as the speed of the broker. Thus, at the end, when the market moves, you will see a huge difference between the original and the copy that defeats the goal of the solution. This functionality is really what should be provided by the broker and implemented in api server plugins or api manager (at least). With the exception of most broker's settings: delay + spread + markup eats up any advantage of your client if you are hoping to get by copying "good" deals.

To fix network problems, since you know that your clients are working with mt4, you also know that 443 outbox should be open on the client machine since it uses mt4. You can also be fairly confident that http (80) is also open, especially since the current solution uses http for communication. Therefore, if you make the server server 443 or 80, and your sender and recipient connect as clients to your server, the client and firewall settings should not matter. In addition, you can always implement some kind of file-based configuration so that you can configure the port on the client side during installation / troubleshooting. In the end, whether your poll or asynchronous network problems are the same, it all comes down to tcp over the socket.