Discussion of article "Communicating With MetaTrader 5 Using Named Pipes Without Using DLLs"

New comment
 

New article Communicating With MetaTrader 5 Using Named Pipes Without Using DLLs is published:

Many developers face the same problem - how to get to the trading terminal sandbox without using unsafe DLLs. One of the easiest and safest method is to use standard Named Pipes that work as normal file operations. They allow you to organize interprocessor client-server communication between programs. Take a look at practical examples in C++ and MQL5 that include server, client, data exchange between them and performance benchmark.

Many developers face the same problem - how to get to the trading terminal sandbox without using unsafe DLLs.

One of the easiest and safest method is to use standard Named Pipes that work as normal file operations. They allow you to organize interprocessor client-server communication between programs. Although there is an already published article A DLL-free solution to communicate between MetaTrader 5 terminals using Named Pipes on this topic that demonstrates enabling access to DLLs, we will use standard and safe features of client terminal.

You can find more information about named pipes in MSDN library, but we will get down to practical examples in C++ and MQL5. We will implement server, client, data exchange between them and then benchmark performance.

Author: MetaQuotes

 
Do the pips work in the tester?
 
Graff:
Do pipes work in the tester?

Why should communication between different terminals work in the tester?

Do it via events, they work in the tester.

 
Urain:

Why should communication between different terminals work in the tester?

Why not? You should try it. But I don't know why... :)


do it via events, they work in the tester.

What through events? Communication between terminals?

;)

 

Named pipelines work in local agents, but are disabled in clades.

That is, both individual tests and mass local agents can connect to a third-party (not only local) pip server.

 
MetaDriver:
Why not? It's worth a try. I don't know why. :)


what through events? communication between terminals?

;)

Get into the essence of the question, if a person needs communication between programmes in the tester, then the task of data transfer between programmes in one terminal is visible, and it can be done through events, omitting all this nonsense, my answer is quite logical.
 
Urain:
If a person needs communication between programs in the tester, then the task of data transfer between programs in one terminal is obvious, and this can be done through events, omitting all this nonsense, my answer is quite logical.
I got into it, it seemed to me that he is just interested in monitoring the testing process from an external program.
 

At a quick glance, there are two ways to use it:

And articles on this topic will be interesting.

 
Rosh:

At a quick glance, there are two ways to use it:

And articles on this topic will be interesting.

Unfortunately this is possible only for those who know how to program in C for Windows, because:

Renat:
Just note that this is client support, and server connectors cannot be created in the terminal.

I.e. in client-server technologies two clients will not see each other without server mediation. I looked at the subject of creating named channels in other programming languages, but unfortunately, in most of them you can create a client for Windows by standard means, although channels for Unix are created almost everywhere without any problems.

We need gateways in the form of EXE-shells, which could connect two named channels full-duplex according to the algorithm:

  1. Create two named channels A and B
  2. Create the first subprocess that listens to channel A for a connection.
  3. After a client that is waiting for a message connects to channel A, create a second subprocess that listens to channel B for a connection.
  4. The first subprocess is switched on to transfer a byte stream in a loop from channel A to channel B
  5. As soon as a client connects to channel B, the second subprocess is started to read the byte stream in a loop from channel B to channel A.
  6. The second client starts transmitting the first message from channel B to channel A.
  7. and so on and so forth, until some client falls off, after which both channels are destroyed and we move on to point 1. 1

Of course, in single-task MQL scripts full duplex is not necessary, because clients cannot receive and transmit information asynchronously. But half-duplex is suitable only for those cases when the server knows the exchange protocol and can easily calculate where the reception-transmission from one client to another ends in order to switch to the opposite mode. If he does not know this, because he does not have telepathic abilities, and this is known only to the clients exchanging with each other using the protocol known only to them, then a full duplex with two subprocesses is necessary. Such a gateway is convenient because each client has only one channel for communication with another client and the sequence of connection from the client's side does not play any role, if he will certainly check the possibility of connection in the initial cycle. The gateway algorithm excludes the possibility of connection of the client, which is the first according to the protocol must transmit a message before the second client connects and the transmission to the void will not happen.

Theoretically, since the number of named channels is unlimited, it would be possible to create a single-task simplex gateway according to the algorithm:

  1. A first named channel is created for transmission from the gateway to the client
  2. After the first client has made a connection, a second channel is created to receive messages from the client
  3. After the transmitting client has connected to the second channel, the process loops the byte stream from the receiving channel to the transmitting channel.
  4. As soon as a client drops out, we remove both channels and move on to step 1.

In this case you will need two such gateways to connect two clients on half-duplex or one if only simplex is used. The disadvantage compared to a full-duplex gateway is that in MQL scripts you will have to write two channels (for reception and transmission) and in them also strictly observe the sequence of connection: first for reception and then for transmission (otherwise the second channel will never be created). The algorithm of this gateway also excludes the possibility of connecting a client, which is the first according to the protocol must transmit a message before the second client connects and the transmission to the void will not happen.

Naturally, the gateways should provide for the possibility of configuring channel names depending on the sequence of receiving-transmitting and connecting clients, for example, through the command line at startup.

If someone programming in C created such gateways and compiled them into EXEs and posted them here, then it would be easy to create connections between scripts, Expert Advisors and indicators using standard MQL5 tools without tambourine in other programming languages.

Theoretically, you can also write an article on how to properly connect clients with such gateways, so as not to create servers in languages other than MQL (I'm probably not the only one who can't program in C, right?) with specific examples in co-authorship with a C programmer. That is, from me the text of the article and examples in MQL, and from the C-sh programmer sources of gateways in C and EXE-shniki. The fee is shared.

 
By the way, the examples show full-duplex exchange, where you don't need to wait for anyone.

The server is simple, all in sources, including the compiled exe file in the /release directory. Tests can be repeated easily.
 
Renat:
By the way, the examples show full-duplex exchange, where you don't have to wait for anyone.

The server is simple, all in sources, including the compiled exe file in the /release directory. The tests can be repeated easily.

That's not the point. I tried to run your example. It works. But it is of no use, i.e. I tried it and that's all, it can be deleted because it is no longer needed.

On the one hand, you got rid of the dll, but on the other hand, again, for application use you need crutches in other programming languages.

The disadvantage of the proposed method is that it is suitable only for programmers developing applications in languages other than MQL and supporting Windows API. That is, the proposed example is not universal and cannot be adapted to other tasks without modification. And everyone has different tasks. And this means that users will have to create even an elementary exchange of information between two scripts to study in addition to MQL another language, so that on it, create a server in which you need to write some of the logic related to the exchange protocol.

I propose to create gateways once, compile and put out for all comers, so that any user can create connections, using only standard MQL tools.

For example, for me it makes no difference whether open or closed raw files are in C. Because I don't write anything in C, and it will take time to sort out flights. I can't even compile these same raw files. And in Pure Java, as well as in many other programming languages, you can create only client connection via file streams using standard tools. If there were a gateway that connects two named channels at least by simplex, there would be no problems. I would write the exchange protocol in the clients, connect through a couple of gateways, debug and everything works. I.e. there is no need to design and create a separate server for each task.

And at the moment, i.e. without gateways, many people will have to install a development environment for C, learn a new programming language, etc., etc.

The gateway doesn't give a damn: what it receives from one client it sends to another. The logic is dumb, but it allows to unite two clients without any additional crutches and dances with tambourine, i.e. it is universal and independent of the protocol of information exchange and knowledge of the C language.

Here, as they say, the fed does not understand the hungry. Those who develop something in C are unlikely to see any problems. And for the rest of us, we can deal with this system as we wish.

1234567
New comment